谦逊与数字化转型 (Humility and Digital Transformation)

原著: Mark Schwartz

译者: 金毅 (Lucy)

～～～～～～～～～～～～～～～～～～

译者按：我关注Mark Schwartz源于2017年SAFe峰会的一个演讲《Measuring Business Value》，演讲者推崇Mark书里对业务价值的定义。我也感觉到《业务价值的艺术》这书名就是一种睿智的隐喻。

维基百科对ART的定义如下：

Art refers to works of creative expression, and also to a skill, a learned applied technique.

艺术是指创造性表达的作品，也是指一种技能，一种学以致用的技术。

今天又恰好在《傅雷家书》里面看到了诠释“艺术”的一段话：

跟着你痛苦的童年一起过去的，是我不懂做爸爸的艺术的壮年。幸亏你得天独厚，任凭如何打击都摧毁不了你，因而减少了我一部分罪过。

可见，艺术即是一门技术，又需要领悟力和创造力，可谓是一种深层次的修为和造诣。下面就让我们读一读《业务价值的艺术》的作者于2018年9月发表的一篇文章，像是谆谆教诲，而不是冰冷的理论。

同时我在Linkedin上了解了一下Mark的背景，他从2017年7月起担任亚马逊的企业战略顾问，与全球电商巨头的高管们合作，帮助他们制定战略，克服进入数字时代的障碍。他经常在各种会议上就创新、成为一个“面向未来”的组织、将敏捷和DevOps应用于企业IT、克服信任度低和官僚主义环境等话题发表演讲。他是AWS云企业战略博客的主编，这是一个面向高级管理者，领导企业进入数字化未来的思想领袖博客。

Mark已出版两本书，2016年《The Art of Business Value》，2017年《A Seat at the Table: IT Leadership in the Age of Agility》,正在预售《War & Peace & IT: Business Leadership, Technology, and Success in the Digital Era》。

～～～～～～～～～～～～～～～～～～

You might say that humility is the essence of digital transformation.

你可以说谦逊是数字化转型的本质。

In the digital world, we are willing to be surprised and to learn. In the old days, we relied on a plan—prepared in advance—to guide our activities. The plan was made by someone, or some collection of someones, who knew enough to specify what needed to be done over a longish period. But in a world dominated by uncertainty, in a world in which none of us knows all there is to know about our customers, about the users of our IT systems, or about what will change in our competitive or regulatory environment, how can someone presume to put together a plan that will surely deliver business value? To do so seems more and more an act of hubris. Have we never been surprised by the market reaction to our products or by the way users used our software?

在数字世界里，我们都向往惊喜和学习。而在过去，我们往往依靠事先准备好的计划来指导我们的活动。这个计划是由某个人或某些人的集合制定的，他们知道足够详细的信息，知道在一个较长的时期内需要做什么。但是，在一个由不确定性主导的世界里，在一个我们都不知道所有关于我们的客户、我们IT系统的用户，或者我们的竞争或监管环境将发生什么变化的世界里，怎么能有人假定制定出一个确实能交付业务价值的计划呢？这样做似乎越来越成为一种傲慢无知的行为。我们是否从未对市场对我们产品的反应或用户使用我们软件的方式感到惊讶呢？

In The Lean Startup, Eric Ries describes product development as a learning journey where the company tries out a business idea with a minimal viable product (MVP), gathers feedback from the market, changes its design based on that feedback, and repeats this process over and over. The goal is to maximize learning early in the process: to get something into the hands of customers and be prepared to be surprised by their reactions. At any given moment, Ries says, the company should have two hypotheses in mind: a value hypothesisabout what product and product attributes will create value for the customer, and a growth hypothesisabout how the product will be able to ramp up its sales or usage. Each of these hypotheses is just that—a hypothesis, something that must be confirmed or disproved through experimental evidence.

在《精益创业》一书中，Eric Ries将产品开发描述为一个学习之旅，在这一过程中，公司用最小可行产品（MVP）尝试商业理念，收集市场反馈，根据反馈修改设计，并反复重复此过程。我们的目标是在这个过程的早期阶段最大程度地学习：将一些东西交到客户手中，并准备好对他们的反应感到惊讶。Ries说，在任何特定的时刻，公司都应该牢记两个假设：价值假设是关于什么产品和产品属性将为客户创造价值，而增长假设是关于产品如何能够提高销量或使用率。这些假设中的每一个都只是一个假设，一个必须通过实验证据来证实或否定的假设。

This is a process founded in humility. The startup—even if it is filled with experts on the target market or the industry—admits that its ideas are only conjectures, and that in order to serve a market, it must learn from that market. Periodically, the team decides whether to persevere with its current strategy or to pivot to another direction. The arrogance of old school product design—the idea that a marketing or product expert knows enough to define a product that can then be “marketed” or pushed out to customers, seems increasingly out of touch with business reality.

