走一步看三步-怎么做好进度计划?

没有战争是根据计划而胜利的,但是没有计划,战争也无法胜利。 --艾森豪威尔  

思考下这句话的逻辑。

首先,我们承认战争的胜负受很多计划外因素的影响,计划不是万能的。第二,战争胜利离不开计划,计划是至关重要的。

正如同“钱不是万能的,但没有钱,却是万、万、不能的”。

在项目管理中,进度计划也同样拥有举足轻重的作用。

 

别怕做计划

既然计划如此重要,可却有很多人从心底害怕或排斥做计划。

表面上看,人们会声称自己不喜欢受约束或被限制,自由随性才能让激发更大的创造力。这些论点看似无可厚非,特别是创意性或探索性的工作。做计划限制了创作,这种观点站得住脚吗?

严格约束下的创作会将想象力的翅膀完全伸展,并迸发丰富想法;在彻底自由下创作可能使作品散作一盘沙。--T.S.艾略特(T.S.Eliot) 

自由与约束并不矛盾,很多例子表明,约束和限制反过来会帮助创作,比如唐诗、宋词的韵律,等等。

计划的本质,是团队对何时完成任务的承诺。从心理学层面来分析,排斥做计划的真正原因,在于人们不愿轻易做出承诺。人人都有一种言行一致的愿望,一旦我们做出承诺,来自内心和外部的压力会迫使我们按照承诺去做。但也正是由于这种下意识的一致性倾向,才让进度计划真正有效。

或许你会说,“我们并不是没有做计划,但计划执行往往是有问题的,做了也没用啊”。

因为计划执行有问题,就不去做计划。 这种逻辑无异于因噎废食。

  

计划要趁早

定计划时经常会听到有人说,等策划案定了再说把,现在也不知道具体做什么,计划做了也是白做。

的确,任何人都很难在早期估计一个项目所需要的时间。说实话,刚刚接触项目管理时,我也是这么想的,后来几次实践下来,渐渐领悟到“越是有太多不确定,越应该给出计划”。在混乱不清的状况下,你根据仅有的少量信息给出了期望值,就好比挖了个坑,人们自然会来填满它。马上就会有人跳出来指出这个时间点肯定不行,那里不靠谱,渐渐的计划变得越来越充实,越来越准确。更有意思的是,经历了这个指手划脚的过程之后,你会发现人们开始下意识地按照计划做事,那个最初不靠谱的计划竟一步步变成了现实!

项目经理应该做头一个挖坑的人,引导团队拨开重重迷雾,将所有不确定一一落地。否则,模糊的概念永远只停留在高层或某个人的脑袋里,不会对团队产生任何实质的影响。

做项目如同下棋,高明的棋手,走一步看三步。好的计划必须是领先于项目实际,要有一定预见性。

 

调计划要谨慎

计划绝不是固定不变的,相反,计划是调整的基础与依据。在整个项目周期中,为应对随时可能出现的变更,计划永远是个反复修正、“渐进明细”的过程。另外,在项目进程中,随着信息越来越详细,估算会越来越准确。因此,计划需要持续的改进与调整。

但,计划的调整绝对需要谨慎,一个天天调整的计划会渐渐失去公信力。重要的是,要确保项目中每个人知道当前的计划是什么,调整计划需要怎样的决策过程,都需要谁参与决策。在我们项目中,与进度计划有关的任何变更,都会提交至项目经理,由对应功能小组成员(该功能模块涉及的策划、设计、开发、测试)及其他相关方共同讨论,明确各方影响,最终做出决策,并公告所有项目组成员。 

 

计划诞生记

计划是“市场需求或高层期望”VS “团队生产力”两者之间平衡的结果。

项目的每个过程都需要做计划,计划应该贯穿项目始终,持续细化调整。具体来讲:

项目立项前,这时的计划比较粗略,可将目标按照功能体系分割成几个重大里程碑,并给出里程碑完成的时间点预期。根据项目周期长短,时间可以是估算到季度或月。此时的重点要给出立项的时间表,如下图所示,何时完成初期调研及评估,何时做好立项准备,启动项目。立项时间表使得项目各资源方有了明确的预期,以便提前做好资源调配。

 

