假设给医院开发系统，目前对医院的业务是略知一二，仅得到一些backlog。按照scrum，现在可以进行开发了，挑选一些backlog，进行sprint1,完了后，算出一个大概的速度，继续sprint。。。（在sprint1进行的同时，新的backlog不断的加了进来。。。）。

现在的问题就是，在谈合同的时候，客户方就需要一个预计的完成日期，我该怎么办？

总不能告诉说：等到没有新的backlog的时候，我就告诉你完成日期吧？

通常项目开发初期阶段，我们经常会遇到这样的困境。应该怎么办？

对于一个还没有跟供应商建立起信任的客户来说，他最希望见到的情况是：

• 每一分钱都花到刀刃上。也就是说，每一点投入都用来开发有用的功能
• 花小钱办大事。也就是说，花很少的钱，完成最有用的功能
• 透明，进度高度可控。每个一段时间都能了解到进度、质量，都有可以用的功能完成，这样客户能够做到心里有数

对于软件供应商来说，肯定是希望在短时间内建立和客户的信任，从而与客户称为长期的合作伙伴，这样对供应商长期的业务发展有很好的保障。

在合同谈判阶段，其是双方对系统的真正需求都不够了解，也不可能了解清楚，如果连做什么都搞不清楚，估计时间是不可能的。所以如果有可能，可以从客户角度提出建议，满足他对项目的期望:

• 把合同时间划分阶段，然后每个阶段的时间长度确定，每个阶段的时间长度应该可以完成一些可以用功能点(Minimum Marketable Feature)。我们可以在一个阶段里面划分为几个sprint。
• 确定每个阶段有可能完成的功能点(MMF)，从而形成了发布计划。
• 与客户达成协议，他可以不断地给出反馈，给出新的优先级意见，PO和开发团队会对新的需求及优先级调整对发布计划做出调整。

这种做法与第1种做法的最根本不同是，第1种做法基于的前提是所有的需求是可以预见的，因此只要对已知的所有需求拍脑袋做一下估算，然后推出时间；而第2种做法假设需求是不可能实现预测的，我们是周期性的审查，调整，客户要做的只是确保把想要的功能排一个优先级，然后团队只是根据自己的开发速度，取出最高有限级的那部分功能，然后去实现。等到客户认为所有的功能都已完成，或者团队开发的功能提供的价值不够客户的投入时，客户可以说停止。

长远来看，第2种做法做出来的功能对客户肯定是客户需要的，而且客户可以清楚的掌控团队开发质量和速度，有利于建立双方的信任。而像第1种方法那样，很多无用的功能，因为如果客户只有一次机会说出所有的需求（在项目开发初期），他他会穷尽脑汁想出很多他根本用不到的功能（可能要占到所有功能的2/3）。而不可避免的，还会有很多有用的功能被遗漏，如果想要，只能提出需求变更。

其实还有几个问题没有回答，如何跟客户承诺每个阶段递交多少功能点？如何确保能够完成这些功能点？如何确保花小钱办大事？因为篇幅有限，我会在接下来几天说明。