前言

业务敏捷可以定义为一个组织重塑自我并快速适应环境变化的能力。克劳斯.利奥波德在他的书《Rethinking Agile》中提出，人们需要优化交付客户价值的流来实现业务敏捷。通过优化流，你迟早会注意到需要组织结构做什么样的调整来加以支持。

首先，关键是理解敏捷的真正含义，就像敏捷宣言中构想的那样，它并不是组织交付客户价值的速度，而是组织以低成本快速响应变更的适应性。（参阅《Scaling Lean & Agile Development》中 Be Agile_一章）。利奥波德对于组织变革还有这样一个观点：在持续地关注系统优化目标时，人们会注意到那些阻碍改进的因素。然而通过系统思考，长时间在实地的观察和实践，对现存系统动态的反思，人们也可以预见到那些阻碍快速适应能力的相对明显的现存组织障碍。在这个故事中，一个组织学习并最终看到影响大规模适应性的组织障碍，它经历了漫长而痛苦的过程。更糟糕的是，很多管理层试图保持传统管理现状而仅仅将事物标记为"敏捷”，而不是去预见 - 或者愿意去预见 - 相对明显的障碍并在一开始就进行必要的变革。简而言之，这个过程恰恰反证了LeSS中的关键导入原则（“对于产品团队，要在一开始就建立LeSS的组织架构，这对导入LeSS非常关键”_）以及由此带来的后果。

所以，接下来的案例说明了，如果组织没有在一开始进行合适的组织设计，会发生什么情况。从开始的传统组织架构和管理方式入手，可能混有一点伪Scrum元素，LeSS要求的组织设计也许会浮现。但这将会是一个更长、更危险的旅程，因为它可能不会带来导入LeSS所预想的好处。为什么？因为一旦没有立即采用新的组织架构，那股保持组织现状的强大力量极有可能会获胜（参阅拉曼组织行为定律）。

本案例的关键"反事实"洞察：如果你想开始业务敏捷的旅程，期望减少过程中的许多痛苦，并快速获得LeSS所预期带来的适应性上的提升，一定要在导入LeSS的开始阶段就建立合适的组织结构，就象LeSS规则所倡导的那样。

开始之前的评注

LeSS就是（多团队的）Scrum，Scrum就是单一团队的LeSS。（参阅原则：大规模Scrum也是Scrum）。为了让本案例中的描述更加准确，我还是会澄清哪些是Scrum指南中的规则，哪些是LeSS指导方略中的规则。在参与这个案例的过程中，我受到less.works网站的积极影响，参加了Bas Vodde和Craig Larman的LeSS实践者课程，并花费了大量时间阅读最初出版的两本LeSS书籍。可惜的是那时第三本书还没有出版。在这个案例中，我阐述了我们尝试过的LeSS实验，并且也会关联我们遵循的LeSS原则、规则和指南，尽管那时并不知晓。

简介

下面的案例涵盖了我从2015年2月到2016年9月在一家公司Sys的IT组织做外部教练的时光。Sys是一家来自德国的从事软件行业的跨国公司。因为我已签署保密协议，所以不能在此公布公司的真名和其他相关的公司信息。时间回到2014年底，Sys着手用一个平台来变革公司软件销售方式，取代现有各种外部合作伙伴平台。这个平台的诞生标志着Sys迈入电子商务新途径的里程碑，不仅重新思考了如何直接地向客户销售软件，还重新定义了卖什么（例如，除软件以外的数据）和怎么收费。

这背后的想法是创建一个网上商城，客户可以通过最小的交互，从Sys或是其他第三方软件发现、尝试和购买软件、内容和数据。目标是通过电子商务产品"SAP Hybris Commerce"来提供像亚马逊一样的简单流程，同时涵盖多样的产品部署（就地部署和云解决方案），支持不同的支付方式（信用卡和PayPal）。

2011年，我曾在负责所有内外部平台的Sys IT部门工作过，这些平台跟Sys商店很像，那时我们整个部门开始将瀑布模式替换成Scrum。在用（单团队）Scrum的方式搭建了两个平台之后，我离开了这家公司，去支援其他客户的敏捷之旅；在2015年的早期，我又重新加入Sys来支持这次重要的旅程。

变革之前

系统架构

