项目管理之进度控制

1、工程管理之进度管理毕业至今，从事 IT 行业五年有余，参与的工程也十多个了。但作为研发工 程师对于工程管理这块并无较深了解， 只有一些个人体会和一些看法。由于 IT 产品更新换代较快，同类产品竞争剧烈，产品的开发周期就势必越 快越好。正所谓快鱼吃慢鱼，如果一个工程消耗两年以上，就算产品做成了，但 你已无市场可卖。所以我个人认为工程进度把控是一个工程成败的关键。所谓进度管理 , 可以从两个方面来理解 ,一方面是要制定一个可行而且高效 率的方案 , 而另一方面那么是要将此方案坚决的贯彻执行。1. 工程活动排序 , 或者说确定工作包的逻辑关系。活动依赖关系确认的正确 与否, 将会直接影响到工程的进度

2、安排、资源调配和费用的开支。工程活动的安 排主要是用网络图法、关键路径法和里程碑制度。2. 工程历时估算。历时估算包括一项活动所消耗的实际工作时间加上工作间 歇时间,注意到这一点非常重要。历时估算方法主要有 : 类比法,通过一样类别的 工程比拟 , 确定不同的工程工作所需要的时间 ; 专家法 , 依靠专家过去的知识、经 历进展估算 ;参数模型法 ,是通过依据历史数据 ,用计算机回归分析来确定一种数 学模型的方法。3. 制定进度方案。 制定进度方案就是决定工程活动的开场和完成的日期。 根 据对工程内容进展的分解 , 找出了工程工作的先后顺序 , 估计出了工作完成时间 之后, 就要安排好工作的时间

3、进度。 随着较多数据的获得 ,对日常活动程序反复进 展改良, 进度方案也将不断更新。对于工程管理者 , 要其在工程初期就预见整个工程的一个准确的时间周期 , 恐怕是一件不太现实的事情 ; 但如果是一位拥有非常丰富的工程管理经历的工程 经理, 他根据以往工程的信息估计、 结合工程自身的特点 (包括工程的范围和可利 用资源状况等 ) 制定出一个基准方案也不是一件太难的事情。估计工程开发周期 的一个最经典的方法是 :根据所有相关的信息 ,分别估计出乐观工期 (To) 、悲观工 期(Tp)和最可能的工期(Tm),然后利用公式期望工时Te=( To +4Tm+Tp)/6得出基 准方案的时间。外表看来 ,

4、 作方案和考虑问题的时间占用得多了 , 但实际上 , 从总 耗用时间量来计算 , 却节省了许多珍贵的即压缩流程的时间 , 最有效的利 用了每个时间单位。安排好了的进度方案需要进展优化 , 网络方案技术是一种科学、有效的管理 方法, 是工程进度控制 ,特别是负责工程进度控制的完整的方案管理的理论根底 , 利用它可以优化整个工程的进度方案。绘制进度时间表常用的网络方案技术方法是甘特图法。 它是以横线来表示每 项活动的起止时间。 甘特图的优点是简单、 明了、直观, 易于编制 , 是小型工程中 常用的工具。优化进度方案的一个常用网络方案技术方法是关键路径法 , 工程是 由各个任务构成的 , 每个任务都

5、有一个最早、 最迟的开场时间和完毕时间 , 如果一 个任务的最早和最迟时间一样 ,那么表示其为关键任务 , 一系列不同任务链条上 的关键任务链接成为工程的关键路径 ,关键路径是整个工程的主要矛盾 , 是确保 工程能否按时完成的关键。实时进度信息的获取与完成度的检查是工程管理者工作的重中之重。 提高进 度信息的获取频率可以尽可能早得发现进度障碍，为消除障碍争取了最大时间， 从而有效减低进度风险。举个例子 ,xx 工程经理向他的组员分配一个任务， 然后他不定期得检查这个 任务的进度。 可是每次他检查进度的时候， 他的结论都是这个组员的工作成果没 有到达他所期望的， 而这个组员却是认为自己已经完成了

6、当天的任务。 这种情形 导致这种组员不断得为返工而加班， 最后导致其身心俱疲， 提出离职申请。 事实 上，这样一个问题产生是因为任务的分配者和执行者事先没有约定好什么叫做 " 完成" 。双方都只是在依照自己心中的 " 标准" 来判断是否完成，从而导致了对于 进度认定的冲突。可见，在我们断定一个任务是否完成、 进展到什么情况前， 首先要规定什么 叫"完成" ，否那么就会在衡量进度的时候产生上述例子中的冲突。 这种对于什么 才叫做完成的规定就叫做完成的标准。 显然，进度不能在脱离质量的前提下孤立 得衡量，因此完成的标准不仅定义了质量要求通

7、常是最低质量标准 ，也是进 度衡量的重要依据。比方，如果你让一个没有什么工作经历的人去安装一个数据库管理系统DBMS,他很可能就是把安装程序执行一遍，假设执行过程中没有遇到安装程 序提示错误就认为是完成了软件的安装。 而最后，其他人都不知道这个已经安装"完成"的软件的访问信息， 比方它所在机器的 IP 地址、侦听端口。 甚至知道了 这些信息后，在实际使用时却发现所安装的软件根本就无法正常运作。其实，对于这样一个任务我们可以定义一个完成标准： 所安装的DBMS要经 过验证比方使用 SQL 能够在数据库中插入一条记录， 并能够使用相应 SQL 查 询到插入的记录，并输出软件的相

