软件项目进行有效时间管理的方法

IT项目最大的问题就是拖延，有哪些原因可能导致拖延，有什么好的方法解决？

48 个解决方案

#1

难得zhaoxichao (小西)前辈问问题
呵呵

以下是新手经验
不当之处
万望指正

哪些原因可能导致拖延？
1。项目草率上马
2。任务不紧迫
3。领导层不重视
4。开发队伍不稳定


方法解决：
我个人经验认为一个强有力的leader是至关重要的

#2

是这样，如果我是一个项目经理，发现项目进度落后于计划（计划假设是合理的）
我想有一个这样的checklist，能够检查出通过什么现象可能反应出现落后的原因，有什么方法解决
比如项目成员很喜欢上QQ，原因是不了解自己任务计划完成的时间，采用的方法是提醒成员任务完成时间或者禁止上QQ

希望大家献计献策

谢谢竹马，不过你说的这些原因，感觉太抽象，解决方法也不是很现实，一个强有力的leader能保证领导层重视吗，能保证项目不草率上马吗？很多是项目经理不能控制的

#3

如果发现项目进度落后于计划, 就应该及时报告你的直接上级,并给出一定的原因分析和解决方案, 比如某个模块开发者需要技术培训,解决方案为增加人手,或实施相关的培训,申请计划变更等... 千万别拖着到最后期限了才说出来.

#4

这个好像不是问题，是一个经验整理。
把大家在项目中出现的影响项目进度的问题都列出来？
我先列一条：
1、项目中采用不熟悉的技术。

#5

呵呵
受zhaoxichao (小西)前辈批评了

我的上述观点主要是来自我的工作经验
我的上一个项目就延期严重
其中项目组长对项目的控制力较差是很重要的原因
包括对领导的资源请求、组员的行为约束等等
所以我很看重leader

#6

no suddenly delay, only daily delay.

#7

我觉得就是应该将任务分解详细些，在布置任务时要具体到项目组的每个人，要有具体的完成目标和时间约定，并在分配时征求每个人的意见，若任务分配不当可以及时调整。一但接受了任务就要按质，按量，按时完成；项目经理做好时间调度表，及时检查每项工作的完成情况。如通过周报或周会的形式进行了解和沟通。
建立各种制度可以，但不能太死板，否则会影响大家的工作热情和积极性。鼓励大家在按时完成任务的前提下，适当的进行放松，但不能影响项目的进度。

#8

总结一下
1，项目中采用不熟悉的技术，这时应该进行评估，评估采用改成别的技术影响的范围、可行性和风险等等，如果还是用原来的技术，可以采用培训、聘请项目组外专家或者招聘的方法
2，任务计划和分配，将任务分解详细些，在布置任务时要具体到项目组的每个人，重要的是进行跟踪，用周报和周会形式对进度进行跟踪
3，缺少资源，争取高层的支持

还有什么吗？

#9

重要的是提高项目管理的可视化程度。 作为项目经理必须了解“真实的”进度。 由很多方法，关键是要坚持。 推荐一个就是：持续集成

#10

4，及时进行系统的集成，了解真正的进度

#11

项目总是因为各式各样的原因，会比原计划的时间拖后30%左右。同时，我感觉，推动一个项目的开始和项目的最后收尾都是比较困难的。

那么，对于这样的情况，我建议的方法如下：
1）实际计划时间应该在原计划的时间上延长30%左右；
2）项目开始之前，尽可能做更多的准备工作，项目开始，需要PM推动项目真正进入状态
3）在项目的后期，往往觉得还有很多事情都没有完成，这时候需要尽快决定是否该结束
   项目，需要结束的话，肯定要砍掉一些东西，或者放弃一些东西。

#12

个人感受:
项目拖延的原因:
1.项目目标不明确.
2.项目在某一个阶段失去控制:比如测试阶段,研发经理失去对项目是否应该结束测试,做出决定.
3.计划不细,目标不可见,再加上监控不力.导致项目日日拖延而不知道。

至于采用技术风险或者人员风险,我个人感觉不明显,因为在一个项目中,不应该让那么多风险加入进来.

