近五年来， Agilean 一直在帮助某大型股份行实施精益看板转型。从全面导入到落地深化，从基层赋能到量化改进，该行目前电子看板使用率已达90%，为国内领先水平。在此过程中，我们将精益思想和看板方法进行了更有机的贯通，形成了一个帮助企业快速提升研发效能的改进体系 FLEET（精益效能提升思维框架，Framework of Lean Efficacy Enhancement Thinking）。我将结合落地经验，对FLEET进行全方位阐释。
以下为FLEET 的的6条核心思路：
- 看见：高效知识工作的最大敌人，是知识工作过程和成果的不可见性。首先要利用看板可视化，构造管理现场；
- 整流：由于知识工作「不可见」，处理过程中很容易造成工作拥堵。建立需求优选机制，减少并行工作，可以保持专注，提升流动效率；
- 细粒：进行整流之后，如果需求颗粒度过大，需求也无法快速流动。这就要进一步减小需求颗粒度，从而加速流动，提升质量反馈速度；
- 润滑：需求交付质量低会造成返工，加剧需求并行度，使彼此之间产生「摩擦」。强化需求澄清、质量前移等质量活动，可以减小需求间的摩擦，缓解过程中的阻力；
- 小批：定期的需求选择会、澄清会、版本移交等批量活动，会减慢端到端的流动速度，造成等待。应尽量减小批量，减少等待时间；
-
降本：交易成本是批量存在的根本原因。通过推进自动化回归测试、自动化部署等活动，降低交易成本，使批量减小成为可能。
Agilean 精益研发管理 FLEET 框架
看见：为管理者构造管理现场
知识工作管理者通常会有一种焦虑感，管的人越多越容易焦虑。在诸多原因中，缺乏有效的可视化管理手段是重中之重。越看不清，就越踌躇，越催生焦虑。陷入焦虑的管理者，往往采用更严格的管理手段，又引起下属更多遮掩和隐瞒，工作状态的不可见被进一步强化，从而形成一个恶性循环。
在斯坦利•麦克里斯特尔（前美军特种作战司令部指挥官）所著的《赋能》一书中，作者提出一个很好的思路：「双眼紧盯，双手放开」。能够做到双眼紧盯，才敢把双手放开。FLEET 的第1个核心思路——用看板实现知识工作的可视化，便是要赋予管理者「看见」的能力。经过良好设计的看板，可以为研发团队管理者提供重要的管理现场。下图是我在2014年辅导的一个创新项目研发看板，该项目在4个月内完成了一个创新金融 APP 从0到1的过程。「可视化」实践里最大的挑战，在于对团队实际工作情况进行价值流的梳理和建模。
整流：建立需求优选机制
请看下图并回答：直觉上，你觉得这是什么地点？
在其它城市培训时，学员往往认为是火车站；生活在北京的学员却一眼看出，这是龙泽或西二旗地铁站。站外的铁栏杆就是地铁系统的整流措施——虽然让个体多走了些路、多了些等待，却保证了整体（每个个体）花更少时间候车。
在长期不可见的情况下，大多数研发团队处于高并行的过载状态，其特点就是持续打断、大量并行。有研究表明，软件研发的流动效率通常只有1%-5%。在流动效率很低的研发过程中，必须引入需求优先机制，即优先级选择。以下图看板为例，「开发」列之前为「选择」队列（红框），将积压需求停留在研发系统之外，避免进一步加剧流程中的阻塞，确保研发流程得以快速优化。
小团队比较容易建立需求优选机制。对大型组织而言，建立需求优选机制的主要挑战，在于如何有效平衡各业务方的诉求。我们在实践中发现，部落制是解决这个问题的有效方式。将研发组织和业务组织拉通（可采用虚拟方式），将研发资源合理分入不同部落、面向不同业务方，然后在部落内建立合适的需求优选机制。
P.S. 流动效率、部落制等话题均较复杂，未来我们将专文详述。
细粒：需求拆分加速流动
需求优选机制运行起来后，下一个改进点是减小需求颗粒度，将需求拆分成更小的可验收可测试单元。规模过大的单元，不利于透明其执行过程中的等待、阻塞和风险。对于大型组织，我们建议采用需求、系统任务、个人任务的三级体系，系统任务控制在10人天，个人任务拆至2-3人天。
下图为之前提到的创新项目快速启动现场（研发正式开始前的启动环节，通常为2-3天）。业务和IT共同拆出350多个粗粒度用户故事，据此制定了迭代计划和关联系统计划，完成看板建模，形成风险应对方案。团队在其后的三个月里完成6个迭代，项目准时上线，产品内容、功能和质量都获得了高度认可，在当年赢取了国内若干重要银行奖项。
润滑：降低需求摩擦
需求颗粒度减小后，通过降低需求彼此之间的摩擦，可以让研发过程流动更加顺畅。什么是需求摩擦？看图——
这段对话熟悉吗？对不少研发同学来说，本来正在做A需求，中间被叫去评审B需求，过会儿又要修改C需求的缺陷，需求之间就产生了摩擦。有很多方法可以降低需求之间的摩擦：
- 实例化需求，提升需求初始质量；
- 产品经理制度，专人负责与业务澄清需求；
- 需求研发双迭代，需求澄清迭代和研发迭代并行，澄清迭代的输出是研发迭代的输入；
- 建立开发自冒烟制度、代码评审制度，提升初始移交质量，减少测试摩擦。
小批：尽一切可能减小批量
加速流动的一个有效方法是减小批量。「批量」指在某些环节中多件事情一起处理，比如多个需求一起澄清，多个设计一起评审，多个功能一起上线，这些都是批量。批量必然导致一些需求等待另一些需求，减慢端到端的需求流动速度。
批量减小后，需求可以更快速地从开发流动到测试和UAT环节，尽早对质量产生反馈。如上图，通过减小批量，原来3个月完成600个需求，现在变成每两周完成100个需求，前置时间缩短到原来的1/6，交付速度大大加快。因此，我们应寻找一切可能的机会减小批量。例如，IT和业务团队不在一个职场的时候，要每周约定开会澄清需求；如果能在一个职场集中办公，澄清需求变得容易很多，就消除了周澄清会所造成的批量。
降本：与合理批量达成最优解
消灭所有批量，实现单件流，最大限度减少等待造成的浪费，这是一种理想状态。在现实中，由于交易成本的存在，形成合理的批量大小，才是我们要寻求的最优解。
交易成本指在做一件事的过程中，需要付出的额外附加成本。例如，需求澄清要预定会议室，要协调参会者时间；版本发布要回归测试，要进行评审，要熬夜发版，这都是交易成本。
交易成本越高，人们就倾向于形成越大的批量。为了减小批量，很多时候需要先降低交易成本。自动化回归测试、自动化部署、减少不合理的流程制度，这些都是降低交易成本的手段。
FLEET 是一套帮助企业快速定位问题、推动初始优化和改进的思维框架，其目标是为企业快速带来改善。我们将 FLEET 与过往实践经验互相印证，形成的精益效能提升实践体系，已帮助多家大型组织实现了「优化冲刺、提速增质」的目标。
