关于 “ 10X 软件 开发人员” 的 争论 很多——她（据称）可以完成 10 名普通工程师的工作。 

我对这场辩论最大的不满是，开发速度通常不是软件驱动型组织/软件开发项目失败的主要原因。与其使用速度，不如尝试使用更具战略性的衡量标准——例如“有效地交付客户想要的软件”。然后很容易看出，一些组织在这方面的表现比一般组织好 10 倍以上。  在本文中，我将这类组织称为10X 组织。

本文适合那些曾经想知道为何其组织交付软件的效率远低于最佳组织的人，以及他们如何能够通过组织中的特定组织、流程或人才改进来获得竞争优势。

首先我们来谈谈为什么我们有 10X 组织/为什么前 10％ 和平均水平之间的效率差距很大。

简而言之，这是因为我们终于发现软件有多么棒 — — 它具有如此快速的可塑性 — — 但我们还不了解如何控制我们最糟糕、最懒惰的冲动，以便有效地构建。

值得我们回想的是全瀑布式软件开发时代，那时我们开发软件就像建造建筑物一样。在那些日子里，我们不断规划，不断规划，然后建造、建造、建造，最后我们得到了一些可以按照设计运行的东西。

但说实话，这实在是一种平庸的建造方式。任何设计和建造过房屋（甚至是厨房改造）的人都可以列出许多他们希望以不同方式完成的事情，无论他们花了多少时间进行设计和进行 3D 演示等。

软件的伟大之处在于——与建筑施工相比——你可以更便宜、更快速地对软件进行更改。因此，我们开始学习如何迭代开发软件，边做边学，这就是我们现在统称为“敏捷”的过程。

我们还了解到 敏捷使一些 事情变得更加困难——更容易出现过度设计，更容易在原始假设改变时产生技术债务，太多的诱惑让人根本不做任何规划。

我们尚未集体认识到敏捷对组织最高战略层面产生的负面影响。

换句话说，我们现在基本上明白了敏捷在战术/技术层面很容易出错，如果我们不断改变需求，我们最终会得到一堆技术债务和一堆乱七八糟的代码。我们中的一些人甚至已经了解到，如果我们实际上提前做了大量的规划，敏捷会发挥最佳效果——至少在开发开始前几周就设定好路线图，而不是在开发人员编写代码时试图编写故事。

但与我交谈过的绝大多数高级管理人员还没有意识到，敏捷让这些管理人员在做出艰难选择和设定重点时变得非常懒惰。

结果似乎是，组织的目标非常包容——我们将满足所有人的需求！” 这听起来像是一种美德，但其实不然。敏捷被用来作为实现短期目标的借口，而高级管理人员唯一的优先事项就是派出大批人员去解决最紧迫的问题。 因为软件！因为敏捷！

现实情况是，成功的组织（和高管）总是在做出艰难的选择并设定重点 — — 尤其是设定的重点不是 2-3 周，而是几年后。敏捷很棒，但如果你自己没有清晰的愿景，并且员工没有协调一致并专注于实现这一愿景，敏捷就无法让你得到你想要的东西。

本文的其余部分描述了任何组织为了有效交付软件需要遵守的关键约束——即使在敏捷时代。

要提供客户想要的软件，您首先需要了解 您的客户是谁 以及 您的软件为客户解决了什么问题。最有效的组织会让每个产品+开发团队都专注于一个客户，一次解决该客户的一个问题。

请注意，客户的定义可以涵盖大量人群，并且该客户群中可以有许多角色，但需要在整个客户群中保持同质性。一旦团队的注意力分散到具有不同问题（或需要以不同方式解决问题）的不同客户身上，您就等于判处团队制造出具有完全冲突的指导方针的平庸产品。

10X 组织不仅让各个团队专注于一个客户、一个问题（每次），而且还与客户保持密切联系。这就是为什么许多人开始谈论“客户开发”而不是“产品开发”的原因之一；前者需要密切的客户联系，而后者通常是一位高管，她根据相对较少的客户互动，认为自己了解客户。

关于如何正确进行客户开发的一个很好的指南是 Cindy Alvarez 的 《精益客户开发》。

当今之所以有这么多优秀的软件开发工具，而用于建筑施工的工具却如此糟糕，原因之一是，开发软件开发工具的软件开发人员 是 客户，他们所解决的问题既痛苦又真实。

