如果要创造一个软件产品，我们现在是怎么做的？

很可能你会先组织进行可行性研究，包括分析市场环境，在纸上算算未来可能的成本和收益。如果技术上也可行，那么就写一份漂亮的商业计划书，编织出美好的数据来说服管理层和财务部门拿到一大笔预算，成立项目。项目启动后首先将需求详细写出来，在正式动工开发之前可能就已经过去了几个月甚至更久。之后负责方案设计的业务分析人员将详细方案文档交给公司的软件开发部门或外部供应商来实现，最后开发团队将软件包交接给一个专门的运维部门部署维护，并提供用户支持。

这就是现在在大多数企业的做法。不仅仅流程冗长，组织结构往往也是按业务，开发，和运维划分成不同的职能机构，大大拉长了一个想法从提出到交给用户的周期，常常错过投入市场的最佳时机；现实中业务人员对于用户到底需要什么、喜欢什么经常产生误判，在这种模式下提前数月制定的大计划就会导致大量浪费；以范围、成本和进度为中心的交付管理使得所有人都迷失了，似乎项目交付就是目的，而忽视了投资本身的初衷是要达到的用户和业务目标，更谈不上持续创新。图 Figure 1 展示了这样一种传统结构：

Figure 1 阶段化的项目模式

这种项目化的传统模式带来的问题不仅于此。由于开发阶段和维护阶段往往由不同的职能部门负责，在成本上也是分开计算，开发人员往往不会很认真考虑运维因素，可能给系统增加不必要的复杂性，例如引入过度异构的设计或难以理解的数据结构，这导致运维成本增高，然而这些问题却反映到不到设计和开发阶段，组织很难看到围绕一个产品实际产生的所有成本；当生产环境出现问题，只有运维人员苦命地 24 小时待命，找到快速恢复的办法，而开发人员却可以心安理得地留下系统低质量和不稳定的风险。

以产品为中心的模式

现代科技企业所面对的竞争环境越加激烈，用户和市场的变化迅速，要能够快速适应变化，真正创造用户喜爱的，有竞争力的产品，并持续创新，需要告别以往多年以项目为中心的管理，建立一种以产品为中心的软件交付模式。也就是说，组织的投资决策与治理结构要支持团队解决问题，而不是交付项目，这是建立高适应力、持续创新的精益企业的核心原则之一。组织创造产品的目的就是要解决用户或组织自身（也就是内部用户）所面临的问题，因此以产品为中心，也就是以解决问题为中心；而相反，以项目为中心的则是以计划、预算和职能为中心。

那么要以产品为中心，组织需要在哪些方面做出改变呢？

首先，以产品为中心，要求管理的核心要素从项目的范围、时间和成本转向给用户带来的实际价值和质量。现在很多软件项目的管理者都有类似 pMp 这样的认证，对如何在范围、时间和成本这三个因素之间周旋很有经验。甚至一些项目管理者几乎全部的工作就是计算各种 pV，EV，SpI，CpI 值，通过加人减人、加班等方式来保持项目在计划和预算之内，却忽略了最最重要的事情：团队忙于添加的特性到底有没有价值？解不解决问题？

价值是产品的最核心要素，然而这在传统的项目管理指南中基本看不到对它的关注。由于人的本能，那些提出需求的人（如用户或业务部门）往往提出来的是他们认为的解决方案，而交付团队可能连真正要解决用户什么问题都没搞清楚，只将其视为需要完成的一项任务。管理工作围绕价值开展就需要管理者将最多的关注放到对用户的分析和对工作的优先级排序。

具体的方法包括与用户和各种干系人一起确立明确的愿景，对目标用户群进行识别和特征分析，找到评判一个想法优先级高低的标准，设计可以验证假设的实验；在交付过程中管理好团队的在制品数量，确保集中精力将最高优先级的特性快速交付并获得真实的反馈，从而更好地决策产品方向。

正因为围绕价值进行管理至关重要，在以产品为中心的组织中更加强调产品经理的角色，而非项目经理。产品经理或产品负责人是一个团队实际的决策者，决定产品的方向和策略，对价值负责。即便仍存在项目经理，也只能是一个辅助性角色。

另一方面，虽然每个人都口口声声质量很重要，但时间、范围和成本往往都在前期的承诺中被固定了，对任何一项预先计划进行调整都需要复杂流程，而且会被视为管理者工作做得不好。当管理者努力要保障一切按计划行事，那么很自然质量这个隐性因素就成为二等公民被牺牲了，团队加班加点，或临时增加人手，降低上线质量标准。而且软件有其特征，很多质量问题是无法通过功能验收测试来发现的，设计和代码的恶化很隐性。要以质量为核心，就需要管理者在团队内建立普遍的质量意识，提升团队的工程实践能力，提升自动化水平，形成持续改进的团队文化，而不仅仅是完成功能。