在我加入的时候，有四个团队并行工作，研发新功能或者增强现有平台，并用固定的时间表合并代码，然后进行好几周的集成测试和验收测试。系统格局是一个复杂的三层结构，包含基于Spring框架的主要J2EE应用程序平台SAP Hybris Commerce，用于存储数据的SAP Hana 数据库，基于SAP PI服务器与SAP ERP和SAP CRM的同步，还有额外的第三方服务用作分析、处理信用卡支付或用户生成内容的集成。

变革之前的组织结构

图3是组织结构。有三个开发团队，两个在欧洲一个在美国，并行工作在系统的不同部分。还有一个架构团队，负责新特性的软件整体设计，以及一个测试团队，在不同团队的代码合并之后进行集成测试。此外，另有一些后台开发（SAP ERP/CRM）专家、DevOps专员和UI专家，他们没有加入任何研发团队，而是建立了自己的团队。欧洲的团队成员（随机地）分布在德国、波兰、西班牙、爱尔兰和保加利亚。这是因为Sys只有六名公司正式员工，其他所有团队成员均来自于专门从事SAP Hybris研发的第三方供应商。

除了技术团队，还有一个超大的业务组织来支持软件的研发和运营。在第一层，经理们带领一个小团队来进行特性的优先级排序、编写蓝图、执行用户验收测试并启用功能。在第二层，又有一个团队专门负责整个产品组合、需求排序以及业务方用户验收。在第三层，是由三个项目集经理组成的项目集管理，一个来自业务（Sys Digital），一个来自Sys IT，还有一个来自Sys Education的项目总负责人。另外，还有一个支持项目集管理的项目和质量管理办公室。为了跟踪研发和业务的进度，每周还有工作流周会，干系人状态周报，以及从项目办公室汇集到管理团队的书面项目集更新。

痛苦的最后期限和变革的必要

当我在2015年2月底加入时，平台基本上已经可以使用，只差正式宣布。各团队还在冲刺最终官方发布日期：2015年5月5日。到时候公司会在美国举行有史以来最大的会议，首席数字官会当场向公众演示这个平台。所有正在研发的功能都是官方需要发布的功能，所以，项目办公室制定了一个看起来能在5月2号发布所有功能的严格的项目计划。该计划包含了研发阶段、系统集成阶段，用户验收测试以及回归测试，就像我们通常说的瀑布模式。

在三月的最后两周和整个四月项目进入一个动荡期。时间表正渐渐延期。当并行工作在不同功能的团队将他们的代码合并到主代码仓库后，很多之前已经测试通过的功能不再能使用或者表现异常。不停修复这些问题又带来新的问题，并且还经常突然接到必须立刻实现的新需求。在此之上，之前从未考虑过的安全问题和负载测试现在也必须解决。管理层变得十分焦虑，每个人不得不工作更长的时间来尽量满足计划。在四月的最后两周，还建立了一个"作战室”，所有的经理、团队负责人和架构师都在这个房间从早到晚不停的清理障碍以保证发布的所有准备工作都做好。最后，开完数不清的升级会议和成百上千小时的加班之后，团队终于能够在大会的第一天发布平台的新版本。

经过了如此痛苦的发布，对管理层来说，毫无疑问现有的研发方式已经不能支撑公司的雄伟目标，那就是销售指数级增长，能快速尝试新的商业模式和推出完全不同的产品。Scrum作为一个敏捷研发框架，专注于首先交付最高业务价值，持续关注透明性、检视和调整，这些都建立在基于经验过程控制的理论之上，它成了一个自然而然的选择。然而要导入Scrum或者LeSS都被认为极其困难，不仅仅是因为组织层级设置和对分散在不同地方的各种技术专家的依赖，还受到巨大营销渠道的影响，即每年有两次不可更改的作为大里程碑的重要峰会。

引入变革

作为一个偏好大规模Scrum的经验丰富的敏捷和Scrum教练，我被要求建议"研发部门"应该如何改变工作方式以应对当前的挑战。 我的挑战因此是（1）让所有人都意识到为了应对挑战_不只是研发部门而是整个组织要改变_；（2）帮助参与者_通过理解为什么_来**_拥有_**变革背后的想法，而不只是跟随我的想法遵循我的建议而已。 在一次上层管理者（包含Sys首席数字官）的会议中，我展示了从和业务和研发代表的对话中收集到的关于挑战的总结。它包括：

• 业务挑战（摘录）

单个特性和产品能力的优先级不明确

明确标注_已完成的工作在后期出现问题

