没人教的项目管理方法之（明白该干什么） 二、项目章程如何写（上）

按照项目过程管理的教科书的要求，任何项目上来，除开前期的项目调研外，项目章程是一个必不可少的项目整体管理的组成部分。

看看书面解释“项目章程是正式批准一个项目的文档。项目章程要么由项目组织以外的发起人或资助人发布，要么由组织内某个级别的管理层发布，以便为该项目提供所需的资金。项目章程对项目经理进行了授权，以便他可以使用组织资源执行项目，应该尽可能在项目的早期确定并任命项目经理。”

其实这段话和所有教科书一样，是建立在完美资源和充分条件的基础上的，在目前国内的实际环境中，一个项目的发起往往就是几个主要决策人拍板决定的，有一个过得去的炒了不知道几遍的调研分析报告，就把合同约定了，有的甚至在没有签定合同的前提下，就开始组建项目团队。在项目章程确定上，不能尽信书也不能无书。

项目章程的在教科书上约定的输入条件、分析工具如下：

输入	工具与技术
合同	项目选择方法
工作说明书	项目管理方法
企业环境因素	项目信息系统
组织过程资产	专家判断

以上内容不太明确的，可以参考清华大学的《信息系统项目管理师教程》的第84-86页的内容。

但是今天的重点不在这些，我想说的是象我们这样的小公司，如何用浅显易懂的方法理清项目章程，让项目章程成为软件开发中的整体过程管理中的标杆文档，为项目管理提供提纲挈领的作用。

我认为，项目章程在国内的小公司只需要抓住如下重点：

一、项目名称、项目立项时间、项目小组成立时间、立项调研文档出处。

大家不要小看上面四项，有很多公司的项目，项目小组内部对项目的名称叫法都统一不了，这样的素质怎么能让客户放心。

二、客户描述

这个客户描述是比较有学问的，一要描述客户的企业背景，二要描述客户的组织结构图，三要描述客户目前项目小组方的主要成员的姓名、联系方式。另外，要对客户在项目中的沟通方式做个简单描述，譬如客户中谁看迭代版本，谁看进度报告，谁看测试报告等，有的项目比较小，不用做项目沟通计划的时候，就可以依照这个沟通方式来执行。

三、项目组及职能描述

这节要分为两部分，一是描述开发方项目小组的主要成员、职务、联系方式；二要描述项目小组的职能矩阵，具体描述如下所示：

序号	工作单元	高xx	欧阳x	张xx	赵xx	谭xx
1	需求调研	D	d	d	d
2	需求分析	D	D	D	D
3	项目沟通	D	d	d	d	x
4	工作计划分解	D	d	d	d	x
5	编码实现	d	D	D	D
6	架构实现	D	D	D	D
7	单元测试		D	D	D
8	黑盒测试		d	d	d
9	用例测试		d	d	d
10	集成测试	D	d	d	d
11	上线实施	D	d	d	d
12	用户培训		d	d	d	d

D 重要决策者 d 参与决策者 x 执行者

四、项目远景

项目远景包含以下内容：

Ø 项目目标

Ø 功能范围目标

Ø 项目管理目标

Ø 组织目标

项目目标：师出必有名，做一个项目，必须让项目组成员明白这个项目是要实现什么目的，这个项目远景就是项目要达成的目标，譬如下面这句话：此项目是为完成客户总部生产技术部实验系统的无纸化管理，将以前手工登记的试验计划、试验结果评定、试验标准对比等纸张数据由计算机系统进行统一管理。这段描述是指的项目的完成目标。

功能范围目标：如果在项目成立之初就了解更多的项目需求和信息，甚至还可以扩展写下诸如项目的功能范围目标（譬如要完成和实现哪些范围的功能），这个功能范围有别于具体的功能列表，可以说是项目的功能边界的描述，如果有《项目范围说明书》，那这里的功能范围目标就要保持前后一致，实际上《项目章程》也是《项目范围说明书》的必要输入条件之一。

