本文字数: 4468字
阅读时间: 9分钟
从去年夏末至今，我一直在阅读《架构即未来：现代企业可扩展的Web架构、流程和组织（原书第二版）》这本书。全书阐述了经过验证的信息技术扩展方法，对需要掌握的产品和服务的平滑扩展做了详尽的论述。具有一定的参考价值。从今天起，我将逐步总结之前所看内容，以飨读者，也以便自己回顾。文章既有摘转录，又有自我理解批注。
本文是该书的第一部分的中间部分，是书中的第三章，主要介绍了组织中人员的可扩展性配置的理论与实践经验中的组织设置。
目录
组织的设置
1. 组织对可扩展性的影响
2. 团队规模
3. 组织结构
组织对可扩展性的影响
沟通和协调，对任何需要多人努力才能完成的任务来说都是必要的。当出现不必要的结构层次且需要大量交流才能完成工作的时候，效率就会降低。
在敏捷开发的过程中，如果研发工程师需要澄清产品的功能点，那么他有两种选择，一是猜测该怎么做，二是等产品经理回答。但大量的等待时间可能会造成团队无法完成承诺的任务，把一些不必要的事情带入到未来的迭代中去，所以会延迟或者降低潜在的投资回报。而安排产品负责人和工程师做在一起也是一把双刃剑，它也可能降低效率。首先，完成项目成本提高。其次，当资源紧张的时候，资源向面向客户的短期项目倾斜，结果牺牲了长期的稳定性项目。
我们可以通过标准化来提高组织效率。如果不采用共同的标准，那么团队很容易在什么是最佳实践的问题上出现严重分歧。例如忽略按照标准注释代码，是以牺牲代码未来的可维护性为代价的。为了避免这些问题，大的机构会帮助工程师理解发布指南、原则和共同规范的价值。支持偏移原则行为的最常见借口是，这个服务对系统无关紧要。如果真的是这样，那么为什么要浪费时间来研发它？如此说来，团队没能有效地使用研发资源。因此，一个团队如果不能养成遵守规范和标准的习惯，本质上是组织容忍了研发质量标准的降低。
内部代码长角(Longhorn)，对外称为Vista的微软操作系统就是在一个机构中典型的标准和质量失控的例子。
归属权也会影响系统的可扩展性和可用性。当很多人在同一套代码上做研发的时候，如果代码各部分归属权不清楚，那么就没有人会感觉到自己对此有责任。
这样，从扩展性的角度来观察，我们所关心的组织已经有了一个清晰的基础。把组织结构和扩展性关联起来，围绕着他们建立一个支持性的组织结构是非常重要的。这也是决定一个组织的两个关键因素：团队的规模和结构。
团队规模
在确定最佳团队规模的时候，必须要考虑四大因素，包括管理的经验、在职的时间、管理的任务以及业务的需要。
团队的大小各有利弊。关键是平衡团队的规模为组织寻找最优的方案。而寻找最优方案的重点在于为组织寻找最佳的团队规模，并不存在一个适合所有团队的魔术般的数字。
团队规模的下限是6人，上限是15人。亚马逊把上限叫做“两张披萨饼准则”，即任何一个团队的规模不能大过两张披萨饼所能喂饱的人数。
当确定的团队规模的时候，首先要考虑的因素是经理的经验。人的经验是确定最优团队规模的一个关键因素。
第二个要考虑的因素是团队的任职时间。个体之间存在差别，必须考虑团队整体的经验程度。如果一个团队高、中、低搭配平衡，那么中等规模的团队也可以有效地运转。当确定团队的规模时，应当考虑所有这些问题，厘清团队规模要多大才能保持高效率，不至于因为规模太大，负担过多而影响生产率。
每个公司对经理应该负责的任务有不同的期望。基层经理的管理职责包括：
- 确保工程师们在有价值的项目上产出高
- 确保完成行政管理工作
- 确保掌握项目和问题的进展状态
这里要知道，经理处理的任务越多，团队就要越小，以确保经理可以完成所有安排的任务。当确定组织的最佳团队规模时，任务的数量和完成这些任务所需要的工作量是两个主要因素。而一个经理每周的时间很容易被那些看起来十分快的任务所填满，例如一对一会谈。
最后一个因素是业务的需要，其目的是加大团队的规模。保持团队规模小的一个主要问题是大的项目需要非常多的研发迭代时间。第二个问题是增加工程师的数量需要相应地增加支持人员的数量，同时增加管理人员。
团队规模不正确的时候出现的信号有沟通不畅、生产率低下、士气低落都是团队规模太大的信号。沟通不畅可能有多种形式，包括工程师们缺席会议、不回邮件、错过规范变更或者多个人问同样的问题。生产率底下可能是团队规模太大的另外一个信号。如果没有人知道、引领、答疑，初级工程师要比正常情况下折腾的很久。相反，高级工程师们忙于回答太多初级工程师的问题，以至于无法完成自己的工作，也会造成生产效率的降低。
功能点和场景点是度量功能的两个不同的标准化方法。功能点从用户角度出发，而场景点从工程师角度出发。
士气低落这种不满的情绪清楚的说明问题，尽管士气低落可能有很多原因，但是团队规模因素不应被忽略。如果团队规模太小，要注意的信号包括不满意的业务合作伙伴、微观管理的经历、过度劳累的团队成员。太小的团队无法快速研发和交付规模较大的功能。心怀不满的业务负责人并不直接抱怨工程师和技术负责人，而是把力气花在增加预算聘请更多工程师上。
正常情况下，有效率的经历如果趋向于微观管理将是一个令人担忧的迹象。这时，通过扩大经理的聚焦点来解除他对团队的持续关注。在这种情况下可以安排的特别任务包括担任某个标准委员会的主席，负责一个跟踪bug的新工具评估活动，建立一个旨在指导工程师的导师计划等。
确定一个团队是否太小的第三个迹象是，看是否有工作过度的员工。这种工作过度的情况对大多数的初创公司而言是可以预见的，甚至是必要的，但是如果持续几个月，最终会消耗团队的干劲，从而导致员工流失、士气低落、质量不佳。最好能留意并分析工作时间的记录，尽早纠正问题，而不是等到大多数工程师递交辞呈时才意识到这个问题。
给小团队增加工程师，不说轻而易举但也直截了当。比较困难的是拆分一个增长很大的团队。当要拆分一个团队（包括在分解代码）的时候，必须要考虑一些事情。首先要根据代码和工作来聚焦。最佳方案是根据故障域来拆分团队和代码，通过隔离服务来限制故障所带来的影响。下一个要考虑的问题是新经理的身份。这是一个外聘或内选的机会。外聘的可以带来新思路和经验，内选的熟悉人员和流程。最后一个要素是对业务部门会有什么影响。如果在工程团队、质量保证、产品管理和业务团队之间有一对一的关系，那么很明显，当团队拆分后这些关系就会发生变化。应该在拆分决策前，与受到影响的负责人讨论清楚这些变化。
最后，我们认识到，团队规模是确定组织对应用扩展有效性影响的主要决定因素。
组织结构
组织结构指的是一个组织内部团队之间相互关系的布局。功能型和矩阵型两种基本结构已经使用多年，一种新型的敏捷型结构最近也开始流行。最常见的情况是，设计一种混合的结构来最好地满足公司的需要。
职能型组织
军队和工业界曾经使用过职能型结构的组织形式。职能或竖井式方法的组织结构有很多好处。所有的经理几乎都是按照层级提升的，即使他们的业绩表现并不抢眼，他至少清楚如何按部就班地工作。除了在管理和工作伙伴方面的同质性和共同性外，职能型结构的优点还包括职责明确、容易分配任务、更好的遵循标准规范。用运动来作类比，职能型的组织结构就像在高尔夫球场练球，高尔夫球手们想要练好和打好高尔夫球，就要和其他高尔夫球手，甚至教练混在一起，切磋技艺。
职能型组织架构图
职能型或竖井式结构的问题包括缺乏单一的项目负责人和跨职能部门的沟通效果不佳。这主要是项目的整体责任不会全部落在管理层级中某个人的头上，而是逐级上升，直到最后落在技术总负责人的头上。另外，在职能型组织中跨部门的沟通出奇的难。另外的一个挑战就是团队之间的冲突。
关于冲突
好的冲突（认知型冲突）是健康的争辩，是团队关于该做什么或者为什么要做而发生的冲突，它涉及更大的视角和更多的经验。坏的冲突（情感型冲突）基于角色，经常涉及怎么做或者谁该做。
好的或者认知型冲突有助于团队扩大行动的可能范围。不同的见解和经验凑到一起有机会从更多角度出发解决问题。
通过营造开放、关爱、尊重的文化氛围，把认知型冲突最大化，情感型冲突最小化。通过设置明确的角色和责任，限制情感型冲突的根源。通过吸纳各类人才在技能和视野上互补，最小化集体思维的机会，最大化策略的选择范围，鼓励机构快速成长。
当同质性的好处超过整体协调和所有权所带来的问题的时候，可以考虑采用职能型组织结构。比如，采用瀑布式研发的组织，经常能从按职能划分的组织结构中获益，因为该结构恰好与瀑布型方法中固有的阶段控制相匹配。
矩阵型组织
矩阵型组织结构的主要概念是层级的两个维度，且包括至少两个管理维度，每个团队的成员或许有两个或多个管理上级，其区别主要在项目管理。
与职能型组织高尔夫球运动比喻相对照，矩阵型类似高尔夫球员应该时常离开高尔夫球场去练习其他的肌肉，比如参加举重培训或者跑步。这种交叉培训的方法和矩阵型组织类似，在不替代高尔夫或工程的基本训练的前提下，通过给予其他的任务比如跑步或项目管理来加强。
矩阵型组织架构图
矩阵型组织在缓和项目责任和沟通问题的时候也引入了其他问题，主要涉及多个管理上级和个人精力分散的问题。向两个或多个人汇报，矩阵型组织可以非常复杂，需要一个人参与多个团队，收到每个老板各自的指令，所以团队的成员会感觉到更大的压力。
敏捷型组织
SaaS的独特要求，敏捷开发方法的出现，还有职能型和矩阵型组织弊端的存在，使被称为敏捷型的新组织结构应运而生。虽然SaaS的定义仍存在着争议，但是大多数人都同意它包括了一个预约定价模式，客户根据用量付费，而不是一个协商好的许可费用。这些应用的架构通常是支持多客户的，这就意味着几个客户共享同一个软件的实例。随着从提供软件向提供服务方向发展，技术人员开始思考如何做个好的服务者而不是软件开发者。
形成敏捷组织概念的最后一个环节，是认识到技术团队的组织结构对软件的质量、扩展性和可靠性都有非常重要的影响。然而，并不是每个技术问题都应该通过技术手段来解决。当反复验证时会发现，这一问题始终会回到组织结构上，例如团队之间的冲突，一个人汇报给多个管理经理，而这些经历并不能理解每个人的任务优先级。事实上是人开发了技术，因此，人对过程至关重要。
为了简化，我们把跨职能同时符合服务架构的制作，标示为敏捷型组织。在这种敏捷型组织中，团队完全是自助管理和自给自足的。跨职能部门的总监、副总裁以及敏捷型团队替代了工程副总裁这样的常规管理角色。
敏捷组织架构图
可以这么说，没有一种固定的模板式的组织设置是可以套用的，每个公司和组织都有自己的目标与使命，对于组织的设置这个话题，既基础，又因情况而异，而正因如此，也导致了很多公司和组织盲目跟风学习导致组织架构一变再变，原本应该提高效率的变化适得其反。因此，在事情的一开始，我们就应该想好接下来的组织变化，符不符合我们现在的目的和价值观，是否能激活最广大人的生产效率。
