关于产品研发管理 -《培思的力量》

一、前言

之前得益于公司内部也在积极探索如何做产品研发管理，在领导的推荐下看了《培思的力量》这一本书，想结合一下 PACE 谈谈对产品开发管理的一些个人理解。

PACE（Product And Cycle-time Excellence），中文称为“产品及周期优化法”，它是美国 PRTM 公司在上世纪 80 年代中后期提出，当时主要是受到了日本公司实行了“基于准时制（JIT）”方法而取得的竞争优势所迫使美国公司所产出的一套产品开发流程。当然后来 IBM 基于 PACE 的基础上又发展出了 IPD（Integrated Product Development，集成产品开发），以华为为代表的国内企业也从 90 年代末开始引进 IPD。

PACE 所体现的实际上就是关于产品研发的流程框架，它关注的是面向市场的产品管理，并同时把产品管理和技术管理进行整合归一。而这个流程是可以被定义、构架及管理的。回归本源，PACE 更多的是帮追我们及时的响应市场需要，做更多“正确的事”。

二、产品开发是一项投资行为（战略）

任何一家企业的资源都是有限的，这是一个无论你接受与否都存在的一个客观现实。所以在选择项目 A 的同时意味着放弃了项目 B，所以我的理解是任何的产品开发都是一项投资行为，那我们一定要将资源用于最有前途的市场机会和产品组合上，并要在产品开发过程中设置阶段性的投资决策评审点,及时砍掉不再具备投资意义的项目。这样就需要 PACE 里面的管道管理，因为它就是为此而生的。它解决这些问题的办法是给项目优先级的确定和跨项目资源管理提供一种流程框架，并且能将职能部门能力和项目要求协调起来。在当今互联网时代，“大鱼吃小鱼”已经变成了“快鱼吃慢鱼”，大企业不一定打败小企业，但是快企业一定打败慢企业。未来的竞争越来越大，迫使企业必须超越项目级的成功管理，对整个产品分析与开发作为整体进行管理。

管道管理将产品战略与项目管理和职能部门联系起来，这里涉及到战略平衡、管道载量、协调部门间的交接这三种方式。我的理解是：

1、战略平衡

针对战略平衡，应该是高管层要对投资项目的组合管理要根据不同元素来进行平衡，它需要要考虑到专一性和多样性之间的平衡，短期目标和长期目标的平衡，高低风险的平衡。就好像我们自己做项目开发一样，我们在针对业务需求需要给出的解决方案中，既要给出最终的解决方案的同时也要提供能解决短期问题的临时方案，在这当中需要综合考虑不同因素给出一个有效的 tradeoff（决策）。

但是这个 tradeoff 怎么做？为了有效的进行决策管理，从流程层面上说建议参考 CMMI 里面的决策分析与解决方案模型（DAR，Decision Analysis Resolution）。DAR 它是一个结构化的方法，它根据也已建立的准则来评估备选解决方案，并决定用推荐的方案来解决问题。这个目前跟我们在做技术选型的方法是一致的。

- 首先，我们要先识别业务的痛点；

- 接着，我们需要识别可供选择的解决方案；

- 然后，我们需要制定包含业务、开发、架构、运维等多维度评选准则；

- 最后，根据准则打分并选定最终解决方案。

2、管理载量

针对管理载量，这是我们科学管理人力资源的一种方式。在过往的项目中，我们很多的项目都是进行独立审核，而没有进行全盘的交叉审核，根本无法知道整个资源池是否存在超负荷的情况。很多的项目就像书中所提到的，在管理层没有掌握跨项目的所有相关信息，也恰恰是这种情况导致管理层只能采取“零基预算”心态，只要觉得对业务有意义的就马上拍板上马，而非综合考虑企业实际资源情况，从优化资源配置的方式进行项目开发。诚然，整个项目资源可以通过加班等方式进行项目推进，最终也一定会完成目标，但是这不是一种能够持续的方式，因为这种方式的成功是基于团队加长工作时间或者从其他团队临时协调资源来实现的，但是整个过程看到的是基于项目需求的临时性调配，这是一个随机过程而且不一定能每次都能成功被复制。

3、协调部门间的交接

针对协调职能部门之间的交接，PACE 建议我们需要建立这样的一种协同机制。职能部门的管理者应该是站在一个“公共部门”的角度去平衡产品开发需求和其他需求，且管理者在资源预估的时候需要考虑到产品开发、技术开发（即技术债务）、产品辅助活动（如生产故障修复、业务咨询）这几个维度的信息。

三、以产品形态构建跨部门协同（组织）

一个产品的开发流程不仅仅局限在一个部门，而是需要多个部门的协同努力，就正如 IPD 中所强调的组建跨部门团队负责产品开发的决策、规划和实施并依据跨部门流程，通过协同的方式来开展工作确保沟通、协调和决策的高效。

正如书中所说的，成功的项目小组组织的秘诀在于三个要素：有效沟通、协同及决策机制。在传统的职能组织架构中，产品的开发是根据整个流程从上游往下游一环一环的往下传递，这是单向且低效的，且容易造成“各人自扫门前雪”的现象。另外，这种组织还有一种弊端就是它会催生流式审批，没完没了的转来转去。存在就是合理，这样的组织架构没有好坏，因为它是适应当时社会背景的一种架构产物；但是在现在“快鱼吃慢鱼”的时代，我们就要想办法从组织架构层面提升产品研发的速度，获取竞争优势。

