红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

文化才是校正方向的标杆 —— Jimdo 团队应对规模增长的经验

It's always a scaling problem!

  • 2014-07-28
  • 本文字数:10366 字

    阅读完需:约 34 分钟

一切都可归结为规模问题!

这个说法可能以偏概全,但是大型和中型组织里的许多弊病,归根结底是由于组织的规模增长而产生的。五个人、十个人在一间房里共事并不困难。每个人都清楚正在进行的工作和需要达到的目标。沟通没有障碍,决策很快就可以定下来。然而,当业务蒸蒸日上,雇用的人越来越多,问题就开始出现了。

组织扩大到二、三十人的时候,原来的工作方式一般还支持得住,只是早晚要增加一些管理架构来帮助协调各方面的工作。大多数公司会开始设置若干中间管理层,成立专职部门,对计划的要求也严苛起来。这些措施都是有意义的,但也都有其代价。团队里愉快的工作氛围一下子淡了。创新和变革受到制肘,步调也慢了下来。过不了多久,你就会开始慨叹哪里冒出来那么多的问题,怀念当初一切都简单明了的好时光。

本公司 Jimdo 的业务是提供简单易用的网站构建方案,支持多达 12 种语言。我们同样遭遇了伴随着快速成长而来的种种困扰。我们的团队在 5 年的时间里从 30 人增加到了 180 人,各种问题都开始显露出来。然而我们希望换一种途径去解决规模难题,因为“标准治疗方案”的处置结果不符合我们的期望。Jimdo 的文化实在是太重要了(详见另文对Jimdo 文化的说明)。熟知本公司的人都会理解,传统的层级式组织架构实在与Jimdo 格格不入。

Jimdo 不能按一般的方式去处置规模难题,还有第二个原因。我们完全无法容忍任何长期的效率低下。这好像是一句正确的废话(谁会喜欢效率低下呢?),但对于我们有着切实的意义。为了说清楚这一点,我们先要简短地回顾一下本公司的历史。

Jimdo 在创始阶段是完全依靠自身的收入而成长起来的。我们只接受过为数不多的资助(500k),没有花过一分钱的风投资金。两年前,几位创始人甚至拒绝掉了8 位数的报价。他们明确地决定保持对公司的完全掌控,不把股票上市当作目标。熟悉创业圈子的人会知道,这样的做法不但异乎寻常,而且是极大的挑战,因为竞争对手不会像这样绑住自己的手脚!也就是说,基本上我们的主要竞争对手随时可以凭借多出一大截的资金来挤垮我们。

由于这些财务上的限制,我们在处理规模难题的时候,不可能押宝在低效率的组织结构上面。单纯地花更多钱去增加人手,或者投放海量的网络营销,也解决不了问题。我们需要找到一条符合自身具体条件的解决之道,才能保持住Jimdo 产品的领先位置。

Jimdo 解决规模难题,靠的是文化、沟通和持续改善这三大要素。让我们按照从后往前的顺序来逐一探讨吧。

Kaizen——持续改善

Kaizen 翻译过来的意思是“持续改善”。最初为丰田公司所推广,由于精益生产实践而变得广为人知。最近几年“Kaizen”这个词在行业里风行一时,传播范围已经远远超出了敏捷社群。

持续改善可以有各种实现形式,有的只是一套听取员工建议的简单制度,有的是专门设计的目标分解机制,从管理层到部门再到个别团队层层落实。对于 Jimdo 来说,持续改善不是一件一劳永逸的事情,不是等人有空的时候才做做看的事情,也不是只在个别团队实施的小圈子爱好。我们认为持续改善对于整个公司都是必不可少的,并且费了很大力气让持续改善的思维越来越深地扎根到公司的基因中去。

为了让持续改善完全融入我们的工作流程,Jimdo 采用了 David Anderson1 发展起来的“看板方法(Kanban Method)”作为基准。看板方法提出六项核心实践:

  • 可视化
  • 限制“在制品(WiP,Work in Progress)”数量
  • 管理价值流
  • 明示的规则
  • 反馈循环
  • 通过协作完成的实验来获得提高

