1. LeSS案例集
  2. Y Soft (中文)
YSoft Logo

Y SOFT的组织设计进化

Y Soft自2019年开始导入LeSS。与其他企业LeSS导入不同，Y Soft不仅实施了一系列重要的组织设计变革，而且它基于学习不断调整前期所做的变革。 正是这种动态调整，是企业达成自适应，并让Scrum或LeSS真正运作的前提条件。组织设计常常需要通过实验来不断学习和进化。因此，本案例的主题是LeSS之旅中组织设计元素的进化。

本文每个章节都描述了LeSS导入过程中组织设计变革的一次实验。每部分结构类似，如下：

  1. 背景
  2. 详述
  3. 检视：反思近期的组织设计变革
  4. 适应：调整变革

我（Mark - 主要作者）在Y Soft的LeSS导入中扮演的角色是在他们LeSS导入进行了整一年之后（2020年1月）作为唯一的外部咨询师提供LeSS导入的现场指导和改进。一年多后（2021年春天），我的工作转变为对Scrum Master提供支持和辅导（每周1-2天），Scrum Master则主要面向产品和团队，为他们提供支持，这种职责模式一直持续到2022年夏天。本案例讲述范围从2018年LeSS准备期开始，一直到2021年底。

本案例结束处的附录包含了一些有趣但次要的话题 - Y Soft在技术卓越上改进的相关实验，以及一些关键的准备事件。

Y Soft介绍

Y Soft是一家跨国软件与电子设备公司，成立于2000年，经营范围覆盖全世界。公司总部位于捷克共和国的布尔诺，在世界很多区域都设有办公室。其产品被全世界超过29700个客户所使用和喜爱，其中44%是全球500强企业。

Y Soft的产品开发主要集中在捷克共和国的布尔诺、布拉格和俄斯特拉发，在丹麦的哥本哈根也有一个120多人的研发队伍，大部分产品开发工作就在这几个地方。

YSoft World Map

产品

作为这个案例学习的背景，本章节介绍了Y Soft的产品SAFEQ，自2018到2021年底的LeSS导入覆盖了该产品。自那以后，Y Soft的产品投资组合发生了变化和拓展，Y Soft在2022年收购了EveryonePrint。与之相关的研发并不在本案例中体现。关于Y Soft和其产品的最新信息，请访问 ysoft.com。

SAFEQ针对不同的打印设备提供不同的打印管理方案。大型打印机供应商把SAFEQ安装在其设备上，与客户直接交互。对大部分客户来说，SAFEQ是无感的。

SAFEQ的客户与供应商遍布全球，他们的需求也因地方/国家战略或法规的不同而不同。因此，针对一个特性经常会有全球化实施还是本地实施的权衡考量，以及哪些需求应该作为产品长期战略的决策讨论。供应商与客户选择Y Soft合作的主要原因是他们灵活的适应性以及快速交付创新功能的能力。

不同的打印机供应商以及不同市场的客户需求，导致了SAFEQ产品的复杂性。此外，供应商在许多不同的设备上都会嵌入该软件，这些设备间有时仅仅有轻微的差异，但是即使是这种轻微的差异，也会对SAFEQ的安装带来很大的影响。在本案例发生期间，大部分客户是要求本地安装的（说明: 也是从那时起，越来越多的客户开始转向基于云的打印管理方案了），因此，Y Soft和供应商有较多的接触，如果需要，也会对客户提供直接安装和支持服务。这类协作一般发生在和本地客户部门之间，如果遇到客户部门无法解决的问题，也会和研发部门对接。在案例发生时，Y Soft正在向云端产品演进，这可以简化实施的复杂度。

在下面的章节中，我将会逐步介绍发生在2018年中到2021年底的Y Soft的LeSS敏捷之旅。也许还会有针对此后改变的后续案例。想了解最新进展，请回看Y Soft在2023柏林LeSS大会上的演讲。

0. 在LeSS导入之前

0.1 背景

以瀑布式产品研发为起点，Y Soft开始尝试“敏捷产品交付”，然而这只是一个他们新工作方式的名字而已，和敏捷与产品交付几乎没有关系。他们重组了9个组件团队，每个团队设定一个架构师作为“产品负责人”！至少需要4个“迭代”才能交付一个特性，而且没有任何团队可以独立交付特性。说明一下，这并不是真正的“迭代”，由于是组件团队（而非特性团队），“迭代”的产出物往往是一些组件任务和不完整的特性，而不是真正的初衷：每个迭代输出一个可交付的产品。各种不同的角色（如项目经理、销售、市场）都可以直接与研发沟通，打断他们当前的工作，并要求他们着手开发新特性。为了解决在交付客户特性方面遇到的挑战，Y Soft公司的研发副总裁（VP）成立了一个产品管理委员会。他们负责产品级的决策，决定团队要开发的特性。这导致了一个过度管控、几乎没有任何适应性的流程，并且对于正在发生的事情也没有增加多少透明度。此外，那些想要实现某个特性或变更的人仍然会利用他们与团队经理和开发者的关系来达成目的，完全超越流程之外。这证明了简便办法（成立产品委员会）往往会回到原点，甚至可能让事情变得更糟。

0.2 详述

第一次尝试特性团队是在产品的扫描领域，这是一个对客户来讲比较直观的业务领域。两个组件团队和来自测试与发布的人员共同组成了一个特性团队，并开始更接近真正Scrum的尝试。虽然没有进行大规模的组织变革 - 组织变革其实是Scrum的隐性要求，但也实施了一些细微的调整，使团队能够以这种方式工作。这也导致我们雇佣了第一位Scrum Master来帮助推动变革。该特性团队首次尝试增量迭代的开发模式，每1到2个迭代给客户做一次产品增量交付。这让团队可以和客户更紧密的合作。因为有更快速的反馈，在开发人员和客户之间不再有中间人的角色，这种协作模式帮助了团队交付客户真正想要的需求，并避免构建“臆想”的功能。基于学习则增加了适应。在特性团队的尝试过程中，研发部门的产品总监（也是SAFEQ产品下全部团队主管的领导）也做了一些微小的管理组织架构改变：他指定了一个经理负责整个特性团队，而不再是三个经理（两个组件团队经理和一个测试经理）。这是管理层逐步向支持性角色转变的首次尝试。同时，这次实验还取消了团队主管角色。

扫描试点后来被认为是整个研发组织“应该的做事方式”。但是，由于当前的组织架构，以及不同的领导和专家依旧希望保持他们的权力现状，导致一些关键因素被忽略，比如真正的跨组件、跨职能团队。简而言之，相比真正的特性团队，他们导入了一系列较小的实践改变，而非深度的组织设计变革，但只有深度组织变革才能在适应性、前置时间和客户满意这些维度带来较大收益。因此，Y Soft只收获了一些较小的改进，所以他们仍旧在寻找更好的方式去应对挑战。

0.2.1 组织设计元素

在LeSS导入前，Y Soft在小范围尝试了一些组织设计元素实验，这些尝试并未对更大的组织产生影响。这些组织设计元素对敏捷有一定积极正面的作用，但是在没有更大规模组织设计变革做支撑的前提下，并不会带来大的影响改变。总结一下，在一个团队所做的实验中涉及的组织设计元素包括：

  • LeSS规则：每个团队是 (1) 自管理的，（2） 跨职能的，（3） 同在一地的，（4）长期的
  • LeSS实验：尝试…通过消除“完成外”工作来消除“完成外”单元
  • LeSS实验：尝试…工作再设计

全部这些组织设计元素都有一定的局限性，因为单团队的外围组织并未发生改变。相比之前，团队变得更加跨职能了，成员都同在一地，且更加长期稳定。但是，自管理是很难的，因为他们在没有帮助的前提下无法独立交付工作增量。而且他们只能从他们有限的视角出发去端到端地交付以客户为中心的特性，而不是从整个产品的视角。即便如此，从他们的局部视角来看，之前被组织在“完成外”单元的工作进行了重新设计和功能整合，确实也带来了一些微小的收益。关于组织设计元素的更多说明请参考第一个组织设计实验的组织设计元素章节。

0.3 检视

第一个特性团队的尝试以及进一步推广的失败，导致Y Soft的人员开始寻找外部的信息资料来弄清楚如何继续他们的Scrum导入。他们初尝了Scrum的好处，但是在没有必要的组织变革支撑下，他们无法收获到Scrum能够带来的全部收益。他们通过Google搜索找到了LeSS官网，并参加了当地的敏捷社区和活动，这引发了他们对LeSS的真正兴趣。特别是Jürgen De Smet在2016年布拉格敏捷大会上的演讲“组织是如何失控的”深深地吸引了他们。

0.4 适应

支持早期变革的VP一开始没有完全接受LeSS，他和另一位VP决定一起参加2018年2月份的CLP培训课程。这成为他们真正把LeSS作为前行之路的起点。

在审视可行的LeSS导入方案时，Y Soft的研发人员意识到这是一场需要外部支持的变革。在2018年4月左右，因为在CLP中的正面体验，他们联系了Jürgen De Smet请求合作。此外，他们给董事会提交了一份LeSS导入的预算提案，包括为什么要变革，以及可能的成功指标。董事会最终在2018年5月底通过了这项提案，这样同年6月LeSS导入得以正式启动。这也触发了第一个重大组织设计变革的准备工作。

1. 实验1 组织设计：有多个特性团队的单个产品

1.1 背景

产品总监决定导入LeSS，设定了未来的一个时间来组织一场为期4天的活动，以遵循LeSS导入指南启动里的步骤建议，确保一个合适的开始。他们把这称为他们的“LeSS翻转向前”活动。产品总监与市场团队（研发之外）选定了一个具体的产品以及清晰的范围可以有效践行“深而窄”，以遵循“深而窄”优于“浅而宽”的LeSS导入原则。通过为期4天的活动，组织一次性完成了结构变革（组织和产品）。

1.2 详述

Y Soft高管选择Co-Learning咨询公司（现在名为Simplification Officers）作为LeSS导入的合作伙伴。Y Soft内部LeSS支持者（Scrum Master、开发人员和部分中层管理者）主动承担了LeSS导入和工作坊的准备工作，他们一起梳理现状与挑战，学习探讨必要的变革（参考下面章节）。这样一来，内部人员成为变革的真正主人，这是获得变革成功和能真正主导变革的一个关键因素。外部知识则被用作指导和知识库。

1.2.1 LeSS导入准备

准备工作以从不同视角分析Y Soft研发背景开始，包括组织、工作流程、实际代码的技术健康度。远程准备的目标是了解Y Soft现状，让Y Soft和Co-Learning（作为LeSS导入的合作伙伴）都获得更好的理解，并一起学习确定下一步任务与方向。分析采用了以下方式：

  • 诸如Confluence、ERP这类内部工具的分析用以组织评估。
  • 通过分析代码、构建和部署计划、分支管理策略和架构文档来评价技术健康度。

技术健康度评估被用于和开发人员一起确认并学习如何改进。例如，开发团队吸取的一个学习点是，要确保只有个别人员具备的知识点（特定组件或技术）能在团队自设计过程中被散布到多个团队，并确保团队成员都有机会学习这类知识。

在LeSS导入准备过程中，指出了下述初始评估结果：

  • 对于相对小的组织来说，存在较多的管理层级
  • 没有明确的产品负责人 - 有“团队PO”、架构师和项目经理，然而这些角色在Scrum中是不存在的
  • 长期处于救火状态，追求表面的完成
  • Jira工作流中存在很多状态与员工实际工作不符
  • 大约有75份显式的待办列表
  • 总共有898个构建计划，最长构建时间25小时，50个构建计划处于持续失败中
  • 发布很困难，需要很多时间，因为每个团队只关注一个特定部分，围绕一个或多个组件

这些评估结果在工作坊中被确认，并作为为期4天的工作坊的输入。

LeSS指南启动的第一步是：全员培训。VP和Scrum Master全都参加了Jürgen de Smet的CLP课程，从而更深刻地理解LeSS。对全部工程师，以及一些潜在的LeSS导入志愿者，我们组织了一轮通往一个LeSS组织的乐高Scrum工作坊（Lego 4 Scrum）。为了挑选出合适的志愿者，以及确定适合他们参与的领域，Jürgen把工作坊组织得十分激烈。重点放在让大家理解与其他团队、客户以及用户的协作是极其重要的。

Jurgen LeSS Course 1
Jurgen LeSS Course 2
Jurgen LeSS Course 3
Jurgen LeSS Course 4

更多关于LeSS导入准备的介绍，请参考“英文版附录B“。

1.2.2 初始组织改进Kata（2018年8月）

基于前期准备的结果，按照Toyota Kata方法，掀起了一场组织改进Kata活动。设定的方向与挑战是在为期4天的活动之后找到最适合开启LeSS导入的组织结构。

Toyota Kata

现状的积极之处：

  • 聚焦组件，在组件上具备较深的知识积累
  • 所有请求都归集于产品
  • 用户体验与安全知识在研发内
  • 关注支持工作
  • 大量的内部知识

对现状的改进项：

  • 团队间互相等待较多
  • 产品级的构建流水线不能有效的工作
  • 几乎收不到来自现场的反馈
  • 从现场到团队没有直接的信息流
  • 传递给团队的需求并不是客户真正想要的
  • 角色职责定义不清
  • 支持工作会打断新需求开发
  • 冲突升级会经过不同的的渠道
  • 文档不健全

一个被选定的小组使用管理3.0中的Meddlers游戏来设计未来的组织状态。他们探索了多个选项，对喜欢的模式进一步优化，并消除大多数（并非全部）不喜欢的模式。

在组织重新设计后，继续由这个小组决定产品是什么。定义产品是LeSS指南启动的第二步。经过“全员培训”的志愿者们被加入进来对组织设计结果给予反馈。这个小组成员一起做了一个特性团队导入地图练习。LeSS指南特性团队导入地图有助于可视化LeSS导入过程中组织变革的演进路径。特性团队导入地图在一个轴上展示团队工作范围逐渐变大，在另一个轴上展示团队跨职能的程度逐步提高。这带来了组织设置上的洞见，并由此确定了启动LeSS导入的4天活动的边界范围。

Initial Organizational Improvement Kata
Feature Team Adoption Mapping

一个重要发现是没有人想做新定义产品的产品负责人。

更多关于LeSS导入准备的介绍，请参考“英文版附录B”。

1.2.3 准备为期4天的LeSS启动活动

在Y Soft，VP和Scrum Master主导了4天启动活动的准备。并没有为此专门成立一个变革小组，全部活动组织的职责都由志愿者承担。志愿者们每周两次同步进展，并讨论下一步工作计划。

活动之一是成立了社区（也称为“实践社区”），以便团队之间能够协作、一起共同设计和知识分享。LeSS指南社区就是为了解决跨团队事宜，比如技能、标准、工具和设计。推荐的社区包括设计/架构社区和测试社区。开发人员有时会被要求成立他们认为有用的社区，这也导致了许多无实际作用的社区。

此外，外部支持也常被用来组织一些深度的技术工作坊。在事件风暴（Event Stroming）工作坊中，志愿者们把他们的（技术）架构链接回业务场景。团队需要从聚焦组件转变为聚焦整个产品，而且这些洞见能够帮助团队更好地理解产品。另外，有一个内部代码静修（Code retreat）工作坊活动，专注于小步重构来引入一些必要的工程实践，以帮助团队向前发展。人们可以在他们团队里使用工作坊中学到的知识。通过这种方式，他们可以实现将全部组件集成为一个产品，包括支持、发布和其他活动。

准备工作中一项重要的活动是寻找产品负责人。通过内部搜索与沟通，产品市场VP担任了产品负责人的角色，这与1993年在Easel首次Scrum导入时类似。他所负责部门的产品市场人员可以帮助团队获得必要的客户理解。

