从项目团队的混沌中寻找根本原因:为什么明明已经很努力了还是赶不上计划?

16 评论 11377 浏览 105 收藏 11 分钟

有的时候,我们需要跳出框框,从更高的角度去思考和归纳问题,这比埋头解决一个又一个问题更重要。

案例背景:这是一个已经在线上运行多年的产品,因业务调整,业务线增多,同时有5,6个项目并行,人员数量并不算多,大概20人左右,但当时的情况是一个开发可能需要同时参与3、4个项目,每天还有不少日常线上支持工作。团队成员为了完成计划经常加班,但还是赶不上进度,项目计划总是不停的调整。团队负责人焦头烂额,因为对外界的承诺已经给出,却迟迟拿不出成果。同时团队成员也感觉无力,明明已经很努力了还是赶不上计划,有些成员的情绪也会产生一些波动。

当时,团队出现了几个比较严重的问题,下面我们来分别看一下这几个问题以及产生这些问题的原因:

问题一:计划不准确,进度难把控

现象:

有些同时参与多个项目的团队成员经常会跟项目经理说:

我在A项目的提测点要延后,因为B项目那边的任务我要多加一个任务,那个要更早做,不然B项目的QA同学会处于干等我的状态。

也有的情况是,团队成员告诉项目经理:

我在A项目当时的估算太乐观了,任务做下去才知道远没有这么简单,所以我B项目的任务要相应延后了。由于人员的依赖,项目之间会出现两两依赖的情况。所以项目的计划经常需要调整,后续的进度也很难预测。

原因:所有项目的计划不是同一时间做的,一个成员在做A项目计划安排的时候,他后续需要投入的B项目的计划还未开始,所以在A项目的计划很大程度上只是拍脑袋。在计划阶段缺乏深入的探讨和思考,对任务理解不到位,就会出现估算乐观的情况。

问题二:项目成员缺乏对产品的主人翁意识

现象:

项目的策划案,交互稿,视觉稿,大家没有积极性review,他们觉得:

这又不是我的任务,这样占用我写代码的时间,本来就很忙了,这样不是把我往死路上逼嘛。策划和视觉稿确认了再来找我们就行了,你们负责需求,我们负责实现就行。

这样的结果往往是,有一些方案在开发实现上明明有困难,却在最后开始代码的时候才发现,策划案修改导致一些返工。另外一方面,开发和QA之间的界限划分也会特别明显,是开发的事情,QA不管,当然是QA的事情,开发也懒得帮忙。

原因:如果一个成员同时参与3个项目,那么平均一下, 他可能在每个项目的投入只有30%,说明他在整个项目中可能只是做了一小部分,很难要求他去把产品整体的设计思路都去理解一遍。另外精力有限必定先做开发任务,如何能让他从产品整体角度思考问题,如何能让他为产品的未来考虑,能够把任务做完就不错了。

问题三:加班情况严重,团队出现疲态和怨言

现象:团队所有成员,包括开发,测试,甚至策划,运营,都开始加班,有的成员甚至经常熬到凌晨。

原因:工作量大是一方面,很重要的一方面在于多任务并行时造成的切换成本。

想象一下从一个任务切换到另一个任务,然后再切换到另外一个,这过程中的开销是非常巨大的。Mike Cohn的《Scrum敏捷软件开发》一书中提到,假设一个开发人员在一个月的产出为1,如果他同时参与两个项目,那么他在这两个项目的产出和就为0.8,如果是同时参与3个项目,那么这个产出和就降为0.6。如果项目更多的话,那么这个值就会更低。

另外,软件开发过程需要团队各角色间的不断沟通。有研究表明团队成员每11min会被打断一次,如果一个人同时参与3个项目,那么他的沟通渠道就会乘以3,那么可想而知他被打断的频率······有的项目成员也会反馈:

我白天的时间只能用于应付邮件,即时聊天,以及各种沟通,只有到了晚上才有时间码代码。

为了不让进度偏离的太离谱,很多成员就选择加班来赶上进度。但是加班是需要慎用的一种赶上进度的方式,短期采用或许能加快进度,如果团队长期处于加班状态,不但当前版本的进度加快不了,还会影响后续很长一段时间的团队成产率。有研究表明,团队连续加班的第四周开始,生产率就开始下降。

秘笈心法

分析下来,我们不难发现,导致团队种种问题的原因中有一条是非常根本的,那就是多项目并行,不仅会导致多任务切换的额外成本高,还导致团队在任何一个项目都没有归属感,也会增加计划之间的项目关联,导致计划很难制定以及一些连锁反应那个。

