高效研发组织的七个习惯 | IDCF

来源：CIO Talk

作者：常红平

关注本公众号回复“研发效能”可获取常红平老师《互联网研发效能方法工具落地金融行业的实践经验》回放地址~

大部分读者可能都知道《高效人士的七个习惯》。然而作为一名组织管理者，除了让自己高效外，更重要的是让整个团队变得高效。

在谈高效研发组织的习惯之前，有必要先澄清一下什么是高效。如果只是把高效对应为在单位时间内写大量的代码或功能特性，最多在代码前加上一个形容词“高质量“，未免太简单粗暴了。

试想一个公司为什么要设立一个研发组织？是为了帮公司实现它的目标或愿景，对吧？对于研发组织，通过什么实现呢？无非是开发出的产品或应用能让客户满意——让外部客户心甘情愿地掏钱或使用，亦或让内部客户的生产力或工作效率大幅提高。

但是客户不是好哄的，有时他们甚至自己都不知道自己想要什么。在这种情况下单单高效的产出高质量的代码或功能特性是不可能被称为高效组织的，更无法帮助公司找到并抓住市场机会，并且在激烈的市场竞争中胜出的。

但这不是一篇教你如何拥抱客户需求变化或者关于敏捷精益的文章。对于一个组织而言，相对一个个敏捷实践，它的组织结构和文化才是决定它是否能长期高效运转的基石。所以今天我们先聊组织结构和文化，关于敏捷实践的内容我们以后聊。

本文略长，需要15-20分钟读完。内容略干，请自行搭配水果，清茶或咖啡阅读。即便如此，因篇幅有限，一篇文章也只能概述最基本的内容。未尽之处，我们后续文章单独展开。

组织结构是组织文化的基础，所以我们先从组织结构聊起。

一、组建高内聚，低耦合的全功能团队

能在大多数情况下不借助外部团队就能独立完成端到端从需求分析到系统上线工作的团队就是全功能团队。

因为做到了全功能，在日常工作中，沟通合作就会更多的发生在团队内部成员间，此为高内聚；而一个个小全功能的团队之间的沟通合作远比团队内部少，称之为低耦合。

从小团队到规模化敏捷，业界已经有很多种组织结构框架。框架虽多，本质上其实都是相通的。为简单起见，本文使用Spotify的框架讲述。

一个小的全功能团队我们称作一个“小分队（squad）”。它的划分要求如下：

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

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

到此，一个高效的组织结构就初见雏形了，然而，这还是不够的。跨小分队，跨部落的沟通协调应该怎么做；在团队遇到困难时，如何互相帮助才是更快速高效的呢？

二、构建目标一致的自组织团队

这里的关键词是自组织，但自组织的前提是目标一致。

目标一致的目的很好理解。有目标的团队才能够保持专注并朝着同一个方向前进。反之，失去目标的团队会由于难以聚焦和缺乏动力，从而停滞不前。这要求管理者能够把团队目标从远景到近期目标都能够定义清楚，有效沟通，团队内部、上下级保持一致，这其实并不容易。

团队自组织和目标的一致性是什么关系呢？

在下面的一致性和自组织四象限中，很明显右上角的高一致性且高自组织性的组织是最佳状态。而一致性越高，团队可被赋予的自组织性才有可能越高。

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

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

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

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

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

具体来讲，服务型领导应该做什么呢？

• 第一，明确组织的长期和短期目标，并有效沟通。这包括目标本身，和为什么是这些目标。这是前提，上文提到过了。
• 第二，时刻帮助团队和每个员工提升能力。这是领导者的第一要务。而项目成功交付等目标实现实际上是团队能力建设的副产品。
• 第三，协调、解决团队无法自身解决的问题。无论团队的自组织能力多高，仍然会有很多问题是团队自身无法解决的。这时领导者要为团队提供解决问题的服务，并自省这项服务是否可以通过改善组织内外部环境，下次让员工自服务就可以解决了，以持续提高员工自组织的能力。
• 第四，组织文化建设。创造良好的文化和环境，让员工能在组织内更好的成长。