• 技术挑战（摘录）

可用性和基础设施问题（性能，端口关闭等）妨碍了日常运行

整个部署流程耗时太长。常常缺少某些部分（模版，后处理等）

“架构师"们忙于做构建流程、合并代码、以及基础设施的建立/配置这样的手动任务

使用各种分支而不是基于主干的开发，导致代码合并的工作量巨大；并且质量很低，有许多缺陷/问题

测试数据的的创建是一个非常耗时的过程并深受知识缺口的影响

在准备这个会议的过程中，我还收集了管理层的整体改革目标。基于与管理团队成员一对一谈话和访问，我总结了如下几点：

• 通过清除浪费来优化系统以更快地向客户交付价值

• 给组织赋能以使其更加理解客户并更快响应新的需求，还能从已发布的不足中学习和调整

• 改进交付代码质量并减少缺陷/问题的数量

• 关注整体产品，对以客户为中心的需求优先顺序可视化

• 增加各团队正在进行的工作的可见性

第二个目标跟LeSS中的整体系统优化目标是一致的，即学习并交付给付费客户最大"价值"所需的最高适应性。其他目标可以通过对LeSS原则的特别关注而实现（例如：第一个可以用排队论和精益思想）。所以我非常高兴地看到研发团队和管理层都喜欢应用Scrum，把它作为一个软件研发框架并紧贴敏捷价值观和敏捷原则。我个人觉得，为了成功，我们不仅要激励那些有着清晰目标的个人，还需要得到组织高层的支持来移除障碍并赋能变革。这已在_LeSS指南三个导入原则（自上而下&自下而上）_中体现。

然而，我也注意到这里并没有对Scrum的理解形成共识，需要一个工作坊来培训所有人并对组织变革达成一致。这也体现在_LeSS指南：开始_中。

我在管理层会议中的总结报告中提出，在开始变革之前需要一些前提条件：

• 业务和研发需要对工作模式达成一致，才能帮助达成上述目标

• 我们需要（1）自组织的（2）跨职能的（3）同在一地的（4）长期的 团队 （见LeSS结构规则）

• 团队需要Scrum培训，创建工作约定并对于完成的定义达成一致

• 建立产品待办列表，包含技术项和业务项

管理层一致同意上述几点，给了一个月的时间来准备过渡到新的工作方式。

开始

下面几段描述了我们当时对组织变革还认知有限的情况下所做的几个启动步骤。我会将它们关联到LeSS的指南和规则 - 我们遵循了哪些；更重要的是强调了那些我们本应做得不一样的部分。

首先，我们组织了一个两天的工作坊，参与者来自研发部和业务部。这个工作坊由我本人负责，并带了一个助教，主要是做Scrum培训。这个做法与LeSS的导入指南一致：LeSS指南：开始 0，培训每个人。

在工作坊结束时，参与者理解到Scrum不是一项实践或者一个定义好的方法，而是想be agile而非"do agile"所需要的组织设计变革。这个工作坊还在研发和业务之间建立了强有力的纽带。

**回顾中得出的关键教训是下一次这样的工作坊要包含所有的高层管理干系人（而不只是几个）。**通过让高级管理人员思考LeSS组织设计的含义，例如团队结构、层级结构、所在地策略、角色、流程和政策，不仅可以获得对更改组织结构和政策的支持，还可以从一开始就建立正确的结构，这能省去很多麻烦 – 正如我们经历的那些。

**第二个关键教训是持续关注如何让参与者探索、理解Scrum和LeSS的意图、想法和组织设计变革的含义 ，而不是仅仅关注教授Scrum或LeSS的知识。**为了更聚焦在原因上，在LeSS原则（例如：系统思考、精益思想）的支持下，让参与者从中导出他们自己的工作模式。这样做使得他们参与更加深入，因为我们更少关注拷贝"最佳实践"或者一个方法理论，而是理解系统优化目标、现有系统动态是如何符合（或不符合）该目标的，以及系统可以通过怎样的改变来更加符合目标。

定义"产品”

就像_指南:开始 1. 定义"产品”_ 中说的，产品的定义是"你做出的最重要的决定之一”，因为它决定了导入的范围、产品待办列表的内容，以及谁是最合适的产品负责人。在我们的案例中，产品的定义受到产品愿景和已有的组织结构的约束。想了解更多关于约束产品定义的因素，可参见_LeSS指南：你的产品是什么？_

