《看板方法实践体系》读后感

最近拜读了一份看板方法的相关文章《看板方法实践体系》，在这里总结分享一下。本篇文章分为两个部分，第一部分会对文章做一个大致的梳理和总结，第二部分我将从个人的角度来谈谈对看板方法的感想。

首先，文章全篇将看板拆分为五个部分：

1. 可视化价值流动，重点要素有三个：
   
   
   
   • 可视化的价值单位应该是用户价值，要以用户价值为导向，每一个价值都应该是一个可验证、可交付的用户需求。
   
   
   • 要体现用户价值端到端的流动过程，就是价值从提出到交付的过程。
   
   
   • 问题要被可视出来，能从看板中看出阻碍或流动不畅的环节。
     
     此外文章还给出了可视化价值的建模方法：分析价值流动，选取可视化元素，建模价值流动。这个部分偏向时间话，这里就不叙述了，有兴趣的朋友可以移步文章。
   
   


2. 显示化流程规则，文章提出了流程规则的三个步骤：
   
   
   
   • 组织和明确流程规则，包括规划价值的流转规则（在各环节中流转的规则），周期性活动的规则（站会、需求发布、上线等等），其他协作规则。
   
   
   • 团队共同拥有流程规则，团队成员要明确和理解规则，团队对规则理解一致自主的决策和协作。
   
   
   • 持续改进流程规则，对明确的规则进行改进和落实。
   
   


3. 控制在制品数量，这里讲道了三个概念：
   
   
   
   • 束水攻沙，更少的在制品就可以更快的流转，将价值快速的流动（加速价值交付），对应的阻碍和问题也会凸显出来（即时暴露问题）。
   
   
   • 暂缓开始，聚焦完成，控制在制品数量的思想核心，“完成越多才交付越多，而不是开始越多交付越多”。
   
   
   • 湖水岩石效应，要从可行但有用的值开始，逐步暴露和解决问题，渐近改善交付能力。
   
   


4. 管理工作项流动，这里也分为了三个实践来讲诉：
   
   
   
   • 看板站会，站会的目的是：检视价值流动状态，促进价值顺畅流动。
   
   
   • 就绪队列填充，确保输入能够符合团队的输入标准（能够合理迅速的流动）；建立合理的输入节奏（填充频率过低会损害决策的质量和团队的敏捷性、填充频率过高带来额外的成本）。
   
   
   • 发布规划会议，建立发布规划的DoD、解耦部署和发布（蓝绿部署，特性开关、模拟环境）。
   
   


5. 建立反馈和改进，通过度量看板的数据进行反馈，可用的工具有：累积流图、控制图、前置时间分布图。

总结完文章，接下来分享一些个人的看法，首先是个人总结归纳的看板方法三个核心：

• 可视化价值
  
  
  
  • 文章提倡以用户价值作为核心及单位，我的观点则略有不同，我觉得以交付的价值为核心会比较贴切一些。原因有二：其一，对于面直接面向用户的项目而言，交付价值等于用户价值，但是在一些非直接面向用户的项目下，用户价值这个概念可能会十分模糊且难以界定；其二，我认为看板方法应该是一个工具，一种方法，它可以被抽取复制在其他类似的领域或小规模的活动中，这时使用交付价值的概念就会更加的准确，便于方法的复用。
  
  
  • 详细体现信息在环节中流动的过程，由于每个人感知不同，所以问题与瓶颈是不客观唯一的，通过看板可以将问题聚焦在价值流动，能够客观的反应出问题的存在，同时也能反向推动团队成员来进行感知。
  
  


• 控制价值的流动，我将显示化流程规则和管理价值流动整合在了这个条目内，这两点其实都是对于价值单元的控制。在这里将这也点重新划分为两大类：
  
  
  
  • 一是价值流动的类型，环节/价值自身的流转规则（自动化规则，即价值单元在各个环节中流转的规则，由团队成员自觉遵守，执行过程中无需变更）；中间过程规则（对应手动规则，比如每日站会就是一个进行价值单元监控，人工干预控制流转的机制）。
  
  
  • 二是价值数量变动的类型，价值的输入（需求规划、紧急需求）、输出（价值交付）。
  
  


• 建立反馈持续改进，基于发现的问题、瓶颈、实施过程中的感受等反馈，对整套看板方法和开发中的一切作出调整优化和定制化。

看板方法是一个工具，虽然方法完整且相对较易于实施，但实践起来还是有诸多的难点，我认为有以下几点：

• “人之蜜糖，我之砒霜”，看板方法不能简单的套用所有项目，这点在文章中有讲到，需要对应团队的情况来进行具体的实施和改进，而这是一个依靠经验和长期实施的过程，需要团队不断的踩坑试错改进才能成功。


• 作为工具而言的门槛和学习成本其实很高，整套方案的实施具备一定的复杂度。比如文章介绍的全套看板方法，就有将近20个步骤和概念，且每个点都具有一定的理解难度和深度，看板方法作为一种“方法”十分依赖实践经验；文章在部分内容上讲得较理论化，比如介绍可视化价值案例时就省略了具体改造的过程，这对于学习者来说比较难以理解，更别说具体应用到整个团队上的情况了。我觉得应该对看板方法的进行拆解，拆分为若干个独立的功能模块，再结合团队当前的现状，针对病结所在“对症下药”，同时小步试错快速迭代，降低实施难度。


• “看板方法应该被团队所拥有”，一个工具它应该为团队带来价值并落实到每个人的身上。其实，作为一个管理工具，看板方法需要与团队成员的自身利益产生关联，如果团队感受不到工具带来的好处从让团队自发的推动和执行，那工具就只是为团队带来额外的负担，进而在实施上只能依赖团队负责人进行推动，这又会产生几种情况：负责人管理任务过重无法兼顾开发和管理，一旦出现在高强度的开发工作时容易忽视管理，就会导致实施停滞难以继续推动；或是负责人过于注重管理和实施，成员只是遵照指令运作，由于下级是非自主的进行实施，容易产生消极倦怠，失误、反馈缓慢等等各样的问题，长期之后管理任务会更加繁重，形成恶性循环，管理难度也会不断爬升，最终导致实施失败。

最后，看板方法是一个已经被业界证实的优秀先进且完善的项目管理方法，但同时，看板方法也经常被错误地理解和使用。其实，看板方法就是一个工具，它应该被团队所理解，应该被团队所拥有，更应该为了团队所服务。