但一般的公司开发软件是为了解决公司中没有人遇到过的问题 — — 并且他们 最好依靠从销售到产品负责人再到产品再到工程的低带宽电话沟通。最坏的情况是，它主要依靠事实上的 产品负责人（可能是 CEO）与客户行业中各种高层人士（可能不是软件的目标用户）进行的 5-10 小时的对话 。

我听到的针对“一个客户/一个问题”观点的常见反对意见如下：

• 我们正在构建一个平台，因此我们必须同时为多个客户解决多个问题
• 我们正在建立一个市场，所以我们必须同时为多个客户解决多个问题
• 我们正在开发一款实用产品，可以同时为许多不同的客户解决相同的基本问题

这些都是错误的反对意见，我还没有看到任何公司尝试用一个团队同时为多个客户解决多个问题，而且是高效且成功的方式。如果你能用如此分散的注意力取得重大成功，那么你的竞争对手就真的无能了。

对于第一种情况——“我们正在构建一个平台”——最好的解决方案是从通过一个客户解决所有问题开始。例如，我以前为建筑部门构建过 SaaS，这是一个平台：建筑文员使用它来处理许可工作流程；建筑官员使用它进行报告和管理；建筑承包商使用它来申请许可/检查、支付许可/检查费用、检查许可/检查状态；房主使用它来查看他们自己/他们有兴趣购买的房屋的许可历史记录。

人们非常强烈地要求我们平等地考虑每一个客户和他们的问题，但要想得到适当的采纳，更好的选择是问：“谁是我们成功的最重要客户，我们如何通过 该 客户看待其他每个利益相关者？”

答案是将建筑官员视为第一个也是唯一的客户（最初），因为建筑官员决定平台是否真正启动和运行。请注意，这也是 Salesforce.com 做出的基本选择——第一个客户是销售 经理，而不是销售人员，而这基本上仍然是 Salesforce 的主要客户。 只要问问任何销售人员，Salesforce 使用起来有多容易/多快！

第二种情况——“我们正在建立一个市场”——实际上可能要求组织处理两个不同的客户和两个不同的问题——但团队应该是分开的，两个团队都应该被视为在开发不同的产品。因此，每个产品都有一个客户和一个问题。

许多非技术高管会认为这里的团队需要合并“因为他们都在处理相同的代码”，但这就像说两个团队需要合并一样，因为他们都在同一间办公室，都使用笔和纸。如今，我们非常了解如何设置自动化测试、代码审查、API、分支/合并、持续集成等，因此不同团队与类似代码交互并不那么困难。

虽然在实践中，一个市场应该很容易拥有两个完全独立的代码库——看看 etsy、ebay、cdbaby 等——但它们为买家和卖家提供不同的部分，只需要让他们的设计师使用相同的样式指南和在网络服务器/代理级别的智能路由。

最后，在第三种情况下——“我们正在开发一款拥有大量不同用户的实用工具”——除非你从一位用户开始，否则你开发的产品对任何用户来说都不是特别好用。如果他们都足够不同，以至于想要单独讨论，而且他们的问题都略有不同，那么试图为某种综合平均值构建产品意味着你正在构建一款平庸的产品，它实际上并没有以他们想要的方式解决任何人的问题。

这意味着您的竞争对手会通过一次挑出一个客户/问题来击败您。例如，想想 Instagram 如何从更通用的社交分享 Facebook 手中夺取社交照片分享，或者像 TaskRabbit 和 Guru（甚至 Craigslist）这样的通用自由职业者市场如何大量流失到更具体的市场，如 Rent-a-Coder、Rover、HomeAdvisor 甚至 AirBnb。

因此，在开始任何类型的产品或软件开发流程（更不用说人员）之前，您需要问自己是否对客户和问题具有独特的关注和清晰的认识，从而能够组建一个取得成功的产品+开发团队。

在您拥有一个客户和一个问题之后，您需要一个产品所有者，其唯一职责是确保您正在开发的解决方案能够为客户解决问题。

这项工作包括三个主要活动：（a）对应用程序、其工作方式及其随时间的发展有一个连贯一致的看法；（b）主动获取来自客户、潜在客户、项目开发人员和其他人的反馈，以继续修改应用程序的路线图；（c）不断与设计师、开发人员、产品 / 项目经理以及所有参与应用程序开发的人沟通，帮助他们了解应用程序的发展方向，并验证投入到产品中的所有工作是否都在将其引向需要的方向。