产品的愿景是"创建一个简单连贯的数字体验用于寻找、尝试、购买和消费Sys软件以及其合作伙伴的解决方案”，并"简化客户的数字购买过程和体验，准确地提供他们想要的东西，在他们想要的时间和地点”。目标是通过这个由当时的CDO（首席数字官）带领的Sys数字部门负责的电子商务产品来实现。电子商务站点用来提供来自Sys不同部门和其他公司的产品。在理想状态下，产品的定义会随着时间扩展（见_LeSS规则：产品的定义应该依照实际情况，尽可能广泛，并以最终用户/客户为中心。随着时间的推移，产品的定义可能增加。_ **更广泛的定义是首选**）。然而从开始的角度来说，有限的产品范围给了我们更清晰的产品定义。

一个非常棘手的已有约束是Sys的IT部门没有任何研发工程师有SAP Hybris Commerce Suite的经验。于是他们聘请了一家专长于此的公司，为他们提供了散布在欧洲各个地方的工程师。然而，就像我们将看到的那样，这极大地影响了团队的建立。

建立团队

第三步，我们关注在建立团队和首次组织变革。

之前提过，最初我们的特定组件团队（比如SAP CRM后端或SAP Hybris Commerce)与单一职能团队（比如架构团队或测试团队）之间是割裂的。在培训时期，我们强调如果想要改进我们的能力来交付以客户为中心的最重要特性的话，就需要建立跨职能、跨组件、稳定并长期存在的特性团队。这反映了_第二条LeSS组织结构规则_，其背后的原因在_LeSS指南：理解特性团队_中作为总结出现，其细节可参考第一部出版的LeSS书籍《Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum》。第二部LeSS书籍中的两个实验也表明了这一点：_避免单一职能团队_和_避免组件团队_。

新建的团队用特性团队来组织，包含了拥有不同技能的各类专家。最终我们建立了四个团队，每个团队里包含三到四个SAP Hybris研发，一个SAP后端研发，一个UI专家，两个测试专家，以及一个专长持续发布的架构师。我们解散了专业测试组和架构组（把他们融入特性团队），并建立了社区，在那里专家们可以定期交流并对齐工作方式。在"社区"部分我会就此详细说明。尽管很不幸合同需要我们依然有带着专家头衔（比如"解决方案架构师"或是"测试专家”）的人，但是我们从一开始就明确团队成员们"愿意把头衔放在门外”，学习必要的技能并帮助他人以便能够在每个Sprint结束时创造一个已集成的产品增量。

开始时每个团队配备一个专门的Scrum Master，因为绝大部分Scrum Master和团队都没有LeSS的经验。为了以身作则，我在其中一个团队里担任Scrum Master。通过我的培训和辅导，一个前项目经理逐渐可以满足Scrum Master的要求并在三个月后替代了我的位置。

在第一年，一个Scrum Master只能支持一个团队，后来有些Scrum Master可以同时支持两个团队。他们的关注点从帮助团队改进工作方式转移到揭露阻碍团队提升绩效的组织功能障碍上。这反映在_LeSS指南：Scrum Master关注点中。

系统运作

Sys的IT部门曾经经历过许多项目的实施，系统在几个月到数年内被构建，但到某个时间点，预算就不再增长而只通过配备离岸团队对系统持续运作和维护投资。在过去，这种方式会在"实施预算"快耗尽前引入一个"交接"阶段。这里也包含了对离岸团队的知识传递。这个"交接"阶段总是十分痛苦，关注点常常只在为维护团队创建"刚刚好"的文档，而这样会导致系统恶化，因为维护团队对每个功能最初背后的原因没有足够的理解，而提供的资金也只能增加一些小的功能而不足以改进整个系统。

我们在"培训工作坊"期间设法解决这个问题，保证有部分"维护预算"来将离岸研发人员一开始就整合到特性团队中。他们刚开始对SAP Hybris Commerce系统或SAP后端系统一无所知，但通过结对和mob编程，他们逐渐能从"仅仅修复问题"到实现系统新增功能。这对系统的代码质量产生了巨大的影响，因为（离岸）团队成员特别关注技术债和必要的文档随系统而增长的事实，而他们将是"实施预算"耗尽后的持续负责人，所以常常是他们来提醒其他团队成员关于系统质量的问题。

开始时未解决的组织挑战

