于C端产品不同，B端的需求和流程都有很大的差别。这篇文章，作者帮我们梳理了B端产品从需求到产品的几个常见问题，希望能对大家有所帮助。

B端产品往往是项目需求推动的，一般首先是定制化项目，在交付第一个客户之后或正在交付中，会以此项目案例为参考，去支持商务接更多同类项目。

当项目慢慢变多时，很多类似的功能可以复用，这个时候就需要用到产品和技术架构了，需要将可复用的部分很好的解耦开。

B端项目往往是复杂多样的，一般以某个项目为基础而衍生的其它项目也会签下来，如果项目比较大，一般企业会选择将不属于公司核心业务的部分外包找供应商做，但如果在评估完商业价值后，如果觉得这部分有想象空间，也会选择自己做。

一、B端产品的四阶段

B端产品开发落地可分为4大阶段：商机调研阶段、规划设计阶段、开发测试阶段、验收维护阶段。B端产品比较适合混合式开发，既有预测（也称瀑布）又有敏捷。

一般B端产品做项目的时候都需要签署技术协议，这个时候要约定交付的内容，也就是这个技术协议的内容。技术协议的详细程度影响了混合式开发中预测和敏捷所占的比例。

二、B端产品的技术协议

一方面，如果技术协议非常详细，那么就需要长周期的调研及设计，对于交付速度往往很难满足，但详细的技术协议对于项目验收却是非常友好的，一般情况，技术协议越详细，交付验收也会相对顺利，因为可以避免大部分扯皮。

另一方面，客户往往不清楚自己要什么，很难在项目开始的时候就定清楚，技术协议只能比较概括得写，快速签订也可以加速交付，项目可以快速开启，调研、设计、开发一起开展，采用增量式交付，客户采购产品都是希望可以快速交付的，有交付周期，交付周期越短的供应商将有更大优势。

三、B端从的项目启动和需求评审

项目经理拿到签署后的技术协议，组织项目团队开项目启动会议，会议后就可以正式开始干了，产品经理出详细的需求文档并拉着相关同事开评审会议，一般会拉着项目经理、研发和测试一起，项目经理代表客户方做需求把关，研发同事需要就设计方案做落地可行性的判断，测试同事需要从质量和验收角度来给出意见。

评审会议一般会耗时较久，产品经理需要切分需求，提前跟相关同事分别沟通需求，以免大家在评审会上才第一次看见需求，发现大的问题导致评审会议效率低下。往往评审会前，产品经理已经挨个聊过需求方案了，会规避掉大的逻辑漏洞。

四、B端产品的开发测试过程

产品同事根据评审会议调整需求文档，研发同事拿到评审后的需求文档，编写开发实现方案、各模块之间的接口对接方案，这个时候会从开发的角度进一步倒推需求的合理性；同步，测试同事编写测试用例，也会从另一个维度发现需求的漏洞。

产品、研发、测试，三方从三个角度完善整体设计方案，然后开干。

开发过程需要注意的是，整体开发节奏由产品经理把控，螺旋式迭代、增量式交付，目的是整个团队的工作效率最大化。具体怎么做才能做大化，不同的团队有不同的合作方式，需要大家一起讨论出一个最优合作方案。

五、B端产品的客户会签

在需求文档确定后，有一个非常重要的事情，那就是找客户确认是他要的东西，邮件确认最佳。客户确认后开干的风险就比较低了，万一客户说这不是我要的，那么可以重新调整需求，避免无效开发。

客户确认后，在正式开发过程中，一旦客户反悔要改需求，或者团队发现需求有问题要调整，这个时候就要启动变更流程，一切更改都要书面记录，邮件记录最佳。具体变更规则可以根据团队不同做调整，目的是大家都清楚并同意此变更，有迹可循。

六、B端产品的验收和维护

最终开发完成，得到一个测试通过的版本，进场交付客户验收。客户验收时，两方面将发挥巨大作用，一方面，是平时公司与客户的商务关系是否优良，另一方面，是项目开展过程中客户的参与度。这两个方面，在项目全过程中都需要维护。

验收通过后，就开开心心收尾款啦。然后启动后期维护，售后对接人需要了解项目情况，产品经理需要长期且定期收集客户反馈，研发团队持续的版本debug迭代，都是维护阶段要做的事情。

七、B端产品的战略合作及长期发展

验收和维护做到客户满意，那么此时是商务去探寻客户是否有更多商机的好时候。一旦首次合作愉快，双方公司就建立了信任关系，就可以考虑是否有战略合作机会，大家一起搞钱搞项目，happy ending。