2021年要换工作了，需要对自己的知识进行总结。另外，和Jira社区的马畅老师聊了一下，发现C端产品经理在B端工作中有些不适应，于是想到了B端大客户交付中的一些难题。首先，让我们先了解一下基础知识。我有10年的软件行业经验，近7年参与了多个大客户项目的交付，经历过各种不同类型的客户。需要注意的是，所有的大客户都是运营商。本文主要讨论在需求阶段遇到的难题，这与项目经理的职责有些交集。讨论的主题包括需求变更、交付不一致、需求收集、需求池管理、高管需求应对等。对于每个主题，我们首先分析原因，然后提出解决思路。需要注意的是，文中的“客户”通常指的是甲方或公司内部统一接收业务方需求的接口人。

客户需求经常变更

客户需求频繁变更是一个令人头痛的问题，意味着我们没有解决客户的问题，同时也浪费了时间，并可能影响团队的士气。客户需求频繁变更的原因有以下四个方面：

1. 需求与产品之间存在沟通障碍，客户描述的需求与他真正想要的东西不一致，直到使用产品后，才会意识到这不是他想要的。

2. 客户不是原始需求提出人，他是将需求经过二次理解后转述给我们，即使我们提供了他要的东西，一旦原始需求提出人认为不对，他会把责任推给我们。

3. 客户本身没有想清楚，他直接告诉我们解决方案，但可能没有找到或者遗漏了真正的问题。即使交付了这样的功能，也无法解决问题。

4. 客户业务频繁变化，这种情况并不常见，更多是客户对业务的理解频繁变化。我们可以根据不同的场景来解决需求变更的问题，包括开发前、开发中和开发后。

5. 开发前：在需求分析阶段，我们可以通过多次确认和验证来解决80%的需求变更问题。

6. 首先，我们需要找到原始需求提出人，通过反复提问、假设和求证的方式，挖掘需求的真正场景。

7. 其次，使用纸、Xmind、Visio等工具将需求具体化，让需求方确认文字是否能准确表达他们的想法。

8. 还可以设计原型图和需求说明书，让需求方提前看到和操作实际功能，以验证是否满足他们的期望。

9. 最后，作为B端产品经理，我们应该比客户更加深入思考，提前与客户沟通可能出现的异常和问题。

10. 开发中：在开发过程中，如果客户突然要求改变方案，我们需要评估变更的影响，包括改动量的大小是否影响本次交付，是否可以先简化交付未完成的部分，或者将需求延迟至下一次交付。采用敏捷方法中的双周迭代可以减轻开发过程中变更带来的影响，通过小步快跑、迭代试错的方式来处理。

11. 开发后：在产品开发上线后，客户可能会不断提出优化功能的需求。如果这种需求变更无法避免，我们可以总结历史上的所有变更，尝试将功能设计成可配置的，或者借用中台思想封装成一个新产品。例如，在处理各类流程时，我们发现列表页、详情页甚至流程本身经常变化，耗费了大量开发团队的时间，后来我们做了一个“流程中台”，解决了这类变更问题。

客户不认账

明明与客户确认清楚了需求，但在开发交付后，客户却不承认。这种情况既没有帮助客户，也浪费了团队的时间。客户不认账的原因可能有两个方面：

1. 需求分析阶段不负责任，参与度低。这种情况下，我们需要做好前期的需求确认工作，确保有物证证明确认过程。

2. 养成邮件确认的习惯，将确认过程留下记录。

3. 对于大型需求，可以召开多人评审会议，并在会议结束后将会议纪要抄送给所有人，留下人证。

4. 客户承受了不能明说的压力，比如高管插手、本身无决策权等。针对这种情况，我们需要了解客户的组织关系和处境，与他和其他人建立一定的私人关系，通过非正式的沟通渠道尽可能了解情况，理解客户面临的压力，帮助他应对，适当加班修正。另外，可以尝试将关键决策人纳入需求确认过程，比如将需求确认邮件抄送给关键领导知会。

客户需求不明确

客户缺乏明确的需求并不意味着给了B端产品经理自由发挥的空间。如果你经历过出了数十个版本，结果客户都不认可的痛苦，就能理解这种情况了。客户需求不明确的原因可能有两个方面：

1. 真的没有想法，可能是因为懒得思考，也可能是不了解业务。

2. 不敢说出自己的想法，可能是因为不愿意承担决策的责任。

针对这个问题，我们可以采用以下四个技巧：

1. 对接关键人物：找到能明确需求的关键决策人，比如客户的上级领导、关键业务需求方等。这种方法最直接有效，但有时客户并不喜欢这种方法，需要产品经理和项目经理根据情况来把握尺度。

2. 全面收集资料：收集与需求相关的所有资料，包括Word文档、汇报PPT、内部邮件等，尝试通过内部材料分析可能的需求。

借鉴友商及互联网思路分析友商或互联网相关产品功能模块，根据需求相似度确认思路。

低成本、频繁确认如果对接人确实无法明确需求，此时应该以最低成本频繁确认，比如口头确认、Xmind梳理核心方向等。