担任产品负责人几乎总是一份全职工作。如果产品负责人除了上述事项外还做其他事情，除非您有一支简陋或兼职的开发人员队伍，否则您的产品就没有有效的负责人。如果您有多个人在做上述事项，而且他们可以互相推翻（或者一个人偶尔检查一下——比如首席执行官——并直接与开发团队推翻表面上的产品负责人），那么您将拥有一个不连贯/不一致的路线图，并且您将拥有过长且低效的开发周期 。

请记住，您正在尝试利用从客户和敏捷软件开发中获得的良好反馈周期，这使您能够不断进行更改，以找到问题的最佳解决方案。产品所有者的全职工作是：确保大量反馈被采纳、综合、转化为路线图、传达给设计/开发团队，并在开发完成后进行验证/接受。没有好的方法可以将创建和传达此路线图的责任分散给所有需要执行的人。

这里有一个关于单一产品负责人的推论：允许产品负责人犯错极其重要。责任越大，权力越大，否则就不可能履行责任的要求。

如果您有一个客户和一个问题，并且您有一个允许犯错的产品所有者，并且她可以花费所有的时间思考下一步该如何为该客户解决该问题，那么您很可能已经远远领先于当今开发软件的普通组织。

即使您的软件开发流程和人才低于平均水平，您也可能比竞争对手更成功地为客户解决该问题，因为领导力的专注和清晰度可以带来巨大的好处。

但是，在其他条件相同的情况下，即使只有一个客户/一个问题/一个产品所有者，一个组织在拥有合适人才的情况下仍然可以比另一个组织高效执行 10 倍以上。

当您纯粹着眼于 10X 工程时，有一件事比其他任何事情都重要：利用现有服务，这样您就不必自己构建它们。没错 — 有点不直观的是，区分最好、最快、最高效的工程组织的东西是他们实际编写的代码量有多小。

他们编写的代码并不会比平均水平更快，甚至也不一定比平均水平更好。他们编写的代码更少，因为他们利用了现有的代码。

迄今为止，关于这一概念最好的文章可能是 风险投资家 a16z 的一篇博客文章，其中问道：“我们还要多久才能收到一份针对只有一名工程师的初创公司的 10 亿美元收购要约？”

然而，几乎无论我走到哪里，即使我带来了可以大大减少开发时间、必须编写的代码量以及保持生产顺利进行的操作需求的技术，我还是会遇到极大的阻力。

例如，  Algolia 是一项很棒的服务——它本质上类似于 ElasticSearch，但速度更快，并且具有通常需要工程师编写代理来位于 ES 前面的所有功能（例如，限制来自 SPA 的调用速率、限制返回哪些数据以确保安全等）。但当我为某个组织在 Algolia 中构建 POC 时，我收到的最常见的回应是他们在 ElasticSearch 中重新实现了该功能。

为什么？ 因为他们了解 ElasticSearch。因为他们可以想出一些 Algolia 比 ElasticSearch 更糟糕的方法（例如，动态排序顺序），即使这些方法对路线图来说并不重要。因为没有人围绕这些 10X 概念以及组织如何从拥有外包到服务优先的工程视角中获得实质性的业务利益来组织工程功能。

10X 工程的默认规则是：如果有一种服务在初次使用时能够“足够好”地完成工作，那么即使它可能不足以满足长期使用，您仍然应该使用它。

进入市场并证明产品与市场契合度是解决客户问题的关键风险。 大多数软件项目失败的主要原因是，在企业资助开发的能力/意愿耗尽之前，它们没有达到产品与市场的契合度。

一旦弄清楚了为什么许多其他组织使用的服务无法满足您的客户需求，您就可以随时推出自己的搜索服务/图像服务/身份验证服务/pdf 处理服务。与此同时，进入市场 — 您可能会发现您对客户需求的假设是错误的！

如今，无服务器应用程序架构的优势被大肆炒作，但它们成为默认架构只是时间问题（以及更好的工具和更好地理解正确的架构模式）。

但与 10X 组织更相关的是一些“服务型”开发所称的内容。我在第一次 Serverlessconf 上介绍了使用大量服务的经验和建议（幻灯片、 视频）。Mike Roberts 在 Martin Fowler 网站上发表的关于无服务器的文章 简要提到了这一点，称之为“后端即服务”， 我认为这只是其中的一部分。

因此，总而言之，那些比一般组织快 10 倍/更好地交付成功软件的组织之所以这样做，是因为他们遵循以下原则：

对于每个产品+开发团队：

• 一位顾客
• 一个问题
• 一名产品负责人</