很多刚刚转向管理岗位的人员，对于项目进度如何把控，往往不知所从。
关于进度，比较容易让人想到的是询问、以及要求写日报、周报之类的。
这些措施首先是不完全的。因为进度管理不仅仅是获取进度信息、更重要的
是还要核实进度信息。就好比说这一样个任务，你让某人去下载一个软件的安装程序。
你要的是Linux版的。等他下载完了Windows版的，指不定他就告诉你这件任务完成了。
其次，这些措施效率太低，试想一下，一个30人的团队，如果每个人进度你都去询问一般，那结果是什么呢？
况且，别人可能还嫌你烦。
另外一方面，一旦发现进度有所滞后，比如较计划滞后，或者某件任务可以花更少的时间时，
还要采取一些矫正措施。就是说，还要一定的控制措施。
比如，有一个测试人员准备测试一个Linux定时任务脚本。
我让他通报下进度，他说还在等待。那么，他在等什么呢？
因为他把他准备测试的定时任务设置为每2小时运行一次。
我对他说，把那个定时任务设置为每5分钟运行一次从测试的角度来看是否也是一样的效果呢（这个脚本所需的执行时间通常只需要几秒钟）。
事实上，我事先就料到他会那么做，所以特意及时要求其通报下进度。
另外，在安排项目计划的时候，就要把进度管理考虑进来。在项目执行过程中，还需要时刻关注进度风险。
IBM developerWorks上面有篇有关如何把控进度的文章，以作者的实际的项目管理经验写的。感兴趣的可以参考：
《敏捷项目管理实战之进度管理》：
阅读(...) 评论()软件测试（70）
移动测试（6）
自动化测试（9）
缺陷管理（3）
　　控制项目进度和质量首先在整体上要有一个合理清晰的流程，并且在整个管理过程中，严格按照流程走。流程的每一步如果都控制好了，那么整个就不会出大问题。
　　下图是我们应该严格遵守的流程。
　　需求是整个流程的入口。通常需求从客户那里来，而客户通常不是那么专业，客户发过来的需求可能很零散，甚至可能不合理，这时，需要对，并且多次不断跟客户沟通，保证正确理解了需求。
　　一个项目的必须只能是一个人——。相信很多项目都遇到过这种情况，客户好像跟有的开发人员很熟悉，有时候客户会把告诉开发人员，开发人员就自己做了，结果不知道。这就会出很大的问题。所以，不管来自内部还是外部的需求，所有的需求都只能经过。
　　流程-原型
　　原型用axure画，不管是web、desktop还是，都用axure画。目前为止没有比axure更强大的原型工具。
　　在我们的经验中，导出成网站的原型，可以作为很重要的一部分。所以，每一次需求的变更都应该首先体现到原型中，原型一定要一直维护下去。
　　画原型的一个最最重要的经验就是，要把所有的UI都体现出来。包括哪些呢？各种状态下的界面，所有的错误或者提示，也就是说凡是最终用户看得见的东西，全部要体现在原型中。
　　由于原型本身还是系统的一部分，所以，原型页面上也可以放一些业务逻辑说明，特别是页面跳转等。还有一些隐藏的也可以在原型页面上写出来。
　　原型做好了之后，就可以让UI团队开始基于原型做设计了。做好了就切图。设计团队的产出物为设计源文件、效果图和切图。放到里面供开发人员使用。
　　原型做好了之后，测试团队就可以基于原型写了。如果没有测试团队，这一步也可省去。
　　流程-任务系统
　　这一步是非常关键的，其中最重要的工作就是功能评估。功能评估建议用Xmind来做，评估好了再录入到我们的任务系统。参考：
　　如果不是项目所需技术领域的专家，那么在评估的时候，叫上领头人一起。但是一个好的项目经理，即使是自己不熟悉的，自己也应该有一个比较准确的评估。
　　任务评估时间还应该包含开发人员自测的时间。
　　当任务都评估好了，就可以录入到我们的任务系统了。录入任务系统之后，就是做迭代计划。
　　在我们的任务系统中，开发计划是通过迭代来做的。建议每一周提一个迭代，最多不超过2周一个迭代。开发人员只需要关心当前这一个迭代里面的所有任务，至于具体先完成哪个任务，如无特殊要求，都应该让开发人员自行安排或者给一些建议。
　　每一个迭代要求明确的开始和结束日期。一旦结束日期到，就应该把迭代里面未完成的任务移到下一个迭代。也就是说，迭代日期到，迭代的进度就是100%。对于有些只完成了一部分的任务，在我们的任务系统中，要么你可以拆分任务把已完成的部分拆分出来，要么你也可以把整个任务移到下一个迭代。
　　开发人员完成功能开发之后，首先要经过全面的。一个聪明的开发人员应该在的时候解决绝大多数。经过自测的产出物应该是具有很高质量的，特别是高质量的UI和UX。自测通过才能提交给测试团队，或者。做不到这一点的开发人员应该被淘汰。
　　自测完成之后，填写工时记录，将进度标记为100%，将任务状态标记为完成（不是关闭）。
　　流程-测试
　　如果没有测试团队，测试就应该由负责。
　　测试中报的BUG要提交到任务系统。测试人员提交BUG的时候不需要，并且也不。项目经理把所有未指派的BUG列出来，然后进行时间评估，然后再指派给某个开发人员。
　　也是属于迭代的。如果不是那么紧急的，可以暂时不安排到迭代里面，可以等到最后再去修复BUG。
　　流程-完成
　　测试团队测试通过，项目经理可以根据实际情况看是否需要再检查一遍。或者检查的力度到什么程度，这都由自行决定。检查通过，任务状态标记为关闭，任务完成。
　　问题 – 团队间等待
　　开发过程中，可能各个技术团队之间的衔接会出现等待。比如客户端开发的开发人员，在做到某一个功能的时候，结果UI设计或者还没有准备好，那么就只能等起。
　　这种衔接等待是无法避免的，我们只能尽可能降低等待的时间。我们是这样解决的：
　　在我们的任务系统中，我们会加一个任务标签，叫“紧急任务”。注意这里是标签，不是优先级也不是任务类型。一旦出现这种等待，等待的人就给被等待的人建一个“紧急任务”。如果等待的人没有新建任务的权限，那么交给其团队负责人创建。我们也建议你把这类任务同时放到一个任务分组里面，并且加个快速查询。
　　等待的过程中，开发人员可以用假数据或者假UI来代替，等数据或UI准备好后再替换。
　　问题 –
　　需求变更是任何开发团队都无法避免的问题。我们要做的就是把对项目造成的影响尽可能降到最低。
　　通常情况下，只有最紧急的才会放到当前的迭代，否则变更的需求都应该放到以后的迭代。如果放在当前的迭代，那么就需要把当前迭代中的部分任务移到下一个迭代。并且跟客户沟通好这个计划的改变。
　　需求变更时，一定要将需求更新到需求管理系统（原型和任务系统），不管变更的需求造成的工作量有多大。这一点是很多项目忽略的。举个例子，用户完成注册，本来系统送100金币，某天客户过来说改成送200金币，结果程序员就花了几分钟时间将100改成200了事。过了几个月，新同事加入项目，看里还是写的100，就去问，项目经理就说什么时候改成200了。于是这个需求管理系统就再没有人相信和使用了。所以这一点非常重要。
　　需求变更时，要按照本文开始的流程图一步一步走，因为是新的需求从流程入口进来了。
　　中经常还会遇到其他棘手的问题，扰乱项目计划，让失去了对进度和质量的控制。
　　本文转载自：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：26710次
排名：千里之外
原创：28篇
转载：66篇
(1)(2)(1)(1)(3)(3)(1)(1)(7)(2)(1)(1)(2)(3)(1)(1)(1)(7)(20)(8)(17)(5)(5)如何控制和管理好工程进度？
来源：网络
作者：佚名
工程项目能否在预定的时间内交付使用，直接关系到项目经济效益的发挥。工程进度目标按期实现的前提是要有一个科学合理的进度计划。工程项目建设进度受诸多因素影响，这就要求工程项目管理人员
工程项目能否在预定的时间内交付使用，直接关系到项目经济效益的发挥。工程进度目标按期实现的前提是要有一个科学合理的进度计划。工程项目建设进度受诸多因素影响，这就要求工程项目管理人员在事先对影响进度的各种因素进行全面调查研究，预测、评估这些因素对工程建设进度产生的影响，并编制可行的进度计划。然而在执行进度计划的过程中，不可避免地会出现影响进度按计划执行的其他因素，使工程项目进度难以按预定计划执行。这就需要工程管理者在执行进度计划过程中，运用动态控制原理，不断进行检查，将实际情况与进度计划进行对比，找出计划产生偏差的原因，特别是找出主要原因后，采取纠偏措施。措施的确定有两个前提，一是通过采取措施可以维持原进度计划，使之正常实施；另一是采取措施后仍不能按原进度计划执行，要对原进度计划进行调整或修正后，再按新的进度计划执行。
工程进度控制管理是工程项目建设中与质量和投资并列的三大管理目标之一，其三者之间的关系是相互影响和相互制约的。在一般情况下，加快进度、缩短工期需要增加投资（在合理科学施工组织的前提下，投资将不增加或少增加）。但提前竣工为开发商提前获取预期收益创造了可能性。工程进度的加快有可能影响工程的质量，而对质量标准的严格控制极有可能影响工程进度。如有严谨、周密的质量保证措施，虽严格控制而不致返工，又会保证建设进度，也保证了工程质量标准及投资费用的有效控制。
工程进度控制管理不应仅局限于考虑施工本身的因素，还应对其它相关环节和相关部门自身因素给予足够的重视。例如：施工图设计、工程变更、协作单位、相关主管单位等。只有对整个项目计划系统进行综合有效控制，才能保证工期目标的实现。
新项目具有规模大、复杂、周期长、协作单位多等特点，因而影响工程进度的因素很多。这些因素可归纳为人的因素、材料因素、技术因素、资金因素、工程水文地质因素、气象因素、环境因素、社会环境因素以及其它难以预料的因素。其中人的因素影响最多也最严重，从产生的根源来看，有来源于业主单位的；有来源于设计单位的；有来源于承包商（分包商）的；有来源于材料设备供应商的；有来源于监理单位的；有来源于政府主管部门的；也有来源于社会和各种自然条件的。现将这些因素归纳如下：
来源于业主方的因素
1、提供设计资料不准确，特别是地质资料错误或遗漏而引起的未能预料的技术障碍。
2、临时供水、供电实施不及时，供应量不足。
3、临时占道、施工占地不及时。
4、地上、地下搬迁工作拖延不能及时提供施工场地。
5、提供的图纸不及时、不配套。
6、因采用不成熟的新材料、新设备、新工艺或技术方案不当而修改设计。
7、合同纠纷引起的仲裁或诉讼。
8、承包商的材料、设备供货不及时，数量、型号、技术参数与实际所需不符，货物产品质量不合格。
9、业主方组织、管理、协调能力不足，工程组织不力，致使承包商、分包商、材料设备供应商、各工种、各专业、各工序的配合上出现矛盾，出现的问题亦得不到及时解决，无法按进度计划执行，打乱施工的正常秩序。
10、业主方的主要管理者和工程管理人员流动或工作岗位调整使有关工作出现无人管或无人知道从而影响问题的解决。
| 分享资料 |
Powered by}