这篇文章上次修改于 189 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 《可扩展的艺术》### Chapter 19 Fast or Right?第19章 快还是对？ > Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays.—Sun Tzu > 因此，尽管我们听说过战争中愚蠢的仓促，但从未见过聪明与长期拖延联系在一起。——孙子 You have undoubtedly heard that from the choices of speed, cost, and quality, we canonly ever choose two. This is the classic refrain when it comes to business and tech-nology. Imagine a product feature where the business sponsor has given your teamthe requirements of delivery by a very aggressive date assuming the use of all of yourteam, a quality standard consisting of absolutely zero defects, and the constraint ofonly being able to use one engineer. Although this particular example is somewhatsilly, the time cost and quality constraints are omnipresent and very serious. There isalways a budget for hiring; even in the fastest growing companies, there is always anexpectation of quality, whether in terms of feature completion or bugs; and there isalways a need to deliver by aggressive deadlines. 您无疑听说过，在速度、成本和质量的选择中，我们只能选择两者。这是商业和技术方面的经典说法。想象一下一个产品功能，业务赞助商向您的团队提出了在非常激进的日期前交付的要求，假设使用您所有的团队，由绝对零缺陷组成的质量标准，以及只能使用一名工程师的限制。虽然这个特定的例子有点愚蠢，但时间成本和质量限制是无处不在的，而且非常严重。招聘总是有预算的；即使在发展最快的公司中，也总是对质量有期望，无论是在功能完成度还是错误方面；并且总是需要在紧迫的期限内交付。 In this chapter, we will discuss the general tradeoffs made in business and specifi-cally the product development life cycle. We will also discuss how these tradeoffsrelate to scalability and availability. Finally, we will provide a framework for thinkingthrough these decisions on how to balance these three objectives or constraints,depending on how you view them. This will give you a guide by which you can assesssituations in the future and hopefully make the best decision possible. 在本章中，我们将讨论业务中的一般权衡，特别是产品开发生命周期。我们还将讨论这些权衡如何与可扩展性和可用性相关。最后，我们将提供一个框架来思考如何平衡这三个目标或约束，这取决于您如何看待它们。这将为您提供一个指南，您可以通过它评估未来的情况，并希望做出最好的决定。 ####Tradeoffs in Business 商业中的权衡 The speed, quality, and cost triumvirate is often referred to as the project triangle as itprovides a good visual for how these three are inextricably connected and how youcannot have all of them. There are several variations on this that also include scopeas a fourth element. This can be represented by putting quality in the middle anddefining the three legs of the triangle as speed, scope, and cost. We prefer to use thetraditional speed/cost/quality project triangle and define scope as the size of the trian-gle. This is represented in Figure 19.1, where the legs are speed, cost, and quality,whereas the area of the triangle is the scope of the project. If the triangle is small, thescope of the project is small and thus the cost, time, and quality elements are propor-tional. The representation is less important than the reminder that there is a balancenecessary between these four factors in order to develop products. 速度、质量和成本三者通常被称为项目三角形，因为它提供了一个很好的视觉效果，说明这三者如何密不可分地联系在一起，以及如何无法同时拥有所有这些。对此有几种变体，其中还包括范围作为第四个元素。这可以通过将质量放在中间并将三角形的三个边定义为速度、范围和成本来表示。我们更喜欢使用传统的速度/成本/质量项目三角形，并将范围定义为三角形的大小。这如图 19.1 所示，其中腿是速度、成本和质量，而三角形的面积是项目的范围。如果三角形小，则项目范围小，因此成本、时间和质量要素成正比。展示并不重要，重要的是提醒我们，为了开发产品，这四个因素之间必须保持平衡。  Ignoring any one of legs of the triangle will cause you to deliver a poor product. Ifyou ignore the quality of the product, it will result in either a feature without thedesired or required characteristics and functionality or it will be so buggy as to renderit unusable. If you choose to ignore the speed, your competitors are likely to beat youto market and you will lose first mover advantage and your perception as an innova-tor rather than a follower. The larger the scope of the project, the higher the cost, theslower the speed to market, and the more effort required to achieve a quality stan-dard. Any of these scenarios should be worrisome enough for you to seriously con-sider how you and your organization actively balance these constraints. 忽略三角形的任何一条腿都会导致您交付劣质产品。如果忽视产品的质量，就会导致产品不具备所需的或必需的特性和功能，或者会出现很多问题，导致无法使用。如果您选择忽视速度，您的竞争对手可能会在市场上击败您，您将失去先发优势以及作为创新者而不是追随者的看法。项目范围越大，成本越高，上市速度越慢，达到质量标准所需的努力也就越多。这些场景中的任何一个都应该足以让您感到担忧，以认真考虑您和您的组织如何积极平衡这些限制。 To completely understand why these tradeoffs exist and how to manage them, youmust first understand each of their definitions. We will define cost as any relatedexpense or capital investment that is utilized by or needed for the project. Costs willinclude such direct charges as the number of engineers working on the project, thenumber of servers required to host the new service, and the marketing campaign forthe new service. It will also include indirect cost such as an additional databaseadministrator necessary to handle the increased workload caused by another set ofdatabases or the additional bandwidth utilized by customers of the feature. You willprobably ask why such costs would be included in the proverbial bucket of costsassociated to the feature, and the answer is that if you spend more time on the fea-ture, you are very much more likely to figure out ways to shrink the cost of newhardware, additional bandwidth, and all the other miscellaneous charges. Thus, thereis automatically a tradeoff between the amount of time spent on something and theultimate cost associated with it. 要完全理解为什么存在这些权衡以及如何管理它们，您必须首先理解它们的每个定义。我们将成本定义为项目使用或需要的任何相关费用或资本投资。成本将包括直接费用，例如从事该项目的工程师数量、托管新服务所需的服务器数量以及新服务的营销活动。它还包括间接成本，例如需要额外的数据库管理员来处理另一组数据库引起的工作负载增加或该功能的客户使用的额外带宽。您可能会问为什么这些成本会包含在众所周知的与该功能相关的成本桶中，答案是，如果您在该功能上花费更多时间，您就更有可能找到降低该功能成本的方法。新硬件、额外带宽以及所有其他杂项费用。因此，在某件事上花费的时间和与之相关的最终成本之间会自动进行权衡。 For the definition of quality, we will include not only the often thought of bugsthat mark poor quality, but also the fullness of the functionality. A feature launchedwith half of the specified functionality is not likely to generate as much interest norrevenue from customers as one with all the functionality intact. Thus, the tradeofffrom launching a feature quickly can often result in lower quality in terms of func-tionality. The same is true for utilizing fewer engineers on a project or assigning onlythe most junior engineers on a project that requires senior engineers. As you wouldexpect, quality also includes the amount of time and resources provided during qual-ity assurance. Resources within quality assurance can include not only testing engi-neers but also proper environments and testing tools. Organizations that skimp ontools for testing cannot as efficiently utilize their testing engineers. 对于质量的定义，我们不仅包括人们通常认为的质量差的错误，还包括功能的完整性。一项仅包含一半指定功能的功能不可能像所有功能都完好无损的功能那样引起客户的兴趣或收入。因此，快速启动功能的权衡通常会导致功能质量下降。对于在项目中使用较少工程师或在需要高级工程师的项目中仅指派最低级工程师的情况也是如此。正如您所期望的，质量还包括质量保证期间提供的时间和资源。质量保证中的资源不仅包括测试工程师，还包括适当的环境和测试工具。缺乏测试工具的组织无法有效地利用他们的测试工程师。 For the definition of speed, we will use the amount of time that a feature or projecttakes to move from the initial step in the product development life cycle to release inproduction. We know that the life cycle doesn’t end with the release to production,and in fact continues through support and eventually deprecation, but those phasesof the feature’s life are typically a result of the decisions made much earlier. Forexample, a feature that is rushed through the life cycle without the ample time inquality assurance or design will significantly increase the amount of time that a fea-ture will need to be supported once in production. Features that are not given enoughor ample time to be designed properly, possibly in a Joint Architecture Design processand then reviewed at an Architecture Review Board, are destined to be of lower qual-ity or higher cost or possibly both. 对于速度的定义，我们将使用功能或项目从产品开发生命周期的初始步骤到发布生产所需的时间量。我们知道，生命周期并不会随着发布到生产环境而结束，事实上，它会一直持续到支持和最终弃用，但功能生命周期的这些阶段通常是更早做出的决策的结果。例如，如果某个功能的生命周期仓促，而没有足够的时间进行质量保证或设计，那么该功能在投入生产后需要支持的时间就会显着增加。没有给予足够或充足的时间来正确设计的功能，可能是在联合架构设计过程中，然后在架构审查委员会进行审查，注定是质量较低或成本较高或两者兼而有之。 For the definition of scope, we will consider the amount of product features beingdeveloped as well as the level of effort required for the development of each productfeature. Often, the scope of a feature can be changed dramatically depending on therequirements that are deemed necessary in order to achieve the business goals thathave been established for that feature. For example, take a particular feature that is anew customer signup flow. The goal of this feature is to increase customer signupcompletion by 10%, meaning that 10% more of the people who start the signup pro-cess complete it. The initial scope of this feature might specify the requirement ofintegration with another service provider’s single signon. The team might decidethrough user testing that this functionality is not required and thus the scope of thisfeature would be dramatically reduced. 对于范围的定义，我们将考虑正在开发的产品功能的数量以及开发每个产品功能所需的工作量。通常，功能的范围可能会根据被认为是实现为该功能确定的业务目标所必需的要求而发生巨大变化。例如，采用新客户注册流程的特定功能。此功能的目标是将客户注册完成率提高 10%，这意味着开始注册过程的人中完成注册的人数增加了 10%。此功能的初始范围可能会指定与其他服务提供商的单点登录集成的要求。团队可能通过用户测试决定不需要此功能，因此此功能的范围将大大缩小。 We use the Project Triangle to represent the equality in importance of these con-straints. As with Figure 19.2, change the emphasis of the project as well as the scope.The two diagrams represent different focuses for different projects. The project onthe left has a clear predilection for faster speed and higher quality at the necessaryincrease in cost. This project might be something that is critical to block a competitor.Thus, it needs to be launched by the end of the month and be full featured in anattempt to beat a competitor to market with a similar product. The cost of addingmore engineers, possibly more senior engineers and more testing engineers, is worththe advantage in the marketplace with your customers. 我们使用项目三角形来表示这些约束的重要性的平等。与图 19.2 一样，更改项目的重点以及范围。这两个图代表了不同项目的不同重点。左边的项目明显偏向于更快的速度和更高的质量，但成本却必要增加。该项目可能对于阻止竞争对手至关重要。因此，它需要在月底之前推出并具有完整的功能，以试图以类似的产品击败竞争对手进入市场。增加更多工程师（可能是更多高级工程师和更多测试工程师）的成本值得您在市场上与客户取得优势。  The project on the right in Figure 19.2 has a focus on increased speed to market witha lower cost point at the expense of reduced quality. This project might be somethingnecessary for compliance where it is essential to meet a deadline to avoid penalties.There are likely no revenue generating benefits for the feature; therefore, it is essen-tial to keep the costs as low as possible. This project might be the equivalent to aY2K bug where the fix does not need to be full functioned but just needs to performthe basic functionality by the specified date with minimal cost. 图 19.2 右侧的项目重点关注以降低质量为代价提高上市速度和降低成本。该项目可能对于合规性来说是必要的，因为必须在最后期限内完成以避免处罚。该功能可能不会产生收入；因此，必须尽可能降低成本。该项目可能相当于 2000 年错误，其中修复不需要完全发挥作用，而只需要在指定日期之前以最小的成本执行基本功能。 For anyone who has been in business for any amount of time, it should not comeas a surprise that there are tradeoffs that must be made. It is expected in business thatleaders make decisions everyday about how to allocate their precious resources, bethey engineers, dollars, or time. Often, these decisions are made with a well thoughtout process in order to understand the pros and cons of giving more or less time,money, or people to certain projects. As we will discuss later in this chapter, there areseveral processes that you can use to analyze these decisions, some more formal thanothers. Knowing that business is almost a constant tradeoff that the product develop-ment life cycle is part of, this is to be expected. Decisions must be made on allocatingengineers to features, cutting out functionality when estimates prove not to be accu-rate, and deciding go/no-go criteria in terms of open bugs that remain in the candi-date release. 对于任何已经从事该行业一段时间的人来说，必须做出一些权衡并不奇怪。在商界，领导者每天都会做出如何分配宝贵资源的决策，无论是工程师、金钱还是时间。通常，这些决定是经过深思熟虑的过程做出的，以便了解为某些项目提供更多或更少的时间、金钱或人员的利弊。正如我们将在本章后面讨论的，您可以使用多个流程来分析这些决策，其中一些流程比其他流程更正式。知道业务几乎是一个不断的权衡，产品开发生命周期也是其中的一部分，这是可以预料的。必须做出决定，将工程师分配给功能，在估计被证明不准确时削减功能，并根据候选版本中保留的未解决错误来决定通过/不通过标准。 The cost, quality, speed, and scope constraints that comprise the Project Triangleare all equally important overall but may vary significantly from project to project interms of their importance and effort to manage. Projects that require higher qualitymay or may not be easier to achieve higher quality than other projects. Also, justbecause it cost more to achieve, does not make it necessarily required. So, justbecause we need higher quality in our project does not mean that the cost of this is alinear relationship. A 1% improvement in quality might cost 5%, but once you arepast a 20% improvement in quality, this cost might go up to 10%. This is why eachproject uses its own Allocation Circle placed over the Project Triangle that designateswhere the focus should be for this project. You can create this diagram for everyproject as part of the specification if you feel it provides valuable information foreveryone involved in the project, or you can just do the tradeoff analysis without thediagram. 构成项目三角的成本、质量、速度和范围限制总体上同等重要，但不同项目的重要性和管理工作量可能存在很大差异。需要更高质量的项目可能比其他项目更容易达到更高的质量，也可能不容易。而且，仅仅因为实现它的成本更高，并不意味着它一定是必需的。因此，仅仅因为我们的项目需要更高的质量并不意味着其成本是线性关系。质量提高 1% 可能会花费 5%，但一旦质量提高超过 20%，这一成本可能会上升到 10%。这就是为什么每个项目都使用自己的分配圈放置在项目三角形上，以指定该项目的重点位置。如果您认为它为参与项目的每个人提供了有价值的信息，您可以为每个项目创建此图表作为规范的一部分，或者您可以在没有图表的情况下进行权衡分析。 ####Relation to Scalability 与可扩展性的关系 How can these tradeoffs between cost, quality, speed, and scope affect a system’sscalability? As hinted at in the last chapter, it can be a very straightforward relation-ship of tradeoffs made directly for scalability or infrastructure projects. Anothermore indirect way that scalability is affected by the tradeoffs made between theseconstraints is that decisions made on feature projects can in the long term affect thescalability of that feature as well as of the entire system. 成本、质量、速度和范围之间的这些权衡如何影响系统的可扩展性？正如上一章所暗示的，它可以是直接针对可扩展性或基础设施项目进行权衡的非常简单的关系。可扩展性受到这些约束之间的权衡影响的另一种更间接的方式是，对功能项目所做的决策从长远来看会影响该功能以及整个系统的可扩展性。 A scalability project that needs to split the primary database, just like a featuredevelopment release, will have to balance the four constraints. Will you take yourmost senior engineers off feature development for this? Will you give the team sixmonths or eighteen months to complete the project? Will you include the built-infunctionality to allow further database splits as necessary, or will you cut the projectshort and have it only provide a single split? All of these questions are ones that youwill have to make over the course of the project and are a balance of the speed, cost,quality, and scope Project Triangle. 需要拆分主数据库的可扩展性项目，就像功能开发版本一样，必须平衡这四个约束。您会为此让最高级的工程师退出功能开发吗？您会给团队六个月还是十八个月的时间来完成该项目？您是否会包含内置功能以允许根据需要进行进一步的数据库拆分，还是会缩短项目并使其仅提供单个拆分？所有这些问题都是您在项目过程中必须解决的问题，并且是速度、成本、质量和项目三角范围的平衡。 These constraints can also affect scalability indirectly. Let’s take for example apayment feature at AllScale where the focus is placed more heavily on the side ofspeed. This feature must be released by the end of the month in order to be ready forthe end-of-month billing cycle. Missing this date would result in days of manualwork to process the payments, which would introduce many more errors resulting incharge backs and lost revenue. The engineering manager, Mike Softe, pulls threesenior engineers off another project to place them on this payment project in order toget it done on time. All goes well and the feature is released the weekend beforemonth-end allowing it to process the billing as planned. 这些限制也会间接影响可扩展性。让我们以 AllScale 的支付功能为例，其中重点更多地放在速度方面。此功能必须在月底之前发布，以便为月末计费周期做好准备。错过这个日期将导致需要数天的手动时间来处理付款，这将导致更多错误，从而导致退款和收入损失。工程经理 Mike Softe 从另一个项目抽调了三名高级工程师，将他们安排到这个付款项目中，以便按时完成项目。一切顺利，该功能在月底前的周末发布，使其能够按计划处理计费。 Six months later, the AllScale HRM site’s volume has increased over 100% and aneven larger percentage of users are participating in the end-of-month billing cycleproducing a total increase in load on the billing feature of close to 150% from whenit was launched. Thus far, it has held up stoically with processing times of no morethan 12 hours. However, this month’s increase in users put it over the edge and theprocessing time jumps to over 38 hours. Designed as an add-on feature to a singletonapplication, this service cannot be run on multiple servers. Now the consequences ofdecisions made six months ago start to be seen. The AllScale operations team mustreallocate a much larger server, planned to be used as a database server, for this appli-cation in order to get through next month’s processing cycle. Of course, this nega-tively affects the hardware budget. The operations team also has to spend a lot oftime monitoring, provisioning, configuring, and testing the server for this move.Engineers and quality assurance engineers are likely brought in to this project to pro-vide advice on changes as well as final validation that the application works on thenew hardware. This new hardware project has to take place during a maintenancewindow because of the high risk to the users and takes up a good portion of the riskallocation that is authorized for the system this particular week. The database splitproject has to be postponed because new hardware has to be ordered, which addsmore risk of problems arising from the database being overloaded. 六个月后，AllScale HRM 网站的访问量增加了 100% 以上，并且参与月末计费周期的用户比例甚至更高，计费功能的总负载较推出时增加了近 150%。到目前为止，它的处理时间不超过 12 小时。然而，本月用户的增加使其超出了极限，处理时间跃升至超过 38 小时。该服务被设计为单例应用程序的附加功能，不能在多个服务器上运行。现在六个月前做出的决定的后果开始显现。 AllScale 运营团队必须为此应用程序重新分配一台更大的服务器，计划用作数据库服务器，以便完成下个月的处理周期。当然，这会对硬件预算产生负面影响。运营团队还必须花费大量时间来监控、配置、配置和测试此移动的服务器。工程师和质量保证工程师可能会参与此项目，以提供有关更改的建议以及最终验证应用程序可以在新硬件上运行。这个新的硬件项目必须在维护窗口期间进行，因为对用户来说风险很高，并且占用了本周为系统授权的风险分配的很大一部分。由于需要订购新硬件，数据库拆分项目不得不推迟，这增加了数据库过载而出现问题的风险。 As you can see from our example, the decisions made during initial feature devel-opment can have many unseen affects on scalability of the entire system. Does thismean that the decisions and tradeoffs were incorrect? No, in fact, even with the ben-efit of hindsight, you might still feel the decision to push to quickly get the featureinto production was the right decision, and we probably agree in this scenario. Theimportant learning here is not that one decision is right or wrong but rather that thedecisions have short- and long-term ramifications that you may not be able to evercompletely understand. 正如您从我们的示例中看到的，在初始功能开发期间做出的决策可能会对整个系统的可扩展性产生许多看不见的影响。这是否意味着决策和权衡是错误的？不，事实上，即使事后诸葛亮，您可能仍然觉得推动该功能快速投入生产的决定是正确的决定，在这种情况下我们可能会同意。这里重要的学习不是一个决定是对还是错，而是这些决定会产生你可能无法完全理解的短期和长期影响。 ####How to Think About the Decision 如何思考这个决定 Now that we have described how these tradeoffs are being made every day in yourorganization and how these can affect the scalability of the individual features as wellas the overall system, it is time for us to discuss how to properly make these deci-sions. There are a variety of methods to choose from when you need to determine theproper tradeoff. You can choose to rely on one of these methods or you can learnthem all in order that you use them each in the most appropriate manner. Unfortu-nately, no decision process is going to be able to guarantee that you reach a correctdecision because often there is no correct decision; rather, there are just ones thathave different pros and cons than others. Just as with risk management, managingtradeoffs or risk or even people is an ongoing process that keeps managers on theirtoes. Today’s seemingly straightforward decision becomes a quagmire tomorrow withthe addition of one more factor. A bug fix identified as low risk suddenly becomeshigh risk as the engineer digs into the code and realizes that a complete rewrite of abase class is necessary. A great idea to rush a payments feature into production todaybecomes a mess when headroom calculations predict that it will outgrow the pay-ment server in two months. 现在我们已经描述了您的组织中每天如何进行这些权衡，以及这些权衡如何影响各个功能以及整个系统的可扩展性，现在是我们讨论如何正确做出这些决策的时候了。当您需要确定适当的权衡时，有多种方法可供选择。您可以选择依赖其中一种方法，也可以学习所有这些方法，以便以最合适的方式使用它们。不幸的是，没有任何决策过程能够保证你做出正确的决定，因为通常没有正确的决定；相反，只有一些与其他有不同的优点和缺点。正如风险管理一样，权衡、风险甚至人员管理是一个持续的过程，需要管理者保持警惕。今天看似简单的决定，明天多了一个因素就会变成泥潭。当工程师深入研究代码并意识到需要完全重写基类时，被确定为低风险的错误修复突然变成高风险。今天，当动态计算预测支付功能将在两个月内超出支付服务器的容量时，今天将支付功能匆忙投入生产的好主意变得一团糟。 Our goal here is to arm you with several methodologies that won’t always giveyou the correct answer, because that can be elusive, but rather will help you rigor-ously process the information that you do have in order for you to make the bestdecision based on the information that you have today. There are three general meth-ods that we have seen used. The first one is essentially the same gut feel method thatwe described in Chapter 16, Determining Risk. The second method is a list of prosand cons for each constraint. The third is what we call a decision matrix and involvesconstructing a well thought out analysis of what factors are important, both shortand long term, ranking these factors compared to each other, defining the actualtradeoffs being considered, and determining how directly the tradeoffs impact thefactors. If that last one sounds confusing, don’t worry; we’ll go through it in moredetail in a few paragraphs. 我们的目标是为您提供几种方法，这些方法并不总是能给您正确的答案，因为这可能难以捉摸，但会帮助您严格处理您所拥有的信息，以便您做出最佳决策。根据您今天掌握的信息。我们见过使用三种通用方法。第一种方法本质上与我们在第 16 章“确定风险”中描述的直觉方法相同。第二种方法是列出每个约束的优缺点。第三个是我们所说的决策矩阵，涉及对哪些短期和长期重要因素进行深思熟虑的分析，对这些因素进行相互比较，定义正在考虑的实际权衡，并确定权衡如何直接影响这些因素。如果最后一个听起来令人困惑，请不要担心；我们将在几段中更详细地讨论它。 First, let’s discuss the gut feel method for making tradeoffs. As we discussed withregards to risk, there are some people who have an innate ability or well-honed skillto determine the pros and cons of decisions. This is great, but as we pointed outbefore, this method is not scalable and not accurate. That doesn’t mean that you needto abandon this method; in fact, you probably already use this method the most ofany other method and you probably do it on a daily basis. We use the gut methodevery time we decide to walk the ten blocks to the market instead of getting a cab,allocating more to the cost saving constraint and less on the speed to market con-straint. You use this in business everyday as well. You decide to hire one person whowill require slightly more salary but will hopefully produce faster and higher qualitywork. It’s doubtful that you conduct a formal analysis about each hire that is a cou-ple percentage points over the budgeted salary; it is more likely that you are likeother managers who have become used to conducting quick tradeoff analysis in theirheads or relying on their “guts” to help them make the best decisions given the infor-mation that they have at the time. 首先，让我们讨论一下进行权衡的直觉方法。正如我们在风险方面讨论的那样，有些人具有天生的能力或经过磨练的技能来确定决策的利弊。这很棒，但正如我们之前指出的，这种方法不可扩展且不准确。这并不意味着您需要放弃这种方法；事实上，与其他方法相比，您可能已经最常使用此方法，并且您可能每天都会这样做。每当我们决定步行十个街区而不是乘坐出租车去市场时，我们都会使用直觉方法，将更多的资金分配给节省成本的约束，而较少分配给上市速度的约束。您在日常工作中也使用它。您决定雇用一名需要稍高薪水但希望能够更快、更高质量完成工作的人。值得怀疑的是，您是否对每名超出预算工资几个百分点的员工进行正式分析；您更有可能像其他经理一样，习惯于在头脑中进行快速权衡分析，或依靠自己的“勇气”来帮助他们根据当时掌握的信息做出最佳决策。 The second and more formal method of tradeoff analysis is the comparison ofpros and cons. In this method, you would either by yourself or with a team of indi-viduals knowledgeable about the project gather your thoughts on paper. The goal isto list out the pros and cons of each tradeoff that you are making. For example, atAllScale, when Mike Softe was deciding to rush the payment feature into productionby reallocating three engineers who were working on other projects, he could list outas many tradeoffs as he could come up with. Then, Mike would identify the pros andcons of each tradeoff, which would look something like this: 第二种也是更正式的权衡分析方法是利弊比较。在这种方法中，您可以自己或与熟悉该项目的团队一起将您的想法收集在纸上。目标是列出您正在做出的每个权衡的利弊。例如，在 AllScale，当 Mike Softe 决定通过重新分配三名从事其他项目的工程师来加快支付功能投入生产时，他可以列出尽可能多的权衡方案。然后，迈克会确定每个权衡的利弊，看起来像这样 1.Engineers reallocated 1.工程师重新分配 * Pros: Faster payment feature development; better feature design * 优点：支付功能开发更快；更好的功能设计 * Cons: Other features suffer from reallocation; cost allocated to feature increases * 缺点：其他功能会受到重新分配的影响；分配给功能增加的成本 2.Speed feature into production 2.加速功能投入生产 * Pros: Fulfill business need for no more manual processing * 优点：满足业务需求，不再需要手动处理 * Cons: Possibly weaker design; fewer contingencies thought through; increasedcost in hardware * 缺点：设计可能较弱；考虑的意外事件较少；硬件成本增加 3.Reduce quality testing 3.减少质量测试 * Pros: Meet business timeline * 优点：符合业务时间表 * Cons: More bugs * 缺点：更多错误 After the tradeoffs that are being considered have been identified and the pros andcons of each listed, Mike is ready to move to the next step. This step is to analyze thepros and cons to determine which ones outweigh the others for each tradeoff. Mikecan do this by simply examining them or by allocating a score to them in terms ofhow bad or good they are. For instance, with the reduce quality testing tradeoff, thepros and cons can simply be looked at and a determination made that the pros out-weigh the cons in this case. With the tradeoff of reallocating the engineers, the prosand cons would probably have to be analyzed in order to make the decision. In thiscase, Mike may feel that the features the engineers have been pulled from were alllow-to-medium priority and can be postponed or handed off to more junior engi-neers. In the event that Mike decides to let more junior engineers work on the fea-tures, he can mitigate the risk by having an architect review the design and mark thisfeature for a code review. Because he can mitigate the risk and the benefit is so great,he would likely decide to proceed with this tradeoff. This process of listing out thetradeoffs, determining pros and cons, and then analyzing each one is the secondmethod of performing a tradeoff analysis. 在确定正在考虑的权衡以及列出的每个方案的优缺点后，迈克准备进入下一步。此步骤是分析利弊，以确定每种权衡中哪些方案更胜一筹。迈克可以通过简单地检查它们或根据它们的好坏程度给它们打分来做到这一点。例如，通过减少质量测试权衡，可以简单地查看利弊，并确定在这种情况下利大于弊。由于需要权衡重新分配工程师，可能需要分析利弊才能做出决定。在这种情况下，Mike 可能会觉得工程师被取消的功能属于中低优先级，可以推迟或移交给更多的初级工程师。如果迈克决定让更多初级工程师处理这些功能，他可以通过让架构师审查设计并将此功能标记为进行代码审查来降低风险。因为他可以降低风险并且收益如此之大，所以他可能会决定继续进行这种权衡。列出权衡、确定利弊、然后分析每一项的过程是执行权衡分析的第二种方法。 The third method of tradeoff analysis is a more formal process. In this process,you will take the tradeoffs identified and add to them factors that are important inaccomplishing the project. What you will have at the end of the analysis is a scorethat you can use to judge each tradeoff based on the most important metrics to you.As stated earlier, this cannot guarantee that you will make a correct decision, becausefactors that may impact you in the future might not be known at this point. However,this method will help you be assured that you have made a decision based on dataand it is the best decision you can make at this time. 权衡分析的第三种方法是一个更正式的过程。在此过程中，您将进行已确定的权衡，并添加对完成项目至关重要的因素。分析结束时您将得到一个分数，您可以使用该分数根据对您来说最重要的指标来判断每个权衡。如前所述，这不能保证您会做出正确的决定，因为可能会影响您的因素此时此刻，未来可能还不可知。然而，这种方法将帮助您确信您已经根据数据做出了决定，并且这是您此时可以做出的最佳决定。 Let us continue the example that we were using with the AllScale payment feature.The tradeoffs that Mike Softe, VP of engineering, had decided on for the paymentfeature were reallocating engineers, speeding the feature to production, and reducingthe quality of testing. He now needs to identify the factors that are most important tohim while accomplishing this project. This list can be generated by one person orwith a group of people familiar with the project and general needs of the businessand technology organizations. For our example, Mike has composed the followinglist of important factors: 让我们继续使用 AllScale 支付功能的示例。工程副总裁 Mike Softe 为支付功能决定的权衡是重新分配工程师、加快该功能的生产速度并降低测试质量。他现在需要确定完成该项目时对他最重要的因素。该列表可以由一个人或一组熟悉项目以及业务和技术组织的一般需求的人生成。对于我们的示例，迈克列出了以下重要因素 * Meet the business goals of launching by the EOM * 满足 EOM 启动的业务目标 * Maintain availability of the entire system at 99.99% * 保持整个系统的可用性在99.99 * The feature should scale to 10x growth * 该功能应扩展至 10 倍增长 * The other product releases should not be pushed off track by this * 其他产品的发布不应因此而偏离轨道 * We want to follow established processes as much as possible * 我们希望尽可能遵循既定流程 He then needs to rank order these to find out what factors are the most important.Mike considers the preceding order stated as the order of importance. In Figure 19.3,you can see that Mike has listed the tradeoffs down the left column and placed thefactors across the top of the matrix. These factors are sorted and he has added aweight below each factor. For simplicity, Mike used 1 through 5, as there are five fac-tors. For more elaborate matrixes, you can use a variety of scales, such as 1, 3, 9, orallocation out of a 100 value sum, where you have 100 points to allocate among thefactors (one may get 25, whereas others may get 3). 然后，他需要对这些因素进行排序，以找出最重要的因素。迈克将前面的顺序视为重要性顺序。在图 19.3 中，您可以看到 Mike 在左列中列出了权衡，并将这些因素放在矩阵的顶部。对这些因素进行排序，并在每个因素下面添加了权重。为了简单起见，Mike 使用了 1 到 5，因为有五个因素。对于更复杂的矩阵，您可以使用各种尺度，例如 1、3、9，或者从 100 个值总和中进行分配，其中您有 100 个点可以在因子之间分配（一个可能会得到 25，而其他人可能会得到 3） 。  After the matrix is created, you need to fill in the middle, which is the strength ofsupport that a tradeoff has on a factor. Mike is using a scale from –9 to 9, with incre-ments of 1, 3, –3, and –1.If a tradeoff fully supports a factor, it would receive a scoreof 9.If it somewhat supports, it gets a 3.If it is unsupportive of the factor, and inwhich case it would cause the opposite of the factor, it gets a negative score; thehigher the more it is unsupportive. For example, the tradeoff of Reduce the QualityTesting for the feature has a –9 score for Follow Established Processes because itclearly does not follow established processes of testing. After the matrix is filled out,Mike can perform the calculations on them. The formula is to multiply each score inthe body of the matrix by the weight of each factor and then sum these products foreach tradeoff producing the total score. Using the Engineers Reallocated tradeoff,Mike has a formula as depicted in Figure 19.4. 创建好矩阵后，需要填充中间部分，即权衡对某个因素的支持强度。迈克使用从 –9 到 9 的量表，增量为 1、3、–3 和 –1。如果权衡完全支持某个因素，它将获得 9 分。如果它在一定程度上支持，它会获得 9 分。 3.如果不支持该因素，并且会导致该因素的相反结果，则得负分；越高越不支持。例如，减少该功能的质量测试的权衡对于“遵循既定流程”的得分为 –9，因为它显然不遵循既定的测试流程。矩阵填好后，迈克就可以对它们进行计算。该公式是将矩阵主体中的每个分数乘以每个因素的权重，然后将每个权衡的这些乘积相加，得出总分。使用工程师重新分配权衡，Mike 得到了如图 19.4 所示的公式。 The total score for this tradeoff in the equation in Figure 19.4 is 67.This formula iscalculated for each tradeoff. With this final score, Mike and his team can analyze eachtradeoff individually as well as all the tradeoffs collectively. From this sample analy-sis, Mike has decided to find a way to allow more time spent in quality testing whileproceeding with reallocating engineers and expediting the feature into production. 图 19.4 等式中此权衡的总分是 67。此公式针对每个权衡进行计算。有了这个最终分数，迈克和他的团队就可以单独分析每个权衡，也可以集体分析所有权衡。根据这个样本分析，Mike 决定找到一种方法，让更多的时间花在质量测试上，同时继续重新分配工程师并加快该功能投入生产。  #####Fast or Right Checklist 快速或正确的清单 * What does your gut tell you about the tradeoff? * 关于权衡，你的直觉告诉你什么？ * What are the pros and cons of each alternative? * 每种替代方案的优点和缺点是什么？ * Is a more formal analysis required because of the risk or magnitude of the decision? * 由于决策的风险或程度，是否需要进行更正式的分析？ * If a more formal analysis is required: * 如果需要更正式的分析 What are the most important factors? In Six Sigma parlance, these are critical to quality indicators. 最重要的因素是什么？用六西格码的说法，这些对于质量指标至关重要。 How do these factors rank compared to each other—that is, what is the most important one of these factors? 这些因素之间的排名如何——也就是说，这些因素中最重要的一个是什么？ What are the actual tradeoffs being discussed? 正在讨论的实际权衡是什么？ How do these tradeoffs affect the factors? 这些权衡如何影响这些因素？ * Would you feel comfortable standing in front of your board explaining your decision based on the information you have today? * 您是否愿意站在董事会面前根据您今天掌握的信息解释您的决定？ We have given you three methods of analyzing the tradeoffs from balancing thecost, quality, and speed constraints. It is completely appropriate to use all three ofthese methods at different times or in increasing order of formality until you believethat you have achieved a sufficiently rigorous decision. The two factors that you mayconsider when deciding which method to use are the risk of the project and the mag-nitude of the decision. The risk should be calculated by one of the methods describedin Chapter 16.There is not an exact level of risk that corresponds to a particularanalysis methodology. Using the traffic light risk method, projects that would be con-sidered green could be analyzed by gut feeling, whereas yellow projects should atleast have the pros and cons compared as described in the pro and con comparisonprocess earlier. Examples of these tradeoff rules are shown in Table 19.1.Of course,red projects should be candidates for a fully rigorous decision matrix. This is anothergreat intersection of processes where a set of rules to work by would be an excellentaddition to your documentation. 我们为您提供了三种方法来分析平衡成本、质量和速度限制的权衡。在不同时间或按照正式顺序使用所有这三种方法是完全合适的，直到您相信您已经做出了足够严格的决定。在决定使用哪种方法时，您可能需要考虑的两个因素是项目的风险和决策的规模。风险应通过第 16 章中描述的方法之一进行计算。没有与特定分析方法相对应的确切风险级别。使用红绿灯风险方法，可以通过直觉来分析被认为是绿色的项目，而黄色项目至少应该像前面的优缺点比较过程中所述的那样比较优缺点。这些权衡规则的示例如表 19.1 所示。当然，红色项目应该是完全严格的决策矩阵的候选项目。这是流程的另一个重要交叉点，其中一组工作规则将是对文档的出色补充。  ####Conclusion 结论 In this chapter, we tackled the tough and ever present balancing act between cost,quality, speed, and scope. The Project Triangle is used to show how each of theseconstraints are equally important to pay attention to. Each project will have a differ-ent predilection for satisfying one or more of these constraints. Some projects need tomore satisfy the need to reduce cost; in others, it is imperative that the quality of thefeature be maintained at the detriment of cost, speed, and scope. 在本章中，我们解决了成本、质量、速度和范围之间始终存在的棘手平衡问题。项目三角用于展示这些约束中的每一个如何同样重要地需要关注。每个项目都会有不同的偏好来满足这些约束中的一个或多个。有的项目需要更多地满足降低成本的需要；在其他情况下，必须以牺牲成本、速度和范围来维持功能的质量。 We first looked at the definitions of cost, quality, speed, and scope. We determinedthat the cost of a feature or project included the direct and indirect costs. This canbecome fairly exhaustive to attempt to allocate all costs with a particular feature, andthis exercise is generally not necessary. It is sufficient to be aware that there are manylevels of cost and these occur over both short and long terms. For quality, we used adefinition that included both the amount of bugs in the feature but also the amountof full functionality. A feature that did not have all the functions specified is of poorerquality than one that has all the specified features. For speed, we defined this term asthe time to market or the pace in which the feature moves through the product devel-opment life cycle into production but not beyond. Post-production support was a spe-cial case that was more a cause of the cost, quality, speed tradeoff, rather than a partof it. 我们首先研究了成本、质量、速度和范围的定义。我们确定功能或项目的成本包括直接成本和间接成本。如果尝试分配特定功能的所有成本，这可能会变得相当详尽，并且通常没有必要进行此操作。只要意识到成本有很多层次，并且这些成本会在短期和长期内发生，就足够了。为了质量，我们使用的定义既包括功能中的错误数量，也包括完整功能的数量。不具有所有指定功能的功能的质量比具有所有指定功能的功能要差。对于速度，我们将这个术语定义为上市时间或功能通过产品开发生命周期进入生产但不超出生产的速度。后期制作支持是一种特殊情况，更多的是成本、质量、速度权衡的原因，而不是其中的一部分。 Armed with the definitions, we concluded that as business leaders and technologymanagers, we are constantly making tradeoff decisions between the three constraintsof cost, quality, and speed. Some of these decisions we are aware of and others we arenot. Some occur consciously, whereas others are subconscious analyses that are donein a matter of seconds. 有了这些定义，我们得出的结论是，作为业务领导者和技术经理，我们不断在成本、质量和速度这三个约束之间做出权衡决策。其中一些决定我们知道，而另一些则我们不知道。有些是有意识地发生的，而另一些则是在几秒钟内完成的潜意识分析。 We then discussed how the tradeoffs were related to scalability. We concluded thatthere was a direct relationship when these constraints were made for infrastructure orscalability projects. There was also an indirect relationship when decisions made forfeatures affect the overall scalability of the system many months or years laterbecause of predictable and in some cases unforeseen factors. 然后我们讨论了权衡如何与可扩展性相关。我们的结论是，当对基础设施或可扩展性项目进行这些限制时，存在直接关系。由于可预测的、在某些情况下不可预见的因素，当针对功能做出的决策影响数月或数年后系统的整体可扩展性时，也存在间接关系。 Because there is a very strong relationship with decisions made in these tradeoffsto scalability, it is important to make the best decision possible. To help you makethese decisions, we provided three methods for decision analysis. These methodswere the gut feel method first introduced in our earlier discussion on risk, a pro andcon comparison, and finally a rigorous decision matrix that involved formulas for usto calculate scores for each tradeoff. Although we conceded that there is no correctanswer possible due to the unknowable factors, there are best answers that can beachieved through rigorous analysis and data driven decisions. 由于这些权衡与可扩展性的决策之间存在非常密切的关系，因此尽可能做出最佳决策非常重要。为了帮助您做出这些决策，我们提供了三种决策分析方法。这些方法是我们之前在风险讨论中首次引入的直觉方法、利弊比较，最后是严格的决策矩阵，其中涉及我们计算每个权衡分数的公式。尽管我们承认由于不可知的因素，不可能有正确的答案，但通过严格的分析和数据驱动的决策可以得出最佳答案。 As we consider the actual decisions made on the tradeoffs to balance cost, quality,speed, and scope as well as the method of analysis used to arrive at those decisions,the fit within your organization at this particular time is most important. As yourorganization grows and matures, there may be a need to modify or augment theseprocesses, make them more formal, document them further, or add steps that custom-ize it more for your needs. For any process to be effective, it must be used, and for itto be used, it needs to be a good fit for your team. 当我们考虑权衡成本、质量、速度和范围的实际决策以及用于做出这些决策的分析方法时，您的组织在这个特定时间的适合度是最重要的。随着您的组织的发展和成熟，可能需要修改或增强这些流程，使它们更加正式，进一步记录它们，或者添加更多定制步骤以满足您的需求。任何流程要有效，就必须使用它，而要使用它，它必须非常适合您的团队。 #####Key Points 关键点 * There is a classic balance between cost, quality, and speed in almost all businessdecisions. * 几乎所有业务决策中都存在成本、质量和速度之间的经典平衡。 * Technology decisions, especially in the product development life cycle, must bal-ance these three constraints daily. * 技术决策，尤其是产品开发生命周期中的技术决策，必须每天平衡这三个约束。 * Each project or feature can have a different allocation across cost, quality, andspeed. * 每个项目或功能可以在成本、质量和速度方面有不同的分配。 * Cost, quality, and speed are known as the Project Triangle because a trianglerepresents the equal importance of all three constraints. * 成本、质量和速度被称为项目三角，因为三角代表所有三个约束的同等重要性。 * We describe a circle that cannot quite fit over the entire Project Triangle as theAllocation Circle. This demonstrates the challenge of having to select equalweighting to all but not complete coverage of any, or a skewed allocationheavily geared toward one or the other constraints. * 我们将一个不能完全覆盖整个项目三角形的圆描述为分配圆。这表明必须对所有因素选择同等权重但不能完全覆盖其中任何一个，或者严重针对一个或其他限制的倾斜分配是一项挑战。 * There are short- and long-term ramifications of decisions and tradeoffs madeduring feature development. * 功能开发过程中做出的决策和权衡会产生短期和长期的影响。 * These tradeoffs made on individual features can affect the overall scalability ofthe entire system. * 这些对各个功能的权衡可能会影响整个系统的整体可扩展性。 * Technologists and managers must understand and be able to make the rightdecisions in the classic tradeoff between speed, quality, and cost. * 技术人员和管理人员必须了解并能够在速度、质量和成本之间的经典权衡中做出正确的决策。 * There are at least three methods of performing a tradeoff analysis. These are gutfeel, pro/con comparison, and decision matrix. * 至少有三种执行权衡分析的方法。这些是直觉、赞成/反对比较和决策矩阵。 * The risk of the project should help decide which method of tradeoff analysisshould be performed. * 项目的风险应有助于决定应执行哪种权衡分析方法。 * A set of rules to govern which analysis method should be used when would beextremely useful for your organization. * 一组规则来控制何时应使用哪种分析方法，这对您的组织非常有用。
没有评论