第一，建立端到端的流程。

产品开发的过程一般都很长，包括立项、概要设计、详细设计、制样、测试验证、小批量生产、量产等多个阶段，其中每个阶段包括的活动数量也很多。同时，这个过程也会卷入众多的部门。这种情况下，以端到端的流程作为主轴，把所有部门/角色在不同阶段的众多活动连接起来，形成清晰的流程路径是非常必要的。如果不能打通产品开发的全流程，就意味着一个庞大的系统工程没有集成“图纸”，从而无法保障集成效率和质量。

研发流程有两个明显的特征，一个是流程分支多，一个是支撑性的流程多。所以，其端到端的流程并不是简单的“一根刺”形状，其中众多的有闭环的分支流程，使它看起来更接近于有主轴的网状结构。而支撑性流程是可被产品开发主流程调用的流程（甚至有不在研发领域的其他流程），它们与产品开发主流程的接口关系也是端到端流程的重要构成部分。由此我们看出，端到端流程建设的实质是一种“序化”，是把一个庞大体系的各种资源、各种要素、各种活动进行“序化”。“序化”的体系才可以被整体掌控。

第二，跨部门的组织。

当产品相对简单时，一般以直线式组织配合开发流程，就能够满足支持产品开发的需求；当产品稍微复杂了，则需要建立轻量矩阵化的项目团队；而在产品很复杂的情况下，就需要建立重量矩阵化的产品开发团队了。

任何企业都会存在一定的“部门墙”。对于规模较大、牵涉部门很多的复杂产品开发而讲，通过更清晰的流程建设、绩效管理等方式，一定程度上可以削减“部门墙”的厚度，但始终还是有干扰。建立跨部门的重量级产品开发团队，是驾驭多部门之间的多方博弈的一种比较现实的选择。通过这种改变博弈形态的方式，来保证具体产品开发项目在资源获取、跨部门决策、例外处理等方面的效率。业界主流把这种重量级产品开发团队称呼为PDT（Product Development Team）。

PDT作为一个跨部门的项目团队，不仅包括开发工程师，如硬件开发员、软件开发员、结构开发员、ID开发员、测试人员等角色，还包括相关各部门的代表，比如采购代表、制造代表、销售代表、品质代表、工程代表、财务代表等。PDT的负责人是一个重量级项目经理，即拥有对重度授权，全面负责产品开发，发挥着直接的、综合性的影响。各个部门的代表则被视为各个部门的在项目组中的全权代表。他们的工作是双向的，一方面是在研发各关键节点代表本部门参与评审与决策，另外一方面则相当于PDT分派给各部门工作的子项目经理，负责统筹协调本部门被分派的工作。PDT通过各部门代表，可以和各部门建立一种比较紧密的、有效的、高效的联系。这种机制下，各功能部门的经理更多是一种幕后支持角色，核心工作是负责本部门的资源与能力建设。

PDT机制本质上是一种矩阵式管理模式（参见本书第4章第5节）。从驾驭组织博弈的角度看，PDT机制其实就是通过构建新的虚拟组织角色，改变博弈形态，冲击直线管理模式里存在的官僚主义壁垒，在直线式组织结构博弈和项目型组织结构博弈之间寻求一种相对不坏的平衡。

从决策与执行分立的原则的看，PDT属于执行角色，对应的还有一个决策组织，通常也是一个团队。我们姑且称这种决策团队为“产品线决策委员会”，一般由产品线或公司层面的高级管理者与资深专家组成，它扮演的是一个投资决策者的角色（与此相关的其他内容请参见第4章第4节）。对于业务规模较小或非多元业务企业，设立一个的决策团队就够了，反之则可能需要设立多个决策团队以对应不同产品组合或产品线。

第三，项目管理流程化。

作为一门已经比较成熟的管理学科，项目管理有自己的一套方法论。其实，开发一个产品就是在做一个项目。那么，如何看待项目管理与产品开发流程之间的关系呢？这不是一个纯理论问题，而是一个现实中必须面对的实践问题。企业内部的产品开发，从项目管理上看，是一次性任务；但从动态发展的角度看，产品开发是反复进行着的，其流程是可以固化下来的。所以，产品开发必须融合项目管理与流程化管理两种不同的方法体系。我提出的一个处理总原则就是“项目管理流程化”。

对于“一次性任务”性质的项目管理，强调的是分工、范围、责任。因为管理空间是比较大的，一般不会在项目推进路径上花力气建设精细的流程，在大框架明确的前提下，更多是依靠人的能动性，重视权变，总体上呈现以人为中心的“片区化”管理特征。而流程管理是基于重复作业的，强调模式的固化、流程路径的相对固化，由此形成的管理空间相对较小，需要精细化、法治化，总体上呈现以流程为中心的“链式”管理特征。因此，在产品开发项目中，以流程管理为主线，能够把项目管理五大过程、十大领域等内容以流程方式固定下来的，将二者有机融合，实现“项目管理流程化”。可以这么讲，项目管理提供了丰富的管理思想指导与实用工具，而流程化管理则可以把它们集成起来，形成一个管道、一套体系。

第四，节点式推进。

产品开发流程中由分到合、由合到分、发生形态变换的节点就是K点，比如经过分析论证决定是否要立项的K点、设计评审的K点、样机确认K点、测试验证K点、小批量验证K点、量产K点等，这些节点在产品开发管理中具有重要的里程碑作用，可利用价值空间非常大。不过在很多企业研发管理体系中，并没有重视并积极利用这些K点。

如果把产品开发视为投资行为的话，产品开发过程中的部分K点可以作为投资审视窗口，来判断投资的风险，以及是否要追加投资或者削减投资，甚至取消投资。

从多部门协同的视角看，K点可起到协同校正点的作用，超前的等一等，落后的跟上来；也起到质量验证点的作用，交付质量未达要求的分支工作可以在这个点被发现，并及时采取相关措施。

从组织分工的视角看，K点起到强化不同部门责任区分的作用，并能及时发现权责模糊之处并做出对应处理。

从技术角度看，研发过程中某些活动反复迭代也是正常的，K点为迭代划分了区间性缓冲区，既能防止发生代价巨大的返工（一般是流程后期才发现问题，这时要对前面大部分工作进行返工），又能让K点区间内的迭代具有足够的灵活性。

从项目调度的角度看，K点也扮演了一个对下一阶段工作进行具体安排的“调度窗”角色。

从监管的角度看，K点为外部监查者或高层领导提供了一个便利的“观察窗”。

从项目进度管理的角度看，K点帮助形成了一种步步为营的推动力量。