项目进度管理-优快云博客

本文链接：https://blog.youkuaiyun.com/longaway/article/details/1484713

为了完成部门的季度绩效改进，在网上 G 了下。搜到些相关内容，摘其精要，贴在内网论坛上，交差了事。

cf 看完帖子，直接问，哪里抄的？
反问他，是不是写得太好了，不能相信？

确实，人家写得确实不错。
这么多年了，写作一直是弱项。

（引文有删截。详细内容，请参见（链接）原文。）

http://software.hdu.edu.cn/article.asp?bid=2&id=43252

　　为了管理好项目进度，首先要制定一个可行的项目进度计划。一开始，项目进度计划只能根据项目的内容、工作量和参加人员进行大致地估算，包括系统分析和设计时间，编程、测试时间和文档制作时间，估算时应根据业务复杂程度加入一些缓冲时间。系统分析、设计完成后，根据程序清单可估算出每个程序的编程时间（根据程序类型和复杂程度，用代码行估算），并在此基础上估算这种程序量下的测试、文档制作和缓冲时间，经过这样估算再做出的进度计划已经可以做到相当准确和细致了。实际上项目进度计划是一个由粗到细且不断调整的计划。随着项目经验的不断积累，这一问题也会变得自然。

　　同时，要确定经过一段时间（如一周）要将项目的实际进度情况与项目进度计划进行对比。对于拖延的工作如无充分理由，则应督促有关人员加班或提高工作效率赶上进度；如有正常理由，在无法追回的情况下可以修改进度计划，申请延期。在这一环上，作为与客户沟通的人员也要发挥相应的交际作用，为赢得项目的最终成功而不懈努力！

　　项目进度管理一定要细致和严格，像设计、编程这种难以量化的工作是很难笼统地去控制进度的。

　　项目进度管理是软件开发中最难以做好的一项工作，但又是不得不做好的一环工作。软件开发工作本身是一个难以量化的工作，再加上开发过程中对设计的修改等因素，使得项目开发工作经常不能按预计的时间完成，这是项目负责人必须在项目开始前意识到的问题。

http://www.ccw.com.cn/cio/research/hangye/htm2005/20050111_112BT.asp

    一项调查表明，大约70%的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20%至50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高。国内绝大多数的IT企业正或多或少地承受着“项目黑洞”的痛楚：项目无法按期完成、项目合作方的工作难以协调、用户需求经常变动、工作质量难以保证。很多企业常常抱怨说，我们的技术实力不比国外差，我们的员工也很努力，但是我们的产品和工作效率为什么总比不上国外？

    诸如此类的问题，就是当前软件开发中，实现项目管理实施时带来的问题。虽然，项目管理在土木工程中，项目管理在中国已经实施得十分成熟。但是，软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性。其问题的具体表现为：

    一、工期失控，计划失控。项目做多，往往会形成一种错觉：不按计划工期完成的项目是正常的；能按计划工期准时完成的，往往是不正常的。这说明，项目的实际工期和计划工期不符，是“家常便饭”。大多数工期延期，很少提前的。工期延期、失控，自然而言会导致计划无法执行；计划无法执行，成本就失控；产品就会变形．．．．．．

    二、项目前期多数出现“没事做”，后期“没人做”。在项目启动后，因为人员的配置，人员的衔接，硬件的配置，客户需求的确定性，一般会造成很多人“没事做”。而有些事是必须放在项目前期做的。前期不做，会对中后期有很大的影响。或者放到中后期做，会，要多花几倍的人力、物力。到了项目后期，会出现“虎头蛇尾”，大量的事情需要人来做，项目的人员又是固定的，其他人因为不了解整个项目，无法“空降”，则只能删除一些事情咯。这样就造成很多事情，没人做，后果可想而知。

    三、开发人员心态失控。延期，赶进度；晚上加班。还是延期，星期六也加班吧。还是不能按期完成，又到项目后期，只好封闭开发。平时晚上加班，星期六、星期天也加班。这就是很多开发人员开发项目渐进式的流程。不同项目的开发人员，只要问问对方是否加班，就大概可以了解到对方参加的项目的开发阶段拉。先抛弃加班对开发人员的效率的影响，对开发人员心态的影响才是最重要的。每个人都有趋利弊害的天性，开发人员也不例外。既然要赶进度，效率没有提高的情况下，要缩短开发时间，那只有简化功能，减少处理异常的情况，能把功能完成再说，等以后测试或用户哪里出问题再说。如果侥幸不出问题，那就没问题拉。这种情况下，当然希望测试的水平越“水”越好拉。哦，别忘了，测试也是开发人员的一部分。工期延期了，上面要求的进度又越来越紧，测试时间就更短，强度大，那只有有意无意去逃避错误，这样就皆大欢喜拉。

    这些共性的问题，就是项目管理所要解决的问题。只有解决了这些问题，项目管理水平就会得到质的飞跃！

