编辑导语：当产品已经临近上线时，领导又提出了另一个需求，而技术也没有额外的人力支持时，产品经理该怎么做呢？本文作者分享了产品项目推进的不可能三角形，从时间、成本、质量三个方面分析，希望对你有所帮助。
“新增这个功能，必须跟最近的版本一起这周就上！”
“可是……技术没有额外的人力支持……”
“我不管，这是老板要的。”
“……”
相信PM们都常常遇到上述对话的情况，明明已临近上线时间，熊熊又追加了一个“老板”提的需求，领导要求一定要满足，但技术同学已经疲惫不堪，这时身为PM的你该怎么办呢？
这里无法用短短的一篇文字教会大家与领导沟通的技巧，但可以教给大家一个推动产品项目要素衡量的思路及框架，在与工作伙伴协调时，可通过这个框架，合理地平衡各方利益、并梳理项目情况让工作伙伴明白，进而最大化地顺利推进产品上线。
01 产品项目推进的不可能三角形
从来没有一个项目可以在时间、成本、质量三方面最优的情况下完成产品上线。如果有，肯定是在你没察觉的地方有所埋坑。
在成本投入最少时，想要保证高质量，则势必需要拉长开发时间；而在要求高质量、时间周期短的情况下，则势必需要投入更多成本。
三个要素中，固定任意要素后，另外两要素有具有负相关，无法两者同时达到最优。
而三个要素汇总仍可进一步细分为以下几点。
1. 成本
- 人力成本：这个人力成本，不单只是投入人力的数量、工时，也包含了人力的质量，人力的投入多寡，便能影响产品完成的时间周期及质量。
- 资金成本：这产品开发是否有项目奖金的激励？是否有对绩效考核的明确影响？是否有足够的服务器或设备投入？是否有资金请外援或第三方工具协作？
- 合作成本：项目能否复用公司内部的现有的资源？是否有关联的中间件或SDK工具可以直接接入？是否能从第三方获取资源节省开发成本？是否需配合内部或外部第三方协作开发？
2. 时间
- 设计时间：产品设计、UI设计、研发架构设计周期时间。
- 沟通时间：各类需求对接沟通、评审会等沟通时间。
- 开发时间：实际研发周期、测试周期等时间。
3. 质量
- 功能数量：需实现的迭代或新增的产品数量。
- 服务器效能：功能实现所消耗的服务器效能多寡。
- 代码质量：代码是否足够简洁？代码逻辑是否自洽？代码耦合度如何？是否有预留后续扩展空间？注释是否清晰？
02 实际运用
当我们掌握了上述的框架后，如遇到开头的情况：老板新增功能、上线时间不变，那么对应到不可能三角形上，我们就很清楚地知道能从这三方面着手思考。
1. 时间
通常上线时间，除非是有明确的时间节点（如双十一、六一八、周年庆），或与公司内部其他部门协作，或与外部第三方协作，必须在固定的日期上线。不然正常新增需求下，都是可以要求增加开发周期的时间。
2. 质量
老板要求新增功能，领导也发话一定要开发了，【减少功能数量】那么是否在这个迭代版本中，是否有优先级不高的功能或需求可以暂缓呢？
而如果是到了最后收尾的阶段，那么也没有任何需求可以舍去的空间，那么也只能从资源上着手。
3. 成本
- 人力：是否能从其他部门调用更多人力投入研发、测试？
- 资金：是否有额外的项目奖金，激励研发人员投入开发？
- 合作：老板要的新功能，是否能从公司内部或外部索取到相关组件，进行支持？
所以遇到老板追加需求、又要求时间按期上线，那么只能从资源这块着手去沟通、协调。
向领导、技术leader或公司索要追加投入成本来完成，如果没有顺利索要到资源的话，你需明确地反馈给领导，功能实现的质量可能会不如预期，即使功能还是实现，还是会有以下的问题存在。
对技术而言，要将一个功能实现有很多方式能搞，在时间紧、意愿不高的情况下，通常就是功能实现方式耗能过高，在用户大量使用下容易造成服务器崩溃。
或者，代码没有预留数据扩展性，造成后续迭代的难度增加，甚至需要重新设计数据表、刷数据库等情况，为将来埋下一个大坑。
03 总结
虽然这次分享的内容看起来比较简单，只要从三大方面去思考项目推进的情况，便能很容易地确定协调的方向及平衡各方要素的办法。
但是实际执行时，还是很可能会受到其他的因素影响，不一定能顺利推动项目达到预期的结果。
对于刚开始能独立推进项目的PM，还是提供了最底层操作逻辑及基本的思考框架，能够在遇到项目突发情况时，透过这个三角形的框架下，做出快度的判断及方向，进行项目的沟通及协调。