扁平的组织架构和服务型领导是什么关系？二者相辅相成。可以想象在一个自组织性极低的组织里，那个事无巨细都要插手的领导是根本无法有时间和精力管理很多直属部下的。而如果让一个组织尽量扁平，客观上可以促进领导者更加专注于目标管理和能力建设，毕竟他/她如果能这样做的话，至少会让自己的工作变得稍微轻松一些。

谈到服务型领导，我们已经开始涉及到文化方面的话题了。有些文化是看得见摸得着的，有些不是。我们先聊聊那些看得见摸得着的文化。

四、创建面对面工作的敏捷办公环境

面对面的沟通是效率最高的，这点毋庸置疑。但仅仅坐在一起也还是不够的。还要让办公环境敏捷起来。

敏捷的办公环境首先是开放式的。没有小隔间，没有为特别人物包括经理设立的专用办公室。理想情况下一个小分队应该面对面或者背对背坐在一起，或者按任何他们喜欢的方式摆放工位。经理或者领导者必须要和团队坐在一起，以保证和团队沟通的有效性。任何门或者看起来像门的物体都会让团队在试图找领导沟通时感到迟疑。

敏捷的办公环境同时也应是自由和舒适的，甚至看起来有一点乱。员工和团队应有极大的自由度安排和装饰自己的办公空间，就像布置他们自己的家一样。真正舒适的家在外人看起来也是有些乱的，不是吗？至少我的家是这样。。。一个员工自己布置的、舒适的办公空间能极大的提高团队的归属感、成就感、甚至幸福感。

敏捷的办公环境应该提供团队可视化一切的设施。敏捷团队的物理看板是必不可少的。除了看板，其他可以可视化的还包括团队愿景目标、项目计划路线图，DevOps运行状况、各种敏捷度量图等等。可视化一切或者工作看板墙（Wall of Work）是加速团队敏捷转型过程的一个非常重要的方法。这个也值得单独展开讲。

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

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

五、构建失败安全的心理环境

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

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

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

试错或者失败安全的环境不止可以促进研发更加敏捷，在日常非研发活动中也同样适用。比如新流程或者工具的试点，新想法的实施等。失败安全是保证组织能够不断创新的基础。

失败安全的文化离不开相应的绩效评估制度。管理者不能嘴上说失败安全，但在年底绩效考评时因为某次试错失败而给员工差评。关于绩效管理，我们后续展开谈。

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

六、结果导向和价值驱动

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

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

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

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

好了，到现在为止，一个作为生命体的组织的骨架，血肉和头脑都有了。那最后一个习惯关注的是这个生命体的健康成长。

七、培养学习型组织以持续改进

学习型组织是管理大师彼得·圣吉（Peter M. Senge）在1990年在《第五项修炼》一书中提出的概念，是指通过培养整个组织的学习氛围、充分发挥员工的创造力而建立起来的一种精简、扁平、有弹性的、终生学习的、不断自我演进的、能持续发展的组织。构建学习型组织有五项修炼，分别是自我超越，改善心智模式，建立共同愿景，团队学习，系统思考。一个学习型组织很像一个生命体的组织和演进方式，通过不断学习，反馈，而持续成长，发展，突破自我。

读完前文所述的六个习惯，再看学习型的组织的概念，你会发现有大部分内容前文都有涉及了。的确，上述很多习惯都是创建学习组织的前提。但这里还是有必要把学习型组织单拿出来讲。因为学习型组织更关注的是组织和组织内员工的长期发展和持续提升，帮助一个组织达成长期的成功。

要注意的是，学习的目的不只是了解到新的知识，而必须是因为学习产生了新的认知和新的行为，从而获得提升和改进。对于一个组织，学习意味着通过试错从一个个成功和失败的案例中不断获得经验和知识，从而能够持续改进自己的行为和文化，以持续成长。而且这个成长是以组织作为一个有机整体为单位，而不是单个的个人。

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

作者：常红平

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

参考资料

• 《仆人式领导》罗伯特·K.·格林里夫 (Robert K.Greenleaf)，1970
• 《高效人士的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

今晚8点，【冬哥有话说】邀请到百度资深产品经理、开源中国产品总监王一男老师，分享《互联网研发效能方法工具落地金融行业的实践经验》

识别下图二维码回复“研发效能”可获取直播地址~