对于以上三个问题,我的解决方式是:
1,在项目前,明确定义项目产品形态:项目是什么,不是什么,包括什么,不包括什么,尽量削减其中的灰色地带的东西.并通过快速原形和频繁的沟通,降低客户的期望,使得客户尽量早期知道项目到底出来是什么东西.
2.项目失去控制,这个时候,需要明确时间计划,我出现过类似问题就是因为不能明确估算测试完成的里程碑到底是什么,于是,在测试阶段,项目失控.对此,主要通过明确相互之间的责任,让测试(或者其他任何部分)人员,提出可见目标.按照计划推进
3 至于说计划不细,监控不力,就是控制问题了.计划本身就不细,不明确到人,计划时刻调整,计划目标不可见,都是导致大家对计划不重视和计划不断被拖延的原因.这需要的就是项目管理人员的时间计划能力和监控力度问题了.如果计划目标是可见的,如果计划是足够细的,那么监控就是一个责任心的问题了.

至于放弃什么还是抓住什么,就看前期的产品形态定义做得如何了,如果做得不好,也存在一个大问题,而且这些东西不适合老是采用,不然大家会形成一种共识,在项目前期,就觉得有一些功能是可以不完成的.那你还能一个一个解释,什么是可不完成的.这只是一个权宜之计,不适合作为解决方式.

#13

你们说的都很有道理。
本来我这一个月都会在作公司一个产品的测试工作。
在上个月我自己做好了schedule，并且里面有考虑到常规的其他任务需要花费的时间，并且划分了4天时间给突发事件。
这份shedule在开发组leader和部门总监处取得了一致。并于本月初开始执行。
但是1周半以后，也就是我刚刚写完case后，来了突发任务。在部门总监看来这个任务优先级很高。从那以后一直到今天，我还没有切换出来。
开发组leader有苦难言，他急需测试结果，但是不能说话。
我也不确定会不会有其他突发任务。

这大概就是zhf_karen所说的失去控制。

我想，一方面这是因为我们没有对如何应付突发事件作详细的准备。
另一方面，我们本身没有明确的分工。没有对每个角色的责任义务权利作specification。
我猜很多公司都会有这样的情况吧。
不管看似如何漂亮的plan,很容易就被打乱了。

#14

谢谢楼上各位
现在换一个角度思考，怎么节约时间
比如我们项目组每周的周会采用站在茶水间的方式（记录员坐着^_^）,并且时间定在周一下班前，这样尽量避免了开会时间的失控

希望大家分享一下经验

#15

对节约时间的个人经验：

在遇到一个阶段性大问题的时候
我喜欢和相关人员
跟着技术支持人员
到一个穷乡僻壤的地方
找个破招待所
封闭式讨论问题
这样的时间效率会高很多很多
缺点是经费成本略高

#16

节省时间的方法有很多。
处理的原则就是考虑一下这件事情，是否对项目有利？是否真的推进了项目，是否还有其他的解决方式：
举例来说：
你开项目例会的初衷是什么？团队激励？还是目标清算？如果是目标清算，需要把所有人拉到一起的情况只有一种：这个团队中的成员难以管理（比如资历都比较老了，级别都比较高），你难以用比较严厉的措辞来催促工作的进行，那么使用团队的压力，促使工作推进是个不错的方法。但是如果这一切都不存在，而且项目没有发生异常情况，就没有必要开项目例会了。毕竟需要了解项目进度，从项目可见的目标和VSS库中最容易看见。而且目标如果没有改变，也不用通知大家下周应该做什么。等等，这可以通过邮件系统来完成。

再比如，从大的方面说：在开发人员和市场之间，和高层之间建立一个屏障，免得没有思考成熟的想法，直接灌入团队，导致目标的不断漂移等等。

当然了，其实开发人员不像流水线工人，节省了那些时间也未必能够带来效益，但是，只是通过这样一系列方式，替大家建立一个平和地，适合开发地，稳定的环境。这样效率好一些

