案例背景：这是一个已经在线上运行多年的产品，因业务调整，业务线增多，同时有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，那么可想而知他被打断的频率······有的项目成员也会反馈：我白天的时间只能用于应付邮件，即时聊天，以及各种沟通，只有到了晚上才有时间码代码。

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

　　秘笈心法

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

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

进行团队划分：分为三个团队。两个项目团队，主要承接项目需求；一个支持团队，主要承接每日来自线上和用户反馈的开发任务，当然在团队划分的时候尽量是新老结合，让经验丰富的成员带领新成员尽快熟悉业务。这样项目团队和支持团队可以分开来，最大程度的减少日常支持工作对于项目造成的影响。

(责任编辑：本港台直播)