范围、时间和成本的管理并非不重要，但在以产品为中心的管理模式下这些因素只是我们交付产品的制约因素，相对于更重要的价值和质量，这些制约因素需要不同的处理方式。如图 Figure 2。

Figure 2 价值、质量与约束

第二，组织要形成围绕产品，也就是围绕业务的组织结构。传统按职能划分的组织导致了不同职能不一致的目标，比如业务部门以市场效益为目标，而 IT 交付部门则以交付产能为目标，却忽略业务价值，运维部门以系统稳定性为目标，而阻碍快速频繁变更。我们需要打破这种职能化的筒仓式结构，建立由业务、设计、开发和运维等多种技能人员共同构成的跨学科跨职能团队，最好能够同一地点办公，紧密协作。为用户交付高价值、高质量的产品应该是所有成员共同的目标，基于共识来驱动所有人的工作步调一致。如图 Figture 3：

Figure 3 产品化的组织结构

有些较为成熟的组织建立了一种矩阵式的结构，即既有以职能为中心的纵向部门，也有以产品为目标的横向组织，但总得来说还是职能为实，产品为虚，员工的绩效考评掌握在职能部门领导手中。常常能看到职能部门在各产品间随意调动人员配置，破坏了产品团队的稳定性、凝聚力和业务知识积累；而且这种强矩阵式结构大大增加了组织的管理消耗，容易导致企业走向一种管理导向文化。而有适应力和持续创新的精益企业更需要一种技术导向的文化（或有些称为工程师文化）。在以产品为中心的组织中产品维度的管理应当为实，而职能方向更像是一种社区，以技能分享和发展，人员培养为主要目的。

在以上组织结构的调整中，最重要的一点就是要让协作的跨职能团队具有一致的目标，以相同的标准来衡量工作表现。不能是以各个职能各自的产出来衡量，比如以需求说明书书写的质量来衡量业务分析人员表现，以完成的需求量来衡量开发人员表现，以发现的缺陷数来衡量测试人员。而应当以产品团队整体交付的价值和质量来衡量，比如用户满意度，用户问题数，业务目标达成等，整个团队责任共担。

运维在很多企业都是一个集中式的部门，负责所有 IT 系统的运行，很多人对运维工作的印象就是繁琐而无趣，大量人工操作，复杂的发布流程。然而随着技术进步，这些都在发生变化，可以通过自动化的部署，监控和基础设施配置以及采纳云计算来大大降低运维难度，使得产品团队可以自助地完成大多数运维工作，将传统集中式的运维人员解放出来，专注于建设数据中心和自动化运维平台，比如组织级的 IaaS/paaS 平台。

第三，应以产品的实际用户和业务成效来衡量进展和表现，而不能基于计划和预算的达成情况来衡量。计划只是一种预测，在不确定和追求创新的场景下计划随时都会改变；预算支出也不能说明我们在达成愿景的道路上已经取得了多少进展。用户成效是指产品确实解决了用户的问题，被用户所认可和喜爱；而业务指标是指产品在商业上取得了成功，为组织带来了预期的收益，这些指标才是我们对产品进行投资的目的，也只能以这些指标来衡量团队工作的进展。换句话说，如果团队在既定的成本内完成了计划的所有工作，然而上线的产品没有人愿意使用，等于没有任何进展，完全浪费。

这里以成效而非产出进行衡量是关键，有悖于一些人的认识。比如输出的文档，书写的代码行，交付的故事点数这些都是产出，产出量再高，如果没有用户、不解决问题则只会无谓地增加系统复杂度，提高运行和维护成本，有百害而无一利。如果所有人的工作都围绕能给用户带来最大价值的特性，以最短的周期发布出去，其带来的成效会远远大于一味地堆砌需求。只有所有成员（不仅仅是业务人员）都理解如何衡量成效，并以此进行考核，才能最大限度地激励每个人去思考最佳方案，而不仅仅是完成任务；而且以产品的成效衡量可以激励团队尽早和频繁地交付，尽早兑现价值。

