写点什么

看板的“面向服务”议题

  • 2014-12-08
  • 本文字数:3799 字

    阅读完需:约 12 分钟

在这个关于看板方法的系列文章中,第一篇介绍了有关“可持续”议题的最佳实践,还有它的三个价值观:透明平衡协作。一般说来,在这些价值观和敏捷等其他方法的实践和人工产出之间,很容易找到对应关系。对于已经具备可持续性的团队来说,比如以《敏捷宣言》中“可持续的步调”之方式,可持续议题就不再是多么前沿的选择了。

面向服务议题却完全不同。该议题以可持续议题的实践为基础,持有以客户为中心领导力这三个价值观。每个价值观都有各自的实施难度,它们放在一起,就可以指明一个正确的方向,走上以更为外向的方式迎接变革的途径。

“以客户为中心”价值观

知道你在交付什么,交付给谁,为什么交付。

认同这具“真言”不难,要将其深深植入“知识探索过程”(这用来比喻脑力劳动很合适)的每个阶段,就不那么容易了。借助精益实践的做法,检验过程的好方法,就是回溯到客户感到满意的时刻开始,要深入探究过程如何预期客户的需要和期望值。

在脑力劳动中,任何这样的检验必须基于这样的假设:在交付过程开始时,针对客户需求的内部知识是不充分的,很可能有很多欠缺。长久以来,演化式的交付方法一直想要解决这个问题,但是仍然可以提问:对于解决前述有关客户知识的问题,交付过程的各个步骤到底有何贡献?

以客户为中心价值观有些好习惯,不妨使用看板作为某种评判的思考工具,强化这些习惯。比如从看板右边到左边的典型站立会议(从最接近完成的工作倒推),我们可以针对每一列、或是某些特定工作项目,提出下列问题。

  • 在这个过程阶段中,探究了谁的需求?具体如何做的?
  • 这里忽视了谁的需求?这么做又带来哪些风险?
  • 我们在这个阶段中掌握了哪些之前没有(或是无法)掌握的东西?
  • 这个阶段的活动如何帮助我们预期将来要做什么?
  • 还有哪些需要掌握的?要应对这些明显的不确定性,在哪个环节最为合适?

在很多系统中,总会看到(或者应该看到)一个“承诺点”,没到这个点时,如果放弃很多完成的工作, 就会导致人们心痛不已。过了这个点,由于交付了快速而稳定的服务,过去的工作就不太可能会白白浪费掉。在某些(我们希望很少见的)情况下,分析一下根本原因分析,可能会发现对于客户领域存在很大误解,或者客户的期望值与我们能交付的东西有无法控制的差距。这些都是吸收深刻经验教训的绝佳机会。

要是这个承诺点往前移,接近工作最初的起源,那就大不相同了:放弃一些工作,感觉上就像打了胜仗。在这里,“上游看板系统”,也就是一整块版,或是现有看板最左侧的竖列,都用来解决工作是否符合需求的问题,以供后续流程使用。这些上游工作项(单独的特性或是整个项目)要想前移,不仅要考察它们自身,还要看它们相对其他工作项的价值、紧急程度和风险。当着意限制在制品时,只要有工作到达的速度比系统所能处理的速度更快,这些优先级排序的决策必定会导致某些工作从看板中移走。

在某些“上游”层面,有些个人化的看板【参考 1】比典型的项目组合管理系统还要成熟。从大处看,现代的上游看板将工作项目视为选择,其假设是:很多工作项目都不应该到达承诺点。它们的目的,是产生可靠的高质量工作项目,后者将会按照规定的速度,流入下游过程。

这些高级技巧无法替代与客户的协作,实际上也是对协作的支持。看板在这里就像在下游中的功效一样:让人们看到行动的需要,帮人们做出良好的决策,捕获人们的经验教训。

“流”价值观

如果在我们的工作环境中,能够直接看到工作在向前推进(或是无法推进),我们也就能掌握了这个价值观。当我们看到流被阻碍,某种不适感油然而生,引发战术层面(针对具体症状)和战略(系统层面)的反应。

