软件工程控制经验总结系列之一 - 软件工程控制总论

前言：在实际的大规模软件实践中，笔者所带领的事业群总是碰到各种各样的项目交付问题，特别是规模稍微大一点的软件项目，更是如此，总是看到我们的项目经理或愁眉苦脸，或通宵达昼，或垂头丧气，或又将告诉你将延迟交付，问题不一而足，但核心要点几乎是一致的，基本都是项目部分处于失控边沿，笔者也做过众多的培训，但仔细思考一下，总感觉点滴传授，缺乏系统性，言语相传，并未存于档案，此系列文章就是基于这个目的，将笔者过去十几年的经验悉数总结梳理一下，按照软件工程的经典理论将每个阶段的控制观念以及核心控制要点在各个环节予以一一展示，目的在于能够培养更多合格的乃至优秀的项目经理，也为我们的软件工程经典理论提供更多来自于大规模软件工程实践的经验。此系列文章众多的理念只有你亲身经历并且苦闷彷徨过且最后在自己的努力下成功解决了之后再回头阅读思索的时候更加能够体会这些管理实践的奥秘，也期望这个系列的文章对各位有非常实际的帮助，本系列文档从总论到分阶段论述总共十二章，后续会不定期对文档进行修订，欢迎各位批评指正。

 

从软件工程的经典瀑布理论而言，可以将软件工程的全生命周期治理管控对应地分为如下阶段：

1.  概念阶段 (Concept phase)

2.  计划阶段 (Plan phase)

3.  需求分析阶段(Requirement phase)

4.  概要设计阶段(Preliminary phase)

5.  详细设计阶段(Detail design phase)

6.  编码阶段(Coding phase)

7.  打包编译阶段(Build phase)

8.  集成与系统测试阶段(CT/ST phase)

9.  发布与部署阶段(Release phase)

10.运维阶段(Maintainance phase)

11.总结阶段(Summary phase)

 

对于阶段的划分，每个组织机构的标准各不相同，譬如IBM会有SIT阶段等，很多同行也不会认可将Build phase单独作为一个独立阶段显式地拉出来作为独立阶段放在工程管理阶段划分里面，这些都不重要，重要的是这些阶段的基本切割并不会阻拦整个工程在进行过程中所有工作事项的分割，换言之，所有在工程管理实践中要多的事情并未因为阶段的分法不一样而发生变化，因此不用太纠结于阶段的分解，而将精力放在如何将工程管理的每个实践细节弄清楚、搞明白，这才是关键。

 

而从管理实践来看，整个软件工程的管理需要从技术、管理两个层面来进行对应的管理，方可确保工程整体的成功，而技术是工程实施的基本内容，管理更多地需要关注流程、标准、品控、量化分析等各个环节，确保各个环节的按期完成。

而依照国际上享有盛名的CMMI工程理论针对软件工程在此处的定义，其整体上分为22个PA(ProcessArea),

1.  配置管理(Configuration management - CM)

2.  过程与产品质量保证(Process and Product Quality Assurance - PPQA)

3.  度量与分析(Measurement and Analysis - MA)

4.  供应协议管理(Supplier Agreement Management - SAM)

5.  项目监督与控制(Project Monitoring andControl - PMC)

6.  项目计划(Project Planning - PP)

7.  需求管理(Requirements Management - REQM)

8.  决策分析与解决方案(Decision Analysis and Resolution - DAR)

9.  确认(Validation - VAL)

10.验证(Verfication - VER)

11.产品集成(Product Integration - PI)

12.技术解决方案(Technical Solution - TS)

13.需求开发(Requirements Development - RD)

14.风险管理(Risk Management - RKSM)

15.集成项目管理(Integrated Project Management + IPPD)(IPM+ IPPD)

16.组织级培训(Organizational Training - OT)

17.组织过程定义(Organizational Process Definition +IPPD)(OPD + IPPD)

18.组织过程焦点(Organizational Process Focus - OPF)

19.组织过程性能(Organizational Process Performance - OPP)

20.量化项目管理(Quantitaive Project Management - QPM)

21.组织革新与部署(Organizational Innovation and Deployment- OID)

22.原因分析与决策(Casual Analysis and Resolution - CAR)

CMMI的这些PA都是对软件工程中所有的服务领域的最佳实践进行总结的，而我们前面的阶段切割只是对于作为系统研发的乙方所需要进行的全部工程管理阶段以及最佳实践进行总结分析的，彼此之间在关于研发过程的管控领域几乎是一致的，只是我们的11个阶段划分仅仅包含了动态管理阶段部分，而CMMI不光是包含了这个方面，更是包含了对于静态部分譬如度量与分析、供应链协议管理等，因此范围要多出更多，为何在此论及CMMI的理论，主要是在后续的分阶段论述中会引用到很多的标准与规范，而这些思想的来源就是CMMI，这样就更加能够解释我们这些控制理论不光是来自于实践，更是国际上优秀理论与众多的工程管理实践进行结合的升华结果。

 