要能够以成效来衡量进展，就需要我们在提出任何解决方案的同时也要明确如何来衡量该方案的实际价值。典型的例子比如互联网企业常用的用户活跃度，点击率，转化率，推荐率，以及在线反馈等；对业务系统也可以采用像日均处理量，处理成功率，处理周期，业务替代率，以及成本节省等指标。我们随时要牢记于心，任何方案在没有得到真实用户反馈之前都只是一个有待验证的假说。在新方案上线之前，我们还需要采用像A/B测试，金丝雀发布，特性开关等技术手段在安全受控的范围内收集线上运营数据，通过数据来验证假说，以数据为依据进行决策才是科学的，才能避免在决策过程中掺入过多职权或政治因素。

决策不仅仅关乎投资，也关乎停止投资。在有了数据为参考时，如果数据证明产品并不能达到预期的成效，团队可以随时停止在某个产品上的投入，转向其它更有价值的工作。而项目化模式下，往往都会执行到预期计划的项目结束时间点。

第四，以产品为中心意味着团队要对产品的全生命周期负责，而不是只对某一个项目阶段负责。既然各种技能人员都有了共同的目标，那么开发、运维等成员就需要尽早参与到需求分析与方案设计过程中，而不是仅仅接受前面阶段的产出；业务分析和设计人员也需要关心开发、运维的每个环节，确保自己的设计被正确地实现，并且第一时间收集到用户的反馈。每个人从自己的技能角度进行分析，提前发现问题和风险，产生尽可能最佳最简的方案，减少浪费，并跟进自己的工作产生的后续影响。

产品运营的工作直接和用户打交道，通过线上和线下的方式培养用户群，倾听用户反馈。但不少企业的运营由单独的运营部门执行，用户声音不能立刻传递给产品的设计人员，最多采用日报、周报的方式提供报表，而且这些报表里的数据既不聚焦，也不直观可视化。因此产品的业务和设计人员应该全生命周期负责，既要融入整个交付过程，也需要直接领导或参与运营工作，每天直接接触用户，才有可能产生移情，站在用户的角度对产品进行持续改善。

另一方面，团队成员要直接对产品的运维负责。由产品团队自主决策是否可以发布，并通过自助方式将新版本发布上线。然后团队需要随时解决线上出现的问题，比如分析师、架构师和开发人员采取轮流值守，一旦生产环境出现问题必须立刻响应，谁写的代码谁维护，保障系统运行的稳定性。这样的职责体系使得分析人员避免添加一些价值不高，甚至带来用户困扰的功能，提升用户体验；开发人员在写代码时会考虑是否带来运维问题，努力提高质量，主动简化系统，毕竟谁也不愿意周末因为一通电话跑到公司去解决紧急问题。

全生命周期负责的模式下，对团队成员的能力成长也更有利。每个人根据自己的兴趣和擅长可以较容易地接触到不同类型的工作，发掘自己潜力。这种模式下组织需要更多的T型人才，即在某一方面专精的同时也能承担多种职能的工作。越是在高不确定环境下工作的团队，越是创新的团队就越需要这种多技能的T型人才。（参考：http://wiki.mbalib.com/zh-tw/T型人才）

第五，建立一种以产品，或者说业务活动为中心的成本核算体系。在项目模式下，可能业务分析阶段的投入计入市场、业务部门的成本；开发团队的支出计入开发项目成本，可能是企业的资产或费用；而运维由于集中管理，往往一个人员同时支持很多产品，其成本很难对应到产品，只能通通计入运维成本，往往计入企业的运营费用。在这种模式下，很难看清楚围绕某个业务机会究竟付出了多少成本。

在以产品为中心的模式下，要将所有的成本尽可能归属到具体的产品，也就是业务活动。如果已经建立了跨职能的产品团队，并且对全生命周期负责，我们就能很容易地通过计算这个产品团队的成本来得到组织在某项业务上的投入。甚至各种公共资源的投入，比如数据中心一类的基础设施，也可以通过计算资源占用量等手段将其成本分配到各个业务产品。从而，产品团队的领导者和组织管理层就能够更加清晰地看到各项业务活动与成本的直接关系，看到真实的投资收益，从而更加科学地做出投资决策。

这种成本会计法就是 80 年代库伯和卡普兰教授所提出的作业成本会计方法（Activity Based Costing，参考：https://en.wikipedia.org/wiki/Activity-based_costing），其被证明是一种能够在不确定环境下支持创新的成本核算体系。然而尽管提出很多年，真正将其运用到实际的企业并不多，根本原因就在于大多数企业的职能划分过细，很难将业务活动的支出从各个细化分工的职能中合理地识别出来。要运用到 IT 行业的软件产品开发，就需要组织找到一种方法将市场、产品、开发、运维各环节的支出按业务活动区分开来，可能需要一些会计工具的支持。

