【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

看板的“面向服务”议题

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

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

关注

评论

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

软件测试 | 测试开发 | Web自动化之显式等待与隐式等待

测吧(北京)科技有限公司

瓜分 28 万现金大奖,Tapdata 数据源 Connector 大赛等你来战!

tapdata

开源 开发者 开源项目 挑战赛

如何使用 eunomia 让eBPF 的部署更简单? | 第 49 期

OpenAnolis小助手

Linux 直播 ebpf sig 龙蜥大讲堂

软件测试 | 测试开发 | 测试面试真题|从手工到测开,一位测试媛宝妈的 BAT 大厂逆袭之旅

测吧(北京)科技有限公司

测试

OpenHarmony主干开发板家族新添两成员,主干开发板数达20款

科技热闻

软件测试 | 测试开发 | 测试面试 | 某互联网大厂测试面试真题,你能回答出多少?

测吧(北京)科技有限公司

测试

最高增强至1440p,阿里云发布端侧实时超分工具,低成本实现高画质

阿里云大数据AI技术

机器学习 企业号九月金秋榜

明道云新增四项国产信创平台兼容性认证

明道云

原生Redis跨数据中心双向同步优化实践

京东科技开发者

数据中心 幂等性 同步 数据容灾 Redis 数据结构

Notebook交互式完成目标检测任务

华为云开发者联盟

人工智能

如何通过 Nginx 解决跨域问题

观测云

Vue3入门指北(四)computed (计算属性)

Augus

Vue 9月月更

本地生活与小程序技术融合迎战增量市场

Onegun

小程序 小程序容器 本地生活

少儿编程是智商税?还是未来的生存技能?

博文视点Broadview

必修课!深度解析金融级分布式数据库一致性技术

腾讯云数据库

数据库 腾讯云 tdsql 腾讯云数据库

百度工程师带你探秘C++内存管理(理论篇)

百度Geek说

c++ Linux 开发语言 企业号九月金秋榜

EasyNLP带你实现中英文机器阅读理解

阿里云大数据AI技术

自然语言处理 深度学习 PyTorch 企业号九月金秋榜

跟我学Python图像处理丨傅里叶变换之高通滤波和低通滤波

华为云开发者联盟

Python 人工智能 企业号九月金秋榜

IaC 存储最佳实践

SEAL安全

DevOps 基础设施 DevSecOps 基础设施即代码 IaC

orbeon form 的配置介绍

Jerry Wang

angular SAP commerce form 9月月更

议题征集:NGINX Sprint China 2022 线上大会

NGINX开源社区

nginx 开源软件 Sprint

当面试官问你:如何才能带领好团队?

测吧(北京)科技有限公司

测试

软件测试 | 测试开发 | 测试面试 | 某个版本/模块问题很多,但上线时间紧迫怎么办?

测吧(北京)科技有限公司

测试

Vue3入门指北(三)ref和reactive

Augus

Vue 9月月更

本周四晚19:00知识赋能第八期第3课丨涂鸦小游戏的实现

OpenHarmony开发者

OpenHarmony

点赞破百万!字节算法大佬亲撰30W字数据算法笔记:GitHub标星93K

程序知音

Java 数据结构 数据结构与算法 后端技术

沉舟侧畔千帆过 | 高德的OceanBase Cloud实践之路

followtry

最佳实践 分布式数据库 数据库迁移 oceanbase

2022华为开发者大赛开学动员 开启想象力无限创新

华为云开发者联盟

云计算 后端 企业号九月金秋榜

软件测试 | 测试开发 | Web 控件定位与常见操作

测吧(北京)科技有限公司

测试

软件测试 | 测试开发 | web 控件的交互进阶

测吧(北京)科技有限公司

测试

Vue3入门指北(二)创建应用实例

Augus

Vue 9月月更

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