在上述11个阶段中，作为项目经理而言，以下八个要素必须时刻记忆在脑海之中，因为这些因素是推动整个工程前进的基础，也是你作为总控人员依赖的根本：

1.项目团队 - 团队的组织结构与分工合作方式直接决定总体执行效率，即CMMI中提及的关联篇幅 - 组织革新与部署，但CMMI中更加强调动态调优组织结构；

2.文档与确认 - 对应于项目中对应的文档材料，文档作为证据载体，而确认对应于证据表现；

3.标准与体系 -  没有标准与规矩，难成方圆，对应到项目中，分别有需求、编码、测试等各个层面的标准，不一而足，对于大团队尤其重要；

4.度量与分析 - 度量是帮助管理者将工作内容数字化，分析将帮助管理者找到低效与不合格部分，对应到项目中，包括时间、工程量、品质等各个方面的度量与分析；

5.效率与组织过程 - 效率对应于资源的最大化利用，而组织过程将对应于如何将效率予以发挥，小到个人到团队，大到整个组织；

6.品质管控与手段 - 品质管控是交付达标的关键治理，小到阶段控制、个人控制、模块控制，大到整体工程控制，如何利用有效的治理手段来进行推进管控是关键；

7.支援体系以及应用 - 支援保障是确保团队顺利作战之关键，针对每个项目的支援保障体系都不一样，某些项目可能是培训技能，某些项目是解决后勤譬如吃住交通问题等；

8.快速反应应对能力 - 拥有快速反应能力，才能应对复杂多变的项目执行环境与体系，知识是死的，灵活应用才能够发挥其最大功效，居无定法，灵动为妙；

 

笔者在这里抛出合格项目经理的评判标准：

1.  需求管理有序可控，文档证据齐备可查；

2.  人员的负荷安排相对合理均衡；

3.  进度管理匹配计划；

4.  变更管理可控有序；

5.  量化管理与分析按标准执行；

6.  品质符合需求要求；

7.  成本符合预算；

8.  团队合作融洽，成员满意度高；

9.  客户交付符合其预期，并且满意度达标；

如果需要变为优秀项目经理，除了上述9个指标外，还有3个指标是非常重要的：

1. 带领的项目是否能够经常性获得了超额利润或者提前完成，譬如整个公司的项目为毛利20%，你能够经常做到30%或以上，人家的产品研发2个月周期，你总是能够做到1.5个月；

2. 总是能够在项目治理过程中有创新点或者突破点，这些突破可能是来源于技术，也可能是来源于管理，不一而足；

3. 能够不断地优化组织内的治理流程，这个也是CMMI所倡导的精神，不断地透过量化与分析寻求优化点，同时积极地寻求优化策略并且付诸实施，这个也是CMMI5的核心内容；

在我们的项目管控出现的问题的时候，我们的项目经理往往首先想到的就是不断加班来解决问题，弄得很多成员谈到做IT就是加班的代名词，谈IT就色变，而这些都是对IT的误解，除了个别因为资源紧缺、周期极短的项目需要加班来弥补天然的规划因素带来的交付压力之外，其他的项目如果管理妥当的话都是非常容易达到预算标准的，当然这里正确的方法也不可能确保每个项目都成功，需求方的因素也是影响的关键因子之一，如果源头很难合理，那后面的交付管理也是不太可能达到预算期望的。

 

多年来笔者一直非常推崇CMMI的控制观点，笔者接下来讲的控制实践观点也是基于这个体系，也曾经经历了美、日、欧、国内等不同市场数以百计的项目群的检验与对比，不仅仅是因为它非常知名，而是因为它内部的组织、标准、度量与量化分析等基本的理论，是整个软件工程得以推进乃至品质得以保证的基础。笔者在实际的工作中碰到过很多所谓的牛人，技术确实不错，但很少接触过软件工程控制观点，一听说要度量与分析或者CMMI总是感觉是瀑布模型，就急于推销自己的所谓Agile敏捷模型，抵触情绪明显，但一到实际的模型细节，往往也是作坊式管理，毫无章法可言，究其实际，就是自己对于管理控制的基础理论非常缺乏，过于主观武断地坚信自己的作坊式、师徒式管理模式是正确无疑的，而这样的执拗之见只会阻碍自己的学习与进步，成为自我前进的累赘而已。

 

同样在多年的团队管理实践与项目管理实践之中，笔者也深深地感受到我们国内在这个行业的软件工程管理能力方面的欠缺，从笔者所在的公司到关联的行业合作伙伴再到众多的软件公司，软件工程其实都是处在无序的运营之中，如何判断公司是否软件工程管理达标问题，给大家一系列问题来对照一下：

1.你所在的公司有专门负责软件工程管理的独立组织职能板块么？人员是否称职？

2.公司是否有明确的软件工程管理过程定义？

3.公司的所有成员是否都对项目过程管理非常清楚？

4.公司对于软件的量化管理是否有一整套度量标准并且将这些标准能够付诸实施?

5.公司对于软件的品质管控方面是否有明确的量化标准以及一整套控制观点与流程并且配合实施；

6.公司对于需求的变更管理、配置管理、发布标准等是否有明确的定义并付诸实施？

