最近处理一个产品管理的事情，作为顾问我大概用三周时间大致梳理了一下现在的情况。原打算是做一个软件系统的产品化，但是经过梳理之后我发现问题可能比想象中要复杂的多。

先说一下现状吧。现在团队大部分的业务是基于一个多年的大客户的多个项目，人员大概有将近 100人，项目也很多。但是经常发现各个项目组都加班开发，人员严重不足，这造成了客户大量的投诉。我通过参与的一两个项目的需求评审发现几个问题：

需求来源于产品经理与对客户的调研，这种调研通常是几次谈话后的总结。
需求的评审是通过召开会议，产品经理按照事先画好的原型，跟研发人员讨论需求。
研发人员通常同时在多个项目上，最少有 2 个项目在身。
然后是研发人手不足，包括 UI、测试、实施等人手都不足。
最后需要产品经理跟部门的最高领导要人。
从上面的简单现状描述，其实反映了几个问题：

  1. 缺少项目立项流程：一个项目是否要做，缺少立项流程。在立项时不仅仅是有人就可以做，还要有其他的资源安排。因此要高层决策，因为这涉及到跨部门和跨团队的资源协调。
  2. 缺少需求评审流程：现在的评审只有原型，没有用户角色划分、用例流程、需求文档，最后这些需求都在产品经理的脑子里，如果研发人员有不清楚的地方，要么向产品经理再次确认，要么就想当然的开发了。最后是否符合用户的需求完全靠运气。因此，需求内部评审完之后，要有一个客户的需求确认。
  3. 缺少项目过程监督：没有定期的项目过程汇报，需求评审会开了之后，就开始协调开发人员，然后就开干了，最后大家之盯着 deadline 交付，中间的过程没有人监督，只看结果不重视过程。又由于之前没有立项和需求确认流程，最后客户的投诉大概率是避免不了的。

基于上面的情况，我认为要做以下的改进：

  1. 成立产品项目管理委员会：由部门主管、产品总监、研发总监和项目经理参加。负责项目的立项审批，定期的项目过程监控。
  2. 明确项目管理制度：对于客户定制项目，每个项目都有明确的项目经理，采用项目经理负责制。这里还有两种方式，如果是强矩阵模式，那么由项目经理对人员进行考核；如果是弱矩阵模式，则由资源部门的经理对人员考核，资源部门与项目经理签订项目外包合同，定期向项目经理汇报。
  3. 明确项目分类，不同项目类型处理方式不同：要有产研项目、实施项目的区分。产研项目是公司的产品平台项目，有明确的产品基线，按照产品基线进行开发，由产品经理负责；实施项目是基于产品化平台进行客户定制，由项目经理负责。
  4. 任命产品总监和研发总监：产品总监负责管理产品团队，研发总监负责管理技术团队。后续的所有产研项目的人员安排由这两个人负责。
  5. 建立例会制度：PMO 有定期的例会，对所有的产研项目和实施项目的过程进行监控。单独的产研项目，成立专门的内部事业部，每周定期开会，反馈情况。要监控的内容包括但不限于：计划执行情况、项目风险情况、项目成本核算、客户回款情况等。

产品化绝对不是一些文档和套路，一定是按照产品化的管理来做的，简单说，先改变管理方式，再根据管理方式的改变变更具体的动作。