写在前面：
To B系统的交付项目，往往是新手BA（Business Analyst，业务分析师）经历项目时最难上手的类型之一。
其原因是一般企业内部系统业务逻辑复杂，年代久远，集成的系统繁多，同时经常又远离终端用户，很难产生共情。其次，由于B端产品往往涉及垂直领域较多，如车企、制造业、金融... 扑面而来的专业名词，让从未接触过的小白们应接不暇。
于是，新手BA可能会给那些还未曾谋面的客户们不自觉打上 “行业专家”，“深耕多年”，“经验丰富” 等标签。但实际上，由于项目行业，和客户类型的不同，一些“先入为主“的标签，反而会不自觉的成为我们工作时的隐形障碍。
通过下面这几个小故事，看看下面这几个“标签”，是否也曾在你的脑海中徘徊？
1.用户应该是“小白”
小A在一个遗留系统改造项目中发现，原有后台管理人员系统中一些功能的操作异常复杂，甚至整个界面只有两个按钮，很多操作还要在系统外进行，对用户仿佛很不友好。
当小A在提出可能的风险时，资深BA给出了解释：
“第一，当时客户确实资金有限，部分功能连前端界面都没做，因为发现数据量大且系统间依赖太强，不如用excel再上传顺手。
第二，这个账号的操作人员都是客户侧资深的同事，大家都已经系统非常熟悉。”
一番话，小A受到了很大启发。
原来“MVP"的思想不仅多用于To C 产品创意验证, B端系统的设计同样适用。在该类场景下用户往往都不是“小白”，用户的“资深”程度和对系统的熟悉程度是产品设计时很重要的考虑因素。
在之后项目的过程中，小A还遇到了很多类似的场景：
“某链接本不应支持该类跳转，为什么我们还要给用户这个入口？“
“某输入框为什么没有做类型校验，而是可以随意输入？”
“某选项在真实场景下没有用户去选，为什么还要保留？“
......
在初步的业务梳理和系统走查的过程中，新手BA经常发现，很多看似”不合逻辑“的功能或校验缺失的情况。但每次和客户沟通下来都发现，背后有很多的历史和限制原因。比如一些看似“重要“校验的缺失，也许会影响大家的一些操作效率，但是在对effort 与风险权衡，和对历史用户的使用习惯调研后，“线上” “线下”，“系统逻辑” “规则约束” 等方式往往可能是客户更青睐的选择。比如上面故事中，对于小A有些复杂的操作，对于”资深客户“来说，却有着不太高的学习成本和较低的出错风险。
所以，在B端系统设计中，我们不能一味地只追求要想“全“所有的场景和校验条件，以“完全小白”的角度来对待“老玩家”，而更应该集中精力抓住问题的主要矛盾，想”准确“，想”必要“，想“适合”。同时，在该类场景下，不妨多问自己和客户几个问题，功能优先级可能随之就清晰起来：
如果没有xx功能，
“是不是会阻碍核心业务逻辑和场景？”
“是否会带来非常严重的管理上的漏洞和风险？”
“是否会带来金融或法务上的风险？”
“根据用户平时的熟悉程度和习惯，是否是必要？”
“最坏的场景是什么，客户是否能接受？”
.....
以上只是列举其中一些可能的角度，更多的也需要大家在实践中不断积累。
2.上了新系统，用户的习惯要“大改变”？
随着项目的进展，小A又遇到一件“奇事”：在对某功能回归测试时，测试环境中发现一个风险较高的bug，但在生产环境中却从未发现，且该功能已运行多年。在QA小伙伴细细探查之后发现，生产系统虽然存在同样的漏洞，但幸运的是，在系统没有任何提示和校验的情况下，客户的后台管理人员凭借自己多年的使用经验并保持着良好的习惯，总在不会产生问题的时间段进行操作，使得问题恰好没有发生。
这个事情让小A意识到，很多时候系统仅仅是服务于用户工作的工具。即使我们设计了再详密的系统规则，考虑再全的场景，很多一线业务人员的遇到的真实问题，我们还是会遗漏。
为了避免这类情况发生，我们可以考虑：
- 首先，在用户调研阶段，充分了解用户真实的使用习惯和场景，而不应仅仅凭借已有系统的流程而想当然；
- 其次，重视后期上线前商家教育环节和操作指南的撰写。重点强调系统目前无法覆盖的一些场景，或需要商家自己注意和人工配合的案例;
- 最后，和客户着重强调系统上新后，用户流程都有了哪些改变，是否需要商家额外增加流程管理与规范。
【习惯和制度的约束】 有时候会大于 【软件的约束】。这就是为什么大多数公司依旧保留着巡店，业务抽查等必要的监督手段。我们无法只依赖于任何一个系统就满足整个公司的业务所有流转的环节。习惯的力量，我们往往不能忽视！
3.客户的优先级应该“最”重要
小A在经历了几个项目后，遇到了那道经典命题 ——用户和客户的价值“不吻合”。
在和客户讨论某方案的过程中，小A发现，目前的方案虽然满足了 灵活的【系统用户（商家）使用场景】的需求，但某些场景下，要牺牲【终端的服务用户（顾客）】的体验。在交流方案改进点时，客户重申了该次系统改造的三个诉求：
- 整个流程可以跑通，不要阻碍系统用户的操作；
- 不会增加系统的不稳定性和bug；
- 用户不会因为我们系统的原因提ticket，造成总公司额外的工作量
用户体验嘛，其实, 我觉得没那么必要
短短几句，“降本增效”这四个大字，被客户诠释得淋漓尽致。往往这种情况下， B端系统中的用户体验就草草被牺牲掉。但其实换一个角度，只要能满足和强调客户的基本价值点，就可以在有限的框架内发挥。例如该故事中，小A之后的方案便在不损害用户体验的前提下，着重强调客户方更加关心的系统稳定性，和特殊流程出现频率低等方面，成功说服了客户，达到了更加“三赢”的结果。
其实，新手BA经常会遇到这种两难的境地，不妨从以下角度考虑：
- 首先需要从产品愿景、价值定位、当前战略目标等出发衡量，客户口中的优先级是否和产品战略层的价值相符合（详见：“当用户不是客户，需求价值怎么定？”）；
- 其次，不妨翻出来产品/项目规划时，干系人对于价值优先级的定义。当然，在产品发展不同的生命周期，价值优先级会随之改变，需要定时回顾和迭代。
- 最后，很多情况下，客户真正关心的优先级和价值，早已初见端倪。比如强成本导向的客户可能会很关心每个功能的估点，而强体验的用户可能会在初期调研阶段参与度很高。
故事中“用户体验”的价值只是一个例子，往往当我们被戴上了【价值优先级】的“紧箍咒”之后，如何在客户可能“不那么关心”的角落做文章，争取最优解，就看我们BA自己”讨价还价“的真本事了。
4.客户应该“什么都懂”！
对于新手BA来说，很容易陷入被客户需求“牵着鼻子”走的情况，但有时候，客户可能真的不知道自己要什么。大部分场景下，客户对于业务逻辑会较为熟悉，但是对于系统化语言或者数字化实现方案的术语可能存在盲区。当然，偶尔也会遇到对接人是新调来该产品线的PO, 或者是和其他部门协调集成系统时的PO。
那么当遇到PO是“新人“，小A也是新人的情况时, 可能会出现从客户处输入较少，需求确认不清等风险。此时，需要考虑：
- 和客户统一语言。客户可能不熟悉系统语言，或者是使用一些比较过时或非正式描述。所以，在确认需求的过程中，最好能用他听得懂的语言进行讲解，并强调系统和现实中的mapping关系。
- 从真实业务场景出发。客户可能对一线系统操作人员的细节更熟悉，但对系统整体设计的逻辑不清晰。我们可以先尝试从物理世界的操作出发再还原到系统上，便于他更好地理解
- 从宏观到微观。曾经有客户不认同迭代开发的方式，原因是没有功能全景，零散的故事卡确认会议，使得需求看似没有逻辑。由于对系统的整体性理解不够，项目进展和迭代间的功能联系总处于黑盒状态。针对这种情况，我们可以考虑
- 首先，在写故事卡的时候，针对客户不熟悉的一些细节，可以适当展开描述，或者配系统图、流程图，方便其理解；
- 其次，在每次需求确认会开始时，就明确该迭代的需求对应整个用户旅程中的哪个部分（比如，采购商品）和 完成客户/用户的哪些预期目标（采购流程中可以创建订单 和 添加基本商品）；
- 最后，将有完整故事线的卡尽量放在相近的时间点去确认，并提前告知客户主题，方便客户去邀请相关更熟悉业务的干系人一同参会。
总结
期望通过几个小故事，分享一些新手BA在与客户“心理战”的过程中，可能会遇到的情况。其实，归根到底， 充分熟悉和理解项目背景，产品愿景和干系人关系永远是重要的第一步。如果你与小A一样，无法理解客户做的一些决定，遇到无数卡住的瞬间，不如回到最初的起点，也许一切都有了答案。
最后的最后，在拒接“标签化”客户的同时，也不要“标签化”自己，在认清当前不足的前提下，也要敢于质疑，勇敢尝试, 最终才能自信地和客户"say no“。
欢迎大家讨论你曾经给客户打过的那些“标签”吧！
参考文献：https://mp.weixin.qq.com/s/HtlX4wn8Nt8l1O6HXSFbJQ
- 相关阅读 -
有了产品负责人，还需要业务分析师吗？
在一个“去QA化”的项目中，QA能做什么？
点击【阅读原文】可至洞见网站查看原文&加粗字体部分的相关链接。
本文版权属Thoughtworks公司所有，如需转载请在后台留言联系。
