什么?项目延期有解药?

最后,项目延期是客观存在的事实,你会选择红药丸,还是蓝药丸?

摘要:当我们要考虑如何让项目不延期时,我们是否做到让每个员工都满负荷了?我们追求的是不延期,还是追求更卓越的产品?

这一两个星期和同事讨论如何使用看板进行项目管理时,总的来说,我遇到最频繁的问题有:

  • 如何能看出项目是否延期?
  • 如何拆任务?

其实,我遇到的问题是:如何能看出项目是否延期?然后经我将问题深挖,才发现他们更本质的问题是:拿到需求,如何拆任务,拆到什么粒度。

讨论这类问题,最好举个例子,否则整个讨论过程会很虚。

比如我们的项目经理从产品经理那里拿到一个需求:改版APP。这款APP有12个界面,所有的界面都需要改。而你手下有6个人。

这时,可以以两种粒度来拆分:

  1. 以界面为粒度
  2. 拆分成更可以量化的粒度。

关于什么是可以量化的粒度,下文会阐述。

按界面粒度来拆分

可以看出,以界面粒度来拆分,简单粗暴:24人天的任务,我们有6个人,所以,理论上我们只需要4天完成“改版APP”。我们可以很容易看出这个项目是否延期,只要每个界面都没有延期。

放到看板上,理所当然,每个界面一张卡。

现实中,我们的项目经理可能还会这样分到人头上:

为什么一定要分到人头上?除了方便KPI(表面上),背后还有一定的文化因素:因为当项目延期时,我们就可以找出那个相应的人进行问责。这种问责的机制导致的后果:人们更愿意推卸责任,而不是共同协作。

放大一些这个问题,公司内部多个技术部门也会因为这种问责的文化,导致部门之间更趋向责怪对方不按期,而不是共同协作完成一件事情。

再再放大一些这个问题:在人们的意识里往往认为,问责后,坏的事情就可以避免问题再发生。放到我们本篇文章讨论的上下文里,也就是问责可以避免延期。但是,可能吗?因为延期已经发生,我们应该在延期发生前进行协调资源来解决延期。

我们举个例子:在项目进行的过程中,人员B在做界面3,4时,在第3天时被一个问题卡住了。而人员C其实在第3天时就已经完成了,第4天开始优化。其他人准时完成了自己的任务。最后人员B的延期导致项目延期了2天。这时,如果你问责人员B,那么,这次的延期能倒退吗?也许你会说,问责后,这个人下次就不会延期了。

我想说:

  1. 延期不延期和你问责没有任何关系。如果有关系,你在项目开始时,就每个人问责一下,这样项目就不会延期了?
  2. 我们应该追求的是每个项目都不延期,而不是下一个项目不延期
  3. 我们追求的是不延期,还是追求更卓越的产品?

回头看这次延期,也许我们是可以避免的,比如在第3天的站会上,人员C说出自己被某个问题卡住了。这时,可能其他人员一句话就点通人员C的问题了。还有可能是人员C遇到的问题是需要其它部门来协助才能根本解决,这时项目经理就需要与其它部门沟通了。

回到问题“按界面粒度来拆分任务”这个问题本身。

将界面再拆分成可量化的粒度

这种方式要我们的项目经理拿到需求后,让最熟悉这个APP的人或团队对需求再进行拆分成一系列工作单元,然后再分别估算这些工作单元在现有的人员基础上需要多少天。最后估算出一个总的交付时间点。我们假设完成这个需求,我们同样需要4天完成。

至于拆分到什么程度,就是我们上文提到的可量化的程度。

什么叫可量化?

上面我们看到将需求拆分成一系列工作单元后,我们可以更灵活的安排优先级。同时,这样也帮助我们发现界面1和界面2有一个工作单元3是有交集的。有交集的工作单元,我们应该让同一个人来完成以避免其中的沟通成本。总的来说,拆分成一系列可量化的工作单元后,我们可以:

  • 更灵活的优先级调控
  • 发现有交集的工作单元,也就能发现可减少沟通成本的空间。

但是,什么样的工作单元叫可量化?