项目立项后,各项人力资源逐步就位,根据对团队生产力的经验估计,结合启动过程中对里程碑的大致预期,进一步推导出需求确认、设计确认、功能完成等中间节点。

 

需求确认后,由设计、开发、测试一起做WBS将工作细化分解。根据分解后各部分工作量的详细估算,项目各方人员共同讨论,对计划进行细化调整。此时需进一步明确以下时间点:设计确认、功能完成、zero bug(零缺陷)、code freeze(发布前代码冻结),以及里程碑完结日期。

 

至此,一个里程碑的计划已经基本成型,在接下来的执行过程中,需要不断监控计划执行情况,识别并应对风险及各种变更,适当调整计划中各时间节点,并确保相关人员及时获知计划变更情况。

有时,我们需要对里程碑进一步划分,做更细粒度的计划,参见最后一节“怎么做好计划”。 

 

别忘了完成标准

简单来讲,完成标准就是该时间点需要完成的事项列表,或应该达到的某项指标(特定水平的bug数量/性能指标等)。进度计划中的任何重要时间节点,都应该有一组完成标准。完成标准越早定义,计划按照期望完成的概率就越大。

以里程碑中最关键的几个时间节点为例,完成标准如下:

需求/设计确认:执行所需的需求稿/设计稿已经完成(有时,并不一定需要全部完成,可以是完成可接受的比例或核心部分完成,具体标准需要准确定义),团队已准备好要编写产品代码。 

功能完成:所有定义的功能都已经完成(已通过冒烟测试,但允许有质量差距或BUG存在),团队已经准备好将焦点转移到质量保证上,所有剩余问题都将作为BUG来跟踪。 

里程碑完成:质量已达到适当水平(如不存在高优先级的Bug等),可以上线发布,或可以开始下个里程碑。

 

克服估算焦虑

做计划就离不开估算,很多人有估算焦虑,这很正常。我们承认估算是困难的,所有估算都是一种概率事件。越早做估算,准确度越低,但只有进行粗略估算才能拥有一个起点,以做更好的估算。

大多数人利用直觉的本能反应来进行估算,通常小团队短周期的项目,这种估算可以起到很好的效果。除直觉之外,有些方法可以帮助我们进行更好的估算,比如昨日天气法(也叫yesterday‘s weather),通过分析团队的历史数据,得出生产率的估计。如果是一个新的团队没有历史数据积累下来,参考下类似条件下的其他团队。

以zero bug时间点的估算为例,我们就可以参考这个团队在之前的工作中,开发每天平均修多少个bug,测试每天平均新发现多少个bug,使用公式“当前有效bug数 + 测试新报速率×X天 = 开发修复速率×X 天” ,通过简单的计算就可得出天数X的值。去除节假日,并根据项目人员的投入情况留出一定的缓冲,zero bug时间点就算出来了。

估算是一项能力,通过反复的练习,估算的准确率能够得到有效提高。

 

怎么做好计划?

首先,好的计划一定是团队共同参与所达成的。

在很多项目中,我们注意到计划往往是某个leader自己拍脑袋就确定了,其他人只有执行的份儿,这样的计划在执行过程中,会面临更大的风险与挑战。计划的本质是承诺,心理学告诉我们,要想让承诺更加有效,它必须得是当事人积极地、公开地、且经过一番努力后自由选择的。计划最终是要整个团队来共同执行的,那么制定计划就必须是项集体活动,参与(involve)所带来的责任感能带来持久有效的承诺,千万别低估这一点。虽然共同参与会带来一定的成本,但实践表明,让相关人员公开参与计划的制定过程,对于提高计划的接受度,保障计划的顺利实施有极大的促进作用。

其次,善于规划的人,会把里程碑分割成一个个的小的阶段,分而治之

例如,持续一两个月的功能开发期,一般会拆分成多次迭代来进行管理。那末计划要做到什么粒度?这里的原则是,方向越容易改变,变更越频繁,迭代的长度就要越短,反之亦然。每个迭代都需要制定单独的计划及完成标准。优秀的项目管理,要把握项目的节奏,张弛有道。

最后,好的计划必须跟进

最怕计划做了就不再看了,那不是计划,那是一张废纸。做了计划就必须跟进!

评论

© 蓓蓓—PM的修炼 | Powered by LOFTER