《架构即未来》阅读笔记01

组织的设置

组织对可扩展性的影响

组织中一些最重要的因素会影响沟通、效率、质量、标准和责任。让我们来分析一下组织是如何影响这些因素的，以及为什么这些因素对扩展性很重要。通过这些分析，建立组织和可扩展性之间的因果关系。

当组织有利于工作的时候，效率就会得到提高;反之，当出现不必要的结构层次且需要大量交流才能完成工作的时候，效率就会降低。在敏捷开发的过程中，产品负责人往往和工程师坐在一起，确保高效而快速地回答有关产品的问题。如果研发工程师需要澄清产品的功能点，那么他有两种选择，一是猜测该怎么做，二是等产品经理回答。在等待的这段时间里，要不就去做另-一个项目，要不就去做些无价值的事情，比如玩游戏。大量的等待时间可能会造成团队无法完成承诺的任务,把一些不必要的事情带入到未来的迭代中去，所以会延迟或者降低潜在的投资回报。

安排产品负责任人和工程师坐在-起可以使有关的问题很快得到解答从而提高效率。坐在一起是一把双刃剑，它也可能降低效率。首先，完成项目的成本提高了。其次，当资源紧张的时候，资源向面向客户的短期项目倾斜，结果牺牲了长期的稳定性项目。季度目标可能会在短期内实现，但是因为缺乏资源而造成的技术负债增加，结果造成系统故障而中断服务，搁浅新产品的上线计划。

可以通过标准化来提高组织的效率。一个不注重代码、文档、规范和配置标准的制订、发布和应用的组织，研发效率和质量必然低下，生产中出现严重问题的风险很大。要很好地理解这一点，我们可以考虑一个完全矩阵化的组织，该组织只有少数几个工程师与产品经理、项目经理和业务负责人在一起工作。如果不采用共同的标准，那么团队很容易在什么是最佳实践的问题上出现严重分歧。因为研发团队追求能有更大的产出，所以不知不觉地忽略了要按照标准注释代码，但这是以牺牲代码未来的可维护性为代价的。为了避免这些问题，大的机构会帮助工程师理解发布指南、原则和共同规范的价值。

团队规模

当然，个体之间存在差别，必须考虑团队整体的经验程度。如果一个团队高、中、低搭配平衡，那么中等规模的团队也可以有效地运转。通过比较发现，如果一个团队都是高级工程师，比如在基础设施项目.上,很可能团队的规模再扩大一倍也不是问题，因为沟通的成本比较低，而且不会为那些普通的工程任务分散精力。当确定团队的规模时，应当考虑所有这些问题，厘清团队规模要多大才能保持高效率，不至于因为规模太大，负担过多而影响生产率。

管理经验、团队在职时间和经理的责任，都是限制团队规模的约束条件。限制团队规模的目的是减少经理的负担，使团队创造价值的时间最大化。

与前面的三个因素不同，最后一个因素是业务的需要，其目的是加大团队的规模。业务负责人和产品经理想总是想要增加收入、击败竞争对手并增加客户数量。为此，他们经常需要研发更多、更复杂的功能。保持团队规模小的一个主要问题是大的项目需要非常多的研发迭代时间。其结果是项目需要更长的时间才能交付给客户。第二个问题是增加工程师的数量需要相应地增加支持人员的数量，同时增加管理人员。把工程类的经理称为支持人员，或许会冒犯他们，事实上，这正是管理所应该做的事情，即支持团队完成项目。团队越大，每个工程师所需要的经理数量就越小。

要想加快项目的进度，可以把项目进一步分解， 但是这种分解有一个限度。即使考虑到了这个因素，有一点还是非常清楚的，那就是:团队的规模越大，项目交付的速度就越快，这样团队就可以承接更大的项目。