更多关于LeSS导入准备的介绍，请参考“英文版附录B”。

1.2.4 4天活动开启LeSS导入

在2019年1月进行了为期4天的启动活动。所有可能的志愿者都将参加，包括产品负责人、管理层和其他一些支持角色。产品总监向大家介绍了LeSS变革的原因。

第一天：初始PBR（Product Backlog Refinement/产品待办列表梳理）

作为初始PBR的第一步，产品负责人分享了产品愿景。LeSS指南初始PBR是确保让团队有一份产品待办列表，里面有足够的已经理解的产品待办条目可以开始工作。在开始导入LeSS时做梳理非常重要，因为通常现有的所谓“产品待办列表”遵循旧的组织结构，往往是职能或者组件导向的，而不是客户导向的。在特性团队模式下，产品待办条目会是客户导向的，因此原“产品待办列表”经常会无效，但是可以作为初始PBR的输入。在说明初始PBR非常重要的众多其它原因中，最关键的是通过PBR能确保团队充分理解产品待办条目，而不是由某个人、某个团队或其他人写下每个条目，并假设其他人都能正确理解这些条目。

产品愿景是初始PBR的起点，大家一起参与。然后工程师们创建一个集市，大家以每个条目大约6人的方式一起工作。大家会进行多轮迭代讨论，每轮后彼此分享结果，这个过程有些类似LeSS迭代评审集市，但仅仅是条目的分析，而非完成特性的展示。在完成多轮迭代梳理后，多个组会“群体编写文档”（Mob documenting），把梳理结果更新到Wiki和产品待办列表中。完成这个工作后，团队开始估算梳理好的产品待办条目。

更多关于4天活动的介绍，请参考“英文版附录B”。

第二天：创建完成的定义与自设计团队

每个人都参与了“完成的定义”工作坊，从而建立起一个面向产品统一的完成定义（DoD）。基于LeSS指南创建完成的定义，这需要在第一个迭代开始前完成。参会者们经历重新分组，并借助LeSS指南跨团队会议中的引导技术，整个团队通过若干“发散再合并”的周期最终形成一份DoD。

在这之后，大家组织了一场“完成外”工作坊来探索哪些活动能在每个迭代内完成（遵循LeSS指南创建完成的定义）。大家将那些不在DoD中的活动 - 意味着团队还不能“完成”这些活动 - 分配到各个小组中。每个小组定义这些活动将如何被完成（何时、何地和做什么），从而识别出为达到一个“完美”的DoD需要的所有遗漏项。团队将在未来使用这个“完成外的定义”去完善DoD。这给了团队透明度，使他们知道需要和谁去紧密协作来完成什么。同时也给团队提供了如何处理（某种类型）“完成外”工作的洞见，以及未来改进DoD的机会。

然后，大家“焚烧”了他们的旧团队。大家制作了关于当前团队以及对他们意味着什么的资料。他们真的焚烧了这些资料，作为对过去团队的告别，从而能够以全新心态去设计新团队。

在这之后，团队自设计工作坊开始了。LeSS导入原则之一是采用志愿模式鼓励吸引人们参与，这让大家有被授权的感觉。其中重要的一个部分是自设计团队，也就是让大家自己决定未来团队是什么样子。自设计团队的标准包括：

  • 团队在同一地点
  • 团队规模在6到10人
  • 能够尽可能多地独立交付产品待办条目
  • 团队成员能力和性格的多样性

在工作坊开始前，我们宣布只有希望成为团队成员的志愿者（遵循采用志愿的导入原则）、Scrum Master和经理们可以留在房间里，因为他们将是在新环境中一起工作的主要人员。其他人被要求离开。一些架构师离开了，因为他们决定不加入团队。每个志愿者基于模板填写了一份“个人特征表”，包括个人能力、技术能力和其它一些想要加进表格的重要信息。这个表格在后续的团队自设计迭代中会频繁用到。经过三轮迭代后，全部团队成员至少对团队设置表示“可以”，这意味着初始团队已经确定形成了。

更多关于4天活动的介绍，请参考“英文版附录B”。

第三天：团队约定以及与团队的跟进

团队以最后一轮自设计迭代开启第三天的活动。在完成团队自设计后，团队继续做了几件事情并达成了一些团队约定：

  • 团队名字
  • 团队之歌
  • 权衡选项并决策的指导原则
  • 团队潜在困难以及如何应对
  • 工作约定

团队也能够在一组Scrum Master中选择一位Scrum Master（限制条件：相同地点）。在这之后，每个团队内部组织了“完成/完成外”评审，从而了解自己能交付DoD定义的哪些部分，以及改进方向。

然后，参会人员共同讨论产品的运维支持类工作。除了客户特性之外，还有一些其它类型的工作，问题或缺陷常有发生，而且经常是“突发”的和计划之外的。Y Soft设有一个支持部，专门负责一级、二级和三级的产品运维支持工作，直接服务客户。如果支持部遇到无法解决的客户问题，或者需要研发支持，他们就会给研发（即团队）创建四级运维单。这些新成立的团队决定每个迭代由一个团队负责处理四级运维单，与支持部（有时是客户）共同解决这些问题。这个团队就是LeSS指南处理特殊事项中的快速响应团队，实现了由全部团队共同承担运维支持工作的轮换职责，并让其他团队得以聚焦。由于原架构下的团队是组件制的，大家各自处理这类支持事件，对大多数新团队来讲，这意味这他们缺乏足够的知识去处理所有运维单，因此大家都需要进一步学习。

更多关于4天活动的介绍，请参考“英文版附录B”。

第四天：迭代计划

在活动的最后一天，团队在新的结构下按照LeSS指南迭代计划一组织了他们的第一次迭代计划第一部分。Jürgen解释了迭代计划的目的和指导原则。产品负责人以说明产品优先级开启了迭代计划。

每个团队分享了他们在下一个迭代的可用时间安排（假期、会议等），以及他们需要完成的已经在进行中的工作。此外，他们补充了要解决的缺陷。然后，有一个集市让团队就自己挑选的产品待办条目跟大家分享他们下一个迭代的选择与设计。这些产品待办条目都被打印出来，以便团队可以方便抓取选择，并和其他团队讨论谁会选哪个产品待办条目。

下一步，每个团队独立地制定迭代目标。然后，所有团队的迭代目标被集合起来，大家对即将到来的迭代约定形成一个整体的迭代目标。重要的是，与Scrum不同，LeSS并不强制要求迭代目标。当迭代目标有用且存在自然明确的整体目标时，那就应用它。但是当没有一个自然明确的整体目标时（比如，因为团队间工作的异质性），最好就不要有一个共同的迭代目标。

在同一个房间内，每个团队选择（打印好的）他们想要做的产品待办条目放到位于他们自己团队空间里的迭代待办列表中（墙上的魔贴白纸）。在LeSS指南多团队迭代计划二中，强调所有团队应该在同一个房间内进行迭代计划二，以便能够通过直接沟通或“直接呼叫”的方式来与其他团队进行协作。

在团队成员查看其他团队选择时，会按照最小化团队间依赖的指令原则将某些事项从一个团队转移到其他团队。在LeSS中不存在依赖，因为每个特性团队都具备必要知识和能力去完成以客户为中心的端到端特性。如果不能，则会期望团队能够学习获取所需的知识技能。由于团队是全新的，所以可能存在有些特性没有团队具备端到端交付它的知识能力。在迭代计划的第二部分，团队会相互协调如何端到端地交付特性；如果需要，他们会借助其他团队的知识和技能，最好是通过主动学习这些知识技能来达成。这样就消除了依赖，因为是团队一起同时来确保特性被完成。事后看来，要求团队尽量减少依赖的指令可能会给团队带来错误的认知，因为重点应该放在通过与其他团队合作来学习和获取知识技能。这些不应该被视为依赖，而只是一起工作来学习并完成特性。随着时间的推移，通过传递正确的信息应该能够消除存在依赖的认知。

在最后，所有参会者通过一个舞蹈挑战来庆祝为期4天活动的圆满结束。而且从那个时刻起，新团队将正式按照新的结构开始一起工作。

更多关于4天活动的介绍，请参考“英文版附录B”。

1.2.5 组织设计元素

组织设计实验中包含的组织设计元素总结和简短说明：

  • LeSS规则: 使用真正的团队作为基本组织构造块来构建组织。

产品是由团队创造的，而传统组织是围绕个人问责构建的。个人问责并不能促成为实现目标而承担共同责任的运作良好的团队。这是为什么围绕（真正的）团队构建组织是重要的组织设计元素之一，也因此有了LeSS指南构建基于团队的组织。围绕团队构建组织会带来重要的影响。团队是工作的主要承担者，而非个人；也就是说个人不会在组织中被随意挪动或资源化。这也意味着工作到团队，而不是个人。作为结果，组织结构将保持（更加）稳定，不需要进行重构，从而避免了所有相关的负面后果。这些团队围绕客户价值来组建，而不是围绕子产品或者组织职能。很多组织是按职能搭建的，在这种情况下影响会比较大。在LeSS导入前，Y Soft实验过跨职能团队，但是未能以这种方式改变其研发组织。从LeSS导入开始，团队就成为产品开发组织的构建块。然而架构师和用户体验专家却是例外，他们在LeSS导入过程中始终游离于团队之外。

  • LeSS规则：每个团队是 (1) 自管理的，（2） 跨职能的，（3） 同在一地的，（4）长期的。

作为前一个组织设计元素的推论，LeSS定义了”团队”的含义。有些对团队的解释并没有体现出基于团队的组织应该带来的好处。因此，团队是自管理的、跨职能的、同在一地的和长期的。此外 - 也许不是必须的 - 每个成员应该100%都属于一个且唯一一个团队。团队需要具备多种职能能力（并且持续提升跨职能程度）以产生一个可交付的的产品。如果你希望团队关注他们作为一个整体如何协作，那么这些团队就需要有稳定性。研发团队重新自设计成为跨职能团队、在同一地方，这些团队长期在一起（除非自然原因，如员工离职）。随着时间推移，团队学会了更多的自管理。但是，自管理方面的改进主要发生第二个组织设计实验中，那里发生了更多的组织设计变革，更多介绍请参考下述章节。

  • LeSS规则: 大部分团队是以客户为中心的特性团队。

根据LeSS指南理解特性团队来创建特性团队，意味着围绕客户价值来组建团队，专注于客户领域而非技术领域（技术专长是在以客户为中心过程中一种偶然的专业化）。特性团队是稳定的、长期的团队，具备端到端交付以客户为中心的特性所需的知识与技能。如果并非如此，那么团队被期望去学习获取所需的知识与技能。这并不意味着每个团队可以交付每个特性。例如，一个较大的特性被分解为多个以客户为中心的部分（并非组件或技术模块），然后通常由不同的特性团队去完成交付。每个团队有能力交付这样的特性（或者通过学习获取能力来交付）。基于LeSS导入原则采用志愿，当前团队通过自设计被重新组织为特性团队。另一种方式是随时间推移不断增加团队的范围和跨职能程度，比如使用特性团队导入地图（LeSS指南）。通过这种方式，团队随时间推移慢慢成长为特性团队。开发这个产品的团队在LeSS导入之初，通过自设计转变为跨职能的和以客户为中心的团队。他们不断优化以具备尽可能多的技能。更多详情请参考检视章节。

  • LeSS规则: 产品定义应该基于实际尽可能的宽泛和以用户/客户为中心。随着时间推移，产品定义也许会拓展，我们倾向于更宽泛的定义。

在LeSS导入前，“产品”其实是整个产品的架构组件，每个组件由一个团队来聚焦。决定开始LeSS导入后，在为导入作准备的组织改进Kata工作坊中，参会人员共同定义了产品。最初的产品定义是整个产品 - SAFEQ - 包括全部的架构组件，除了基础设施。此外，全部外围职责也被包含到产品定义内，例如技术支持、回归测试和产品发布。这几乎覆盖了整个研发部门，而且因为SAFEQ在当时是公司的主要产品，所以也影响了研发与Y Soft内部绝大多数其他部门的协作。一个宽泛的产品定义，不能比这更加以用户/客户为中心了。

  • LeSS实验: 尝试…通过消除“完成外”工作来消除“完成外”单元

拥有一个“完成外”单元（如Y Soft的测试和发布团队）会延迟增量的实施交付，延迟学习与反馈，并削弱了团队的责任感。因此，“完成外”单元应该被消除。Y Soft内部最关键的“完成外”单元是测试和发布团队。在团队自设计过程中，测试和发布团队的成员加入了特性团队。团队达成一致，轮流负责创建发布版本（每次发布轮流）和支持工作（每个迭代轮流）。这个团队就是LeSS指南处理特殊事项中的快速响应团队，实现了由全部团队共同承担运维支持工作的轮换职责，并让其他团队得以聚焦。

这不但消除了瓶颈，还在共享“流程”方面带来了很多改进，如运维支持、问题修复、回归测试和产品发布。为了完成这些“流程”任务，团队需要学习很多技能（而且需要互相教导与帮助），在一年后，大部分团队都可以胜任这些“流程”中的大部分任务。此外，团队也做了很多流程改进，因为他们现在要对整个产品负责。有时候这感觉很痛苦，需要付出很多努力，有时还会出现错误，所以影响并不小。但是，团队更好地理解了整个产品，并共同承担责任。

  • LeSS实验：避免…职能单元

许多组织都是围绕职能专业来构建的，如测试、开发、架构和产品市场。这些职能单元的存在会因其有限的职能视角导致局部优化。相反则以（跨职能）团队作为组织单元。在Y Soft案例中，LeSS导入前研发部是以职能单元构建的，一些（中层）领导负责测试、开发、架构等团队。在LeSS导入的重组中，这些领导转变为（跨职能）团队的负责人。唯一的例外就是安全和架构部门，架构师们决定（目前暂时）不加入团队。而安全专家确实加入了团队，但他们也同时非常积极向没有安全专家的团队传播安全知识，这有效限制了安全方面的局部优化。

  • LeSS实验：尝试…工作再设计

在Scrum中，团队每个迭代都交付完整的以客户为中心的产品待办条目。这对工作的组织方式、以及工作的设计都有很大影响。在这一点上，重要的是要从客户的角度为团队设计更广泛的工作职责。作为采用组件团队的自然结果，Y Soft内部的工作设计聚焦于组件、技术和功能。在开始导入LeSS时，工作被重新设计以覆盖以客户为中心的产品待办条目，将（不同组件和职能）的任务结合在特性团队中。

从LeSS原则“以小为大”的角度检视组织设计原则：

我们使用下述组织设计原则来简化成为LeSS组织：

  1. 从专家角色到团队：团队成为组织构建块。随着时间的推移，特定领域（主要是技术领域）的专家在团队内部和外部分享他们的知识，因此团队获得了这些知识，而不再依赖个别专家。
  2. 从资源思维到人才思维：组织构建的基础逐渐转变为团队，个人绩效评估转变为团队反馈。组织仍旧期望以完整团队的形式增加“产能”，这表明在一定程度上资源思维仍旧存在；但随着时间的推移，渐渐转变为更加注重人才的思维。一个人才思维的例子是，CEO发现研发部门的的薪酬低于市场平均水平，于是他大幅提升研发部门所有员工的薪资到高于平均水平。
  3. 从围绕技术的组织到围绕客户价值的组织：团队转变为特性团队，聚焦以客户为中心的产品待办条目。技术显然也是重要的，但是专业知识在团队内部和团队间分享。
  4. 从独立团队到持续的跨团队协作：LeSS实施促进了跨团队协作和现状的透明度。在LeSS启动后有了越来越多的协作，但是真正的和更为持续的协作需要时间去学习。
  5. 从协调以集成到通过集成实现协调：这的确是个挑战，具体可参考1.3.6章节。因为团队对全部产品相关的工作负责，他们开始不断改进前提条件和行为以持续地集成。
  6. 从项目到产品：对研发来讲，不再有项目的概念，全部工作都来自于一份产品待办列表。尽管在研发外部仍旧有一些项目，但这些项目对研发影响有限。有时产品待办列表中的待办条目源自某些外部项目，如市场项目。
  7. 从多个小产品到少数宽泛的大产品：与组件团队聚焦具体组件开发、职能团队聚焦具体职能工作不同，重新定义的产品定义让多个团队一起工作在同一个产品上。这是从多个小产品转变到一个大产品的良好开端。在这个产品之外，公司还有许多其它小产品，但是这个产品在当时是Y Soft的核心产品。

