某论坛上关于如何建设管理软件团队的一些问答，其中一些对话颇有意义，记录之，分享之。

Q: 啥子是Programmer manager
A：program manager的program不是程序啦。。。一般管一个business domain的end to end solution. 在甲方的话，一般还会分成几个team，下面的service manager管operation和client management，还有initiative manager管一堆project manager来deliver project。

Q: 请教一下，从带10-20人到带更多的人，最需要注意的是什么？

A：
请教不敢，我就是完全失败的一个典型，呵呵，经验教训可以简单说说。

我自己的经验，其实技术团队的管理， 真正质变的大概是从超过25-30人起， 道理很简单。 一个人可以直接充分管理的人大概就是4-5个为佳， 25个以内，分组就可以，超过25/30个以后就必须分3层，管理成本就开始剧烈增加，啥问题都出来了。
二层结构的时候，下面人有问题容易及时修补，对小组leader的协调能力要求不高，只要负责即可，这种情况下基本没有多少管理成本。但是到了三层结构以后对第二层的人要求比较高，如果没有合适的第二层人员，就基本是个乱摊子。老大这时候主要的工作，其实就是应该在人数超过50之前，尽可能快的培养出适合第二层次的负责人，而不是急着做大导致整天忙着救火。另外分层架构的一个必然问题就是容易产生帮派和分离势力，不注意这方面出现的内耗杀伤力极大。所以对下属马仔头目的监控会耗费你比较多的精力，而且同时还要充分考虑到如何让这些小流氓敏感脆弱的心理感觉到尊重。


我自己感觉50个人左右时是个大坎，如果可以突破就可以顺利向三层的黑社会组织结构发展，可以过度到100人以上，我们那时候的问题就是老板其实并没有意思到管理成本这个问题，错误的以为可以通过规模追求效益。在基本能突破50个人这个坎的时候，老板被上年的产值弄混了头，盲目发起了一场新战役，又空降了一个一心想做大事的牛人，两人一合作，就一起over了。我们当时的架构，老板热衷于搞大合并，把几个事业部合并了弄个大部门，把一些马仔头目拆分的乱七八糟的，说是充分利用资源，打破部门间的壁垒（扁平化管理？)，然后又乱七八糟塞了一大堆人进来，原来的三层结构彻底打破，结果变成无人负责制。

软件项目的团队规模，个人还是觉得越小越好，可能的情况下尽可能走小而精的道路，在培养了团队成员的默契和一些共同的文化认同以后，再逐步拆分扩充，要比一开始就上大摊子有效的多。 我们之前成功的一个项目，最初的预算是60人，我采取的做法现在看起来非常明智，首先只找了1，2个核心的程序员和少数的普通程序员，通过结对开发的方式让他们彼此熟悉和磨合，在这个过程中完成基本的核心开发，在2个月以后再补充第二批程序员，把原来人分拆重新结对。通过这种方式逐步过度到20-30的团队。 再往后考虑到个人能力和管理成本的问题，就拒绝再加入了，最后以项目规划的1半左右的资源就完成了开发工作。而且这期间培养了不少人，大部分人后来又补充到其他项目，逐步建立了整个部门技术团队。这种逐步圈地的做法比较稳妥，也容易培养团队之间的信任文化，那时候整个工作气氛还是蛮好的，我们是公司最少加班的团队，但是是公司开发效率最高的团队。而其他几个规模只有一半，一开始就砸进几十个人的项目，都是问题多多那种。

100个人以上的团队，我只见过，没管过，，基本上我觉得战斗力要比50人甚至30人低，吵架pk聊天时间多过做事时间，别相信啥1+1>2 。最近听朋友说XXX为了保证销售额，把销售人员增加了1倍，销售人员任务降低一半，这种规模游戏也就是骗领导有用吧，地球人都知道，横竖能干活的就是那么几个人。

对一个leader来说，我自己的感觉就是4，5个人的时候啥都可以不管，自己把活干大头就好了，要有nb的小弟就扔给她做。 10来个人的时候，就要注意大家吃喝玩乐心情愉快，因为到了这个规模，基本上靠个别牛人发飙已经不可能搞定工作了，需要你去努力拍下属的马匹投其所好，让他们赏脸做事，而且一定要有风险控制机制，关键工作岗位一定要有backup。规模再往上走，自觉往后面站，基本上你工作的中心就是要培养一批打手让他们自己折腾自己。


P：
Q： 受教了，多谢分享！
一个问题就是：在2个月以后，团队开始扩充时，如果仍然采用结对的方式，而不是传统的分组（几个人一个小组，然后选拔组长），如何保证队伍具有非常一致的目标和想法，如何保证团结？

A：
软件工程里面有个著名的brook定理，大意就是向一个进度落后的项目加人，只会让这个项目更加落后，引申开来就是应该避免在项目的中后期大幅度加人。 这里面的主要的原因有几点。

1. 新人加入团队以后需要获取团队成员的信任和尊重，这需要比较多的沟通和交流成本，软件开发说到底是一种群体活动。
2. 新人要理解，认同团队的文化，也需要很大的成本
3. 新人需要对项目进行学习和了解，过程会拖累其他开发人员
4. 新人太多，有可能会彻底摧毁原来团队已经建立的平衡结构，比如团队文化， 团队间的角色定位。
5. 管理者会因此大幅度的增加管理成本，另外，管理者很可能并未做好管理这样团队的准备，有可能会因为不合适的行为和决定导致团队崩溃
6. 人员增加以后，彼此之间的交流沟通成本会大幅度增加，超出一般人的想象。

