克服大团队的危险性

冯大师在博客DBA Notes中写”大团队的危险性“。这种危险性来自多种因素。大船“瓦沙”是一个大团队危性的常见结果。

1625年，瑞典国王古斯塔夫二世·阿道夫打算建造有史以来最棒的战舰。他雇了最好的造船工匠，专门种植了一片最刚硬的橡树林，都为了建造大船瓦沙。国王不断提出各种要求，希望把船建得更宏伟壮丽，到处都加上华美的装饰。有那么一天，他甚至决定在船上配备两套甲板炮，这是当时世界上绝无仅有的。他的船会是海上的霸王。而且由于迫在眉睫的外交问题，他还希望大船瓦沙能尽快造好。当然了，工匠们一开始的设计只有一套甲板炮，不过既然国王提出了要求，自然就得再加一套。由于太赶时间，工匠们来不及做“摇晃测试”──让一群水手从船的一边快跑到另一边，船在这种情况下不应该摇晃得太厉害（换句话说，没有头重脚轻）。结果，它的处女航只有几个小时，然后就沉入了海底：在给它加上所有华丽“特性”的同时，国王和工匠也让这条船变得根本无法航行。大船瓦沙在北海的海底长眠了几百年，直到20世纪初才被打捞出来，陈列在博物馆里。

一个有趣的问题：到底是谁导致了瓦沙的沉没？是国王，因为他要求了太多的特性？还是工匠，因为他们只顾着满足国王的要求，没有大声说出自己的担忧？看看你正身处其中的项目吧：你是不是正在建造又一艘瓦沙？

只做当下需要的。一开始这会很难，但最终你会得到一个更好的代码库。如果不引入不必要的复杂度，在修改或是重构时就不用对抗这些复杂度。程序员应该谨记：熵会杀死软件，所以，如无必要，勿增特性。

其实，这种危险性在我们的团队中一样存在。公司从最初的几十个人，用两年多的时候发展成500人。技术开发团队有200人的规模。一个总监，近10个经理或主管，每个经理下面15个员工左右（包括外包和实习生）。总监下属几个专家或架构师，各部门经理下面也有自已的架构师。这样的一支团队，从组织结构上看还是清楚的，但这已经是一支大团队。这支大团队会遇到这些问题：

1. 部门各自目标不同；每个部门都希望作出大成绩，搞大项目，以建立自已的影响力；大项目的启动成本是很高的，先要建立虚拟组织，建立新的合作流程，然后是角色分工，然后任务分解，再进入设计研发…….。因为是大项目，所以管理者一般不允充项目出问题，所以前期一定会精确管理，认真对待。
2. 每个部门有自已的风格，包括规范和流程，部门之间要统一流程和规范的话，需要大量时间进行培训；小团队流程很少，很多问题都直接口头交流；大团队为了加速不同部门人员的理解和统一思路，必须借用各用画图工具，项目管理软件等进行管理；很多团队为了用这些软件还需要进行角色培训；于是团队的成员一个个都成为了软件的使用者，准确的说，在被软件所使用。越来越多的只了解自已的环节，还不知道全局。
3. 决策层次太多，沟通低效。当需要跨部门合作时，沟通占用大量时间，并且沟通的层级会很多；为了保证项目的并行度，往往需要多部门合作。学计算机的人都知道，多线程并发的效率是最高的！然后多部门沟通时，人与人之间的沟通并不像线程这间的通信这么简单。好的架构设计和分工可以减少沟通或提高沟通效率。而分工和任务项的越细，并行度越高，会带来明显的沟通成本。人不是机器，计划总是不如变化快。一个蝴蝶可以引起一场海啸。一个小任务项的DELAY，一定会引起相关方的等待。与时，沟通产生了，但沟通的大会小会，一般不会进入项目计划。
4. 搞大项目，搞完美的项目，是大团队的通病。大技术团队，人强马壮，想去作一些小公司、小团队不敢想的大项目；那些很好的小项目，只要综合好了，一样可以产生大项目的效果。但是，大团队如果去作小项目，那这个大团队存大的价值就会被挑战。作大项目的时候，大团队会在一开始就严格要求每一个细节每一个feature，很多80%的人在80%的时候 不会用的功能在一开始就被设计进去，并要求zero bug。
5. 管理者确实喜欢搞一些统一的基础服务或基础设施；让别的项目或产口依赖这些基础，从而带来问题是，这些基础服务一点变动或升级，一定会引起上层依赖方的回归测试或各种问题。于是，有些时候上层应用宁可自已研发一个独立的基础服务。但这样又会进入一种不统一的状态，管理者会认为大量软件基础被重复研发了，于时又开始会提出统一的架构与基础设施。这时候另一方，即商业部门会来挑战说“为什么完成这样的一个FEATURE需要这么多时间呢？”；基础服务还需要有很多的培训学习期，比不上市场上的开源软件广为人知；
6. 大团队里很容易让个人的工作积极性受压制。成绩在很多时候是个人英雄主义的产物。大团队里如何发展个人英雄主义？老板们者很头痛，因为这个确实是个麻烦事。

大团队的危险性大家都深有体会。我们可以从几点来克服或减小他的危害性：

1. 让小团队，小部门去完成大项目；很多互联网知名公司和网站都是由小团队创建的。小团队适合初创的项目；
2. 减少决策层次，充份信任最接近用户和客户，离炮火最近的决策人；使用最简单的决策工具。
3. 搞小项目，把小项目组合成大项目；
4. 多用已有的开放软件或组件，少作统一封装。竟可让各应用自由封装，也不要出统一的服务。除非这个统一的服务边界相当明显，调用相当方便，否则我建议宁可费点人工重写，也不宜搞统一封装提供给多个不同的业务或上层应用。互联网上，没有什么东西找不到的。可以搞小团队内的封装，但不建议强制大团队的统一。这种统一只会减少团队工作的灵活性。传统软件的管理者一般会倾向于选择统一的底层封装，而互联网服务的海量客户导向特性却要求极高的灵活性。很多产品的生命周期是很短的。服务器一开，项目启动了，服务器一关，项目就结束了；
5. 作减少，不要作加法。一开始就要减少需求，减少那些少量用户会用的功能，把主流程，主要服务搞好。让大部份主要功能可以稳定的工作。
6. 允许BUG，搞好业务相关的功能。互联网是一个工具，把工具相关的功能作好。允许项目中存在BUG,并让用户去发现。这一点和WEB2.0的BETA理念一致，大团队一样可以用这个理念。
7. 给团队成员时间去学习和创造，让成员有机会成为英雄。

PS: 经常回想99年的时候作项目，三五个人，快乐的工作。