1.3 检视

在这一部分，我们将对组织设计实验进行检视，重点关注组织设计变化以及LeSS导入。首先，我们将进行一般性检视，然后针对随LeSS导入而改变的组织设计元素进行具体检视。

1.3.1 第一个组织设计实验的一般性检视

Y Soft通过LeSS导入获得很多收益，即使在最初动荡“痛苦”的3个月（如下）。首先，未来全部的工作被整合成一份产品待办列表，并且由一位产品负责人确定优先级。尽管刚开始还不完美，但是团队确实更清楚了解了工作优先级，并且能相对容易地自行决策。其次，团队能够更好地看到和理解完整的产品，并且能交付比以前更端到端的以客户为中心特性。第三，由于团队跨职能和跨组件能力提升，以及共同承担责任，等待队列和等待时间减少了。第四，消除了瓶颈，并改进了共享的“流程”，如执行回归测试、修复缺陷、运维支持和产品发布。关于最后一点的更多介绍，请参考1.3.6。

在启动LeSS导入后，新成立的特性团队开始了第一个迭代的工作。团队开始端到端地交付完整特性。这些特性更加以客户为中心（尽管还不完美）。对于组织的其它部分，研发不再是一个黑盒子，因为产品待办列表和团队当前进行的工作变得更加透明。Y Soft内部的干系人能更好地了解在被开发的内容，并能够更好地在他们的工作中使用这些信息，比如产品市场在与客户沟通中。

Y Soft原先已经是高度聚焦客户：客户需求被认真对待并优先处理，与供应商（销售打印机的合作伙伴，他们在打印机里嵌入了Y Soft打印管理解决方案）紧密协作。Y Soft的员工对产品充满热情，渴望推动产品发展并向客户交付价值。在LeSS导入开始后，团队与客户和供应商之间的直接联系更加紧密，因为他们现在开发以客户为中心的特性，而不是仅仅关注组件需求。

然而，已有痛点的透明化也有不利的一面，这也是团队导入Scrum过程中非常可预见的情况：一些人把这些痛点归咎于新的工作方式和LeSS。大家需要与他人分享知识（有些人并不喜欢这样）；需要做回归测试，但之前这不是必须的；需要共同进行产品待办列表的梳理细化，而之前只是部分人创建需求而已，等等。一些人没有努力改进系统，而是互相指责。一些关注“效率”和产出（而非成果）的团队经理强化了这种状况；他们推动团队快速完成工作，而不是聚焦质量和产品改进。这种推动自然是由历史上的“效率和产出”管理指标和奖金所驱动的，尽管这些指标和奖金已经被取消，但人们还没有因此改变他们的行为。然而，高层管理仍然关注所谓的“速度”，即团队在一个迭代中所完成的工作量。这种关注最初延续了这种行为，尽管这并没有与之相关的奖金。后来，当事情逐渐稳定下来，新的产品负责人 （参考章节3.2.4）上任后，团队感受到的压力才慢慢减少。

总体来说，最初的几个迭代被描述为是“痛苦的”，但它们带来了大量的透明度，为持续改进工作奠定了基础。在外部支持下，产品总监和Scrum Master们持续努力进一步优化产品开发过程，这是一段曲折而挑战的旅途。

几个月后，产品开发方面似乎有了很多改进。虽然价值没有被度量，但团队的产出和可预测性方面有了明显进步。团队将这一点视为自身的重要改进，尽管产出（不同于成果）如果不带来价值且不直接贡献于适应性的话并不那么重要。其它被视为改进的迹象还有：

  • 客户和供应商直接参与了一些主要特性的开发。
  • 内部干系人对更好的特性开发结果表示感谢。
  • 内部干系人与团队之间的合作更加紧密。
  • 更互动的PBR，团队之间更多的分享和学习。
  • 更清晰透明的产品待办列表，更明确（且艰难）的特性优先级决策。
  • 团队对现有的工作方式显然更加满意。

尽管大多数团队都感到更加满意，但在LeSS导入的第一年，Y Soft流失了大约20%的员工。这些人可能感觉是被迫加入到LeSS变革中，而不是自愿的。由于该产品是公司的一个主要产品，员工内部调动到其他部门的选择有限。如果公司能更好地传达自愿的真实选项，并管理好大家的期望，也许能阻止部分员工的离职。说明：后来CEO发现员工薪资低于市场平均水平，于是他大幅提高了研发部门每个人的薪资，使其高于平均水平。因为一些人员提到薪酬是他们离职的原因。

重新对齐工作坊

几个月后，Y Soft意识到他们在LeSS导入方面需要帮助。他们请Jürgen De Smet组织了一系列的工作坊，以检视LeSS导入的情况、进一步改进，并为下一步转向LeSS Huge做准备。第一场工作坊是重新对齐工作坊，旨在更好地了解组织系统，并能够识别哪些系统变量需要改进。CEO、产品总监、研发管理层和Scrum Master代表参加了这个工作坊。

参会者们创建了一个系统模型（因果回路图），并识别了一些趋势指标来定期评估所采取的措施是否带来了整体系统改进。这次工作坊提出的主要评估指标包括：

  • 合并PR的时间
  • 特性与其它类型产品待办条目的比例
  • 修复构建失败的时间
  • 修复缺陷的时间
  • 每个迭代的预估商业价值
  • 工作满意度
  • 迭代交付的可预测性
  • 版本交付的可预测性

得出的因果回路图如下：

System Model of re-alignment

以下是局部放大图：

System Model of re-alignment Zoomed

这次工作坊和识别出的系统评估指标让团队更好地理解组织系统。他们在一段时间内收集了许多洞见，但并未专注于形成共识以真正改进。参会者选择关注的指标主要集中在“迭代交付的可预测性”、“特性与其它类型产品待办条目的比例”以及“合并PR的时间”。而团队尤其经常使用前两个指标来检视进度，并确定改进方向。请注意，可预测性指标并不是Scrum和LeSS所追求的，因为优化目标是适应性提升以发现最高的客户价值或满意度，这在某些情况下与可预测性是背道而驰的。对可预测性的要求也源于过去，那时因为各种原因客户需求和协议未能满足。产品市场和CEO希望提高可预测性，以便能够更好地与客户达成协议。只要交付时间满足共同设定的时间点（或更早），就没有交期的压力。自从LeSS导入以来，由团队设定预期的交付日期，而不是像以前那样由项目经理设定截止日期。工作坊的目的是让Y Soft的人员找出自己的指标，而很少精力放在对指标的具体目标讨论上。

对产品开发系统动态建模的结果被用来作为后续关于成熟度模型及创造新组织设计的工作坊的基础。后续工作坊是一个改进Kata工作坊，旨在确定如何逐步达成下一个目标。

工程师、Scrum Master和管理层参加了为期两天的成熟度模型工作坊。这个由不同角色组成的参会者群体定义了Y Soft背景下的“成熟度”含义，并确定了哪些角色和元素与成熟度模型相关。这导致了不同类别的多个成熟度模型：

  • 被授权的自驱型团队
  • 产品待办列表
  • Scrum Masters
  • 经理
  • 技术卓越

参会者分别为每个类别定义了不同方面。例如，在“被授权的自驱型团队”这一类别中，参会者定义了如“工程技能水平”和“处理客户反馈”等方面。对于每个方面，他们都描述了五个成熟度级别的定义。例如，“工程技能水平”的第三级被描述为：“自行设计交付功能：我们能够自行设计和交付功能。如果团队中包含新手，他们会得到适当的支持（但不会被持续的监督或检查），并且会为他们制定发展计划”。

CEO、产品总监、研发中层管理者和一名Scrum Master讨论了生成的成熟度模型。一位外部顾问对现状（每个类别）进行了分析。在准备过程中，Scrum Master使用了之前工作坊的结果以及这项分析，选择了几个主题与CEO、产品总监和管理层进行讨论：

  • 组织结构（包括LeSS Huge）
  • 产品和产品领域定义及设置（包括待办列表）
  • 该结构内的角色与职责
  • 社区
  • 成为技术领导者的使能因素
  • 结构内的信息流和可用性
  • 关键绩效指标（KPI）结构

该小组经过讨论后改进了部分主题。其中之一是解散架构团队，而让架构师加入各个团队。这次检视有效推动了当前组织设计和LeSS导入的改进。

CEO现场巡检（Gemba walk）及博客记录

布拉格的一支团队邀请CEO与他们一起工作了整整两天。在这两天里，他参加了他们的所有会议，并参与了集体编程（他在初创公司时就亲自参与产品研发，包括编码）以进行实际的产品开发。

他在给公司全员的博客中关于这两天的几个亮点：

“过了一段时间，我觉得有些信息值得与大家分享。”[…]

“我很高兴接受来自布拉格研发办公室<已移除的团队名>团队的邀请，与他们共度了两天。我原想重新当两天工程师不仅会很有趣，还可以帮助我解释为什么我们的效率不能进一步提升。但实际上，这次体验比我预期的还要棒，所以我决定与全世界分享我的经历和发现。”

第一天

“第一天，我们正在排查某个组件及其功能的缺陷。在升级到该工具的新版本后，看上去似乎需要在备份前进行一些额外的配置。我们采用了‘集体编程’（Mob Programming）。团队大约有6个人，只用一台电脑，并且每15分钟我们就会更换坐在电脑前的人。一开始，我认为这非常低效，我相当肯定这个工作由两个人做会快得多。但两个小时后，我意识到，由于采用了这种方式，整个团队 - 之前并不熟悉我们正在排查的SAFEQ部分 - 都获得了关于它的知识和经验。就连我，之前从未见过名为（工具名）的安装工具，也能很快编写代码。我从不相信自己能这么快地做出贡献，但幸亏‘集体编程’，我学得非常快。” […]

“真正让我高兴的是，当我向团队提出挑战，告诉他们仅仅修复一个缺陷并不能改善客户体验时，团队真的严肃地对待了这个问题，除了解决问题本身，还做出了额外的改进：一旦安装了<工具>，工具可以实现自动配置数据库。这才是我们正确的工作方式：每当修复问题时，我们应该总是问自己，如何能让客户体验更好？而且这还不是全部。团队还将<工具>的配置文件纳入规范的代码管理，这会让未来改动起来很容易。所以，现在的代码比之前要整洁了一些。再次强调，这是一个小的、快速的改进。但是，如果我们每次修复缺陷时都做出这样小而不显著的改进，SAFEQ将会变得越来越出众。”

“总结下我的主要收获：

  • 集体编程（Mob Programming）应该更频繁地用作一种学习方法，或者用于快速培训新员工。
  • 大量不同的工具会大幅降低效率。我们需要努力简化并更好地记录如何使用这些工具（尤其是那些较少使用的工具）。
  • 通过修复小错误来做出小的改进，从而不断改善SAFEQ用户和管理员的产品体验，这是可行的。”

第二天

“我们组织了一次梳理会议。这次会议的目的是深入探讨某个主题，并梳理它如何创造价值、需要完成哪些工作，以及工作量评估。这些信息随后将被产品市场团队用于路线图规划。主要发现是团队的业务知识不足。大家并不清楚为什么这个<主题>很重要。” [...]

“当梳理会议中至少有一位参会人了解<示例主题>时，会议会非常高效，并且也帮助很多人熟悉具体问题。估算过程富有建设性而又高效。这是一次很好的体验。”

“之后我进行了<部分产品>的回归测试。虽然这个过程有详细的文档记录，但相关问题依旧花费了我大约一个小时的时间。说实话，这份工作相当无聊。我把工程师定义为是那种宁愿花三个小时去做自动化，而不愿意花一小时去手工做这类事情的人……但我得赶火车回布尔诺，所以只好手动完成了。” [...]

“我在火车上小憩了一会儿，梦想着有一天，我们的工程师将不再需要执行不带来增值的简单管理工作步骤，因为即使是<组件名称>的回归测试也已经实现了自动化。毕竟，整个IT行业都是关于自动化的，不是吗？”

“第二天的主要收获：

  • 梳理工作有了显著改善，但前提是要有相关知识背景的人参与。
  • 我们对主题如何交付价值以及它们的重要性缺乏足够的了解。
  • 我们在自动化方面虽然取得了很大进步，但仍然在花费大量时间进行手动测试（但与一年前相比，现在的情况已经得到了显著改善）。”

1.3.2 检视组织设计元素：LeSS规则：使用真正的团队作为基本组织构建块。

自从启动LeSS导入的四天活动，形成了一份单一的产品待办列表，团队直接从中挑选工作。为了让团队能够按照客户价值来选择这些工作，并了解需要学习什么（技能），我们在产品战略和愿景上的薄弱变得很明显。例如，在PBR中，产品负责人无法很好地解释需要什么，甚至有时在梳理中优先级还会发生变化。Y Soft的员工习惯于在项目里工作，并将工作分解为不同职能和组件任务分配给不同的团队。从产品视角看，新工作模式对产品市场、产品负责人以及其他组织部门来说都是一个巨大的变化。以团队作为构建块需要这样的改变，但Scrum Masters和VP低估了以团队作为构建块与一个薄弱的产品愿景组合所带来的影响。

许多研发部门之外的人仍然使用非正式的沟通渠道要求研发部门承接和交付相关工作，例如存在其他部门的人仍然直接联系工程师。而这得到了部分研发经理的支持，他们接受这种做法，甚至直接将这类工作带给了团队！Scrum Masters需要确保其他部门的人理解他们必须直接与产品负责人沟通协作，以便对工作优先级进行合理排序（以及为什么有些工作根据优先级没有被选择），并且干系人必须亲自帮助团队正确理解工作的背景和价值。组织设计变革需要一段时间才能逐步运作正常。

1.3.3 检视组织设计元素：LeSS规则：每个团队是 (1) 自管理的，（2） 跨职能的，（3） 同在一地的，（4）长期的。

在导入LeSS之初，团队进行了自设计，他们同在一地工作、保持团结、拥有工作所需的大部分（跨）职能技能，或通过学习掌握了这些技能。然而，更加困难的是实现自管理。工作是以客户为中心来组织的，团队拥有更多端到端的技能来完成工作。然而，他们仍然坚持被动应对的方式去执行工作和改进，并确保完成。由于他们有了更多的必要技能，所以工作自然变得更加容易，然而却未看到更多的改进。

其中一个原因是，一些基本的Scrum原则没有得到很好的践行，这是因为在Scrum和LeSS导入过程中，Scrum Master缺乏经验。这导致了较低的经验主义，以及团队内部和团队之间学习的局限性。例如，在迭代计划中待办工作的透明度很低，团队之间的互动也很少，很难为下个迭代选出最优价值的工作。一个轮流的Scrum Master“领导”了迭代计划，而大多数团队代表只想让它快点结束。这样做带来的结果是，对于要交付的价值和所做的选择透明度有限，从而导致几乎没有互动，也几乎没有对下一步应该做什么的讨论。另一个例子是迭代评审，基本上就是各团队展示已交付的特性，没有形成反馈闭环，也没有从整个产品视角清晰展示增量。参会的内部干系人数量有限，未来的工作没有透明度 - 因此也没有形成检视和调整 - 以获取下一步工作的反馈。除此之外，普遍的意识是“改进是Scrum Master的事”（一位团队成员就是这么说的），所以团队没有承担改进他们工作和协作方式的责任。Scrum Master在6个多月的时间里都没有组织过一次整体回顾！一开始，产品负责人和支持产品市场的人员承担了团队该承担的责任，既扮演了领域专家的角色，又扮演了客户的角色，这阻碍了团队搞清楚客户问题，并强化了团队原先的行为模式：请告诉我们应该做什么。这些因素都不利于创造条件让团队学习自管理。