8、关使用信息如软件所在机器的 IP 地址、 软件的侦听端口。可见，完成的标准不仅定义了质量要求通常是一个最低质量要求 ，也定 义了任务所要交付的产出物。 完成的标准所定义的产出物和质量要求正是评估任 务进度的依据。 一个任务在整个团队中有了一个大家一致认同的完成标准时， 任 务完成的质量和进度的衡量才不会出现冲突。从工程开发成员的角度来讲， 由于团队开发中的每个团队成员的日常工作 之间都存在或多或少的依赖关系： 某个人的工作要以其他人的一件工作产出为输 入，同时其工作的输出又是另一个人的某件工作的输入。进度信息是将团队成员的工作自主得衔接起来的重要因素。 因此，敏捷开发 团队中，进度不应该是只有

9、工程经理才关心的事情， 而是整个团队成员都应该关 心的事情。但事实上，团队成员往往倾向于只关心自己手头上的工作。因此，工 程经理需要引导和鼓励团队成员主动关注自己手头上的任务所依赖的任务的进 度。进度是整个团队应该关心的事情， 这就要求在团队内有一个统一的进度信息 获取与发布的平台和途径。 这个平台可以是一个管理软件， 比方工作流软件。 也 可以是一个即时通讯软件。 不管采用什么样的平台， 工程经理应该引导和鼓励团 队成员主动将各自的进度信息推送到这个平台， 而不是每个人进度还要等其他人 来询问。站立会议也是进度信息的发布和获取的一个常见途径。 站立会议中， 每个团 队成员都要介绍自己昨天完成

10、了什么， 今天方案做什么。 这样， 每个人的进度信 息都可以让其他人了解到。但是从我个人的工程经历来了， 大多数工程完成时间都滞后于预期， 有些甚 至返工重新来过。工程目进度的滞后的主要原因， 往往是工程的需求、 本钱变化，以及对工程风险分析缺乏1. 因为对工程的范围没有做相信明确透彻的分析和定义，致使工程在执行 当中作了许多额外的工作。 工程管理者对工程的范围未作深入细致分析， 未和相 关责任人做详细讨论，或未作明确说明和定义，就开场启动工程，而埋下隐患。 有些工作的内容可能和工程的目标并不一致， 只是技术人员处于对技术完美主义 的追求而画蛇添足， 自作主张增加补充功能。 而工程管理者却没有

11、发现， 或者没 有意识到这对工程的影响。2. 因为对工程的所涉及的资源、环境、工具等的本钱分析不够完善准确， 致使工程实施过程中遇到资源、环境、工具的限制，而不得不以时间作代价。3. 对于工程的质量不够重视，或者说不具备质量管控的能力，导致工程执 行过程中不断出现质量问题， 活动安排时序局部失控或者完全失控， 工程进度管 理方案形同虚设。工程进度失去控制。4. 把风险分析作为独立要素考虑而不是贯穿在整个方案分析之中，导致风 险分析及预防与工程方案之间脱节。 许多工程的风险分析并未引起工程管理者的 足够重视， 只是做作样子给上级看看而已。 工程风险的管控能力其实更多的表达 工程管理者的专业素质和

12、从业经历。 许多风险之所以不能被预先识别， 或者给与 足够重视主要原因是受制于工程管理者的个人能力。 然而，给与工程进度影响 最大的就是“风险。之所以这么说是因为许多问题“没有想到嘛！ 因为工 程管理者想不到的事情太多， 因此工程实施过程中的意外问题接踵而至， 不断需 要应对这种所谓的 “风险。 细细想想， 我们所经历的工程中有多少风险是真正 意义上的风险？ 工程管理的疏失造成的意外比比皆是。 当然如果遇到真正的风 险，那后果只能说是不可想象了。5. 关于对工程进度影响的主要因素中还有一个不经常为人所重视的就是 “工程组成员的职业素养。 工程组成员的职业素养包含两个方面 “专业能力、 “职业精

13、神。现在许多工程中的成员的专业能力虽然不强但也勉强能够满足工 作的要求， 但是职业精神却差的一塌糊涂。 之所以有这样的见解主要是因为这是 整个国人的通病。 在工程中真正专注于自身工作， 对工作精益求精， 对自己的质 量、自身形象负责的成员少之又少。工作不认真，都是想法往上混，各种投机取 巧应付的手段都在用。6. 我们在从事着最现代化的劳动但是却远远不是现代化的从业者。 这种职业 的素养，最终导致的结果就是：遇到问题，不设法解决而是相互推诿；眼睛只是 盯着考核指标和领导的眼色， 而不是履行职责； 工作的目的不是为了承当好职责， 做好与其他成员的相互协作， 完成共同的目标， 而是如何能够表现自己。

14、 对于这 样素养的团队如果能够有完备严密的管理， 或勉强可以维持， 但对我们现在许多 软件企业的管理水平来说， 确实很难驾驭队。 身处这样的环境， 或参与这样的软 件工程，我们不能不深思。 改变这种现状的途径或许很多， 但是就工程管理自身 而言，还是需要合格的工程管理者来通过自身的日积月累努力， 逐渐改变。 就这 个行业现状而言， 对于合格的软件工程管理者的期待是广泛而迫切的， 只是工程 管理者自身对自己的期待有时过低，从而不能不说是令人失望。对合格的工程管理者的素质要求论述的文章很多， 但是我个人以为最核心的 有以下几点，简单列举一下：1. 工程管理的知识。 能够对工程管理所涉及的知识领域有比拟深入的了解， 并可活学活用。2. 个人职业素养。专业的能力，专业的精神。自己做不到，就很难要求别 人也做到。这一点最难。3. 组织和沟通能力。即便是最顽劣的人也是向往光明的，关键如