带领团队的一点心得(多任务管理)

quasiceo 2013-03-06

展开全文

一、 计划的制定

任务池的管理:

何谓任务池，说白了就是我们将所有任务集中，将优先级标注出来，让我们随时清楚我们当前在做什么，即将要做什么，还有那些可以放在后面做，当有新任务来临时都要放进去，比较一下优先级，知道大概要到什么时候才可以做，最大的好处之一，就是可以防止漏项，避免”杯具”，比如十月份，其实河北的反馈任务就给漏了。另外，只有真正的管理好任务池，才有可能看的更远，对于后面的计划做到了然于胸，坐怀不乱。

那么任务池管理的一个精髓在哪里呢？个人认为是优先级的排序，要先做什么，后做什么，任务分为四种，重要且紧急(A)、重要不紧急(B)、紧急不那么重要(C)、不重要也不紧急(D)，那么我们处理的优先顺序也就一目了然了，A>B>=C>>D，显然我们没有不重要也不紧急的，我们就将D定义为”不那么重要且不那么紧急”吧。

注意，这里所说的重要紧急是针对总部而言，对于分支来讲，自己要求的那块永远都是重要且紧急的。

联想到我们十月份的任务，可以这样简单划分一下:

北京版本:B

河南版本:D

黑龙江版本:A

甘肃补丁版本:C

甘肃新定额版本:A

新疆准备版本:A

新疆新定额版本:B

陕西版本:A

新疆金润接口:B

具体的任务安排的先后顺序，在下面的多任务管理里面详细总结

节奏图的制定:

何谓节奏图，套用某人的话来说，就是”计划的计划”，前一个计划，指的是我们的具体的某个版本任务的”作战地图”或者”任务分解”，而后一个计划自然说的就是”节奏”了，比如我们是先搞陕西呢还是先搞新疆呢之类的，换而言之，节奏图是站在一个更高的位置去统筹安排任务，就像是连长说我们要突破防线，必须先端掉这个碉堡，然后再端掉那个炮楼，具体这个碉堡怎么端，是迂回包抄还是正面强攻呢，那就是是排长要考虑的事情了。

其实这个东西也和前面提到的任务池关联，如果对所有的事情都做到心中有数了，自然可以登高望远，那我现在能看多远呢？自认为撑死也就只有一周半吧。

写到这里，也回答了我自己之前的一个疑问，新疆的东西简直是疑雾重重，那我就先做好已经明确的，做完之后，等到新疆明确了再分析再做，因为东西不明确，我也没法估算时间，也不知道什么时候可以给，怎么可能做节奏呢？现在回过头来看，也不是没有方法，如果真的按我的思路处理，那么甘肃黑龙江的新定额版本，注定要”杯具”了。

作战地图的制定:

其实如果作战地图这一块，说明前面的东西都已经明确了，因为这一步就到了我们制定该如何去炸碉堡的计划了，在制定作战地图的时候，心里真的是感慨”人到用时方恨少”，各种杂七杂八的任务都需要人来处理，感觉恨不得有十个开发十个测试给我才够用，为什么会有这种感觉呢？主要有以下两点

第一，任务拆解不够详细，并没有真正明确每项任务花费的时间，只是大概估算，还是拍脑袋算法，最明显的例子就是我之前估计开发配置新疆2010完整定额的时间，一拍脑袋说2天差不多了，可真正详细拆解之后来看，需要26个工时，大概3个多工日。

第二，没有搞清楚任务的主次，这个后面多任务管理详细说。

周报的目的:

这里我就不写每日汇总的目的了，估计都清楚，为什么要特意强调周报呢？周报可以总结这一周的情况，展望下一周准备要做什么。很多人都会看中周报的”总结”这一方面，而忽视了他的”展望”这一方面，从十月份的任务看来，我认为”展望”才是周报的精髓，毕竟无论做的对与错，好与坏，过去的已经过去了，关键的是在于后面怎么做，如果做错了，如何去弥补，同时这里也和任务池有关联，是否有些任务需要调整优先级，是否有任务根据情况可以适时的延后，可以说周报就是让大家检视自己的任务池，给自己一个”中场休息调整”的机会，以免在后面偏离轨道。我们在十月中旬的时候就重新调整了计划，为下半月任务顺利完成奠定好了基础。

二、 多任务管理

区分主、次任务:

前面提到十月份的任务，刚刚接手的时候简直是一团乱麻，按照既定计划刚刚执行了一天，就被告知来了几个地区的新定额要求给版本，打乱了我的阵脚，根据分支要求的交付时间，我们不得不并行五个版本任务，况且这些地区版本任务还不是很明确，有的地区版本任务的瓶颈还是在数据方面，能否协调到位还是未知数，这还不算反馈和临时任务的处理，而我的资源有多少呢？加上我6开发4测试，其中开发新人2个，测试新人1个，而且老的开发还要保证每周有一人专职处理反馈，这就要求必须要并行任务处理，那么如何并行呢？

最总要的是要制定出主线任务，主线任务必定是重要的，按照上面排列的优先级，同时还要考虑到任务本身的一些情况，我们将陕西作为本月的主线任务，新疆作为次主线任务，考虑有如下几点

1．属于重要的任务，分支展会时间虽然不是很紧，但是考虑到其他任务(主要是新疆)，必须提前做，同时因为促销版本，对于质量和稳定性的要求很高，必须要花费大量时间来保证版本没有问题。

2．需求明确，需要做的内容较为清晰，启动条件具备