在团队最初建立之后，仍有两个挑战未得到解决：分散的团队和与业务人员的集成。虽然这在前期带来了更大的问题， 它们在后来还是被解决了。

第一个挑战是我们团队太分散。之前说过，内部研发部门没有人懂SAP Hybris，所以必须依赖外面的公司提供懂SAP Hybris的工程师。而这个公司的工程师散布在欧洲各个地方，大部分人在家办公。在那时，让所有团队成员搬到一个地方长时间工作是不可能的事情，也没有资金，所以我们建议先做两周的启动活动, 然后每六个月安排一次现场活动。让所有人在一起办公的效果太明显啦，以至于大家很快都意识到这种差别。而对团队结构的调整也极大地改善了团队的绩效。不到一年后，团队就又重新组织，以使大部分成员在一个地方工作。

新的组织结构已经变成了图六这样。

第二大挑战是与业务人员的集成。之前说过，组织里除了真正做市场调研或伙伴关系管理的产品经理们，还有很多在真正的研发人员和真正的业务人员之间的中间人。这些中间人忙于传统瀑布中定义的任务，比如识别下一步做什么、描绘系统蓝图，或做终端测试。同时，研发部门已经习惯了与他们自己的（伪）产品负责人以Scrum的方式工作，这个产品负责人实际上只是一个中间人项目经理。在过去，这个人作为一个团队与业务的接口而存在。在研发这边还常常有一个带伪中间人"产品负责人"身份的业务分析师，负责编写需求和为研发部门澄清需求，以及一个带伪"产品负责人"身份的项目经理充当业务人员和研发之间的唯一桥梁。当我们在"培训工作坊"中讨论这件事情时，大家都清楚这里有管理层的限制和缺乏管理层的支持来从一开始就直接改变组织结构。但是就象在接下来的"唯一的产品负责人"章节所述，这个情况导致了非常多的组织功能障碍。大约八个月之后，我们改变了组织结构，只有一个产品负责人负责整个产品，其他产品经理则对其支持。

启动

“培训工作坊"结束两周后，研发和业务的代表们一起组织了一个大型工作坊，让所有团队成员都来参加这个最初的启动活动。两周内，所有的团队成员都有机会相互认识，相互讨论、反思并就他们共同希望的工作方式达成共识。

这个大型工作坊还涵盖了两天的Scrum培训（所有人都参加），创建了最初的完成的定义（DoD)，建立了团队和整体工作公约，最重要的是帮助团队凝聚在一起。

对于我作为一个教练和其中一个团队的Scrum Master来说，有一个很重要的事情是让团队尽快从"形成"阶段过渡到"规范"阶段和"高效"阶段。当然在两周内是不能达成的，但是理解了团队发展动态，让我们知道在这两周内我们最主要的关注点应该放在建立一个共同目标和建立团队成员之间的信任上。因此我们做了非常多的团建活动，取得了巨大的成功。

完成的定义

在这两周"启动"会议中，所有人都来到了现场，来建立一个适用于所有团队的初始"完成的定义”，如_LeSS指南：创建完成的定义_描述的那样。在这个工作坊，我们与所有成员一起探索为了交付产品（潜在可交付产品增量）我们需要做什么，并将所有团队那时已能在日常Sprint中做的活动和产品发布所必需的其它活动区分开来。这也是我们第一次深入讨论不同类型的测试和文档，并设法让大家对于工作方式达成一致的理解。

图7中划线的条目是大家一致同意放进初始"完成的定义"中的条目。其他都算作"完成之外的工作”，即不在"完成的定义"中但也是交付产品需要满足的条件。开始时这个"完成之外的工作"非常多，而我们最终目的是让所有在"完成之外的工作"中的条目最终都包含在"完成的定义"中。在随后的"发布Sprint"章节我会解释我们是怎样处理这些"完成之外的工作"的。随着时间的推移，我们通过整体回顾会议渐渐扩展了这个初始"完成的定义”。

唯一的产品待办列表

对我们而言，重点之一是从一开始就有唯一的产品待办列表。这也符合_LeSS规则：一个整体交付的产品只有唯一的产品待办列表_。

