写点什么

Computest 的故事:向着敏捷企业转型

  • 2017 年 8 月 21 日
  • 本文字数:7138 字

    阅读完需:约 23 分钟

主要结论

  • 将客户置于首位,通过更顺畅的价值创建流程改善组织运作。
  • 帮助每个人理解自己在流程中的价值,例如,如何对公司的整体成功做出自己的贡献。
  • 将恰当的人员安排在恰当的位置,支持开放的交流并提供清晰的边界,借此培养自主管理型组织。
  • 将领导力视作整个组织范围内普遍发生的事情,打造一种能鼓励这种做法的指导体系。
  • 通过可视化工作流程管理创造透明度,通过学习了解当前所做工作及有待改进的地方。

Computest 是一家快速增长的公司,目前有大约 120 名员工,总部位于荷兰海牙,专门从事性能测试、安全测试,以及测试自动化领域的工作。

2016 年初,Computest 发起了一项雄心勃勃的任务:“转变成一家自主管理型组织”,曾在 2017 年当选海牙年度创业者称号的公司 CEO Hartger Ruijs 为此撰写了自己的第一篇博客文章:向着自主管理型组织转变

本文介绍了 Computest 的具体做法,并介绍了下列情况和相关数据:

  • 这一使命的主要推动因素:为何一开始要培养自主管理型组织?
  • 具体是如何进行的:从各自为政的职能到多领域团队,从传统方式到敏捷方法,从层级式管理到指导服务。
  • 为何 Computest 要引入外部专家,又该如何建立优雅、共创性的“陪练”式合作关系。
  • 对于 Computest 努力想要实现的全新组织模式,为何必须专注于价值流。
  • 如何对角色和职责进行匹配,并通过看板(Kanban)实施各种想法。
  • 他们从中学到的经验,以及这些经验对后续工作蕴含的意义。

这一使命的主要推动因素有哪些?

2015 年中期员工人数达到 50 人后,Computest 的董事会已经很清楚,目前的组织形式和管理模式需要变一变了。

他们原本采用了基于职能团队的组织结构,为团队安排有专门的直属经理,并直接受 CEO 指挥。

他们讨论过多种模式,但 CEO 不愿为当时的层级式结构进行扩展,再添加另一个层管理机制。CEO 深信必须采用一种截然不同的方法才能顺利应对下列挑战:

  • 应对未来成长

    该公司的目标是每年继续增长 25%-30%,这就需要有一种伸缩性更好的组织模式,但不能增加额外的管理层或员工数,因为这会导致成本增加,敏捷度降低。

  • 维持公司文化

    Computest 的成功始终源自不断进取的精神,以及这家公司非正式但极为友善的文化。任何新的组织模式都必须维持这样的文化。

  • 提高市场导向和客户导向的程度

    该公司有着强烈的技术型 DNA 以及强大的“自内向外(Inside-out)”战略,但希望进一步获得“自外向内(Outside-in)”战略,进而继续扩大现有优势。新的组织模式必须能鼓励大家持续专注于市场本身。

  • 激励各级领导者并实现更高程度的自我责任心

    为了帮助组织中所有人员发挥全部潜力,我们希望实现最大化的自我责任心,推进领导力即服务的模式,取代原本的层级式职能。

  • 变成自主管理驱动,真正的敏捷企业

    在工程方面体验到敏捷工作所提供的优势后,CEO 认为变成真正的敏捷企业将能帮助他们获得重要的竞争优势,而自主管理是实现这一目标的唯一方法。此外 Computest 的客户也有可能会从组织管理模式的创新中获益。

  • 加速创新,缩短上市时间

    更贴近客户,更敏捷地响应客户需求,他们也可以更快速地开发全新解决方案满足客户需求,在更短时间内将解决方案投放市场。

起点

我们的旅途从传统管理模式开始。图 1 展示了我们最初的矩阵式组织形态,这种矩阵有着常见的不足:CEO 的控制力跨度过大,同时“创收”和“收入的交付”之间存在明显的区分。

与其他很多组织类似,销售、营销和产品管理往往通过不同的职能“竖井”加以管理,然而交付团队会按照部署类型进行划分,而非按照不同行业进行组织。缺乏集成式工作流管理机制,这一点已经非常明显。

(点击放大图像)

图1:Computest 最初的管理形态

