该帖子同步发自：(飞眉的博客  访问该博客)

　　先简要描述一下我们做项目的流程，在做项目中经常遇到某些需求要求在某个时间段内完成。当PD开始收集所有需求问题后整理，召集相关人员分析需求的可行性。同时要求能评估出开发时间，往往这时候因对需求实现上存在不同方式、理解上不够，决定了开发时间的不准确性。当最后确定要做的需求后，由项目经理安排开发。这时候项目首先进入对需求的具体分析设计阶段，随着设计的细节考虑，时间评估上出现了较大偏差。反馈到PD后，大家就觉得项目怎么搞的，按照规定时间可能是做不完了，只好砍掉一些需求，这个过程又会浪费部分时间。最后由于时间的紧迫性，加班赶工，进入测试阶段，在测试过程中又会发现开发的兼容性、扩展性等方面由于前期代码架构的问题引出新的问题。经过一番折腾终于在规定时间内搞完，也许有些功能还没有具体测试。当要发布的时候，总结一下，发觉有些需求并不太符合最原始的需求了。而且花费近两个多月也没做几个需求，反倒是因为部分需求需要修改原来的实现，或者因兼容以前的功能做了更多的事情。

　　下面我们看一下流程图：　

　　项目流程图

　　从以上可以看出需求实际上占了整个开发的三分之一，当然了前期需求没设计好是很影响后面的开发的。同样的，当前项目中的系统架构及设计没做好是会影响后面项目的。有些需求可能还与其他部门相关，在配合上也存在较大风险。

　　一般来说主要问题在因时间紧迫，有些涉及架构的需求被砍掉、或者因业务需求导致原始架构变更。在同一个产品上持续开发，每次小项目的完成将导致测试回归所有的功能，这个占的时间比例也很大。通常我们将开发时间和测试时间是对半的。

　　从多个小项目实践上看，如何将项目时间和需求功能合理调配比较关键，同时对需求功能的时间评估及设计，需要对系统比较熟悉的人来做，往往我们拿到需求后给相关开发人员去评估工作量，开发人员的理解因只限于局部，或者因其他原因预估时间偏差也比较大。针对上面的流程图，我们可以根据实际情况加以改进，但PM要把握好整个进度执行。