项目管理目标：我们都知道项目管理的铁三角（成本、质量、进度），也有人说项目管理有金四角（成本、质量、进度、功能），钻石五角（成本、质量、进度、功能、发展）等等（见张传波的UML视频），其实不管怎么解释，对各类中小型软件企业来说，首先要完成的是项目的目标本身，其次才是扩展项目的管理目标，这是一个渐进的目标层次。在这里，应该尽量量化项目的管理目标，而不要模糊化，因为目前国内的项目经理的能力普遍参差不齐的前提下，要通过短短的几次培训让他们明白何为项目管理太难了，还不如明确的告诉本次项目要完成的项目管理目标，譬如：在项目最终版本交付时，level300以上的bug数为零；项目章程中各项规定的文档提交齐全并通过外审和内审；项目总结时按期提交知识共享文章等等。项目管理目标是在完成项目目标并按约束条件验收（后面论述）的前提下，完成软件开发企业对项目管理过程提升和总结归纳的要求。说白了，在国内目前的情况下，很多中小型公司都要完成从项目到产品或解决方案的转变，否则项目做完了，企业也就无米下锅了。

组织目标：组织目标和项目管理目标不同，项目管理目标是在项目管理过程中进行明确的要求，而组织目标则是站在企业战略目标的基础上对项目产生的提交物或是企业整体能力完善提出更高的要求。譬如：完成某某通用组件并形成可部署的解决方案1.0版本（含相关使用帮助），并在内审通过后完成企业内开发人员的使用培训；完成项目小组中开发人员对报表系统的开发能力的提升，并完成对企业内其它开发人员的报表系统的培训；在项目中尝试使用客户沟通管理系统，并提出完善意见和客户对沟通系统的使用反馈总结等。

五、项目约束

项目约束是指驱动项目成功的因素，在这里奉劝大家要站在出资人的角度去考虑这些约束条件，而不要过多的考虑上述第三条的项目管理目标、组织目标等，我前面说过，项目成功是先决条件，否则其它都是扯淡。

我罗列一些项目的常见约束条件如下：

约束	备注
项目资源	人力资源、设备资源、关系资源等一切可以为项目成功或失败的因素对应的实体，可用鱼骨图分析
发布日期	在何时发布什么版本，对大部分项目来说，客户会只要求一个最终版本，这是不现实的，要告诉在最终发布版本前起码还有2个或以上的内测版本
功能列表	要完成哪些功能，即实现哪些必要功能是这个项目成功的必要条件，这个条件需要和客户反复的商榷，客户通常都是买小菜的念头，相信功能越多越好，要让客户理解项目成功的铁三角关系，这个需要进行多次项目管理思想的宣讲甚至培训
缺陷管理	要将缺陷控制在一个什么样的程度上，这个指标要量化，譬如在最终版本时，level300的bug要为零
工作环境	这点恐怕大家都不太注意，我要重点说的是就中小型公司来说，要竭力避免现场开发，这里写清楚，以后就少了很多扯皮的事情
沟通管理	有时候出资方的管理背景比较复杂，就要求项目经理要提早知道哪些干系人会对项目验收造成影响，要学会及时沟通和汇报，多打几个电话可以免去很多沟通障碍
企业愿景	这是指开发方对项目中产生的过程知识进行完善和规划的要求，通常这个对项目成功的约束很小，但在某些项目，譬如要完成项目到解决方案或产品的抽象时需要这个，不过要完成这个约束需要很高的项目管理造诣，如果项目比较有把握完成时才建议把这个纳入到约束中来

以上只是列举了一部分，当然实际情况中，项目的约束有很多，不过对于大部分软件开发公司来说，基本上足够了。

值得注意的是，项目的约束需要进行优先级别的排序。也就是说一个项目中，这些约束不要在同一个优先级上全部满足，根据我的经验，一个项目也就是一个高优先级的关键约束，另外加上两到三个的次要约束条件即可满足项目成功的所有必需条件，另外的约束条件应该作为锦上添花的约束进行罗列，完成了当然好，不完成也影响不了项目的总体验收。

大部分国内项目的约束条件的头4个基本是1）工期、2）完成必要的高优先级的功能点，3）可以保证质量的最终交付版本，4）项目资源的保证及稳定，高于一个关键约束条件或高于三个以上的次要约束条件对项目的成功会造成比较大的风险，同时也会对项目的成本造成很大压力，毕竟国内的项目很多都是定价合同，象国外一样的按功能点签议价合同的是天方夜谭的事情。不过3个以上的次要约束条件才能保证项目本身成功的项目也有很多，这就要发挥你项目经理的沟通能力了，如果你不能说服客户，那么就这些约束条件你就要做详细的风险分析了，这个以后的章节再作讨论。

下节将介绍项目假设、项目管理方法论、项目的可交付成果、概要进度、参考里程碑提交物等概念

待续……