代码行数是最简单的,估计完成APP改版需要写10万行代码。一个工作单元,我们定1万行?这种工作单元是可以量化,但是写完那么多行代码,你就是完成APP改版这个任务了?

我们举个例子来说明什么样的工作单元叫可量化,比如对于界面1,我们需要:

  1. 把“完成”按钮的颜色从绿色改成蓝色
  2. 当完成值为100时,不显示100,显示成“恭喜,已完成”
  3. 缓存从服务器获得的任务完成值,对于多次操作,只向服务器请求一次,以提升用户操作的流畅感

从这个例子,我们可以看出,每个工作单元都应该是:

  1. 准确的:将绿色改成蓝色,而不是红色
  2. 不可分割的:不显示100,显示成“恭喜,已完成”,这个工作单元,你不能再分割了
  3. 体现了业务含义:代码行数并不能体现业务含义,但是提升用户操作的流畅感有业务含义的。

可量化的工作单元、站会与看板

有了可量化的工作单元后,再结合站会和看板,这样,我们每天都可以知道(可视化)团队的工作状态了。延不延期,大家都可以看得到,大家都是成年人了:

  • 谁做得快,谁捡更多的卡来做的。而且可以捡优先更高的卡先做,也降低延期的风险。我们可以从这个过程中识别人才。
  • 站会的第3天,人员B还在做_#3_卡,我们其他成员可以加快速度做其它卡以弥补人员B的慢速度,同时项目经理也可以更早的介入这个可能延期的卡中帮助人员B
  • 当出现质量问题时,人员D的卡会被打回Todo多次,因为有站会,我们所有人都很感觉到_#5_这张卡可能存在一定难度或者人员D在协作方式存在问题,这时,我们其他人就会主动帮助人员D解决问题,而不是责怪他。

慢慢地,团队的协作方式变得以解决问题为导向,而不是以问责为导向。

拆分成可量化的工作单元,一样会延期

但是,我个人的经验看来即使我们将需求拆分成可量化的工作单元,项目一样可能会延期。

看板只能帮助我们更可视化,更容易地了解到项目当前的状态,对于这个状态,我们的项目经理要如何反应,完成是个人问题了。

同时,看板也能帮助我们找到延期的根本原因,比如是某个人的卡在In Progress上拖了很长时间、某个人请假了、其它部门中间改需求了、项目人员在某项技术的能力问题……

所以,要延期的项目一定会延期,我们应该正确面对,找到原因并根本解决。我们要做的只是保证每个人每个工作日都是满负荷的。

这里,留给大家一个思考题:如果其它外部条件不变,每个人每个工作日都是满负荷了?如何不延期?

拆成可量化的工作单元会增加项目经理的工作量?

然而,又会有人说了,这么多项目,我每个项目都要拆分成可量化的,我们项目经理会增加很多工作量。

其实,如果真的有作用了,这些工作量是值得的,只要你真的理解可量化工作单元的作用。同时,当出现多个项目时,你忙不过来时,说明现在是你培养另一个项目经理的时机了。你可以尝试将一些项目管理的工作交给团队成员来完成。但前提是项目经理本身也是超负荷工作,影响正常工作了。

小结

想让项目不延期,我们首先关注的是如何将需求拆分成可量化的工作单元,然后想办法保证这些工作单元真正被有效的执行。办法通常可以有:

  • 使用看板可视化所有的工作单元
  • 通过站会了解工作单元执行过程可能的风险
  • 通过协作来取长补短
  • 通过优先级来降低延期时的风险
  • 通过打包有交集的工作单元减少沟通成本

通过以上方法可以将团队“调”到可能的最优状态。但是如果还是延期,原因可能就不在团队了。

2 4 收藏 3 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 0.0 前端 05/11

    每天早上开站立会议

  • 一个悲鸣的时代 程序员 05/12

    这个问题个人感觉很简单,一个项目,你要是按期完成了,领导会以为时间还可以压缩,下次会压缩一点,你要是还是按时完成了,以此类推直到你按期完不成(不知道为毛会有这个想法,哈哈哈)

    • ManKane coder 05/12

      哈哈,所以每次估算的时候,都要往后延个一段时间,这是给自己留后路。

跳到底部
返回顶部