受到Henrik Kniberg 和Anders Ivarsson 撰写的著名文章 Spotify 如何伸缩自己的开发部门启发,我们决定以多领域团队为中心,辅以团队外部一群侧重于指导,可满足全公司各种职责需求的人员。如图 2 所示,第一阶段的转变过程中,最大的差异在于将尽可能多的集中职能集成于跨领域团队,按照行业调整其结构,并将“领导者(Captain)”和“指导者(Coach)”的领导职责差异对待。领导者负责团队的社交领导以及资源与客户的管理,指导者则通过在不同领域有着丰富经验的思想领袖建立了一个团队,负责策略和解决方案方面的问题。

(点击放大图像)

图 2:转换的第一步

在转换过程的早期阶段,我们打破职能竖井创建了侧重于不同市场的多领域团队。一开始我们的员工不能充分理解后者的作用,但最后发现这是我们向着真正的客户导向型组织转变过程中一个至关重要的决定。尽管如此,在对结构进行扩展促进敏捷度的过程中,我们依然面临棘手的工作流程管理问题。虽然在图 2 所示的模式中,依然由组织结构而非客户导向型流程所支配,但箭头代表了我们向着价值驱动型模式转换过程的第一步。由于领导职责的不明确,我们还陷入了矩阵型组织的陷阱中。在这一阶段,我们主要解决两个问题:1) 如何通过对人员进行组织来执行整个公司的不同任务,以及 2) 如何在领导者和指导者之间分配领导职责。

为何向外界求助?

虽然我们意识到客户导向多领域团队积极的一面,但面对其他挑战还没有找出有效的解决方法。实际上由于太多地考虑该如何组织自己的工作,而忽略了实干,我们开始失去活力。在为核心多领域团队之外的人员厘清角色和职责时,这个问题尤为严重。在考虑到组织转型过程中可能面临的机遇以及蕴含的风险后,我们决定寻求外部建议。

在研究过有关领导力和自主管理型组织的大量案例时,我们读到了 InfoQ 一篇名为“什么是自组织团队”的文章。随后意识到其他人早已经历并成功解决了我们目前面临的难题,在一通电话后,我们与本文作者 Sigi Kaltenecker 首次见了面。“你知道已经触及自己认知的局限,需要外界的帮助,这往往是强大和自信的象征”,Kathleen Sutcliffe 和 Karl Weick 在他们的经典的“掌控意外(Managing the Unexpected)”一文中这样说过。

为应对 Computest 遇到的意外,我们决定首先通过现场会议相互了解,并确定外界帮助能起到最大作用的地方。虽然 Ruijs 和 Riedl 将自己称作“指导怀疑论者(Coaching skeptic)”和“咨询抵抗者(Consulting resistant)”,这让 Kaltenecker 感到吃惊,但这次会议依然沿袭了以相互尊重和开放为主的文化。在专业方面,我们针对外界帮助达成了下列预期:

  • 针对整个改变过程提供指导。
  • 鼓励“实作”。
  • 找出有可能存在盲点的领域。
  • 为需要的地方提供必要的经验技能。
  • 分享来自其他公司的良好实践。
  • 充当一种观察、倾听并提供反馈的“陪练”搭档。

从时间的角度考虑,我们决定以迭代的方式解决自己的问题,每 6 周 -8 周进行一次为期 2 天 -3 天的“冲刺”,并持续进行下去。在这些冲刺期间,我们会通过邮件、电话或 Skype 交流最新进展,确保所有人紧跟步调并随时就出现的问题进行澄清。后来我们甚至为负责转变的核心团队建立了一种所谓的热线,在大家需要时借此引入外部经验和帮助。

从内容的角度考虑,从一开始我们就极为明确,我们这种依然类似于矩阵的组织结构对业务敏捷性来说实际上是一种障碍,而非催化剂。因此我们决定将精力全部专注于大目标:组织看起来应该是什么样的?如何培育出可以感觉到,并能快速反应的文化?为了在所有层面增强自主管理能力,又需要什么样的领导力?

至于答案,毋庸置疑,我们需要从组织的最上层着手。为了履行我们对管理方式所做的承诺,Ruijs 和 Riedl 一开始就投入了多到让人吃惊的时间和精力。随后我们发现,通过分享与组织有关的一些基本假设,进而做出改变并相互帮助,这对作为外部顾问的 Kaltenecker 以及公司内部人员 Ruijs 和 Riedl 之间的合作非常重要。我们没用多长时间就获得了下列共识:

  • 组织也是一种社交系统,内部的行事方式自有一套“自然”准则(即组织文化)。
  • 任何系统都不仅仅是所含部件的简单汇总,而是不同部件相互交互的产物(即敏捷活力)。
  • 无论系统或人员都不能简单地直接改动。需要足够长的时间提前通知,需要被理解,需要参与,最终承诺实施所要进行的转变(即争取人才)。
  • 同时这种转变很可能产生变数,因为我们需要持续不断地审查并适应自己最初的“方案”(即逐渐演变)。
  • 指导是持续改进的催化剂。因此指导者必须能同时提供技能和过程指引,这样才能共同应对最大的挑战(即敏捷和系统化指导)。
  • 系统中任何变动都要从最顶部着手。需要有一定程度的首席管理层和 / 或负责人来设定恰当的边界,并对希望在组织内部看到的行为模式制定规范(即自主管理型系统的先决条件)。