这是一个建立在谦逊之上的过程。这种创业，即使是充满了目标市场或行业的专家，也要承认它的想法仅仅是猜测，而且为了服务市场，它必须从市场中学习。团队定期决定是否坚持当前的策略，还是转向其他方向。老派产品设计的傲慢态度在于——一个营销或产品专家因足够了解情况而定义了一个产品，然后就可以“营销”或推出给客户，这种想法看来是越来越脱离商业现实了。

Ries’s principles do not just apply to startups or to products created for an external market. Even for IT applications intended for use within the company, an attitude of humility is necessary. When a part of “the business” approaches IT with a set of requirements, those requirements are simply a set of IT capabilities they believe will accomplish a particular business objective. The business objective is the real…well, objective, while the requirements themselves are someone’s view of how to achieve the objective. The writer of the requirements has an unstated, and often unacknowledged, hypothesis.

Ries的原则不仅适用于初创企业，也适用于为外部市场打造的产品。即使是打算在公司内部使用的IT应用程序，也必须保持谦逊的态度。当“业务”的一个部分需要IT实现一组需求时，这些需求只是他们认为能够实现特定业务目标的一组IT能力。业务目标是真正的……嗯，目标，而需求本身就是某人对如何实现目标的看法。需求的作者通常带着一个未声明的，未确认的假设。

People who participate regularly in IT initiatives are constantly surprised by what happens when new IT capabilities are actually rolled out. When I was CIO at US Citizenship and Immigration Services (USCIS), we developed a new, streamlined, all-digital process to speed up adjudication of I-539 applications, applications non-immigrant visitors to the US use to change their status. When adjudicators began using the new process, we discovered that it actually caused processing time to increase from fifteen minutes to over an hour. Yet that process had been designed by user interface experts working with adjudicators and their managers, and the system had been built precisely according to their requirements—and tested. For the same reasons that a startup needs to validate its designs through minimal viable products and customer feedback, a company creating an internal system to accomplish a business objective must test the assumptions behind its requirements.

通常参与IT规划的人总是对新的IT功能实际推出时所发生的事情感到惊讶。当我在美国公民和移民服务局（USCIS）担任CIO时，我们开发了一个新的、流程化的全数字流程，以加快对I-539申请的裁决，并用于改变美国的非移民访客申请的状态。当调解员开始使用新的流程时，我们发现它实际上导致了处理时间从15分钟增加到了一个多小时。然而，这个流程是由一些用户界面专家与裁决者及其管理者们合作完成的设计，并且该系统是根据他们的需求精确构建并测试过的。出于同样的原因，初创公司需要通过MVP和客户反馈来验证其设计，而通过创建一个内部系统来实现业务目标的公司，也必须测试其需求背后的假设。

Each time someone translates a business objective into a requirement, they have added risk—namely, the risk that that particular requirement will not actually accomplish the objective. The only way to manage that risk is to treat the requirement as a hypothesis, test it, and then modify it as necessary. It is arrogance that leads us to label the hypothesis a “requirement,” and it requires humility to accept that your requirement might need to be modified, even if you are paid to be an expert.

每当有人将一个业务目标转化为一个需求时，他们都会增加风险，也就是这个特定的需求实际上无法实现目标的风险。管理这种风险的唯一方法就是将需求视为一个假设，测试它，然后根据需要修改它。正是傲慢导致我们把假设称为“需求”，而它需要你谦逊地接受，你的需求可能需要修改，即使你是作为一名专家被付钱的。

After seeing this sort of thing happen again and again, we introduced an IT framework at USCIS where software development was driven directly by the business objective itself. Rather than being presented with a set of requirements to implement, the delivery team—including both technical and business folks—was given a business objective to accomplish. They formulated their own hypotheses about what to deliver to meet that objective, tested their hypotheses, and pivoted based on what they learned.

当看到这种情况一次又一次地发生之后，我们在USCIS引入了一个IT框架，软件开发直接由业务目标本身驱动。交付团队（包括技术人员和业务人员）不是被动承接一组要实现的需求，而是被赋予要实现的业务目标。他们给自己制定关于如何实现目标的假设，然后测试他们的假设，并以他们所学习到的知识为基础。

Humility doesn’t only apply to requirements and product design, it also applies to how managers interact with their employees. With the development of agile IT techniques came an interest in servant leadership, the idea that managers exist to support their employees and remove impediments for them. Since employees are delivering the value-adding product, managers need to provide the conditions under which the employees can do so efficiently and at a high level of quality. Employees frequently run up against obstacles when they are trying to deliver value—bureaucratic rules, subject-matter experts they need to talk to who are unavailable, or even the inability to book rooms for meetings or get access to other needed resources. The job of servant leaders is to quickly make impediments disappear. It takes humility to acknowledge that your employees are the ones creating value, and that your role is to make them successful.

