IPD开发阶段：合同签了，门谁来守？

前面讲解了IPD概念阶段、IPD计划阶段。

今天继续从落地实践角度展开IPD的开发阶段。

项目上了，合同也签了，开发阶段正式开始。

然后又出现了新问题，很多事情在执行中开始跑偏。

TR评审变成走过场，需求变更也没有门控，计划和执行越来越远。

目录：

1. 开发阶段的真实处境

2. 开发阶段的两道核心评审门

3. 需求基线怎么管

4. DCP和TR：谁有权力停项目

5. 三个常见错误

1. 开发阶段的真实处境

很多企业把开发阶段当成"执行期"。

合同签了，方向定了，接下来就是干活。

结构、硬件、代码都跑起来，里程碑也追起来。

相信很多企业也是这么做的，如果只是做到这一步，那就对IPD有误解了。

开发阶段还有两件事：履约 + 守门。

• 履约，是按合同要求把东西做出来；

• 守门，是用技术评审守住质量，不让不合格的中间产物流入下一阶段。

计划阶段回答的是：值不值投。

开发阶段回答的是：能不能按约定交付，同时守住质量。

两个问题都回答了，开发阶段才算合格。

2. 开发阶段的两道核心评审门

IPD里，技术评审从TR1到TR6，贯穿整个流程。

开发阶段最核心的是两道门：TR4和TR5。

TR4：详细设计评审

这道门评的是：

• 各模块的详细设计方案，是否完整覆盖了系统规格？

• 评设计规格有没有被遗漏，实现方案是否对得上测试方法？

常见误区：把TR4开成"技术方案讨论会"，结论写"基本可行"。

正确做法：拿着系统规格，逐条对照。

• 这条规格谁负责实现？

• 实现方案是什么？

• 测什么？

• 怎么测？

TR5：开发阶段出口门

TR5标志着开发阶段的正式结束，该阶段没有正式的决策评审。

TR5的核心是：对设计可靠性做一个整体评估，判断产品是否做好向验证阶段移交的准备。

通过标准只有一条：规格能验证，指标能测量，结果和基线对得上。

两道TR，有一个共同的核心原则：规格可验证。

要有标准、能测试、对得上。

这条原则守住了，TR评审才有价值。

守不住，TR就变成了走过场。

3. 需求基线怎么管

计划阶段锁定的需求，是PDT对IPMT的合同承诺。

开发阶段遇到新情况，能不能改？

能，但必须走变更评审。

不是谁想改就改，不是产品经理拍脑袋，不是研发自己决定。

变更评审要回答三个问题：

1. 这个变更影响了哪些合同条款？

2. 对进度、成本、技术风险的影响是什么？

3. 有决策权的人判断：值不值得改？

很多企业的实际情况：产品经理提一个需求，开发评估了一下能加，就加了。

• 没人问对合同的影响；

• 没人记录；

• 没人评审。

范围蔓延，是开发阶段吞噬项目成本最隐蔽的方式。

每一项小变更，单独看都"没什么大不了"。

累积起来，产品和最初签的合同，已经是两张皮。

4. DCP和TR：谁有权力停项目

还有一个最容易混淆的地方。

TR团队：评技术，给建议，不能停项目。

TR评审给出的是技术判断，不做商业决策。

技术上不可行，商业上可能依然值得继续。

反过来，技术上完美，商业上可能已经不划算。

IPMT（DCP）：有商业决策权，可以叫停项目。

IPMT站在投资视角，评估的是：这个项目继续投，还值不值。

这是两套完全不同的职责体系。

很多企业的问题是：用TR代替DCP。

技术评审开了一堆，结论写了几页——然后没有然后，项目继续。

TR是质量守门员，IPMT是指挥官。

• 守门员发现风险，要报告给指挥官，由指挥官决定下一步；

• 门员不能直接宣布比赛结束。

5. 三个常见错误

错误一：TR评审形式化

评了，但不严格。

专家说差不多，结论写通过，下一阶段继续。

代价：在验证阶段甚至发布阶段，才发现规格对不上。

从营收700亿看哇哈哈宗馥莉的产品战略布局

了解更多

产品人卫朋

查看原文：IPD开发阶段：合同签了，门谁来守？

文章来源：

产品人卫朋

扫码关注公众号