为何专注于价值流会如此必要?

基于这些假设,我们通过精益思维模式克服了扩展整个组织的结构,而不仅仅是流程这一过程中面临的难题。也正是因此,我们确定了自己的价值和价值流,并以价值生成活动作为中心,周围围绕着为多领域团队提供支持的特殊领导力服务,借此重塑了我们的模型。通过这种方式,“流”本身将居于首位。在陪练合作模式的帮助下,Ruijs、Riedl 和 Kaltenecker 通过合作,逐渐创建出目前的 Computest 模型。

(点击放大图像)

图3:框线图绘制的模型草案

图3 也许可以帮你概括了解共建式协作到底是什么样的。这一模式基于极强的信任,同时要求大家必须愿意分享自己的想法,并愿意根据他人的想法进行设想和行动。我们就这样一步步从想法中提炼出了最精髓的东西:通过一个价值流从不同想法直接延伸至能够让客户满意的价值,当然整个过程都是由感到满意的员工来执行的(图4)。从务实的角度来看,价值流可以分为两个主要部分,随后又可通过不同的看板飞行水平(Flight level)来代表(见下文)。“战略发展流”主要侧重于开发和完善我们的解决方案产品组合,但同时需要通过战略性的内部项目增进我们自己的能力。“产品上市流”将客户生命周期内的所有活动,从营销和销售,到交付和收款,全部结合在一起。这样便可将战略发展流的成果实质化。很明显,为了将想法变成客户获得的价值,所有流的所有组成部分都不可或缺。

(点击放大图像)

图 4:一个端到端的价值流

角色和职责

以流的思维代替原本的条条框框,这已经是一步飞跃,但我们依然需要回答一些基本问题:从组织的观点来看,我们的员工到底是在什么位置开展自己工作的?当不同职责开始归属于不同的多领域团队但没有专门的负责人,从能力的角度来看,又该如何管理这些职责?针对整个公司提供的不同服务,我们的想法又是什么?

为了得到有信服力的答案,我们为员工提供了三种工作模式:

  • 多领域团队

    我们的大部分员工是全职的,并且全身心归属于某一个多领域团队。侧重于具体行业的这些团队是与对应市场建立联系的关键,需要逐步培养出面向不同领域的经验。

    例如:销售团队、安全专家、性能专家、功能测试专家

  • 多团队服务(MTS)

    主要适用于原则上来说,应当属于且位于某个多领域团队内部的角色和经验,但并非必须设立全职职位的角色。MTS 角色的员工虽然是专注于团队层面的,但可以同时加入多个团队。

    例如:交易团队、人员招募团队、合作伙伴管理团队

  • 泛公司服务(CWS)

    主要适用于履行公司不同任务和职责必不可少,因此不应归属于某一特定团队的角色。CWS 员工可担任战略发展流中不同领域的专家,但同时也可帮助并指导产品上市流涉及的团队。

    例如:技术指导、F&A 指导、解决方案营销、研发、开发

图 5 概括展示了我们价值流模型中的这三种模式。其中 CWS 员工需要负责战略发展流,其他团队以及 MTS 人员需要负责产品上市流。需要再次提醒,所有员工必须明确知道自己的角色是什么,以及自己如何能为 Computest 的整体成功做出贡献,这一点极为重要。

(点击放大图像)

图5:流、角色和职责概述

价值流和可视化工作管理

你也许觉得这听起来是个有趣的理论,但具体实践效果如何?为了让我们的想法变成现实,具体又是怎么做的?嗯,我们决定通过可视化工作管理机制让自己的想法尽可能保持透明。看板为我们提供了一种行之有效的手段。

(点击放大图像)

图6:看板飞行水平

Klaus Leopold 提出的飞行水平提供了极为有用的指南,可以帮助我们不仅在本地,更是可以在全球范围内实现目标。图 6 展示了如何通过看板更好地运营日常业务,对多个团队的工作进行协调,或阐述自己的产品组合最终将会是什么样的。这并不是一种成熟度模型,而是一种能对组织中不同方面进行优化的沟通工具。按照 Leopold 的说法:“如果你想在组织内部进行一些改进,必须首先明确从哪一层面进行才能获得最佳效果。飞行水平可以帮你确定最适合的层面。一般来说,可以认为飞行水平越高效果就越好”。

