项目由一个又一个环节构成，本文将其拆分为目标、计划、进度、风险、复盘五个部分，并分别对每个部分进行了详细讲解，帮助大家了解身为项目负责人该如何做好项目推进工作。

最近观察到很多同学着急忙慌地做事，但在很多最基本的工作上犯错，持续犯错。准备花点时间把工作过程里已经形成肌肉记忆的东西整理出来。我个人风格偏向解决实际问题，所以会更多讲一些拿来即用的小技巧。无论你是什么岗位，工作方法与决策模型底层都是互通的，希望能支持到有意愿自我提升的同学们。

准备写成一个系列，估计会很长，尽量不断更。

我们先来谈谈第一个话题“如何成为一个合格的项目负责人”。小到一个业务节点，一个项目组，大到一条产品线，一个事业部，你都会获得独立负责工作的机会。机遇到来时，希望你已经做好了准备：）

这个话题相对比较庞大，细节也比较多，我会分成几篇文章来讲解：本文是这个系列的第三篇

• 报信 | 如何做好信息同步工作
• 摇人 | 如何做好资源协调工作
• 拉车 | 如何做好项目推进工作
• 铲事 | 如何做好危机处理工作

拉车 | 如何做好项目推进工作

老话都讲低头拉车，抬头看路。今天聊聊如何做好项目推进工作。作为一个it从业者，这个话题应该都不会陌生。对这些老生常谈的内容，我做做梳理，分享一些个人的观点。我将一个完整的项目过程拆解成目标、计划、进度、风险、复盘五个部分，后文也会按照这个结构表达。

关于目标

基本上所有人都认可目标的重要性。这里就只谈一个基本知识“目标导向”。拿我们都听过的一个思考模型来举例。大到一个产业，小到一个文案修改的任务都存在背景、现状、目标、方法四元素。这四个元素按照逻辑顺序自上而下排列。我是这么理解他们的：

• 背景：交代前因后果，相对宽泛。描述事实和隐藏的约束条件。我个人的习惯是只同步事实而不加判断。
• 现状：与背景信息强关联，大多数情况是由背景中描述的事实和约束条件，推导出的判断。项目是否做的说服逻辑之一。
• 目标：要解决的问题或要收获的结果。比如：提高日活，召回老用户，增加业务收入。目标一定是明确的，可衡量的。项目是否做的说服逻辑之二
• 方法：也叫手段，方案。是把目标兑现的过程

我是这么理解四个元素之间的关系的：背景、现状、目标这三个是常量，而方法是变量。

在立项阶段我们的方法都是服务于目标的。一般我管项目的初始阶段叫蜜月期，这个阶段都比较顺利。但随着项目过程的推进，大概率会出现计划内的事情做了但是没效果或者收效甚微的情况。这种意外的出现会让负责人们的基本功出现变形，方法和目标不再紧密结合，开始出现裂缝。于是喜闻乐见的情况出现了。各种各样“灵光一现的点子”开始冒出来，越做越错（也是产品被研发诟病的地方）

所以，没有彻底执行目标导向的工作原则是症结所在。
有的时候我会要求项目负责人恪守在项目启动时定下的目标，只做与目标达成强相关的事，少做甚至完全不做与目标达成弱相关的任何事。

让他们有权say no！

这样看起来比较死板和严苛，但是可以保证资源有限的情况下不做无用功。所谓的不见兔子不撒鹰说的就是这个道理。当然，也并不是一条路走到黑。

前文说过，方法是变量。如果收效有限，大家讨论变更方法。怎么找方法是个强依赖经验和个人业务能力，本篇暂不展开以后成文来讲。

关于计划

计划是项目过程中的框架，是确保执行稳定的有效方法。一个好的计划好比航行时的地图，除了让我们知晓进度，方向之外还能让我们有效管理风险。我在之前的文章中写过如何制定计划，方法很多不再一一赘述了。

我个人比较习惯使用朴素的思考方法来进行计划整理，核心是不断询问自己，再向协作上下游确认：

• 要达成xx目标，我们要办哪些事儿？
• 这些事之间的关系是什么？有依赖性吗？

计划是典型的重要不紧急的事项。我提议尽可能做到精确，但不需要事无巨细。

这句话有点儿反直觉。我澄清一下：

• 尽可能精确的要点是别漏掉事
• 不需要事无巨细，即计划阶段关注三步之外的事，而非眼前的一两步棋

对粒度的把握，就很重要了。举个例子：

因为很久没有人维护，我们要对由用户贡献内容的模板中心的内容清洗。

这是一个短期一次性内容，那么粒度便可以细一些。

计划记录在0.5~1天比较合适。模板共计1500个，需要3个工作日，每个工作日完成500个即可完成。很轻松地整理出一个可行的计划。

我们要进行一个公司级别的系统对接项目。

初步整理除了30个工作事项。

这是一个长期的迭代项目，粒度可以粗略一些，计划记录在1周就比较合适。

按照敏捷的工作方法预估总共75个工作点，研发团队一周5个工作日的生产力在7个点左右。额外增加一些buffer时间，预计完成的周期在12个工作周左右。

粒度过于致密会让团队处于紧绷状态，引发抵触情绪；粒度过于松散自然而然会产生懈怠，徒增风险。以上这两种都是不利情况。

