【原创漫画】计划排太满造成的3种悲催结局,你遇见过几个?
这是故事的3个主人公:
产品经理小花 开发小明 测试小燕
这是故事的开始:
2018
07
17
做版本计划第一天
2018
07
31
到了发版前一天
第1种悲剧结局:延期
这是第1种悲催结局:发版延期
第2种悲剧结局:回滚
由于没有充分的时间测试,于是就有了:
第2种悲催结局:上线后质量问题频发
产品上线了。
经过半年的持续加班/通宵,第二年3月份的时候,团队人员大幅离职,要重新招聘。
这是第3种悲催结局:士气降低,人员流动
PS: 加班造成的人员流动并非危言耸听。
我之前曾任职的一家公司,遇到一个新来的项目经理,TA连续加班4个月,因为长了一个瘤(还好是良性的)被医生劝说离职。
是的,是医生建议TA离职。
故事讲完了。现在问题来了:
为什么我们这么努力,却得到这样的结局?
简单的回答是:计划排得太满。
我通常推荐团队把“完美情况下”团队能完成的工作乘以90%做为研发团队承诺完成的目标,10%做为延展目标(stretch goal)。
研发团队将在时间允许的情况下尽可能完成延展目标。
注意:延展目标不是在"完美情况下“团队能完成的工作之外的、从100%到110%的那10%,而是90%到100%的那10%。
为什么不全力以赴?
产品经理通常会这样挑战我的建议。甚至有时候开发经理也会这么问。
我的回答很简单:
如果你们要按照“完美情况下”来制定计划,就请不要在最后一刻发现世界并不是完美的时候觉得很惊讶。
现在来说使用延展目标的3个好处:
1
更高的产能
这是一个违反直觉的结论。但这是真的。
如果没有延展目标,团队必须承诺完成100%的需求。当“完美世界”(几乎不可避免地)崩塌的时候,团队就不得不在牺牲质量和延期之间做选择。
产能指的是单位规模的团队在单位时间里的有用的产出。注意,是有用的产出,也就是说,需要具备基础的能被用户接受的质量。
牺牲基础质量是一个糟糕的选项,因为后续团队需要在修复缺陷上付出更多,而且糟糕的产品质量会给用户造成不良印象甚至流失,造成的负面影响无法估量。
如果延期,从长期来看,团队的交付价值的周期变长了,也就是说,原本在一个比较小的单位时间就存在的团队产能,现在在这个单位时间里已经实现不了了。
如果不是刻意计划更低频地发布,那么这是一种团队能力的退化。
2
更好的信誉
研发团队将获得更好的信誉。通常把存在变数的需求作为延伸目标,让团队聚焦交付主要事项。这样,团队总是按时完成工作带来团队的信誉提升,这有利于团队和各方干系人之间建立更多的信任。
3
更灵活应对变化
延展目标给团队按节奏交付提供了必要的缓冲,同时也给变更提供了空间。
总结
计划不要排太满,将存在变数的工作做为10%的延展目标,有利于提高团队产能、提升团队信誉、和给团队赋予更灵活的应对变化的能力。
最后,如果你所在的团队存在计划排太满的问题,请他们参考这篇文章可能有帮助:)
END
精选文章
京东末位淘汰:为什么末位淘汰不适合用在软件研发团队(附特朗普亲身示范正确做法)
“轻松做软件”是IT人的效率公众号,不加班必备
科学工作,少走弯路,快来关注吧!