所以,我们主要围绕这个问题采取了一系列的应对措施:

  1. 进行团队划分:分为三个团队。两个项目团队,主要承接项目需求;一个支持团队,主要承接每日来自线上和用户反馈的开发任务,当然在团队划分的时候尽量是新老结合,让经验丰富的成员带领新成员尽快熟悉业务。这样项目团队和支持团队可以分开来,最大程度的减少日常支持工作对于项目造成的影响。
  2. 减少并行,让团队成员更专注:每个成员尽量只服务于一个项目,如果有些开发成员实在无法只服务于一个团队,他会有一个投入超过60%的主要项目,有了这个60%,那么至少他会对这一个项目有更多的归属感,总好过对所有项目都没归属感,他在这个项目中的参与度就会更高。
  3. 进行固定长度的迭代方式:两个项目团队每两周一次计划,两个团队在同一天做项目计划,一个在上午,一个在下午。这样方便有项目并行工作的同学统筹他的精力分配重。
  4. 审视项目的优先级:把项目分优先级,一个团队可能会负责两个项目,但是这两个项目有优先级区分,例如团队一负责A项目和B项目,A项目优先级更高。那么团队最先开始一个A项目的两周计划,接下来两周做B项目的计划。当然如果A项目结束后,发现A项目接下来的需求优先级比B项目更高,则会继续开始一个两周的A项目计划。
  5. 强化计划过程:每个两周计划前会有一个迭代计划会,需求会在这个会上被理解清楚,因为每个需求都会被要求做WBS和估算,如果需求理解不清楚或者不去理解需求是没法做WBS和估算的。这个过程促使开发和测试人员更早的去跟策划讨论需求细节。在迭代过程中的变更就会更少。

这些措施实施之后一段时间,项目经理渐渐观察到一些小的变化:

  • 某些开发同学开始不时的找策划同学讨论需求中未完善的细节;
  • 某个测试工作量很大的迭代中,开发和其他角色的同学主动要求承担部分测试的工作;
  • 某个项目的而一个迭代中测试被其他项目占用,需要用一个新部署的测试环境,但是这个环境之前都有一些问题,一直没能用起来,但是这一次大家都召集,测试和开发同学齐心协力,在半天时间内搞定了之前很长一段时间都没搞定的问题,顺利用上了新环境;
  • 大家加班的情况得到了缓解,曾经有对立关系的测试和开发的关系更融洽了
  • ……

其实在这个案例中,虽然看起来问题有好几个,但是最终分析下来,会发现有一个最根本的原因,这个原因导致了一连串的问题,把这个问题解决了,其他问题也会迎刃而解。

所以,有的时候我们需要跳出框框,从更高的角度去思考和归纳问题,也许这比埋头解决一个又一个问题更重要。

 

作者:何燕华,网易资深项目经理,PMP,CSM。先后在网易私有云、网易用户中心、网易GACHA、网易LOFTER等项目担任项目管理工作,积累了丰富的项目管理实践经验,并始终致力于项目的成功交付和团队的健康发展。《网易一千零一夜》主要作者之一。

本文由 @网易杭研项目管理(微信公众号:NetEasePM) 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 解决这些问题的核心我认为是高层战略,如果能从源头上把控住需求,才是最有效率的方式

    回复
    1. 赞同!是一步一步向上溯源~问题根源很多时候是老板(最大的产品经理)的需求与期望管理哈哈

      来自浙江 回复
    2. 嗯呐,所以如何揣摩高层用意,找出最优化解决方案,也是产品的一大挑战呐

      来自北京 回复
    3. 呵呵,我们2个半产品,做4个完全独立的业务板块,10多条产品线,20多个产品各种产品。

      来自内蒙古 回复
    4. 呃,为啥会有半个

      来自北京 回复
    5. 有一个兼任?或者担任管理职? 哈哈

      来自浙江 回复
    6. 估计是兼任 🙂

      来自北京 回复
  2. 所以大家工作都不能只关注自己那一块啊喂,还得想到协作问题

    来自广东 回复
    1. 是的~真的很难单打独斗的~ 协作是一门艺术

      来自浙江 回复
  3. 小公司,就想不了那多了

    来自湖北 回复
    1. 嗯嗯小公司确实有其他要考虑的点,上面还是有一些要点可以参考哈~

      来自浙江 回复
    2. 只能在老板的需求和用户的需求中,尽力找到平衡点

      来自湖北 回复
    3. 通常都是老板需求比较紧急 😥

      来自浙江 回复
    4. 而且是不讲道理的需求,也得满足啊 😮

      来自湖北 回复
  4. 理想很美好,可惜的是很多事情在实际开展过程中受限于当前你在企业的位置,企业的文化,企业的组织架构,团队成员的定式思维,要改变,真的不容易。

    来自广东 回复
    1. 是的~ 但我们还是尽最大努力去做影响~

      来自浙江 回复