0°

做一名合格的项目负责人(三):如何做好项目推进工作?

Lil_Sun+++做一名合格的项目负责人(三):如何做好项目推进工作?+++2019-05-20+++http://www.woshipm.com/zhichang/2346580.html

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

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

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

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

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

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

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

老话都讲低头拉车,抬头看路。今天聊聊如何做好项目推进工作。作为一个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协议

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论