Scrum Master非常勤奋地帮助和推进各项工作。然而，这也导致了补位行为，比如填补各种工作漏洞，帮助“推动”事情向前发展以实现特性交付和问题修复。但是，团队没有因此学会自管理，没有为这些“漏洞”承担责任，而是继续依赖他人，从之前依赖项目经理到现在依赖Scrum Master。通过一段时间的外部帮助，Scrum Master重新聚焦并改进了Scrum和LeSS的基础原则，以提高经验主义。其中一个例子就是改进PBR，帮助团队组织PBR，以合理的方式拆分大工作项，并确保团队成为PBR的主导者，能主动邀请用户和干系人参与，让PRB真正发挥作用。

1.3.4 检视组织设计元素：LeSS规则：大部分团队是以客户为中心的特性团队。

在LeSS导入之初的团队自设计中，一个标准是“能独立地交付尽可能多的产品待办条目”。这导致团队试图拥有尽可能多的不同专业的成员，而不再专注于产品的某个特定（客户导向的）部分。一些团队开始互相学习以提升团队知识技能，例如测试人员学习编码、开发人员学习开发更多的组件。然而，也有团队仍然专注于团队内部旧有的术业专攻，这导致了大量的交接工作、要开发某些特性时的等待瓶颈，以及有限的“挑战”和尝试理解手头的特性和问题。结果是一些团队开始使用“更加新的”技术来完成特性，而其他团队则继续处理他们所“熟悉”的特性，这也导致这类团队总是在处理较低优先级的产品待办条目上，因为他们对自己处理“新”技术没有信心。显然，这不利于适应并致力于最高客户价值的工作。

这是在LeSS导入时可能出现错误的两分法这一思维误区的一个很好例子：错误地从一个人或团队只知道一件事的极端，转向另一个极端，即要求团队知道“一切”。组建新团队时在客户领域上聚焦的重要程度受到学习难度的影响；在一些较小且简单的产品组中，这并不是一个顾虑。尽管我们当时还没有采用LeSS Huge，但请注意这正是LeSS Huge的动机：团队聚焦在一个相对较小的范围内，从而让团队所需的学习不会过于繁重。

1.3.5 检视组织设计元素：LeSS规则：产品定义应该基于实际尽可能的宽泛和以用户/客户为中心。随着时间推移，产品定义也许会拓展，我们倾向于更宽泛的定义。

宽泛的产品定义给团队关注和理解整体产品带来了一些初始的挑战。这一挑战与消除大部分“完成外”的工作并将其转移到团队中（在接下来的部分详细描述）相互交织。

对于组织的其他部门，宽泛的产品定义也是一个转变。以前，他们需要联系多个团队来完成工作。而现在，他们只需联系一位产品负责人，并在PBR中与多个团队合作。总的来说，这一转变进行得相当顺利，不过也存在一些挑战，即人们有时会直接找自己熟悉的开发者而不是向唯一的产品负责人提出意见想法。

1.3.6 检视组织设计元素：LeSS实验：尝试…通过消除“完成外”工作来消除“完成外”单元

在导入LeSS前，一直聚焦组件，许多活动分散在整个组织中。例如，执行回归测试、修复错误、其他支持类工作（所有这些都分散在多个组件团队中）以及测试和产品发布（单独的团队）。从LeSS导入开始，团队共同承担了这些活动。例如，支持和发布产品的工作是由团队轮流完成的（“轮流值日”），这也体现了LeSS的建议，即在特性团队之间轮流承担这些必要的专项任务（例如，处理发布、突发缺陷、改进构建系统）。团队发现他们的构建系统和自己的工程实践不能支持他们轻松地完成集成和部署工作。构建流水线没有针对整个产品进行优化，包含许多不同的代码分支，没有一个明确的主干，也没有简单的方法能将各个分支集成到主干。以前，团队没有意识要快速地集成他们的改动，因此创建了许多不同的分支，没有及时合并到主干，也没有删除过时的分支。对于使用哪个分支存在很多混淆，集成需要花费大量时间和精力。LeSS指南持续地集成清楚地解释了持续集成（CI）是开发者的行为。为了支持这种行为，需要有配套的流程和工具，但开发者的行为和习惯仍是能做到持续集成的主要决定因素。回归测试和缺陷修复 - 除了高紧急性的错误外 - 主要是通过（自动）选择的“值日”特性团队来完成的；如果需要的话，也会在迭代计划第一部分中进行讨论。

由于“完成外”工作属于团队的责任范围，团队因此承担了更多针对这类“痛点”的职责，并加强了对更宽泛产品问题的理解。团队能够对如何完成这些工作做出更多 - 通常是小的 - 改进。例如，当开发一个新特性时，他们通常会创建自动化测试，这使得回归测试变得更容易、更快和更好。以前，这些“痛点”会导致延期交付和产品质量问题，但现在所有团队都要为此承担责任，所以情况得以显著改善。尽管这些“痛点”并没有完全消失 - 即使在LeSS导入后的两年里也没有 — 但团队已经显著减少了它们，至少没有阻碍价值的交付。目前，最大的“痛点”是团队必须承担这些“职责”并致力于解决这些痛点，而不是开发（客户）特性。不过，这种情况正在慢慢改善，至少最大的痛点已经克服。请注意，这里所说的“痛点”是团队必须完成的工作，但许多“完成外”工作的消除使产品本身的痛点显著减少，这是组织设计变革的结果。

1.3.7 检视组织设计元素：LeSS实验：避免…职能单元

在LeSS导入前存在多个职能单元，在本章节中将会对其逐一检视。在团队自设计过程中，产品总监识别出三类特定角色，他们可以加入团队或者游离于团队之外（采用自愿原则）：

  • 安全专家
  • 架构师
  • 用户界面（UI）/用户体验（UX）专家

自从开始导入LeSS，安全专家们就决定加入（不同的）团队，并在团队之间传播安全知识，成为“常规”开发人员。他们建立了一个强大的社区，邀请所有团队派出一名代表（“安全捍卫者”）加入该社区，以分享知识并确保每个团队都了解基本的安全知识。产品总监和团队都认可这种方法，所有团队都至少能够在日常开发中满足安全的基本需求。团队将更复杂的问题带到社区中，或者移交给有安全专家的团队。团队对安全问题的紧迫感有所增强，这是跨团队传播知识的一大成果。

架构师们在那时决定不加入团队，而是保持作为一个独立的团队。遵循LeSS采用自愿的导入原则，他们的工作是安全的（但角色并不安全和固定）。达成的约定是架构师不能阻碍任何团队的开发进度，如果他们想对产品有影响力，就需要与团队紧密合作。一些架构师做得相当好，但也有一些架构师不喜欢这种方式，最终选择离职。一些架构师在过程中加入了团队，并从下一个重大组织设计变革（参考 下个章节）开始正式成为团队的一员。在团队中他们的知识帮助团队更好地了解产品，而架构师也可以离实际产品更近。这样，他们可以发挥更大的影响力，在整个组织中传播更多的架构知识。

UI/UX专家在初期决定不加入团队。在后续阶段，他们曾经尝试加入团队，但团队和UI/UX专家自己都认为这不是一次成功的尝试。在这次实验中，他们虽然名义上是在团队中工作，但实际上只是各自为战，并没有过多地参与团队工作。对于他们来说，他们的工作与团队工作重叠的部分并不多，而团队也并没有因为他们的加入而得到什么好处，因为他们主要在做与产品不直接相关的工作。这是大家的普遍结论，因此他们转到了公司内可以运用他们技能的其他部门。同时，一些团队也雇佣了“前端开发人员”，他们能够直接参与团队的开发工作。他们的角色对团队很有帮助，让团队能更好地应对“前端”工作。

产品负责人是产品市场团队的负责人，在组织上隶属于市场部门，不属于研发部门。产品市场团队的大多数成员都与团队紧密合作，类似于LeSS实验(《精益与敏捷开发 - 大型应用实战》)中的PO代表或助理PO。PO代表主要围绕“主题”来组织，这些主题通常是以客户为中心的特性，但也可能围绕某具体供应商的请求或缺陷。PO代表在PBR中扮演主要角色，在迭代计划和迭代评审中也发挥着积极作用。他们与团队一起讨论特性的重要性，并帮助团队做置换权衡。然而，PO代表仍然作为一个独立的职能单元；虽然协作有所改善，但团队无法独立完成与产品市场相关的工作，总是需要与他们合作才能交付产品。

Scrum Master团队与研发部门协同工作，但作为一个独立职能单元存在。他们非常勤奋并一起紧密协作。然而，这也带来了一些负面影响，即他们过于关注Scrum Masters团队本身，而较少关注Scrum Master角色的其它重要方面，特别是支持产品负责人。他们对团队的主要关注点是组织和引导团队及跨团队的活动。我们与Scrum Master团队进行了一次系统建模会议，以了解当前系统和主要挑战。这使他们意识到应该关注之前未曾注意到的一些挑战。这成为他们更好地了解系统、明确要解决哪些挑战以及如何提升透明度的起点。很快，Scrum Master团队开始采取行动来提升他们想要解决的问题的透明度，特别是与产品相关的问题（主要是产品待办列表）。借助一些支持，Scrum Masters团队很快就开始关注主要挑战，而不是之前较小的关注点以及他们团队本身。

考虑这些职能单元，职能专家加入团队后带来了最好的改进。避免（从而消除）职能单元的组织设计变革带来了适应性的重大改进，但也对组织产生了重要的后果。

1.3.8 检视组织设计元素：LeSS实验：尝试…工作再设计

在开始导入LeSS时，特性团队把原先属于不同组件和职能的任务整合起来，工作被重新设计以涵盖以客户为中心的产品待办条目。团队最初对此感到挣扎，因为他们源自组件团队，还不习惯产品和客户的视角。在与供应商、大客户以及直接与客户和供应商打交道的内部干系人更紧密地合作一段时间后，团队更好地理解了客户领域的相关内容，“传话游戏”逐渐变少。以前，团队主要从项目经理或内部干系人那里接收工作，几乎不与真正的客户或用户互动。开始定义以客户为中心的产品待办条目就需要团队的学习，特别是在梳理和工作设计方面。随着时间的推移，团队在这些方面的表现越来越出色，组织设计变革的“工作再设计”最终带来了这一改进。

1.4 适应

在这个实验中的主要适应性变化总结如下：

  • 一位产品负责人管理的一份产品待办列表
  • 跨职能和跨组件的团队共同对整个产品负责
  • 团队共同承担整个产品的共性工作（如技术支持、缺陷修复、回归测试及发布），而不是单独保留一个“完成外”单元或团队
  • 团队自管理（并在这方面不断改进）

这些变化带来了以下主要结果：

  • 更加注重技术卓越性
  • 过了一段时间后，更加注重整个产品的发布
  • 定义产品待办条目时更加以客户为中心，把组件和职能任务整合形成端到端的产品待办条目
  • 团队有能力选择更多的以客户为中心的产品待办条目，并在需要时与其他团队一起协作来学习相关技能。

在重新对齐工作坊之后，产品总监决定在LeSS导入过程中增加更多的外部帮助，主要侧重于指导他们的Scrum Master。通过这种方式，Scrum Master能够学习并具备能力去主动推进相关工作。也就是在这时本文的主要作者加入了Y Soft的LeSS辅导。

根据检视结果，Y Soft在一年后希望继续向前迈进。下一步包括团队重组、取消研发部门经理角色，以及Scrum Master角色转变为敏捷教练，并招聘了在组织设计和团队辅导上更有经验的其他员工。Y Soft公司CEO和产品总监希望继续向前推进的原因有很多，包括：

  • 扩大团队的自管理，减少决策延迟，提高组织的透明度。CEO决定取消产品总监与团队之间的管理层，以在组织层面对团队内部发生的事情有更高的透明度，并通过取消管理层来减少决策所需的人数（以规避决策延迟）。
  • 产品中人员（和团队）数量不断增加，各团队的规模差异很大。团队招募了新员工，并纳入了其他角色（例如架构师）。产品总监从基础设施部门为产品增加了一个全职的“团队”（仍然作为一个组件团队），基于该团队的技能，他们需要服务其他各个团队。此外，CEO和产品总监希望增加额外的团队（产能），因此启动了两个新团队（完全从一家咨询公司招聘）。
  • 团队和管理层都希望提高端到端交付以客户为中心的特性的能力。这将使团队具有更高的跨职能程度，并能够承接产品更多部分的工作。一些团队意识到，他们需要提升技能范围，以便更好地端到端交付以客户为中心的特性。这些团队中的一部分却拥有过于宽泛的专业技能，他们则需要聚焦到一些客户领域，以便能够轻松地变得更为完美并有重点的学习；不是必需能够做产品待办列表中的任意工作。这些团队希望改变团队设计以得到优化。这导致了对继续推进既有自上而下也有自下而上（对于大多数人而言）的支持。

下一步是第二个重大组织设计变革事件，以及他们LeSS导入的后续步骤。在把启动LeSS导入的初始4天活动称为“LeSS翻转”或“第一次翻转”之后，他们将这称为“第二次翻转”。基本上重复了LeSS指南启动中的相关步骤。以下是组织设计变革的概述：

  • 团队（自我）重新设计
  • 不再有直接管理团队的经理

这些组织设计变革的背景和详述将在下一章中展开。

2. 实验2 组织设计：重新设计特性团队并移除管理层

2.1 背景

如前面的章节所述，我们提前安排了一场活动来开启下一次组织设计变革。我们已经在2020年2月 - 那时候新冠还没有流行 - 就计划了在5月11号举行该活动。产品总监决定按计划进行，因为 1）并不清楚什么时候能回归线下 2）他们不想推迟进一步改进和往前走。

发生的主要改变是：

  • 团队重新设计：大家自设计形成了“新”的团队结构。团队优化了自身结构以“交付更多端到端的客户价值”。另外，剩下的架构师们和基础服务团队也加入到团队中。
  • 团队不再配置直接经理：经理要么成为了敏捷教练，要么离开了Y Soft。团队设计了“宏观流程”来在没有经理的情况下处理诸如招聘、绩效评估，以及冲突升级等问题。
  • 用敏捷教练替换Scrum Master：产品总监认为Scrum Master的关注范围太窄了（主要在团队上），在更大的系统和组织上的关注太少。此外，有些团队曾经跟一些Scrum Master有过不好的体验。所以产品总监决定引入敏捷教练，他们明确需要关注更广的范围。一些Scrum Master成为了敏捷教练，大部分Scrum Master离开了Y Soft。在接下来的章节中，会有关于这个情况及其原因的反思。

在下一个章节，我们将展开描述这些改变及其背后的考虑。

2.2 详述

