To B 实例：从定制开发到通用性产品

  本文从真实的业务场景出发，谈谈如何完成从定制开发到通用性产品方案的确定。

  笔者在《To B 行业的 MVP：定制开发》一文中粗略地介绍了产品经理怎么样处理客户的定制开发需求。也就是在处理客户提出的需求时，理清以下六个关键性问题：

  本文结合以上六个问题，从真实的业务场景出发，谈谈如何完成从定制开发到通用性产品方案的确定。

  在产品圈内有一个老生常谈的话题——“怎么来识别客户的真实需求”，这样的一个问题最常见的回答思路是：知道客户是谁，他们要做什么事，接着才是按照每个用户标签、业务场景等进行具体分析。

  做需求分析时，识别客户真实需求是我们的首要目的，为实现这个目的，要解决以上四个问题；在处理问题的过程中，会收集到很多信息；在这一些信息中，产品经理不仅仅需要提取出真实需求，还要得出跟市场和公司战略相关的结论。

  这是小白产品经理与资深产品经理最大的区别，资深产品经理能够时刻保持对市场和公司发展的关注，在接到需求的那一刻，能够马上想到自己要验证什么样的问题，所以能快速回答这个需求能不能做，面临的难点是什么。

  AD 公司购买了我方的一款财务软件，客户在业务交流中反映：影响 AD 公司收支平衡的最大不确定因素是合同账款统计的滞后性；由于集团无法及时收到子公司的报表汇总，导致报表合并与汇算工作滞后，不能即时反映集团财务情况；因此希望实现收款类合同账款的快速统计与汇总功能。

  从这些沟通中我们得知，AD 公司项目的需求方主要是财务专员，他们只关注财务问题，尤其希望能快速收到下级部门的数据统计报表。但我们大家都知道，最快速的方法不是让“报表”与“报表”之间形成联动，而是把触角伸到合同的具体数据，让财务“管”到业务上（业内称为“业财融合”）。

  这就涉及到了商务方面的事情：AD 公司的业务部门并没有提出合同管理需求，并且该项目在 AD 公司的责任方是财务部，占用的是财务部的预算；我方产品部无法与 AD 公司的业务部门取得联系。

  当公司决定为客户进行定制开发后，就从另一方面代表着这项“小型产品”即将成为公司产品线上的一个成员。怎么样才可以提高投入产出比，让这个“成员”更好地发挥自己的价值呢？

  我们需要在设计之初就考虑到这款产品一生的命运，也就是上文说的：要不要把新功能规划到产品的下一代升级中，新功能能否独立成一个单元模块，新功能能否独立成一条产品线等等。

  在规划产品生命线时，最容易陷入的误区就是一个劲儿地往里塞功能，相信很多产品都有体会。每个人的想法都很不错，也确实会有相应的目标客户，但一不小心就会把产品设计成一个四不像，甚至是根本没办法做。

  既然做加法容易出错，那就做减法。在考虑到公司整体的产品布局和市场需求后，要给产品限定一个范围；比如说，坚决不做某某行业的此类业务，某项功能实现困难，短期内坚决不考虑等等（开个玩笑，只要客户粑粑钱给到位什么都做）。

  通过与 AD 公司需求方的讨论，我们列出了在定制开发中要实现的功能清单，这里用 UML 用例图来表述：

  通过这个用例图不难发现，其实这个定制开发对完整的合同管理软件来说，相对是比较简单的（产品设计角度），连常用控制功能都没有，只需要挂一条审批流程即可，剩下的关键部分就是统计分析。

  因为客户的需求就这么简单，“我只想知道截至目前还有多少合同没有收款，应收、欠收等数据的比例是怎样的”，“我想通过合同台账，直接生成财务报表”。

  理清客户的需求并进行企业内部汇报后，BOSS决定借助这次定制开发的机会，做一款通用型合同管理软件，要能够覆盖合同管理的整个生命周期。于是产品部开会讨论，做出SWOT分析：

  随后，经过一系列的市场调查与研究、竞品分析，我方产品部与开发部讨论后做出以下决定：

  这时还要再考虑最后一种可能性：你家开发要升级原来的技术方案吗？前后端框架要更换吗？市场部门有没什么特别的条件（比如在线申请试用）？

  之所以提出这样一些问题，是因为现在 SaaS 真的太火了，传统软件企业想涉足，确实有可能要更换一些技术方案。