http://www.javaeye.com/topic/18884

1. 计划的四个要素，以及衡量计划优劣的标准

计划的四个要素是：时间、成本、质量、范围。
1. 时间：从开始执行计划到最终达成目标所消耗的时间。
2. 成本：人力、物力等方面的投资成本。简单情况下可以只计算对计划的直接投资成本。
3. 质量：执行计划后最终产出物的质量，质量的衡量标准以计划执行结束时客户方对质量的要求为准。
4. 范围：计划执行后最终产出物的范围，从客户的角度来看，范围是一个百分数。例如某软件预期完成10个功能，但最终只完成8个功能，则范围是80%

衡量一个计划的优劣，主要有两种方式：
1. 执行前衡量：三个考查点：
 是否有足够的细节。
 是否足够真实。
 结合本组织的历史数据，根据经验预测计划是否可以顺利执行。

2. 执行后衡量：计划执行结束后，考察以上四个要素。通常，好的计划总是能够平衡以上四个要素，达到最佳的投入产出比。而不良的计划可能会在时间、质量或成本方面出现较大的问题。

2. 计划的制定

制定好地计划，关键如下：
1. 制定有足够细节的计划。
2. 制定足够真实的计划。

2.1 细节
通常，高层只会提出一个目标，而计划必须指出为了达到这个目标，我们需要做哪些工作。因此首先需要进行的是将各种为了达到目标所进行的工作细分，然后将细分的工作串联起来，确保其能最终达到目标。如果有可能，尽可能让下层的执行人员参与工作细分。上层先将工作进行大致的划分，然后将划分后的局部块分配给执行人员，让执行人员亲自进行估计。执行人员细化工作任务，需要细化到最细的级别，然后进行反馈。注意这里只是将工作细分，不要引入时间约束和资源约束。
特别的，如果制定软件开发计划，最好能够有详细的（比如MSF中的）软件功能规格说明书或详细的设计文档，足够详细的功能说明书和设计文档，可以使人们更好地估计工作量，进而产生足够详细的开发计划。如果对“要做什么”都没有认识的话，毫无疑问该计划会缺乏细节。
另外，如果一个企业如果有自己的SOP，则该SOP也是制定计划时的重要参考资料，应以SOP为基础，结合具体情况规划具体的工作步骤。

2.2 真实
细分工作时，需要考虑到真实的工作方式。真实即“按照计划的要求办事”（听起来好像很简单，呵呵）。对“真实”的阐述详见下文的案例分析。

例如制定一个子系统界面部分的开发计划，参考下面例子：
计划一：画第一个界面、画第二个界面……测试
计划二：画所有的Table，画所有的Form，画布局，添加远程事件，联调测试……

很明显，计划一缺乏细节，与真实的工作方式关联很弱，这样的计划，只能称作里程碑。采用这种计划，我们只有在到达里程碑指定的时间时，才能发现我们的进度已经提前或落后。
而计划二的细节非常充分，在任何一点，我们都可以得知计划的执行情况。而且更严重的是，如果开发界面的真实过程确实如计划二所指，在最初就要由一个人画出所有的Table、Form和布局，那么计划一指出的开发方式就会严重阻碍工作的进行，因为计划一的开发方式与真实的工作方式有很大的冲突。

上文反复强调真实这两个字，因为，如果以计划是否真的遵循现实中的工作方式为衡量标准，那么绝大多数计划都是不真实的。不真实的计划也可以达到目标，但是需要付出更多的成本或更长的时间，而且具有错误的指导意义。
有一件值得特别注意的事情是，当人们明白什么是真实的计划时，他们会拒绝写这种计划，即使它真的很有用。通常这是因为这样的计划会暴露他们的弱点，并且让他人了解他们工作的方式。在某些组织中，将自己的弱点和工作方式暴露在阳光下是致命的。但是，起码你可以制定自己的真实计划，并且只给自己看。

3. 计划的变更
在执行计划的过程中，不可避免的会有计划的变更。计划的变更非常重要，主要体现在以下几点：
1. 计划几乎肯定是不能符合实际的，对此要有坦然的心态。不断接受别人的意见，不断修正计划。
2. 客户方的需求可能会发生变化，此时就需要立即修正计划，以免到最后时刻才发现无法按计划实现客户已经变更的需求。
3. 己方的人员、设备等资源发生变化后，也需要立即调整计划。

Tech-Ed 2006 中国 http://www.microsoft.com/china/teched/agenda/session_bj.asp
的《软件开发项目管理 – 精华再谈》也颇有意思。

ThoughtWorks agile training in china http://www.thoughtworks.com.cn/press-releases/ThoughtWorks-agile-training-in-china.html
应该也是很有意思的东西。就是小一万的费用，比较咂舌。

网站开发新手笔记-持续改进实践：开发计划的改进 http://blog.youkuaiyun.com/ViktorYu/archive/2003/07/30/18992.aspx
颇有现场感。