在接触项目管理的这段时间，工期的预估一直以来就是一个特大难题，但是这也是一个必须去解决的问题，为此我们想过N多种的方案，也参考研究了很多的网上的案例，为此，我尝试建立了两种的流程模型。
第一种针对的小型的项目，一眼就能看到项目的结尾，如一个开发某个小型产品，这种模式也是我实际的在项目中使用过，但坏处就是，在项目前期需要投入大量的精力去深入的研究与分析，所以这个也只适合用于小型的产品开发。
在需求发来后，在项目前期的迭代划分时，有负责人来制定阶段的可见目标，由开发者粗略的估计完成此目标需要做的任务并粗略的估计这些任务需要的工作量，（我是使用工作量与工作日两个尺度，其实对于一个发展均衡的团队来说，我感觉有个工作量就够了，但是我们团队目前还无法达到此水平，所以增加一个工作日参数），然后根据阶段难度预留部分机动工作量与工作日，这样就确定各个迭代的工期，从中反推整个项目的工期。
最终在开始每个迭代之前，需要在计划会上详细拆分立项前粗略的任务划分，进行一次迭代开发，并且在迭代结束后，能完成可见目标。
这个的很大的一个难点就是在可见目标上的选择。
讲点我的个人看法，对于项目的工期预估准确性问题与风险可能存在两种，技术风险和需求风险，对于我目前公司来说，这个风险绝大部分是存在于需求，因为并没有形成一个完成的需求分析体系，所以导致项目在开发过程中不断的变更需求，导致开发人员根本无法预估项目的工期，如果想更准确的预估工期，必须在前期投入大量的时间去深入的进行需求分析，完全定稿需求后在进行开发，可能会事半功倍。
对于大型项目，这个我没有发言权，因为暂时还没有实例去验证这个模型的可行度。
我可以稍微讲一下我的理念，对于那些无法一眼看到结尾的项目，拍脑门想都是半年、1年的项目，我感觉就直接拍脑门定立项(不要把时间定的太宽泛)，把更多的精力放在眼前的迭代或者之后的几个迭代的周期把控上，这样逐渐的又把控的向整个项目结尾靠近，可能在经历过几个可见目标之后，可以像走向最后的第一种小型项目的模型。