我们可以主动关注流。跟以客户为中心一样,我们可以使用看板作为思考工具,指引对流程的检视。还是从右到左来检视工作,从客户产生满意度的地方回溯,我们会提出如下问题:

  • 工作项目如何离开流程中的这个阶段?它们满足什么条件算是准备就绪了?这些条件如何表述?这种状态的改变如何沟通?
  • 一般来说,每个工作项目在这个阶段用去多少时间?其中具体多少时间是在真正运转,多少是在等待之中?
  • 最难以预测的问题来源是什么?是在工作中,还是在等待的时候?是要等待内部的处理能力,还是等待外部的依赖?
  • 这个阶段中有多少工作能力耗费在返工之中?有多少用于应对失败的需求(failure demand)?所谓“失败的需求”,是指之前的工作成果无法满足客户需求时产生的需求。
  • 工作项目如何到达这个阶段?我们怎么知道它们都已满足进入这个阶段的条件?

随着经验的丰富,我们就能深入理解流,以及流与在制品的关系。从数学角度看,它们与“利特尔法则”【译注】和其他排队理论的关键结果相关;从实用角度看,实践者会学着将在制品的隐蔽形式可视化,并加以控制,从而刺激在不太明显之处的工作流。

如果将状态的改变在累积流图(cumulative flow diagram,简称 CFD)中记录下来,这种重要的关系就更为明显。下图展现出每种活动(每条线的斜率)的交付速率、每种状态或者临近状态组(垂直高度)中的工作数量,以及对应的前置时间(水平宽度)。

一张累积流图

也存在其他可视化和度量方式,实践者可用其来理解时间的分布情况,深入了解内部工作流程和客户体验的服务。看板有一点做得很好,它会无视不人性的做法,常常自己放弃追求“资源的高效利用”,对流的关注与“可持续”议题也是相处融洽。

组织不需要太大规模,也可以在端到端的流中融入多种服务。在制品的管理不仅限于服务内部,更要管理多个服务之间的部分,这样流才能顺畅。可能某种服务的“上游看板”就是另一个服务的“依赖看板”,窍门在于让两者配合起来。要扩展看板,重点在于让工作和知识在组织内部流动得更快,添加多个看板层次不是重点;当然,层次对于资源分配和风险管理还是有价值的。

“领导力”价值观

领导力在看板方法中有关键作用,能够融合实践和原则。一方面是我们已经看到的、属于“可持续”和“面向服务”议题的价值观和实践,其中产生了大量领导力可以发挥作用的机会;另一方面,还有一些价值观和原则涉及到领导力的关键之处,那些属于“生存性”议题,这是本系列下一篇文章的内容。

有意思的是,在看板方法的定义【参考 2】【参考 3】中,只是从 2012 年开始,领导力才以如下原则的形式被明确提到:

在组织的各个层面,从个人贡献者到资深管理层,都要鼓励领导力行为。

早已视为理所当然的事情,为什么还要花心思落在纸面上?这是出于实用的目的(毕竟这个理论是从现实世界的观察中抽取出来的):如果没有领导力,组织变革很少能成功。

注意:虽然我们并不坚持认为领导力来自高层,我们只是需要它出现在需要改变的地方。哪里需要透明平衡协作以客户为中心呢?当然哪里都需要,而且它们不可能随随便便发生。

当改变需要跨越职能的界限时,对领导力的需要最为明显。如果这些界限特别难以逾越,要跨越它们就必须有很强的意愿推动,甚至还需要勇气!上报问题也许是另一种可选策略,但那么做有多少时候能产生最真心的协作?反而更有可能引发防御性的反应。

下面这个领导力方法的灵感来自丰田,其中体现了推行和培养领导力的方式。想象有一个资深主管到你那里,提出下面这三个问题:

  1. 流程是什么?
  2. 我们如何知道它能发挥作用?
  3. 它如何改进?

反复不变地使用这种有意设计的领导风格,可以帮助组织及其产品和流程向前推进,同时能在未来的领导者们中间培养这种能力。即使此种方法看起来有些格格不入,它还是表现出看板在各个层面都提倡的领导力,这种领导力希望个人和流程能够先后成长起来。

实施“面向服务”议题

使用看板实施面向服务,要先以看板角度审视组织中的服务交付、工作流程和知识发现过程。一般来说,可以从发现客户的需求、期望和痛点开始,同时匹配内部机制的能力和痛点。“可持续”议题的工具包括可视化、控制在制品、反馈循环等等,都可以用起来,强调其端到端的能力,同时向上、下游的客户扩展。

这种“水平化”的方式要用“垂直化”的手段作补充。这些也都可以基于“可持续”议题的工具。使用风险分类、服务类别、战略目标或主题,或者仅用一个看板,可以在更大的粒度上聚合在制品,比如“传奇”或“最小可行产品(MVPs)”,而不仅仅是“特性”或“用户故事”。在每个层面上,经济模型都可以影响规程策略。

