你真的懂B端大客户吗？来试试这8个棘手的需求问题中薪|高薪|航天|机器人|技术

编辑导语：在与B端客户交流的过程中，有很多需要注意的问题，在产品的不同风格阶段，客户都会提出很多需求，而对于客户的需求产品经理需要有判断以及解决的能力；本文作者分享了关于B端大客户的需求问题的解释，我们一起来看一下。

文章插图
2021年换工作，要做一下阶段性知识总结，另外跟Jira社区马畅老师聊到C端产品经理在B端的不适应，由此想到B端大客户交付中棘手的需求问题。
照例，先说下视角基础，笔者有10年软件行业经验，近7年交付过多个大客户项目，做过各种不同的项目，遇到过各种类型的客户；视角局限性在于，所有大客户均为运营商。
本文主要讨论做需求时的棘手问题，在职责上与项目经理有些交集；讨论的主题包括：需求变更、交付不一致、需求收集、需求池管理、高管需求应对等，每个主题先分析原因，再给出解决思路。
注：文中“客户”通常代指甲方或公司内部统一接收业务方需求的接口人。
01 客户是变更狂魔客户需求经常变更是个头痛的问题，意味着我们没能解决客户的问题，同时浪费了时间，也会让团队产生挫败感而影响士气。
客户频繁变更可能的原因有4个：需求与产品间有鸿沟、客户非原始需求提出人、客户本身没想清楚，客户业务频繁变化。

需求与产品间有鸿沟主要是客户描述的需求和他真实想要的东西不一致，直到把产品给他用时，他才知道这是不是他要的；
客户非原始需求提出人是客户接到需求后，经二次理解加工转述给我们，即使我们给了他想要的，一旦原始需求人说不对，他分分钟甩锅给你背；
客户本身没想清楚是客户直接把解决方案告诉我们，但他本身可能并没有找到或者遗漏了真正的问题，这种功能即使交付了也解决不了问题。
客户业务频繁变化是个伪命题，更多是客户对业务的理解频繁变化，这种场景并不常见。

我们分3种场景来解决变更，分别是开发前、开发中和开发后。
1）开发前
开发前是需求分析阶段，这里做好了可以解决80%的需求变更，解决方法是“多确认、多验证”。

首先，我们一定要找到原始需求提出人，通过反复提问、多做假设、多做求证的方式，挖掘到需求“痛”的场景（5W1H）；
其次，借助纸、Xmind、Visio等工具把需求物化下来，让需求方确认文字是否能表达他的想法；
再次，如果需求较大，还需要设计原型图、需求说明书，让需求方提前看到、摸到实实在在的功能和操作，来验证是否满足他的期望；
最后，我们作为B端产品经理，应该比客户想的更多，提前把功能交付后可能的异常、引发的问题等与客户沟通。

2）开发中
开发中是已经进入开发过程中，客户突然要求改方案，这种要么确实是突然业务变化了（如高管有新的指示），要么就是客户描述需求时漏掉了关键信息。
在这情况下更多是评估变更影响，改动量大小是否影响本次交付，是否将未完成的先简化交付，抑或需求延迟至下期交付等。
采用敏捷方法中“双周迭代”可以弱化开发过程中变更产生的影响，小步快跑、迭代试错。
3）开发后
开发后是开发上线后，每隔段时间客户就要优化功能。
如果这种需求变更是无法避免的，解决方法是总结历史所有变更，尝试对功能进行抽象，看是否可以将功能设计成可配置的，抑或是否需要借用中台的思想封装出一个新产品；比如，我们在做各类流程时，发现列表页、详情页、甚至流程本身经常变化，消耗了大量开发团队的时间，后来，我们做了“流程中台”，此类变更迎刃而解。
02 客户翻脸不认账明明跟客户确认清楚需求了，开发交付后客户翻脸不认账，这种场景同样既没帮到客户，又浪费团队的时间。
客户不认账的原因可能有2个：需求分析阶段不负责任、参与度低，客户承受了不便明说的压力。
解决这个问题分2种情况：
1）客户不负责
这种首先把上文谈的“开发前确认”工作做好；其次，养成邮件确认的习惯，把确认过程留痕，留下物证；再次，大型需求召开多人评审会议，并在会议结束后将会议纪要抄送所有人，留下人证。
2）客户承受了不能明说的压力
比如高管插手、本身无决策权等，这种情况首先要了解客户的组织关系和他的处境，跟他以及其他人建立一定的私人关系，通过非正式沟通渠道尽可能多的了解情况，理解客户面对的压力，帮他一起应对，适当加班修正，终有回报。