在第二次组织设计改变中重复并改进了LeSS指南启动中的某些步骤。至于为什么Y Soft要做这些组织设计改变，有如下原因：

  • 扩大团队的自管理并移除经理
    CEO和产品总监认为，经理限制了团队的自我管理能力，导致了决策的延迟以及通向团队的信息过滤。在LeSS导入的一开始，经理的角色就已经改变，他们被安排去“管理”两个跨职能团队，而不是负责某个组件或职能。经理不再对团队的结果负责。他们主要是处理人事相关的事务。然而，不同的经理工作方式不同。有些经理在处理冲突升级上非常积极，主动协调“干系人的需求”和团队的工作。另外一些经理则专注于支持单个团队成员，而避免对团队日常工作产生影响。这样的行为有时会导致团队的功能失调和自管理变弱。当经理被移除后，团队的“可预测性”和产出并未因此降低。历史上，研发部门的经理是对组织其余部分的接口和冲突升级点。在没有明确的方式来支持团队、发布产品、需求排序、管理团队与组织其他团队合作的时候，移除经理角色对组织会是有害的。当它能发生的时候，是因为前面说的那些前提得到了满足。
  • 又有职能团队加入到LeSS导入中，并且有许多新人加入
    团队内部的这些改变有几个原因：团队招聘了新人、其他部门的人加入到团队、架构师们非正式地加入到团队，以及人员离职导致团队规模的变化。此外，产品总监还在LeSS导入中增加了基础设施团队，但这个团队保持了以前的组件团队设置。他们想要变得更加跨职能，而其他团队想要具备更多与基础设施相关的技能。
  • 渴望改进团队的能力以更好地交付端到端的客户价值
    团队普遍总结，在最初导入LeSS时的团队自设计中，他们过于注重在团队中拥有尽可能多的技能（职能和产品模块）。事后看来，团队初始自设计时的其中一个标准（能够独立地交付尽量多的产品待办条目）没有被足够清楚地说明。这导致团队尽量“收集”跨整个产品所有的技能，而不是看相聚合的技能集合以便能够协作交付端到端特性。最终，在很多团队中，团队成员独立地工作在“任务”上，并互相交接工作。大家并不会把自己的技能教授给其他团队成员，因为他们的技能差异实在太大。

2.2.1 准备第二次组织变革活动

产品总监决定第二次活动不应该像初次LeSS导入时花4天那样多，因为大家已经习惯了一起紧密工作。另外，新冠隔离也让办公室没人。在这个LeSS会议视频和这篇博客中，分享了关于Y Soft如何远程实现团队自设计的更多细节。为了更有效地准备，准备本身也分成了不同的工作坊。在解释和宣布后续进行方式后，团队被要求代替产品总监来做自我重新设计，以更好地交付端到端客户价值。公司的Scrum Master们和刚刚入职的敏捷教练一起组织了两场工作坊来帮助团队重新设计。

团队设计工作坊 1

工作坊目标：形成团队设计（草案）并了解团队交付端到端特性的可能性。

在三个地方有团队为这个产品工作。位于最大办公场所（包含50%以上的团队）的团队已经开始自发改进现有的团队设计。一些团队成员自发帮助准备了工作坊。他们提供了重要的输入，例如（草案中）团队的当前状态和最常见的团队规模人数。

我们学习到：因为这三个办公场所的大小不一样（工作坊之后一个地方有8个团队，而另外两个地方分别有2个和3个团队），我们本可以有区别地去准备和参与工作坊。对于最大的场所，关于谁加入哪个团队的分组讨论太过复杂了。对于其他两个更小的场所，他们的团队在部分自设计迭代中的参与明显要少很多。对于未来类似的情况（不同地点的团队规模不一），应该考虑让小地点参与的方式，但仍然要在决定如何最好地优化整个大团队时包含他们。

我们有意将团队设计工作坊分成了两场。在同地的团队设计过程中，团队成员经常会在开会间隙讨论团队设计。从以前的团队设计中我们学习到的是在两个迭代中间空出30分钟就能让这发生。没有这个间隙的话，这些讨论就会在工作坊结束之后进行，团队也会随之改变。在远程情况下，这种在间隙的聊天非常难以实现。于是我们在第一场和第二场工作坊之间空出来一周，这样团队成员可以反思并讨论未决的问题和顾虑。

我们用Miro来引导工作坊所有的步骤。每一步，参会者在Miro白板上移动并增加/改变内容。最多的时候，Miro有95位参会者同时在线。最重要的引导提示：不要集中讨论。用其它方式来替代，比如在分组讨论之后用5分钟或者10分钟来读输入的内容或者使用便利贴对其提问。

为了帮助团队反思自己交付以客户为中心的端到端特性的能力，团队在第三轮的自设计过程中对产品待办列表上的工作做了一次练习。敏捷教练和Scrum Master们在Miro白板上准备了一些史诗（注意：一个史诗就是Y Soft产品待办条目的集合，这里参照了所用产品待办列表工具里的说法）。每一个团队都可以指出他们是否能够端到端交付那个史诗，或者是否有意愿交付并能够学习它。团队们在主表上评估他们可能交付的史诗，在上面贴一张绿色的便利贴（我们可以端到端交付它）或者一张橙色的便利贴（我们有意愿并能够学习来端到端交付它）。我们提前说清楚了后期不会用这个结果来看哪些团队可以交付哪些史诗。有些团队害怕这种透明会在事后被用来挑战他们：为什么不愿在一些特定的史诗上工作。当然，如果团队想，他们自己事后可以使用这些练习的结果。

结束时每个参会者添加一点对团队设计的可能顾虑。这个输入被团队成员使用，同时也是产品总监在第一场和第二场工作坊之间需要工作的内容。

团队设计工作坊 2

工作坊目标：最终确认团队设计并识别未来改进持续学习的步骤。

在两场工作坊之间的那一周，参会者讨论了团队设计的许多开放式结局。有些团队太大了，有些人则还没有加入任何团队。产品总监接受有些人可以不加入团队，不应该强迫团队接受他们不想要的团队成员。产品总监、敏捷教练和Scrum Master们整体了解了当前状态，并通过跟合适的人沟通来在两场工作坊之间帮助推进一些事情。

第二场工作坊跟第一场的结构类似。在两场工作坊之间大家用线上合作工具来更新他们团队设计的进展。在总结状态和一个新的迭代之后，参会者来收集阻塞问题。对于参会者投出的唯一阻塞问题有一个短暂的分组会议。有一位想加入其他团队的同事生病了，所以两个团队都不想做出最终决定。他们都同意在这个人回归之后再解决这个问题，之后团队重新投票：在这个措施之后，还需要另一个自设计的迭代吗？大部分人的回答是不需要（只有两个人想要另一个自设计的迭代），这也成了最终的团队设计。

在工作坊的结尾，大家对下一步行动做了三种分类，1）需要当前立马解决 2）需要在第一个新迭代内解决 3）需要在下两个迭代内解决。

更多关于准备工作坊的信息在”英文版附录D”。

2.2.2 第二次组织设计变革活动

组织设计变革活动不仅启动了新团队的工作，而且不再有经理。活动本身基本上是一整天的“庆祝”，也是一个新阶段的正式开始。因为新冠，这个活动也是远程的。

CEO开场了这次活动，他感谢每一个人的积极参与，和对Y Soft的成功以及整个战略的重要贡献。他详细解释了公司战略上的变化，以及为什么所有团队对这些变化的理解是重要和必须的。他也谈论到了“无经理”组织，因为从此以后产品研发中的所有经理都被去掉了。团队自己取一个团队名字（如果他们想，也可以加一个团队标识），并讨论对他们来说重要的团队价值、如何合作，以及如何确保互相学习。团队和其他伙伴团队一起商量解决了如何承担快速响应团队的角色，以让新团队尽快运转起来。

没有了经理，团队设计了“宏观流程”，以使自己能接手之前经理负责的事务。宏观流程的例子包括新员工入职或招聘新员工。团队利用这个时间就最重要的宏观流程形成了一个团队间如何处理它们的草案。

第二天早上，新团队的第一个迭代从迭代计划开始。团队们被要求全员参与（而不是派代表），有两个原因：

  • 当团队成员还互相不了解对方的技能时，他们可以一起讨论来选择产品待办条目
  • 产品负责人（活动前一个月刚开始工作）已经为即将到来的下一阶段准备了更具战略性的大纲

在迭代计划一之后，团队转向他们的迭代计划二，并按照新团队设置开始一起工作。

更多关于第二次启动活动的信息在“英文版附录D”。

2.2.3 组织设计元素

组织设计实验中涉及组织元素的总结和简短阐述：

  • LeSS规则：大部分团队是以用户为中心的特性团队。

从前面的组织设计实验中检视到：团队尝试涵盖尽可能多样的专家，却导致合作和学习非常有限，以及团队内部过多的交接形成了瓶颈。在第二次团队自设计中，团队围绕产品待办列表上的工作做了练习，来评估他们是否可以端到端交付某项大块工作（“史诗”），或者有意愿并能够学习它。这样帮助团队关注在产品待办列表中特定的部分（在客户领域上专业化），而不是尝试拥有能做尽可能多产品待办条目的技能。另外，在团队自设计中，Y Soft的架构师们正式加入到团队中。这些是自己能动手开发的架构师，他们向团队传授了更广泛的产品知识。

前面组织设计实验里的这个章节中介绍了这条LeSS规则。

  • LeSS实验：尝试…扩展产品的定义

最初的产品定义常常不够完美。通过扩展产品的定义 - 通过改进完成的定义 - 组织级的改进得以发生。团队学习或者增加了他们不曾拥有过的技能。在第二个组织设计实验中，之前在LeSS导入范围之外的基础设施团队也参加了团队自设计，其成员加入到特性团队中。这样，产品完成的定义得到了延伸，部分完成外的工作被包含进了团队里。

前面组织设计实验里的这个章节中介绍了这个LeSS实验。

  • LeSS指南：倾向在客户领域上专业化

对特性团队的一个普遍误解是，它会导致特性团队完全放弃专业化。专业化是多维度的，不止是技术，还有客户领域。在客户领域上专业化（领域对一个团队来说可能随时间而变化）常常意味着在某些技术上偶然的专业化。之前团队并没有在技术上专业化，而是尝试在他们团队中拥有太多的专业以便能够围绕客户特性协作，反而限制了团队在客户领域上专业化。在第二个组织设计实验中，团队反思了他们能够（并愿意）工作在哪类特性上，以便在某个客户领域上专业化。

  • LeSS指南：经理是非必需的

在LeSS中，经理是非必需的。经理可以发挥一个有用的角色，但大部分大型组织不缺经理角色和位置。LeSS组织更倾向于把职责给团队，而不是给经理角色。在第二个组织设计实验中，对团队中的人员来说已经没有了经理；只有产品总监，但他并不承担大部分传统经理的职责。这些职责现在由团队承担，与HR紧密合作。这个指南与LeSS实验尝试…保持组织尽可能扁平相关。

  • LeSS实验：尝试…让HR参与进来

HR实践在许多组织中是一个主要障碍，仅有一小部分成功地改变了HR实践。传统HR实践关注在个人，而在敏捷开发中团队才是主导者，这带来了系统冲突。为了培育出真正的团队，HR实践必须要改变，比如奖励和绩效评审。为了做到这点，让HR专家参与进来是非常重要的，向他们解释为什么敏捷开发会影响HR实践。在Y Soft，HR专家（包含招聘）在第二个组织设计实验的准备中就开始与团队紧密合作，比如招聘新成员和升职。从那时起，团队必须与HR紧密合作，而HR也很好地参与了团队的工作并支持到了团队，比如招聘新员工。在这个章节中分享了更多关于团队如何在没有经理的情况下工作的细节。我们尝试的其中一个LeSS实验就是尝试…团队自己招聘。

  • LeSS实验：避免…奖金与绩效挂钩

（个人）奖金与绩效挂钩是基于旧的假设 - 人们可以控制他们的绩效并被奖金所激励。这里的建议是“把报酬和任务分开”（来源）。在第一个组织设计实验中，我们曾经尝试通过奖励团队来促进团队合作。然而，这些依然是对绩效的奖金，效果并不完美。此外，有些经理仍然对个人绩效进行“奖励”，即使没有真正的奖金。从第二个组织设计实验开始，不再有与绩效挂钩的奖金，无论是个人还是团队。当组织表现好时，所有团队都拿到同等的奖金，团队可以在内部分配这些奖金。相关的LeSS实验是尝试…用奖励团队代替奖励个人和避免…绩效考核。

检视来自LeSS原则以少为多中的组织设计原则：

我们使用以下组织设计原则来简化成为LeSS组织：

  1. 从专家角色到团队：在第一个组织设计实验中，团队已经成为了组织构建块。在第二个组织设计实验中，由团队自己来牵头；团队已经习惯承担责任和一起工作。
  2. 从资源思维到人才思维：Y Soft的HR和产品总监，从第一个组织设计实验中学习到要更多地关注在团队需要和人的需要上，因为团队作为组织构建块把大家的感受和需要变得透明了。
  3. 从围绕技术的组织到围绕客户价值的组织：在第一个组织设计实验中我们重新构造了组织，在第二个组织实验中本质上没有改变。但是，团队增加了对客户领域的学习，比如就某些以客户为中心的特性与大客户紧密合作。
  4. 从独立团队到持续的跨团队协作：在导入LeSS的开始，团队关注在自己的工作上。他们开始越来越多在大特性开发中合作。特别是当公司战略改变（因为新冠）并导致产品待办列表改变了许多时，团队需要在新的战略和技术上一起发现和学习。这发生在第二个组织设计实验前后，重新设计帮助团队更好地聚焦在这上面。
  5. 从协调以集成到通过集成实现协调：自从第一个组织设计实验以来，这还是一个挑战，见这个章节。因为团队开始负责所有产品相关的工作，他们开始改进持续地集成所需的前提条件和行为。在第二个组织设计实验中，团队也继续工作在改进技术卓越和他们的集成行为上。
  6. 从项目到产品：随着时间的推移，已经不再有私下给到团队的需求。这一点也没有因为第二个组织设计实验而改变，而是从第一个组织设计实验中延续了下来。
  7. 从多个小产品到少数宽泛的大产品：在第二个组织设计实验中，产品的定义没有改变。但是，通过把基础设施团队引入到特性团队中，完成的定义被扩展了。

2.3 检视

2.3.1 第二个组织设计实验的一般性检视

前一个组织设计实验包含了在组织设计上更加影响深远的变革。因此，第二次组织设计实验中需要检视的东西就变少了。其中一个值得检视的主题是从Scrum Master到敏捷教练的转换。

为什么是敏捷教练而不是Scrum Master？产品总监在某个时刻得出如下结论：Scrum Master的关注范围太窄了（主要在团队上），在更大的系统和组织上的关注太少。此外，一些团队因为同样的原因跟Scrum Master有过不好的体验。所以产品总监决定启用敏捷教练，他们有明确强调要关注在更广的范围上。所有的Scrum Master必须申请才可能成为敏捷教练。

反思：对Scrum Master这个角色有一些误解，定义敏捷教练的角色基本意味着Scrum Master的角色定义是合适的。此外，Scrum Master工作范围太窄的问题是可以预防的。Scrum Master们在导入LeSS的开始几乎没有得到外界的帮助，因此没能关注在系统性的重要变量上。他们主要关注在团队上，与产品负责人在产品待办列表（以及与之相关的活动）上没有任何互动。当更密集的外部辅导和教练开始实施，以及工程VP（作为敏捷教练角色）也成为Scrum Master组内成员后，Scrum Master就有了改进。然而在其他人的眼中，伤害已经造成。在第二次组织设计中，产品总监宣布组织中不再有Scrum Master的岗位，Scrum Master可以加入团队或者尝试在组织中找到其他的位置。在晚些时候 - 仍在Scrum Master们离开之前 - 产品总监宣布一些Scrum Master可以申请成为敏捷教练。这表示Scrum Master们已经学习并作出改进，因为产品总监在更早的时候并没有这样宣布。不幸的是，大部分Scrum Master不喜欢一开始他们被对待的方式，因此决定离开。