因此一般正确的做法是避免在项目中后期加人，虽然这么显然简单的道理大部分老板都不相信。

所以表面上看，逐步圈地的做法是违反brook定理的。但实际情况，恰恰因为结对工作在很大程度上克服了上述的问题，所以你要是理解了结对的收益，就可以明白为什么结对可以保证“队伍具有非常一致的目标和想法，保证团结”


1. 结对可以让新人之间加快了解过程，尽快的融入团队， 不使用结对的方式，一个新人可能需要1，2周才能和团队相处融洽， 使用结对的方式以后，1，2天就可以很熟悉。

2.结对降低了新人的学习成本，在结对过程中，原团队的成员采取人盯人的方式尽快的将技能和团队文化传递给新人，而新人一开始就可以上手工作（即便是菜鸟，在结对过程中也可以通过质疑和提问对老人提供帮助和监督，而出于维护个人的自尊，团队成员一般都会急于向新人推销，证明自己），更有成就感和归宿感。对团队也就更容易认同。

3. 结对是分而治之的，有助于避免新人因为陌生环境产生分离感，建立自己的帮派。 有助于强制性的向新人灌输团队的目标，保证团队的团结。习惯了结对的工作模式以后，程序员之间必须强制性的进行沟通和交流，也可以避免产生帮派和内耗。

4.作为boss更关心的一点就是，通过结对这种方式，可以获得足够的backup，可以避免因为人员流动给项目带来毁灭性的风险。因此可以大幅度的降低管理成本。我们项目中期流失了近三分之一的人，进度没有受到任何影响，所以前期boss极力反对做pp，后期大力支持。我们自己有过一个大致统计，正常情况下离职一个人，要损失至少半年的人工。

通过结对这种方式，互相之间建立了沟通和信任机制，再划分如果有目的的小团队，就比较自然，另外在不同的小团队之间交换结对伙伴也可以做激励和监督作用。而一次性投入的建设新团队，碰到的问题会更多。

这个项目其实失败的一个地方就是中期迫于人员流动而放弃了结对，最后导致帮派和内耗，纠正过来化了血本，否则还能做的更好。人员流失有一部分是因为个人当时管理经验不足，对问题的解决欠妥，还有一个原因是原材料不合适，老板在团队组建之初盲目的招来了一些并不适合的人（后来碰到一个老板，居然跟我提招10留1的理论，Orz），也为后来的内耗埋下了隐患。这也算是一个经验，团队成员的选择leader一定要过问，对于那些性格比较偏激，难以控制的人应该尽量回避，绝不可以因为资源紧迫就充数。

按：pp的工作方式，对团队成员性格有一定要求。
Q：
任何团队的组织划分，一定不是用技术最好的人来做leader。对技术好的人要进行压制。不管有多出色，都要尽力扶持听话的人。
找技术好的人是对的，但是他技术好，你技术不好，就面临挑战了。何况技术好，不听话的，到哪里都是干活的命，没有人会重视他们的。

A：
你老外说话也不真见外，按你这样管， 几天大家就造反了。

软件团队和一般的团队区别非常大， 对软件团队来说，最好的管理模式就是不管理， 让大家自己发挥，做好足够的引导工作就好。小团队leader身先士卒起个带头示范左右，大团队， leader要躲在后面做好后援当保姆。 技术好的人的做leader是非常自然的，不懂技术的人做负责人倒是比较容易引起问题，技术人员都比较骄傲，除非是个美女mm带头，那还可以忍忍。 不是说不懂技术的人做不好pm，但是没有技术背景的人天然就和技术人员有鸿沟，技术人员背后搞的小九九，花样那个多，所以没有技术背景，管理成本会比较高。

有个老外专门写了本书论证为啥技术好的人就该做leader， 你可以找找看。

按：管理层对技术人员的不尊重和粗暴压制， 才是技术人员不听话的一个重要原因。

Q：
说起来， 管理无所谓，只要肯听话的，这个是永远的原则。
听话的，能力也强的--这当然最好的，但是一般听话的能力都比较一般。要是能力强，不听话，最好不要，这样的人， 很容易出问题。

A：
软件开发和普通的项目是有根本的差别的，软件本质还是个体的脑力劳动， 所以软件的生产力完全取决于个人的能力和工作态度。 2个程序员之间工作效率的差别可以轻易超过10倍， 所以你找找再多听话的人又有什么用？

能力的问题可以举个真实例子： 某500强企业开发的一个业务系统， 投入近20个人， 历时2年至今还不能上线。而同样的东西，在另外一个团队只是2个人一个月的工作量而已。第二个团队的平均人工是要低于第一个团队的。

态度的问题也可以举个真实例子： 某公司开发的一个应用系统，4个人组成的验收团队测试了5个月只找到40个的缺陷， 系统提交客户以后，客户方自己组织测试，3天内就发现了40个以上的重要缺陷。


任何一个公司，都必须有听话（执行者）和不听话的人（创造者和破坏者）的存在，否则这个公司就离死不远了。 管理要的不是简单的听话与否，管理者关心的应该是可控和有效性。

Q：
为了达到目标，有效性就是听话，完成任务达到目标可控性，也就是要听话。

A：
算了，让我去死吧。

按：管理人员和技术人员的沟通真是鸡同鸭讲，呵呵。