下面的例子可以说明 Jimdo 所用的看板是什么样子的。

走进我们的办公室,你会注意到墙上挂着三、四十块白板。其中一部分充当经典的“卡片墙”(或称“看板图”),其余的用来显示若干数据和图表。还有一些白板上画着检查清单或者时间线。每块板子的作用都是在恰当的时间向恰当的人提供正确的信息。

这种可视化的管理让受到某些决策影响的人们可以自发组织起来,完成恰当的决定。每当成立一个新团队或者任务小组的时候(这是经常发生的事情),团队要做的第一件事就是设立一块新的板子。这块板子将成为他们组织工作的地方,板子上显示的数据和图表也是他们展开有意义讨论的基础。

(点击图片可放大观看)

可视化的管理在Jimdo 随处可见,并不局限于开发团队。图中展示的除了有内部教练团队(A-Team)的板子,还有厨师用来管理点餐单的板子。

新团队成立后要做的第二件事情,是规定好每日“站立会议”。站立会议是以固定频率(通常为每天)举行的简短、专注的团队会议。会议的目的在于互相通报最新的进度和困难,并组织协作去完成最重要的任务(深入了解站立会议可参阅 Jason Yip 的文章)。各种站立会议已成为 Jimdo 员工例行的活动,充当着第一重的反馈循环。

我们用“回顾会议(retrospectives)”作为第二重的反馈循环。回顾会议是以研讨会的形式,让团队或更大规模的群体达到改进工作方式的目的(参阅 InfoQ 迷你书《 Getting Value out of Agile Retrospectives 》)。Jimdo 的大多数团队都固定每二到四周举行一次回顾会议。每次回顾都由一位来自团队外部的人员主持。在 Jimdo 每年要举行 150 到 200 次回顾的情况下,外部主持人的设定产生了一个有意思的问题。

为了有足够的人选去带领所有的回顾活动,我们训练了来自开发、运营、设计、支持等不同背景的团队成员,让他们成为优秀的主持人。训练的内容十分全面,除了教授主持的技巧和回顾的技巧,还会与有经验的主持人共同主持,或安排教练旁听辅导。

我们还建立了以持续改善为主题的实践社群(Community of Practice)。这是主持人之间互相分享知识与经验的一个定期聚会。聚会不止向在任的主持人开放,任何感兴趣的人都可以参加。

目前我们有一个包括 21 名主持人的抽签大名单,我们的 20 多支团队可以随时从中抽选回顾会议的主持人。这些实施回顾活动的团队里面,包括了国别团队、在线营销团队、SEO 团队等等,并不仅仅是开发团队。就连我们的大厨,也刚刚和他的队伍举行了第一次回顾——成果之一是让每批次的供餐份数可视化,以便更准确地预计备餐数量。

回顾活动受到我们三位创始人的极力支持,这是很妙的一点。只要有团队邀请他们出席回顾,他们都会尽力参加。团队为什么要邀请创始人出席呢?因为在某些情况下,比如问题涉及多个团队,或者需要在更大的组织范围里实行系统性的改革,这时让创始人参与进来就有意义了。

在某支团队面临特别大压力的时候,常常是某位创始人去提醒他们实施回顾。当然创始人绝对不会支配会议的结果。

我们的回顾活动会产生五花八门的结果。曾经有些团队决定向其他团队提供“实习”位置来提高相互的理解。还有些团队决定尝试新的组织框架,甚至解散团队本身。当然大多数情况下,我们会进行小幅度的实验,避免直接进行更难逆转的大规模变革。

有一个例子发生在某支团队商量引入结对编程的时候。他们针对优点和缺点进行了好几次长时间的讨论,最后一致同意先进行一次实验。团队中的两名开发者用了结对的方式来完成一个特性的开发,然后向整个团队报告他们的体会。实验获得了非常正面的反应,于是其他人也产生了兴趣,纷纷开始结对编程。到今天,结对编程已经成了这支团队不可或缺的一部分,团队的人员也成为结对编程实践的传播者和其他团队的宝贵学习资源。