如果在导入LeSS的一开始 - 或者甚至在晚些时候 - 我们密切地帮助Scrum Master们，这种情况本可以避免。他们热切又有才华，仅仅是缺乏经验和支持。Scrum Master应该可以帮助组织变革和解决问题，但因为缺乏经验和支持，他们没有做这些事情。产品总监没有理解这一点，也没有帮助Scrum Master来做这些事情。相反，我们通过引入了新角色这一快速但糟糕的方案来解决问题。敏捷教练其实就是在LeSS和Scrum里的Scrum Master，因此在LeSS导入时并不需要引入敏捷教练角色。

有一个Scrum Master变成了敏捷教练 - 关注在技术辅导上，而其他Scrum Master都离开了Y Soft。有一个Scrum Master多待了一段时间来帮助大家。一位经理成为了敏捷教练，工程VP成为了敏捷教练，而其他敏捷教练是从公司外部招聘的。

在经理被移除之前，Y Soft已经采用简单的职位描述，没有在研发中区分专业。开发工程师在他们升职的时候会晋升一个级别，但他们的角色基本上跟以前的职业路径一样。跟LeSS实验尝试…创建唯一职位名称和尝试…通用名称带不同级别非常像。

2.3.2 检视组织设计元素：LeSS规则：大多数团队是以客户为中心的特性团队。

导致团队需要重组的根本原因是可以预防的。在团队内部和团队之间缺乏持续学习和协同学习的问题应该得到更多的关注，特别是来自Scrum Master的关注。在LeSS导入开始的4天活动中，太多的注意力被放在每个团队需要拥有（几乎）全部技能上，许多团队因此一直为成为一个真正的团队并能够端到端交付而挣扎。更好地支持Scrum Master也可以预防这一点。

在团队内部学习变得越来越跨职能和跨组件本应该是首次导入的一部分。虽然有部分团队在这方面有所成长，大部分团队并没有。在这个时期，团队关注在学习做支持任务、做回归测试、修复缺陷和发布上。虽然这些都很重要，并且也是获得整体产品焦点的主要因素之一，但是团队对组内合作以及分享业务领域和组件知识的关注有限。

在第二次组织设计变革的准备过程和工作坊期间，我们关注并鼓励了团队学习。团队识别了不能共同跨职能交付价值的根本原因。在这次活动中，团队识别了在团队内部和团队之间需要学习的领域，以防止类似情况在未来发生。

正式加入团队的架构师们在团队中动手参与实战，他们中的大部分也会帮助其他成员理解全貌和产品整体，特别是跟新技术相关的部分。

2.3.3 检视组织设计元素：LeSS指南：尝试…扩展产品的定义

在第二个组织设计实验中，曾经排除在外的基础设施团队参与了自设计并加入到了各特性团队中。这样一来产品完成的定义被扩展，一部分以前的完成外工作也包含进了特性团队中。

基础设施团队是在导入LeSS的产品团队之外的一个独立的（组件）团队。在团队自设计中，原基础设施团队成员分别加入到了三个特性团队中，这三个特性团队都至少拥有两个基础设施团队的成员，以防止他们被其他团队成员孤立。我们没有对这个变化做单独评估，但也没有发生关于它的任何争议。基础设施工作成为了产品待办条目和完成的定义的一部分，有些团队会接手更多基础设施相关的工作，因为这些工作对他们聚焦的某个（客户）领域来说是必需的。产品定义的扩展很自然就发生了，因为相关的人都很好地融入了团队并渴望让这一变化能够成功。

2.3.4 检视组织设计元素：LeSS指南：倾向在客户领域上专业化

大概是在开始第二个组织设计实验的时候，发生了一次战略变化（因为新冠），也导致了产品待办列表的大范围变更，包括对不同技术的聚焦改变。最初有三个团队，稍后有第四个团队，聚焦到了这个（客户）领域，他们跨团队紧密合作来学习了这一新的客户领域。这是一个在（新）客户领域上专业化的成功案例。

然而，从某个时刻开始，这个领域成为了产品待办列表的主要部分，需要更多的团队参与进来。让其他团队参与到这个新领域和技术中则花了大量学习和协作。

2.3.5 检视组织设计元素：LeSS指南：经理是非必需的

很难基于硬性指标来反思有经理和没有经理的不同。事实是团队交付产品待办条目的数量和以前一样（在团队规模相同的情况下）。平均每个团队少一点，但总体数量是一样的，因为团队规模变小了。在几个迭代之后，交付的产品待办条目数量提升到了和以前一样的水平。虽然产出完全不应该成为目标，但这也表明了在没有经理的情况下产出并没有变化，新组建的团队甚至没有过产出降低的阶段。

Y Soft如何推进自我管理、如何应对曾经由经理们领导的跨团队（甚至跨部门）主题，都非常值得学习。在Y Soft，这些主题被称为“宏观流程”（比如冲突升级、招聘、解雇）。宏观流程用以设计如何让所有团队在没有经理的情况下保持运行。针对一些主题，例如招聘，团队在考虑宏观流程的约束后，自己内部决定怎么做。这其实就是特定团队的微观流程。

团队志愿者、产品总监，以及敏捷教练代表一起创建了如何实施宏观流程的指导原则。一个志愿小组（主要是团队成员，还有其他相关干系人或者如果需要也包括PO）设计最初的也是最重要的宏观流程。受到LeSS全景图的启发，志愿小组为每个主题定义原则，并创建相应规则。这些规则可以是实际存在的约束（比如HR对申请人的响应时间），也可以是志愿小组一起确定用来保证对一个主题有一定的一致性。基于原则和规则，志愿者们设计了在团队内用来应对主题的指南。跟LeSS指南先有一些做法然后基于实验进行学习类似，团队可以根据自己的情况做出调整。在指南完成以后，宏观流程（基于原则、规则和指南）被所有团队讨论，或（取决于主题是什么）发送给所有团队征集反馈。

Macro processes

宏观流程是如何被解释的

设计这些宏观流程让团队有了更多职责，因为他们既是设计者也要负责执行这些主题。这个博客中有Y Soft团队如何应对升职的例子。

2.3.5.1 产品总监离开Y Soft且没有替代者

大概一年半以后，产品总监离开了Y Soft。需要做出一个选择：招聘一位新的产品总监或者由CEO担任产品总监。招聘新产品总监产生的风险是，这位新人可能想要改变一些事情，因为他并没有参与现有的组织设计。在咨询了一部分团队成员之后，CEO决定不再招聘产品总监，而是试图在他和团队之间不再设置任何经理。为了应对这种情况，HR在系统中设置了一个正式的角色来处理一些事情，例如，给新人签订合同（而不是产品总监来做）；有一个来自研发团队外部的人代替产品总监管理采购和供应商（例如，招聘外部人员加入团队），这部分工作相对其他组织来说比较有限。直到今天（2023年春），Y Soft也没有再招新的产品总监。CEO似乎也没有因为产品总监的离开而增加工作量，因为团队承担了额外的工作（参见上面章节的宏观流程），HR跟团队一起负责人事事务，有一个人管理采购和供应商。不管怎么说，CEO常规性地参加迭代评审，有用时也会参加PBR，并经常在迭代计划开始时提供业务更新。这些并没有因为产品总监的离开而改变。显然，产品负责人也没有增加额外的工作，因为产品总监之前也并没有参与到产品和产品愿景中。

2.3.6 检视组织设计元素：LeSS实验：尝试…让HR参与进来

在前面组织设计元素的检视中，HR这个角色帮助了团队应对没有经理的情况。CEO明确了他对HR的期望，以及在LeSS导入中希望HR与团队合作。HR非常支持团队，跟团队一起紧密合作。针对招聘新人，团队与HR一起设计了相关宏观流程。在这些宏观流程中，他们约定好了谁负责做什么以及有哪些约束。比如团队需要对每一份职位申请在24小时内做出响应，并跟申请人沟通他们的决定。HR负责发布招聘信息和搜索新的人选供团队面试。团队和HR都喜欢这种工作方式，根据（被聘用的和未被聘用的）申请人的反馈，招聘过程的质量也有所提高。

2.3.7 检视组织设计元素：LeSS实验：避免…奖金与绩效挂钩

自从第二个组织设计实验，已经没有了与绩效挂钩的奖金，无论是个人还是团队。当组织表现好时，所有团队都拿到同等的奖金，跟绩效没有关系。有些团队实验过不同的团队内部奖金分配方式，某些情况下团队在内部不均等地分配了奖金。然而，大部分团队在内部均等地分配奖金。也没有与绩效挂钩的加薪和其它奖励。在某个时候，CEO发现公司薪酬低于市场水平，他大幅提高了研发团队所有人的薪酬，超过了市场平均水平。从那时起有不与绩效挂钩的定期加薪。团队内部和团队之间没有了竞争关系，大家感觉公司提供了合理的报酬，并知道有一个可以获得晋升 - 当他们达到要求时 - 的流程。

2.4 适应

在这个实验中的主要适应性变化总结如下：

  • 重新设计跨职能和跨组件的团队，以便单个团队能够交付端到端产品待办条目（不意味着：所有团队都可以端到端地完成所有产品待办条目）
  • 剩下的架构师正式加入到各特性团队中
  • 解散独立的基础设施团队，团队成员加入到常规团队中
  • Scrum Master被敏捷教练所取代
  • 移除所有经理，除了产品总监以外
  • 团队奖金不关联到单个团队的绩效

这带来了以下主要结果：

  • 一些Scrum Master离开了，一些经理变成了敏捷教练
  • 提升了团队自我管理，并给予了额外重视

从导入LeSS开始发生了许多组织设计改变，在接下来的几年里还有许多小的改进。这些改进没那么显著，但Y Soft持续改进来增加提升团队的责任感，以及在没有经理情况下开展工作。同时也改进了与组织其他部分的合作，比如产品市场、（本地）支持和销售。

CEO在LeSS导入的早期，在第二个组织设计实验之前，表达了想要将SAFEQ转向LeSS Huge。Y Soft有增加市场份额和可能的话扩张市场的雄心。转向LeSS Huge应该可以帮助他们扩张，包括扩大团队规模。

比较显著的调整是Y Soft的联合创始人成为了SAFEQ的产品负责人。他非常有经验，跟（打印）供应商/合作伙伴以及大客户关系亲密，对产品了如指掌，因为他（跟CEO一起）开发了最初的产品，并一直贴近产品和代码。当他成为产品负责人后，我们对愿景的理解和对基于供应商和客户的优先级清晰度都得到了提高。因为得到了授权（他的决定受到尊重），他不会基于来自组织的“要求”而改变方向，从而减少了团队因切换客户领域带来的认知负荷。这也包括响应来自（打印）供应商和客户的反馈和学习。团队没有了紧急需求，可以更加专注，即使我们有10个团队共同工作在一份产品待办列表上。一个连贯的产品愿景、清楚的优先顺序、产品负责人与团队良好的合作，改善了团队（感觉上）的聚焦。自从这个产品负责人 - 和一个组织内经验丰富的助理PO - 加入到产品团队之后，内部干系人和外部客户的满意度更高了。团队有了更好的基线来进一步改善，更明白应该聚焦在哪里，以及长期要学习什么。

之前有过多次关于转向LeSS Huge的讨论。敏捷教练和（新）产品负责人讨论了把SAFEQ转向LeSS Huge的原因和后果。他们得出的结论是，转向LeSS Huge的主要原因是产品负责人不再能理解SAFEQ所有客户和市场的需要，进而不知道从中长期来说应该聚焦在什么地方。（2021年春）讨论的时候，SAFEQ刚刚增长到了11个团队，而产品负责人表示他能够管理客户和市场需求，以及产品待办列表中的主要主题。他提到团队已经成长为能够推进主题（探索和交付），以及必要时跟内部干系人和合作伙伴一起梳理产品待办条目。他对产品、市场和重要供应商和客户的经验和知识可能帮助了他具备这个见识。如果在未来他无法再管理这么大范围，可以到时再转向LeSS Huge。

反思：尽管LeSS规则说LeSS Huge是针对8个以上的团队，然而团队的数量不应该成为转向LeSS Huge（或者拆成两个产品）的原因。多少人能够工作在一起会有限制，但这个限制是基于上下文的，取决于产品、人员的知识、复杂度、公司规模等。第二，当整个产品 - 在这里几乎是整个组织 - 的规模是在8个左右（是13个，而不是50个那么多），应该对为什么所有团队一起工作是个问题的原因做深入分析。可能有更重要的根本原因需要解决，而不只是因为“太多团队一起工作”。然而，当决定转向两个产品的时候，并没有对这个问题做更深入的根因分析，例如，缺乏对好的产品愿景的分享、太频繁改变需求优先级，以及延迟的客户反馈。

3. 转向两个产品

因为产品定义会带来相关的组织后果，决定产品定义是组织设计的一个重要方面。这章将讨论产品定义及转向两个产品的决策。讨论聚焦在产品定义对适应性提升以发现最高的客户价值或满意度这一优化目标的影响。这章补充了前面章节的组织设计评估。

3.1 背景

如前面章节所述，我们多次考虑转向LeSS Huge。在某个时候，Y Soft推出了OMNI系列，这是来自基于SAFEQ产品待办列表开发的结果：一种能够将打印设备连接到多种环境（如Microsoft 365）的硬件设备，即使打印设备未配备与云环境连接。OMNI系列的客户是打印设备的实际最终客户和用户，而SAFEQ则是作为包嵌入在供应商的设备包括软件上销售。这意味着客户和需求不同，因此销售渠道也不同（直销与通过合作伙伴/供应商销售）。使用的技术不同（注：没有假设的那么多），这让CEO、战略规划师和所有产品VP决定将两个产品分开。由此我们转向两个产品，每个产品有一个产品负责人和一份产品待办列表。已经在OMNI系列上工作的团队转向工作于OMNI系列的产品待办列表（3个团队），而其他团队转向工作于SAFEQ的产品待办列表（10个团队）。新产品的第一个迭代从2020年11月开始。在本章中，重点介绍向两个产品的转变。

总的来说，CEO和一些其他来自诸如市场的高管认为：1）两个产品有不同的客户和不同的市场渠道，2）需要对这两个产品更聚焦。

3.2 详述

CEO和销售VP有志于在未来几年迅速扩大市场份额，成为市场的技术领导者。Y Soft有很多市场机会，他们希望能够响应这些机会。之后，机会经常因条件的变化而变化（新冠疫情是最相关的例子），现有客户也希望对现有产品进行更新。考虑到Y Soft历史上一直有快速满足（定制）客户需求的优势，能够响应现有客户的诉求非常重要。为了能实现这些愿望，产品开发要能适应所需的变化。

从组织变革的第二次活动开始，在产品开发中定义了13个团队。当增加到第11、12个团队时，来自团队的反馈是他们没法对某个领域有足够的聚焦，不得不经常在优先级之间切换。换句话说：认知过载。Y Soft的考虑是拆分成LeSS Huge的需求领域（后来转向两个产品）将有助于团队聚焦于某个客户领域。因此，CEO希望转向LeSS Huge，以使团队能够对某个客户领域有更多的了解和聚焦。他们的考虑是工作在一个需求领域能够在某个领域获得更好的了解和聚焦，同时不失去整体产品焦点和与其他团队的协作。本章稍后将对此考虑进行反思。

当第二次活动于2020年5月举行时，高管同时准备了公司战略的更新。团队已经为这一更新的战略进行了一些产品开发，但由于2020年3月新冠疫情的影响，战略以及伴随着的开发的更新都加快了。因为许多人开始在家工作，“打印”行业的客户和供应商显然有了不同的需求。此外，高管将此视为更新公司战略并加快实现相应目标的合适时机。

公司战略的更新更明确地将重点放在了产品上。CEO非常明确地表示Y Soft是一家产品公司，因此应专注在产品上。该策略可以概括为：

  • 简化向客户提供的产品（例如，定价、安装、基础设施）
  • 利用新技术实现新的客户特性
  • 为不同的细分市场提供新特性，主要面向中小型企业

