受组织结构影响的重要因素有沟通、效率、标准、质量和所有权。让我们逐看看各个因素，分析组织是如何影响它们的以及这些因素为什么对可扩展性很重要，从而在组织和可扩展性之间建立一一种关系。

受组织结构影响的重要因素有沟通、效率、标准、质量和所有权。让我们逐看看各个因素，分析组织是如何影响它们的以及这些因素为什么对可扩展性很重要，从而在组织和可扩展性之间建立一一种关系。

沟通是所有流程的核心。组织沟通不畅，一定会导致应用故障。如果没有清晰的沟通，那么组织架构的设计、运行中断范围的控制、客户投诉的处理成者产品的修改都将惨不忍睹。如果一个团队有50个人，没有定义任何分工或层级，那么极有可能每个人都不知道其他所有人在做什么。团队中的成员也很有可能不知道应该问谁什么问题，或者把什么信息发送给谁。这样的沟通不畅，在大多数时间中，也许只会造成一-些小问题，比如可能需要问50个人才能得到一个问题的答案。但终会有一天，当一个工程师被与她无关的问题打扰了一年后，会错过一个关键请求，而答复这个请求或许可以防止运行中断的发生，或者帮助一个中断迅速地恢复运行。那么这时是错在这个工程师忙中出错，还是错在组织架构有问题导致不能清楚有效地沟通呢?



当组织架构使工作流顺畅时，个人和整个团队的效率(即输出和输人的比)都会提高；而当项目陷人不必要的组织层级时，效率就会降低。在敏捷软件开发方法中，产品责任人通常应该和工程师坐在一起，以便立即解答有关产品的问题，而不是通过电子邮件进行冗长的解释。如果工程师在开发过程中遇到需要得到澄清的地方，她有两个选择:一是自己猜测可以行进的方向，二是询向产品责任人并等待答案。在得到产品责任人的答复前，工程师只能止步不前，或者转而做其他不相干的事情，比如浪费许多时间搭建环境和重新研究资料，或者去游戏室，浪费几个小时打电视游戏。让产品责任人和工程师坐在一起， 这样就可以快速答 复问题，不让工程师有机会在电视游戏上得高分，从而提高效率。对于可扩展性来说，效率降低意味着组织可用资源减少，这时资源更倾向于投向短期的面向客户的特性而非长期的提高可扩展性的项目。这虽然有助于实现季度目标，却损害了平台长期的发展能力。

在一个组织内，唯一有意义的标准，就是组织遵守的那些标准。如果在编码、文档、规格说明书以及部署方面，一个组织没有制定、推广并遵守一系列的标准，那么一定 会降低工作效率、降低产品质量、增加发生重大生产问题的风险。以一个采用矩阵式架构的组织为例，在每个组中与产品经理、项目经理和业务责任人合作的工程师都非常少，可能只有一名。由于没有非常重视标准的沟通，所以这个唯的工程师很 容易会不遵守以前建立的准则。又由于没有其他的工程师或经理来检查这个工程师是不是忘记了提交自己的文档，他在效率方面得到了短期收益，这样做在他看来是利大于弊。但是一个组织应该帮助工程师理解并且遵守已经建立且大部分人同意遵守的准则、原则和规范。至于不遵守准则而对可扩展性可能产生的影响，不妨想象一下，假如一个工程师对于所有服务都要在三个或更多个不同的物理实例上运行的架构原则不以为然，于是等到部署服务时，人们才发现这个服务只能在一个服务器上运行。这无疑会增加发生服务中断的可能性，而且也不能把这个服务扩展到超出一台服务器的产能。

如前所述，不能遵守规范和标准的组织，只会降低产品的质量。一个小例子是，一个具有固定的单元测试框架和流程的组织，由于团队规模或团队构成的问题，导致这种单元测试框架没有被接受和实施。前面讨论过的那位唯一的工程师，也许发现这种偷懒的举动太过诱人，于是对那些为所有特性建立单元测试的请求置之不理，不再进行单元测试。这很可能会导致代码质量低下，从而使大小缺陷的数量增加。这样还会进一步导致应用发 生故障停机，或者造成其他可用性问题。由于bug增多和产品问题，部分软件开发资源会被分流，从而用于编码或扩展项目 (如数据库要的特性以支持长期的提高可扩展性项目。分区)的资源也就少了。正如我们在前面见到过的，当资源短缺时，就更难以推迟短期的客户需最后一个可以直接影响应用或服务的可扩展性的主要因素是所有权。假如某个组织内的团队由50个工程师组成，既没有职责分工也不分层级，那么我们很可能会发现许多工程师都在开发同.段代码。 当许多人都在开发同一段代码， 并且没有明确或模糊的层级时，没有人觉得这段代码是自己的责任。这样就没有人会去检查别人的代码是否遵守了标准、是否构造了要求的功能或者是否维持了产品所需的高质量。这进而会导致前面提到的资源利用率不高、更多的生产问题以及沟通不足等问题，从而影响到应用的可扩展性。

综上所述，我们可以看到，组织确实对影响应用的可扩展性的关键因素有所影响。既然我们已经对从可扩展性的角度考虑组织有了基本的认识，接下来该了解组织的决定性因素，即规模和架构。