在阿里，我如何做好一个项目的启动？-阿里云开发者社区

阿里妹导读：俗话说“好的开始是成功的一半”，管理一个项目也是这样，项目运行中的遇到的问题往往就是在填项目启动时所埋的坑。一个好的项目启动能极大地提高项目成功的概率，避免项目过程中的很多风险。今天，阿里巴巴项目专家鹿迦总结了一般项目启动的过程，希望能给需要的同学一点参考。

项目启动的构成

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

对于项目启动的环节，又可以分出三个部分：

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

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

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

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

启动准备

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

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

项目目标

大家都知道爱丽丝梦游仙境的故事，里面有一个场景：爱丽丝跟着一个兔子掉进了井里，从而到了一个神奇的世界，在这个是世界里，她迷路了并遇到了笑脸猫。

爱丽丝问这只猫：“请你告诉我，我该走哪条路？”

猫说：“那要看你想去哪儿？”

爱丽丝说：“我不知道要去哪儿。”

猫说，“那么走哪条路也无所谓了。”

——爱丽丝梦游仙境记

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

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

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

项目范围

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

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

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

项目关键里程碑

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

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

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

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

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

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

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

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

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

项目人员组织架构

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

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

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

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

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

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

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

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

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

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

项目信息同步机制

项目信息同步机制的确定是项目启动准备中非常重要的一环，让项目中的信息做到快速平稳的流动，做到项目信息对项目干系人公开透明是降低项目风险、推动项目进展的重要手段。

下面是常见的项目中信息同步的方式，基于不同类型和特点的项目，我们可能会有针对性地进行一些调整，但基本套路比较类似。