目录
目录
1. 开发阶段的真实处境
2. 开发阶段的两道核心评审门
3. 需求基线怎么管
4. DCP和TR：谁有权力停项目
5. 三个常见错误
作者简介
前面讲解了IPD概念阶段、IPD计划阶段。
今天继续从落地实践角度展开IPD的开发阶段。
项目上了，合同也签了，开发阶段正式开始。
然后又出现了新问题，很多事情在执行中开始跑偏。
TR评审变成走过场，需求变更也没有门控，计划和执行越来越远。
1. 开发阶段的真实处境
2. 开发阶段的两道核心评审门
3. 需求基线怎么管
4. DCP和TR：谁有权力停项目
5. 三个常见错误
很多企业把开发阶段当成"执行期"。
合同签了，方向定了，接下来就是干活。
结构、硬件、代码都跑起来，里程碑也追起来。
相信很多企业也是这么做的，如果只是做到这一步，那就对IPD有误解了。
开发阶段还有两件事：履约 + 守门。
-
- 守门，是用技术评审守住质量，不让不合格的中间产物流入下一阶段。
计划阶段回答的是：值不值投。
开发阶段回答的是：能不能按约定交付，同时守住质量。
两个问题都回答了，开发阶段才算合格。
IPD里，技术评审从TR1到TR6，贯穿整个流程。
开发阶段最核心的是两道门：TR4和TR5。
TR4：详细设计评审
这道门评的是：
-
- 评设计规格有没有被遗漏，实现方案是否对得上测试方法？
常见误区：把TR4开成"技术方案讨论会"，结论写"基本可行"。
正确做法：拿着系统规格，逐条对照。
-
- 实现方案是什么？
- 测什么？
- 怎么测？
TR5：开发阶段出口门
TR5标志着开发阶段的正式结束，该阶段没有正式的决策评审。
TR5的核心是：对设计可靠性做一个整体评估，判断产品是否做好向验证阶段移交的准备。
通过标准只有一条：规格能验证，指标能测量，结果和基线对得上。
两道TR，有一个共同的核心原则：规格可验证。
要有标准、能测试、对得上。
这条原则守住了，TR评审才有价值。
守不住，TR就变成了走过场。
计划阶段锁定的需求，是PDT对IPMT的合同承诺。
开发阶段遇到新情况，能不能改？
能，但必须走变更评审。
不是谁想改就改，不是产品经理拍脑袋，不是研发自己决定。
变更评审要回答三个问题：
1. 这个变更影响了哪些合同条款？
2. 对进度、成本、技术风险的影响是什么？
3. 有决策权的人判断：值不值得改？
很多企业的实际情况：产品经理提一个需求，开发评估了一下能加，就加了。
-
- 没人记录；
- 没人评审。
范围蔓延，是开发阶段吞噬项目成本最隐蔽的方式。
每一项小变更，单独看都"没什么大不了"。
累积起来，产品和最初签的合同，已经是两张皮。
还有一个最容易混淆的地方。
TR团队：评技术，给建议，不能停项目。
TR评审给出的是技术判断，不做商业决策。
技术上不可行，商业上可能依然值得继续。
反过来，技术上完美，商业上可能已经不划算。
IPMT（DCP）：有商业决策权，可以叫停项目。
IPMT站在投资视角，评估的是：这个项目继续投，还值不值。
这是两套完全不同的职责体系。
很多企业的问题是：用TR代替DCP。
技术评审开了一堆，结论写了几页——然后没有然后，项目继续。
TR是质量守门员，IPMT是指挥官。
-
- 门员不能直接宣布比赛结束。
错误一：TR评审形式化
评了，但不严格。
专家说差不多，结论写通过，下一阶段继续。
代价：在验证阶段甚至发布阶段，才发现规格对不上。
那个代价，是开发阶段走形式十倍以上。
包括我在讲解需求管理的时候也经常提到，越往后，解决问题的成本会指数级上升。
错误二：需求变更没有门控
合同签了，开发阶段随意改。
改了没记录，没评审，没人对整体计划负责。
最后产品做完，和合同面目全非。
错误三：把开发当纯执行
没有质量门控，没有变更评审，没有基线管理。
项目在开发阶段失控，通常不是技术问题，是没有人守门做控制。
总结
PDCP是开工令，TR是质量门。
开工令发了，门没守，开发阶段就是一场不知道终点的奔跑。
你的开发阶段，是在"干活"，还是在"履约+守门"？
这中间的差距，就是执行与专业的距离。
卫朋，《硬件产品经理》作者，实战派产品及流程专家，人人都是产品经理受邀专栏作家，CSDN认证博客专家、嵌入式领域优质创作者，阿里云开发者社区专家博主。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/265614.html