这不仅大大改变了产品待办列表，还引入使用团队不知道的新技术。因此，团队需要学习新技术和新市场才能实现新目标。

三个团队已经主要在做来自于原先单一产品待办列表中OMNI系列相关的工作，所以他们就转到了OMNI系列产品。其他十个团队已经在做SAFEQ相关的工作，所以他们就转到了SAFEQ产品。当OMNI系列的工作被引入到单一产品待办列表时（在转向两个产品之前），想要工作在OMNI系列产品上的团队已经主动地开始在这上面工作。团队讨论了是否仍然需要三个OMNI系列团队帮助完成某些日常的SAFEQ工作，但他们认为这样做没有多大意义，即使在短期内也没有必要。

3.2.1 考虑拆分成两个产品

Y Soft的产品开发随着时间的推移在增长，因为Y Soft渴望快速发展，成为技术领导者，并能够快速响应市场机会。战略方向的改变极大地改变了产品待办列表上的条目（高达70%），包括使用技术的根本变化。Y Soft转向两个产品的考虑可分为两类：1）考虑将工作“拆分”成较小的关注点（需求领域或单独产品）；2）考虑从客户和市场的角度来看是一个还是两个产品。

薄弱的产品愿景和短期内优先级的频繁变更

高管希望使用路线图来持续讨论下一步做什么，那样就不会失去长期目标。在组织变革的第二次活动（2020年5月）之前，CEO要求产品负责人制定一个产品的“整年路线图”，以便能够识别产品的未来需求，并分析组织应聚焦在哪里。制定这个路线图花了将近一年的时间。因此，产品负责人（注：这是在联合创始人成为产品负责人之前）和支持他的产品市场人员在制定路线图的过程中几乎没有关注（客户）领域。CEO和其他董事会成员清楚地解释了 - 比如在PBR中 - 他们想要的产品方向。然而，产品负责人无法向团队清楚地解释这个产品愿景。他专注于短期的客户截止日期，而忽略了对长期愿景的透明度和解释。这导致了对未来的愿景不一致，并且太过频繁地改变优先级。此外，这还阻碍了团队选择聚焦某个客户领域。

战略方向的改变放大了产品负责人在分享一致的长期产品愿景上的能力不足。由于新的战略方向，产品负责人和支持他的产品市场人员需要将注意力转向不同的客户需求、不同的客户细分市场，以及使用新的技术（对于Y Soft来说基本都是未知的）。此外，产品负责人和支持他的产品市场人员忙于了解需要什么特性，试图与客户和供应商保持联系，但主要还是与内部诸如销售和支持部门讨论需要什么。公司的其他人，如销售和支持人员，参与了大量澄清工作，并帮助决定下一步应该做什么；他们经常参加PBR，以帮助团队对接下来的工作有更多了解。然而，诸多未知让产品负责人在创建产品愿景和决定产品待办列表中的下一项工作上越发挣扎。

团队的认知过载

团队抱怨说他们每隔（很少）几个迭代就会改变在一个特定领域上的聚焦，这让他们很难学习一个特定的客户领域。事实上，这是认知过载，也就是在太短的时间内需要学习太多不同的东西，让他们感到缺乏聚焦。认知过载的主要原因是缺乏对好的产品愿景的分享以及由此带来的缺乏在产品待办列表上的一致性。然而，高管的假设是，通过缩小团队的专注范围来让团队更聚焦，将帮助团队应对认知过载。对Y Soft来说，因为有这样的假设 - 较小的专注范围会增加聚焦从而减少认知过载，想要未来发展和增加更多团队，转向LeSS Huge并随后转向两个产品似乎是合乎逻辑的一步。

如之前章节所述，认知过载的主要根本原因是薄弱的产品愿景和产品待办列表中太过频繁变化的优先级。团队需要学习与战略方向变化相关的新型工作：与云相关的任务以确保SAFEQ将在云上运行，OMNI系列包括硬件设备上的开发和新软件技术的使用，部分用于新市场。结果就是团队需要学习很多关于这些新技术的知识，并了解不同的客户需求。由于经常改变优先级，团队不得不在太短的时间内学习太多不同的东西 - 认知过载。为了能够开发这些新的产品待办条目，团队必须从不同技术（以及客户对这些技术的不同使用）的角度学习，还要学习具有不同产品特性的新型设备。

一个较小但相关的其它因素是团队必须习惯于与更多其他部门密切协作。特别是在PBR中 - 但也发生在迭代评审中 - 许多来自销售和支持部门的人加入了进来。复杂的是干系人对产品愿景没有一致的解释，他们加入有时会争论要遵循的方向（甚至在PBR活动中）。这是缺乏分享好的产品愿景所导致的结果。不同的解释和缺乏清晰度 - 因为在开始开发时没有直接的客户反馈 - 让团队难以理解在实际开发中应该做出哪些决定，他们需要学习和解释许多不同的东西。一个强大且一致的产品愿景 - 以及更少的优先级变化 - 本可以让团队更清楚地了解应该学习什么，从而减少认知过载。团队本可以聚焦在特定的领域或技术上学习，通过增加聚焦来减少认知过载。

已经有了许多团队并希望在未来增加更多团队

想要在未来增加更多的团队并不是拆分成两个产品的主要原因，但高管肯定也考虑到了这一点。他们认为拆分成需求领域/转向LeSS Huge（那是在转向两个产品之前最初的想法）将有助于实现增加团队数量的雄心。

在讨论转向两个产品时，有13个团队工作于单份产品待办列表。由于存在一个最多能有“8”个团队工作于单份产品待办列表的经验法则，高管将其作为拆分两个产品的原因（尽管不是主因）。转向LeSS Huge的合理原因应该是当产品负责人开始超负荷，无法再全面看管市场、干系人和产品待办列表。“8”这个数字只是一个对产品负责人会开始超负荷的常用经验值。

不同的客户、市场和销售渠道

最终，他们用来支持拆分成两个产品的主要理由是SAFEQ和OMNI系列在客户、市场和销售渠道方面的差异。高管从OMNI系列和SAFEQ的开发中了解到这些产品从客户、市场和销售渠道（B2B与B2C）的角度来看非常不同，这引发了是否拆分成两个产品的讨论。CEO、战略规划师和所有产品VP的另一个基本假设是这两个产品之间几乎不需要协作。因此，就不需要或希望在两个产品之间共享知识，从而也就不需要为交叉学习去优化。

3.2.2 关于多个产品的LeSS视角和如何定义一个产品

作为背景：本节重点讨论LeSS使用的适应性提升以发现最高的客户价值或满意度这一优化目标。对于其它优化目标，另外的考虑可能是与其一致和有效的，但由于它是LeSS的优化目标，本节将重点讨论这一点。

关于产品定义的LeSS规则

关于产品定义的LeSS规则:

产品的定义应该是在实际可行的前提下尽量宽泛并且以终端用户／客户为中心。随着时间的推移，产品的定义可能会扩大。我们倾向于更宽泛的定义。

让我们来拆解这个规则，并对Y Soft的（两个）产品的定义进行反思。

  • “在实际可行的前提下尽量宽泛”</br>从整体产品焦点的角度来看，Y Soft可以从宽泛的产品定义中获得以下好处：
    • 团队根据客户需求和市场机会从一个主题转向另一个主题的适应性
      LeSS的优化目标是能适应不断变化的需求，以能实现最高的客户价值。当团队被限制在一个狭窄定义的产品中时，他们不太可能适应其产品定义之外的工作，因为整个产品视图、对客户和市场的理解以及产品知识都局限在狭窄定义的产品中。如果是一个产品，团队将有更广阔的视野、对客户和市场更广泛的了解，从而也更容易适应其它类型的工作。当然，这仍然需要学习，但与狭窄的产品视角相比，作为整体产品视角会更容易。
    • 工作在全局最高的价值上
      定义成两个产品会在某个时间点导致产品1的价值明显高于产品2。但是，工作在产品2上的团队仍然会挑选产品2的最高价值来做，而不是挑选产品1中更高价值的条目。这意味着从客户和组织的角度来看，我们挑选了潜在价值较低的工作。
    • 更好的总览和更细粒度的优先级
      选择转向两个产品，公司层面的总览会减少，因为这两个产品有单独的产品待办列表，它们之间也更少对齐。分成两个产品限制了总览，而像OMNI系列相对较小，当时只有3个团队在它上面工作。
    • 避免类似产品之间的重复
      如前所述，Y Soft认为这两个产品是不同的，并预期它们之间几乎没有重复。明显两个产品之间是存在重复的，因为产品需要连接并使用相同的基础设施技术。要考虑的是有多少重复，它能否充分支持转向两个产品的选择。良好的设计也能限制产品之间的重复，尤其是作为单个产品来考虑时。
    • 所有产品的用户体验一致性
      随着产品的增多，用户体验的一致性会变得更加困难，因为需要更多的对齐。
    • 简化组织复杂性
      拆成不同产品意味着为一个产品工作的团队与为另一个产品工作的团队会有不同的协作方式，比如处理自我管理（如招聘）和技术实践。这最终会导致产品之间在组织和协作上出现分化，从而形成更复杂的组织环境。与拆成两个产品相比，一个产品将减少组织复杂性。随着引入OMNI系列作为一个单独的产品，额外的流程、团队之间的约定等使组织复杂化。需要考虑的是这种额外的复杂性有多大，因为组织仍然相对较小。

      来自《大规模Scrum：以少为多》：“通过宽泛的产品定义，所有条目都在同一个待办列表中，从而可以进行细粒度的优先级排序，并增加开发和产品的总览。”
      当有两个产品时，两个产品之间的适应性会变差；例如，当从产品待办列表的角度决定更多聚焦一个而不是另一个时。明确拆成两个产品会产生不同的焦点，开发中较少一起考虑的那些产品决策和产品愿景可能会随着时间的推移而分化。当考虑到随着时间的推移其实是想要扩大产品定义，转向两个产品就背离了这种扩大。

      让我们从一个宽泛产品的角度来看“实际可行”的部分，考虑到：“[…]可能会导致最初的产品定义不够完美。这使得用产品定义作为持续改进的工具成为可能”（《大规模Scrum：以少为多》)。有趣的是，工作在OMNI系列上的三个团队在转向两个产品之前基本上就已经聚焦在OMNI系列上了，除了做“必需的工作”（主要与SAFEQ相关，作为快速响应团队处理支持工作以及发布的职责）之外。虽然团队应对的主要是SAFEQ的实际问题，但从团队的角度来看，把OMNI系列加进来并不被认为是“不切实际的”。
  • “在实际可行的前提下尽量以终端用户／客户为中心”
    OMNI系列和SAFEQ都是以最终用户和客户为中心的，它们被客户和最终用户所认识和理解，并且可以直接向客户交付。从这个角度来看，拆成两个产品是实际可行的。然而，问题是将两者作为一个产品是否不切实际。显然，销售渠道（B2B与B2C）以及OMNI系列和SAFEQ所聚焦的细分市场是不同的。然而，这是否从最终用户/客户的角度验证了转向两个产品的决定？内部作为一个产品并不意味着不能有不同型号的产品以不同名称和商标进行销售。作为一个产品不会影响客户或最终用户，只要你能组织好以客户为中心，并将客户反馈纳入产品待办列表中。这将是一个从外部看狭窄的（比如营销成不同的产品）与从内部看宽泛的产品，它既给你提供了整个产品视图和适应能力，又仍然能够区分不同的客户类型或市场。当优化目标是适应性提升以发现最高的客户价值或满意度时，更宽泛的产品定义是与其一致的。

    如果我们考虑重复的产品/业务功能，客户并不需要与打印和扫描解决方案完全不同的东西，即使两个产品针对不同的细分市场。然而，从重复功能的角度来看，有几件事情可能会发生（来自《大规模Scrum：以少为多》）。需要从SAFEQ移植功能到OMNI系列，这要额外的协调和代码澄清，尤其是在团队长期没有密切协作的情况下。其次，两个产品有共享的基础设施，它在组织上属于两个产品之外的一个团队。这引入了一些相关的组织复杂性，主要在于所需的额外协调。

    让我们看看限制产品定义取得最高客户价值的适应性的共同特征（来自《大规模Scrum：以少为多》)：1）愿景，2）客户或市场，3）领域。如果我们从1）愿景来看，Y Soft内部认为SAFEQ和OMNI系列的愿景是不同的。然而，从很高层次看他们都是帮助客户提供打印和扫描解决方案。对于2）客户或市场，两者确实聚焦不同的细分市场。然而，客户想要的仍然是解决类似问题的方案。这就把我们带到了3）领域。这两个产品仍然围绕着打印和扫描解决方案，并不是完全不同的东西。

    如果深入来看客户/最终用户“实际可行”的部分，我们可以说作为一个产品也是可行的。销售和市场部在相同的组织结构下延续了之前的工作方式，与一个还是两个产品并不相关。这意味着从销售和市场的角度来看并非不切实际。

    目前，产品的某些部分并没包括在产品定义中，比如硬件开发（两个产品）以及提供给客户的产品安装和支持（SAFEQ）。从客户/最终用户的角度来看，当组织通过学习改进使得“实际可行”逐渐发生变化时，在未来其它部分就可以包括在产品定义中。
  • “随着时间的推移，产品的定义可能会扩大”
    转向两个产品的原因之一是薄弱的产品愿景。LeSS的第一本书（《大规模Scrum：以少为多》)解释了宽泛产品定义的不切实际之处：“越来越难以表达清晰且吸引的产品愿景”。然而，产品愿景薄弱的根本原因并不是产品定义的宽泛。

    我们可能会在未来扩展产品的定义，因为希望不断改进以达到完美，比如通过“扩展完成”来把“完成外”工作加入到产品定义中。自从开启LeSS的旅程，Y Soft已经在为期4天启动LeSS导入的活动中做到了这一点（将人员组合起来创建跨职能团队），并在之后进行改进（比如把架构师和私有基础设施加到团队）。然而，由于转向两个产品，产品的定义却缩小了。

    通过选择拆成两个产品，Y Soft基本上是限制了产品定义，而不是扩展它；这与适应性提升以发现最高的客户价值或满意度的优化目标不太一致。当然它可能对其它优化目标是有价值的。
  • “倾向于更宽泛的定义”
    在前一点中，我们讨论了由于选择转向两个产品而带来的产品定义缩小。在决定转向两个产品之前的讨论中，明确讨论到了有导致“多产品”战略的风险，即创新发生在产品之外和团队之外。从长远来看，Y Soft有风险最终会产生几个产品，1）从宽泛的产品定义来看应该是一个（或至少是更少个数的）产品，2）是在没有充分利用现有产品的集成和知识的情况下在团队之外开发的。高管承认这一风险，但提到他们不会让这种情况发生，也不是应该发展的方向。
从客户那里获得反馈

有一件事在讨论转向两个产品时没有被考虑在内，那就是基于OMNI系列开发的学习（来自实际的验证）。在决定转向两个产品时，OMNI系列还没有推出，也没有经过实际客户的测试。首先，尚不清楚OMNI系列会卖得好还是只有少量，因此还不能证明作为一个独立产品的合理性（注：在撰写本文时，OMNI系列已经卖得很好）。其次，还没有实际客户的反馈，它可能会改变OMNI系列的优先级和方向，或者验证所做的想法和主张。如果坚持这个方向，可能会发生产品定义上的不同推理和讨论，由此可能会产生另一个决定。

创建一个更简洁的组织

