这一篇我们继续讲如何管理用户期待。
上一篇我讲了管理用户期待的两个方法之一：信息透明。这篇我们讲方法之二：给用户的交付日期承诺是可靠的。
要做到第二点，本质是依赖于两点：
1.团队有稳定的产能。产能指的是单位规模的团队在单位时间里产出的可靠的软件的规模（规模的意思就是大小，和工作量相对应）。也就是团队交付软件的速度。
2.团队对新来的需求的规模，能有一个相对可靠的估算。
假如团队做软件的速度是：T长度的时间里产出S规模的软件。
新来的这个需求的规模是A。
那么团队预计交付这个新来的需求的工期就是A/S*T。（请记住A/S*T这个公式，这篇文章后面我们会多次提到。）
如果新来的这个需求前面还有一些其他的需求，那就以此类推，把前面这些需求的工期也加进去。
如果A估算得不准，或者S团队自己也不知道（或者非常不稳定）。那么A/S*T得出来的值也是不可靠的。
在本系列文章的第一篇，我曾经有提到专家估算。有人可能会问：这个给用户的预计交付时间，是不是也可以用专家估算法（拍脑袋式）？
简单的回答是不太可能。
即使是使用拍脑袋式评估，拍脑袋的大思路仍然是需求大小除以团队做需求的速度——A/S*T。
A，新来的需求的规模，勉强也可以用专家估算。但是S——团队的产能，却不是一个估算的问题，而是一个实际团队能力的问题。
也就是说：团队要达到稳定的产能，不是靠思考和计算就能达到的，而是需要团队软件工程能力达到一定的水平。
有人可能会问，什么情况下才能算有稳定的产能呢？
回答是：团队能在固定的时间里交付固定的软件规模。
这句话是不是听起来很耳熟？
是的，这就是迭代开发的方法。
要实现这个目标，需要做很多的事情，其中的任何一点做的不好，都会对产能造成影响。
比如，如果需求定义不清晰，一边开发一边澄清需求/返工，或者需求变更没有得到很好的控制，都会造成产能不稳定，甚至到交付的时间了还是零产能。（所有需求都没有达到交付状态。）
看到这里，可能有些团队会觉得有点沮丧：
“我们现在的团队还没有达到稳定的产能，我该怎么给用户可靠的交付时间呢？”
对这个问题，我有两个建议：
一，不要在压力下过早地给出完全没有参考价值的交付时间承诺。
二，在可以给出有相对参考价值的交付时间承诺的时候，使用“我有百分之XX的信心，可以在XX时候交付”句式。
先说第一点。举例说明。
我曾经作为敏捷顾问支持一个小型团队。这个团队是在团队的领导(GM)的要求下建议我进去支持的，当时他们还在开发软件的第一个版本。
经过调研，我发现团队最大的问题就是，之前他们在压力下给GM承诺了两次第一个版本的发布时间，但是两次都没有按照他们的承诺发布，这让GM很不满意。
我看了一下这个产品的情况，包括当时的遗留缺陷的数量和缺陷的趋势图，和待完成的需求的数量。这些信息都表明：这个产品不可能在短期内交付。
而产品经理正在为在接下来给GM的例行汇报中如何汇报交付时间而发愁。
我说：在我们能得到一个相对比较可靠的预计完成时间之前，不要给出交付时间，但是要给对方我们什么时候可以给出相对可靠的交付时间，并且说明理由。
比如可以说：
“我们现在没有可靠的预估时间，但是我们在3周后，也就是X月X日可以给出一个相对可靠发布时间的预估。
这个3周的时间是怎么得出的呢？
在这3周里，我做了下面的事：
第一周，带领团队对发布标准（质量）和第一个版本的剩余需求（范围）做了明确的界定，然后引入敏捷估算，引导团队估算了剩余要完成的软件规模，也就是A。
用团队的一个迭代周期（两周）度量团队的实际产能，也就是S。
在第3周结束的时候，我用A/S就能得到N个迭代后能发布的发布时间，汇报给GM。
以上就是第一点：不要在压力下过早地给出完全没有参考价值的交付时间承诺。
再来说第二点：在可以给出有相对参考价值的交付时间承诺的时候，使用“我有百分之XX的信心，可以在XX时候交付”句式。
还是拿上面这个案例来说。
3周后。
产品经理得到了团队的实际产能，结合估算/产能不稳定造成偏差，我建议他和GM汇报说，
“我们有75%的信心可以在M月D日发布。”
75%也许不是一个很高的信心指数，但是这是一个反应事实的信息，对用户是有参考价值的。
如果GM要求更早的发布日期，我们可以说，对于在您说的这个日期前发布，我们有XX%的信心。如果只有20%的信心，也要如实相告，并且把相应的风险进行及时的披露。
最后，这个产品按承诺的时间交付了。GM很满意。
好了，现在我们对本篇内容做一个总结。
“信息透明”和“给用户的交付日期承诺是可靠的”是管理用户期待的两个方法。
给用户的交付日期的可靠程度是依赖于团队的估算水平，和团队的产能的稳定性。（如何达到可靠的估算水平，和稳定的产能，我们后续再说，这里不展开。）
如果团队目前不具备给出可靠预计交付时间的条件，建议仅仅给出新的需求在所有需求队列中的位置（参考上一篇讲信息透明的文章），让用户有一个大概的预期。
避免在压力下过早给出完全没有参考价值的交付时间承诺。
在可以给出有相对参考价值的交付时间承诺的时候，使用“我有百分之XX的信心，可以在XX时候交付”句式。
在用户提出交付信心很低的要求交付日期的时候，尽早使用“信息透明”的方法（详见上一篇）说明实际情况，并且如实告知按照这个时间交付的实际信心程度，和其他交付风险。
关于管理用户期待，你遇到过什么样的故事，有什么好的方法？欢迎你在后台留言！
END
精选文章
“轻松做软件”是IT人的效率公众号，不加班必备
科学工作，少走弯路，快来关注吧！
