一、 干系人分析应该怎么做
不少刚从技术人员提升成为项目经理的员工经常面对项目中无穷无尽的沟通和注意事项感到筋疲力尽，以前也有同事对我说,“老大，我是不是不太适合项目经理这个岗位，现在感觉还不如做开发人员的时候开心。”我当时除了勉励他，教他一些项目管理的方法，支持他并给你提供更好的资源，也为他做了一些项目上针对性的分析，现在看来，初次当上项目经理的同事，即使经过项目经理的简单培训，仍然对项目管理抓不住重点。
今天第一课，项目干系人分析，是所有项目经理的必修之道，好比练功，这是基础中的基础，马步站桩虽然不及拳脚好看，可这是夯实你项目成功最重要的一步，而且在整个项目管理过程中，还要经常回顾和分析，就好像陈氏太极大师陈王廷，每天还坚持站桩。而这个干系人分析在教科书上说得太理论化，今天我就用实例来说说干系人分析应该怎么做。
项目干系人，软考中参考书籍上有解释：项目干系人又称为项目相关利益者，是指积极参与项目、或其利益会受到项目执行或完成情况影响的个人或组织。项目干系人对项目的目的和结果施加影响。项目管理团队必须识别项目干系人，确定他们的需求和期望，尽最大可能地管理与需求相关的影响，以获得项目的成功。
上面是书面解释，实际过程我举个活生生的例子：某公司A的系统集成项目，客户信息中心主任与该公司的关系很好，而这家公司A通过努力也顺利的中标，并开始组建项目小组，分配资源，准备实施，公司派了一位技术经验丰富的工程师小张作为本项目的项目经理，因为这个项目需要同时与客户、软件厂家、硬件厂家、公司技术支持人员（不属于此项目小组）进行沟通，按公司项目管理规定，小张首先拿出了《项目章程》，按以前其它项目的模板照猫画虎完成了，在干系人分析时，只是简单的罗列了相关的客户方成员信息、厂家信息、和小组成员及技术支持人员信息，简单的说，就是只做了个通讯录。
各位可能会说，这样就很不错了啊，我们来看看这个项目章程中的干系人这一节的截图
大家看到了，就算是个通迅录，也还缺少相应人员的邮箱，问个对方的邮箱不是难事，可这个项目经理小张可能忽略了，最重要的是，他没有做相应的干系人利益分析。
作为项目干系人分析的第一步，需要先仔细识别出本项目的全部干系人。项目经理需要对项目干系人有一个全面的了解，在心中有一张完整的项目干系人结构图，以后无论是启动、计划还是执行、问题处理和收尾，都需要系统全局地思考问题，切忌头痛医头、脚痛医脚。
在项目干系人识别中，对客户方项目干系人的识别和分析更是重中之重，在本文中将重点集中在对客户方干系人做重点分析。通过对上面案例分析，可以画出一张客户方项目干系人结构图，打比方说这个客户中所有干系人的情况如下图所示
在识别出项目干系人之后，还需要分析干系人之间的关系和历史渊源，如果不做这进一步的分析，会在项目过程中遇到不小的麻烦。比如在上述案例中，信息中心主任和公司A的关系很融洽，有多年的合作关系，且相互间合作很愉快，这个主任属于集团的行政副总分管，和副总的私人关系也还不错，地位比较稳定。而财务部经理虽然也属于同一个副总分管，可他希望这个系统由公司A的竞争对手Z公司来做，因为这是平台化项目，一旦开始，后期还有源源不断的项目可以开展，但Z公司在竞标过程中被淘汰，让财务部经理心里很不满意，很担心这个整合项目一旦由信息中心主任做成功了，Z公司从此就没办法再拿到后续的项目，从心理上就希望项目做不好，从行动上也倚仗自己是企业的核心部门处处对项目设置障碍（不管怎么说财务的地位在大部分企业里面是高于信息部门的，除非本身就是IT公司，呵呵）。财务经理手下的人对系统整合也不太支持，认为不仅剥夺了自己本部门系统的建设权，而且以后业务运作都处在领导监控之下，自然就不怎么好好配合项目了。
通过以上对干系人的识别和初步分析，我们可以看出，如果不能对项目干系人进行无遗漏地识别，仅仅关注项目具体事情和计划，项目出了问题可能都不清楚问题出在哪里了。项目干系人结构图为项目经理描绘了客户方项目干系人的全景，为进一步对干系人进行分析，为更好地把握项目管理打下了一个很好的基础。
在中国做事情，有时候是做事，有时候是做人，事情做好了，人没有做好，项目失败的案例比比皆是，在这里，我不是说项目经理要练的跟销售经理一样油嘴滑舌，就算你练到这样了，客户反而认为你这项目经理靠不住，毕竟项目经理是需要技术底蕴获得客户信任的。那么，有个朋友说“这项目经理太难了，装孙子也不是，装大爷更不行，怎一个囧字了得！”我说，你没有抓住人心的本质，你要比客户更专业，让他信服你的技术能力比他更优秀，他就不会给你不尊重或乱指挥。客户很多时候乱指挥，是因为我们没有让他信服的技术能力和对客户业务的理解能力，所以造成客户亲自操刀，上阵指挥，各位初哥项目经理们扪心自问，你如果是客户，你是希望对方的项目经理帮你一杆进洞干净解决问题呢，还是希望亲自上场导致令出多门以惨败收场呢？
当然，项目中不可能这样完美，我们做项目的时候，能力不可能在每个方面都比客户强，所以需要我们去和客户真诚的交流，中国人讲究个面子，你夸他几句，说他是业务方面的专家，给对方一个高帽的同时也表明了你在技术上比他更专业，大家配合做事才可能成功，技术上的事我说了算，业务上的需求我们来一起协商，私底下，把客户当朋友，请吃个饭，聊些他喜欢的话题，拉进一下距离，送一些对他胃口的小礼物，都是必要的，大家不要做技术做单纯了，做的人情世故都不懂了，那就是技术人员的最大悲哀了，毕竟，人是感情的动物，你不可能要求别人都和程序员一样，不是1就是0，不是黑就是白，项目中的干系人分析来分析去，落脚点就是两个字“利益”。
象上面的例子，怎么对付这个财务经理，很简单，首先这个项目经理应该对客户的每个干系人在现场都拜访一遍，把公司的荣誉和资料介绍给那些不了解公司的干系人，让他们了解公司的实力。再则根据合同，把需求整理好并与客户签字，了解这个项目中可能影响这个财务经理意志的干系人（譬如行政副总或他手下的财务主管位）最在意的利益所在（譬如数据要顺利迁移、要保证切换后的系统稳定等），当财务经理来刁难的时候，根据双方确认的需求和合同，不在这个范围内的，找项目负责人信息中心主任确认，遇到要到老总那里打官司的，提前和信息中心主任对好说辞，并定期向分管副总和财务经理汇报进展，这样可以把很多问题解决在萌芽状态。
项目经理的第一课，是具有中国特色的干系人利益分析法。
二、项目章程如何写
按照项目过程管理的教科书的要求，任何项目上来，除开前期的项目调研外，项目章程是一个必不可少的项目整体管理的组成部分。
看看书面解释“项目章程是正式批准一个项目的文档。项目章程要么由项目组织以外的发起人或资助人发布，要么由组织内某个级别的管理层发布，以便为该项目提供所需的资金。项目章程对项目经理进行了授权，以便他可以使用组织资源执行项目，应该尽可能在项目的早期确定并任命项目经理。”
其实这段话和所有教科书一样，是建立在完美资源和充分条件的基础上的，在目前国内的实际环境中，一个项目的发起往往就是几个主要决策人拍板决定的，有一个过得去的炒了不知道几遍的调研分析报告，就把合同约定了，有的甚至在没有签定合同的前提下，就开始组建项目团队。在项目章程确定上，不能尽信书也不能无书。
项目章程的在教科书上约定的输入条件、分析工具如下：
| 输入 | 工具与技术 |
| 合同 | 项目选择方法 |
| 工作说明书 | 项目管理方法 |
| 企业环境因素 | 项目信息系统 |
| 组织过程资产 | 专家判断 |
以上内容不太明确的，可以参考清华大学的《信息系统项目管理师教程》的第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个以上的次要约束条件才能保证项目本身成功的项目也有很多，这就要发挥你项目经理的沟通能力了，如果你不能说服客户，那么就这些约束条件你就要做详细的风险分析了，这个以后的章节再作讨论。
下节将介绍项目假设、项目管理方法论、项目的可交付成果、概要进度、参考里程碑提交物等概念
五、项目假设
就字面意思来解释，就是必需满足这些假设的条件，项目才可能按计划开展任务，这里的假设大家不要写得过多，而要集中关键假设上，这个需要结束上篇文章提到的项目约束来讲：
为了大家不用翻上篇文章，我把描述粘过来
值得注意的是，项目的约束需要进行优先级别的排序。也就是说一个项目中，这些约束不要在同一个优先级上全部满足，根据我的经验，一个项目也就是一个高优先级的关键约束，另外加上两到三个的次要约束条件即可满足项目成功的所有必需条件，另外的约束条件应该作为锦上添花的约束进行罗列，完成了当然好，不完成也影响不了项目的总体验收。
因此，影响高优先级及次要优先级的假设条件才是你需要关注的：
譬如：工期作为高优先级约束。有些项目有近乎苛刻的工期要求，这时首要保证的假设无外乎如下：
- 人力资源（包括开发方和客户方，大部分项目经理在做假设时只估算了开发方，其实客户如果业务繁忙，没法配合你的需求调研、版本审核、业务指导等也会影响工期，如果有第三方，那么还要包括第三方）
- 设备资源（计算机设备、网络设备、其它硬件设备、办公条件等）
- 资金资源（人力成本、加班经费、风险准备金（这个要估足）、交通误餐等）
- 知识储备（预估项目中可能遇到的知识难点，可以通过培训、外聘专家、外包等解决）
- 根据项目实景分析（采用鱼骨图，SWOT等工具）会遇到的项目延期问题，譬如客户没一个懂需求分析重要性的，那就要安排相应的需求分析知识培训给客户
项目假设是可以补充的，应该说项目假设有点类似于风险分析，但项目假设是着重于关键约束实现的必要条件，而不是应对方案。
六、项目管理方法论
项目管理方法论就不过多阐述了，如果你的企业有一个完整的项目生命周期管理，那么这里其实就是选择相应的生命周期，如果需要适当裁剪的，要把裁剪后的周期详细说明。
瀑布、敏捷、RUP等这些都是生命周期的呈现形式，根据不同的企业特点，会对这些方法进行相应的改动以适应开发过程。
七、项目的可交付成果
这个很清晰，一般来说第1、2项是客户要求的，第3项需另外约定
1、软件各个版本
2、各个里程碑提交物（文档、阶段交付产品）
3、项目过程中生产的其它附属提交物（通用类库或组件、附属开发产品（譬如一个小型OA））等
八、概要进度
这一项很多项目经理很反感，确实我也很不愿意预估，因为项目开始的时候很多条件都不是很明确，那些WBS在这个阶段是没法弄的，没办法预估，而项目章程非要来这么一项，怎么办呢。
我提供一些思路给大家
1、凭经验预测，这是最不靠谱的，建议不到山穷水尽的时候不要用，因为你一旦对企业承诺了，实现不了就全是你的责任了
2、短暂启动评估法
老外也叫这个“哈德逊湾式启动”，方式源自17世纪加拿大的哈德逊湾航运公司，这家公司的商船在启航后，会在距离港口几英里的地方做短暂停留几天，这样确保如果忘记装载了一些必须的给养和装备，可以回到港口再补充。
运用到项目管理中，可以让项目小组先尝试在项目的实际环境中先开展完成某些功能和工作，具体说来譬如一组测试驱动的代码或是某一组功能的思维导图，这个时间要尽量短，一般不要超过三天，如果你不好选择开展哪些工作，那么你可以选择手头上可以在4小时内完成的工作，完成之后，项目组一起来分析这些工作。如果还是不知道，那么请看下面的办法
3、短期迭代
和上面不一样，这个估算是以一组功能或工作完成后，团队成员来一起分析整个项目的工期，譬如说大家一起把需求分析中所需的功能点整理出来后，或是以某一组功能完成为前提，来进行工期的整体评估，这个时间最好在一周内。
4、团队头脑风暴
按任务从上至下进行分解，大家各抒己见，用加权平均来分析具体工期。这个做法的误差很大，而且要求项目组成员的经验足够丰富，否则不宜采用。
九、参考里程碑提交物
这个就举例说明了，大家看看下面的表格就一目了然了
|
序号
|
工作里程碑
|
前置任务
|
参考提交物
|
|
1
|
项目立项 | 《项目章程》 | |
|
2
|
需求分析 |
1
|
《需求分析说明书》 |
|
3
|
编码实现 |
2
|
《任务分配表》《测试计划》 |
|
4
|
测试 |
3
|
《用例测试》《bug报告》 |
|
5
|
部署 |
4
|
《管理员手册》《操作员手册》《数据字典》《验收报告》 |
|
6
|
维护 |
5
|
《维护计划》《灾难恢复手册》 |
*黑体的文件需客户签字认可
作者：george.hu，发布于2012-11-27，来源：博客园