编辑导语:当产品已经临近上线时,领导又提出了另一个需求,而技术也没有额外的人力支持时,产品经理该怎么做呢?本文作者分享了产品项目推进的不可能三角形,从时间、成本、质量三个方面分析,希望对你有所帮助。

“新增这个功能,必须跟最近的版本一起这周就上!”

“可是……技术没有额外的人力支持……”

“我不管,这是老板要的。”

“……”

相信PM们都常常遇到上述对话的情况,明明已临近上线时间,熊熊又追加了一个“老板”提的需求,领导要求一定要满足,但技术同学已经疲惫不堪,这时身为PM的你该怎么办呢?

这里无法用短短的一篇文字教会大家与领导沟通的技巧,但可以教给大家一个推动产品项目要素衡量的思路及框架,在与工作伙伴协调时,可通过这个框架,合理地平衡各方利益、并梳理项目情况让工作伙伴明白,进而最大化地顺利推进产品上线。

01 产品项目推进的不可能三角形

从来没有一个项目可以在时间、成本、质量三方面最优的情况下完成产品上线。如果有,肯定是在你没察觉的地方有所埋坑。

在成本投入最少时,想要保证高质量,则势必需要拉长开发时间;而在要求高质量、时间周期短的情况下,则势必需要投入更多成本。

三个要素中,固定任意要素后,另外两要素有具有负相关,无法两者同时达到最优。

而三个要素汇总仍可进一步细分为以下几点。

1. 成本

  • 人力成本:这个人力成本,不单只是投入人力的数量、工时,也包含了人力的质量,人力的投入多寡,便能影响产品完成的时间周期及质量。
  • 资金成本:这产品开发是否有项目奖金的激励?是否有对绩效考核的明确影响?是否有足够的服务器或设备投入?是否有资金请外援或第三方工具协作?
  • 合作成本:项目能否复用公司内部的现有的资源?是否有关联的中间件或SDK工具可以直接接入?是否能从第三方获取资源节省开发成本?是否需配合内部或外部第三方协作开发?

2. 时间

  • 设计时间:产品设计、UI设计、研发架构设计周期时间。
  • 沟通时间:各类需求对接沟通、评审会等沟通时间。
  • 开发时间:实际研发周期、测试周期等时间。

3. 质量

  • 功能数量:需实现的迭代或新增的产品数量。
  • 服务器效能:功能实现所消耗的服务器效能多寡。
  • 代码质量:代码是否足够简洁?代码逻辑是否自洽?代码耦合度如何?是否有预留后续扩展空间?注释是否清晰?

02 实际运用

当我们掌握了上述的框架后,如遇到开头的情况:老板新增功能、上线时间不变,那么对应到不可能三角形上,我们就很清楚地知道能从这三方面着手思考。

1. 时间

通常上线时间,除非是有明确的时间节点(如双十一、六一八、周年庆),或与公司内部其他部门协作,或与外部第三方协作,必须在固定的日期上线。不然正常新增需求下,都是可以要求增加开发周期的时间。

2. 质量

老板要求新增功能,领导也发话一定要开发了,【减少功能数量】那么是否在这个迭代版本中,是否有优先级不高的功能或需求可以暂缓呢?

而如果是到了最后收尾的阶段,那么也没有任何需求可以舍去的空间,那么也只能从资源上着手。

3. 成本

  • 人力:是否能从其他部门调用更多人力投入研发、测试?
  • 资金:是否有额外的项目奖金,激励研发人员投入开发?
  • 合作:老板要的新功能,是否能从公司内部或外部索取到相关组件,进行支持?

所以遇到老板追加需求、又要求时间按期上线,那么只能从资源这块着手去沟通、协调。

向领导、技术leader或公司索要追加投入成本来完成,如果没有顺利索要到资源的话,你需明确地反馈给领导,功能实现的质量可能会不如预期,即使功能还是实现,还是会有以下的问题存在。

对技术而言,要将一个功能实现有很多方式能搞,在时间紧、意愿不高的情况下,通常就是功能实现方式耗能过高,在用户大量使用下容易造成服务器崩溃。

或者,代码没有预留数据扩展性,造成后续迭代的难度增加,甚至需要重新设计数据表、刷数据库等情况,为将来埋下一个大坑。

03 总结

虽然这次分享的内容看起来比较简单,只要从三大方面去思考项目推进的情况,便能很容易地确定协调的方向及平衡各方要素的办法。

但是实际执行时,还是很可能会受到其他的因素影响,不一定能顺利推动项目达到预期的结果。

对于刚开始能独立推进项目的PM,还是提供了最底层操作逻辑及基本的思考框架,能够在遇到项目突发情况时,透过这个三角形的框架下,做出快度的判断及方向,进行项目的沟通及协调。