“最高指导原则(Prime Directive)”是 Jimdo 实施一切回顾及协作活动的基本原则。关于此原则详情可参阅《Project Retrospectives》一书 2。(“最高指导原则:无论眼前所见为何,我们理解并真诚相信,每个人都已根据自己当时所知、自身技术与能力、手头可用的资源、眼前的实际情况,穷尽了自己的努力。”)

Jimdo 的回顾实践还有最后要说的一点,那就是我们并不把回顾局限在团队的层次。去年举办第一届 Jimdo 用户大会之后,由各团队抽调人员组成的会议组,解散返回原团队之前举行了一次回顾。我们发布 iOS 应用之后也有一次回顾。iOS 应用项目是汇集了全公司上下努力成果的大项目,回顾的时候全部 20 多支团队都派了代表出席,三位创始人也都全部到齐。

谈持续改善就不能不提“松弛时间(slack time)”。松弛时间是可以用来履行改善措施的工作余裕。举个例子,很多团队都会遇到这样的情况:其实每个人对于应该采取哪些改善措施都毫无异议,但是这些措施一条都执行不下去。这种常见现象就是徒有回顾,而缺乏松弛时间造成的。时间都被日常的工作任务占用掉了。

那么 Jimdo 怎样确保我们有充分的松弛时间来履行改善措施呢?

首先,我们对每周五做了特殊的安排。早上有全公司早餐,然后下午还有各种讲演或其他形式的教学活动。并不是说这一天大家都不去做任何“常规”工作,我们只是发现周末的时候大家比较容易放下团队里的日常事情,换换脑子。

第二种增加松弛时间的办法是每隔几个月就举行一次“编程马拉松(hackathon)”。马拉松期间,大家会组成小团队,用一个星期的时间去挑战一些新鲜的事物。马拉松的主题非常多样化,但都是事先按支持度投票选出来的。编程马拉松不是为了给滥开新项目找个冠冕堂皇的借口。其目的在于让你有时间跳出日常的窠臼,离开熟悉的团队,与其他人一起去探索一些陌生的主题。

持续改善的效果最终取决于组织的文化。组织认可那些投入到改善活动的时间和精力的价值吗?大多数情况下,改善是由每个团队自发的,团队自行组织起来,制定和实施改善的计划。事前并不需要得到任何人的批准。

沟通

按照系统思维倡导者(Systems Thinkers)Russell Ackoff 的说法,“一个系统的总体表现并不等于其各部分表现之和,而是等于各部分之间相互作用的乘积。”3 这句话对于组织的设计和发展,有着很深的含义。的确,组织里不能缺少拥有卓越技能和丰富经验的优秀人才,但仅凭这些,仍不足以在组织层面取得整体的优异表现。

请想象一支每个位置上都由全世界最好的球员组成的足球队。这支队伍会是世界最佳球队吗?不见得!除非这些球员彼此能够充分地沟通与合作。这个道理放在任何组织都是成立的。个人与队友之间的相互作用是关键所在。放在更高一点的层面,不同团队之间的相互作用也决定着整个组织能否取得成功。

Jimdo 是怎么样维系并增强这种相互作用的呢?在团队级别,站立会议和回顾基本承担了这方面的功能。此外我们安排了团队教练作为补充。教练可以在主持、冲突管理这一类能够从外部视角获得益处的事情上提供帮助。

我们针对团队间的沟通设置了几种交流形式。有些是敏捷界的常见做法,但也有一些可能是 Jimdo 独有的。

实践社群

随着 Jimdo 成长,我们的团队也越来越趋向于综合型的团队。不再像以前那样,拥有相同技能的成员都呆在同一支团队里。那么这就产生了一个新的问题:我们需要找到一种方法,让从事同一领域却分属不同团队的专业人员能够互相协调。比如说,让所有的设计师能够维持对公司设计标准的一致理解,也维持对最新的趋势和工具的掌控。

