团队效率模式（一）

团队效率很大程度上受团队管理者的影响：

1.         团队管理者的能力决定了团队成员的能力提升水平的上限。

2.         团队管理者的管理方法决定了团队整体运作的效率。

 

在互联网、游戏公司，更是这样。这样的公司和传统的软件公司相比，产品周期更短、变化更多、更新更快、团队更小，但是在软件质量上相应的要求会低一些。因此在管理上更是要求在保证质量的前提下，尽可能的提高效率。

 

在我的项目经验中，感觉有一些好的方面是可重复的，技术出身，习惯性的叫它们“模式”了。我把这些模式的介绍，以GOF设计模式的形式进行组织。先提出模式的背景问题，再给出解决方案，最后说明使用此模式的效果。

另外，有模式，就有反模式。常见的错误做法，也应当列出来，让每一个人，在试图做类似的事情时，能更快的识别出来，不重蹈覆辙。

 

团队效率模式

 

下属培养

问题

团队效率要提高，每个人都要能独挡一面，关键时刻谁都能上前线。这就要求每一个人都具备比传统软件行业相对更高的技能水平。

在互联网、游戏行业，团队的管理者往往是团队中技能水平最高的，这一方面是由于管理者对整个技术方面把握比较好，能更快针对问题提出好的Solution；另一方面也是希望管理者能带动团队技能提高。

如果团队中只有一个精英骨干，其他人都能力差太远，那么，结果往往是以下几种：

1.       随着软件规模变大，骨干一个人力量支持不住，导致项目效率下降。

2.       随着软件趋于稳定，骨干的工作趋于常规，如果骨干换岗或离职，项目立即缺少能继续维护的人，导致项目危机。

3.       随着团队变大，更多的人写出有问题的代码需要骨干来调试和修正，项目效率将变低。

 

方案

骨干或是管理者需要以下属培养为首要任务。

下属培养可以有多种形式：

1.       多让下属分担任务，并多加协助。初期可能效率会有下降，但当下属技能提高，会带来长期的效率提高。

2.       多进行技术交流，并带动大家不断提高自己技能。分享自己解决的问题，与大家一同讨论自己的设计思想。让团队成员更多的是了解Why，而不是How。

3.       让达到一定水平的下属去带动其他的团队成员，或是作为新员工的导师。教会别人，能让自己已经掌握的知识更牢固，还可能在交流中形成新的知识提高自己。

4.       制定明确的考核标准，以统一的质量要求考核团队中的每一个人的工作成果。

 

效果

在下属培养初期，会有小量的效率降低。

但当所有下属的提高的程度已经可以抵消管理者进行下属培养所减少的的那份后，效率将开始提高，并会因为下属的能力提高而不断提升。

另外，随着下属培养和技术交流成为团队成员的习惯，会对整个过程产生正反馈，让团队变的更加有效。

能让新进入的团队成员也很快加入这个过程中，团队的成员变化和成员离开对项目的影响也会给团队带来更小的影响。

 

压力传递

问题

产品的变化快，竞争对手跟进快，哪家的团队稍有懈怠，就会被落在后面。而你的团队中，似乎只有几个核心成员急的火烧眉毛，其他同事好像没有意识到项目的紧急程度。

原因往往很简单：核心成员或是管理者没有将压力传递到下属。

新提升上来的管理者往往会因为人缘方面的考虑，而在压力传递上有很多顾虑。怕自己对下属说的多了会引来不满，怕下属压力大了会有抵触心理。于是就把压力自己抗着，对下属实行招安政策，甚至是对下属的一些不职业化的做法和心态也采取纵容态度。时间越长，下属对项目的敏感就越低，团队的效率也就无可挽回的开始下降了。

 

方案

管理者应当及时的把压力传递到下属一层。让下属随时了解到项目目前的情况；进度是怎样的；竞争对手与我们的距离；我们产品的缺点在哪里，如何改进；我们产品的长处在哪里，如何长期保持。

如果在紧张的时候，下属并没有一起紧张起来，就需要提醒下属目前是紧张时刻，更多的把时间放在可以立竿见影的工作上。

1.         完成还没完成的需求

2.         修正产品BUG

3.         改进用户体验

4.         优化界面

5.         提高程序效率

6.         在尽可能少的时间里完成必须的任务

7.         花更多的时间用于把自己负责的工作做的更好。

在并不是非常紧张的时候，也需要安排下属为后面可能的紧张时刻做好准备，打好提前量。

1.         把需要做的基础工作做扎实

2.         把一些早晚要做的事情开始一件件作起来

3.         把产品可以优化的点继续优化

4.         把相对领先的内容做的更好。

5.         将目前的技术实践进行积累抽象，为后面的工作或其它项目做些准备。

总之，不会有没有事情做的情况，如果没有事情做了，只能说，团队冗余太大了。要么就是你的项目是非常重要的项目，需要做人才储备；要么就是需要减员精效了。

开始使用压力传递时，会引来一些抵触，这个是正常的情况，需要管理者与团队成员进行有效沟通。其实大家都是做项目的，也许各人对从项目中能获得的收获的预期不同，但至少有一点是一定要一致的，那就是没人希望项目失败。所以做好每个人的工作，渡过压力传递适应期后，会迎来一个好的结果。

 

效果

每个团队成员在了解了项目的压力后，可以感同身受，与项目节奏一起呼吸，步调也与项目同步。

在项目紧张时，每个人都能自发的开始紧张起来，为项目做好自己负责的部分，并能尽可能的做好相关的一些额外内容。

在项目稳定时，每个人都能积极的进行优化，并能保持比较高的效率，把项目做的更好。

 

 

团队效率反模式

 

救火队员

问题

作为一个团队的管理者，或是团队骨干，所有的问题都自己解决。出发点往往有以下几个：

1.         我做的更快

2.         我没有时间来指导别人做

3.         这么紧张，让下属做更紧张，给下属压力太大

4.         这个问题难度高，不好教会的

5.         这个技术很核心，教给别人，跑了就把技术带走了

于是，越来越多的问题“只能”由管理者或是团队骨干来做，时间长了，管理者或骨干成了整个团队工作效率的“关键路径”。而且随着事情越来越多，这条路径的效率越来越低下，导致团队效率下降。

最后，管理者或骨干撑不下去，走掉了。项目无以为继，出现问题无人能解决，核心技术真的Gone with the wind了。

 

方案

使用下属培养和压力传递两个模式

 

效果

团队中核心代码有至少两人了解，其它部分的功能有多人了解。查找修正问题的办法团队中每个人都了解。遇到问题时，大家任何一个人在场都能站出来解决。每一次解决问题，当事人的满足感和责任感都进一步得到加强。更少的人会从团队中流失，因为这个团队才是他们想留下的地方，他们能从这个团队得到更多。

 

 

下一篇《团队效率模式（二）》提到：

邮件确认模式：确保工作中的每一环做的好坏就可以量化，并且在事后可以对结果进行评估，以便找出短板，进行效率上的改进。同时也避免了由于没及时确认导致的时间浪费、工作反复、计划混乱。