这篇文章上次修改于 198 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 > Management of many is the same as management of few. It is a matter of organization.—Sun Tzu > 对多人的管理与对少数人的管理是一样的。这是一个组织问题。——孙子 In the past two chapters, we have discussed how important it is to establish the rightroles within your team and to get the right people in those roles. This hopefullymakes perfect sense and is in line with everything you believe: accomplishing greatthings starts with finding great people and getting them in the right roles. Now wehave come to the organizational structure, and you are probably wondering why thishas anything to do with the successful scaling of your application. The answer lies inwhat factors are affected by an organizational structure and in turn how importantthose factors are to the scalability of your application. 在过去的两章中，我们讨论了在团队中建立正确的角色并让合适的人担任这些角色的重要性。希望这是完全合理的，并且符合您所相信的一切：完成伟大的事情始于找到优秀的人才并让他们担任正确的角色。现在我们已经讨论了组织结构，您可能想知道为什么这与应用程序的成功扩展有关。答案在于哪些因素受到组织结构的影响，以及这些因素对应用程序的可扩展性的重要性。 This chapter will highlight the factors that an organizational structure can influence and show how those are also key factors in an application’s or Web service’sscalability. There are two determinants of an organization: team size and team structure. If you are given the size range of the teams and how the teams are related toeach other, you have a clear description of the organization. These two descriptors,size and structure, will be covered in this chapter, providing insight into the variousdimensions of each, large versus small team sizes and silo versus matrix structures. 本章将重点介绍组织结构可能影响的因素，并展示这些因素如何成为应用程序或 Web 服务可扩展性的关键因素。组织有两个决定因素：团队规模和团队结构。如果您知道团队的规模范围以及团队之间的相互关系，您就会对组织有一个清晰的描述。本章将介绍规模和结构这两个描述符，深入了解每个描述符的各个维度，大型团队规模与小型团队规模以及筒仓结构与矩阵结构。 #### Organizational Influences That Affect Scalability 影响可扩展性的组织影响 The most important factors that the organizational structure can affect are communication, efficiency, standards, quality, and ownership. Let’s take each factor and examine how the organization can influence it as well as why that factor is also importantto scalability. Thus, we can establish a causal relationship between the organizationand scalability. 组织结构可以影响的最重要因素是沟通、效率、标准、质量和所有权。让我们考虑每个因素，并研究组织如何影响它，以及为什么该因素对可扩展性也很重要。因此，我们可以在组织和可扩展性之间建立因果关系。 As we will see in Part II, Building Processes for Scale, which deals with processes,communication is central to all processes. Failed organizational communication is a certain guarantee for failures in the application. Not clearly communicating theproper architectural design, the extent of the outage, the customer complaints, or thechanges being promoted to production can all be disastrous. If a single team has fiftypeople on it with no demarcation or hierarchy, the chance that everyone knows whateveryone else is working on is remote. The possibility that an individual on this teamof fifty people knows who to ask what questions of or who to send what informationis unlikely. These breakdowns in smooth communication, on most days, may causeonly minor disruptions, such as having to spam all fifty people to get a questionanswered. There will come a day when after being spammed for a year with questions that don’t apply to her, that engineer will miss a key request for informationthat may prevent an outage or help to restore one quickly. Was that the engineer’sfault for not being a superstar or was it the organizational structure’s fault for making it impossible to communicate clearly and effectively? 正如我们将在第二部分“构建规模化流程”中看到的，该部分涉及流程，沟通是所有流程的核心。组织沟通失败是应用失败的一定保证。如果不能清楚地传达正确的架构设计、中断的程度、客户的投诉或正在推广到生产的变更，都可能造成灾难性的后果。如果一个团队有 50 人，没有界限或等级制度，那么每个人都知道其他人正在做的事情的机会就很小。这个由 50 个人组成的团队中的某个人不太可能知道向谁提出什么问题或向谁发送什么信息。在大多数情况下，这些顺畅沟通的故障可能只会造成轻微的干扰，例如必须向所有 50 个人发送垃圾邮件才能得到问题的答案。总有一天，在一年内不断收到与她无关的问题的垃圾邮件后，该工程师将错过一个关键的信息请求，这些信息可能会防止中断或帮助快速恢复中断。是工程师的错，因为他不是超级明星，还是组织结构的错，导致无法进行清晰有效的沟通？ The efficiency, the ratio of output produced compared to the input, of both peopleand entire teams can be increased when an organizational structure streamlines theworkflow or decreased when projects get mired down in unnecessary organizationalhierarchy. In the Agile software development methodology, product owners are oftenseated side-by-side engineers to ensure that product questions get answered immediately and not require long explanations via email. If the engineer arrives at a point inthe development of a feature that requires clarification to continue, she has twochoices. The engineer could guess which way to proceed or she could ask the productowner and wait for the answer. Until the product owner replies with an answer, thatengineer is likely stuck not being able to proceed and can either try to context switchto something unrelated, which wastes a lot of time setting up environments andrestudying material, or she can go to the game room and waste a few hours playingvideo games. Having the product owner’s desk beside the engineer’s desk helps maintain a high efficiency by getting those questions answered quickly and preventing theengineer from earning another high score on the video game. The problem withdegrading efficiency in terms of scalability is what it does from an organizationalresource perspective. As your resource pool dwindles, the tendency is to favor shortterm customer facing features over longer-term scalability projects. That tendencyhelps meet quarterly goals at the expense of long-term platform viability. 当组织结构简化工作流程时，人员和整个团队的效率（即产出与投入的比率）可以提高，而当项目陷入不必要的组织层次结构时，效率就会降低。在敏捷软件开发方法中，产品负责人通常与工程师并排坐在一起，以确保产品问题立即得到解答，而不需要通过电子邮件进行冗长的解释。如果工程师在某个功能的开发过程中到达需要澄清才能继续的阶段，那么她有两个选择。工程师可以猜测继续进行的方式，或者她可以询问产品负责人并等待答案。在产品负责人回复答案之前，该工程师可能会陷入无法继续的困境，可以尝试将上下文切换到不相关的内容，这会浪费大量时间设置环境和重新研究材料，或者她可以去游戏室浪费时间玩几个小时的电子游戏。将产品负责人的办公桌放在工程师的办公桌旁边，可以快速回答这些问题，并防止工程师在视频游戏中获得另一个高分，从而有助于保持高效率。可扩展性方面效率降低的问题是从组织资源的角度来看的。随着资源池的减少，趋势是倾向于短期面向客户的功能，而不是长期的可扩展性项目。这种趋势有助于实现季度目标，但会牺牲平台的长期生存能力。 The only standards that matter within an organization are those to which theorganization adheres. An organization that does not foster the creation, distribution,and acceptance of standards in coding, documentation, specifications, and deployment is sure to decrease efficiency, reduce quality, and increase the risk of significantproduction issues. Take an organization that is a complete matrix, where a very fewengineers, possibly only one, reside on each team along with product managers,project managers, and business owners. Without an extreme amount of diligencearound communicating standards, it would be very simple for that solo engineer tostop following any guidelines that were previously established. No other engineer or manager is there to check that the solo engineer has not forgotten to submit his documentation, and the short-term gain in efficiency might seem a great tradeoff to him.The proper organization must help engineers understand and follow the establishedguidelines, principles, and norms that the larger group has agreed to follow. As forthe potential impact of this noncompliance on scalability, imagine an engineer deciding that the architectural principle of all services must run on three or more physically different instances is not really important. When it comes time to deploy theservice, this service can only run on a single server, thus increasing the likelihood ofan outage of that service as well as not being able to scale the service beyond thecapability of a single server. 在组织内唯一重要的标准是组织所遵守的标准。一个不促进编码、文档、规范和部署标准的创建、分发和接受的组织肯定会降低效率、降低质量并增加重大生产问题的风险。以一个完整的矩阵组织为例，每个团队中只有很少的工程师（可能只有一名）以及产品经理、项目经理和企业主。如果没有围绕沟通标准进行大量的努力，独立工程师很容易停止遵循以前建立的任何指导方针。没有其他工程师或经理在那里检查单独的工程师是否忘记提交他的文档，并且短期效率的提高对他来说似乎是一个很好的权衡。适当的组织必须帮助工程师理解并遵循既定的指导方针、原则，以及更大群体同意遵循的规范。至于这种不合规性对可扩展性的潜在影响，想象一下，工程师决定所有服务的架构原则必须在三个或更多物理上不同的实例上运行并不重要。当需要部署服务时，该服务只能在单个服务器上运行，从而增加了该服务中断的可能性，并且无法将服务扩展至超出单个服务器的能力。 As described earlier, an organization that does not foster adherence to norms andstandards has the effect of lowering quality of the product being developed. A briefexample of this would be an organization that has a solid unit test framework andprocess in place but is structured either through size or team composition such that itdoes not foster the acceptance and substantiation of this unit test framework. Thesolo engineer, discussed earlier, may find it too tempting to disregard the team’srequest to build unit tests for all features and forgo the exercise. This is very likely tolead to poorer quality code and thus an increase in major and minor defects. In turn,this can possibly lead to downtime for the application or cause other availabilityrelated issues. The resulting increase in bugs and production problems takes engineering resources away from coding new features or scalability projects, such assharding the database. As we have seen before when resources become scarce, thetradeoff of postponing a short-term customer feature in favor of a long-term scalability project becomes much more difficult. 如前所述，不促进遵守规范和标准的组织会降低所开发产品的质量。一个简单的例子是，一个组织拥有可靠的单元测试框架和流程，但其结构是通过规模或团队组成来构建的，因此它不会促进对该单元测试框架的接受和证实。前面讨论过的独立工程师可能会发现忽视团队为所有功能构建单元测试的要求并放弃练习太诱人了。这很可能导致代码质量较差，从而增加主要和次要缺陷。反过来，这可能会导致应用程序停机或导致其他与可用性相关的问题。由此导致的错误和生产问题的增加使工程资源无法用于编码新功能或可扩展性项目，例如数据库分片。正如我们之前所看到的，当资源变得稀缺时，推迟短期客户功能以支持长期可扩展性项目的权衡变得更加困难。 #### Longhorn 长角牛 The Microsoft operating system code named Longhorn that publicly became known as Vistaserves as an example of the failure of standards and quality in an organization. Ultimately,Vista became a successful product launch that achieved the ranking of being the second mostwidely adopted operating system, but not without significant pain for both Microsoft and theircustomers. The time period between the release of the previous desktop operating system XPand Vista marked the longest in the company’s history between product launches. 代号为 Longhorn 的 Microsoft 操作系统被公开称为 Vista，成为组织中标准和质量失败的一个例子。最终，Vista 成为了一次成功的产品发布，成为第二大最广泛采用的操作系统，但微软及其客户都遭受了巨大的痛苦。上一代桌面操作系统 XP 和 Vista 的发布之间的时间间隔是该公司历史上产品发布之间最长的间隔。 In a front-page article on September 23, 2005, in The Wall Street Journal, Jim Allchin,Microsoft’s copresident, admitted to telling Bill Gates that “It’s not going to work,” referring toLonghorn. Jim Allchin continues in the article describing the development as “crashing to theground” due to haphazard methods by which features were introduced and integrated.(Robert A Guth. “Battling Google, Microsoft Changes How It Builds Software.” WallStreet Journal, September 23, 2005, http://online.wsj.com.) 在 2005 年 9 月 23 日《华尔街日报》的头版文章中，微软联席总裁吉姆?#38463;尔钦 (Jim Allchin) 承认曾告诉比尔?#30422;茨“这行不通”，他指的是 Longhorn。 Jim Allchin 在文章中继续将开发描述为“崩溃”，因为引入和集成功能的方法是随意的。（Robert A Guth。“与 Google 作战，微软改变了软件构建方式。”《华尔街日报》，9 月 23 日， 2005 年，http://online.wsj.com。 One of the factors that helped revive the doomed product was enlisting the help of seniorexecutive Amitabh Srivastava who had a team of architects map out the operating system andestablished a development process that enforced high levels of code quality across the organization. Although this caused great criticism from some of the individual developers, it resultedin the recovery of a failed product. 帮助这款注定失败的产品重获新生的因素之一是获得了高级管理人员 Amitabh Srivastava 的帮助，他的架构师团队规划了操作系统，并建立了一个开发流程，在整个组织内强制执行高水平的代码质量。尽管这引起了一些个人开发者的强烈批评，但它却使失败的产品得到了恢复。 The last major factor that the organization can affect that directly impacts theapplication’s or service’s scalability is ownership. If we take the opposite extreme of anorganization from what we were using in our previous examples, and assume an organization where each team has fifty engineers and no separation or hierarchy, we mayvery well see many different engineers working on the same part of the code base. Whenlots of people work on the same code and there is no explicit or implicit hierarchy, noone feels they own the code. When this occurs, no one takes the extra steps to ensureothers are following standards, building the requested functionality, or maintainingthe high quality desired in the product. Thus, we see the aforementioned problemswith scalability of the application that stem from issues such as less efficient use ofthe engineering resources, more production issues, and poor communication. 组织可以直接影响应用程序或服务的可扩展性的最后一个主要因素是所有权。如果我们采取与之前示例中使用的组织相反的极端，并假设每个团队有 50 名工程师并且没有分离或层次结构，我们很可能会看到许多不同的工程师在代码库的同一部分上工作。当很多人使用相同的代码并且没有显式或隐式的层次结构时，没有人觉得自己拥有该代码。当这种情况发生时，没有人采取额外的步骤来确保其他人遵循标准、构建所需的功能或保持产品所需的高质量。因此，我们看到上述应用程序可扩展性方面的问题源于工程资源使用效率较低、生产问题较多和沟通不畅等问题。 Thus, we see that the organization does affect some key factors that impact thescalability of the application. Now that we have a clear basis for caring about theorganization from a scalability perspective, it is time to understand the basic determinants of all organization, size and structure. 因此，我们看到组织确实会影响一些影响应用程序可扩展性的关键因素。现在我们已经有了从可扩展性角度关心组织的明确基础，现在是时候了解所有组织、规模和结构的基本决定因素了。 #### Team Size 团队规模 Before we explore the factors that influence optimal team size, first we should discusswhy team size is important. Consider a team of two people; the two know eachother’s quirks, they always know what each other is working on, and they never forget to communicate with each other. Sounds perfect right? Well, consider that theyalso may not have enough engineering effort to tackle big projects, like scalabilityprojects of splitting databases, in a timely manner; they do not have the flexibility totransfer to another team because each one probably knows stuff that no one elsedoes; and they probably have their own coding standards that are not commonamong other two-person teams. Obviously, both small teams and large teams havetheir pros and cons. They key is to balance each to get the optimal result for yourorganization. 在我们探讨影响最佳团队规模的因素之前，首先我们应该讨论为什么团队规模很重要。考虑一个由两人组成的团队；两人了解彼此的怪癖，总是知道对方在做什么，而且永远不会忘记彼此沟通。听起来很完美吧？好吧，考虑到他们也可能没有足够的工程努力来及时处理大型项目，例如拆分数据库的可扩展性项目；他们没有灵活性可以转移到另一个团队，因为每个人都可能知道其他人不知道的东西；他们可能有自己的编码标准，这在其他两人团队中并不常见。显然，小团队和大团队都有各自的优点和缺点。关键是平衡每一个因素，为您的组织获得最佳结果。 An important point is that we are looking for the optimal team size for your organization. As this implies, there is not a single magic number that is best for all teams.There are many factors that should be considered when determining the optimal size for your teams; and even among teams the sizes may vary. If forced to give a directanswer to how many team members should optimally be on a team, we would provide a range and hope that suffices for a specific enough answer. Although there arealways exceptions even to this broad range of choices, our low boundary for teamsize is six and our upper boundary is 15. What we mean by low boundary is that ifyou have fewer than six engineers, there is probably no point in dividing them intoseparate teams. For the upper boundary, if there are more than 15 people on a singleteam, the size starts to hinder the management’s ability to actively manage and communication between team members starts to falter. Having given this range, there arealways exceptions to these guidelines; more importantly, consider the following factors as aligned with your organization, people, and goals. 重要的一点是，我们正在为您的组织寻找最佳的团队规模。这意味着，没有一个对所有团队都最好的神奇数字。在确定团队的最佳规模时，需要考虑很多因素；即使在团队之间，规模也可能有所不同。如果被迫直接回答一个团队中最佳的团队成员数量，我们会提供一个范围，并希望这足以提供足够具体的答案。尽管对于如此广泛的选择也总是存在例外，但我们的团队规模下限是 6 人，上限是 15 人。下限的意思是，如果您的工程师少于 6 人，那么将他们分成单独的团队可能没有意义团队。对于上限，如果单个团队超过 15 人，规模就开始阻碍管理层积极管理的能力，团队成员之间的沟通开始动摇。给出这个范围后，这些准则总是有例外情况；更重要的是，请考虑以下与您的组织、人员和目标相一致的因素。 The first factor to consider when determining team size is the experience level ofthe managers. The role of the engineering or operations manager can entail differentresponsibilities in different companies. Some companies require managers to meetone-on-one with every team member for at least 30 minutes each week to providefeedback, mentoring, and receive updates; others have no such requirement. Managerial responsibilities will be discussed later in this chapter as a factor by itself, but forour purposes now we will assume that managers have a base level of responsibility,which includes the three following items: ensuring engineers are assigned to projects,either self directed or by edict of management; that administrative tasks, such asresolving pay problems or passing along human resources information take place;and that managers receive status updates on projects in order to pass them along toupper management. Given this base level of responsibility, a junior manager who hasjust stepped from the engineering ranks into management may find that, even with asmall team of six engineers, the administrative and project management tasks consume her entire day. She may have time for little else because these tasks are new toher and they require a significant amount of time and concentration compared withher more senior counterparts who can handle all these tasks for a much larger teamand still have time for special projects on the side. This is perfectly normal for everyone. New tasks typically take longer and require more intense concentration thantasks that have been performed over and over again. The level of experience is a keyfactor to consider when determining the optimal size for a given team. 确定团队规模时首先要考虑的因素是管理者的经验水平。工程或运营经理的角色在不同的公司可能需要承担不同的职责。一些公司要求经理每周与每个团队成员进行至少 30 分钟的一对一会面，以提供反馈、指导和接收最新动态；其他人没有这样的要求。管理责任将在本章后面作为一个因素单独讨论，但出于我们的目的，我们现在假设管理者具有基本的责任级别，其中包括以下三项：确保工程师被分配到项目中，无论是自我指导还是由工程师指导管理法令；执行行政任务，例如解决薪酬问题或传递人力资源信息；经理接收项目状态更新，以便将其传递给高层管理人员。考虑到这一基本责任级别，刚刚从工程岗位进入管理层的初级经理可能会发现，即使有一个由六名工程师组成的小团队，行政和项目管理任务也会占用她一整天的时间。她可能没有时间做其他事情，因为这些任务对她来说是新的，与更高级的同事相比，它们需要大量的时间和注意力，而更高级的同事可以为更大的团队处理所有这些任务，并且仍然有时间处理特殊项目。这对每个人来说都是完全正常的。与一遍又一遍地执行的任务相比，新任务通常需要更长的时间并且需要更集中的注意力。在确定给定团队的最佳规模时，经验水平是需要考虑的关键因素。 In a similar vein, the tenure of the team itself is a factor to consider when contemplating team size. A team that is very senior in tenure both at the company and inengineering will require much less overhead from both management as well as eachother to perform their responsibilities. Both durations are important, time at thecompany and time in engineering, because they both influence different aspects ofoverhead required. The more time at a particular company will generally indicatethat less overhead is required for the administrative and human resource tasks thatinundate new people such as signing up for benefits, getting incorrect paychecksstraightened out, or attending all the mandatory briefings. The more time practicing engineering the less time and overhead that will be required to explain specifications,designs, standards, frameworks, or technical problems. Of course, every individual isdifferent and the seniority of the overall team must be considered. If a team has awell-balanced group of senior, midlevel, and junior engineers, they can probably exist in amoderate-sized team; whereas a team of all senior engineers, say on an infrastructureproject, might be able to exist with twice as many individuals because they shouldrequire much less communication about nondevelopment related items and be muchless distracted by more junior type questions, such as how to check out code from therepository. You should consider all of this when deciding on the optimal team sizebecause doing so will provide a good indicator of how large the team can effectivelybe without causing disruption due to the overhead overwhelming the productivity. 同样，在考虑团队规模时，团队本身的任期也是一个需要考虑的因素。一个在公司和工程领域都担任高级职务的团队将需要更少的管理费用以及彼此履行职责的费用。在公司工作的时间和在工程部门工作的时间这两个持续时间都很重要，因为它们都会影响所需管理费用的不同方面。在特定公司工作的时间越长，通常表明新员工所需的行政和人力资源任务所需的管理费用就越少，例如申请福利、纠正不正确的工资或参加所有强制性简报。实践工程的时间越多，解释规范、设计、标准、框架或技术问题所需的时间和开销就越少。当然，每个人都是不同的，必须考虑整个团队的资历。如果一个团队拥有一支均衡的高级、中级、初级工程师队伍，那么他们很可能存在于一个中等规模的团队中；而一个由所有高级工程师组成的团队，比如在基础设施项目中，可能会有两倍的人员存在，因为他们需要更少的非开发相关项目的沟通，并且不会被更初级的问题分散注意力，例如如何检查代码来自存储库。在决定最佳团队规模时，您应该考虑所有这些因素，因为这样做可以很好地指示团队可以有效达到多大规模，而不会因开销压倒生产力而造成中断。 As we mentioned earlier, each company has different expectations of the tasks thata manager should be responsible for completing. We decided that a base level of managerial responsibilities includes ensuring the following: 正如我们前面提到的，每个公司对经理应负责完成的任务都有不同的期望。我们决定基本的管理职责包括确保以下内容 * Engineers are assigned to projects * Administrative tasks take place * Status updates are passed along * 工程师被分配到项目 * 执行行政任务 * 状态更新被传递 Obviously, there are many more managerial responsibilities that could be asked ofthe managers, including one-on-one weekly meetings with engineers, coding of features by managers themselves, reviewing specifications, project management, reviewing designs, coordinating or conducting code reviews, establishment and ensuringadherence of standards, mentoring, praising, and performance reviews. The more ofthese tasks that are placed upon the individual managers the smaller the team that isrequired in order to ensure the managers can accomplish all the assigned tasks. Forexample, if one-on-ones are required, and we feel they should be, an hour-long meeting with each engineer weekly for a team of ten engineers will consume 25% of a 40-hour week. The numbers can be tweaked—shorter meetings, longer work weeks—but the point remains that just speaking to each engineer on a large team can consume a very large portion of a manager’s time. Speaking frequently with team members is critical to be an effective manager and leader. So obviously, the number andeffort of these tasks should be considered as a major contributing factor to the sizethat the optimal teams should be in your organization. An interesting and perhapsenlightening exercise for upper management is to survey your front-line managersand ask how much time they spend on each task for a week. As we indicated with theone-on-one meetings, it is surprisingly deceptive how easy it is to fill up a manager’sweek with tasks. 显然，经理还需要承担更多的管理职责，包括每周与工程师进行一对一的会议、经理自己对功能进行编码、审查规范、项目管理、审查设计、协调或进行代码审查、建立和实施代码审查。确保遵守标准、指导、表扬和绩效评估。分配给各个经理的任务越多，为确保经理能够完成所有分配的任务所需的团队就越小。例如，如果需要一对一的会议（我们认为应该这样做），那么对于由 10 名工程师组成的团队，每周与每位工程师进行一次长达一小时的会议将占用每周 40 小时的 25%。这些数字可以调整——缩短会议时间，延长工作周——但要点仍然是，仅仅与大型团队中的每个工程师交谈就可能会占用经理的很大一部分时间。经常与团队成员交谈对于成为一名有效的管理者和领导者至关重要。显然，这些任务的数量和工作量应被视为影响组织中最佳团队规模的主要因素。对于高层管理人员来说，一个有趣且可能具有启发性的练习是调查一线经理，并询问他们每周在每项任务上花费多少时间。正如我们在一对一会议中所指出的那样，经理的一周充满任务是多么容易，这是令人惊讶的欺骗性。 The previous three factors, experience of management, tenure of team members,and managerial responsibilities, are all constraints in that they limit the size of theteam based on necessity of maintaining a low enough overhead of communication and disruptions to ensure projects actually get accomplished. The next and last factorthat we will discuss is one that pushes to expand the team size. This factor is theneeds or requirements of the business. The business owners and product managers, ingeneral, want to build more and larger customer facing projects in order that theycontinue to fend off competitors, grow the revenue stream, and increase the customerbase. The two main problems with keeping team sizes small is first that large projectsrequire, depending on the product development life cycle methodology that isemployed, many more iterations or more time in development. The net result is the same,projects take longer to get delivered to the customer. The second problem is thatincreasing the number of engineers on staff requires increasing the number of supportpersonnel, including managers. Engineering managers may take offense at being calledsupport personnel but in reality that is what management should be, something thatsupports the teams in accomplishing their projects. The larger the teams the fewermanagers are required. Obviously for those familiar with the concepts outlined in theMythical Man Month: Essays on Software Engineering by Frederick P. Brooks, Jr.,there is a limit to the amount a project can be subdivided in order to expedite thedelivery. Even with this consideration, it is still valid that the larger the team size thefaster projects can be delivered and the larger projects can be undertaken. 前面的三个因素，管理经验、团队成员的任期和管理职责，都是限制因素，因为它们限制了团队的规模，因为需要保持足够低的沟通和干扰开销，以确保项目实际完成。我们要讨论的下一个也是最后一个因素是推动扩大团队规模的因素。这个因素是业务的需要或要求。一般来说，企业主和产品经理希望构建更多、更大的面向客户的项目，以便继续抵御竞争对手、增加收入流并扩大客户群。保持较小团队规模的两个主要问题是，大型项目需要更多的迭代或更多的开发时间，具体取决于所采用的产品开发生命周期方法。最终结果是一样的，项目需要更长的时间才能交付给客户。第二个问题是，增加员工中工程师的数量需要增加包括管理人员在内的支持人员的数量。工程经理可能会因为被称为支持人员而感到生气，但实际上这才是管理应该做的，支持团队完成项目。团队越大，需要的经理就越少。显然，对于那些熟悉 Frederick P. Brooks, Jr. 所著的《人月神话：软件工程论文》中概述的概念的人来说，为了加快交付而可以细分的项目数量是有限的。即使考虑到这一点，团队规模越大，项目交付速度越快，并且可以承担的项目也越大，这仍然是有效的。 The preceding discussion focused on what you should consider when planningteam structures, budgets, hiring plans, and product roadmaps. The four factors ofmanagement experience, team member tenure in the company and in the engineeringfield, managerial duties, and the needs of the business must all be taken into consideration. Returning to our example at the concocted company of AllScale, Johnny Fixer,the new CTO, had just finished briefing his 30-60-90 day plans. Among these was toanalyze his organizational structure and the management team. During one of his initial meetings, Mike Softe, the VP of engineering and a direct report of Johnny’s,asked for some help determining the appropriate team size for several of his teams.Johnny took the opportunity to help teach some of his concepts on team size andwent to the whiteboard drawing a matrix with four factors across the top (managerexperience, team member tenure, managerial duties, and business needs). He askedMike to fill in the matrix with information about the three teams that he was concerned about. In Table 3.1, there are the three different teams that Mike is evaluating. 前面的讨论重点是规划团队结构、预算、招聘计划和产品路线图时应考虑的事项。管理经验、团队成员在公司和工程领域的任期、管理职责和业务需求这四个因素都必须考虑在内。回到我们在 AllScale 炮制公司的例子，新任首席技术官 Johnny Fixer 刚刚介绍完他的 30-60-90 天计划。其中就是分析他的组织结构和管理团队。在他的一次初次会议上，约翰尼的直接下属、工程副总裁迈克?#32034;夫特 (Mike Softe) 请求帮助确定他的几个团队的适当团队规模。约翰尼借此机会帮助教授一些有关团队规模的概念。然后走到白板上绘制一个矩阵，顶部有四个因素（经理经验、团队成员任期、管理职责和业务需求）。他要求迈克在矩阵中填写他所关心的三支球队的信息。在表 3.1 中，迈克正在评估三个不同的团队。 For all the teams, Mike considered the managerial responsibilities to be mediumand consistent across all managers. This may or may not be the case in your organization. Often, a particularly senior manager may have special projects he is responsible for, such as chairing standards meetings, and junior managers are often requiredto continue coding while they make the transition to management and hire their ownbackfill. Mike Softe’s Team 1 has a very experienced manager and a long tenuredteam; and the business needs are high, implying either large projects are on the roadmap or they need them as soon as possible, possibly both. In this case, Johnnyexplains to Mike that Team 1 should be considered for a large team size, perhaps 12to 15 engineers. Team 2 has a very inexperienced manager and team members. Thebusiness requirements on Team 2 are moderate and therefore Johnny explains thatthe team size should be kept relatively small, 6 to 8 members. Team 3 has a veryexperienced manager with a new team. The business does not require large or frequently delivered projects from this team at this time. Johnny explains that Mikeshould consider letting the team members on this team gain more experience at thecompany or in the practice of engineering and assist by keeping the team relativelysmall even though the manager could handle more reports. In this case, Johnny stateswith a smile, the manager might be a great candidate to take on an outside projectthat would benefit the overall organization. 对于所有团队，迈克认为所有经理的管理职责都是中等且一致的。您的组织可能会出现这种情况，也可能不会。通常，特别高级的经理可能会负责特殊项目，例如主持标准会议，而初级经理通常需要在过渡到管理层并雇用自己的后备人员时继续编码。 Mike Softe 的 Team 1 拥有一位经验丰富的经理和一支长期任职的团队；而且业务需求很高，这意味着大型项目要么已在路线图上，要么需要尽快完成，也可能两者兼而有之。在本例中，Johnny 向 Mike 解释说，Team 1 应考虑大型团队规模，也许有 12 到 15 名工程师。第二队的经理和团队成员都非常缺乏经验。团队 2 的业务要求适中，因此 Johnny 解释说团队规模应保持相对较小，即 6 到 8 名成员。 Team 3 有一位经验丰富的经理和一支新团队。目前，该团队不需要大型或频繁交付的项目。约翰尼解释说，迈克应该考虑让这个团队的成员在公司或工程实践中获得更多经验，并通过保持团队相对较小的规模来提供帮助，尽管经理可以处理更多的报告。在这种情况下，约翰尼微笑着说，经理可能是承担一个对整个组织有利的外部项目的绝佳候选人。 ##### Warning Signs 警告标志 Now that we have discussed the factors that must be considered when determining orevaluating each team’s size, we should focus on signs that the team size is incorrect.In the event that you do not have an annual or semiannual process for evaluatingteam sizes, some indicators of how to tell if a team is too big or too small could behelpful. If a team is too large, the indicators that you should look for are poor communication, lowered productivity, and poor morale. Poor communication could takemany forms including engineers missing meetings, unresponsiveness to emails, missedspecification changes, or multiple people asking the same questions. 既然我们已经讨论了确定或评估每个团队规模时必须考虑的因素，我们应该重点关注团队规模不正确的迹象。如果您没有每年或半年度的流程来评估团队规模，则一些指标如何判断团队是否太大或太小可能会有所帮助。如果团队太大，您应该寻找的指标是沟通不畅、生产力下降和士气低落。沟通不畅可能有多种形式，包括工程师缺席会议、对电子邮件没有回应、错过规格变更或多人提出相同的问题。 Lowered productivity can be another sign of the team size being too large. Thereason for this is that if the manager, architects, and senior engineers do not haveenough time to spend with the junior engineers, these newest team members are notgoing to produce as many features as quickly. Without someone to mentor, guide,direct, and answer questions, the junior engineers will have to flounder longer thanthey normally would. The opposite is possibly the culprit as well. Senior engineersmight be too busy answering questions for too many junior engineers to get theirown work done, thus lowering their productivity. Some signs of lowered productivityinclude missing release dates, lower function or story points (if measured), and pushback on feature assignment. Function points and story points are two different methods that attempt to standardize the measurement of a piece of functionality. Function points are from the user’s perspective and story points are from the engineer’s perspective. Engineers by nature are typically over-optimistic in terms of what they thinkthey can accomplish; if they are pushing back on an amount of work that they havedone in the past, this might be a clear indicator that they feel at some level their productivity slipping. 生产力下降可能是团队规模过大的另一个迹象。原因是，如果经理、架构师和高级工程师没有足够的时间与初级工程师相处，这些新的团队成员就不会那么快地生产出那么多的功能。如果没有人来指导、指导、指导和回答问题，初级工程师将不得不比平常更长时间地陷入困境。相反的人也可能是罪魁祸首。高级工程师可能忙于回答太多初级工程师的问题而无法完成自己的工作，从而降低了他们的生产力。生产力下降的一些迹象包括错过发布日期、较低的功能或故事点（如果测量）以及功能分配的推迟。功能点和故事点是两种不同的方法，试图标准化一项功能的测量。功能点是从用户的角度来看的，故事点是从工程师的角度来看的。工程师本质上通常对他们认为自己能够完成的任务过于乐观。如果他们推迟了过去完成的大量工作，这可能是一个明确的指标，表明他们在某种程度上感到生产力下降。 Both of the preceding problems, poor communication and lowered productivitydue to lack of support, can lead to the third sign of a team being too large: poormorale. When a normally healthy and satisfied team starts demonstrating poormorale, this is a clear indicator that something is wrong. Although there may bemany causes for poor morale, the size of the team should not be overlooked. Similarto how you approach debugging, look for what changed last. Did the size of the teamgrow recently? Poor morale can be demonstrated in a variety of manners such asshowing up late for work, spending more time in the game room, arguing more inmeetings, and pushing back more than usual on executive level decisions. The reasonfor this is straightforward, as an engineer when you feel unsupported, not communicated with, or that you are not able to succeed in your tasks, it weighs heavily onyou. Most engineers love a challenge, even very tough ones that will take days just tounderstand the nature of the problem. At the point that an engineer knows he cannotsolve the problem, suddenly he falls into despair. This is especially true of junior engineers, so watch for these behaviors to occur first in the more junior team members. 上述两个问题，即沟通不畅和由于缺乏支持而导致的生产力下降，都可能导致团队规模过大的第三个迹象：士气低落。当一个通常健康且满意的团队开始表现出士气低落时，这是一个明显的迹象，表明出现了问题。尽管士气低落的原因可能有很多，但团队的规模也不容忽视。与调试方式类似，查找最后更改的内容。最近团队规模有扩大吗？士气低落可以通过多种方式表现出来，例如上班迟到、花更多时间在游戏室、在会议上争论更多，以及比平时更多地推迟执行层的决策。原因很简单，作为一名工程师，当你感到不受支持、无法沟通，或者无法成功完成任务时，你的压力就会很大。大多数工程师都喜欢挑战，即使是非常艰难的挑战，需要几天的时间才能理解问题的本质。当工程师知道自己无法解决问题时，他突然陷入了绝望。对于初级工程师来说尤其如此，因此请注意这些行为首先发生在初级团队成员中。 Now that we have covered some of the signs to look for when a team becomes toolarge, we can shift our focus to the opposite extreme and look for signs when a teamis too small. If the team is too small, the indicators to look for are disgruntled business partners, micromanaging managers, and overworked team members. If the teamis too small, one of the first signs might be the business partners such as productmanagers or business development spending more time around the manager complaining that they need more products delivered. A team that is too small is justunable to quickly deliver sizable features. Another tactic that disgruntled businessleaders can take is instead of complaining directly to the engineer or technology leadership, they focus their energy in a more positive manner by supporting budgetrequests for more engineers to be hired. 既然我们已经介绍了团队规模过大时要寻找的一些迹象，那么我们可以将注意力转移到另一个极端，寻找团队过小时的迹象。如果团队太小，需要寻找的指标是心怀不满的业务合作伙伴、微观管理经理和过度劳累的团队成员。如果团队太小，第一个迹象可能是业务合作伙伴（例如产品经理或业务开发人员）花费更多时间在经理周围，抱怨他们需要交付更多产品。太小的团队无法快速交付相当大的功能。心怀不满的企业领导者可以采取的另一种策略是，他们不直接向工程师或技术领导层抱怨，而是通过支持雇用更多工程师的预算请求，以更积极的方式集中精力。 When a normally effective manager begins to micromanage team members, this isa sign to look into the root cause of this behavior. There might be lots of explanations, including the possibility that her team size is too small and she’s keeping busyby hovering over her team members, second guessing their decisions, and asking forstatus updates about the request for a status update. If this is the case, it is the perfectopportunity to assign this manager some other tasks that will serve the organization,help professionally develop her by expanding her focus, and give her team some relieffrom her constant presence. Some ideas on special projects include chairing a standards committee, leading an investigation of a new software tool for bug tracking, orestablishing a cross team mentoring program for engineers. 当一位通常有效的管理者开始对团队成员进行微观管理时，这是一个迹象，需要调查这种行为的根本原因。可能有很多解释，包括她的团队规模太小，并且她一直忙于将鼠标悬停在团队成员上方，再次猜测他们的决定，并询问有关状态更新请求的状态更新。如果是这种情况，那么这是一个绝佳的机会，可以为这位经理分配一些其他任务，这些任务将为组织服务，通过扩大她的关注点来帮助她专业发展，并让她的团队从她的持续存在中得到一些缓解。关于特殊项目的一些想法包括主持标准委员会、领导对用于错误跟踪的新软件工具的调查，或为工程师建立跨团队指导计划。 The third sign to look for when a team is too small is overworked team members.Most teams are extremely motivated by the products they are working on and believein the mission of the company. They want to succeed and they want to do everythingthey can to help. This includes accepting too much work and trying to accomplish itin the expected timeframe. When the team members start to leave later and later orstart to consistently work weekends, these are signs that you might want to investigate if you have enough engineers working on this particular team. This type of overworking behavior is expected and even necessary for most startup companies butworking in this manner consistently month after month will eventually burn out theteam causing attrition, poor morale, and poor quality. It is much better to take noticeof the hours and days spent working on tasks and determine a corrective action earlyas opposed to waking up to the problem when your most senior engineer walks inyour office to resign. 当团队太小时要寻找的第三个迹象是团队成员过度劳累。大多数团队对他们正在开发的产品非常有动力，并且相信公司的使命。他们想要成功，并且想要尽一切努力提供帮助。这包括接受过多的工作并试图在预期的时间内完成它。当团队成员开始越来越晚离开或开始持续在周末工作时，这些迹象表明您可能需要调查是否有足够的工程师在这个特定团队中工作。对于大多数初创公司来说，这种过度工作行为是预料之中的，甚至是必要的，但月复一月持续以这种方式工作最终会耗尽团队，导致人员流失、士气低落和质量低下。最好注意在任务上花费的时间和天数，并尽早确定纠正措施，而不是在最高级的工程师走进办公室辞职时才意识到问题所在。 These are signs that we have seen in our teams when they were either too large ortoo small. Some of these symptoms of course can be caused by other things besidesteam size but it is often the case that managers jump to conclusions with the mostcursory of investigations into the real cause and often do not even consider the organizational structure as a possible cause. Often, the most frequently blamed is theteam leader and his inability to manage his team effectively or manage the customer’sexpectations effectively. Before you place the blame on his shoulders, be sure that theorganization that you have placed them in supports them as much as possible byassisting in his success. Running a great junior leader out of management becauseyou placed him in a team that was too large for his current skill level would be dreadful. Invest in the future of your leadership team by building the proper supportingstructure around each manager, allowing his own skills and experience to develop. 这些是我们在团队规模太大或太小时时看到的迹象。当然，其中一些症状可能是由团队规模之外的其他因素引起的，但通常情况下，管理者对真正原因进行了最粗略的调查后就草率下结论，甚至常常不考虑组织结构作为可能的原因。通常，最常受到指责的是团队领导者以及他无法有效管理团队或有效管理客户期望的能力。在你把责任归咎于他之前，请确保你安排他们的组织通过帮助他取得成功来尽可能地支持他们。因为你将一位优秀的初级领导者置于一个对于他目前的技能水平来说太大的团队中，而将他排除在管理层之外，这是可怕的。通过围绕每位经理建立适当的支持结构，让他自己的技能和经验得以发展，从而投资于领导团队的未来。 ##### Growing or Splitting Teams 扩大或分裂团队 For the teams that are too small, adding engineers, although not necessarily easy, isstraightforward. The steps include requesting and receiving budgetary approval forhiring, writing up the job description, reviewing resumes, conducting interviews,making offers, and on boarding the new hires. Although these simple steps may takemonths to actually accomplish, they are generally easy to understand and fairly simple to implement. The much more difficult task is to split a team when it has becometoo large. Splitting a team incorrectly can have dire consequences caused by confusion of code ownership, even worse communication, and stress of working for a newmanager. Every team and organization is different, so there is no perfect, standard,one-size-fits-all way of splitting teams. There are some factors to consider whenundergoing this organizational surgery in order to minimize the impact and quicklyget back to a productive and engaged existence among the team members. 对于太小的团队来说，添加工程师虽然不一定容易，但很简单。这些步骤包括请求并获得招聘预算批准、撰写职位描述、审查简历、进行面试、提出录用通知以及新员工入职。尽管这些简单的步骤可能需要几个月的时间才能真正完成，但它们通常很容易理解并且实施起来相当简单。更困难的任务是当团队规模太大时将其拆分。错误地拆分团队可能会因代码所有权的混乱、更糟糕的沟通以及为新经理工作的压力而带来可怕的后果。每个团队和组织都是不同的，因此不存在完美的、标准的、一刀切的团队拆分方式。在进行组织手术时需要考虑一些因素，以便最大限度地减少影响并快速恢复团队成员的高效和投入状态。 Some of the things that you should think about when considering splitting a teaminclude how to split the code base, who is going to be the new manager, what involvement will individual team members have, and how does this change the relationship with the business partners. The first item to concentrate on is based on thecode or the work. As we will discuss in much more detail in Part III, ArchitectingScalable Solutions, this might be a great opportunity to split the team as well as thecode base into what we term failure domains. These are domains that limit theimpact of failures by isolating services from one another. 在考虑拆分团队时，您应该考虑的一些事情包括如何拆分代码库、谁将成为新的经理、各个团队成员将参与哪些工作，以及这将如何改变与业务合作伙伴的关系。第一个要关注的项目是基于代码或工作。正如我们将在第三部分“构建可扩展解决方案”中更详细地讨论的那样，这可能是将团队和代码库划分为我们所说的故障域的绝佳机会。这些域通过将服务彼此隔离来限制故障的影响。 The code used to be owned and assigned to a single team needs to be split betweentwo or more teams. In the case of an engineering team, this usually revolves aroundthe code. The old team perhaps owned all the services around the administrative partof the application, such as account creation, login, billing, and reporting. Again,there is no standard way of doing this, but a possible solution is to subdivide the services into two or more groups: one handling account creation and login, the otherhandling billing and reporting services. As you get deeper into the code, you willlikely hit base classes that require assignment to one team or the other. In these cases,we like to assign general ownership to one team or even better to one engineer andset up alerts through the source code repository that can alert each other if anythingis changed in that particular file or class, therefore everyone can be aware of changesin their sections of the code. 过去拥有并分配给单个团队的代码需要在两个或多个团队之间分配。对于工程团队来说，这通常围绕着代码。旧团队可能拥有应用程序管理部分的所有服务，例如帐户创建、登录、计费和报告。同样，没有标准的方法可以做到这一点，但一种可能的解决方案是将服务细分为两个或多个组：一组处理帐户创建和登录，另一组处理计费和报告服务。随着您深入代码，您可能会遇到需要分配给一个团队或另一个团队的基类。在这些情况下，我们希望将一般所有权分配给一个团队，甚至更好地分配给一名工程师，并通过源代码存储库设置警报，如果该特定文件或类中发生任何更改，可以互相提醒，因此每个人都可以知道自己的更改代码的各个部分。 The next item to consider is who will be the new manager. This is an opportunityto hire someone new from the outside or promote someone internally into the position. There are pros and cons of each option. An external hire brings new ideas andexperiences; whereas an internal hire provides a manager who is familiar with all theteam members as well as the processes. Because of the various pros and cons of eachoption, this is a decision you do not want to make lightly and may want to ponderfor a long time. Making a well thought out decision is absolutely the correct thing todo, but taking too much time can cause just as many problems. The stress of theunknown can be dampening to spirits and cause unrest. Make a timely decision; ifthat involves bringing in external candidates, do so as openly and quickly as possible.Dragging out the selection process and wavering between an internal and externalcandidate does nothing but cause trouble for the team. 下一个要考虑的问题是谁将成为新任经理。这是一个从外部聘用新人或从内部提拔某人担任该职位的机会。每个选项都有优点和缺点。外部聘用会带来新的想法和经验；而内部招聘则提供了一位熟悉所有团队成员以及流程的经理。由于每种选择都有不同的优点和缺点，这是一个你不想轻易做出的决定，可能需要考虑很长时间。做出深思熟虑的决定绝对是正确的事情，但花费太多时间也会导致同样多的问题。未知的压力可能会抑制精神并引起不安。及时做出决定；如果这涉及引入外部候选人，请尽可能公开、快速地进行。拖延选拔过程并在内部和外部候选人之间摇摆不定只会给团队带来麻烦。 The last of the big three items to consider when splitting a team is how the relationship with the business will be affected. If there is a one-to-one relationshipbetween engineering team, quality assurance, product management team, and business team, this is something that will obviously change by splitting a team. A discussion with all the affected leaders should take place before a decision is reached onsplitting the team. Perhaps all the counterpart teams will split simultaneously or individuals will be reassigned to interact more directly along team lines. There are manypossibilities with the most important thing being an open discussion taking placebeyond the engineering and beyond the technology teams. 拆分团队时要考虑的三个重要事项中的最后一个是与业务的关系将如何受到影响。如果工程团队、质量保证、产品管理团队和业务团队之间存在一对一的关系，那么通过拆分团队，这显然会改变。在做出拆分团队的决定之前，应与所有受影响的领导者进行讨论。也许所有对应团队将同时分裂，或者人员将被重新分配，以便沿着团队路线更直接地互动。有很多可能性，最重要的是在工程和技术团队之外进行公开讨论。 We have covered the warning signs associated with teams that are too large andtoo small. We also covered the factors to consider when splitting teams. One of the major lessons that should be gleaned from this section is that the team size andchanges to it can have tremendous impacts on everything from morale to productivity. Therefore, it is critical to keep in mind the team size as a major determining factor of how effective the organization is in relation to scalability of the application. 我们已经介绍了与太大和太小的团队相关的警告信号。我们还介绍了拆分团队时要考虑的因素。从本节中应该吸取的主要教训之一是团队规模及其变化会对从士气到生产力的各个方面产生巨大影响。因此，牢记团队规模是组织在应用程序可扩展性方面的有效性的主要决定因素，这一点至关重要。 Optimal team size checklist: 最佳团队规模清单 1. Determine the experience level of your managers 2. Calculate each engineer’s tenure at the company 3. Look up or ask each engineer how long he or she has been in the industry 4. Estimate the total effort for managerial responsibilities a. Survey your managers for how much time they spend on tasks b. Make a list of the core managerial responsibilities that you expect managers toaccomplish 5. Look for signs of disgruntled business partners and managers who are bored to indicateteams that are too small 6. Look for losses in productivity, poor communication, and degrading morale to indicateteams that are too large 1. 确定经理的经验水平2。计算每个工程师在公司的任期3。查找或询问每位工程师他或她在该行业工作了多久4。估计管理职责的总工作量a。调查你的经理在任务上花费了多少时间b。列出您期望管理者完成的核心管理职责5。寻找不满的业务合作伙伴和经理的迹象，他们无聊地指出团队太小6。寻找生产力下降、沟通不畅和士气低落的情况，以表明团队规模太大 Splitting a team checklist: 拆分团队清单 1. Determine how to separate the code basea. Split by servicesb. Divide base classes and services as evenly as possible with only one ownerc. Set up alerts in your repository to ensure everyone knows when items are beingmodified 2. Determine who will be the new managera. Consider internal versus external candidatesb. Set an aggressive timeline for making the decision and stick to it 3. Analyze your team’s interactions with other teams or departmentsa. Discuss the planned split with other department headsb. Coordinate your team’s split with other teams to ensure a smoother transitionc. Use joint announcements for all departments to help explain all the changessimultaneously 1. 确定如何分离代码库。按服务划分b.尽可能均匀地划分基类和服务，并且只有一个所有者。在存储库中设置警报，以确保每个人都知道项目何时被修改2。确定谁将成为新任经理。考虑内部候选人与外部候选人b。为做出决定设定一个积极的时间表并坚持下去3。分析您的团队与其他团队或部门的互动a。与其他部门负责人讨论计划的拆分b。协调您的团队与其他团队的分配，以确保更顺利的过渡。使用所有部门的联合公告来帮助同时解释所有变化 #### Organizational Structure 组织架构 The organizational structure refers to the actual layout or how teams relate to eachother within an organization. This includes the separation of employees into departments, divisions, and teams as well as the management hierarchy that is used forcommand and control of the forces. There are as many different structures as thereare companies, but there are two basic structures from which everything else stems.These structures are functional and matrix. By understanding the pros and cons ofeach structure, you will be able to choose one or the other; or, perhaps a more likelyscenario, create a hybrid of the two structures that best meets the needs of your company. In the ensuing paragraphs, we will cover the basic definition of each structure,the benefits and drawbacks of each, and some ideas on when to use each one. Recognize that the most important lesson is how to choose parts of one versus the other tocreate the organizational structure that is best for your scenario. 组织结构是指组织内的实际布局或团队之间的相互关系。这包括将员工分为部门、部门和团队，以及用于指挥和控制部队的管理层级。有多少家公司就有多少种不同的结构，但有两种基本结构是其他一切的根源。这些结构是功能性结构和矩阵式结构。通过了解每种结构的优缺点，您将能够选择其中一种；或者，也许更可能的情况是，创建最能满足公司需求的两种结构的混合体。在接下来的段落中，我们将介绍每种结构的基本定义、每种结构的优点和缺点，以及何时使用每种结构的一些想法。认识到最重要的教训是如何选择其中一个部分与另一个部分，以创建最适合您的场景的组织结构。 ##### Functional Organization 职能组织 The functional organizational structure is the original structure upon which armies andindustries were based. This structure, as seen in Figure 3. 1, separates departments and divisions by their primary purpose or function. This was often called a siloapproach because each group of people was separated from other groups just asgrain or corn would be separated into silos based upon the type or grade of produce.In a technology organization, this structure would result in the creation of separatedepartments to house engineering, quality assurance, operations, project management, and so forth. Along with this, there would exist the management hierarchywithin each department. Each would have a department head, such as the VP of engineering, and a structure into each department that was homogeneous in terms ofresponsibilities. Reporting into the VP of engineering would be other engineeringmanagers such as engineering directors and reporting into them would be engineeringsenior managers and then engineering managers. This hierarchy was consistent inthat engineering managers reported to other engineering managers and quality assurance managers reported to other quality assurance managers.  职能组织结构是军队和工业所依据的原始结构。如图 3. 1 所示，这种结构根据部门和部门的主要目的或职能将其分开。这通常被称为筒仓方法，因为每一组人都与其他组分开，就像谷物或玉米会根据产品的类型或等级分成筒仓一样。在技术组织中，这种结构将导致创建独立的部门来容纳工程、质量保证、运营、项目管理等。除此之外，每个部门内都会存在管理层级。每个部门都有一个部门负责人，例如工程副总裁，并且每个部门的结构在职责方面是同质的。向工程副总裁汇报的将是其他工程经理，例如工程总监，向他们汇报的将是工程高级经理，然后是工程经理。这种层次结构是一致的，因为工程经理向其他工程经理报告，质量保证经理向其他质量保证经理报告。 The benefits of the functional or silo organizational structure are numerous. Managers almost always were raised through the ranks; thus, even if they were not goodindividual performers, they at least knew what was entailed in performing the job.Unless there had been major changes in the field over the years, there was very littleneed to spend time explaining to bosses the more arcane or technical aspects of thejob because they were well versed in it. Team members were also consistent in theirexpertise, engineers worked alongside engineers. Questions related to the technicalaspects of the job could be answered quickly by peers usually located in the nextcube. This entire structure is built along specificity. To use an exercise analogy, thisorganizational structure is like a golfer practicing on the driving range. The golferwants to get better and perform well at golf and therefore surrounds himself withother golfers, perhaps even a golf instructor, and practices the game of golf, all veryspecific to his goal. Keep this analog in mind because we will use it to compare andcontrast the functional organizational structure with the matrix structure. 职能型或筒仓型组织结构的好处很多。经理几乎都是通过级别晋升的。因此，即使他们不是优秀的个人执行者，他们至少知道执行工作需要做什么。除非这些年来该领域发生了重大变化，否则很少需要花时间向老板解释更神秘或技术性的内容因为他们精通这项工作的各个方面。团队成员的专业知识也一致，工程师与工程师一起工作。与工作技术方面相关的问题可以由通常位于下一个立方体的同事快速回答。整个结构是根据特殊性构建的。打个比方，这个组织结构就像高尔夫球手在练习场练习一样。高尔夫球手想要在高尔夫球上变得更好并表现良好，因此他周围都是其他高尔夫球手，甚至可能是高尔夫球教练，并练习高尔夫球比赛，所有这些都非常针对他的目标。请记住这个类比，因为我们将用它来比较和对比职能组织结构与矩阵结构。 Other benefits of the functional organizational structure, besides the homogeneityand commonality of management and peers, include simplicity of responsibilities,ease of task assignment, and the greater adherence to standards. Because the organizational structure is extremely clear, almost anyone, even the newest members, canquickly grasp who is in charge of what team or phase of a project. This simplicityalso allows for very easy assignment of tasks. In a waterfall software developmentmethodology, the development phase is clearly the responsibility of the engineeringteam in a functional organization. Because all software engineers report up to a singlehead of engineering and all quality assurance engineers report up to a single qualityassurance head, standards can be established, decreed, agreed upon, and enforcedfairly easily. All of these are very popular reasons that the functional organization hasfor so long been a standard in both the military and industries. 除了管理层和同事的同质性和共性之外，职能型组织结构的其他好处还包括职责简单、任务分配容易以及更严格地遵守标准。由于组织结构极其清晰，几乎任何人，甚至是最新的成员，都可以很快掌握谁负责项目的哪个团队或哪个阶段。这种简单性还可以非常轻松地分配任务。在瀑布式软件开发方法中，开发阶段显然是职能组织中工程团队的责任。因为所有软件工程师都向单一的工程负责人报告，所有的质量保证工程师都向单一的质量保证负责人报告，所以可以相当容易地建立、颁布、商定和执行标准。所有这些都是职能组织长期以来一直成为军事和工业标准的非常普遍的原因。 The problems with a functional or silo organization include no single projectowner and poor cross-functional communication. Projects almost never reside strictly in the purview of a single functional team. Most projects always require tasks to beaccomplished by multiple teams. Take a simple feature request that must have a specification drafted by the product owner, a design and coding performed by the engineers, testing performed by the quality assurance team, and deployment by theoperations engineers. Responsibility for all aspects of the project does not reside withany one person in the management hierarchy until you reach the head of technology,which has responsibility over the product managers, engineering, quality assurance,and operations staffs. Obviously, this is a significant drawback having the CTO orVP of technology the lowest person responsible for the overall success of the project.When problems arise in the projects, it is not uncommon for each functional ownerto place blame for delays or overspends on other departments. 职能型或筒仓型组织的问题包括没有单一的项目所有者和跨职能沟通不畅。项目几乎从来不严格属于单个职能团队的职权范围。大多数项目总是需要多个团队来完成任务。以一个简单的功能请求为例，该请求必须由产品负责人起草规范、由工程师执行设计和编码、由质量保证团队执行测试以及由运营工程师进行部署。项目各个方面的责任并不属于管理层级中的任何一个人，直到技术主管为止，技术主管对产品经理、工程、质量保证和运营人员负责。显然，CTO 或技术副总裁是对项目整体成功负责的最低人员，这是一个重大缺陷。当项目出现问题时，每个职能负责人将延误或超支归咎于其他部门的情况并不少见。 As simple as the functional organization is to understand, the communication canbe surprisingly difficult when attempting it across departments. As an example, asoftware engineer who wants to communicate to a quality assurance engineer about aspecific test that must be performed to check for the proper functionality may spendthe time tracking up and down the quality assurance management hierarchy lookingfor the manager who is assigning the testing of this feature and request that she makeknown who the work will be assigned in order that the information be passed along.More likely, the engineer will rely on established processes, which attempt to facilitate the passing along of such information through design and specification documents. As you can imagine, writing a line in a 20-page specification about testing isexceedingly difficult communication as compared to a one-on-one conversationbetween the development engineer and the testing engineer. 尽管职能组织很容易理解，但跨部门尝试沟通时可能会出奇地困难。例如，想要与质量保证工程师就必须执行的特定测试进行沟通以检查功能是否正确的软件工程师可能会花时间在质量保证管理层次结构中上下跟踪，寻找分配该测试的经理。功能并要求她告知将分配工作的人员，以便传递信息。更有可能的是，工程师将依赖已建立的流程，该流程试图通过设计和规范文档促进此类信息的传递。正如您可以想象的那样，与开发工程师和测试工程师之间的一对一对话相比，在 20 页的规范中写一行关于测试的沟通是极其困难的。 The benefits of the functional organization as just discussed include commonalityof managers and peers, simplicity of responsibility, and adherence to standards. Thedrawbacks include no single project owner and poor communications. Given thesepros and cons, the scenarios in which you would want to consider a functional organizational structure are ones in which the advantages of specificity outweigh theproblems of overall coordination and ownership. An example of such a scenariowould be a scalability project that involves sharding a database. This is a highly technical project that requires some coordination among peer departments, but the overwhelming majority of effort and tasks will be within the engineering discipline.Decisions about how to split the database, how the application will handle thelookup, and all other similar decisions will fall to the engineering team. The productmanagement team may be requested to provide information about specific customerbehavior or the cost to the business for changes to functionality, but it will not be asinvolved as it would be for a new product line launch. 刚才讨论的职能型组织的好处包括管理者和同事的共性、责任的简单性以及对标准的遵守。缺点包括没有单一的项目所有者和沟通不畅。考虑到这些优点和缺点，您需要考虑职能型组织结构的场景是，特殊性的优势超过了整体协调和所有权的问题。这种场景的一个例子是涉及数据库分片的可扩展性项目。这是一个技术性很强的项目，需要同行部门之间进行一些协调，但绝大多数工作和任务将在工程学科内进行。有关如何拆分数据库、应用程序如何处理查找以及所有其他类似决策的决策将在属于工程团队。产品管理团队可能会被要求提供有关特定客户行为或功能更改的业务成本的信息，但不会像新产品线发布那样参与其中。 #### Matrix Organization 矩阵式组织 In the 1970s, organizational behaviorists and managers began rethinking the organizational structure. As we discussed, although there are certain undeniable benefits to the functional organization, there are also certain drawbacks. Companies and evenmilitaries began experimenting with different organizational structures. The secondprimary organizational structure that evolved from this was the matrix structure. Theprinciple concept in a matrix organization is that there are two dimensions to thehierarchy. As opposed to a functional organization where each team has a singlemanager and thus each team member reports to a single boss, in the matrix there areat least two dimensions of management structure, whereby each team member mayhave two or more bosses. Each of these two bosses may have different managerialresponsibilities—for instance, one (perhaps the team leader) handles administrativetasks and reviews, whereas the other (perhaps the project manager) handles theassignment of tasks and project status. In Figure 3. 2, the traditional functional organization is augmented with a project management team on the side. 20 世纪 70 年代，组织行为主义者和管理者开始重新思考组织结构。正如我们所讨论的，虽然职能型组织有某些不可否认的好处，但也存在某些缺点。公司甚至军队开始尝试不同的组织结构。由此演化而来的第二种主要组织结构是矩阵结构。矩阵组织的基本概念是层次结构有两个维度。与每个团队有一个经理，因此每个团队成员向一个老板报告的职能组织相反，在矩阵中至少有两个维度的管理结构，其中每个团队成员可能有两个或更多老板。这两个老板中的每一个都可能具有不同的管理职责，例如，一个（可能是团队领导）处理管理任务和审查，而另一个（可能是项目经理）处理任务分配和项目状态。在图 3. 2 中，传统的职能组织增加了项目管理团队。 The right side of the organization in Figure 3. 2 looks very similar to a functionalstructure. The big difference comes from the left side, where the project managementorganization resides. Notice that the Project Managers within the Project Management Organization, PMO, are shaded with members of the other teams. ProjectManager 1 is shaded light gray along with Engineer 1, Engineer 2, Quality AssuranceEngineer 1, Quality Assurance Engineer 2, Product Manager 1, and Product Manager 2. This light gray group of individuals comprises the project team that is working togetherin a matrixed fashion. The light gray team project manager might have responsibility for the assignment of tasks and the timeline. In larger and more complex matrixorganizations, many members of each team can belong to project teams. 图 3. 2 中的组织右侧看起来与功能结构非常相似。最大的区别来自于项目管理组织所在的左侧。请注意，项目管理组织 (PMO) 内的项目经理与其他团队的成员位于阴影区。项目经理 1 以及工程师 1、工程师 2、质量保证工程师 1、质量保证工程师 2、产品经理 1 和产品经理 2 呈浅灰色。这个浅灰色的个人组包括以矩阵方式一起工作的项目团队。浅灰色团队项目经理可能负责任务分配和时间表。在更大、更复杂的矩阵组织中，每个团队的许多成员可以属于项目团队。  Continuing with the project team responsible for implementing the new billingfeature, we can start to realize the benefits of such a structure. The two primaryproblems with a functional organization are no project ownership and poor crossteam communication. In the matrix organization, the project team fixes both of theseproblems. We now have a first level manager, Project Manager 1, who owns the billing project. This project team will likely meet weekly or more and certainly have frequent email dialogues, which again solves one of the problems facing the functionalorganization: communication. If the software engineer wants to communicate to theQA engineer that a particular test needs to be included in the test harness, it is as simple as sending an email or mentioning it at the next team meeting, thus alleviating theneed to trudge through layers of management in search of the right person. 继续与负责实施新计费功能的项目团队合作，我们可以开始认识到这种结构的好处。职能型组织的两个主要问题是没有项目所有权和跨团队沟通不畅。在矩阵组织中，项目团队解决了这两个问题。我们现在有一位一级经理，即项目经理 1，他负责计费项目。该项目团队可能每周或更多次会面，并且肯定会进行频繁的电子邮件对话，这再次解决了职能组织面临的问题之一：沟通。如果软件工程师想要与 QA 工程师沟通某个特定的测试需要包含在测试工具中，那么只需发送电子邮件或在下一次团队会议上提及即可，从而减轻了在管理层中艰难跋涉的需要。寻找合适的人。 We can pick up our golf analogy that we used in the discussion of the functionalorganization. You probably remember that we described a golfer who wants to getbetter and perform well at golf. To that end, he surrounds himself with other golfers,perhaps even a golf instructor, and practices the game of golf, all very specific to hisgoal. This is analogous to the functional team where we want to perform a specificfunction very well and so we surround ourselves with others like us and practice onlythat skill. What sports trainers have found out in the recent past is that specificity isexcellent at developing muscle memory and basic skills but to truly excel, athletesmust cross-train. This is the concept of moving away from the golf course periodically and exercising other muscles such as through weight training or running. Thiscross-training is similar to the matrix organization in that it doesn’t replace the basictraining of golf or engineering but it enhances it by layering another discipline suchas running or project management. For those astute individuals who have crosstrained before, you might ask “can the cross-training actually hinder the athlete’s performance?” In fact, if you are a golfer, you may have heard such talk around notplaying softball because it can cause havoc with your golf swing. We will discuss thisconcept in the context of the drawbacks of matrix organizations. 我们可以采用在职能组织讨论中使用的高尔夫类比。您可能还记得我们描述了一位想要在高尔夫比赛中变得更好并表现出色的高尔夫球手。为此，他与其他高尔夫球手（甚至可能是高尔夫教练）一起练习高尔夫比赛，所有这些都非常具体地针对他的目标。这类似于职能团队，我们希望很好地执行特定职能，因此我们周围都是像我们这样的人，并且只练习该技能。运动教练最近发现，特异性对于培养肌肉记忆和基本技能非常有效，但要真正取得优异成绩，运动员必须进行交叉训练。这是定期离开高尔夫球场并锻炼其他肌肉（例如通过举重训练或跑步）的概念。这种交叉训练类似于矩阵组织，因为它不会取代高尔夫或工程的基本训练，但它通过分层跑步或项目管理等其他学科来增强它。对于那些曾经进行过交叉训练的精明人士，你可能会问“交叉训练真的会阻碍运动员的表现吗？”事实上，如果您是一名高尔夫球手，您可能听说过有关不打垒球的讨论，因为这会对您的高尔夫挥杆造成严重破坏。我们将在矩阵组织的缺点的背景下讨论这个概念。 If we have solved or at least dramatically improved the drawbacks of the functional organizational structure through the implementation of the matrix, surelythere is a cost for this improvement. The truth is that while solving the problems ofproject ownership and communication, we introduce other problems involving multiple bosses and distraction from a person’s primary discipline. Reporting to two ormore people—yes, matrix structures can get complex enough to require a person toparticipate on multiple teams—invariably causes stressors because of differences indirection given by each boss. The engineer trapped between her engineering managertelling her to code to a standard and her project manager insisting that she finish theproject on time is a setup that is asking for stress and someone not being pleased by her performance. Additionally, the project team requires overhead, as does any teamin the form of meetings and email communications. This does not replace the teammeetings that the engineer must attend for her engineering manager and thus takesmore time away from her primary responsibility of coding. 如果我们通过矩阵的实施，解决了或者至少大幅度改善了职能型组织结构的弊端，那么这种改善肯定是有成本的。事实是，在解决项目所有权和沟通问题的同时，我们引入了涉及多个老板和分散个人主要纪律的其他问题。向两个或两个以上的人汇报——是的，矩阵结构可能会变得足够复杂，需要一个人参与多个团队——由于每个老板给予的间接指导不同，总是会带来压力。工程师被困在她的工程经理告诉她按照标准编码和她的项目经理坚持要她按时完成项目之间，这种设置会带来压力，而且有人对她的表现不满意。此外，项目团队需要开销，任何团队也需要会议和电子邮件通信的形式。这并不能取代工程师必须为工程经理参加的团队会议，因此会占用更多的时间来承担主要的编码职责。 As you can see, while solving some problems, we have introduced new ones. Thisreally should not be too shocking because that is typically what happens and rarelyare we able to solve a problem without consequences of another variety. The nextquestion, given these pros and cons of the matrix organization, is “when would wewant to use such an organizational structure?” The appropriate times to use thematrix structure are when the fate of the project is extremely important eitherbecause of the timeline or other such factor. In these cases, having a project team surrounding the project, where there is a clear owner and the team structure facilitatescross team communication, is the right answer to ensure delivery. 正如你所看到的，在解决一些问题的同时，我们也引入了新的问题。这确实不应该太令人震惊，因为这通常是发生的情况，而且我们很少能够在不产生另一种后果的情况下解决问题。考虑到矩阵组织的这些优点和缺点，下一个问题是“我们什么时候想要使用这样的组织结构？”使用矩阵结构的适当时机是当项目的命运由于时间线或其他此类因素而极其重要时。在这些情况下，围绕项目建立一个项目团队，有明确的所有者，并且团队结构促进跨团队沟通，是确保交付的正确答案。 Unfortunately you are likely to experience challenges across your organizationthat are not always as straightforward as we have expressed in our simple examples.Real life, especially in a technology organization, is always more complex. Here iswhere the hybrid solutions become necessary. Your entire engineering organizationdoes not need to be part of a matrix structure. Instead, teams that are focused on verycross team oriented projects may be in a matrix, but other teams working on infrastructure projects might not be. Alternatively, you could use the multidimensionalnature of the matrix without actually creating the project team. An example of thiswould be to collocate the project team together, in the same cube row, without actually implementing the matrix. There are many other examples of how to createhybrid functional-matrix organizations. The key here is to use the organizationalstructure to solve your problems that exist today. There is no single right answer thatis right for all companies at all times. 不幸的是，您可能会在整个组织中遇到挑战，这些挑战并不总是像我们在简单示例中所表达的那样简单。现实生活，尤其是在技术组织中，总是更加复杂。这就是混合解决方案变得必要的地方。您的整个工程组织不需要成为矩阵结构的一部分。相反，专注于面向跨团队的项目的团队可能位于矩阵中，但从事基础设施项目的其他团队可能不是。或者，您可以使用矩阵的多维性质，而无需实际创建项目团队。一个例子是将项目团队放在同一立方体行中，而不实际实施矩阵。关于如何创建混合职能矩阵组织还有许多其他示例。这里的关键是利用组织结构来解决你今天存在的问题。没有一个正确答案在任何时候都适合所有公司。 #### Conclusion 结论 In this chapter, we highlighted the factors that an organizational structure can influence and showed how those are also key factors in an application or Web servicesscalability. Thus, we established a link between the organizational structure and scalability to point out that, just like hiring the right people and getting them in the rightroles, building a supporting organizational structure around them is just as important. We discussed the two determinants of an organization: the team size and thestructure. 在本章中，我们强调了组织结构可能影响的因素，并展示了这些因素如何也是应用程序或 Web 服务可扩展性的关键因素。因此，我们在组织结构和可扩展性之间建立了联系，以指出，就像雇用合适的人员并让他们担任合适的角色一样，围绕他们建立支持性的组织结构也同样重要。我们讨论了组织的两个决定因素：团队规模和结构。 tructure.In regards to the team size, we covered why size mattered—too small and you cannot accomplish enough; too large and you lose productivity and impact morale. Wefurther covered the four factors of management experience, team member tenure in the company and in the engineering field, managerial duties, and the needs of thebusiness. These all must be taken into consideration when determining the optimalteam size for your organization. We also covered the warning signs to watch for todetermine if your teams were too large or too small. For teams that were too large,we stated that poor communication, lowered productivity, and poor morale weresymptoms. For teams that were too small, we stated that disgruntled business partners, micromanaging managers, and overworked team members were all symptoms.Lastly on the team size discussion, we covered what items to consider when growingor splitting teams. Growing teams was pretty straightforward but splitting up teamsinto smaller teams entailed much more. For splitting teams, we covered topics including how to split the code base, who is going to be the new manager, what involvement will individual team members have, and how does this change the relationshipwith the business partners. 关于团队规模，我们讨论了为什么规模很重要——太小，你就无法完成足够的工作；太小，你就无法完成足够的工作；太大会降低生产力并影响士气。我们进一步涵盖了管理经验、团队成员在公司和工程领域的任期、管理职责和业务需求这四个因素。在确定组织的最佳团队规模时，必须考虑所有这些因素。我们还介绍了需要注意的警告信号，以确定您的团队是否太大或太小。对于规模太大的团队，我们指出沟通不畅、生产力下降和士气低落是症状。对于太小的团队，我们指出不满的业务合作伙伴、微观管理的经理和过度劳累的团队成员都是症状。最后，关于团队规模的讨论，我们讨论了扩大或拆分团队时需要考虑的事项。扩大团队非常简单，但将团队拆分成更小的团队需要做更多的事情。对于拆分团队，我们讨论的主题包括如何拆分代码库、谁将成为新经理、各个团队成员将参与哪些工作，以及这将如何改变与业务合作伙伴的关系。 The team structure discussion covered the two basic structures: functional andmatrix. We described each, discussed the benefits, analyzed the drawbacks, and recommended scenarios to be used. The functional structure was the original organizational structure and essentially divided employees up by their primary function, suchas engineering or quality assurance. The benefits of a functional structure include thehomogeneity of management and peers, simplicity of responsibilities, ease of taskassignment, and the greater adherence to standards. The drawbacks of the functionalstructure were no single project owner and poor cross-functional communication.These problems were specifically targeted in the matrix organizational structure andthey were solved. The matrix structure started out looking very similar to the functional structure but a second dimension was added that included a new managementstructure. We provided examples of the matrix structure, which normally includesproject managers as the secondary dimension. The strengths of the matrix organization are solving the problems of project ownership and communication but the drawbacks include multiple bosses and distraction from a person’s primary discipline. Weconcluded the organizational structure discussion with some thoughts on how hybridapproaches are often the best because they are designed to fit the needs of yourorganization. 团队结构讨论涵盖了两种基本结构：职能型和矩阵型。我们描述了每一个，讨论了优点，分析了缺点，并推荐了使用场景。职能结构是最初的组织结构，基本上按照主要职能（例如工程或质量保证）对员工进行划分。职能结构的好处包括管理层和同事的同质性、职责的简单性、任务分配的便利性以及对标准的更大程度的遵守。职能结构的弊端是没有单一的项目负责人，跨职能沟通不畅。这些问题在矩阵组织结构中得到了针对性的解决。矩阵结构一开始看起来与职能结构非常相似，但添加了第二个维度，其中包括新的管理结构。我们提供了矩阵结构的示例，其中通常包括项目经理作为第二维度。矩阵组织的优点是解决项目所有权和沟通问题，但缺点包括多个老板和分散一个人的主要纪律。我们在组织结构讨论中总结了一些想法，即混合方法通常是最好的，因为它们旨在满足组织的需求。 ##### Key Points 关键点 * Organizational structure can either hinder or aid a team’s ability to produce andsupport scalable applications. * Team size and structure are the two key attributes with regard to organizations. * Teams that are too small do not provide enough capacity to accomplish the priorities of the business. * Teams that are too large can cause a loss of productivity and degrade morale. * 组织结构可以阻碍或帮助团队生产和支持可扩展应用程序的能力。 * 团队规模和结构是组织的两个关键属性。 * 团队太小，无法提供足够的能力来完成业务的优先事项。 * 团队规模太大可能会导致生产力下降并降低士气。 * Two basic organizational structures are functional and matrix. * Functional organizational structures provide benefits such as the commonalityof management and peers, simplicity of responsibilities, ease of task assignment,and greater adherence to standards. * Matrix organizational structures provide benefits such as project ownership andimproved cross team communication. * Both team size and organizational structure must be determined by the needsand capabilities of your organization. * 两种基本的组织结构是职能型和矩阵型。 * 职能型组织结构带来的好处包括管理层和同事的共同性、职责的简单性、任务分配的轻松性以及对标准的更大程度的遵守。 * 矩阵组织结构提供了项目所有权和改进的跨团队沟通等好处。 * 团队规模和组织结构都必须根据组织的需求和能力来确定。
没有评论