Jimdo 的答案是实践社群(Community of Practice,CoP),敏捷界常见的一种沟通形式。各种 CoP 定期聚会,一般隔周聚一次,每次两三个小时。成员可以在会上交换知识,约定或调整各种标准,也可以共同解决工作中遇到的问题。

Jimdo 里的 CoP 数量不断增加,有 PHP 小组,有基础设施小组,甚至有威士忌品酒小组。除了 CoP,我们还创造了另一种有些类似的小组形式,取名为“Matrix Teams”。“Matrix”这个字眼一方面表达出矩阵式的组织结构,另一方面也带有它在同名电影中的含义。要说清楚这种新的小组结构的创造过程会跑题太远,我们还是另找机会吧。

全体大会“Teamverløtung”

周一下午是全体大会“Teamverløtung”的时间。也就是说,汉堡办公室的所有人——人数保持在 130 人左右——全部聚集在一起,就每周的情况做一次小结。会议首先由几位创始人发表最新的数据(如新的注册人数和销售情况),然后介绍新加入的员工。这些新同事会逐一进行自我介绍,并受到大家的鼓掌欢迎。

再公布完其他重要消息,就该到四支团队轮番上来介绍各自范畴的新情况了。内容包括团队的进展,面对的问题,需要其他团队帮助解决的困难等等。每周只有四个名额,所以每支团队都要轮候四周才有一次机会。

最后由我们的“正能量管家(Feel Good Manager)”公布本周的公司活动安排,并主持“茶会”的抽奖。抽中的员工们要一起喝茶。设立“茶会”的目的,是让未必互相熟悉的同事有机会坐在一起喝茶聊天。

Teamverløtung 大会 20 到 30 分钟之内就会结束,并完成其让 Jimdo 的每一个人都掌握最新情况的目的。会议过程会拍成视频,让我们在旧金山和东京的团队也参与进来。

Teamverløtung 的具体形式在这些年里变动过好几回,不过主旨始终如一。即尽可能地让所有员工都掌握最新的信息,理解彼此的想法。而要做到这一点,最好的办法莫过于面对面的沟通,再加上尽量少的一点书面媒介。

我们还观察到全体大会的一点额外好处。在 Teamverløtung 散会之后,有一些小群体会留在会场上继续讨论某些话题,协调彼此的工作。这样的交流有着极高的价值,尤其对于那些位于不同楼层,不常碰面的团队来说非常有效。聚集 130 人来开半小时的会显然是很高的成本,但我们非常确信,如果不这么做,代价只会更高。

开放的优先级评议会

开放的优先级评议会(Open Prioritization Meeting,Jimdo 员工一般简称为 OPM)是我们用来改善团队间沟通的另一种形式。包括商店团队、支付团队、办公室管理团队在内的若干团队都设立了两周一次的 OPM 周期。任何人都可以带上对主办团队的请求出席会议,无论是功能需求,还是改进建议。

与会者抛出自己的请求,解释为何自己这桩请求对于公司有很高的业务价值,应该排在优先完成的位置。然后主办团队,通常再加上一位创始人,将决定哪些请求可以进入后续两周的日程,哪些会被拒绝。

OPM 会议有一个重要原则:“绝不许下无法实现的诺言!”这就要求每个团队都准确把握自身的能力,知道自己可以应付多少份请求,每份请求不能超过多大的工作量。

没有被接受的请求立即交回给提交者。有时候主持团队会请提交者过几周带着这份请求再来一次,有时候则会彻底拒绝。被拒绝的提交者固然难过,但早早就失望,总好过被虚假的希望所蒙蔽,到破灭的时候经受更大的挫折。

OPM 保证了不会积压大量的请求。按照我们的经验,OPM 是最有效的期望管理(expectation management)方式!何况一次 OPM 只需要花费二、三十分钟。起初只在一支团队里试行的 OPM,很快就推广到了别的团队,而且往往是自发的。

