@liuhui0803
2017-07-01T18:33:58.000000Z
字数 7620
阅读 1919
文化和方法
敏捷
组织管理
Scrum
摘要:
本文介绍了Computest贯彻自主管理型组织这一使命的方法。其中介绍了主要的推动因素,整个过程的开展方式,Computest专注于价值流的原因,以及他们将角色与职责进行一一对应,并通过看板(Kanban)实施各种想法的方式。同时本文还分享了他们学到的经验,并探讨了这些经验对后续工作蕴含的意义。
正文:
主要结论
- 将客户置于首位,通过更顺畅的价值创建流程改善组织运作。
- 帮助每个人理解自己在流程中的价值,例如,如何对公司的整体成功做出自己的贡献。
- 将恰当的人员安排在恰当的位置,支持开放的交流并提供清晰的边界,借此培养自主管理型组织。
- 将领导力视作整个组织范围内普遍发生的事情,打造一种能鼓励这种做法的指导体系。
- 通过可视化工作流程管理创造透明度,通过学习了解当前所做工作及有待改进的地方。
Computest是一家快速增长的公司,目前有大约120名员工,总部位于荷兰海牙,专门从事性能测试、安全测试,以及测试自动化领域的工作。
2016年初,Computest发起了一项雄心勃勃的任务:“转变成一家自主管理型组织”,曾在2017年当选海牙年度创业者称号的公司CEO Hartger Ruijs为此撰写了自己的第一篇博客文章:向着自主管理型组织转变。
本文介绍了Computest的具体做法,并介绍了下列情况和相关数据:
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),其中概括包含了:
图7:Computest的战略板
在战略层面应用看板,产生了一些效果:首先,通过责任转移塑造了更流畅的价值流上行。如果我们不针对专家发现阶段进行必要的设计,做出更明智的经济考量,并对进行中的工作数量进行限制,那么注定一开始就会失败。因此我们会试图同时鼓励战略性思维和产品组合管理。其次,可视化工作管理使得我们可以更好地协调不同层面的工作。针对正在从事的工作建立系统化的视图,有助于我们端到端地专注于价值流本身。通过让最终目标变得更透明,也可以更容易地将团队工作与组织倡议进行匹配。为工作设置物理界限,也使得我们可以更好地进行协作。这也体现出了一种共同关注(例如“学着观察”)以及将生理与心理健康相结合(例如,我们真正会亲自站在看板前,并且随时准备进行交流,而不会受制于普通会议上常见的阻碍因素,例如桌椅电脑等)的意味。最后同样重要的是,这样做有助于帮助受到相关变化影响的人更好地塑造出真正自主管理型组织。
我们的实体看板就摆在宽阔的大堂里,而大堂本身也是整栋建筑的社交中心。这样我们的战略项目也获得了一个真正意义上的可视化工作流程管理机制。同时不仅符合转变工作的核心团队,所有CWS员工也会在工作中使用看板,越来越多的会议都改在看板前进行。甚至Computest董事会也决定董事会会议上针对战略话题的常规更新也应该在看板前进行。
感觉可以写一写我们目前的成果了。在转变为敏捷企业的过程中,Computest走到哪一步了?目前获得了哪些经验?又该如何将这些见解应用到面向不远的未来进行的规划工作中?
我们获得的经验可总结如下:
我们会尽可能记住这些经验,但同时依然有很多工作等待完成。接下来我们计划:
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