团队的组织形式

本文是对《架构即未来》第2章的总结
1. 团队组织的核心就是人员的管理问题
2. 规范和标准对于一个团队来说非常重要，个人理解，它能保障团队成果的质量底线，如果一个团队不能养成遵守规范和标准的习惯，那这个团队的产出成果就会良莠不齐；规范和标准是一个团队由游击队走向正规军的标志；
3. 团队中的任何工作都要职责清晰、明确；如果全凭自觉，靠吃大锅饭的形式，当任务下来的时候就不会有人觉得自己对它有责任，最终会造成团队像野草一样成长；
4. 团队的大小，书中给出的建议是团队的规模在6~15人；书中举了亚马逊的两个披萨的例子，即两个披萨就能喂饱的人数就是一个团队的最好规模，这个感觉比较抽象，不知道老外披萨是多大。但是根据个人经验来说，团队越小就越好管理，你能非常轻松就能知道团队里每个人都在干什么，但是随着团队的人数增加，这样的了解就越发困难了。其实，小团队的力量毕竟是有限的，小团队能做好一件具体的事情，但是一旦事情变复杂了，小团队也就难以承担了。
5. 制约团队规模的三个因素：管理经验、团队成员的在职时间和经理的责任；其实，总结起来就是管的和被管都是有经验的，大家都习惯性地知道自己该干啥了，这时团队就好管了，团队规模也就可以继续扩大，否则，团队就扩不起来；
6. 影响一个团队规模的最关键因素就是人，具体而言就是团队成员的工作经验以及团队成员的任职时间，如果团队的成员都是素质较高的高级工程师，他们都知道自己要干什么、下一步要做什么，那么这样的团队管理起来将会非常容易，这时成员再扩大一倍，团队的工作效率一样不会受到影响；
7. 团队规模和团队所承担的工作量有关，如果一个团队的工作量非常大，所需要的成员非常多时，如果它的成员都是经验丰富的，倒不是问题，如果人员的经验程度不高时，为了管理的有效性就需要把团队再拆分成多个小团队了，否则就很难有效了解每个人的进展，规划他下一步的工作，管理起来就异常困难。
8. 基层经理的工作职责：（1）确保工程师们在有价值项目上的高产出，即要了解每个成员的状态；（2）确保完成行政任务；（4）确保掌握项目和问题的进展状态；
9. 如何确定一个团队的规模是不是处于一个正常状态呢？这分为两个问题：
（1）怎么样才能确定一个团队的规模是不是太大了呢？
当团队规模过大时会有一些负面现象出现：沟通不畅、生存率低下、士气低落；
（2）怎么样才能确定一个团队的规模是不是太小了呢？
事多人少，大家的工作压力大；团队负责人闲着没事干总是插手团队成员的工作中；
10. 团队管理中的冲突分为认知型冲突和情感型冲突，认知型冲突时是健康的争辩，例如团队的头脑风暴，这种思维的碰撞更易产生新的想法；情感型冲突是坏的冲突，它是基于角色，经常涉及责任划分等等，还有的涉及到政治性或领地性的，如果处理不当会对团队造成不良影响。
11. 团队的组织形式：
（1） 职能型团队，即垂直管理形式，该形式是按照职能组织团队，例如：测试的人全部归到测试团队，开发的全部归到开发团队，产品的全部归到产品团队；职能型团队组织形式的优点：职责明确、容易分配任务，容易为工作制定标准，团队的所有成员所干的工作都是同样性质的，每个人至少都知道怎么按部就班的工作；缺点：大部分的项目都是跨部门合作来完成的，这种组织方式容易造成跨部门沟通困难，引起团队之间的冲突；职能型团队的组织形式如下图所示：

（2） 矩阵型团队，即垂直水平混合模式，它为了解决职能型团队造成的团队之间沟通问题，引入另外一个角色进行项目负责，该项目负责人进行跨团队协作和沟通，团队中的成员要接受双重领导，一个是职能团队的领导，另一个是项目团队的领导，这种方式的多重领导容易给团队成员造成困惑，还容易造成任务分配冲突等各种问题。

（3） 敏捷型团队，即水平管理模式，这种组织形式要求每个团队中所有需要的领域的人都齐全，团队完全是自给自足，自助管理，如下图所示：

敏捷型团队中，大家来自不同领域，为了一个共同的目标走到一起，这种组织方式产生情感型冲突的概率会非常低；
12. 关于团队组织形式的看法，现在敏捷这个词很火，一旦一个事情敏捷起来就立马高大上了，虽然现在很多人都推崇敏捷团队，但是真正能敏捷组织起来的团队我还没见过，个人理解敏捷型团队组织起来有两个比较重要的困难：
（1） 敏捷团队对每个团队的成员要求很高，当团队的每个成员都是来自各领域的经验丰富的人员时，比较有用；但是，绝大多数情况下并不是这样，一般都是同领域内有一两个经验丰富的人带着一群刚入门不久的人，你很难把这样的人分到一个项目团队里让他独立把这个项目的开发或者测试做出来；
针对这个问题，书中建议采用人员跨团队共享的方法，这可以在一定程度上缓解经验丰富人员紧缺的问题；
共享人员时要特别注意责任明确、切记吃大锅饭、让一群人共同管一堆事等问题；即便人员要共享，也要明确分清楚哪个人负责哪个事情。
（2） 敏捷团队比较适合软件外包性质的工作，对于研发型的团队不太合适，因为软件外包的工作中，有相当一部分工作是类似的，成员干过一两次之后就有经验了，后续的项目就能自己照着做起来了；但是对于研发型的工作，因为，研发性质的工作大多面临未知的研发任务，一般需要基础好、学习能力强的人才能搞定一件事情，但是团队中这样的人不多，就不能为多个项目提供足够的人员；
（3） 服务端开发时，很多代码都是多个项目公用的，这时候就涉及到代码在各个不同项目的共同开发和维护，容易造成冲突；另外，在服务端开发过程中，需要从各个项目中抽象出一些公共项目、系统，作为后续业务发展的平台，采用水平组织形式的敏捷模式不利于跨团队抽象出这些平台性的东西出来。