在培思中，结构化的产品开发流程是指相互关联的工作要有一个框架结构，并要有一定的原则来组织归类。比如，在一个自上而下的层次结构当中，上层结构简单一些，越到下层越复杂。每项工作都被明确规定，所有与产品开发相关的人员都能清楚地找到从事的工作内容及其与他人的对接关系。

图3-7　结构化流程的范围

如图3-7所示，在对新产品进行结构化开发以及对开发流程进行定义的时候，容易出现两个极端。一端是，如果没有结构化，开发工作容易失控。开发人员不知道如何相互衔接，高管则忙于 “救火”。另一端是，过度结构化导致流程文档冗杂，官僚习气严重，效率大大降低。而培思提倡的结构化是在不受任何约束的“无结构化”和事无巨细的“过度结构化”中间寻求一种适当的平衡。一方面，产品开发过程需要具备可重复可衡量的流程；另一方面，流程规范也需要对新思想新方法采取灵活开放的态度，合理的结构层次划分可以平衡好两个方面的关系。

基于培思理念，结构化产品开发是一种具有层次性的流程，上面一个层级的流程是下面一个层级流程的总结，而下面一层流程则是对上面一层流程的展开。这种结构化的层级与业界流程管理的层级是相似相通的。

如第二章图2-4所示，结构化开发流程分为5个层次：价值链、步骤、任务、活动和操作。一般来说，第一层价值链分为3 ～ 6个阶段，第二层将价值链展开为15 ～ 20个步骤，第三层将步骤展开为200 ～ 500个任务，第四层则将活动再展开为1000+个活动，第五层对活动进行操作层面的展开，为IT系统开发提供基础。

价值链是整个结构化流程的最高层级，即一级流程，通常体现为产品全生命周期的阶段划分。

二级流程即步骤，是最重要的一级。为了让不同职能的人员对接不同研发方向的关键节点，一张图中需要清楚地总览一个产品开发所需的所有步骤和先后顺序安排。这样也能更可靠地估算新产品的开发周期。一二级流程共同构成流程蓝图，支持公司战略和业务目标实现。

任务是第三级流程，是对二级流程中每一个步骤的展开，聚焦于步骤的落实和执行。它定义了完成一个步骤不同职能部门需要做的事情，而且列出了先后次序，更有效地指导业务落地。

活动是第四级流程，将任务分解为不同岗位的职责，将流程要求落实到具体的岗位。

操作则是第五级流程，将活动进一步分解为连串操作，通常结合IT系统的界面进行讲解及展开。

实战案例：建立合理的结构化流程

一家智能硬件公司在引入培思之前只有各个职能部门自己制定的研发流程，职能之间存在多处断节。在他们引入培思的过程中，公司开始按照跨职能流程要求，重新梳理研发流程。(www.daowen.com)

各个部门精心选择了部门代表，他们聚集在一起，建立了一个研发流程设计小组，共同讨论以制定跨职能的研发流程。他们先确定了一二级流程蓝图，然后开始讨论流程蓝图中的步骤应该如何进一步展开为三级流程--活动，我们称之为细节流程设计。

在这个过程中，我们有一个有趣的发现：如果一项活动只涉及单独的一个部门，就非常容易获得跨职能设计小组的认可。但一旦涉及多个部门的协作，这个活动到底要描述得多细，要不要再拆分成几个小活动，部门之间总是难以达成一致意见。

在一次细节流程的设计研讨会议中，负责关键部件和主板的两个职能代表开始了激烈争吵，争吵的内容竟然是关于一封邮件到底由谁来发。在过往的研发经验中，有一类bug的出现，可能与两个职能都有关系，即多因一果，两个职能都有可能发现出了错，但谁会先发现却不是每次都一样的。旁观者很明白，既然谁都有可能发现bug，那么让先发现的人来通知是最有效率的方法。但争执双方却坚持要在流程中标明这个动作到底由谁来负责，其中一人甚至说道：“如果我发现了这个bug，要撰写邮件至少需要十几分钟的时间。这个时间不该我们来花。”

这样的争吵看起来有些无理取闹，但这却是我们在辅导公司设计研发流程中经常会发生的。大家会把日常部门间沟通不畅、互相推诿的怨气带到新流程的设定中，希望通过新流程的制定，把所有事情的边界都规范得一清二楚。

但事实上，这样的做法并不可行。一旦把所有事情都通过流程做出规范并极度细化，流程反而变成了一本厚厚的辞典，因为太过繁琐反而没有人去执行。执行流程的人也不再是拥有创造力的个体，反而像机器人一样被禁锢手脚，丧失了自主思考能力，也没有了创新活力。除此之外，我们也无法预见在产品开发中可能发生的所有情况，因为产品开发虽然有规律，但绝不是千篇一律。

制定结构化流程要做的就是把好的规律固化下来，但保留不同产品、不同项目间的灵活度。按照流程级别，若无需重新开发一套IT系统，一般细化到三级或者四级就已经足够指导产品开发了。

这样的流程能够通过列出完成关键步骤的任务流，让执行人员可以在一张纸上明确知道自己所负责部分的先后顺序，以及与其他人合作的关系。流程并不刻板地限制操作细节，而是通过制定开发过程中的指导原则，有效传递产品研发经验，帮助执行的人员能够运用好的经验，又能按照原则指引找到更好的开发方案。

如果确实有一些细节需要提醒执行者注意，也不需要一味通过流程来做规范，而可以通过结合模板和工具的使用，达到更好的效果。比如，飞行员每次在飞机起飞前，都会根据检查清单（checklist）仔细核对，避免遗漏。这就是一种有效的细节管理工具，也是对结构化流程很好的补充。

那么怎么解决上述的谁来发邮件的问题呢？不是通过无止境的细化流程，而是将单职能的思维转变为跨职能的合作思维，谁先发现问题，谁来发起沟通，最有效率。

这也说明，培思是一个含团队、决策、流程以及其把背后先进的管理理念和文化转变为一体的完整体系。如果公司在变革过程中，不能同时推动多维度的改变，只从一个维度切入，那么很可能会导致在一个维度上用力过度。如果谁来发邮件这种操作上的小事也需要写入流程，这种不合作、呆板被动的做法，反而会通过流程被制度化、合理化了。