好的开始是成功的一半 -- 怎么做好一个项目的启动-阿里云开发者社区

俗话说号的开始是成功的一半，管理一个项目也同样是这样，很多的时候，项目运行中的遇到的问题往往就是在填项目启动时所埋的坑。一个好的项目启动能极大的提高项目成功的概率，避免项目过程中很多的风险。这里我简单总结一下一般项目启动的过程，希望能给需要的同学一点参考。

本文附件有实用项目启动信息模板工具（项目章程）下载，对理论不感兴趣的可以直接拉到最底下，拿走不谢。

项目启动的构成

首先我们看一下项目启动在整个项目管理过程中的位置。基于PMP的框架，一般我们把项目管理分成了五个过程组，第一个过程组就是项目启动。

对于项目启动整个环节，往往又可以分为三个部分：

项目价值研究
项目启动准备
项目的启动会

价值研究是整个项目出现的第一步，是从一个想法到一个项目的孵化过程，这个阶段的主要目的是证明把一个想法变成一个项目是否有价值、是否符合我们现阶段战略的方向、是否有足够的ROI等。这个工作往往是由业务和产品同学参与的，价值研究的一个明确的输出就是MRD，只要通过了MRD评审的项目，我们才可能进入项目的启动准备阶段。
这个阶段一般情况项目经理往往都没有参加，所以本文暂先跳过对这个阶段的介绍。

启动准备阶段是我们整个项目启动过程中最最重要和花时间的部分，作为一个PM（项目经理），需要花最多最密集的时间在这个阶段，这个阶段也是本文重点介绍的部分。

启动会项目启动会是项目启动阶段的一个高潮，也是一个终点，所有启动准备的付出就是要在个会上做一个整体的亮相，在项目启动会之后项目正式进入规划和执行阶段。

启动准备

对于项目的启动准备，最核心的是要澄清几个问题：

项目目标是什么？
项目包含的内容（范围）是哪些？
项目的关键里程碑怎么确定？
项目的人员组织架构是怎么样的？
项目的信息怎么同步，怎么做决策？

项目目标

大家都知道爱丽丝梦游仙境的故事，里面有一个场景：爱丽丝跟着一个兔子掉进了井里从而到了一个奇异的世界，在这个是世界里她迷路了并遇到了笑脸猫。所以爱丽丝就问这只猫：“请你告诉我，我该走哪条路？”，猫说：“那要看你想去哪儿？”，爱丽丝说：“我不知道要去哪儿”，“那么走哪条路也无所谓了”猫说。

忽视目标是项目管理中一个比较常见但又非常致命的问题，俗话说“不忘初心”、“以终为始”就是常见的针对这个问题的提醒。

项目目标一个重要的要求就是必须满足SMART原则，我们千万要记住项目结束的时候就是要用这个目标来衡量我们项目的成败，如果是一个不能用来清晰指导我们判断项目成败的目标一定是一个不好的目标。

项目目标一定要清晰写出来，并获得项目发起人和主要干系人的确认，有了项目目标，后面的工作才能有据可寻。

项目范围

项目范围确定了在项目里做什么和不做什么。项目范围是逐步细化的，在启动阶段不强求细化到具体的需求粒度，但必须确定范围和边界，这样才能确定干系人，框定投入项目的人力资源；

确定项目范围的过程可以理解是一个先发散再收敛的过程：

在开始的时候要involve更多的项目关系人参与到项目范围的收集和讨论中来，目标是防止重要的项目范围被遗漏。常见的情况是只关注了功能性的需求，而遗漏了性能、可测性、运营支持类的需求，导致项目进行中才发现，导致项目范围扩大，项目交付时间不可控；
为了保证项目效率和ROI，我们肯定不能接受包罗万象的项目范围。当经过充分的项目范围发散之后，就要开始项目范围的收敛了。项目收敛的方法有很多：
- 需求和项目目标的关联程度
- 项目时间和项目资源投入的限制
- ROI（投入产出比分析）
- 需求是否可验收可度量

项目关键里程碑

项目启动准备的第三个非常重要的事就是确定项目的关键里程碑。

里程碑是项目组根据历史的项目经验或者参照其他项目，团队做的水平，制定的里程碑，是大家达成一致的结果，是项目的内部基准，大家都按照这个做事。这种里程碑由于是柔性的影响项目，更加能够体现项目管理水品。

里程碑不等于期限：期限（deadline）其实没有什么可讲的，那是强制性的约束条件，你必须遵守。但是里程碑不是，它充其量在约束方面算是参照系，而不是强制约束。