我们观察到实行 OPM 的若干正面效果:

  • 团队能够承担的工作量更清晰可见。更容易防止团队超负荷运转。
  • 待完成的任务队列会产生压力。(“我们还有那么多工作没做完!永远都做不完!”)废止一部分队列(很多请求会被即时拒绝,不留记录),压力会降低。
  • 相关人员可在会议上直接沟通,而非像以前那样在请求轮候系统里干排队。这么做有利于防止误解,建立信任。
  • 促使各团队内部展开讨论,确定哪一项请求是对于团队来说最为重要的,因为只有一两项请求可能被接受。
  • 出席会议的所有人都会得知公司为何决定投入到某些方面,而放弃另外的一些方面。创始人被逼着经常去筹划公司的战略。(“你的想法很好。但今年我们希望把重点放在另外一些目标上。原因如此这般。所以我们今年不会执行你的想法。”)OPM 在这里充当了调整公司战略,并将战略传达给员工的一种手段。
  • 在 OPM 的作用下,源自不同专业的无数知识和经验在小小的一间会议室里汇集起来,帮助我们迅速地找出简单而又充满创造力的方案。

“第一目标”会议

如何维持或找回组织里上下一心的状态,这是扩大组织规模的重大挑战之一。当组织扩大并拆解成若干团队、部门之后,各个小群体会倾向于紧紧地盯住本群体的目标。这么做当然是对的!然而,我们又深知,Jimdo 要成为世界上最好的建站服务,只有让所有的团队都朝着同一个方向使劲。即便我们清楚,让公司上下始终像一支大团队那么齐心并不现实,我们仍然希望经常能够校正各支团队的方向,一起努力去取得成就。

