写点什么

新书问答:Agile Management

  • 2018-04-19
  • 本文字数:3381 字

    阅读完需:约 11 分钟

本文要点

  • 敏捷其本身并不能构成一个目标,而是一种改进产品上市时间、客户价值创造和雇员满意度的工具。
  • 敏捷并非完全是一种技术或工具,它在很大程度上是一种价值和原则。
  • 最强有力的敏捷理念,就是在多学科团队中开展工作。
  • 推荐使用精益和敏捷方法去建立一种混合型组织。
  • 实现敏捷的过程中,应该使用敏捷方式。

Mike Hoogveld 所著的《敏捷管理》(Agile Management)一书,探讨了为提高组织内的灵活性和创业精神,应如何以敏捷方式实现敏捷的原则和价值观。此外,该书还介绍了如何以“客户的声音”为出发点,设计提供给客户的产品、服务、渠道和流程。

有兴趣的 InfoQ 读者,可以下载本书的样章

InfoQ 采访了 Hoogveld。访谈内容涉及:敏捷管理的范畴、组织如何评估自身的敏捷性状况、是什么使得敏捷规划与众不同、如何定义客户价值主张及它们在实践中的具体表现、企业高管应如何增进组织的敏捷性。

InfoQ:您能介绍一下撰写本书的初衷吗?

Mike Hoogveld: 作为一名顾问,我看到很多组织正努力追随客户在行为、竞争和市场环境上的快速改变。从客户的角度来看,传统的运作方式阻碍了组织迅速采取行动,以及由外而内(Outside-in)开展工作的能力。究其主要原因,在于组织的流程针对的是如何提高一些可预测、重复性活动的效率,组织的结构基于的是具有专业分工的独立部门。这引发了我的思考,我应该怎样解决这个问题?

与此同时,在许多 IT 部门内,敏捷正大行其道。在我看来,敏捷的确能成为一种实际的解决方案。综合上述因素,我决定针对在业务领域内部署敏捷的成功因素,启动一项博士课题研究。我在研究中,注意到组织的确非常希望能在业务部门尝试实施敏捷,但正在寻求一种可靠的方法去做到这一点。由此,我决定撰写这本书。

InfoQ:本书面向哪些读者?

Hoogveld:该书主要针对的读者,是那些想要提高自身企业的产品上市时间和客户价值创造的管理者,同时也适合那些希望知道自身能在其中做出什么贡献以及应如何做出贡献的员工。但我也听说,不少顾问和教师也在使用本书。

InfoQ:您如何定义敏捷?

Hoogveld:首先,敏捷是个时髦用语(哈哈)。但是严肃地说,我认为仍然有许多专业人士将敏捷本身看成是目标。敏捷只是一种工具,可以采用敏捷提高组织内的灵活性和创业精神,进而增加以客户为中心、价值创造和员工满意度,缩短产品的上市时间。你可以说,敏捷有助于像创业公司一样地思考和做事。

InfoQ:敏捷管理的范畴是什么?

Hoogveld:这里存在一个陷阱,许多管理人员依然将敏捷理解为部署一套技术和工具,例如 Scrum 等。我有时将这些人称为“Scrum 原教旨主义者”。他们出于各种原因将 Scrum 看成是圣杯,采用 Scrum 手册并按其指导原则完成所有的工作。然而,尽管许多组织完美地部署了 Scrum 技术和工具,但并未带来他们所寻求的优势,例如缩短上市时间等。他们实际上做的是创建了一个新的官僚机构,尤其是在他们完全依附于缩放模型的情况下。

当然,虽然人们的确需要一些工具和技术,但我相信敏捷管理主要针对的是原则和价值。管理者应该创造一种环境,使员工可以利用他们的所有精力和灵感,去为顾客创造最佳的产品、服务、渠道和流程。这种背景涉及通过文化定义、给出行为典范、建立多学科团队、创造便利的实际环境、实施适当的评估和奖励方法等。在此环境中,人们感到可以自由地并安全地进行尝试和失败。他们应适应该环境对自身、同事和工作流程的严格要求,以持续改进组织做事的方式。