图 7 展示了我们战略板的当前状态(看板飞行水平 3),其中概括包含了:

  • 目前 Computest 正忙于什么工作(黄色和绿色“贴纸”代表具体活动)。
  • 我们并行做了多少工作(对进行中工作数量进行限制,不再开始新工作,先结束原有工作)。
  • 不同活动的典型类型(侧重于内部或外部改进)。
  • 战略开发过程的典型步骤(从“想法”和“探索”等内容到“开发”、“反馈”以及“交接”)。
  • CWS 员工明确同意的策略(四处张贴的白色纸张)。
  • 谁正在做什么(每个贴纸上的标记的名牌)。
  • 哪些工作受阻了(红色小贴纸)。
  • 每个阶段还有多少工作有待完成(遵循不再开始新工作,先结束原有工作的原则)。
  • 为了尽可能促进流动,每日立会确定的当前工作重心(倾斜 45°的贴纸)。

(点击放大图像)

图 7:Computest 的战略板

在战略层面应用看板,产生了一些效果:首先,通过责任转移塑造了更流畅的价值流上行。如果我们不针对专家发现阶段进行必要的设计,做出更明智的经济考量,并对进行中的工作数量进行限制,那么注定一开始就会失败。因此我们会试图同时鼓励战略性思维和产品组合管理。其次,可视化工作管理使得我们可以更好地协调不同层面的工作。针对正在从事的工作建立系统化的视图,有助于我们端到端地专注于价值流本身。通过让最终目标变得更透明,也可以更容易地将团队工作与组织倡议进行匹配。为工作设置物理界限,也使得我们可以更好地进行协作。这也体现出了一种共同关注(例如“学着观察”)以及将生理与心理健康相结合(例如,我们真正会亲自站在看板前,并且随时准备进行交流,而不会受制于普通会议上常见的阻碍因素,例如桌椅电脑等)的意味。最后同样重要的是,这样做有助于帮助受到相关变化影响的人更好地塑造出真正自主管理型组织。

我们的实体看板就摆在宽阔的大堂里,而大堂本身也是整栋建筑的社交中心。这样我们的战略项目也获得了一个真正意义上的可视化工作流程管理机制。同时不仅符合转变工作的核心团队,所有 CWS 员工也会在工作中使用看板,越来越多的会议都改在看板前进行。甚至 Computest 董事会也决定董事会会议上针对战略话题的常规更新也应该在看板前进行。

经验和未来展望

感觉可以写一写我们目前的成果了。在转变为敏捷企业的过程中,Computest 走到哪一步了?目前获得了哪些经验?又该如何将这些见解应用到面向不远的未来进行的规划工作中?

我们获得的经验可总结如下:

  • 完善组织(模型)并非最终目的,而是为了更好地管理为客户创造价值的过程。
  • 每位员工需要理解自己在这个过程中的价值,采取的每一步行动必须对价值的创建产生直接或间接的效果。看板使得这一切变得非常透明,可以通过贴纸将个人与职责联系在一起。更重要的是,随着会议中对看板的使用越来越普遍,价值已经成为所有人最关注的问题。
  • 如果不知道自己目前所处的位置,那么就很难进行改进。
  • 自主管理并不意味着个人可以自由行事。这并不是一种放任的策略,而是需要在基础架构、信息、反馈环路的决策权等方面通过系统化的边界进行明确的指导。为了鼓励高效率的自主管理,我们会对相互之间的预期进行澄清说明,并确立明确的策略。
  • 也许听着琐碎,但少即是多!可视化工作流管理机制可大幅提高透明度。

我们会尽可能记住这些经验,但同时依然有很多工作等待完成。接下来我们计划:

  • 为价值流的运营部分实现看板,例如设计飞行水平 2 的看板,更好地协调团队工作。
  • 告知、培训并邀请所有员工参与,顺利实现整体承诺。
  • 为全公司各方面人员进行培训,以实现更好的回顾能力。通过自己的经验以及各种技能(例如从敏捷回顾中获得价值)进行开发,我们已将“回顾”视作学习和完善的重要途径。全面回顾各种基本原则,提供更清晰的结构和鼓励方法,在所有领域建立更完善的额回顾序列,借此改善整个公司的审查和适应能力。
  • 通过不同服务团队的大规模群体回顾能力进行实验,并在顾问帮助下将其与我们在客户端的经验进行整合,借此提炼各种创新的想法并最终顺利投放市场。
  • 与其他自主管理型组织交流,从其他践行者身上学习经验。
  • 关注更上游的东西:如何确定最恰当的战略规划?

