| 编辑推荐: |
本文介绍华为百人团队精益看板演进变革的历程，从建立看板到运作看板，取得小胜利，再到团队遇到困局，停滞不前甚至倒退，面对困局同团队一起再审视改进，重新走上了正确的道路。
本文来自于csdn，由火龙果软件Luca编辑、推荐。 |
|
1华为研发面临的挑战
客户分类：
传统运营商客户：运营商受到互联网企业的冲击，要求版本更新得更快。
企业客户：以华为的DCN数据网络中心为例，承载了大量的数据业务，企业对此格外重视，版本更新迭代较之以往提速许多。
终端客户：个人客户需求变化频繁，甚至是每天都在改变。
华为内部：团队庞大，产品、业务复杂。一个产品的解决方案有时会牵扯到上千人导致效率低下。
02为什么要选择精益看板
1.对研发冲击小：精益看板不会改变组织架构、人员角色，但可以将整体格式化、规范化。
2.适应性强：看板是“元流程”，它可以和任何流程相匹配，无需担心要怎么去融入看板。
3.可提升吞吐量：研发的吞吐量与车道流量十分相似，其相关定义如下图：
在研发过程中，难免会存在吞吐量非常小的环节，我们可以称其为研发中的瓶颈，瓶颈发生的地方称之为阻塞点。那么如何解决呢？关键在于保证WIP一定情况下缩短Leadtime，这可以从缩短Worktime和waittime两个方面着手。例如做自动化测试，可以大大缩短编译时间，提高整体“通道的流速”。
4.看板是一种持续改进的机制。 
仔细观察上图，可以看到开发已经没有正在进行中的事项，但还有许多待办事项，这是由于测试环节处存在积压事项。但此时我们仍要进行深入的分析其究竟是不是瓶颈再做定夺。
在图中，异常卡片所代表的事项是环节中的阻塞点。异常卡片这一设置是看板上的可视化元素，可以让团队持续改进，把问题充分暴露出来。
03百人团队实施案例分享
下图是在引入一个新方法时，绝大多数团队会经历的历程。下面我们以引入看板为例： 
出于产品的诉求，引入了看板机制，之后会取得一定的小胜利，但在使用过程中也逐渐出现新的问题，只有解决新问题后团队才能走上正确道路。
但大多数团队会由于没有正视问题而迷失在困局内，这不是引入模式的问题，而是团队使用方法出现了问题。
业务痛点
1.市场增加，需求增大：外部市场的增加，同时团队面临着组织的调整，团队的人数减少了，这种情况下更急需提升团队的产能。
2.需求变化快，需要快速响应：在研发无法满足市场时，需要进行一些变革，这也是引入精益看板的原因。但也需要考量项目团队是否与精益看板相匹配：第一业务诉求与精益看板是否相匹配；第二团队积极性是否高昂。
看板的引入
在引入看板时，存在两组实践。 
第一组实践是建立看板，另一组为运作看板。并把八大实践分为两组，建立可视化过程。
价值流映射
将研发过程可视化，映射到看板上。 
按照华为团队需求结构可分为三层：IR、SR、AR。
第一层IR是初始来自客户的需求，随后分解到第二层的系统需求，最后分配到团队级的AR。我们根据上述特点，建立了产品级看板和团队级看板。需求从上往下分解，状态从下向上卷积。
显示化流转规则
卡片的每一次向下流动都需要一个规则，这些规则是共同定制的质量条件，目的是为了保证每一步的进程都是良好可运行的。
但规则不是死的，是随着环境、研发的变化而变化，是可以被重新商议更改的。唯一的条件是，规则制定后必须严格执行。
规则的制定来源于自働化。众所周知，自働化是丰田的重要原则之一。丰田最早做自动织布机时，把传统的手动织布机改为自动织布机，但是问题来了，当有线断掉的时候织布机不会停止，这样出来的产品时残次品，后来经过改良在织布机出现故障时由人工
来检查重启，检查通过后才会继续运作。这也是内建质量的过程。 
限制在制品
这是看板中最难实施的一个步骤。因为为保证投入的精力，每人同时只能干两件事情。
尽管在以往，一个人同时做多件事情被认为也是无伤大雅的。但这是由于需求流动无法被直观看到，最终极易导致需求流转不动，一直停留在开发进程中。这时候我们需要转换自己的视角，更多关注流动效应。 
因为研发的交付速度需要很快，所以研发人员的流动效率与资源效率理应很高。但实际上，效率是无法都达到百分百的。所以我们提倡提高流动效率，减少浪费，自然可以提高资源效率。
看板正是为我们提供了这样一个视角，把不可见的需求转化到可视化的看板上，把需求的变动转化为卡片的流动。
看板运作
运作看板首先有一个需求的填充，这个过程在华为被称为二次填充。从大的流程看，二次填充仍然属于IPD，但可以限制大的IPD，更好地管理风险。 
第二个是通过看板站会管理流动效率。站会与以往不太一样，不再关注要做什么，遇到什么问题，而是关注卡片和价值的流动。
看板从右向左看，成员更多的关注如何让右边的卡片尽快向下流动。在这个过程中尽快解决可能存在的阻塞、瓶颈，其最终目的也是为了让卡片向下流通。
拉动式开发
拉动式开发是团队形成自组织非常重要的一点。这也意味着，如果你的团队想要做到拉动式开发必须是自组织的。在建立拉动式开发时，必须要关注上下游的每一步质量究竟如何，只有下游可以流动，上游才能被拉下来。 
组织者必须具有全局观，善于发现问题。
建立规则
这些规则会定制的十分详细，包括团队运作看板时的操作规则。例如，看板站会之前，团队人员会把卡片拖动到正确位置，标记异常情况。
示例
观察下面看板图片： 
在运作过程中，我们发现在团队级看板的AR一级，SDV测试内没有任何卡片，反而都堆积在Ready For
SDV。看起来SDV是一个瓶颈，但实际上这是因为自身流程——批量式转乘造成的。
回顾改进：从下示意图中，可以看到批量式交互的累积流程是呈现阶梯状的，散点图是集中于某一时间交付。 
在回顾改进时，我们制定了改进测试，每周进行小批量的SDV测试。
在有了这样的小胜利后，团队的趋势从上图变成了下图。团队从原来的的批量交付，修改大量缺陷。变成了当前的每周发现问题，每周进行修改。
困局与破局
在这个版本结束后，看板使用率就大大降低了。和其他团队沟通后，发现是因为团队太忙根本没有时间顾虑看板。
破局一：建立看板的分析请求分配产能
下图是Muri、Mura、Muda浪费示意图。 
特别注意Muri、Mura直接导致Muda。Muri系统超载导致任务的切换，任务切换本身就产生很多的浪费。Mura系统的波动性会打乱团队的节奏，例如突然来一波需求导致系统过载进而产生浪费。
这个团队Mura情况比较严重，除了本身的特性包需求意外，还会有一些需要快速响应的小需求，导致团队疲于应付。解决方法是把团队人员分为两组，一组人做运营快速发布版本，小需求出现后，以固定的节奏快速发布。大的需求用火车版本。
美国海军陆战队有句话“慢就是稳，稳就是快”（slow is smooth，smooth is fast）。这和丰田的“均衡化”原则的原理相似，需求进入管道时一定是稳定的，如果不稳定会导致优化大打折扣。
破局二：找回需求
AR只是任务，不能称作需求。测试是检测SR，所以我们转换视角关注到需求上面，采用FO，拉通端到端。 
破局三：减小批量
下图的瀑布中，总计44天，但编码只占用10天，后面20天是没有任何编码的。在这样的情形下，做的需求会较少。
解决措施：按周填充，减少SDV批量，减小SIT批量，加速价值流动，质量保证前移，减少fix时间段，增加编码实践，提升吞吐量。
04Q&A
Q：如何能真正做到减员增效？
A：看板。因为在业界里面，比较好流动效率才刚20%到40%，所以如果你的流动效率能达到40%，其实你有60%还是浪费的。所以如何不断的提升流动效率，让卡片流动越来越快带动吞吐量提高。只有不断的把水分给挤掉，这就是减员增效。
Q：华为是怎么突破精益看板中的坑呢？
A：最大的坑是思维的变化，对于某些看板上展示出的问题不以为然。我们团队认为要持续改进。持续改进其实已经是改善的结果。
改善要有自我批判的精神，能够不满足现状，能够有勇气去改进，然后才会用到相关的工具去做持续改进。在有了这种思维后，才会使用看板。所以首先要改善，其次才是改进。
|
