这是故事的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人的效率公众号，不加班必备
科学工作，少走弯路，快来关注吧！
