开思基于LESS框架的敏捷转型规模化设计与思考案例

老是一页纸一句话需求怎么破？

2020年2月6日

运用四色建模法进行领域驱动建模分析DDD

2020年2月12日

本文根据优普丰敏捷学院首席教练申健和深圳开思时代科技敏捷教练曾庄浚在2019年北京RSG大会上的演讲所整理。

深圳开思时代致力于建设开放的汽后市场产业互联网生态，业务涵盖全车件交易平台“开思汽配”、ERP管理系统“1号车间”、供应链金融、汽配物流等，是一个B2B性质的电商平台。优普丰敏捷教练在客户A轮融资阶段介入。目前客户进行到C轮融资阶段。

本案例首先根据LeSS原则阐明敏捷组织设计的原则。然后针对本案客户面临的问题和挑战，尝试根据组织设计原则定制推进策略和实践。最后展示成效和启示。

两周一个短迭代的Scrum，鼓励尽早反馈进展和纠偏。强调团队只有一个PO，共享同一份产品待办清单。提高共识和透明性，以增强响应变化的敏捷性。

LeSS框架是多团队Scrum，从实践中总结了十大组织设计原则。强调从系统整体思考，以客户为中心，关注基于整个产品的组织设计和优化。特别重要的是“以少为多”，尽量去除一切不必要的复杂性，来获得响应变化的能力。如下图。

二、辅导初期面临的问题和挑战

1、创业初期，研发团队20多人。

传统团队是按职能划分，即需求、开发、测试通通分开管理，单个需求需要跨很多组进行协作。然而存在的问题如下：

无法直接面对客户。自扫门前雪。
团队成员只了解自己负责的环节，视角单一，没有话语权
团队只为产品中的某一模块负责
沟通存在部门墙

在外部敏捷教练进入之前，该组织的研发总监已经基于Scrum，结合微服务将原先的组件团队重组为特性团队。好处如下：

以客户为中心，从整体视角来看待产品
大家都可以为产品提出更好的优化意见
团队为产品最终结果价值负责
团队内沟通无障碍

注意此时，各个特性团队各有自己的一份的产品待办列表，以及各有各自的PO。所有PO汇报给产品总监。单个团队内部的需求优先级做到了统一，但是团队之间却没有。

2、创业一年，研发团队50-60人

当团队人数进一步扩张，拆分出更多特性团队和更多的PO，问题也逐渐爆发：研发资源争抢。各个PO及背后的业务部门（市场、销售）都觉得自己的需求优先级更高，但是现实中却得不到资源支持和倾斜。于是高层的感觉就是研发做的“慢”，研发总监和产品总监经常受到挑战。

三、策略和实践

全员培训

此时外部教练受邀入场。首先进行了全员培训，所有产品和研发部门参加，统一认识，理解为什么要敏捷。值得一提的是，在培训结束之前，进行了Scrum Master招募活动，自愿举手成为“公仆式领导者”。一开始有担心没人举手，但结果却是得到了比团队数量还要多的SM候选人，很多人被点燃了。

用户故事地图

外部教练带领产品总监进行系统思考，大家认识到在资源紧张的情况下更应该统一优先级，聚焦去交付最大客户价值的工作，而不是摊大饼。同时信息透明也有利于研发部门与业务部门和高管层建立更好的信任关系。
下图是产品总监亲自带领建立的全公司产品看板，也叫「用户故事地图」。横向为迭代发布周期，纵向为不同的子产品或需求领域，从上到下即为优先级，所有人一目了然。

建立大PO角色

在外部教练的建议之下，产品总监天然是LeSS框架中的大PO角色（其他实践框架也有称为Chief Product Owner的）。产品总监在高管会议得到CEO授权，有权决定全公司所有功能的高层优先级。

通常需求分3个来源：市场部门要求的新功能设计、客服收到的投诉、系统测试测出的缺陷或改进。大PO不可能也不应该关注过多的细节，所以组织决定大PO必须定期对新功能和一部分投诉类排列优先级，并在定期的高管会议上汇报。而功能缺陷和小型改进则由各团队小PO决策。