7.公司是否有整个组织的基线库管理并且是否有经常发布企业的基线库供各项目组进行对比学习？

 

在整个项目的工程管理实践中，其实决定整个软件工程的核心进度的因子是如下8个核心因子：

1.需求范围的严格管控

2.项目组织结构的合理性，特别是针对技术能力组合上的合理性

3.流程管控的合理性，特别是对于技术实施的流程管控方面

4.资源的合理调配与使用，简言之，最合理的人与事务的配对

5.对于技术方案的最合理使用，简言之，最能够适用项目条件的方案的使用

6.对于进度与品质管控方面的量化分析，就是数据化分析团队的产出与品质

7. 对于所有项目文档的分类管控，并且与项目干系人的确认；

8.发现问题后及时快速地应对措施进行跟进

也正是因为软件工程管理（项目管理）影响因子非常多（核心因子都有多个），而且囊括了包括 来自需求、技术、标准、体系、沟通、组织过程、量化与分析、文档、配置、流程、采购等不同的领域知识（Domain knowledge)，因此要求工程控制人员对于这些不同的细节控制域的控制点非常熟悉且能够辨证地灵活应用，项目经理必须非常清晰自己的项目终极目标，努力地寻求各种资源来快速地解决问题迅速达成目标，其实工程控制就是如此简单，但很难想象譬如对于量化管理无任何经验的项目经理能够管理几十人月的项目而且次次确保成功，成功的秘钥都不握在自己手头，仅凭感觉与经验能够到达彼岸么？

也是为了更好地把握每个阶段的核心要素，后续的章节讲解中将突入每个阶段的事项（目标）、控制项、控制过程、沟通与文档记录要点、品质治理目标、检查列表等几个大的子项来勾勒出阶段全貌，从而更好地帮助各位理解阶段的治理管控之精髓。

在实际的项目管理实践中，我们的项目经理在碰到项目问题整体进度延迟之后往往束手无策，只能考虑通过加班来追赶进度，而往往忽略了整个项目管理的核心因子，而这些核心因子也离不开后续的管理手段与措施的深入理解与融会贯通式的应用，如何能够在项目出现失控之后按照合理的步骤来诊断这些问题并且后续找出应对措施来解决这些问题呢？下面是笔者推荐的几步会诊法：

1.需求与预算是源，两者是高度的辩证统一，正本清源乃诊断第一要务，何种预算对应何种需求这个是关键；

2.技术实施方案合理性与高效性、适用性是第二步需要审核与验证的 ，同样的道理是何种预算对应于何种技术实现；

3. 规模度量与效率核算是紧跟在需求与预算之后的第二步，必须明确生产能力与工程要求的工作负载是不是平衡的，齐备资源才能够配合计划的实施；可以借助量化模型来分析项目进度是否合理？此乃诊断之关键，很多的问题通过这个手段可以发现出来；

4.资源的调配使用是否最合理，是否将整个团队的产出按照最优化产出来调配使用，将个人的单兵产出发挥到极致是项目进展高效之关键因素；

5.品质治理管控的量化分析，各个阶段的管控是否合理 ？

6.支援保障体系是否强劲有力，很多时候后勤不给力，包括培训、交通、饮食等都是核心因素之一。

7.团队的士气、战斗力等是否能够产生足够的吸引力来让每一位成员乐于奉献与协助。

 

经过上述七步法之后你就会发现项目管理实务中的各种各样的问题，而且大多数项目都是各种症状综合并发的，项目经理如何能够锻炼自己的"火眼金睛"来快速识别这当中的问题并且努力尝试解决，这就要用到接下来在下面的论述中详细地描述的各个环节需要考虑与应对的关键问题，接下来的章节将按照前面的11个阶段来分开逐章描写，精彩敬请期待。

后记：我们往往很多的项目经理在做项目的时候缺乏系统的控制观点，不懂核心的控制因子，只是将项目当成一个普通的程序在开发，需求不做控制，进度无法量化告知，技术实现追求所谓的“完美”，品质管控没有观点与量化指标......，一切的一切都是在挑最难的环节力求突破，如此下去如果不加班能够按时交付项目才是真的奇迹，其道理非常简单，在无边的需求中使用工作量最大的解决方案并且没有任何量化手段来控制项目进度，这个才是真正的可怕，对于每个阶段的控制点都要深入骨髓的理解并且灵活运用才是真正的优秀项目经理。简单的来说，优秀的项目经理将大量项目做得非常成功，少量项目做得失败了，但经“抢救”后又成功了，经过九死一生的轮回考验之后才能够体会百炼成钢的蜕变感受，才能够真正享受成功带来的喜悦感与幸福感！

其实笔者也非常认同CMMI是系统控制论方面特别是组织内的系统控制论方面非常优秀的实践经验总结（Best practice），熟读其要点，领会其思路与精髓对于大家不光是管理项目，哪怕是治理部门与公司，如果能够依法得以坚持，不断改进，持之以恒，未来一定会精彩纷呈，达此境界才能真正成为管理界的大牛，也期待各位能够早日达到胜利的彼岸。