AICon上海|与字节、阿里、腾讯等企业共同探索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:052229
用户头像

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

关注

评论

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

[架构实战营]模块一作业:微信业务架构与学生管理系统

Geek_99eefd

架构实战营 「架构实战营」

百度人脸采集SDK通过CFCA权威安全测评

百度大脑

人工智能 人脸

字节半天*3面/5天拿offer,全凭自身硬实力和这份Java面试笔记

Java 编程 程序员 架构 面试

人生成长密码:高效能人士的7个习惯

dinstone

第 20 章 -《Linux 一学就会》- 条件测试语句和if流程控制语句的使用

学神来啦

Linux linux运维 linux云计算 linux一学就会

【权限专栏】谁允许你访问了?

趣链科技

区块链 权限管理

IP地址溯源 从源头遏制计算机恶意程序感染

郑州埃文科技

网络安全 ipv6 IP地址 木马病毒

架构实战营-模块一作业

随风King

「架构实战营」

架构训练营模块一作业

Beyond Ryan

架构实战营

Golang fasthttp实践

FunTester

golang Fasthttp 接口测试 测试框架 FunTester

数字货币交易所软件系统开发简介(搭建)

网易云信的音频共享技术 | 体验共享专题

网易云信

音频技术

模块1

侠客行

架构实战营 「架构实战营」

百度大脑DuMix AR赋能中国人寿财产保险,助力车险定损场景数字化转型

百度大脑

人工智能 百度

自定义 View:Bitmap和Drawable

Changing Lin

10月月更

再次捕获云上在野容器攻击,TeamTNT黑产攻击方法揭秘

腾讯安全云鼎实验室

容器 云安全

营销CRM软件(销售管理工具)让客户都成为回头客

低代码小观

营销 企业 企业管理 CRM 管理系统

21 张图 | 带你领略集合的 线程不安全

Java 架构 面试 线程 后端

研究表明到2025年多接入边缘云市场规模将稳步增长

云计算运维

架构实战营-模块1-作业

无名

架构实战营

Map (映射) 实现

BlockQuant

map 哈希表 hash table

飞桨联邦学习框架PaddleFL新升级,实现纯两方安全计算协议

百度开发者中心

最佳实践 百度飞桨 版本升级

数字货币交易所系统APP开发(源码搭建)

数字货币交易所系统APP开发源码搭建

腾讯云 CIF 工程效能峰会完美收官

CODING DevOps

DevOps 云原生 腾讯云 CIF 峰会 开源生态 企业研发管理

《世界质量报告》重磅发布,人工智能与机器学习成软件质量保证测试焦点

现成数字货币交易所源码系统开发

数字货币交易所系统软件开发简介(搭建)

Cloud Studio 邀您互动,好礼送不停 | CIF 活动邀请

CODING DevOps

自动化部署 Cloud Studio 开发标准化 可视化编辑 多人协同

k8s集群安装经历

追风少年

k8s kubenetes

优酷鸿蒙开发实践|优酷 Android 与HarmonyOS Hap 混合打包

阿里巴巴终端技术

android 鸿蒙 客户端开发 HarmonyOS 优酷

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