除此之外，计划中最好包含一些紧急预案。预案可以帮助我们提前设计好一旦有什么情况发生，就用相应的机制去应对。这部分在后文-风险部分详细说。

所以，我认为好的计划的原则是：

• 精确的梳理
• 合适的粒度
• 不可控因素的预案

计划的制定对很多经验丰富的人来说都形成为肌肉记忆。建议有意愿成为项目负责人的同学主动练习和尝试。完整地跟完二至三个项目后，必有收获。

关于进度

进度是校验工作完成度的可衡量指标，他可以把“快了/大概/基本上”这种虚的表达变成具体，可感知的表达。我个人比较习惯按照百分比的方式来同步：

项目完成了52%

时间过去了60%

目前进度落后预期8个点，会通过xx补回短缺进度

scrum的四个会议，计划会议，每日站会，验收会，回顾会议。其中每日站会是解决进度问题的。

每日站会：项目组内部的进度沟通会，我建议每个人的汇报时间不超过180秒。同时汇报过程中只关注三类话题：

• 昨天的工作进度
• 今天的工作计划
• 需要团队知晓的信息及自己需要的支持

需要注意的一点是，进度汇报的阶段是不追责，不分析问题原因的。我们这样做是尽可能保证整个团队的效率，不会掉入扯皮中。有紧急问题的话，邀请相关责任人单独发起会议讨论直至问题被解决就好了。至于更复杂的问题，比如涉及外部（项目组以外）条件，怎么解决它，属于复盘这个部分，我们在最后环节讨论。

有些职场关系课里提到，定期汇报是职场里的小仗，要利用日常的机会建立威信。我个人是持反对态度的。在利己的事件上浪费大多数人的时间，不经济，不体面，不推荐。

至于怎么汇报，技巧是什么，用什么方式汇报请查看之前的文章，里面已经写得很详细了。

关于风险

分享一则小故事：

老王是一名驾驶技能过硬的老司机，驾驶时遵守交通规则，一直安全行驶。有一天上班路上正常行驶结果出事故了。

老王是一名驾驶技能过硬的老司机，有一天上班来不及了超速+走应急车道，结果出事故了。

进结果看，俩老王都出事故了。但底层是不太一样的。

风险在项目过程中是客观存在，只要开车就存在系统性风险，很难避免「你遵守规则，不代表别人就不会撞上你」

但你能做的是遵守交通规则，这就是我们选择了不主动提高系统性风险的方法「你遵守规则，降低事故的发生概率」

风险是无法被消灭的，妥善管理他们就好。那么问题来了，怎么做？

第一，我比较推崇的工作方法是：

• 在计划阶段假设各个环节都会出现问题
• 为每个风险点准备一个应急预案
• 每个应急预案关联一个对接人

第二，我比较信奉的一句话“十卒不如一将，十将不如一王”。（来自纯银）

目前阶段团队较小，我个人的习惯是更关注人。一旦开启周期较长的项目，我在开始前会花至少半小时的时间跟团队每个人做沟通。目前规模下，我有足够精力了解每位成员当前的状态。比如是否要休假，工作成就感如何，是否有不爽的地方，以便于在合作中避免内耗。

人的状态对路了，很多风险就会被自然而然地内化掉。这个点有些玄学，但就我个人经历来说，士气低迷的团队好比屋漏偏逢连夜雨，铲不完的事。有精力的时候还是要关注的。

关于风险识别，风险管理的知识我目前掌握的有限，在成熟一些之后再来分享了。

作为员工，没有人愿意于一天到晚铲屎应对计划外的事，都期待从容不迫，游刃有余的工作状态。说白了，你的计划质量越高，预案越完备，你的日常状态就能离体面更近一点。

关于复盘

scrum的四个会议，计划会议，每日站会，验收会，回顾会议。其中回顾会议专门用于解决复盘的问题。

回顾会议（Retrospective Meeting）的时间会相对长一些，也必须提前做准备工作。在我的团队中我们管这类会议叫Retro，我们是这样做的：

1. 准备好便利贴，笔，计时器。邀请项目组成员加入
2. 每个人用5~10分钟写下来哪些做的好，哪些做的不好，哪些问题需要讨论
3. 将自己的便利贴贴到白板上，由主持人朗读确保每个人的意见都被听到
4. 对所有便利贴进行归类，对待讨论事项进行投票
5. 票选排名前三的议题进行讨论（一般不会很多，多的话就是粒度没处理好）
6. 每个议题提供5~10分钟时间讨论，直至得出「谁，负责什么事，在什么时间完成，达到什么目标」结果

要点：

相比进度同步的会议，回顾会议是要直面错误和避免错误再次发生的，本质上这是个严肃的会议。但是这种议题往往伴随着冲突（情绪和利益的），所以我提议张弛有度。过程可以轻松一些，准备一些小零食饮料来帮助大家放松。但立场上要表达严肃。

以往的Retro，我司是按照半年一个周期来做的，我个人觉得收效不大。在我的项目组内将频次提高到一个月一次，一个季度下收效还不错。当月问题，在次月就能得到解决。团队的士气在正向循环里，也就相对顺利。

总结

项目推进是一个又一个的工作自循环，积极主动的思考会让我们更快的成长。作为项目负责人，项目推进能力是基本功中的基本功。

作者：Lil_Sun，公众号：maxiwenfine

本文由 @ Lil_Sun 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议