作者|刘一莹写在前面的ToB系统交付项目往往是新手BA（BusinessAnalyst，业务分析师）在经历项目时最难上手的类型之一。究其原因，一般企业内部系统的业务逻辑复杂，年代久远，集成系统众多。同时，往往远离终端用户，难以产生共情。其次，因为B端产品往往涉及到更多的垂直领域，比如车企、制造、金融……扑面而来的专业术语让从未接触过的新手不知所措。因此，新手BA可能会不自觉地给那些素未谋面的客户贴上“行业专家”、“深耕多年”、“经验丰富”的标签。但实际上，由于项目行业和客户类型的不同，一些“先入为主”的标签会不自觉地成为我们工作中无形的障碍。通过下面的小故事，看看下面这些“标签”，它们是否曾在你的脑海中挥之不去？1、用户应该是“新手”小A在一次遗留系统改造项目中发现，原来的后台管理系统中有些功能的操作极其复杂，甚至整个界面只有两个按钮，很多操作不得不在系统外进行，对用户来说显得很不友好。当小A提出可能存在的风险时，资深BA给出了解释：一是客户当时资金有限，有些功能连前端接口都没有实现，因为发现数据量大大，系统间依赖性太强，还是用excel比较好，然后顺利上传。第二，这个账号的操作人员都是客户端的资深同事，大家对系统已经很熟悉了。几句话下来，小A深受鼓舞。原来，“MVP”的思路不仅用于ToC产品思路的验证，还用于B端系统的设计。在这种情况下，用户往往不是“新手”。用户的“资历”和对系统的熟悉程度是产品设计中非常重要的考虑因素。在后续做项目的过程中，小A也遇到过很多类似的场景：“某个链接应该不支持这种跳转，为什么非要给用户这个入口呢？”但是可以随意输入吗？”“真实场景中没有用户可以选择的选项，为什么要保留？”……在最初的业务梳理和系统走查过程中，BA新手经常会发现很多情况看似“不合逻辑”的功能或验证缺失，但每次与客户沟通，我发现背后有很多历史和制约的原因，比如缺少一些看似“重要”的检查，可能会影响你的一些运营效率但在权衡努力和风险，以及调查历史用户的使用习惯后，“线上”+“线下”、“系统逻辑”+“规则约束”等方式往往可能是客户更青睐的选择。比如上面的故事，对于小A来说有些复杂的操作，但是对于“高级客户”来说，学习成本并不算太高，出错的风险也很低。因此，在B端系统的设计上，不能一味追求“全”所有场景和验证条件，以“完全菜鸟”的眼光对待“老玩家”，而应该集中精力抓住主要矛盾问题是想“准确”，想“必要”，想“合适”。同时，在这类场景下，不妨多问问自己和客户几个问题，功能优先级可能会变得清晰：如果没有xx功能，“会不会阻碍核心业务逻辑和场景？”“会不会带来非常严重的管理漏洞和风险？”“它会带来财务或法律风险吗？”“按照用户平时的熟悉度和习惯，有必要吗？”“最坏的情况是什么？客户能接受吗？”.....以上只是一些可能的角度，更多的需要在实践中积累。2、有了新系统，用户的使用习惯会“大变样”吗？随着项目的推进，小A又遇到了一个“奇迹”：在某个功能的回归测试中，在测试环境中发现了一个高危bug，但是在生产环境中一直没有发现，而且该功能一直在经营多年。经过QA小伙伴的仔细排查，发现虽然生产系统也存在同样的漏洞，但幸运的是，在系统没有任何提示和验证的情况下，客户的后台管理人员保持了良好的习惯，始终在该时间段进行操作不会引起问题，这样问题就没有发生。这件事让小A意识到，很多时候系统只是一个为用户工作服务的工具。即使我们设计了更细化的系统规则，考虑了更完整的场景，我们还是会漏掉很多一线业务人员遇到的真实问题。为了避免这种情况，我们可以考虑：第一，在用户调研阶段，充分了解用户真实的使用习惯和场景，不能想当然地依赖现有的系统流程；二是注意后期上线前的业务教育和操作说明的编写。强调一些系统目前无法覆盖的场景，或者需要商家自己关注和人工配合的情况；最后与客户强调系统更新后用户流程有哪些变化，商户是否需要增加额外的流程管理和监管。[习俗和制度的约束]有时大于[软件的约束]。这也是为什么大多数企业仍然保留必要的监管手段，如进店检查、业务抽查等。我们不能依靠任何一个系统来满足整个公司的所有业务流程环节。习惯的力量，我们往往不能忽视！3.客户的优先级应该是“最”重要的。经历了几个项目后，小A遇到了经典命题——用户和客户的价值“不匹配”。在与客户讨论解决方案的过程中，小A发现，虽然目前的方案满足了灵活的【系统用户（业务）使用场景】的需求，但在某些场景下，需要牺牲【终端服务用户（客户）】经验。在交流方案的改进点时，客户重申了系统改造的三个要求：整个过程能够顺利进行，不妨碍系统用户的操作；不会增加系统的不稳定性和bug；用户不会受到我们系统的影响。原因是提票，会给总公司和用户体验造成额外的工作量。其实我觉得没那么必要。短短几句话，“降本增效”四个字被客户诠释得淋漓尽致。往往在这种情况下，草草牺牲了B端系统的用户体验。但其实从另一个角度来说，只要能够满足和强调客户的基本价值点，就可以在有限的框架内使用。比如这个故事中，在不牺牲用户体验的前提下，小A之后的解决方案着重于客户更关心的系统稳定性，以及特殊流程的低频等，成功说服了客户，并且取得了更加“三赢”的成绩。事实上，新手BA经常会遇到这种困境。你不妨从以下几个角度来考虑：首先，你需要从产品愿景、价值定位、当前战略目标等角度去衡量。客户提到的优先级是否匹配产品策略层的价值（详见：《当用户不是客户时，如何确定需求的价值？》）；其次，不妨了解一下利益相关者在产品/项目规划中对价值优先级的定义。当然，在产品开发的不同生命周期中，价值优先级会相应发生变化，需要定期回顾和迭代。最后，在很多情况下，客户真正关心的优先事项和价值已经开始显现。例如，成本导向强的客户可能会很在意每个功能的预估，而体验强的用户可能在初期调研阶段的参与度很高。故事中“用户体验”的价值只是一个例子。往往当我们被套上【价值优先】的“魔咒”时，如何在客户可能“不太关心”的角落里做文章，争取最优解，就看我们BA真正的“讨价还价”本事了.4、客户要“无所不知”！对于新手BA来说，很容易陷入被客户需求“牵着鼻子走”的境地，但有的时候，客户未必真的知道自己想要什么。在大多数场景下，客户熟悉业务逻辑，但在系统语言或数字化实施方案方面可能存在盲区。当然，偶尔对接人是新调入产品线的PO，或者是与其他部门协调整合系统时的PO。那么当PO是“新人”，小A也是新人时，可能会存在客户投入少，需求确认不明确等风险。此时，需要考虑：（1）统一与客户的语言。客户可能不熟悉系统语言，或使用一些过时或非正式的描述。所以，在确认需求的过程中，最好用他听得懂的语言来解释，强调系统与现实的映射关系。（2）从真实的业务场景出发。客户可能对一线系统操作员的细节比较熟悉，但对整体系统设计的逻辑并不清晰。我们可以尝试从物理世界的运行入手，再还原到系统上，让他从宏观到微观更好的理解（3）。曾经有客户不同意迭代开发的方式，因为没有功能全景图，分散的故事卡确认会，让需求显得不合逻辑。由于对系统的整体理解不够，项目进度与迭代之间的函数关系始终处于黑盒状态。针对这种情况，我们可以考虑，第一，在写故事卡的时候，可以适当描述一些客户不熟悉的细节，或者提供系统图、流程图，方便客户理解；其次，在每次需求确认会的开始，就明确本次迭代的需求对应于整个用户旅程的哪一部分（比如购买商品），完成了客户/用户的哪些预期目标（可以创建订单）基础商品可在购买过程中添加）；最后会有一张完整的故事线的卡片，尽可能在相似的时间点确认，提前将主题告知客户，让客户邀请相关干系人参与比较熟悉的业务参加会议。总结期望通过几个小故事，分享新手BA在与客户“心理战”过程中可能遇到的一些情况。事实上，归根结底，充分熟悉和了解项目背景、产品愿景和利益相关者关系始终是重要的第一步。如果你像小A一样，无法理解客户做出的一些决定，遇到无数卡顿的时刻，不如回到最初的起点，也许一切都有答案。最后，在拒绝接受“贴标签”客户的同时，也不要给自己“贴标签”。在认清当前不足的前提下，敢于质疑，勇于尝试，最终才能自信地向客户“sayno”。欢迎大家一起讨论你们给客户的“标签”！