本系列下一篇文章将会检视三个议题中最后一个——“生存性”议题。如果所有的变革都以符合理解同意尊重的方式实施,会有何种效果?

参考资料

  1. Personal Kanban: Mapping Work | Navigating Life ,Jim Benson and Tonianne DeMaria Barry (CreateSpace Independent Publishing Platform, 2011)
  2. 大卫·安德森,《看板方法 : 科技企业渐进变革成功之道
  3. The Kanban Method

关于作者

Mike Burrows是的英国总监,也是 LeanKanban Inc 的培训计划总监。他的博客点此可以访问。他的新书Kanban from the Inside 刚刚出版。他的 twitter 账号是: @asplake @KanbanInside

译注:利特尔法则,英文名:Little’s law,是一个有关提前期与在制品关系的简单数学公式,由麻省理工大学斯隆商学院(MIT Sloan School of Management)的教授 John Little﹐于 1961 年所提出与证明。其描述是:在一个稳定的系统中,长时间观察到的平均顾客数量 L,等于,长时间观察到的有效到达速率λ与平均每个顾客在系统中花费的时间之乘积,即 L = λW。利特尔法则对于精益生产的指导意义是:最有效地缩短生产周期的方法就是压缩在制品数量。

查看英文原文: Kanban’s service orientation agenda

2014-12-08 09:052312
用户头像

发布了 479 篇内容, 共 170.7 次阅读, 收获喜欢 52 次。

关注

评论

发布
暂无评论
发现更多内容

JavaWeb 数据库操作

Emperor_LawD

sql javaWeb 5月月更

FinClip小程序+Rust(二):环境搭建

Speedoooo

rust 前端框架 小程序容器

Go Web 编程入门:Go pongo2 模板引擎

宇宙之一粟

Go web Go 语言 模板 5月月更

FinClip小程序+Rust(一):夹心饼架构

Speedoooo

rust 前端框架 小程序容器

FinClip小程序+Rust(五):用内联SVG实现二维码

Speedoooo

rust 前端框架 小程序容器

FinClip小程序里如何安全使用SVG

Speedoooo

rust SVG 前端框架 小程序容器

HDD·耀星领航出海峰会:华为游戏中心联运服务加速游戏出海获量增长

最新动态

HIVE3 深度剖析 (下篇)

明哥的IT随笔

大数据 hive

Redis「5」事件处理模型与键过期策略

Samson

学习笔记 Redis 核心技术与实战 5月月更

三种常见的 Mac 安装 git 工具的方法

liuzhen007

git git 学习 5月月更

ABBYY2022全新版PDF文字识别功能

茶色酒

你中奖了吗?低代码开发师(高级)认证中奖名单揭晓啦!

一只大光圈

钉钉宜搭

飞书将于5月25日举行春季发布会 同步推出全新项目管理产品

陈泽涛

飞书 飞书项目

先进数据中心背后,“东数西算”的三重意志

脑极体

OpenMLDB v0.5.0 发布 | 性能、成本、灵活性再攀高峰!

第四范式开发者社区

人工智能 机器学习 数据库 数据 特征平台

企业架构如何促进创新?

涛哥 数字产品和业务架构

企业架构

学生管理系统(5)

5月月更

String基础整合

工程师日月

java 5月月更

设计模式之装饰器模式

乌龟哥哥

5月月更

【JavaScript】数值转换为数值

恒山其若陋兮

5月月更

宠物类自媒体运营心得:如何才能拍得更有创意

石头IT视角

数据库连接池 -Druid 源码学习(六)

wjchenge

Druid 数据库连接池

AIrserver2022手机软件无线投屏电脑屏幕

茶色酒

AirServer

FinClip小程序+Rust(三):一个加密钱包

Speedoooo

rust 前端框架 小程序容器

FinClip小程序+Rust(四):端到端融合

Speedoooo

rust 前端框架 小程序容器

柏拉图会成为元宇宙风险标吗?PlatoFarm的机会很大

小哈区块

druid 源码阅读(七)Druid Filter 介绍

爱晒太阳的大白

5月月更

零基础学Java第一节(语法格式、数据类型)

编程攻略

java 5月月更

druid 源码阅读 6——如何实现断链重连的?

张大彪

源码分析 Flutter 的 setState 过程

岛上码农

flutter ios 前端 跨平台开发 5月月更

看板的“面向服务”议题_精益_Mike Burrows_InfoQ精选文章