我同样也看到,一些组织正在整个组织范围内部署敏捷。因此,敏捷管理也适用于非直接面对客户的组织部门,只要这些部门的活动是可预测的、重复性的,例如财务部门。为了提高效率,应该在这些部门中应用精益方法,创建一种兼具精益和敏捷的混合型组织。在精益和敏捷的交汇处,应关注的是两者间一些共同的原则。

InfoQ: 组织应该如何对自身的敏捷程度做出评估?

Hoogveld:大多数可用的成熟度模型,都可用于衡量敏捷技术和工具的部署程度。我更喜欢从另一个角度来看。首先,确定与敏捷性相关的最重要绩效度量,例如上市时间、员工满意度、客户满意度等。然后,在可能的情况下以这些度量作为基准,追踪它们随时间推移的发展情况,确定各项度量是否正在得到改善。

基于此,读者可以将我书中给出的八种敏捷价值和原则为清单,确定组织在该清单中各项内容上的表现情况。由此所获得的洞察力,可作为评估的起步点,去除各种抑制创建敏捷组织的障碍。采用这一做法,然后观察敏捷技术和工具是如何为日常实践提供支持的。

InfoQ:什么使敏捷规划与众不同?

Hoogveld:Facebook 给出了一个很好的说法。尽管他们对于未来 25 年内组织的发展具有共识,但这是远处天边遥不可及的一个小点。实际上,他们只对未来六个月的发展情况做出规划,因为他们认为事情是如此不可预测,以至于看得过远是毫无意义的。我认为对于组织应该如何做出规划,Facebook 的做法给出了一个很好的解释。不要去制定一个厚厚的计划和瀑布式规划,但应在“内在问题”上达成共识,即你想达到的重要目标是什么?就此问题取得共识,相信团队的所作所为正是达成目标所需的。然后以短周期迭代方式检查进度,并支持对优先级做持续重新排定。超前的洞察力使你能够以最有效的方式完成任务。所以,在事情是未知的、不可预知的或相当复杂的情况下,应该采取一种小步骤推进的方式,不要太在乎效率的问题。

InfoQ: 如何定义客户价值主张?它们在实践中是如何表现的?

Hoogveld:其实很简单:只做客户看重的事情,不要做那些根据一些假设、内部考虑或管理意见认为是重要的事情。应该以“客户的声音”作为出发点,设计提供给客户的产品、服务、渠道和流程。这需要对你的组织彻底地转变思维。举个例子,Booking.com 为增加营收,需要了解网站和应用中的哪些方面对客户是最有效的。为此,它每天会执行约 170 次的 A/B 测试。另一个例子是,Nike 和 Lego 支持客户去设计和购买定制的或全新的产品,该活动使得企业可以洞悉最新的趋势。

我在本书中介绍了一种经过验证的方式,可用于对读者当前的主张做出评估或重新设计,也可用于对新体系结构和实现开展头脑风暴。你可以使用画布,绘制出你所主张的所有元素(例如客户可能会遇到的问题),以及你为解决客户的这些问题所提供的一些有利条件。该方式在日常实践中工作良好。

当然,对于突破性创新(disrupting innovations),有时你仍然必须要做出“信仰上的飞跃”。但你可以通过概念、模型、演示、原型等形式,测试“最小可行的产品”,从而实现降低风险。

InfoQ:要增进组织的敏捷性,企业高管应如何做?

Hoogveld:阅读我的这本书(哈哈)。但是严肃地说,我认为实施敏捷的最佳方式,是通过敏捷的方式来实现。切勿从 Scrum 手册中推出标准蓝图,而是要了解自己定义的方法在自身所处的特定组织中的最佳效果。因此,应该通过开展一些有人工介入的实验,采取多个小步骤确定哪些做法是行得通的,哪些做法是行不通的,并对结果做出评估。