最后，产品团队需要有足够的自主权力，根据实际的用户喜好和市场环境快速做出决策。在美国空军上将博伊德谈论关于在不确定环境下竞争的决策机制时（参考：https://en.wikipedia.org/wiki/OODA_loop），他强调隐式指引胜过显式指引。在企业里，显式指引就是所有的决策都由集中的决策机构自上而下以正式指令或遵循流程的方式来下达，而隐式指引则是身处竞争中的产品或业务团队根据事先明确的目标和当时的环境条件自主做出决策，而没有来自中央的正式指令。只要产品团队具备适当的能力，尤其是以用户为中心进行设计和进行安全的实验的能力，完全有可能找到比中央集中决策更加优化的解决方案，并且决策速度要快很多。

相反，在项目化的模式下，当面对突发的情况和环境变化时冗长的流程和分散的职能让进行实验和获得反馈的周期更长，会让决策束手束脚，进而错过机会。

具体来说，产品团队所需要的自主权力包括：

选用人的自主性，产品负责人能够雇佣具有必要胜任力并能融入协作的人出资决策的自主性，在一定的范围内，要为新发现的机会能够随时获得额外的预算，或停止投资，而不需要集中式的财务审批决定做什么不做什么的权力，在几个月之前作出的大的计划往往在团队获得更新的信息时，原来计划的范围或方案需要作出调整，这样的调整可以随时进行，不需要流程决定何时发布产品或特性的权力，团队可以频繁地随时自主策略将实验或特性发布给用户，这样的实验发布不需要冗长的审批流程

在越是追求创新和适应力的企业里，这样的权力下放会做得越彻底。像 Netflix，Etsy 这样的企业甚至开发人员都可以自己决定随时将代码变更推向生产环境。

在这个过程中，上层组织需要做的就是保证产品的所有决策符合组织的战略，与组织所要实现的目的和愿景是一致的，确保存在一种机制使得团队在决策出现错误时也是安全的，并在产品团队自身无法获得足够信息做出有有效决策时提供协助。

讨论团队自主性，除了治理结构上提供的授权外，不得不提到另一个限制因素，那就是系统架构。如果产品与产品之间，产品内的各个业务领域之间架构上耦合过高，我们就不得不在各团队之上建立一层额外的机构来协调彼此的进展，就必然会限制产品团队各方面的自主性。要消除这一层剥夺自主性的额外集中控制，就要求整个企业在软件产品的架构设计上合理地围绕业务建立系统，并在应用、数据和环境层面做到高度松耦合（关于系统架构与组织结构的关系更多论述参考康威定律，https://en.wikipedia.org/wiki/Conway's_law）。要做到这一点，正确的 SOA 和微服务架构模式是需要考虑的策略。

总结下来，以产品为中心具体体现在以下六个方面：

Figure 4 以产品为中心的六个方面

产品化模式的根本目的是要最大化产品价值。这里所指的价值体现在真正解决用户的问题，提供优秀的用户体验，并为企业带来持续客观的收益。

无论你的产品还处在需要通过实验来验证商业模式的阶段，还是需要通过丰富有价值的特性来规模化的阶段，都需要多种学科多种职能的人在高度一致的目标下紧密协作，让实验和特性能够持续频繁的交付并立即得到用户反馈。若真实的价值与预期不符，就立即做出调整，甚至放弃投资。这一目标的达成只有在组织的投资决策与治理结构以产品为中心的模式下才能做到最大化。

以上所描述的产品化模式不仅仅适用于为外部用户/客户提供的产品，也应当用于内部 IT 系统的开发。以往大量的内部 IT 系统都依靠长周期大笔的投资，并通过行政命令推行，这是造成这些系统普遍不受欢迎、不易用，却成本极高的根本原因。只有同样采用围绕业务、围绕产品为中心，通过实际的用户成效为衡量标准，提供给内部用户可选择使用或不用的权力，才有可能改变内部 IT 系统各种被人诟病的问题，最大化 IT 系统给组织带来的真实收益。

作者简介

姚安峰，ThoughtWorks 咨询师，08 年起开始致力于敏捷的践行和推广，理论与实践跨越敏捷、精益、持续交付和 DevOps 全流程各领域，帮助各行业客户将优秀的管理和技术实践与企业环境相结合，交付高价值、高质量产品，提升创新能力，推动持续改进。主导翻译了著作《精益企业》。

---

感谢张凯峰对本文的策划，感谢崔康对本文的审校。

济宁IT新闻