大厂Data+Agent 秘籍:腾讯/阿里/字节解析如何提升数据分析智能。 了解详情
写点什么

看板的“面向服务”议题

  • 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:052370
用户头像

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

关注

评论

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

区块链的抽象与演进

CECBC

20道阿里面试必问JVM面试专题(文末附送答案及JVM学习文档)

编程 程序员 JVM

操作系统——计算机硬件简介

思想者杰克

前后端、多语言、跨云部署,全链路追踪到底有多难?

阿里巴巴中间件

阿里云 云原生 中间件 全链路追踪

不敢想,做个博客竟如此简单!

程序员鱼皮

博客

新消费:如何度过从0到1的破局期?

石云升

学习笔记 11月日更 新消费

十年数据库专家,呕心力作MySQL技术精粹,薪资直涨3K其实很轻松

数据库 程序员 MySQL 数据库

模块七作业

Geek_fc100d

「架构实战营」

赋能优秀传统文化,区块链助力讲好中国故事

CECBC

科技热点周刊|ClickHouse 融资 2.5 亿美元、个人信息保护法正式实施、Facebook 改名 Meta

青云技术社区

云计算 facebook 云原生

区块链+农业开启智能化生产时代 解决世界性食品及粮食安全问题

CECBC

架构课毕业总结

伏波

架构

RadonDB ClickHouse on K8s 2.1.0 发布!

RadonDB

数据库 Kubernetes Clickhouse RadonDB

Bash 脚本简介

码语者

bash Shell

SAP CRM和C4C的内容管理(Content Management)

汪子熙

内容 CRM C4C 11月日更

央行数字货币即将破茧,一场大变局,震撼全球!

CECBC

阿里大牛教你如何用Dubbox+SpringBoot+Docker架构,实现双11项目

编程 程序员 springboot

如何在实际场景中使用异常检测?阿里云Prometheus智能检测算子来了

阿里巴巴云原生

阿里云 云原生 Prometheus 异常检测

杂谈—程序人生第一份工作

思想者杰克

程序人生 新手指南 程序

CRM WebClient UI的浏览器打印实现

汪子熙

JavaScript CRM SAP UI5 JavaScript图表库 11月日更

电商秒杀系统

伏波

架构

Eureka 源码之客户端注册

悟空聊架构

Eureka 源码剖析 注册中心 悟空聊架构

【死磕Java并发】-----深入分析synchronized的实现原理

chenssy

死磕 Java 死磕 Java 并发

软件架构治理 之 架构混沌之谜

码猿外

架构 软件架构治理

杂谈——程序人生我的大学

思想者杰克

牛掰!“基础-中级-高级”Java程序员面试集结,看完献出我的膝盖

Java spring 程序员 JVM hashmap

端开发技术——5个高效的Flutter开发工具

思想者杰克

2021年10月云主机性能评测报告

博睿数据

北鲲云超算平台如何成为就生命科学云计算领域先行者?

北鲲云

布局人工智能,银行有的不只是智能客服

CECBC

面试必备!阿里内部Java面试八股文出炉,教科书式完美回答

Sakura

Java 程序员 架构 面试

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