业务方原有的组织结构和不同产品经理的职责分配给我们的开始带来了不少挑战。不同的产品经理负责在电子商务网站上发布不同的Sys产品，这导致了优先级的冲突。在过去，每个团队有一份他们自称的"产品待办列表”，由一个横在真实的业务人员和团队之间的带伪"产品负责人"身份的项目经理来对团队待办列表上的条目进行排序。这导致了局部优化，因为每个团队的"产品负责人"只关注交付产品的某个部分，而缺乏整体视野。结果就是每个"产品负责人"都在争取交付更多的功能，而期望"其他团队"来改进整个产品和发布的流程。当然，这并没有发生。

我们的目标是让真正全局重要的（已经确认包含在里程碑中的）条目包含技术条目可见。我们尝试了用户故事地图。想法是在地图上标注所有的重要条目并重新组织它们以使得我们能够把所有重要条目放在一起来讨论和排序。通常情况下，在产品待办列表梳理结束几天之后，在Sprint计划会议开始的几天之前，基本上是每两周，产品经理团队（包含伪PO们）会花大约两个小时来展示和讨论各个梳理结果，并就要带到下次Sprint计划上的产品范围达成一致。这样做的优点是为业务方下次里程碑上需要实现的条目创造了可见性，包含了团队在梳理中对条目所做的估算，以及有多大可能在一个Sprint里能实现这些条目。这样做的挑战在于，它引起了许多激烈的讨论，因为每个产品经理都有一些"个人目标"要实现，因此几乎不可能达成共识。这导致了一段时间之后在谁负责排序这个问题上的改变。

唯一的产品负责人

之前说过，开始的时候我们在研发方有一个带着伪"产品负责人"身份的业务分析师，在真正业务人员与团队研发人员之间有一个带着伪"产品负责人"身份的项目经理，我来讲讲这件事的背景。在2011年早期开始把（单团队）Scrum作为研发框架导入组织的时候，由于不够理解Scrum和真正的Scrum Master或产品负责人是什么样的，来自Sys IT部门的项目经理们被要求选择是否想把自己变成所谓的"Scrum Master"和所谓的"产品负责人"来满足新的工作模式，这当然没有真正改变什么（见拉曼组织行为定律 #1和#2）。一部分前项目经理选择成为"Scrum Master”，另一部分选择成为"产品负责人”。这给大多数前项目经理形成了巨大的挑战。困难的部分并不在于学习新的未知技能（比如个人或团队辅导），而是与软件研发团队工作时放弃原先的信仰和行为模式（比如在自组织不发生的情况下如何做）。这导致事实上在我们团队里只有一个前项目经理后来保持作为Scrum Master（并且这个人向公仆式领导者的转变非常快）。因为只有头衔变更而组织结构和政策都没有相应变化，并没有真正的_产品负责人_成为"产品负责人”，而只是重新把项目经理标记为伪"产品负责人”。

这种每个团队带有两个伪"产品负责人"的非常规设置，是基于没有理解导入Scrum的意图，在开始的时候感觉还不错，因为研发团队有了"业务现在已经靠近研发"的错觉，并产生有了研发团队获得客户期望的"高效渠道"的假象。然而这导致了两个主要问题：一是让团队"产品负责人"们负责团队的"产品待办列表"会导致局部优化，如上所述；二是团队的"产品负责人"们（业务分析师）逐渐成为团队理解需求的中介和瓶颈。让伪产品负责人编写产品需求说明书，然后递交给团队来"实现”，这样的做法产生了大量的浪费，比如交接问题、延迟、过度处理、在制品和缺陷。

整个产品只有唯一的产品待办列表，并按时（每个Sprint）讨论，我们确保了团队"产品负责人”/项目经理们可以改变一些条目的优先顺序，但还有其他人可以管理团队正在研发的所有条目的优先顺序。有时候，团队"产品负责人"们所定义的优先顺序并没什么意义，因为团队最终会工作在其它相对于整体产品更关键的条目上。终于到了某个时刻，其他项目管理部门的人在优先顺序上花费的时间越来越少，只有唯一的一个非常靠近CDO的人来负责对所有团队的所有条目排序。

第二个问题的处理（团队产品负责人是信息瓶颈）更加困难，主要是因为公司本身的约束。事实上，团队成员对和客户澄清需求感到不舒服，或是缺乏这方面的技巧，或是相信由一个人来做需求澄清同时其他人专注在研发上会更加（局部）“高效”，亦或是伪产品负责人团队（项目经理们和业务分析师们）有着不一样的身份和薪水 – 所有这些都让它成为一个巨大的挑战。

由于篇幅限制，后续内容见：LeSS案例之Sys商店（下）