#17

  计划的时间最多只能站项目真实时间的2/3；

   一个强有（能）力的Leader至关重要；

   如果项目周期过长，必将导致士气的低落；长时间的加班，必将导致效率的低下……怎么想办法提高士气，提高效率；

   越大的项目越容易失控，而且容易形成诸侯割据各占一方，每人独霸一块，导致进度失控，质量失控，从而最终导致项目失败；

   非常时期——如果是阶段性的突击，可采取强势的管理办法，如禁止QQ，MSN等甚至截断通讯的封闭……个人认为对技术人员的管理还是已引导为主而不适合强势，这种办法不可滥用，易导致抵触情绪的出现；

  经常进行模块的集成；

  必须有固定的交流时间，技术人员怕冗长无聊的会议，建议用站立方式，主要已进度汇报与技术困难为主  ；
 
   项目初期对项目的设计需求确认等，最少各采取一次头脑风暴的形式，各类人员都参与；

    ……
    金钱的刺激永远是有效的 ：）

      
   

#18

我想每周的例会还是必要的，因为需要让大家了解项目的整体进度情况，同时通过分析原因和总结经验，还能够起到相互促进的作用。

许多项目由于商务原因，从签订合同那天起就注定是一个无法按期完成的项目，这是外部环境的现实存在，一个好的PM应该能够顶住压力，制订可以执行的计划，并保证按时完成。同时，通过适当的激励措施，促进项目提前完成。

另外，对于促进计划按时完成的技巧上，可以采用明确目标，逐级验收的方式进行。对于工期较长的任务，还需要加强任务中的监控。对任务的划分上，要体现任务对项目的贡献价值，例如：终极目标是项目成功验收，而不是程序编写完毕。这样可以避免项目后期增加未知的风险。

此外，还应加强项目组的培训和经验交流，使得项目成员能够通过项目成长。当然，与日常培训的侧重点有所不同的是，内容主要集中在本项目范围内，目标是解决项目存在的问题，当项目存在大量技术性问题的时候，就应该考虑调整计划，预留时间。

#19

呵呵，我的意思并不是说一定需要取消项目例会。但是，你必须明白你开项目例会的目标所在，比如了解项目整体进度，那么可以通过项目管理工具就可以随时得到；明确谁完成了什么，什么没有完成，这也没有必要，目标就在那里，完成的东西可视，自己看吧。

项目例会的意义在于协调资源，比如由于多个部门系统工作的项目，协调步伐，协调资源，这些不能通过邮件系统，或者工具很好解决的问题（比如外部资源协调组告诉你，客户的一个特型机难以按时到达，那么会对谁造成影响，如何排除）等等，这些才需要通过项目例会来协调完成。

综合一点来说，就是：知道你自己是协调者，而不是监工。
当然，在实际工作中，我们还是会经常使用项目例会制度，这是因为人不完全是理性的，有时候，一些感性的交流，更适合项目推进。

我认为为项目组节省时间的时候，眼睛要往外看，象一个谐波器，屏蔽各种冲突尖峰，在项目进行过程中，尽量减少对项目组人员的干扰。这才是最大的时间节省。

#20

最容易導致進度延誤的應該是需求變化
因為需求不是由開發人員掌握主動權
在客戶手裡

#21

to  windsoft(風寒葉殘) :
不对。需求分析总有个头吧。跟客户签字。凡是签字以后，再要改动的需求，客户都必须接受因此带来的拖延。

#22

大家有没有那些不是书本上的大道理，自己总结的一些小技巧？

#23

我不爱看书。

#24

如果进展的按排合理，那原因应该就在于项目实施当中，我的团队当中没有不允许上QQ或者不能聊天等等。
我感觉行之有效的方法就是公开化，让团队当中的每个人都互相了解别人在干什么，清楚的知道自己这个月应该完成什么、这个星期的计划应该怎么按排、具体到每一天应该去完成自己所按排的计划。
作为项目经理就是要每天早晨开半小时的会议，让大家讲一下昨天干完了什么，有没有什么好的经验让大家共享，无形当中成为了一种相互的监督、共同进步。
这是我在项目当中所运用的方法，非常有效。
在这种情况下如果进展按排合理，一般是可以按计划完成的。

#25

员工的工作热情很重要，如果大家都斗志高昂，众志诚诚的话，很多问题都可以解决的。
毕竟：
1，计划跟不上变化，计划无论如何周密都是有限的。
2，不能过于依赖项目经理的水平，一个项目组可是一个团队。
所以，在金钱刺激的情况下，企业有必要加强企业文化的建设。

#26

在项目管理过程中，有没有什么好的工具来对项目进行管理，比如：项目的开发计划、开发进度、开发过程中的完成情况、及设计需求的变化的跟踪管理的方法或软件？

