UML软件工程组织

控制工作经常是很事务性的，人们不愿意做有规律的坚持。如果用一句话表达控制的重要性，不妨一问：控制的反面叫失控——谁愿意自己的项目失控呢？

什么是控制

曾有人在谈到什么是管理的时候说，管理就是制定计划，然后按计划执行。这话足够精练。试想，如果所有的事情都能够按照计划执行，管理将成为一件简单的作业。但是实际情况并不那么简单，由于环境的变化、认识的偏差、能力的不足等，造成了实际状况与计划的偏离。而要保证项目围绕计划开展，就得用到项目控制。

项目控制以一定的标准为依据，定期或不定期地监控项目，发现项目活动与标准之间的偏离，并采取必要措施进行解决。

项目控制可带来的好处：

· 项目问题可以被及时解决，避免损失扩大；

· 控制体系的建立是管理者授权的前提，许多管理者不愿意授权，就是因为害怕下属犯错误；

· 管理者了解当前项目的状态；

· 客户了解状态，增强信心；

· 管理者了解工程师在努力工作，工程师获得信心。

项目控制包括进度控制、成本控制、质量控制、风险控制等方面，具体的控制措施包括：周会、周报、里程碑报告、提交物审计、过程审计、配置审计、风险跟踪、挣值报告，乃至一些技术相关性很强的活动，比如测试和同行评审，也可被归入控制范畴。

本文主要以周报为例来说明控制的原理。

控制过程

控制可分为三个步骤：

（1）衡量实际绩效；

（2）将实际绩效与标准进行比较；

（3）采取管理行动来纠正偏差或不适当的标准。

我们很容易联想到著名的PDCA循环，控制过程体现的正是C、A两个步骤。

还应该注意到，跟踪和监控过程是有标准存在的，标准有两类：项目计划、组织规范。组织规范可能是基于各种管理体系建立的，如ISO9000、CMM、PMBOK等，它具有稳定性和长期适用性。与此相对，项目计划只对一个具体的项目起指导作用。

衡量实际绩效

· 如何衡量？

除了采用常见的口头沟通（如周会）和书面沟通（如周报）外，还可以用走动管理的方法来直接获取第一手资料，通过这种方法可以获得其它方法得不到的信息，包括情绪、态度等容易被其它方法忽视的信息。

· 衡量什么？

衡量什么非常重要，因为它在很大程度上决定了员工的目标。

软件项目通常需要追踪以下要素:

· 规模

· 工作量

· 成本

· 关键计算机资源

· 进度

· 技术活动

· 风险

作为控制的标准，希望其具有明确性、可测量性、可验证性。下面的标准是难以被衡量和控制的：

（1）近期完成测试环境的准备（进度标准）

问题：时间不明确

（2）本项目期间，降低缺陷率（质量标准）

问题：不可测量

（3）11月制定配置管理计划（进度标准）

问题：角色不明确

（4）必要时，在头文件中说明全局变量（质量标准）

问题：不可验证

也有许多工作不能用量化数据表达，这并不意味着这些因素可以不被衡量和跟踪了，管理者应该积极地寻找一种主观衡量方法（虽然主观方法有很多局限性，但是总比没有标准要好）。

项目的实际状态与计划完全吻合几乎是小概率事件，多数情况下不是超过就是不足。在偏差比较之前，确定可接受的偏差范围是必要的，超出这个范围就需要引起管理者的注意了。在实施量化管理的高成熟度组织里，可借助控制图比较偏差。前面提到，计划通常作为跟踪的标准，计划既可以是项目初期制定的总体计划，又可能是周报或者二者的结合。周报实际上是一种短期计划和短期总结的综合（见样例）。

采取管理行动来纠正偏差或不适当的标准

经过偏差比较之后，管理者需要从以下三种措施中选择其一：

· 什么也不做；

· 改进实际绩效；

· 修订标准。

改进绩效有两种方式：一是纠正，二是预防。所谓纠正是把现有的问题纠正到正确的轨道上；预防是指解决问题的根源，避免以后类似问题的再发生。管理者经常以没有时间为借口，只是纠正，而不去真正地解决问题，容易造成“救火式”管理的恶性循环。

样例：通过项目经理周报跟踪进度和风险

周报

工作周： 2001/4/22 — 2001/4/26

部门： A项目组

小组成员： A、B、C、D、E、F

报告人： G

1．顾客抱怨

2．本周任务完成情况

任务
状态
说明
延误

dh业务（接口、编码）开发
完成
100%
-

jjr批量处理方案制定
完成
90%
-

生产线排错
完成
100%
-

注释：任务名称从MSP中获取；说明列中填写原因和完成百分比。

3．下周需要完成的任务

● EEX界面修改方案制定；

● OCOG打印汇总清单代码开发；

● 对公批量处理代码开发。

4．风险跟踪

预期的风险是否发生，是否被化解是否有新的风险发生。

编号
风险名称
发生概率
严重程度
状态

-

5．存在问题

希望增加人手，开始开发新业务。