3．从分支代码同步上来，根据以往经验，这种同步上来的版本问题也比较多，需要大量的时间去测试和修改。

4．河南甘肃的补丁版本，本身属于补丁性质，自然不能作为主线任务。

5．新疆版本和陕西类似，但是由于新定额数据迟迟未到，根本不具备启动条件，所以选择陕西。

任务的拆解:

主线任务制定出来后，剩下的自然就是次要任务或者说是支线任务，这其中还有一个最大的定时炸弹，那就是新疆，新疆属于新定额，但是数据迟迟不给，启动条件一直不具备，到底要做什么，要做多久谁也不知道，那么该如何处理呢？

这里就要谈到任务的拆解，这里并不是任务分解，而是拆解，所谓拆解指将任务划分出阶段，制定出一个一个的里程碑，分阶段完成，直到最终完成。那么面对新疆这个大炸弹，我们是如何拆解的呢？

首先分析下新疆的情况，新疆是之前的1801那个老古董版本上升级上来的，和最新的主干差距过大，因此新疆一个重头戏是在主干上保证新疆原有的东西没有问题，最主要的是，这个工作和新定额无关，可以启动，而且前期不需要需求参与，因此我们新疆做了如下的划分

1．新疆新定额准备版本，将分支代码同步到主干上，针对旧特性进行测试，保证主干上新疆原有功能没问题，同时还要测试新的通性功能。

2．在主干版本上，完成新定额。

这样新疆的任务就被拆解为2个阶段，其中第一个阶段可以和陕西并行，因为陕西

同样也是同步上来的版本，对于测试而言可以两个一起测，还可以节省时间，提高并行的效率。

主次任务间的切换:

主线任务和支线任务都已经确定，那么时间如何安排呢？更加确切的说是先做那个后做那个呢？

这个问题其实很好回答，我们要有一个坚定的信念，那就是一定要保证主线任务做好，其他的拦路虎通通要处理掉，为主线任务节省出时间，因此我们采取第一周首先将河南和甘肃的补丁版本迅速解决掉，排除干扰，同时主线任务也同时启动，先期将代码同步完毕，为测试提早介入做准备。

当支线任务处理完毕后，就是全力投入到主线任务和次主线任务，这两个版本可以并行的原因上面也已经分析过了，一切为了主线任务，途中有了临时任务等等需要临时抽调人处理，也要迅速处理完毕，早点回到主线任务来做贡献。

一起工作:

这个东西其实tianjp在四月份就已经总结过，其实就是要给大家一个明确的目标，大家向着一个目标去使劲，才能达到1+1>2的效果，如果所有任务全部并行，每个人负责一个版本，完全是各自为战，一盘散沙，也就丧失了团队的凝聚力。

部门间的咬合:

这个问题其实也是老生常谈了，我们这次甘肃和黑龙江以及新疆的任务，其实全部都卡在了数据这里，关键点就是数据何时可以交付，在数据交付前，这些地区的版本我们可以做些什么？这也是要考虑的内容，比如新疆可以做第一个里程碑，黑龙江可以检查有关DEID的配置，甘肃可以做评审的报表等等。

此外，这次数据问题还有个比较大的教训，那就是当GDT组出现问题时如何处理呢？黑龙江数据18号答应交付，但是由于工具问题，知道22号发版前才最终交付，我们这种情况下找数据其实是没有太大作用的，这个时候就应该直接去找GDT组尽快处理问题，保证我们的按时发版。

三、 团队管理

角色的转换

这个问题其实之前就有人提过，但是真正深有体会的是在这里作为大区负责人的执行过程中，作为一名开发，我可以很好的完成交付给我的任务，那就可以了，那作为一名负责人呢？恐怕还远远不够，不再是”一人吃饱，全家不饿”的情况了。

不要急于去做一个功能改一个bug，不要急于完成某一个细节上的东西，这些你都可以安排其他人去做，你现在最需要做的是如何去制定计划，然后去执行他，最后顺利的完成任务，你关注的是整体计划是否可以完成以及用何种手段保证他可以完成，而不是必须亲自上阵，否则，即使最终任务完成了，也只能说没有真正明白负责人的职责所在。

强内聚、松耦合:

我所负责的这个月，其实谈不上管理，基本上都是在学习如何管理，前面在角色的转换里面也提到了一些，下面是我对这负责人这个角色更为深一层次的理解。

”强内聚、松耦合”这是OO里面所提倡的，具体含义不解释了，不清楚的可以去百度一把，其实大区、数据、需求、自动化都可以看做是”计价产品线”这个程序里面不同的模块，他们实现不同的功能，配合起来使得”计价产品线部”可以正常的运营，作为一名程序员，如何设计”大区”这个模块呢？

首先”大区” District要有一名管理者，也就是PM，这个管理者对于自己内部的两大重要子模块，Coder和Tester进行管理，Coder和Tester的核心工作，就是完成PM交付下来的Task(这些Task是PM和其他模块交互之后得到的)。PM同时还要和外部的其他模块比如”自动化”AutoTest，”数据”Data，”需求” Requirement进行交互。

PM关注的是什么？是Coder和Tester完成Task的情况，然后是和外部的通信，如果我设计这个类，我会根据其他几个模块，提几个不同的通信接口，然后每个Coder和Tester都去实现这些接口，也包括PM，当我向Tester和Coder发出Query请求时，我只需要得到Task的完成情况，然后根据反馈回来的信息去调整Task或者去和其他模块沟通。具体的完成任务过程中所需要的其他模块的交互，那就可以让Coder和Tester自己通过通信接口去完成吧。