#27

需求不确定、分工不严密、目标不明确，怎么解决合理呢？
我们公司现在排进程都是根据交货时间在拍脑袋：（

#28

同意dragongong(中国龙) 的一句提法：“许多项目由于商务原因，从签订合同那天起就注定是一个无法按期完成的项目”。

做项目的时间管理不光是项目组的事情，而是整个公司的事情。而事实上，经常的情况是：最磨蹭时间的未必是项目后期的开发、测试阶段，而是项目前期拖的时间太长！要么是老板迟迟不决定是否做这个项目，要么是迟迟不决定这个项目具体做什么，或者是必须的设备、工具、外包部分迟迟不决定引入，还有迟迟不定项目的需求、规格说明书等基础性的东西。似乎决策者“日理万机”，而真正他做决策时，往往大好的时间已经过去了！
而且，决策者制定的最终期限有没有真正考虑该项目的具体实现所需要的时间？我看有很多就是他认为应该结束的时间，从这个意义上讲，项目无法按期完成就是必然的了。
我想改正的办法还是有的，而且关键需要从决策者入手，在定决策的时候，应该提前请实际的开发、测试、文档编写等部门专家介入，看看完成这样一个项目各部门到底要花多少时间，同事要求这些部门专家对自己的评估负责，而只有这样定下的deadline和milestone才是具有实际操作价值的。
当然，在理想的情况下，即使计划的订立是慎重的，在项目的实际运行中，还是会出各种问题，这时，及时的项目监控、协调就很重要了。

#29

去禁止程序员做什么是不实际的。

#30

总之，在软件开发过程中有很多突发的事件，它的过程之所以难控制就是因为它不是固定的，不的项目可能采用的方式不同。我觉得在做计划和做工作的时候，给突发事件预留时间，尽量减少一些突发的事件，比如说在需求方面的经常变更，我觉得还是有办法做到减少，杜绝是不可能的。

#31

这主要是关于软件项目的管理
主要还是对人员，产品，技术这些方面的管理
有哪些原因可能导致拖延，主要还是在以上的这点没有管理好。
我个人觉得项目拖延的原因太多太多了，
我曾做过的一些项目中，就总结过项目拖延的原因：
1.没有正确的标识出需求定义者
2.如果使用原型方法对项目具体做什么，有个更完整的了解（可惜那时，我们太急于实现了)
3.由于1的原因，项目注定改了又改，因为不清楚谁是真正定义需求。
4.需求方对系统将要实现什么也没有明确的定义
5.采用新技术，需要解决的问题很多很多（不过这对于日后的项目开发还是带来好处）
6.也是由于1的原因，系统需求的重点偏移了
7.多人开发各自的系统，对于后期的整合出现了麻烦(对各个子系统的依赖，关联没有定义好)
8.需求方也有独立的系统，也需求挂进来，这在项目开始时并没有包括在里面。。

以上都是导致本人曾经历的项目拖延的主要原因，其中核心的是第一个。
出现这个的原因也和*部门有关系（项目是给*部门做的）

关于解决的方法:
对于1，定义好需求标识者
对于2，原型方法是对未曾涉及过的系统，无类似经验时，最好用原型方法准确获取系统需求。
对于3，同解决方法1
对于4, 尽量的让需求方说出真正的需求，但这里的需要太多的技巧了。
对于5，可以找些顾问，或者有些经验的朋友等帮忙
对于6，同解决方法1
对于7,一个是由于1的原因，还有一个是需求分析,系统设计没做好
对于8,和需求方进行有效的沟通非常重要

#32

我从Tech-ED上学来的
1。事前充分估计可能的变化（主要是类型）
2. 对变化做详细记录

这样，有东西给客户和领导看：喏，这么这么多原因我才没法及时完成的

#33

客户和领导是不关心原因的，只看结果，试想每个领导都关心项目里的每个细节，
那他还能干什么决策方面的事。
我认为项目要按计划完成，
1。必须计划做得细。
2。尽可能多的预测到项目的风险。
3。对项目组成员的能力有充份认识。
4。多检查跟进项目进度
5。发现有苗头，立即处理，调动成员积极性
我最近，做了个小项目，系统分析设计都搞完后，再做了个编码计划。
其中有一个成员的任务没完成，不是计划不合理，做计划时还和他沟通
过，他也同意，但到后来，他只做了一道程序。最后项目延期很多。
写代码过程中，我知道他没做，崔他也没用，他说其它事耽搁，因为他是
开发部经理助理，又是老总的人，我没辙。还有一点是，我不了解他的能力，
实际上给他的时间可以完成两倍的工作量。

