项目计划排定大致分为5个阶段：项目启动、制定计划、执行任务、监控过程、项目收尾。我们可以通过拆解项目各阶段的具体任务，用19个关键点，再使用对应的工具来高效推动和管理项目。
一、项目计划排定与关键节点
01项目启动
项目启动作为初始化阶段，主要对项目章程等框架性的内容进行梳理和确认。至少包含：明确项目需求、明确项目目标、明确项目范围、组建项目团队（含相关方）……
1、明确项目需求
根据软件的所处阶段、软件属性等要素，软件项目会衍生出多种项目场景。不同场景下的项目诉求也不尽相同，首先需要了解和确认项目要干什么。比如：
自研产品启动：通常是基于公司战略规划而启动的项目，应该和领导了解清楚项目的来龙去脉，从而明晰项目需求。
定制产品启动：针对客户/业务定制化的产品基本都是客户提出诉求，产品经理通过调研和需求分析等方式来澄清项目需求。
常规产品迭代：通常由产品经理根据产品当前发展阶段，从需求池中选择优先级较高的需求组成。
需求一定要述之文字和干系人澄清确认，千万不要自以为很明确。如果理解错误又没确认，项目从开头就走偏了。
有时也会过于“乐观”地分析项目可行性。有时领导抛出命题让下面人验证，下面人预设了“成功”立场来找证据佐证，显然是有失偏颇的。
2、明确项目目标
在确认项目需求时也要同步确认项目目标。我们不能保证自行推演出的目标就是客户想要的。有的项目看重质量，有的项目要快速上线，有的项目要较低的成本……
所以项目目标需要和客户确认清楚，同时注意不是客户说什么就是什么。需要充分考虑资源的配置情况，制定的项目目标应当符合SMART法则（具体的、可衡量、可达到、相关性、有时限）。
客户说要送快递去火星，实在是做不到啊！如果目标是3个月内完成XX业务产品的PC端和APP端研发上线，用户日活达到5千。还是可以商量的。
3、明确项目范围
知道了目标，接下来需要项目干系人明确完成目标必须做的事项，这就是项目范围。范围内应当是必须做的事情，多做会浪费资源，少做会达不成目标。明确项目范围将便于制定更详细的计划以及各项资源的消耗评估。
我们可以通过目标来拆解出需要做的事项清单，再进一步推导出各事项需要交付的成果。
比如在“产品上线运行”项目目标下，项目范围的事项应包含：需求分析、产品设计、UI设计、产品研发和测试、运营推广……这里拆解的事项颗粒度仍然较粗，在后续环节中要继续细化。
4、组建项目团队
事情有了总得有人干活，是时候组建项目团队了……这里的项目团队不只是执行的人员，也不是确定项目范围后才突然冒出来的一群人。项目团队应包含以下4种角色。同时通过角色来识别干系人，弄清楚谁和项目相关，有效选取项目成员。
谁负责：负责执行和协调整个任务的角色。如产品经理、UI、研发、测试、运营等人员。
谁批准：对任务负全责、对进度进行监督的角色。如项目经理（此时由产品经理代行）。
咨询谁：在任务实施的中提供指导意见的人，一般是受项目影响的部门或个人。如业务、运营部分的同事。
告知谁：当阶段任务完成时需要被通知的人员。如上级领导或客户。
确定人员后，针对不同角色的干系人采用不同的管理机制和策略。比如汇报策略、决策策略等。
02制定计划
立项成功后，需要制定一个全面、详细、贯穿项目全部阶段的整体行动计划。项目计划是项目团队的行动指南，因此要充分考虑到项目的复杂性。
一个能够被执行的项目计划应包含以下几点：任务分解、进度规划、沟通计划、制定预算、采购计划、风险管控……
1、任务分解
饭要一口一口吃，事要一件一件做，可根据项目范围来拆解任务。在产品项目中任务分解一般采取先按照实施过程分解，再按照功能模块分解相结合的方式。怎么拆解也有章法可循：
遵循MECE原则：任务拆解要做到全完穷举，不遗漏；相互独立，不重复。
可控的任务粒度：任务颗粒度不能太粗，会看不见细节，把控容易遗漏；太细则过于繁琐，增加管理成本，且无必要。
通过WBS呈现：以可交付成果为导向对任务分组，归纳了项目的整个工作范围。每下降一层代表对项目工作的更详细定义。
任务分解是成功项目管理的名列前茅步。也就是WBS。
总之，无论是使用什么管理工具，任务分解是名列前茅步，学会分解任务,只有将务分解得足够细，你才能心里有数，才能有条不紊地工作,才能统筹安排时间表 。
任务分解之后，你可以使用管理工具来自定义你需要展示什么信息。我的建议是至少展示以下信息：
任务定义：
即使线下沟通过，但是在这里的撰写，还是要尽可能定义清楚，是“确认”还是“交付”，或者“完成”，在工作量上是不一样的概念。
最晚开始与截止日期：
这里没有用“时长”，而是用了“最晚开始”和“截至时间”的组合，是因为，截至时间是每项任务经过最终的deadline加上讨论得到的每项任务的“时长”倒退得到的。所以，截至时间是每项任务必须要保证的。我只需要每个负责人知道这一点。而最晚开始时间是截至时间减去“时长”得到的。
关联任务：
设置前置和后置关联：对于任务之间的影响关系一目了然。A任务<：代表受前面A任务影响，若A任务不完成，我无法开始。>A: 代表本任务是下面A任务的前置任务，若本项任务不完成或有延迟，下面A任务会受影响。这个后面再细说。
当前状态：
项目管理表需要每日检查，时时更新，并将重大变化时时通知给相关方。当前状态可以让每项任务的完成情况一目了然，并将延迟的任务重点标识出来。
负责人：
每项任务都需要指定一个负责人，而时间点和交付物的标准已经得到了该负责人的正式确认。
2、进度规划
煮饭要先把米淘洗干净再下锅添水煮，项目任务情况更加复杂。要求在多重条件（资源）受限的情况下，完成任务合理高效的分配。进度规划主要做这几件事：
任务执行顺序：确认顺序时要考虑任务间的依赖关系，有时Ａ事项的输出是Ｂ事项的输入条件。如研发之后才能测试。
任务优先级别：主要是无逻辑依赖任务间的优先级排序，先核心再边缘，先重要再次要。如先满足核心业务再满足分支业务。
任务工时评估：估算任务执行用时，并设置截止日期。注意预留缓冲时间，为后续风险保留余地。
任务验收标准：各任务需要有对应的交付输出内容和验收标准。既是进度规划也是质量管理，同时方便后续进度监控。
将上述事项做完以后，ＷBS也基本填写完成。
3、沟通计划
每天和人说话时发生的信息传递和接收就是沟通。沟通如此轻松，为什么还要制定所谓的沟通计划呢？因为要“有效沟通”……项目中的沟通计划是为了让各干系人能够及时、准确地获取并理解应关注的信息。
项目沟通的关键要素包含：谁通知、谁接收、通知内容、通知频次、通知方式。沟通方式大家都应该接触过，可根据任务重要紧急程度自行选择方式和频次。比如：
邮件：较为正式，但及时性较差。可作为项目进度的存档，便于后续的追溯。
站会：基本是项目执行人员参与，每日站会可快速了解当前进度、今日计划、当前风险等情况。可结合甘特图使用。
日报：可根据项目阶段调整报告频次。前期变化较多时可日报、周报，项目平稳后可改为月报或关键节点报告。
例会：和站会相似，一般会有干系人参与，在会上报告项目的进度、风险、计划等。常见为月例会或季度会议。
4、制定预算
在“常规迭代产品”类型的项目中较少涉及成本和预算概念，但是“自研产品启动”和“定制产品启动”时一定会核算成本，评估成本和收益之间的比重，估算结果是入不敷出，那项目也就黄了。
以估算的成本为依据制定预算——各事项需要什么资源，多少资源。制定预算细则是为了：
保障实施项目所需资源能够落实；
避免资源使用不当的情况发生；
有效控制实际成本和预算之间的差额；
确保项目任务和资源使用的一致性。
这里的成本、收益、预算的形式是多种多样的，可以是时间、人力、资金、物料等。制订预算需要符合实际情况；描述清晰且具体；涵盖所有活动。具体编制每个项目都不一样。
5、采购计划
不是每个项目都需要采购，涉及到使用公司外部资源才会有采购介入，包含但不限于是软件应用、硬件设备、咨询服务、人力外包等。
我们在本环节的主要任务是列出需要采购的详细清单，至于如何采购，应交由公司的采购人员处理。
6、风险控制
常见风险类别包含：流程、计划、人员、沟通、需求、技术、其他等。风险的存在不以我们的主观意志而转移，风险控制就是预测潜在的各类风险并提供应对措施。控制风险的准备工作应该怎么做呢？
识别风险：根据事项类型建立并不断完善风险项清单，可从其他项目移植经验。注意标记风险可能的触发点。
风险定级：评估不同风险项的重要程度和影响范围，从而帮助更好的建立预警和处理机制。
应对风险：提前预设对应风险项的解决方案，分为风险发生前的潜在风险应对和风险发生后的处理举措。
最重要的还是规避风险，要及时识别，及时预警，及时处理。
03 执行任务
合理的“制定计划”创造了良好的项目实施环境，环境的保持则需要“任务执行”来维护。任务执行是指协调人员和资源，按照计划来管理项目的执行活动。任务具体执行不做过多解释。
从管理角度看，本环节要做到：资源调配、团队管理、沟通管理……
1、资源调配
经过“制定预算”明确了执行所需的资源，在执行中要做的就是合理配置资源。资源调配不等于资源发放，需要全面了解配置情况、到位情况、发放情况、使用情况……
在软件项目中常见资源比如：外部软件平台（第三方账号申请情况）、人力（项目新增成员到位情况）、硬件设备（服务器到位情况）等。结合任务特性和进度规划中所在位置，提前安排即可。
资源在某环节出现异常后，要及时预警和变更调整。涉及风险管控、变更管控、质量管控，在下面详细讲解。
2、团队管理
项目就是临时拉着一帮人干活，是固定搭档也就罢了，如果是由不熟悉的人员组成，在合作上难免需要磨合。此时需要项目经理来建设和管理团队。
团队氛围：人不是机器，精神状态对工作质量起到重要作用。管理员可以以团建等方式提高积极性，避免消极、推诿、埋怨等负能量。
工作协调：磨合就会有摩擦，管理员可以用组织会议了解彼此工作习惯。一方面将人员安排在合理位置，另一方面建立合适的任务衔接模式。
提高积极性不一定是团建，重点在于了解对方的个人诉求，将诉求和项目结合从而打动对方。团建也不一定是聚餐，或许下午的一瓶饮料也能产生凝聚力……
3、沟通管理
项目成员根据预设的“沟通计划”进行沟通，确保双方能够及时、有效地传递和接收。同时有效沟通能够提升管理相关方的参与度，提升支持。举个例子：
需求评审：【产品经理】在【输出PRD】后，通过【邮件、IM】通知【UI、研发、测试、运营及相关方】参与【需求评审会】。
UI评审：【UI设计师】在【输出设计图】后，通过【邮件、IM】通知【产品、研发、测试、运营及相关方】参与【UI评审会】。
用例评审：【测试工程师】在【输出测试用例】后，通过【邮件、IM】通知【产品、研发及相关方】参与【测试用例评审会】。
04监控过程
项目的所有阶段都在监控范围内。监控的作用在于跟踪、审查、调整项目进展是否偏离计划，如果偏离则及时识别变更和控制变更。
随着项目的开展，监控清单不仅包含“制定计划 – 风险控制”的内容，也要及时识别新的风险项。监控内容繁多，应重点关注：整体监控、进度监控、监督沟通、变更管理……
1、整体监控
整体监控负责全面监控项目的执行是否存在偏差。如果触发风险项，立即按照“风险控制”的计划处理。理论上的监控项有很多，根据项目的实际情况进行选用。比如采购监控、质量监控、时间监控和……
范围监控：确认执行的范围是否符合原计划，不能出现多做、少做、做错等情况。范围变化严重影响各项资源、进度、质量。
预算监控：核对各项预算（资源）的分配和使用情况，是否符合在预定的计划内。
确认异常后，优选是拉回原计划，如果拉不回来需要针对性的处理。
常规处理措施比如：增加人员、增加投入时间（加班）、调整人员、调整工作方法和工具，实在不行就降低要求（缩小项目范围、降低质量要求）。
2、进度监控
主要是对项目执行过程中的跟踪，防止团队成员对任务理解偏差或其他因素影响，导致执行阶段出现问题。监控环节的重点是进度监控，进度监控的重点是高风险任务（关键性任务）。
任务监控除了通过“沟通”和“会议”实现，还有一个重要方法是“阶段性交付物审核”。
以迭代产品项目为例，也要经过产品设计、UI设计、研发测试等多环节。所以项目的执行实施阶段会拆解为多个子节点，针对子节点的交付物进行审核。
比如产品经理的PRD文档、UI设计师的设计稿、测试工程师的测试用例、运营人员的运营计划等。
3、监督沟通
沟通为什么要监督？虽然制订了沟通计划，但是项目涉及的多个团队和部门的运作模式并不一样，所以沟通协作的难度较大，从而计划执行的质量得不到保障。为了动作不变形，监督必不可少。
怎么监督沟通？监督沟通不是要参与每场沟通场合，而是建立固定的沟通渠道，要求每场沟通都输出会议纪要。纪要并不强调格式，哪怕是简明的几句话也是可以的。（如果有设置好的纪要模板，每次填写内容也是很好的选择）
唯有如此才能总控于心，不至于监督失效。
4、变更管理
有时为了适应项目运行中与各种关键因素的变化，保证项目目标的实现而对项目计划进行的调整，称之为变更管理。
变更的触发有很多可能，比如客户/领导的想法变化、外部环境变化（政策或市场）、项目资源调整、团队人员调动……
不论基于什么原因，不断变更必然导致项目进度的失控，所以需要建立一套规范的变更管理机制，从而使项目变而不乱。
少数接收入口：任何人都可以提出变更需求，但必须指定一个人做为少数的接收人，一般由产品经理担任。避免到处是口子，无法统筹全局。
评估变更影响：接收后要严格评估变更对项目的影响，没有定论前的变更不能进入执行阶段。执行人不接受任何非产品经理的变更需求。
变更及时预警：评审通过后更新计划阶段受影响的文件，时间、资源、成本等……重点是及时和相关人员同步变更情况，进行预警。
延伸阅读：
二、进度跟踪的关键性活动
首先是获得进度的状态。进度状态通常是检查其活动是否按预期进行。根据不同的检查方法和目的，一般有过程和结果检查，过程检查主要是指定期的项目进度报告。项目中的许多活动需要持续一段时间，需要在实施过程中不断监控其进度，是否按预期进行，是否影响最终完成期。因此，结果检查主要取决于里程碑审查和主观项目进度报告的差异。里程碑审查是通过客观明确的结果评估标准来确定项目是否按进度完成。里程碑审查给出的信息要正确得多。一般来说，一个项目有两种方法可以综合使用。
防止进度延误。此时，需要随时观察和记录项目中的风险，并尽可能采取措施消除风险，减少风险对进度的影响。
纠正进度。一旦发现项目进度确实与标准计划有误差，就需要分析偏差的根源，然后选择两种处理方法，或者改变计划，以反映误差的结果，或者采取纠正措施消除误差，分析原因后，如果确认偏差原因，不会继续影响项目，项目干预者同意改变进度，可以开始改变进度计划。如果我们必须纠正和消除这个错误，我们必须采取一些措施来缩短项目的后续工作时间，那么一般有两种方法，一种叫做赶工，另一种叫做快速跟进。说赶工是项目关键路径上的活动，增加资源，缩短其活动时间。这显然会增加项目的成本。快速跟进是通过改变关键路径上活动与活动之间的依赖关系。但在这个时候，如果这种关系被打破，大多数情况都会给产品质量带来风险。可以看出，缩短项目进度的两种方式都会带来一些不良影响。当然，这个结论也是可以理解的，因为原来的进度计划是平衡各种元素的优异结果。打破这些平衡，那么就会偏离较好，这些其实就是我们所说的项目进度的跟踪。