培养PO能力

现状已经存在10来个PO，然而工作经验相对薄弱，对业务理解不足，也无法一下子承担所有产品决策，同时还有兼顾需求分析与设计的职责。本案例没有照搬LeSS框架缩减PO数量，而是遵循向完美持续改进的LeSS原则，先尊重现实，把关注点放在：

1) 培养优秀PO该有的决策能力、设计能力、计划能力等；2) 要PO更加贴近市场，获得一线业务经验，同时也在业务部门建立威信。

各特性团队的信息同步

各个团队的迭代周期同步，同一天开始，同一天结束。特别是，同一天集体进行Sprint评审会，如上图LeSS框架所示。然后再分头进行团队级回顾会，双周的周四进行组织级回顾会，参加者包括研发总监、PO们、Scrum Master们。

阶段性收益

01节奏统一
所有团队迭代节奏统一，迭代时长、计划会、站会、演示、回顾会统一时间

02跨团队信息同步
各团队早会结束后，团队SM再同步各组信息，主要同步团队进度，需要其他团队配合或求助的事项，多团队协作项目的进度情况

03统一演示
演示会议统一时间召开，由测试或开发人员统一对业务和产品进行演示

04回顾会议
每个迭代各团队在迭代最后一天早上召开，下午所有SM进行全体回顾特性专项在项目上线后，各团队先进行内部回顾，各团队代表再进行全体回顾

05管理层的支持
设定组织级障碍清单，张贴在白板上，透明公开。同样设定截止时间和责任人，由管理层人员负责改进

06优先级排序
由产品总负责人进行优先级排序

出现新的问题关于业务价值澄清的故事：

有业务人员反馈，会时常出现货物在运输过程中损坏的问题，因此提出货损险的概念，即通过与保险公司合作，在平台购买保险，货物出现损坏后，由保险公司帮忙赔付；于是产品研发投入人力进行开发，结果上线运行后，卖出去的保险非常少，导致项目亏损，最终不得不把功能下线

总结发现：一、货损险大的市场很小，很多时候货物损坏是可以找物流公司进行赔付的；二、保险费对于客户来说是额外开支，在客户的认知里是本身就应该带有的服务（线下交易如此）

策略和实践成立「业务线」，业务人员与产研团队进行端对端的沟通交流，所有人为业务结果负责，职责包括：

获取需求、分析需求
做面向用户的业务及价值设计

绩效考核方式

偏重业务指标，职能部门考核只做参考

产品待办事项列表梳理流程

在将业务人员纳入更大的反馈循环周期之后，组织获得了更完善的客户价值闭环。按照LeSS整个产品的原则，来进行深入的反馈和优化。于是建立了以下的产品待办列表梳理的新流程。

3、创业三年，研发团队接近200人

扩展带来的新问题

随着公司的扩张，更多新人涌入。人员激增，新人却不熟悉业务，老人无暇顾及，线上质量频发，产能跟不上业务需求。是时候考虑进一步的组织设计，以提高组织效率了。

策略和实践

基于巨型LeSS结构的部落化调整

成立四大部落

基于LeSS框架，结合时下流行的部落与中台概念，组织成立了四大部落进行业务需求领域的解耦。每个部门负责一些子产品。这里涉及如何划分解耦的产品线，也是导入LeSS的关键动作。下图是比较适合该电商产品线的一种划分方式。

除了统一的部落PO，还增设部落SM、架构师、测试架构师三个角色

LeSS的另一原则：以少为多。和敏捷原则#10一样，尽量减少不必要的工作和角色。同时从LeSS的另一原则：系统思考出发，要尊重现状。考虑到新人太多，成长缓慢的因素，每个部落除了定义统一的部落PO之外，组织在本阶段需要定义出一些专家角色。成立四大部落，部落之间的沟通交流有部落中的SM进行拉通，开发技术和测试技术由架构师和测试架构师拉通。