谦逊不仅适用于需求和产品设计，也适用于管理者如何与员工互动。随着敏捷IT技术的发展，人们对服务型领导产生了兴趣，认为管理者的存在是为了支持他们的员工并为他们消除障碍。由于员工负责交付增值产品，管理者则需要提供条件，使员工能够高效、高质量地完成这些工作。但是员工常常在交付价值的过程中遇到各种障碍，比如官僚制度，需要交流的领域专家不到位，甚至无法预订会议室或获取其他所需的资源。服务型领导的工作是迅速消除障碍。谦虚地承认你的员工是创造价值的人，而你的职责就是让他们成功。

Humility is also important for managers trying to stimulate innovation in their organizations. What happens when an employee approaches his or her manager with a new idea? Does the manager try to poke holes in it—“Did you think of this? Did you think of that? How about this? Did you make sure it’s okay with Igor? Did you project revenues? How do you know your projections are right?” We have been taught that managers are supposed to know more than their employees, and that they should avoid risk by weeding out bad ideas. But this is no way to stimulate innovation.

谦逊对于组织中激励创新的管理者也很重要。当一个员工向TA的经理提出新想法时会发生什么？经理是不是想在里面钻个洞？—— “你想过这个吗？你想过那个吗？这个怎么样？你确定Igor没事吗？你计划营收了吗？你怎么知道你的预测是正确的？” 我们被教导，管理者应该比他们的员工了解得更多，他们应该通过剔除坏主意来规避风险。但这根本无法激励创新。

For a humble manager, there is a better way to reduce risk. The manager can assume that he or she doesn’t know whether the idea will turn out to be a good one, and instead work with the employee to find a way to quickly and inexpensively test the idea. The manager can coach the employee on finding a good, minimal test, and what success would look like. Then, once the test is conducted, the manager and employee can agree on whether the idea is promising or not.

对于一个谦虚的经理来说，有更好的方法来降低风险。经理可以假设TA不知道这个想法是不是会变成一个好主意，而是与员工一起寻找一种快速而廉价地测试这个想法的方法。经理可以指导员工找到一个好的、最少测试方法，以及成功会是什么样的。然后，一旦测试完成，经理和员工可以就这个想法是否有希望达成一致。

DevOps was created to support this humble approach to delivery. A DevOps team tries to reduce lead times for getting capabilities to production so that they can get fast feedback from users. Feedback, by the way, is not necessarily verbal feedback from asking customers what they like. More commonly, it is quantitative measures relating to goals the company has established.

DevOps的创建就是为了支持这种谦逊的交付方法。DevOps团队试图缩短上线的交付时效，以便从用户那里获得快速反馈。顺便说一下，反馈不一定是询问客户喜欢什么的口头反馈。更常见的是，它是与公司制定的目标相关的定量措施。

The cloud also helps enable this way of working. With the cloud, it is easy for the enterprise to create a quick MVP and then iteratively refine it. The cloud mitigates risk, because any infrastructure or services that have been provisioned can quickly be de-provisioned if an idea doesn’t work. The cloud makes the DevOps processes of continuous integration and continuous delivery possible and lets the company put in place security, compliance, and reliability guardrails, which then let that company experiment at high velocity.

云技术也有助于实现这种工作方式。使用云技术，企业很容易创建一个快速的MVP，然后迭代改进它。云降低了风险，因为如果一个想法不起作用，任何已提供的基础设施或者服务都可以很快被取消。云技术使持续集成和持续交付的DevOps过程成为可能，并把公司置于安全、合规和可靠的防护栏之内，然后让公司开展高速的实验。

Is it surprising that Lean and Agile IT require humility? Or that today’s uncertain and rapidly changing business environment demands it?

精益和敏捷需要谦逊，这令人惊讶吗？或者说，当今的不确定且快速变化的商业环境需要它？

We have always thought that managers and experts should know what their markets want. But in a business environment of uncertainty, complexity, and rapid change, where customers, regulators, and even nature are full of surprises, it should come as no surprise that humility can improve a company’s competitive position, facilitate innovation, and help build relationships with customers.

我们一直认为管理者和专家应该知道他们的市场需要什么。但是，在一个充满不确定性、复杂性和快速变化的商业环境中，客户、监管者甚至大自然都充满了惊喜，只有谦逊可以改善公司的竞争地位，促进创新，并帮助建立与客户的关系，这就不足为奇了。