整个项目出现的第一步，是从一个想法到一个项目的孵化过程，这个阶段的主要目的是证明把一个想法变成一个项目是否有价值、是否符合我们现阶段战略的方向、是否有足够的ROI等。声明一下哦本文是基于PMP的框架的。
上周群内连续三天有产品同学问到项目管理方式、流程、协同软件、迭代周期、敏捷项目管理等一系列项目管理相关问题，大家也都有一些个人和公司层面对项目管理的理解。
本文是由孟金桥（前爱奇艺iOS开发工程师，前点我达iOS高级开发工程师， 前阿里高级无线开发工程师）在大产品之路五年产品三年模拟群的分享，小助手认为是相对比较系统的比较全面的讲述，原文在语雀不易阅读，故整理成公众号文章的形式，输出给群内的五年产品经理。文章过长，一次阅读时长过长，故此分成上下两篇文章来发。
项目启动的构成
首先我们看一下项目启动在整个项目管理过程中的位置。基于PMP的框架，一般我们把项目管理分成了五个过程组，第一个过程组就是项目启动。
项目管理过程组
对于项目启动整个环节，往往又可以分为三个部分：
- 项目价值研究
- 项目启动准备
- 项目的启动会
项目启动组成
价值研究
整个项目出现的第一步，是从一个想法到一个项目的孵化过程，这个阶段的主要目的是证明把一个想法变成一个项目是否有价值、是否符合我们现阶段战略的方向、是否有足够的ROI等。这个工作往往是由业务和产品同学参与的，价值研究的一个明确的输出就是MRD，只要通过了MRD评审的项目，我们才可能进入项目的启动准备阶段。
启动准备阶段
我们整个项目启动过程中最最重要和花时间的部分，作为一个PM（项目经理），需要花最多最密集的时间在这个阶段，这个阶段也是本文重点介绍的部分。
启动会 Kickoff
项目启动会是项目启动阶段的一个高潮，也是一个终点，所有启动准备的付出就是要在个会上做一个整体的亮相，在项目启动会之后项目正式进入规划和执行阶段。
启动准备
对于项目的启动准备，最核心的是要澄清几个问题：
- 项目目标是什么？
- 项目包含的内容（范围）是哪些？
- 项目的关键里程碑怎么确定？
- 项目的人员组织架构是怎么样的？
- 项目的信息怎么同步，怎么做决策？
项目目标
忽视目标是项目管理中一个比较常见但又非常致命的问题。
项目目标一个重要的要求就是必须满足SMART原则，我们千万要记住项目结束的时候就是要用这个目标来衡量我们项目的成败，如果是一个不能用来清晰指导我们判断项目成败的目标一定是一个不好的目标。
项目目标一定要清晰写出来，并获得项目发起人和主要干系人的确认，有了项目目标，后面的工作才能有据可寻。
项目范围
项目范围确定了在项目里做什么和不做什么。项目范围是逐步细化的，在启动阶段不强求细化到具体的需求粒度，但必须确定范围和边界，这样才能确定干系人，框定投入项目的人力资源；
确定项目范围的过程可以理解是一个先发散再收敛的过程：
- 在开始的时候要involve更多的项目关系人参与到项目范围的收集和讨论中来，目标是防止重要的项目范围被遗漏。常见的情况是只关注了功能性的需求，而遗漏了性能、可测性、运营支持类的需求，导致项目进行中才发现，导致项目范围扩大，项目交付时间不可控；
- 为了保证项目效率和ROI，我们肯定不能接受包罗万象的项目范围。当经过充分的项目范围发散之后，就要开始项目范围的收敛了。项目收敛的方法有很多：
- 需求和项目目标的关联程度
- 项目时间和项目资源投入的限制
- ROI（投入产出比分析）
- 需求是否可验收可度量
项目范围形成
项目关键里程碑
项目启动准备的第三个非常重要的事就是确定项目的关键里程碑。
里程碑是项目组根据历史的项目经验或者参照其他项目，团队做的水平，制定的里程碑，是大家达成一致的结果，是项目的内部基准，大家都按照这个做事。这种里程碑由于是柔性的影响项目，更加能够体现项目管理水平。
里程碑不等于期限：期限（deadline）其实没有什么可讲的，那是强制性的约束条件，你必须遵守。但是里程碑不是，它充其量在约束方面算是参照系，而不是强制约束。
而期限或者deadline是强制性的约束，不是项目组能左右的了的。比如商务合同，订单，备忘录等书面或者口头承诺的。这种里程碑是外部的。你不执行，就要准备承担相应的后果。考虑到后果和商誉的影响，这些是强制性的，都是要做的。如果变更，就准备好承担相应责任。
在不同的项目情景里，我们可能会用到不同的项目关键里程碑划分的方式，最常见的两种方式有：
- 强调过程的按阶段拆分
- 强调结果的按迭代拆分
项目关键里程碑拆解方式
在软件项目管理中，按阶段拆分在瀑布模型中比较常见，比如拆成需求分析、设计、编码、测试、上线等阶段。按迭代拆分敏捷模型中比较常见，比如拆成用户支付、用户下单等功能点。这个都需要基于你的项目特点和环境慎重的判断和选择。
其次，在软件开发中错误发现得越晚，对于开发造成的损失越大。里程碑式开发模式可根据每个阶段产出结果分期确认成果，避免血本无归。通过早期里程碑评审一般可以提前发现需求和设计中的问题，降低后期修改和返工的可能性。例如，在需求分析阶段发生的错误，那么最多就是把需求分析写一遍，损失的是一个人的劳动;而到了测试阶段发现了需求错误，再回去重新做需求分析，那么损失可能是致命的。
而且一般人在工作时都有前松后紧的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理粒度。对复杂的软件开发项目而言，每一阶段的进度都需要逐步逼近目标，里程碑产出的中间“交付物”就是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间想知道“现在进度做的怎么样了”是很困难的。