#34

  我的看法，请大家参考。

    在项目开始前，肯定有很多是不可预测的东西，比方说没有想到用户的要求原来是这样，没有想到某个关键的程序员跳槽，没有想到某个技术点根本不能在这个系统中使用，等等。如果这些没有预测到的内容占整个项目比率很大的话，那就很有可能导致项目延迟或者失败。
    要解决这个问题是尽可能的细化这些不明确的内容，同时对于有可能出现的情况来做好预防措施。比如技术储备、规范用户需求的变更，加强同程序员的沟通、金钱的刺激等。
    还有一点是在做SCHEDULE的时候要留有余量，这样可以缓冲某些危机。
    另外对于突发事件我们有时候采取突击的方法（如封闭开发）来解决也是一种 很好的解决方法。

    完全对项目的所有问题预先全部把握是不可能的，而对这些问题的把握程度取决于项目负责人和项目成员的综合实力，以及整个公司各方面的因素。

    一孔之见，请大家指点。

#35

我没有做过什么项目，只是提出自己小小的看法。我认为提高一个团队的工作效益是主要有以下几点：
  1。责任明确、分工合理
  2。了解团队中每一成员的技术含量、强项及偏好
  3。了解团队中每一成员的心理
  4。增强团队成员的时间观念
  5。做好与客户、上级领导、团队成员的工作交流

小小建议，请大家多多指教。

#36

呵呵.各位说的很有道理.就合同而言,商务却是一个问题.不过对于一个合格的项目经理而言,如果在做时间计划的时候发现时间的不可行性,应该通过商务,销售同客户进行协调.价格也是一样.要保证项目的时间基线,一般情况下取决于工作包的分解.分解的粒度可以按照80小时记,也可以按照40小时记.粒度合理,对于时间的计划的实施越精确.即使出现某个工作包的拖延,解决也是较容易了.对于关键工作包,这方面的进度要求必须得到资源的保证.同样,软件开发的时间记录是公司的重要财富!对于一个新项目的实施有重大的参考!应该将粒度和时间进行记录.作为参考.其次,里程碑制度是很重要.甘特图可以作为这样的工具.而就我的看法,客户的需求的挖掘不是很彻底(也就是我们经常抱怨的:需求又变了)是项目的时间变化的主要原因.而客户的需求变化一般在验收前后,如果和客户的级别存在诧异,这是最难把握的.所以,建议建立一个变更控制委员会以及变更控制基线,这样,即使产生变更,也会得到有力的保证.

#37

所谓落后或提前都是与计划相比，如果计划不合理，那比较结果会合理吗？

计划怎么合理？你如何计算出开发一个功能需要的时间？

拖延并不代表失败，超前也不代表成功，应该在某一个时间和空间范围内与其它项目进行比较而论，重要的不是拖延了多少，而是真正理解拖延的根源，充实自己的经验和判断力，下一次做得更好：）

#38

个人实战中的经验


1.会议前做好会议准备,解决问题或达成共识后马上结束,这东西成本太高.任何管理会议(包括评审)2小时内结束,而且不占用业余时间.这样才会保证会议的质量.
2.一直不喜欢强行约束开发人员的行为,还没找到一个可行的办法.只要任务单他们可以按时按量的结束就行了.
3.对于热情较高或能力比较强的人会让他们参加训练营,也就是公费的培训或考证.以激发他们的表现欲望.
4.定期(2-3月)由考评小组进行绩效考评.网上下的考评表.主要是技术性方面;对公司及工作态度方面;个人品质方面;人与人相处技巧等大类.强项奖励,弱项不会进行任何负激励,由他的直接领导监督整改.下次评估没有改进就该处理了 :)

#39

项目管理可预见的问题非常多，何况还有许多不明因素，需要
leader来统筹这些工作。当然对他的要求比较高，他得技术出身
又熟悉人事管理和企业运转，能够熟悉开发流程，把握工作进度，
能发现日常问题并解决在萌芽状态。