我想指出的是,应从组建多学科团队着手,并审视团队的运行情况,这是我的研究给出的最强有力的理念。我在案例研究和定量研究中所使用的数据表明,这些团队应对自身的目标负起端到端的责任,并且这种责任应被团队的专业知识构成完全覆盖,这样团队中其他成员才可以独立地完成自身的目标。此外,团队所工作的实际物理环境,应有利于开展面对面的和可视化的交流和协作。例如,一间团队专用的工作室。最后一点,应该形成一种公仆型领导层,这样会促进团队中的自组织,进而提高团队的工作速度、承诺感和创业精神。

对于实施的问题,尝试找出一些具备此信念的“信徒”。这些人希望从一种自下而上的新措施着手,并会在达到某个群聚效应(critical mass)时,将新措施与自上而下的方向结合起来。同样重要的是应该知道,在被要求改变他们的工作和行为方式时,人们会承受痛苦。因此,需要不断地传达这种变化对于项目紧迫性和自身抱负的必要性。即,为什么这些变化是十分必要的?这些变化会为人们带来什么?

本书作者简介

Mike Hoogveld (资源管理学硕士)是 Holland Consulting Group 的合伙人。他通过采用敏捷和精益创业方法,帮助企业提高客户绩效。Hoogveld 在 Nyenrode Business 大学从事学术研究。此外,他也是多个大学和商学院的国际演讲嘉宾和客座讲师。Hoogveld 曾为世界各地多家公司和组织工作。详细介绍可参见 www.mikehoogveld.com。

查看英文原文: Q&A on the Book Agile Management

2018-04-19 17:5516864
用户头像

发布了 391 篇内容, 共 133.9 次阅读, 收获喜欢 256 次。

关注

评论

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

redis之单机多节点集群

Java 程序员 后端

Redis小白入门教程

Java 程序员 后端

Redis(十一):键的生存时间与过期时间

Java 程序员 后端

RocketMQ源码分析之NameServer

Java 程序员 后端

SAP为Java 16贡献JEP 387 “弹性元空间”

Java 程序员 后端

Servlet 入门

Java 程序员 后端

macOS 环境安装Flutter

坚果

flutter 11月日更 安装部署

Redis(四):整数集合

Java 程序员 后端

Redis哨兵原理,我忍你很久了!

Java 程序员 后端

Redis常用命令总结

Java 程序员 后端

Redis(二十六):Sentinel—

Java 程序员 后端

【Flutter 专题】12 图解圆形与权重/比例小尝试

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 11月日更

Redis实现feed流(1)

Java 程序员 后端

Redis实现feed流

Java 程序员 后端

RocketMQ 主从同步读写分离机制

Java 程序员 后端

redis数据迁移之redis-shake

Java 程序员 后端

Redis(十六):事件

Java 程序员 后端

RocketMQ消息轨迹-设计篇

Java 程序员 后端

Redis哨兵模式原理剖析,监控、选主、通知客户端你真的懂了吗?

Java 程序员 后端

Redis持久化方式AOF技术原理?一文带你从底层彻底吃透

Java 程序员 后端

Redis的各种用途以及使用场景(1)

Java 程序员 后端

RocketMQ一行代码造成大量消息发送失败

Java 程序员 后端

RocketMQ消息丢失场景及解决办法(1)

Java 程序员 后端

Redis的各种用途以及使用场景

Java 程序员 后端

RocketMQ msgId与offsetMsgId释疑(实战篇)

Java 程序员 后端

RocketMQ 千锤百炼--哈啰在分布式消息治理和微服务治理中的实践

Java 程序员 后端

Serverless 如何在阿里巴巴实现规模化落地?

Java 程序员 后端

Redis安装与部署新手入门教程

Java 程序员 后端

Redis(十八):服务器

Java 程序员 后端

RocketMQ消息丢失场景及解决办法

Java 程序员 后端

Spring @Lookup实现单例bean依赖注入原型bean

Java 程序员 后端

新书问答:Agile Management_Book Review_Ben Linders_InfoQ精选文章