我们用来统一目标方向的沟通形式叫做“第一目标(Goal #1)”。这项实践的思路主要得力于 Stephen Bungay 的作品 4。思路很简单,创始人们必须回答 Bungay 所说的“Spice Girls 问题”,也就是她们的著名歌词“Tell me what you want. What you really, really want!”——当前对于整个公司来说,哪一样是最重要的?

最重要的目标只能有一个,其他一切(尤其是团队的小目标)都是次要的。至今为止,我们的“第一目标”都由一支团队来担纲核心,全公司都明白该团队不可以受到阻碍。“第一目标”团队需要的基础设施、翻译、技术支持都会立即得到满足。如果任何团队需要按照优先次序来为其他团队提供服务,“第一目标”团队会自动排在队列的第一位。

Jimdo 的首个“第一目标”是发布我们的 iOS 应用。这个项目听起来并没有多么特别,但对于 Jimdo 来说是一次业务上的大转变,也是一大挑战。这个项目意味着 Jimdo 从纯粹基于浏览器的 Web 服务,变成一家跨平台的公司。该项目的进程几乎牵涉了公司的每一个部门,包括产品开发团队、基础设施团队、媒体团队、各国的本地化管理团队、网络推广团队,以及各种支持部门全部需要高效地参与协作。

设置“第一目标”的概念给了全公司一个明晰的目标,让每一个人都借着它来找准方向。当然很多时候各团队会为了给“第一目标”让路而拖延了自身的目标,难免产生挫折感。不过我们认为这样的代价还是值得的。

实现“第一目标”需要二十多支团队的通力合作。合作中主要的反馈循环就是由所有团队的代表出席的“第一目标会议”,每二到四周举行一次。“第一目标”团队汇报自身的进展,指出存在的问题并寻求帮助。其他团队倾听,提出反馈意见并提供帮助,让项目顺利进行下去。会议最长不超过 45 分钟,一般会在 15 到 20 分钟内结束。

尽管“第一目标”起初只是一次实验,后来的发展也并非完全如我们所愿,但我们在很短的时间里,就已经观察到这项实践的几个优点:

  • 专注:目标清晰是目标一致的前提,“第一目标”设立了毫不含糊的目标。
  • 快速决策:三位创始人设置了“第一目标”,因此他们有义务为之负责。当第一目标团队向他们求助的时候,创始人必须立即响应。举个例子,第一目标团队的进度多次因为等待基础设施团队的支持而停滞,创始人及时地插手,调配两名全职的系统管理员加入了第一目标团队。
  • 自我认识:有一位员工在参加完“第一目标”会议之后说:“啧啧,我都不知道原来我们 Jimdo 的实力有这么强!”在“第一目标”的直接影响下,公司里的自我认识径直提高,连带着集体自豪感也大大上升。

关于沟通还有最后要提的一点:工作空间的设计方式,将会大大地影响人与人之间能否沟通以及如何沟通。这就是 Jimdo 设立“混乱队长(Captain Chaos)”职位的主要原因。担任队长职位的是一名专业的 architect——这可是正牌的建筑师,不是什么软件架构师哦。她的任务是给所有的 Jimdo 团队配备最好的工作环境。她花费了很多心思和精力来创造不期而遇的机会,让素不相识的同事能够碰面交谈。有时候为了达到目的,甚至不惜拆掉一整面墙。穿梭在 Jimdo 的办公区里,不仅随处可见舒适的沙发休息区,还有专门的水族箱房间和打盹房间……这个话题够我们说上一整天。

文化

我们应付公司规模增长的方法其实充满了弹性。我们的工作流程经常在变。我们所用的工具,如“开放的优先级评议会”和“第一目标会议”也需要时时调整,到了必要的时候,取消它们或者用别的工具取代它们,都是可能的。我们随时准备着调整团队里当前设置的各种角色,有需要的话,我们也不惜改造队伍的组织架构。

这样的策略实施起来好像会很不安稳,甚至一团乱,但其实不然。我们的核心信念“每个人都可以成就卓越”并不会轻易动摇。归根结底,当我们航行在持续改变的险恶水面上,是公司的文化在一片漆黑中像北极星一般安定地指示着方向。

Jimdo 从来都以我们的文化而自豪。创始人们内心很清楚,他们绝不愿意拿自豪的文化来换取公司的发达。他们更愿意每天愉快地来到公司,让工作的愉悦推动自己去创造卓越的产品。他们珍惜这一切,并且希望新来的员工也能感受到同样的愉悦。

那么,创始人们必须回答这个问题:在公司规模持续快速扩张的情况下,怎样保护公司文化?他们认为寻找答案的第一步,应该先找出“Jimdo 文化”的真正含义,对 Jimdo 的核心价值观建立一致的见解。这件事情不是一下子就能做好的,他们很快认识到事情的难度,于是召集了 10 名团队成员到丹麦共度一周时间,一起分辨 Jimdo 的每一条核心价值观及其对工作氛围的影响。

在此必须提醒本文的读者,文化是一种难以捉摸的东西。我见识过一些公司企图制定和控制本公司文化的失败尝试。在我看来,凭空制定自己向往的公司文化,然后指望据此建立一家公司,这绝无成功可能。在现实中,公司文化的来源正好相反。它已经蕴藏在公司的运转方式里面,重要的是从中鉴别出有效的成分,确认创始人和每位员工认为重要的方面,并找出需要加强或改变的地方。一旦确定了公司的核心价值观,写成书面的记录可以坚定公司的支持立场。接下来就要采取行动来滋养、强化和扶植我们树立起来的公司文化——首先从创始人自身开始,以身作则来影响其他人。

作为在丹麦一周的成果,文化小团队找出来的代表 Jimdo 文化的价值观,构成了后来《Jimdo 文化手册》的基础。手册中记载的大原则里面,有这么几条:

  • 承认任何人都不是超人,因此是会犯错的
  • 应该让每个人都能够从工作中获得乐趣
  • 每个人都应该努力发挥自己的最大能力
  • 有时候偷偷懒也是可以的
  • 不允许踩着别人往上爬的竞争心态

设立“正能量管家(Feel Good Manager)”职位是我们培育 Jimdo 文化的一个重要步骤。我们一开始就认为,虽然“正能量管家”具体应该做哪些事情还需要摸索,但毫无疑问地每一位团队成员都会因为这个职位而深深受益。现在回顾起来,实验结果比当初的设想还要成功。Jimdo 有很多东西在持续地演变着,“正能量管家”这个角色也一样。就目前而言,“正能量管家”需要照料下面这些事情:

  • 帮助新入职的员工安顿下来,适应新的岗位、新的城市乃至新的国家
  • 确保员工们理解 Jimdo 的运作方式,准备好让员工们愉快、高效地工作所需的一切
  • 组织日常的反馈讨论和员工培训
  • 帮助每个人保持工作与生活的平衡,通过组织体育及社交活动来创造一个充满乐趣的工作环境
  • 随时有意识地了解并帮助解决一切人员问题和人员需要

所以,只知道整天讲笑话和给大家发小点心,是做不好“正能量管家”这份工作的。我们的管家照看着公司的文化,但从不粗暴干涉。她细心呵护培养 Jimdo 文化,但不会指手画脚地规定别人该怎么做。

(点击图片可放大观看)

Jimdo 每年都举行大规模的文化调查。所有的员工都有机会评估和议论核心价值观的落实情况。图中是一条结构及流程相关议题的调查结果。

文化的重要性说起来好像是个很玄的话题,但其实与我们的日常工作息息相关。每当遭遇困境,面对重大变化,或者招聘新员工的时候,我们总是可以停下来,问一问核心价值观可以怎样帮忙解决当前的状况。这个办法总能取得很好的结果,至今帮我们排解了诸多难题和冲突。我们真诚相信健康的公司文化是无价之宝,并且会大胆地投入在这上面。归根结底,管理理论家 Peter Drucker 说得一点都没错,他说,“在文化面前,公司战略什么的根本不是对手!”

结论

规模增长是所有大、中型公司都必须面对的重大挑战。Jimdo 选择了大大异于传统的处理方式。我们没有预设的规模增长计划,而且尽力避免大部分“常规管理套路”,如中间管理层、预算额度、详细规划等等。文化、沟通和持续改善这三大要素支撑起了我们的规模增长之道,一直帮助我们找到最适合的解决办法,推动着 Jimdo 不断进步。

参考书籍

  1. Kanban: Successful Evolutionary Change for Your Technology Business. By David J. Anderson (2010).(中文版《看板方法:科技企业渐进变革成功之道》,译者章显洲、路宁,2014 年出版。)
  2. Project Retrospectives: A Handbook for Team Reviews. By Norman L. Kerth (2001)
  3. The Democratic Corporation: A Radical Prescription for Recreating Corporate America and Rediscovering Success. By Russell L. Ackoff (1994), page 23.
  4. The Art of Action: Leadership that Closes the Gaps between Plans, Actions and Results. By Stephen Bungay (2010).

继续在 InfoQ 上学习“看板”

Jimdo 简介

Jimdo 是一套直观的 CMS 系统,人人都可以方便地用它创建自己的网站,而不需要任何专业知识。Jimdo 始创于 2007 年,现在已有 180 名充满热情的员工分布在全球的四处办公地点:汉堡(所有产品开发工作都在此完成)、旧金山、东京和上海。您可以到 www.jimdo.com 创造自己的网站。进一步了解 Jimdo 请访问三位创始人Matthias、Fridtjof 和Christian 的博客,以及阅读我们的迷你电子书《 Doing things differently! 》。

作者简介

Dr. Arne Roock 在德国 Jimdo 公司工作,这家公司的提供非常简单易用的全套建站方案。Arne 有着各种环境下,包括初创公司、中型公司和国际性大公司在内的深厚的精益及看板实施经验。他对“系统思维(Systems Thinking)”十分着迷,喜欢拿 Ackoff、Drucker、Deming 等前辈的想法来做实验。Arne 是德国第一个“Limited WIP Society”社群组织的建立者,也是“ Lean Kanban Central Europe ”会议的理事和组织者。Arne 曾于 2012 年获得“Brickell Key Award”奖项,以奖励他在精益和看板社群的活跃表现。读者可通过 Arne 的 Twitter 博客邮件与他联系。

查看原文链接: Culture is the True North - Scaling at Jimdo


感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-07-28 22:121597
用户头像

发布了 225 篇内容, 共 60.5 次阅读, 收获喜欢 49 次。

关注

评论

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

为什么学Go(一)

soolaugust

Go 语言

[Go 并发编程实战课]02.Mutex 源代码

Quincy

Go 语言

月薪60k的Java开发在阿里是什么级别?对技术能力有哪些要求?

Java架构之路

Java 阿里巴巴 程序员 面试 编程语言

英特尔聚焦全栈量子研究:发布多项重磅量子计算研究成果

E科讯

spring-boot-route(十五)整合RocketMQ

Java旅途

Java RocketMQ Spring Boot

技术解析 | 云游戏在未来如何实现?

腾讯云音视频

开发 游戏 视频

[Go并发编程实战课]01.Mutex学习笔记

Quincy

Go 语言

只要十步,你就可以应用表达式树来优化动态调用

newbe36524

C# netcore ASP.NET Core

视频会议的应用

anyRTC开发者

ios 音视频 WebRTC 直播 安卓

vidyo在数字化办公中提供了什么便利?

dwqcmo

音视频 集成架构 解决方案 智能硬件

4年Java经验,备战两月成功拿到美团、京东、字节offer

Java架构之路

Java 程序员 面试 编程语言

架构师训练营第四周作业

四夕晖

手把手带你玩转 openEuler | 如何安装 openEuler

openEuler

Linux 开源 操作系统 openEuler

LAXCUS大数据集群操作系统:一个分布式分时共享E级系统软件(一)

陈泽云

人工智能 云计算 大数据 基础设施 国产操作系统

生态共赢-anyRTC创业扶持计划

anyRTC开发者

ios 音视频 WebRTC RTC 安卓

TNFE-Weekly[第七十五周已更新]

莹姐🙈

小程序 大前端 周报

详细分析定制企业应用的价格

Philips

敏捷开发 快速开发

2020年第三季度《全国移动App 风险监测评估报告》

InfoQ_11eaedef67e9

App 移动安全 个人隐私安全

java安全编码指南之:锁的双重检测

程序那些事

java安全编码 java安全编码指南 java代码规范 java代码安全

LeetCode题解:145. 二叉树的后序遍历,栈,JavaScript,详细注释

Lee Chen

大前端 LeetCode

Java零基础到进阶宝典!从小白到大神,金九银十面试这届斩获23K月薪

Java架构追梦

Java 学习 架构 面试 核心知识点

蚁架构师首推SpringBoot套餐(原理+实战+面试)

小Q

Java 学习 架构 微服务 SpringBoot 2

惊险的B站Java后端岗面试之旅,复盘面试经历及面试真题

Java架构之路

Java 程序员 面试 编程语言

实现一个简单的 MobX

局外人

大前端 js React

搞开发,写SQL就够了

棒锤🐮

sql mybatis springboot Web框架 Rocket API

手把手带你玩转 openEuler | 初识 openEuler

openEuler

Linux 开源 操作系统

【全球案例】ESL 游戏公司如何通过 Jira 定制化解决方案连接全球团队

Atlassian

项目管理 敏捷 Atlassian Jira

TensorFlow 篇 | TensorFlow Serving API

Alex

tensorflow keras model serving tensorflow serving api

1分钟将vscode撸成小霸王

gamedilong

vscode 大前端

WebSocket从入门到精通,半小时就够!

JackJiang

html5 网络编程 websocket 即时通讯

教育场景方案升级| 打通业务前后端,少量开发快速上线(一):互动小班

ZEGO即构

在线教育 低代码

文化才是校正方向的标杆 —— Jimdo团队应对规模增长的经验_研发效能_Arne Roock_InfoQ精选文章