而对于员工，开发日志和例会是必不可少的。日志和例会周期得
视项目而定。但个人认为一天一次也没有什么不行的，因为日志
是工作进展文档，而例会可以明确目标并调动员工积极性。

#40

偶的办法：
把项目截止时间提前

#41

hao tie

#42

说了那么多方法和原则．．
我们也应该总结一下
同时，我认为一个有力的工具，也能为项目管理带来高效的收益
请大家聊聊有关软件生命周期内，大家所使用的管理项目的工具
本人接触的较小．．
Microsoft Project 
Rational RequisitePro
Rational ClearCase

#43

离题万里。。。有人在讨论时间管理吗？

实际上这个问题很简单。项目延期的原因在于项目经理没有正确的估计两个因素：
1。工作量，主要指标是代码规模，以千行记。
2。生产率，工程师单位时间内产生的代码行数。

这两个因素之间的关系，只是简单的小学算术。但是就目前的工程水平，没有人能够独立作出精确的估计。解决的办法只能靠经验数据的不断积累。许多大型的公司都维护着庞大的项目数据库，记载历史上完成项目的程序类型、生产环境、工作量、生产率等参数，管理人员根据这些历史数据，利用经验公式，计算当前项目的参数。他们也区分工程师的工作时间和有效任务时间，测量统计工程师的工作环境对他的生产率的影响。这些都是每个项目经理必须要做的工作之一。我想，这些才是时间管理真正的意义。

软件工程是门科学，科学结论需要数据的支持，而数据需要通过实验来获取。如果没有这些数据，不做这些实验，项目经理可能作出正确的估计吗？而目前国内是没有一家公司这样做的，然而他们却的的确确在估计项目时间，讨论各种管理方法和控制手段。是不是国内的项目经理都是善于建造空中楼阁的神仙呢？这么简单的道理，为什么没有人想到呢？呵呵，我又想起了胡适的寓言中那个总是在画建筑蓝图的中国人。。。

#44

嗯，的确是最常见的问题，我也遇到很多次。
以下纯属个人意见，各位大虾发现不妥之处还请多多包涵啊：
1，规划设计的阶段一定要尽可能的详细。
2，随时进行监控，成立项目进度控制小组包括各个部门的人员，人数10人左右，进行进度控制，解决拖延的问题和预测可能出现的问题。
3，打出富裕空间20%。这个大家都知道的啦。
4，根据具体影响进度的问题来进行处理，尽可能的迅速发现，迅速解决。
5，无论对员工还是用户尽可能细致的为他们设想更好的开发和使用的环境。
其它的就是根据不同的项目和公司具*定不同的制度了，我也不能很清楚的描述出一些细节。

#45

补充一点：
6，对计划变更进行严格控制，一旦进入开发阶段功能不能增加只能减少，所有更改必须进行评估，大改动需要用户协商。

#46

我也没有做过，想到一点不知道可行否？
就是由项目经理或者说个人把每个人的分工尽可能细化，贴到墙上或者黑板上，每个人做完了一件工作，就在上面打个够或者画个小红旗，表示当天/周的任务完成了，这样在任务和时间上就有一个对比，比如时间过去了50%，完成的任务才40%，那就要加快进度了，否则就可以尽情的上一下qq,让他松弛一下，准备接下来的工作。

#47

我目前在试运行做法是：
1、项目主管必须做项目总体进度计划
2、项目主管必须每周部门经理（专门管理项目的）上报项目周报，详细说明未按计划完成的
   原因，部门经理根据实际情况进行协调，周报的格式一进度计划挂钩上，对于本周的执行
   情况要描述清楚，小组情况如何、对客户情况说明、重大或疑难问题要反馈。
3、项目主管对项目组成员进行详细的任务分配（可能集体到日），每周进行跟踪，检查组内 
   成员的进度情况。
4、做阶段总结（组内所有成员）
当然还跟一些制度配套执行，目前对项目的跟踪很清楚，项目也基本能按时完成

#48

1）最终确定的计划时间最好能比理论上的时间多出30%-40%，这样留些后路。
2）在项目开始前，最好把准备工作做的详细些，越详细越好
3）在项目进行中，一定要严格按照计划进行，不要随意改动
4）在项目收尾阶段要果断，不能思前顾后。