软件研发那些事儿——项目计划的控制

       无论软件产品还是软件项目，在需求分析真正结束之前，都难以确定整个项目周密而详细的进度计划，道理很简单，我们尚且不知道要做什么，如何知道每天的工作？所以，完整的项目计划是阶段性，层层递进的。

       对软件项目来说，系统设计之前的主要工作包括方案书的制定和确认、需求调研及分析。在处理方案和需求的时候，需要不断地和用户协调，沟通，甚至反复讨论确认一些关键问题，项目计划会频繁的受到用户个人工作安排的影响，以致很多时候需要经常变更具体的计划，以适应用户的工作安排。在控制这部分工作的计划时，要考虑到用户方面的影响，在计划中预留出变动的余地，但实际工作需要尽量往前安排，让变化来得早些总别来得晚些要好的多。

       有的项目，用户更关注时间进度，即项目是以时间为基准的；有的项目，用户对时间进度的要求不是很严格，但更关注功能的完整性，即项目是以功能为基准的。

       按照经验和规律分析，一个项目系统设计前的工作时间大概占到整个项目总时间的三分之一。对于以时间为准线的项目，首先要明确用户要求的时间总要求，然后切分出三分之一留给系统设计前的工作，在需求分析阶段根据剩余的三分之二的时间长度来规定出要开发的功能。而对于功能为准线的项目，无需在需求阶段太过保守，也就是需求阶段尽量以功能的全面性为目标，而不必过多考虑时间的约束。在分析完所有的需求后，再重新制定接下来工作的详细计划。

       项目在设计、编码、测试阶段所占的时间比大概是1:1:1，但国内大部分软件项目都达不到这种标准。一个突出的特点是中间大，两头小，也就是设计阶段占用时间非常少，粒度很粗，代码阶段占去了大部分时间，然后测试又做的很浅，软件的最终质量可想而知。

       方案是告诉用户我们解决问题的一个大致思路，需求分析是和用户共同约定我们要实现什么，而设计则是解决如何实现的问题。如果在真正实现之前，不把思路、方法考虑清楚，不预先估计潜在的困难，很可能造成编码的反复修改，大部分失败的项目都是在编码之前埋下了祸根，要么需求不彻底，要么设计不正确。所以，在需求完整的情况下，设计阶段必须要有充足的时间保证，不能一味加快进度而忽视设计的质量。其实，前面的工作做的越充分，编码和测试阶段的工作就越轻松，计划的执行也就越顺利。为了避免计划的延迟，以及编码的反复，必须给设计留下足够的时间。

       大部分公司的系统设计都是由水平较高的技术人员来做的，这部分工作的计划变更较少。但到了编码阶段，参与开发的编程人员水平参差不齐，详细的开发进度计划就可能经常变更，大部分是由于对成语能力的估计不足造成的。随着开发的推进，这部分的影响会慢慢的削弱，越来越多的计划变更开始和需求和设计有关。在制定开发阶段的计划时，开始部分应为变更预留多点的空间，中后期可以紧一些，但团队成员的整个工作气氛还应保持紧张的程度。

       导致加班的原因有多种，比如用户要求的时间紧，项目的开发水平不够，团队的工作效率比较低，等等，但我一直认为加班不会给项目带来积极的影响，事实也是如此。如果要想达到较高的项目质量，我们应避免加班，为了避免加班，我们就必须在提高团队开发能力和开发效率上下功夫。如果一个团队在加班的认识上清晰且一致，问题就很好解决。往往是领导一味追求进度，给项目经理施加较大的压力，项目经理再将压力下放，层层传递，加班的事情似乎不可避免，项目的质量也就埋下了隐患。一味追求进度的领导不是好领导，一味想通过加班推进项目的领导不是好领导，好的领导应该比项目组团队更加清楚加班的负面影响，然后通过更加积极的方式来达到工作的目的，比如培训、鼓舞士气、计划控制等。

       总之，要想达到好的计划控制，应做到以下几点：

       合理安排项目各阶段的时间

       和用户的协调沟通事务要快，要向前赶

       对系统设计工作要缓而细，缓是指慎重考虑，细是指思考全面

       分析每个人的能力水平，合理分配任务

       适当的培训

       让团队在正常工作时间全神贯注，保持紧张的工作态度

尽量避免加班，尤其是项目后期的加班。