管理一个软件团队，就像放牧一群骄傲的猫

前言

10多年前，我在看侯捷翻译的名著《深入理解C++对象模型》时，看到前言中有这么一句话“管理一个软件团队，就像放牧一群骄傲的猫”，让我印象极为深刻。 

当我看到老领导的文章《高效研发组织的七个习惯》时，我立刻想到了这句话，程序员是“骄傲的”，怎么把开发人员组织起来，形成一个高效的团队呢篇文章给出了一个答案。 

也许你现在只是普通程序员，这并不妨碍你去了解下高效的研发组织是什么样子的，也许有一天，你就走上了领导岗位了呢！

当一个组织有超过5个以上的小分队时，就要考虑是否把小分队分别划分到不同的“部落（tribe）”了。部落的划分原则仍然是全功能、高内聚、低耦合。

无论是对小分队还是部落，高内聚的的文化基石都是整体负责，荣辱与共。就像在激流中奋勇前进的漂流小队一样，为了保证不但不翻船，还能尽快到达目的地，每个成员既要有自己的专长和分工，又要在需要的时候要帮助队友，帮助团队。如何做到这点涉及到更细节的能力建设、激励机制、敏捷及工程实践方面的话题。本文先不展开了。

很多传统组织的管理者对自组织可能内心都是排斥甚至恐惧的，但它却是让整个组织敏捷的必要条件。古有“将在外，军令有所不受”，今天在公司里也有高效的管理者通过大量的授权，赋能的方法让员工能够在划定的边界内最大限度的发挥潜能和主观能动性。如何有效的授权的方法有很多，比如通过授权等级和授权看版等。以后我们可以展开讲。

但是现在问题来了。如果一个组织内大小事务都尽量自组织了，那还要领导做什么呢/p>

03

服务型领导和扁平的组织构架

AT&T公司的CEO在1970年提出了仆人式领导（Servant Leadership）的概念。他提出“仆人式领导首先是仆人， 他怀有服务为先的美好情操。他用威信与热望来鼓舞人们，确立领导地位。仆人领导关心的是服务，是他人的需求是否得到了满足。” 仆人式领导怀有一颗服务团队的心来赋能团队，从而让团队更高效，并因他/她的人格魅力受到团队的追随和拥戴。

但我一般不把Servant Leadership直译成仆人式领导，而更喜欢意译成服务型领导。毕竟仆人一般不会为主人制定战略目标，并且受到主人的拥戴。这和公务员说他们要为公民提供服务，比说他们是人民公仆更容易理解和操作是一样的道理。

办公环境是一个团队文化最直观的体现。比如你如果想了解你刚认识不久的女朋友或男朋友的真实性格的话，出其不备到她/他的房间参观一下就门儿清了。同理，如果你要了解一个团队的文化，参观下他们的办公环境是最有效的办法。

除了办公环境，更多的文化是看不见、摸不到的。比如心理环境。

05

构建失败安全的心理环境

失败安全是指团队不必担心失败后会受到指责或惩罚，所以不害怕失败；失败后敢于及时报告；使整个团体能从失败中快速学习、创新、和进步。

一个失败安全的环境甚至是鼓励失败，尤其是鼓励快速失败的。能够承受快速失败通常也意味着团队有能力快速恢复（fail fast, fix faster）。所以这里的快速失败是一种主动的试错或实验，也可以叫试错安全（experiment-friendly）。

在一个试错安全的环境中，所有的成品发布都是一种验证假设的过程。研发团队通过快速发布来快速验证针对新业务需求的假设，以达到快速演进的目的。所以既然每次成品发布都是为了验证假设，假设错了当然很正常，不但不应受到责备，反而应该因为试错过程非常快而受到奖励。

如果把一个组织比作一个有机生命体的话，它的组织结构就是骨架，它的物理和心理环境就是它的血肉和心智。而它的头脑是否能让这个生命体往正确的方向行动，是下面第六个习惯决定的。

06

结果导向和价值驱动

结果导向有两层含义。一是指在开始做一件事情之前先要想清楚要达到的结果是什么。二是在工作过程中始终要以最终结果为目标，不断修正方向。关于结果导向，在《高效人士的七个习惯》中也有类似的表述，叫做“以终为始”，这两个词基本是一个含义。但团队与个人的结果导向又有什么区别吗/p>

最直观的一点就是结果或者目标的一致性问题了。个人与团队，团队上下级的目标都要保持一致。这点我们上文提到过了。

另外，既然目标要保持一致性，就要求目标很容易被沟通、理解、和衡量。要很好地做到这一点，就要求目标能够被量化。在敏捷开发中，排定用户故事优先级或识别最小可用产品（MVP）等实践尤其需要量化的指标来帮助决策。同样，在非研发活动中可量化的目标也可以帮助团队选择正确的方向，少做无用功。比如小到举办一场活动，大到制定一整年的部门目标。

再进一步。上面提到的量化应该使用什么样的指标呢应该是由价值驱动的。因为只有价值才最终需要的，有效的结果，同时也是可以相互比较的。用敏捷开发中产出（output）和成果（outcome）来说明的话，量化的指标应该是衡量outcome，而不是output。比如写了多少行代码，举办了多少场培训是output，但新功能可以带来多少业务价值，培训后有多少人的技能提升到什么水平是outcome。做同样一件工作，我们鼓励产生尽可能少的output，但是尽可能多的outcome。

至此，本文大致总结了一个研发组织如要达到高效运转，从组织架构到组织文化方面所需具备的七个习惯。低效的组织各有各的不同，高效的组织却都是类似的。文中七个习惯无法涵盖所有高效组织的方方面面，而且即使全部做到的话也不能保证百分百成功，但希望本文能给研发组织管理者或者希望成为管理者的读者们一些启发。欢迎大家在留言区交流讨论。

转载请注明出处。

作者：常红平

IT职场老兵，在做过除用户体验设计师外的所有软件研发团队中的角色后，于10年前开始专注于管理。爱技术、爱敏捷、爱读书、爱分享。现在IBM CIO中国实验室作为IBM全球软件和云服务销售系统负责人，领导IBM年交易量数百亿美金的核心系统的研发和运维工作。近年来，他还带领跨国团队成功实施了一系列敏捷转型、技术革新、和组织文化转型。

参考资料

• 《仆人式领导》罗伯特·K.·格林里夫 (Robert K.Greenleaf)，197

• 《高效人士的7个习惯》斯蒂芬·科维 (Stephen R.Covey)，1989

• 《第五项修炼》(The Fifth Discipline) 彼得·圣吉 (PeterM. Senge)，1990

• 《Spotify Engineering Culture》https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/，2014

来源：码农翻身