客户太有想法（强给方案）

客户直接给解决方案看似为产品经理省事了，但如果客户本身缺乏对业务的理解深度或不懂产品设计，会出现上线后变更率高、功能复杂等问题，对用户、客户和开发团队都不利。

客户强给方案的原因可能有2个：客户本身控制欲强、解决方案源于更高层。

解决这个问题有4个技巧：

1. 倾听多问问题多倾听，搞清楚客户解决方案背后的思考。

2. 用数据和用户说话把平台的数据和用户意见领袖的反馈呈现给客户，尝试说服客户转变。

3. 用竞品说话拿有相似需求竞品的功能设计，尝试引导客户向我们期望的方向转变。

4. 适当妥协按客户的想法做，但争取少做、分阶段做，根据数据和用户反馈，引导客户做出转变。

需求太多

需求太多是个很可怕的事，它意味着需求等待引发的业务方抱怨、频繁加班引发的团队怨气、经常被投诉引发的高管负面印象等；团队明明干了更多的活，却收获了更多的差评。

需求太多的原因可能有4个：对接的业务线过多、低价值需求过多、产品缺乏边界、团队研发效能低。

解决这个问题有4种技巧：

1. 建池建立需求池和业务资源配额池，把团队资源、当前需求积压队列、各业务方消耗的资源量等数据公开、透明的展示出来，把资源争夺推给各业务方内部、不同业务方之间。

2. 边界明确团队支撑的业务线和产品边界，明确拒绝不属于产品范围的需求。

3. 拉援跟客户打好关系，让客户看到团队辛苦程度，帮忙拒绝一部分低价值需求。

4. 交付改善包括3方面：

   • 简化，复杂需求先交付核心功能；

   • 复用，抽象常见功能为可复用的能力；

   • 提效，通过DevOps等工具提升交付效率。

需求太少

需求太少同样很可怕，它意味着我们的项目和团队不再被需要，从长远看可能会遭遇生存危机；需求太少的原因可能有2个：用户有需求但没反馈渠道、业务稳定用户真没需求了。

解决这个问题有2种技巧：

1. 建通道、打关系建立便捷的需求反馈渠道，可以让用户直接反馈工作中实际需求；跟用户意见领袖打好关系，让他们在一有需求时能直接联系到我们。

2. 造需求首先要明确，B端造需求是件不道德的事，我们不能臆想需求；但有2种方法可以在缺需求时创造需求，一是产品使用数据，通过数据分析发现问题点并跟用户进行确认；二是通过新技术、竞品等借鉴式创新，发现改进点并跟用户进行确认。离开了用户确认，我们就走到了“伪需求”的路上。

考验灵魂的高管需求

高管需求是把双刃剑，做好、做坏的影响都很大。高管需求主要有2个难点：如何理解高管需求、如何与高管沟通需求；高管需求通常描述极简单、抽象、空洞、难落地；理解高管需求还是要落在沟通上，与好相处的高管沟通相对容易，所以，我们从3个角度聊聊与脾气不好、“官威重”的高管如何沟通。

1. 调整心态，保持平常心首先，我们要认识到很多高管在某些方面确实能力出众，但同时，他们也存在认知的局限性，可敬仰，但无需神化。其次，要理解在有些环境中，高管的无力感在于想法不能落地执行；此时，官威是一种简单粗暴的执行力，很无奈、很悲哀，脾气差、有官威的领导容易争取到更多资源和下属的执行力，以对比其他高管形成政治竞争力，应对他们，我们只需表现出自身的执行力即可。最后，有些高管拿脾气、diss下属当树立权威的手段，更有甚者，只顾自己业绩不顾下属死活，同时如果他们缺乏深刻见解；那这类人不值得追随（又累又没成绩），能远离就远离，远离不了就自带“情绪过滤器”，忽视他们的情绪，做好自己能做的事即可。

2. 做事精细，少即是多首先，多想少做，做的功能越多，越容易被挑刺，不如只做核心的功能，也给高管一个展示他思考全面的机会。其次，凡做的功能必须要思考清晰、细致，用专业度镇压高管，此时，通过高保真、设计原则、细节等清晰的把想法表达出来。

3. 思考、表达重逻辑首先，表达简洁有逻辑，比如结论先行、主次分明、因果清晰等，具体可读《金字塔原理》。其次，软硬结合，面对自负的高管，适当的认同，不重要的点不纠正解释，核心理解偏差该硬刚就硬刚。

客户工作敷衍or组织内斗

客户工作敷衍或客户组织内斗是一个敏感的话题，当存在这种场景，挖掘需求、确认需求、对需求达成一致等都很难。应对这种场景，笔者暂时没有好办法，但提供2种应对思路：

1. 少即是多在这种场景下做出成绩很难，反而做多了被挑刺的概率更大，不如做少、做精。

2. 谋与不谋可以尝试接近高管、贴近业务方等收集高价值的需求做，甚至尝试谋求新的业务机会；但不应该尝试将客户接口人替换掉，更换其他客户接口人，除非足够了解组织的政治、有足够的政治影响力。