根据康威定律，我们需要根据产品形态去组建完整团队，并从项目制转成产品制。但是我的理解是这不是一个“革命”的过程，不是一夜之间城头变幻大王旗，而是应该是“春风化雨”式渐变的一个持续过程。

• 首先，先识别企业中对组织战略有着核心价值的产品并针对产品出具明确的产品定义；
  

• 接着，在现成的职能架构框架下，组件围绕该产品的跨职能团队（即包含产品经理、项目经理、BA、开发、测试、运维等工种），然后团队里面所有人要背负相同的KPI指标用于统一目标与方向，而且这些KPI的设定最好是相辅相成，下层支持上层的。这个跟核心小组模式是一样的。
  

这跟国内很多同业的组织架构转型跟上述所说的是有异曲同工之妙。

第一个阶段主要为了解决业务响应率低和提升IT内部效能的问题，在IT部门会建立BA和技术Leader一起做决定，一个对外一个对内，这个有点类似军队中的营长和政委的关系；

第二个阶段的目标主要孵化IT复合型人才，提升IT和业务融合度，则要求一名具备产品、技术的灵魂组员并融入到业务部门，用于缩短业务与技术的沟通链路；

第三个阶段的目标主要是持续孵化IT复合型人才，同时赋能给IT达成IT引领业务。

综上所述，针对跨部门协同这个命题，我觉得正如 TW 某篇文章所说的本质上不是”如何切（划分团队）“的问题，而是识别出战略性产品，为这些产品配齐从需求到价值角度端到端的能力，构成真正的跨职能产品团队，这个才是真正的王道。

四、技术管理（产品化）

文中的技术管理主要分为技术开发以及技术转化。技术开发与产品开发有很大程度上的不同，相比产品开发，技术开发的不可预测性更大，过多的流程框架会抑制团队的创造力，所以 PACE 认为应该把技术开发的管理与产品开发的管理分离开来。

在技术开发过程中，技术方案的不断成熟是通过多个阶段的技术评审（TR，Technical Review）而不断的把技术产生的技术风险降低的，同时让团队对技术的理解和把握得到提高。然后在达到一个平衡后，在某次的技术评审后就会启动某一产品开发项目，这样就开启了技术转化的阶段。PACE 也说到，这需要有一个技术过渡小组专门负责技术转化的协调和流程。

这对我们从项目开发模式转向产品开发模块有着一个重要的启示。在 IPD 里面也有提到过，产品的开发周期必须是很多短的，为了保证较短的开发周期（最好像搭乐高积木一样，基础“积木”已经有了，那剩下只是按照业务需求进行不断的优化组合），IPD 是提倡将这些技术风险在技术转化前先解决掉。就好像现在做技术/产品输出一样，甲方关心的不外乎两个事情：1）快以便抢占市场，2）最佳实践复制以便赋能。

那怎么能达成以上两个目标呢？我对这个思想的理解是，我们要做的就是中台化建设（实际上这也跟 IPD 里面强调的 CBB【Common Building Block，公共构建模块】一样的），因为中台化的道路就是产品化的道路。为什么？因为中台化建设的作用有三：1）最大化复用、2）沉淀企业核心能力支持业务创新、3）反向推动业务侧往跨业务方向演进。

但是怎么建设？我还是坚持我之前所说的。

1、阶段

在这里我对于中台的理解是它需要分为三个阶段进行落地：

1）基础架构阶段，这一阶段主要先去识别一系列的公共组件，然后通过统一集群的方式对所有应用系统开放（如配置中心、服务发现中心等）；

2）组件化阶段，这一阶段主要在于进一步打通各团队的合作模式，通过各个团队的具体项目作为切入点，建设或抽象出可复用的业务模块，并开放给各团队进行共享使用；形成你中有我，我中有你的局面与习惯；

3）中台化阶段，这一阶段主要遵循康威定律，建立起独立研发团队，专注于通过打通上述一系列可复用模块的数据流而建设起中台，挖掘出中台的价值 。

2、方法

接着，我们要想如何推进中台建设。我的看法是，银行的中台沉降过程因为跟互联网电商的业务中台沉降点不一样，可能会更多的是面向功能进行沉降，在流程与能力解耦的原则下，将不同流程分离成相应业务聚合层，同时剥离可通用的能力（这里称“原子服务”）作为服务复用层。结合中台沉降的大方向，我认为整个互联网条线的系统应该参考以下的方向进行切分：

1）从横向切分，主要分为四个部分：渠道前端层、服务聚合层、服务复用层、外部支撑层。

2）从纵向切分，根据不同的业务流程或条线切分为不同的业务聚合层。

五、后语

从 PACE 方法论的核心思想可以看出来（起码我觉得），它不单单是一套产品研发方法那么简单，它里面涉及到比较核心的几个元素：战略、决策、组织、产品，然后通过一套流程把这几个元素有机绑定起来，如果能在人才体系方面再丰富一点，俨然就是一套企业的管理办法。