关于本书作者

Hartger Ruijs是天生的创业者,坚信技术能为社会带来更多价值的他,23 岁就成立了自己的第一家公司。2005 年,他成立了 Computest,目前该公司员工总数已超过 100 人。Ruijs 是个价值驱动的人,会不断尝试自我完善,并认为自我责任和快乐的员工是为客户创造价值,让客户感到快乐的基础。他最近当选了荷兰海牙地区“年度创业者”称号。

Clemens Riedl是奥地利的 IT 创业者,他早在 19 岁就开始创业,并于 1998 年将自己的公司卖给 Dutch Exact Group,后在这家公司承担各种跨国管理职责直到 2010 年。随后他投资了一系列小型 IT 公司,包括 Computest,他在这家公司的组织发展和管理指导等工作中积极担任各种角色。同时他的关注点也转向了高端葡萄酒和当代艺术领域的小企业。

Siegfried Kaltenecker是维也纳 Loop Consultancy 公司的联合常务董事。作为精益和敏捷变更管理领域的专家,Kaltenecker 曾参与大量公司的相关工作,包括 bwin.party、eSailors、Magna、RWE、Swiss Federal Railways,以及 Thales Group。他曾撰写过 InfoQ 图书 Leading Self-Organising Teams ,并合作撰写了 Kanban Change Leadership 一书。

作者 Clemens Riedl Hartger Ruijs Sigi Kaltenecker 阅读英文原文 The Computest Story: The Transformation to an Agile Enterprise

2017 年 8 月 21 日 17:46906
用户头像

发布了 283 篇内容, 共 90.4 次阅读, 收获喜欢 48 次。

关注

评论

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

Ansible 变量

耳东@Erdong

变量 ansible 8月日更

Netty如何解决粘包以及拆包问题

慕枫技术笔记

后端 Netty

vue入门:router路由简介与使用

小鲍侃java

8月日更

万企明道成立八周年,邀你书写留言!

明道云

【Vue2.x 源码学习】第四十二篇 - 组件部分 - 组件挂载流程简述

Brave

源码 vue2 8月日更

手撸二叉树之根据二叉树创建字符串

HelloWorld杰少

数据结构与算法 8月日更

人工智能下的音频还能这样玩!!!!

Python研究者

8月日更

Android基础知识

刘帅强

腾讯良心了?!!!

Jackpop

elasticsearch7.13.4 ik中文分词器安装

Rubble

8月日更

服务发现机制SPI居然是破坏者!

4ye

Java 源码 后端 sping 8月日更

大数据技术不能被平台滥用,必须维护消费者的合法权益

石头IT视角

缓存函数的简单使用

编程三昧

JavaScript 8月日更

管道(Channel)的读取与写入「让我们一起Golang」

Regan Yue

协程 Go 语言 8月日更 管道

MySQL 系列教程之(十)索引原理:B+ 树与索引

若尘

MySQL 数据库 8月日更

Vue进阶(五十二):vue-cli 脚手架 webpack.dev.conf.js 配置文件详解

No Silver Bullet

Vue 8月日更

iOS开发:开发过程中单例模式的使用

三掌柜

8月日更 8月

硬盘空间免费扩容了2TB!!!

Jackpop

程序员必备!5款小众高效的开发神器

Jackpop

帮小姐姐打分系统的模型创建,滚雪球学 Python 第三轮第 11 篇

梦想橡皮擦

8月日更

【Flutter 专题】61 图解基本 Button 按钮小结 (一)

阿策小和尚

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

你可能不知道的css动画性能

云小梦

CSS layout requestAnimationFrame 重排和重绘 will-change

Vue进阶(五十一): vue-cli 脚手架 webpack.base.conf.js 配置文件讲解

No Silver Bullet

Vue 8月日更

Linux之bc命令

入门小站

Linux

在线HTML5,CSS3,VueJS,jQuery运行测试练习工具

入门小站

工具

销售 小姐姐 给买家打分系统,用 Python Django 又整了一个花活

梦想橡皮擦

8月日更

Go 语言, 一文彻底搞懂 iota 实现原理

微客鸟窝

Go 语言 8月日更

【设计模式】访问者模式

Andy阿辉

C# 后端 设计模式 8月日更

白手起家之注册中心zookeeper

卢卡多多

ZooKeeper原理 8月日更

Go字符串拼接最佳实践

Rayjun

Go 语言

低品质的勤奋者

箭上有毒

8月日更

Computest的故事:向着敏捷企业转型-InfoQ