而期限或者deadline是强制性的约束，不是项目组能左右的了的。比如商务合同，订单，备忘录等中书面或者口头承诺的。这种里程碑是外部的。你不执行，就要准备承担相应的后果。考虑到后果和商誉的影响，这些是强制性的，都是要做的。如果变更，就准备好承担相应责任。

在不同的项目情景里，我们可能会用到不同的项目关键里程碑划分的方式，最常见的两种方式有：

强调过程的按阶段拆分
强调结果的按迭代拆分

在软件项目管理中，前者在瀑布模型中比较常见，比如拆成需求分析、设计、编码、测试、上线等阶段。后者敏捷模型中比较常见，比如拆成用户支付、用户下单等功能点。这个都需要基于你的项目特点和环境慎重的判断和选择。

其次，在软件开发中错误发现得越晚，对于开发造成的损失越大。里程碑式开发模式可根据每个阶段产出结果分期确认成果，避免血本无归。通过早期里程碑评审一般可以提前发现需求和设计中的问题，降低后期修改和返工的可能性。例如，在需求分析阶段发生的错误，那么最多就是把需求分析写一遍，损失的是一个人的劳动;而到了测试阶段发现了需求错误，再回去重新做需求分析，那么损失可能是致命的。

而且一般人在工作时都有前松后紧的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理粒度。对复杂的软件开发项目而言，每一阶段的进度都需要逐步逼近目标，里程碑产出的中间“交付物”就是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间想知道“现在进度做的怎么样了”是很困难的。

项目人员组织架构

确定项目人员组织架构按PMP的说法也叫识别项目干系人，这个是项目管理中一个非常关键的事情。

项目干系人我们可以从这两个维度来识别：

参与项目的人，跟项目有直接关系的
参与项目的包含：项目团队、项目经理、职能经理等；项目发起人；业务伙伴、合作厂商、第三方资源等等。
- 受项目影响和影响项目的人，受项目影响或影响项目的包含：客户/用户；政府或社会团体机构；普通公众。

识别干系人我们不光是把干系人找出来就可以了，还需要识别每个干系人对项目的需求和期望、对项目的贡献、影响及其制约作用等这些都是要整理记录下来，准备后续的管理。

对于不同的项目关系人，我们在项目管理的时候应该采用不同的管理策略：

权力大且项目相关利益大的要重点管理：他们有很高的权力，也很关注项目的结果，项目经理应该“重点管理”，跟他们明确项目目标，使其积极的参与到项目中来；频繁的与这区域的干系人沟通，并听取他们的反馈建议，让他们满意。项目的客户、主管领导就是这块区域的人。
权力大但项目相关利益不大的要令其满意：他们有很高的权力，但对项目的相关性不是很大，这一区域的人项目经理应该定期向他们汇报项目的进展结果，这一部分人更关注结果，不需要了解细节。我们要保证这一部分人满意，尽量不要让他们影响项目的正常进展。
权力小但项目相关利益大的要随时告知：项目结果会直接影响到这一部分人，所以项目的进展、变更等等一系列的事情，都应该随时告知这部分人。
权力小且项目相关利益也小的要最小关注：利益低权力也低，花很少的精力关注下即可。

识别出项目关系人是第一步，下一步我们要梳理出项目的关系人组织架构，理清关系人之间的业务关系。最常见的我们有两种干系人组织架构图：

一种是基于项目组织相关方的梳理方式，如把项目核心工作团队和周边相关组织分离出来，明确项目核心工作团队和上层管理决策团队、兄弟依赖团队、行业运营团队等部门之间的关系。目标是明确在项目中各个组织的定位和职责；
第二种是基于项目任务的拆分，明确各个子系统、模块的负责人，这样的好处是确定每个干系人的职责范围和项目工作汇报关系；

但要强调的一点是识别干系人是需要持续识别并贯穿项目的始终的事情：

干系人识别不可能一步到位一下子就全部识别出来，虽然在启动阶段识别全部的干系人一般会作为目标，但是这是一个几乎不可能完成的任务。因为不同的项目阶段，项目的干系人会不同。
项目在运行过程当中，干系人也是会发生变化的，当干系人发生变动时，要重新对干系人进行识别和评估，并主动投入精力进行沟通和交流，力争新的项目干系人是为项目服务的。
干系人对项目的态度也会发生变化，开始时支持项目的干系人，如果在执行过程中干系人发现项目已经不再符合他的利益，甚至损害他的利益，则可能会从支持者的角色转变到反对者的角色，这种态度上的变化，我们也要随时关注和识别，不断更新这些信息。项目管理要求尽早的识别和面对负面干系人，并且一视同仁，如同对待正面干系人一样，力争将负面影响转换为正面支持，忽视和冷漠负面干系人会一定程度提高项目失败的可能性。