最近的项目由于是新客户的原因，客户对我们团队是没有太多信心的。在接到项目的初期，客户只表示，他们其中一个关键的OKR是9月底要完成XXX，能将该功能交给用户使用，占领市场先机。
那客户侧对接的PO在我们开始进入交付之后，就开始一再询问交付进度预测。他们需要看到目前团队能到什么时候完成既定的功能需求。其实作为长期服务海外客户的我来说，我又一次看到了海外客户的人性化和讲道理，哈哈哈哈。如果换做国内客户，估计不会问你要预测，而是你作为一个乙方公司必须在他们需要的业务时间点上做完。通常这种情况，除了加人，就只剩加班。
为了完成这个预测，需要把目前计划在上线范围内的特性或者说故事卡整理出来，并且每个故事卡都有相应的估点，即团队基于目前的技术栈和特性复杂度给出了相应的评估。那么你会得到一个总的点数，例如第一次上线的内容，55个点。
根据这个点数，我们需要考虑一下点来做大概的上线时间点：
- 团队的请假概率，反面会得到团队的可用时间
- 团队里面TL写代码的时间分配，例如每天TL有很多技术的会议需要参加，也许只能花他个人时间的50%用来写代码。对于比较大的团队，TL有可能完全没精力写代码，时间都花在和比较Junior的dev进行结对，做分享，参与产品架构，方案讨论等等。
- 团队在初期估计的点数，随着后期对业务和技术栈的进一步了解，会有一定数量的膨胀，不能指望团队在初期就能考虑到实现层面的方方面面，做到全面估计。所以我们通常会根据最初的估算乘以20%左右的缓冲。这样得到一个更合理的工作量。
- 团队的人员数量，这个主要指团队中直接贡献进度的Dev数量。
- 根据团队对新项目的了解和熟悉程度，会有一个渐进提升速率的过程，我目前所在的组织，会认为，第一个迭代团队能拿出25%的时间进行实现，第二个迭代能到50%，第三个迭代75%，第四个迭代能全面开挂。作为任何一支新团队，比较理想的是技术栈都非常熟练，不用花额外的时间学习，业务也是100%理解清楚，不用额外时间沟通。但现实经常是，团队技术栈不熟练，业务也在持续熟悉中。因此这个百分比也是合理的。
有了以上的因素和变量，基本能得出团队各个迭代的累积消耗量，便能得到累积的burnup 图，也就得到了你的上线日期。
image.png