更宽泛产品定义的原因之一是创建一个更简洁的组织。两份产品待办列表、两个产品负责人、更多（仍是并行的）迭代、通常更多的经理（因此有额外的对齐）和其它事情导致组织更加复杂，比如跨产品就公共部件进行额外协调。在一个交互效应是主要影响因素的系统中，减少交互效应有助于使系统变得更好。拆成两个产品与更简洁的组织相反，是有负面后果的局部优化，比如额外的交接和复杂的协调。然而，对于团队来说没有太大的变化，组织的其它部分也没有为转向两个产品作出调整（除了有两个产品负责人而不是一个）。从短期来看，转向两个产品可能并没有导致一个更加复杂的组织，因为基本上没有因为这个决定而发生太多变化。然而，从长远来看，由于交互效应将会有增加的复杂性。愿景和方向会出现分化，共同部分需要额外的协调，而这很少顺畅，从而导致更多的重复和不一致。团队将对彼此的工作和工作方式越发不熟悉，导致额外的协调问题和团队承担的责任减少。

协作

LeSS中一件至关重要的事情是协作（主要是在团队间和团队内），并鼓励尽可能多的协作，这与常见的说法“开发人员之间的协作效率低且困难，所以调整组织方式以避免它”形成了鲜明对比。LeSS的优化目标是适应性提升以发现最高的客户价值或满意度。团队之间的协作 - 以及必然会伴随的学习 - 对于实现这一优化目标至关重要。两个产品导致两个（不同的）优先级，这限制了团队之间的协作，进而限制了适应性。

在许多组织中，协作（和学习）往往被视为成本高昂或效率低下。为了在产品层面上学习，协作是必不可少的。对于一个复杂产品，团队需要协作、共享和共同学习，并相互教学，以便能够工作在客户看重的特性上。协作效率低下的想法往往来自于只看表面，而不看根本的系统和结构。使协作成本高或效率低的力量通常是组织中相应的结构。比如等待他人（因为团队是单一专业化的），在产品中使用不支持协作的技术，或者在团队和产品组之外进行决策，这些都是局部优化。

一个与两个产品

在前几节中，我们得出的结论是至少在短期内转向两个产品并没有太大的变化，尤其是对团队来说。从这个角度来看，拆成两个产品在短期内并没有太多缺点，而且由于团队仍然非常了解彼此，只需有限的额外努力就能在特性上保持一致。

对于适应性提升以发现最高的客户价值或满意度的优化目标，有几个原因可以解释为什么转向需求领域而不是转向两个产品会更有利。一个产品的条目被感知的客户价值相对于另一个产品的条目将随时间推移而变化，这将导致其中一个产品对客户和组织作为整体来说产生的价值较低，因为一个产品的团队只会根据这个产品的产品待办列表来工作。这同样会发生在一个需求领域的最高价值工作不及另一个需求区域的工作。然而，当这种情况发生时，产品负责人可以决定将团队移到另一个需求领域，调整起来相对容易。尽管总会有一些延迟。此外，拆成两个产品可能会伴随着创建各自的产品组，与产品关联的各自经理和专家职位。由于这些位置的存在，改变一个产品相对于另一个产品的优先级将很难。而在LeSS Huge中，唯一的产品负责人可以简单地选择将团队从一个需求领域移到另一个，因为需求领域没有与设置了经理和其他职位的组织结构相关联。这样一来，在整个产品层面上改变方向相比两个产品会容易许多。此外，当一个客户请求跨多个产品，并且每个产品都有私有代码所有权的边界时，这将增加跨产品客户请求的交付周期时间。Y Soft并没有创建各自的产品组，而是保持了组织的简洁，如其它部分所述。

其它选项

对于所感知到的问题，除了转向两个产品之外存在其它选项。

其中一个选项是做团队已经在做的事情：团队聚焦在特定领域上。工作在唯一产品待办列表上的其中三个团队在PBR和他们的迭代中重点关注与OMNI系列相关的条目。这样做仍然给予了OMNI系列聚焦，但没有失去在其它时刻切换并专注于产品不同部分的适应性，并在需要时跨团队协作以提高适应性。随着联合创始人成为SAFEQ的产品负责人（见本节），愿景和优先级更加清晰，团队能够根据愿景和优先级更多聚焦在某些客户领域。如果这发生在讨论和决定转向两个产品之前，决定可能会有所不同，因为这个问题很可能已经得到解决。

另一个选项是将OMNI系列工作转到一个需求领域。Y Soft的需求领域需要进一步探索和定义。当产品愿景和焦点 - 尤其是从产品负责人的角度来看 - 是需要解决的有效问题时，这一选项将有机会创建更好的产品愿景，并让更多客户反馈融入其中。作为唯一产品待办列表中的不同需求领域，仍然会有一个产品负责人能够决定优先级，包括OMNI系列的工作；他能够决定聚焦OMNI系列以外的其它内容，或者在OMNI系列销售非常好且客户需求很大时更多地聚焦OMNI系列。这仍将获得在优先级设定上的适应性，团队也将有更多选项来协作和相互学习。此外，在有需求领域的LeSS Huge中，团队为了响应发现成果从一个领域慢慢转到另一个领域是容易适应的（虽然意识到认知过载的问题），但另一方面在有两个产品的情况下，在两个产品组之间移动团队至少在“政治”上也是困难的。

3.2.3 针对辅导和咨询的反思

从敏捷教练的角度来看，这里描述的反思在与CEO、战略规划师和所有产品VP讨论转向两个产品时并没有包括。其中一些见解在讨论当时考虑到了而且也很清楚，但许多见解是事后才学到的。因此，外部顾问和敏捷教练在与高管的讨论中就选择两个产品还是一个产品多个需求领域未能很好地解释它们的组织后果。讨论转向了语义，即它们实际上是否是两个产品；而讨论应该就选择“独立的两个产品”还是“一个产品中的两个需求领域”所会产生的组织后果展开。具备这些见解，转向两个产品的讨论会有所不同，结果也可能不同。这就是为什么我觉得在这个案例研究中分享我们的经验很重要，以帮助处于类似情况的其他人。

3.2.4 产品负责人的更换

伴随变成两个产品，CEO决定更换产品负责人。之前的产品负责人 - 当时仍然是一个产品 - 是产品市场部门的一个人，而他们部门的同事则会帮助团队进行PBR和其它活动。对两个独立产品的新关注使CEO决定从董事会中为每个产品选择一名产品负责人。新的产品负责人都能更好地对产品做出战略决策，因为他们有更多的授权，并在Y Soft董事会内讨论战略。前产品负责人仍然作为产品市场的成员之一参与其中。

尽管来自产品市场团队的产品负责人有被授权与团队工作并进行优先级决策，但他很难做战略决策，也很难接触到高管的战略思维。正因为如此，产品方向不得不经常改变。新产品负责人作为董事会成员积极参与有关产品及其背后战略思想的讨论，这使得决策及设定和分享产品方向更为容易。除了让联合创始人担任产品负责人外，还有一位来自组织其它地方经验丰富且备受赞赏的同事作为助理PO（LeSS实验）加入，他不做优先级决策，但会帮助产品负责人和团队。

3.2.5 发生了什么？

高管决定拆分产品待办列表，让更少团队工作于其中一部分产品待办列表。他们的理由是以此能解决产品负责人无法拥有和分享好的产品愿景以及对客户和市场需求的理解这一问题。高管（CEO、战略规划师、所有产品VP）最初是想通过转向LeSS Huge来拆分产品待办列表，但因为在此期间OMNI系列新兴发展，他们最终决定了拆成两个产品。高管的假设是通过拆分，PO和支持产PO的产品市场人员会有一个更好的总览，可以更好地了解产品待办列表，更好地了解客户和市场需求。团队将在一个客户领域上更多聚焦，因为需要关注的（部分）产品待办列表变小了，并且更少团队工作于那个较小的（部分）产品待办列表。

因此就转向了两个产品，每个产品都有一个产品负责人（都是董事会成员），每个产品都有一份产品待办列表。已经在OMNI系列上工作的团队转向工作于OMNI系列的产品待办列表（3个团队），其他团队转向工作于SAFEQ的产品待办列表（10个团队）。新拆分产品的第一个迭代在2020年11月开始。

3.3 检视

3.3.1 针对薄弱产品愿景的检视

整个组织都关注战略改变，公司的所有重要人员都可以提供帮助，这意味着更多地参与PBR和迭代评审。战略、产品愿景或路线图与产品待办列表之间没有很好的对齐。需求和优先级经常发生变化，产品负责人和支持他的产品市场人员无法跟上CEO和市场VP期望的节奏，这导致产品愿景薄弱、团队对产品愿景缺乏理解。这导致了“只是做”产品负责人被告知的事情，因此也让团队更难理解方向，更难挑战客户和市场需求。由于实际客户参与开发的时间太晚，所以在很长一段时间内反馈完全只来自组织内部。不同的干系人对要做的工作有不同的想法和需要（比如支持与销售）。这也推迟了路线图的制定。

3.3.2 针对认知过载的检视

团队频繁改变焦点的根本原因是产品愿景薄弱，而且短期内过于频繁地改变优先级，以至于团队感到缺乏聚焦。这对团队来说是认知过载，需要在太短的时间内学习太多不同的东西，他们觉得这是缺乏聚焦，无法在一段时间内专注于特定的客户领域。高管确实注意到了经常变化的优先级，但没有将它跟认知过载的根本原因关联起来。如果解决了这一问题，可以帮助团队在一段时间内聚焦在特定客户领域，并专注于该领域的学习。或者通过举办领域研讨会或架构研讨会等方式来对客户领域和/或架构给予额外关注。敏捷教练在帮助产品负责人更一致地分享长期愿景这方面的尝试失败了，也没能帮助到团队减轻认知过载。

当联合创始人成为PO时，就有了一致的产品愿景，也有了明确的优先级，以及PO和团队之间的良好合作。这提升了团队的聚焦（感受），并减少了认知过载。内部干系人和外部客户的满意度更高了。团队有一个更好的基线来进一步改进，并且更清楚在哪里聚焦以及长期该学习什么。这证明了团队的认知过载并不是由于产品的宽泛造成的，一位具有强大产品愿景和更一致优先级决策的产品负责人可以消除其根本原因。

3.3.3 针对产品具有不同客户、市场和销售渠道的检视

首先，如果你用一个宽泛的产品定义，客户和市场会因此很不同吗？仍然是有客户想要打印和扫描解决方案，尽管这些客户会在不同的细分市场。购买OMNI系列的客户并不需要与打印和扫描解决方案完全不同的东西。当你从外部视角拉远来看，这些产品都非常相似，尽管从内部视角来看可以很不同。第二，销售渠道是不同的。但这是否是拆分产品的充分理由？OMNI系列将要求直接向客户销售，创建网店，并采用不同的促销方法。但是在一个产品中就不能有不同的销售策略吗？存在许多宽泛的产品定义，其中产品销售给不同类型的客户和使用不同的销售渠道。Office365可能就是一个例子 - 内部基于宽泛产品来思考，同时又有不同的销售渠道、客户类型，甚至部分产品是单独销售的。

产品开发被拆成两个产品，但市场和销售仍保持着与以前相同的结构，作为一个部门兼顾两个产品。从产品市场来看，一些人专注于OMNI系列，但他们仍在同一个产品市场部门工作。这与两个产品的市场和销售非常不同的说法相矛盾。产品开发基于这一说法改变了结构，而市场和销售则保持了同样的结构。在产品开发之外（比如市场和销售）的差异显然并不大，那么它为什么能支撑对产品开发进行拆分？

3.3.4 针对适应性的检视

战略变化导致产品待办列表的优先级发生了重大变化，团队需要学习许多新技术，还需要对客户采取不同的方式。至少那三个团队从一开始就完全聚焦在云技术上，开发并配置了基础设施，改变了许多面向客户的功能，解决了安全问题等。他们在六个月内交付了一个在云上能用的环境，包含了大部分面向客户的特性。这证明了组建跨职能团队并聚焦学习确实有效！这些团队能够探索并理解需要什么，学习新技术，并用这些新技术成功开发出产品；而在他们开始工作之前仅准备了非常有限的前提条件。主要是来自IT部门的人员与团队紧密工作建立了基础设施，并分享了他们提前做的云技术相关试验。我们无法想象另行组建没有客户和产品上下文的新团队会有效，而这在基于项目的组织中却经常发生。在新冠疫情发生之前，Y Soft的高管仍然认为LeSS（和Scrum）是提高交付、质量，并做到信守客户交付协议的方法。战略变化和客户想法的变化使高管意识到LeSS的组织变革和团队端到端交付客户特性的能力使他们能够迅速改变。简言之，他们获得了适应的（敏捷的）组织这一好处。

3.4 适应

以下总结了在转向两个产品过程中发生的主要调整：

  • 两份产品待办列表，两个产品负责人
  • 充分授权的董事会成员成为产品负责人

这带来了以下主要结果：

  • 对于整个产品更低的适应性，在产品之间需要更多的对齐和开销
  • 改善了产品愿景和方向
  • 减少了团队的认知过载

自从转向两个产品又发生了许多小的改进和变化。特别是关于团队之间一起工作，聚焦长期愿景，提升技术卓越，并学习更多客户领域。

两个产品之间的团队开始更多地一起工作，经常就跨产品主题进行多团队PBR，并在迭代中就跨产品主题进行协作。这也表明了相比两个产品，以一个更宽泛的产品定义但包含多个需求领域作为LeSS Huge导入会是更一致的选项。在一次整体回顾中，一些团队成员希望更好地了解产品之间的重叠部分，当把架构建模出来时他们数出了13个共享组件，进一步表明同属一个宽泛的产品。这引发了对话，后来PO与CEO决定将两个产品合并回一个产品，再次以一份产品待办列表工作，而来自SAFEQ的PO（联合创始人）则作为唯一的PO。这证明两个产品几乎不需要协作的假设并不成立。由此带来的主要影响是来自SAFEQ的团队必须学习并帮助支持OMNI系列，这对他们来说是相对未知的。来自OMNI系列的团队仍然熟悉SAFEQ的大部分内容，这使他们更容易应对。团队找到协作的方式，并与其他团队“结对”以确保所有团队都能支持好OMNI系列和SAFEQ。

结论

Y Soft由于导入LeSS获得了巨大的收益。团队能够更好地看到和理解整个产品，此外还能够交付比以前更多（且更有影响）的端到端以客户为中心的特性。在开始导入LeSS之后，团队与客户和供应商有了更多的直接联系，因为他们是开发以客户为中心的特性，而不是组件需求。像任何做出重大变革的组织一样，Y Soft也有自己的挣扎。在导入LeSS的第一年，团队并不总能理解分担“痛苦” - 比如所有团队都做回归测试，在团队之间轮换支持职责，以及更多 - 的做法；而且为了获得整体产品焦点进行的学习也是大量的。CEO曾表示导入LeSS的最大成功在于“我们成功地增加了很多人，而且还能够交付越来越多”，同时也进行了大规模的协作。

随着2020年新冠疫情大流行，Y Soft改变了战略。产品待办列表的优先级改变了大约70%；战略变化的结果是团队需要比以前更快地学习新技术并了解新的市场需求。因为更高适应性的组织，团队更容易适应这些新技术和市场。在以前面向组件的团队结构中，团队工作于许多项目和干系人的不同产品待办列表，他们的适应性永远不会如此快速有效。当然还有其它变化帮助到Y Soft的改进，比如决定在没有经理的情况下工作。

Y Soft的LeSS导入的独特之处在于不断检视和调整组织设计的意愿和勇气。正如本案例研究中所述，它不是开始LeSS导入然后只是进行小的改进，而是考虑并执行更大的变革。

关于Y Soft的LeSS导入的更多公开信息

关于Y Soft的LeSS导入的更多信息可以从这些公开资源中找到：

关于作者

主要作者：

  • Mark Uijen de Kleijn

贡献者：

  • Georgiy Zhytar
  • Milan Schwarz
  • Jürgen De Smet
  • Michal Donát

评审者：

  • Viktor Grgic
  • Craig Larman

译者：

  • 车晓雪/Hebe
  • 蔡世超/Sally
  • 吕毅