亲历者说:敏捷?我被洗脑了吗?

几年之前我还是个野生程序员的时候,对“敏捷”这个词是有些抗拒的。那时候,要么是没有想法、懒得去理会,要么就是主观上拒绝:

肯定又是些无所事事的人弄出来的无聊概念,帮他们自己刷存在感的东西!

敏捷,就是那些咨询公司弄出来给别人洗脑的嘛,那些理念太空,根本无法落地!

那些一大堆概念都是些什么鬼?条条框框太多了,运作起来太麻烦了!

不用敏捷,我们现在不也挺好的吗?敏捷跟我有什么关系?

但后来我却选择加入了 ThoughtWorks,这个传说中的敏捷大本营,一方面因为很多出名的书都是 ThoughtWorks 的人出的,另一方面也想亲入虎穴一探究竟。而如今,历经敏捷项目的洗礼,我已经成为专职的一线咨询师,为众多大型企业提供敏捷转型过程中的技术指导。

他们

在一些朋友看来,我自从换了工作,就开始在群里转发一些敏捷相关的文章,发表一些感言。在转发这些内容的时候,我经常用到的叙事口吻是“他们”。

他们的代码真的写了好多测试。

有时候要开一整天的会,我真不知道他们是怎么撑下来的!

感觉跟着他们一起做测试驱动开发好像没那么难。

这段时间里,我让自己成为一个“警惕的观察者”。不管是主观上的警觉,还是故意在外人面前将自己打造成这样的一个形象。深怕在我还没有觉察到的时候就已经被敏捷洗脑了;同时也希望在曾经的好友面前以尽量理性、中立和客观(理中客)的形象示人:不过,这不妨碍在他们看来,我已经被洗脑了。

后来我了解到,这如同学习新知识过程“守破离”中“守”的阶段。“守”的过程既是获取新认知的过程,也是与过去的认知做比较和更新的过程。观察现象——对比质疑——私下学习——拨开疑云,大体就是这样的不段重复,在不断了解新实践的过程中,也同步去认识它、理解它。

渐渐地,一系列疑问得以解答,使得最终我接纳了敏捷开发思想,并认为它是适用于现代开发团队中的工作方法。

疑问

在过去我呆过的团队中,一直有两个无法解答的问题。那时作为技术经理,我经常被别人问到的问题,也是我自己无法用经验回答的问题。

  • 做完这个功能,你估计需要多少时间?
  • 为什么大家在办公室显得很安静、气氛有点压抑?

在成功学的洗脑课程中,有一句被强调最多的话:“失败一定有原因,而成功一定有方法!”那么,我们过去回答不了的上面这些问题,以及由它们导致的管理上的难题,其根本原因又是什么呢?获得管理上成功的方法又是什么呢?我带着这两个问题离开了之前深度参与的创业项目。与朋友分享了要探索新征程的想法之后,他真诚地邀请我加入他的创意,并希望由我来带领团队一起续写新的故事。我猛然间发现,其实虽然之前在团队里担任所谓技术经理的职位,但我真正给团队带来的帮助似乎更多的只是一个有经验的工程师给新手的指导。那时候,第三个疑问产生了:

  • 如何去做好一个团队带头人?应该安排团队成员每天做什么?

这些疑问不得到解答,我就如同掉下井底的青蛙,虽然能听见外面世界的声音,却只能看到井口大小的世界。

答疑

加入新团队后不久,这些疑问就完全得到了解答。第一个要实现的需求就是一个“明星”功能,集成第三方系统的调查问卷。团队很快组织了需求计划会议,并细致地过了一遍第一期要完成的目标,实现这个目标要包含的业务范围,而具体又包含哪些步骤(用户故事)。

  • 目标:发出问卷链接,并将数据收回来。
  • 范围:选取模板、发送链接、收回数据、发送提醒邮件
  • 步骤:
    1.  管理员在外部系统中创建好模板(不需要开发)
    
    1. 用户可在 XX 页面中使用选项来选择问卷模板(系统自动将外部系统中的模板名字同步到本地系统)
    2. 用户可在 YY 页面中使用链接发送调查表单,客户收到包含链接的邮件
    3. 系统自动将外部系统中收到的数据同步到本地系统中以供使用
    4. 如果没收到提交数据,系统自动在7天后自动发出提醒邮件,客户再收到一封包含链接的邮件

接着开发人员和测试人员对还不够详尽的细节提出问题,讨论获得一致,一起对各个步骤大致估计所需时间。每个用户故事并不确定由谁来做,而是大家一起就其中的细节进行讨论,并就所需时间形成一致:有的人说需要 3 天,有的人觉得 2 天就够了。他们会叙述自己的想法,并最终达成共识。

这项活动,以及之后的迭代过程中,基于这个会议的开发过程解答了我第一个疑问。

他们有一个角色叫 BA,会写一个个的用户故事来描述需求,一两天就可以完成一个故事。明确的前提条件和验收标准(从哪里开始做,做到哪里为止),让开发工作变得有节奏感,需求不清楚的时候随时就这个需求的范围进行讨论。

相比于拿别的产品做个演示,甩一句“就照这个做”,然后就天天催进度、做出来之后又说不对劲的产品经理,有一个专门负责业务、随时可以叫过来讨论的 BA 让开发人员感到倍感轻松。

江湖上传言说敏捷不需要文档,原来是谬误。敏捷并没有说不需要文档,只是说认为团队成员之间的沟通协作比详尽的文档更重要。所以,用户故事仍然是会包含必要的描述内容的。要写清楚为什么要做这项功能,以及验收标准等。

团队一起估计时间的过程,不光可以消除特定人估计时的无助感,更重要的是它让所有人都了解用户故事的细节,在后续开发中谁都可以参与开发。

相对较小的用户故事,估计起来要比一整个功能(比如对整个调查问卷功能进行估计)估计起来靠谱得多。即使有特定的用户故事估计不准确,其影响范围也是可控的。

把所有故事的估计时间相加,即为整个功能所需要花费的时间。

估计只是帮助做计划的一种方法,在后续开发过程中,如果发现比当初估计的要复杂,或者简单,需要与 BA、PM 等角色一起更新这个估计值,从而帮助团队及时完善一开始制定的迭代计划(如果必要,可以加入一些,或者减去一些,或者修改一些)。

这样,我发现开发团队的时间原来是需要管理的,而管理时间这件事其实也需要花些心思才能做好。这时候,如果你问我某项功能需要多久做好?我会告诉你,让我来拆分一下功能,粗略估计就成为了可能。

而后面的其他疑问也很快得到了解答。关于团队气氛,如果一个团队里每个成员都在闷头做自己的工作,独自面对自己的交付压力和技术挑战,成员之间互相帮不上忙,他们的气氛一定不会太好。而如果所有人通力配合工作在相同的功能上,一起理解消化业务,一起解决技术问题,共同做技术决策,并分担解决缺陷(BUG)的责任和压力,那么团队的气氛怎么会不好呢?

最后一个问题,关于团队。

团队里大家的角色是如何分配的,规模又应该多大?团队之间应该如何配合?这就不难回答了。典型的业务功能团队,以及后来出现的微服务团队,都很好的诠释了团队结构和规模问题。有一个论述产品设计和组织结构关系的康威定律,值得我们深入思考。团队带头人?我突然反应过来,一定要有这个角色么?如果大家都能很好地运作了,那其实这个所谓带头人的作用是很淡化的,这也就是所谓的自组织团队了。如果一定要一个带头人,那他的职责一定是确保这样一种自组织的机制在团队中持续地运作下去。

所以,我被洗脑了吗?

也许你可以这样认为。

作者我现在是接受了敏捷思想的,其中还有一些工具和方法,我还在持续学习过程中。不过,“洗脑”这个词本身其实具有一定的预设立场,它是那些质疑者的说法。

那么,重新回到问题本身。敏捷是什么呢?它会将人们洗脑吗?

敏捷不是什么宗教,它只是一种生产软件的思路,一种倡议。它倡议,通过加强团队成员间的交流协作,尽快交付高质量、有价值的软件,让团队以良好的响应性来拥抱软件的变化。为了符合这种思路,它一般又会有一些典型的实践方式。我们可以说哪些实践是由敏捷方法所推荐的,因此是“敏捷的”;而哪些实践是不推荐的,因此是“不够敏捷的”。但不会说哪种是好的,哪种是不好的。

比如,敏捷的:

  • 自主提交代码,尽早集成
  • 自动化一切,包括环境初始化
  • 代码由团队共享,随时重构和优化

不敏捷的:

  • 逐次代码提交都需要他人审查并批准的管控
  • 手动部署生产环境
  • 不让他人修改自己编写的代码

但这些“不敏捷”的条目,基于团队具体情况,可能实际操作起来更可行,就可以根据目前的阶段去施行,并向着更敏捷的方向去持续改进。类似地还有,敏捷不会说团队一定要开站会,站会一定要在早上开等等……相反,如果要求团队一定要做某件事,其实它与敏捷思想是背道而弛的。我们应该遵循敏捷理念去对实践进行改良,以适应团队实际情况。

事实上,“敏捷”一词来源于英语 Agile,这一英文词汇也类似于中文中的形容词“敏捷”一词,其适应性相当广泛。人们往往用它来形容业务的灵活性,思路的开放性等。因此对于敏捷来说,并不存在什么洗脑不洗脑的说法。它只是一种风格,一种态度。只要你运用这种思路和风格去让团队协作越来越好,开发出来的软件的质量越来越好,那就是敏捷的。敏捷中典型的具体实践方法有 Scrum)、XP 和 Lean 等。此外,近年被广为谈论的 DevOps,也已经成为了敏捷软件方法的典型实践。


更多精彩洞见,请关注微信公众号:思特沃克

Share

从增强现实到增强人类

《增强人类》美国增强现实专家海伦·帕帕扬尼斯(Helen Papagiannis)的新著作,系统地描述了增强现实及其各种模式的含义及应用分类的知识体系。海伦向我们展示了增强现实赋能人类的能力,我们需要扩展自身的思维和想象力,重新思考“增强”一词在未来对于人类的意义。ThoughtWorks肖然和王晓雷翻译了本书,此文是肖然为《增强人类》写的译序。

从增强现实到增强人类

翻译此书的过程中正好遇到父亲心脏出现问题,几经周折医生建议安装心脏起搏器。父亲心里很纠结,一台电子仪器植入体内或多或少让人感觉有些惶恐。于是利用此书安慰父亲到:你只是提前体验了未来,等翻译完毕一定让你看看更广阔的增强人类世界。

虽然只是一句安慰的话,但本书的确为我们展现了一个全新的世界,甚至定义了新一代结合智能技术的增强人类,这是在翻译之前始料未及的。翻译过程中不断查询作者引用的企业和产品,就像展开了一幅通向未来的画卷,经历了一次非常享受的想象力之旅。在另一位译者王晓雷的提议下,我们也在原书的基础上增加了很多的图像,试图传递我们在这个过程中得到的启发和脑洞。也许本书的再版就会脱离纸面,通过各种感官技术带给各位读者身临其境的感受。

本书的另外一个重要贡献如前言中指出,VR/AR技术本身已经日臻完善,但如何应用这些技术确是另外一个挑战。在这个科技时代我们经常会拿着各种新技术的“锤子”去找“钉子”,这种做法在科技时代之前带有很强的讽刺意味,经常会被导师用来教育那些知其然而不知其所以然的学生们。但随着第四次工业革命的到来,我们看到了类似AR这样的技术突破引领着人们对问题认知本身的改变。拿着锤子找钉子这样的做事方法被重新定义为用新技术去颠覆各行各业,这件事情在我们身边随时发生着,以至于谈起新技术每个人都会有自己的感慨。

对于VR/AR技术,很多人预测将随着5G网络时代的到来而爆发,这也是我们最初选择翻译本书的原动力。但怎么爆发以及在什么地方爆发确不可能有人给出准确的答案。就这个爆发的问题,本书作者给出了非常有意义的见解,书名也从增强“现实”变成了增强“人类”。这意味着我们的关注点应该从技术本身转移到我们人类自身,从我们自身的感受和体验出发去寻找增强的机会点。我们采用增强现实技术的目标也应该是为人类提供更好的生活和体验,从这点出发我们会发现一个很不一样的增强现实领域,超越了简单意义上的视屏叠加,而是能够调动我们人类听觉、味觉、触觉、甚至于情感的体验增强。

到这里,我们确实对作者关于增强体验设计是一门艺术的观点非常赞同。未来良好的增强人类应用很可能出自于艺术家们的手中,就像我们身边各类艺术作品一样,美化着我们的体验,成为我们生活的一部分。而艺术本身就是一种创作,最好的作品是出于生活却高于生活的,这也是我们在考虑现实增强技术应用时是所需要遵循的原则。从某种意义上讲,我们这样的技术人员应该尝试着向艺术家一样去贴近生活,让技术服务于我们的生活,并创造更好的生活。

最后,这也是一本充满正能量的科普读物,相信大家读完后会少一点对新技术的恐惧,多一分对未来生活的向往。技术本身没有正邪之分,作为创造者和应用者的我们决定了技术的走向。读完此书,我们更加坚定技术会增强我们人类的生活体验。而翻译结束时父亲也开始揶揄自己是增强人类了。

书籍内容概要

第1章:回顾从1997年开始的AR的经典定义,讲述了AR的今天和未来变化。

第2章:从艺术装置,到机器人和自动驾驶汽车,探讨计算机视觉如何为我们提供新的“眼睛”,增强人类视觉体验。

(ARKit的典型应用:无缝地在现实桌面上展示虚拟玩具车)

第3章:介绍触觉技术的研究和创新,以及使用触感进行沟通的新方法。

第4章:探讨了增强音频和“可听式”设备(佩戴在耳朵中的可穿戴技术),如何改变倾听周边环境声音的方式,甚至改变环境如何“听到”你的声音。

(Detour带你游览著名的卡斯特罗街道)

第5章:探讨数字嗅觉和数字味觉这个持续成长的研究、原型和产品设计领域,及如何增强我们共享和接收信息的方式,增强娱乐体验。

第6章:探讨如何通过AR来创造引人入胜的叙事体验。

第7章:探讨虚拟化身、智能代理、物品和材料如何成为活跃的情境变化因素:针对情境来学习、成长、预测和进化。

第8章:探讨了从电子纺织品到嵌入身体的技术,以及大脑控制接口等各种增强人类身体机能的方式。

(丝芙兰的虚拟艺术应用Modiface,查看自己上妆后的“妆容”)

第9章:归纳了10个AR体验分类,展望AR对人类更美好未来的影响。 谁应该读这本书?

“我特别欣赏海伦对艺术家(或被她称为‘惊喜创作者’)这一角色的洞察力和敏感度,这将会是下一波创新的火花。据我所知,迄今为止没有一个组织或社区曾经踏足过这片天地。增强现实不仅是工程师和计算机科学家的领域,也同样是作家和艺术家的地盘。体验才是我们能够记住,并终将改变我们的。希望技术(或者说类似于我的贡献)能够变得‘不可见’,为人类的创作腾出更大的空间。” AR/VR的祖父,汤姆弗内斯在为本书写的序中这样说。

无论是设计师、企业家、教育家、艺术家、商界领袖,还是开发者、工程师、技术爱好者,只要对AR充满好奇和兴奋,相信本书中的大量案例,会让你大开脑洞。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

WebAssembly:系统编程语言的逆袭

引子

Any application that can be written in JavaScript, will eventually be written in JavaScript. ——Atwood‘s Law

有人用 JavaScript 做语法词法解析,有人写了 x86 模拟器, 还有人用 JavaScript 写了可自举的 JavaScript 引擎。JavaScript 早已经在”重新发明一切”的路上一骑绝尘了,JavaScript 的流行也使它始终位于各大语言排行榜上的前列,这无疑是属于 JavaScript 程序yuan们最好的时代。

这并非是因为 JavaScript 是门优秀的语言 (恰恰相反),而是因为当今的世界是 Web 的世界,Web 的载体浏览器只会说 JavaScript。这难免使人眼红,王侯将相,世人无数次想要取代 JavaScript 的地位,目前为止的历史我们都看到了,无一不铩羽而归。求上不得,得其中,最新成果是大家(伙儿)齐心协力把 JavaScript 变成了新一代的汇编语言。请移步这里看大家的最新成果。

WebAssembly

去年 11 月 13 日,Mozilla 在其官方博客上发表了一篇文章,WebAssembly support now shipping in all major browsers,指出当今世界四大主流浏览器 Firefox,Chrome,Safari,Edge(排名分先后),都已经支持了名为 WebAssembly 的新技术,并回顾了一路走来的艰难历程。最后指出这是新时代的开端,大家一起欢呼吧。那么,WebAssembly 到底是啥?让我们发出发聋振聩的三连问:

可以吃吗?

请移步 WebAssembly 官网。官网解释如下:

WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web.

关键词:

  1. 可移植: WebAssembly 是一种可移植的二进制格式,它不依赖于具体的浏览器平台。
  2. 高效:WebAssembly 被设计为针对 Size 和 Load Time 进行优化的格式,可以在各个硬件平台上以 native speed 运行。
  3. 安全:WebAssembly 是运行在沙盒内的,甚至可以和当前的 JavaScript 虚拟机共享一套环境,并且也遵守浏览器各种跨域不跨域的规章制度。
  4. 开放:WebAssembly 是开放标准,不受某一家厂商控制(Oracle你听到了吗)。并且被设计为可以和 JavaScript API 和 Context 交互。

简而言之,WebAssembly 可以被看做是通过浏览器运行的某种高效的开放的二进制格式,并且可以和 JavaScript 环境互通。

WebAssembly 的目的是取代 JavaScript 吗?FAQ 这样回答:不,WebAssembly 是被设计来补充而不是替代 JavaScript。随着时间推移,越来越多的语言可以被编译为 WebAssembly,但是 JavaScript 还是作为 Web 唯一的动态语言而存在。

这样看来老二的位置摆得很正嘛。对于 WebAssembly, 笔者最看重的一点是作为开放标准的同时有粗大腿的支持 (M$ Google Apple Mozilla),这才是它有可能活下来的原因。问题是可以吃吗,答案当然是可以吃(佛系码农也可以不吃)。

怎么吃?

WebAssembly 同时存在一个二进制格式和一个文本的描述格式,这很像是机器语言和汇编语言的关系。这里我们用一个例子解释一下。

事实上,WebAssembly 可以被看作是运行在一个 structured stack virtual machine 里,懂行的朋友一眼就可以看出这和 Java bytecode 非常的像。所以大家不要以为 WebAssembly 是在重新发明 Flash 了,这货明明是在重新发明 Java Applet 啊,好吧 Silverlight 也有点像…。顺带一提,Android 的 Dalvik 为了效率,使用的是 register-based virtual machine。对 WebAssembly spec 感兴趣的朋友可以移步这里

作为 WebAssembly 的 MVP,C/C++ 及其类库的支持是首当其冲的。因为基于 LLVM 的平台,所以理论 LLVM 支持的语言都可以编译为 WebAssembly,C/C++,rust,甚至 .net 和 Java 也可以编译到 WebAssembly,只不过托管语言都需要附带一个巨大的runtime。

下面我们以 C/C++ 为例,我们写一个函数给 JavaScript 使用。

步骤:

  • 安装 WebAssembly 构建工具链 emscripten,针对 macOS,请参考这里
  • 安装后,执行 emcc --version 判断是否成功
  • 创建 C++ source:cat random.cc
#include <random>
#include <cmath>

extern "C" {

long normal_rand() {
    static std::random_device rd{};
    static std::mt19937 gen{rd()};

    return std::lround(std::normal_distribution<>(0, 100)(gen));
}

}

这里用 C++ 产生一个正态分布,期望为0,方差100的随机数,然后导出为一个 C 函数 normal_rand

执行 emcc --bind -std=c++14 --emrun -s WASM=1 -s EXPORTED_FUNCTIONS='["_normal_rand"]' -O3 -o random.html random.cc 顺利的话会在当前目录生成如下文件

$ ls -l
total 496
-rw-r--r--  1 haoli  staff     810 Dec 24 21:44 random.cc
-rw-r--r--  1 haoli  staff  102728 Dec 24 22:17 random.html
-rw-r--r--  1 haoli  staff  120624 Dec 24 22:17 random.js
-rw-r--r--  1 haoli  staff   20130 Dec 24 22:17 random.wasm

random.wasm 就是我们的 WebAssembly,random.jsrandom.html 是模板代码,帮助我们加载 WebAssembly。

执行 emrun --no_browser --port 8821 random.html 启动一个 WebServer

用支持 WebAssembly 的浏览器访问http://localhost:8821/random.html,然后在 console 里面执行 Module._normal_rand() 即可看到结果

怎么做好吃?

古往今来,在浏览器里面尝试改善 JavaScript 性能和增强功能的尝试大约都失败了吧,前有 ActiveX,Java Applet,Flash,后有 Silverlight,Flex,NaCl。WebAssembly 应该是各个浏览器大佬的最新尝试。不过这次大家都学乖了,没人指(xi)望一个私有标准会成功,于是联合起来开发一个开放的标准。

至少目前看来,结果还是很让人欣喜的。因为开放标准的缘故,除了上面的 emscripten,还有大量的工具开始支持 WebAssembly,甚至 clang 可以直接指定 target 为 WebAssembly。加上浏览器把诸如 DOM API 以及 WebGL API 都暴露给了 WebAssembly,应用场景相当可观。首当其冲的就是游戏厂商,EpicUnity 都是 WebAssembly 的早期尝试者,他们已经把自己的游戏引擎移植到 Web 平台而不用重写代码。不仅如此, WebAssembly 还支持 non-web 的场景,比如 NodeJs 也开始支持 WebAssembly。WebAssembly 官网有个 use case 清单,列举了可能的应用场景。图形图像的处理,计算机辅助设计,AR/VR,VPN,加解密等等。到那时,前端可以玩出的花样,想象空间实在太大。

有点过于美好了哈,我们还是就此打住,拭目以待吧。

Reference

这里列举一些 WebAssembly 相关的资源,各位随喜:

  1. Funky Karts, 移植到 WebAssembly 的网页游戏,作者在网站记录了学习 WebAssembly 到移植成功的全过程。
  2. WasmExplorer,在线的 C/C++ to WebAssembly 编辑器,同时也可以查看 Assembly 内容。
  3. WasmFiddle,另一个在线编辑 WebAssembly 的工具
  4. WasmRocks WebAssembly 新闻站
  5. emscripten 官网

更多精彩洞见,请关注微信公众号:思特沃克

Share

把“墙”推倒 - 扁平组织中的自主和责任

《MD脑洞》系列之

此篇文章为《MD脑洞》系列第四篇。


最近一段时间内,我常常听到这样的对话……

销售:“研发总是不跟我们销售知会一下就擅自把东西发给客户,人家客户问起来,我们都不知道发生了什么,这弄得我们很被动。”

研发:“我们是专业人员,客户要的就是我们的能力,我们知道怎么弄,为什么一定要通过销售?”

销售:“销售在看一个客户的时候,跟谁说话,什么时候说,说话要到达什么目的,这都是有设计的,不是想到哪儿做到哪儿。研发人员擅自行动或是隐藏信息,更糟的是阳奉阴违,就会破坏了我们的设计。兄弟们总是在擦屁股。”

研发:“但如果客户关系是个黑盒,只是销售代表客户点菜,研发人员按单上菜,这怎么能行?我们又不是卖PC的。销售有销售的设计,我们也有我们的想法。”

由于经常处理这样的矛盾,我荣获了“专业捣糨糊”的称号。回想起来,类似的对话也曾发生在项目经理和团队之间、业务分析和开发之间、现场团队和离岸团队之间,差别只是没那么的剑拔弩张。这种种争执,暴露了一个让我们一直痛苦挣扎、却又有意无意回避的组织问题,就是在ThoughtWorks这样的扁平组织里,如果不希望一切边界和流程都由规章制度或是所谓的领导来决定来拍板,平等的个体之间该如何处理自主能动与行为责任之间的关系?

在讨论这个问题之前,我们首先要设定一个假设 – 我们所有ThoughtWorker是一个团队。在不同的场景下,由于要完成各种各样的任务,我们又会或长期或短期地组成相对更小的团队。在1993年3月Harvard Business Review有一篇文章“The Discipline of Teams”对团队作了一个颇为冗长的定义 –

“a team is a small number of people with complementary skills who committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable.”

如果从这句话里摘出几个关键词,那就是:

  • 共同使命( common purpose)
  • 互补的技能(complementary skills)
  • 绩效目标(performance goals)
  • 相互承担责任(hold themselves mutually accountable)

共同使命的重要性自不必冗述,我们来看看个人和共同使命之间的关系。当我们选择加入一个团队,必然始于个人的某些诉求。这个诉求可以是能力的成长、阅历视野的拓展,或是做出一番什么成就,以至于改变行业和社会,也可以是个人财富的增长,生活水平的提高,又或仅仅是自由宽松的工作环境。

判断成员和团队是否匹配的一个依据,是看在为共同使命所设计的框架下能否达成其个人诉求。这也就是我们在ThoughtWorks常听到的一个词 – Alignment。如果出现了不匹配的状况,并不一定是诉求和使命孰对孰错,可能只是不匹配了而已,尝试调节或是再做选择就是。

使命一般很难依靠单独一人或一类人达成,需要依据任务类型和所需经验技能的差异,定义一些不同的角色,就是所谓的专业化分工。在ThoughtWorks历史上,专业化分工也曾算是个敏感词。有人曰“能者无所不能”,又有人曰“术业有专攻”。一种声音是要废了xx角色,所有人都要全功能,又有一种声音是要发展领域专家,才能领先行业。吧台前、饭桌上、邮件里,都曾上演种种狗血的辩论剧情。但是不管对专业分工的观点如何,ThoughtWorks内部事实上已经出现了各种角色,有的是参考行业内其它公司的定义,也有不少是ThoughtWorks在摸索中衍生创建的。我们共同使命的实现依赖于这些角色的协作。

绩效目标则既是团队所有人对外的共同承诺,也是团队对自己的期望。检验绩效目标的达成状况,不仅能够验证我们是否走在正确的路上,更成为持续改进的基础。一旦目标设定,团队成员个体之间就要相互承担责任,否则我们常提倡的“集体责任制(collective ownership)”就会变成“谁也不负责任”(no ownership)。

以往做国内市场规划的时候,一般是我跟销售总监在小黑屋里一通密谋,拍脑袋得出不同类型服务和总体的营收目标。对照前面团队的定义,我意识到这方式存在着明显的问题:这是大家认可的绩效目标吗?参与的各个角色认为自己属于同一个团队吗?大家有意愿对这样的目标相互承担责任吗?琢磨了半天,我的答案是:不一定,不一(guan)定(xin),不一(ke)定(neng)。

既然发现了问题,就得想办法解决。我要设计一个机制,让参与实现目标的不同角色形成共识,在执行中相互负责。这时想到几年前看到的一篇文章“First, Let’s Fire All the Managers”,说的是一家番茄制品供应商的案例,文中提到个人和团队在没有经理角色的组织里如何领取并履行职责。他们使用的一个工具叫做Colleague Letter of Understanding (CLOU),我称其为同事谅解备忘录。方法就是让有关联的团队和个人之间相互协商,识别出未来一段时间里各自的活动领域,以及相应的成功衡量方式,然后写进这个谅解备忘录里。

对,就是这样。我也要搞一个这样的东西,先在销售和研发人员之间试试。不过如果等到年底再做,要是各方谈崩了,那明年中国区计划不就泡汤了。所以我打算提前一个季度开始做,万一不行,年底还有机会换个招儿卷土重来。

于是,趁着2014 China Away Day(一个让ThoughtWorker齐聚一堂的日子),我提前集结了销售团队、零售团队、XD团队的代表,加上交付业务的负责人。用了整整大半天的时间,把他们关在西安office的一个大会议室。我去开其它的会了,所以也不太清楚这过程中发生了什么,反正最后他们拿出的结果还算让人满意,从会议室出来的时候每个人看上去也算完整。大家对12个月的规划和达成条件形成了一个初步的共识,约定每个季度回顾和调整一次。

有了目标之后,我们这帮人应该怎样在执行当中体现共同使命和相互责任呢?过去的争议经常聚焦在两点:行为过界和未能充分履行自己责任。摘录一段在小范围讨(chao)论(jia)时我发的邮件,权作我对此的看法。这里只取了结论部分,去掉了血腥的上下文,有兴趣的可以套用各种身边角色冲突事件自行脑补。

“XX和YY不应该是一种甲方、乙方的关系,而应该是为共同目标负责的整体团队。一个团队的建立首先是accountability的划分。各个角色都有自己的专长,自然在这个团队中对各自行为产生的结果就有相应不同的期望,并为此承担责任。然后则是协作机制的建立。虽然我们每个人在自己负责领域都能够并且应该做出决策,但并不意味着决策过程是一个人在小黑屋里拍拍脑袋做出判断,然后对其他成员仅仅是通知、执行。除了紧急的行动(这也需要执行后的知会和收集反馈),主要决策应该在团队内部有个协商和听取意见的过程。”

自主行动的意愿很大程度上取决于当事人是否能影响事情的决策,在合作关系中,挫败感一个主要来源就是缺乏影响力。在信息链处于相对后端的角色常觉得自己处于劣势。我自己在做项目的时候,也曾因信息不对称难以影响onsite团队而苦恼,也曾抱怨销售安排接触客户高层时太过谨慎。

但后来发现,在ThoughtWorks只要愿意主动获取信息,一般没有遭到拒绝的可能,如果事先充分准备和交流,销售其实很愿意创造机会展现我们的优势。影响力是等不来的,是自己挣来的。跟影响力密切关联的有一个词叫“担当”。所谓担当就是关心、担心结果成败,并能为之费心费力。如果能做到比他人先想一步,多做一步,自然就会赢得主动,影响决策的过程。那么我们为什么不主动一点呢?

写在最后

人是复杂的生物,社会是复杂的系统,简单抽象出来的方案从来都不可能完美地解决复杂的系统问题。自主行动和主动承担责任在我们这样的组织中必然就不是黑与白的简单问题,探索中纷争和挫败感不可避免。负能量的抱怨和攻击只能在我们周围筑起一面面防卫的高墙,如果我们不想被高墙围绕,唯有大家都积极发起建设性的反馈和建议。


编者按:管理层如何从更高角度观察内部团队及个人间的交互,从而对照组织内部的机制运行状态,寻求更积极的改进,而不是片面的奖惩,是组织积极健康发展的必要条件。


更多精彩洞见,请关注微信公众号:思特沃克

Share

生机型文化之使命式指挥

摘要:

为了让精益敏捷转型顺利和持久,做出精益敏捷的“神”,必须努力建设生机型文化;而在生机型文化中,一个重要的实践是使命式指挥。如何践行使命式指挥呢?


从生机型文化谈起

越来越多的企业进行精益敏捷转型,但是有一个很普遍的问题:当外部顾问离场后,回退很严重,流于走形式。其中,一个很重要的原因在于精益敏捷文化。文化建设对精益敏捷转型的持久性和高效性非常重要,如同塑造一个人的“性格”,组织的“性格”决定了结果。

什么是文化?文化是为共同目标而工作的员工之间的共同的信仰、价值观以及假设。管理大师沙因用钻石模型描述了文化的三个层次:

  • 外在表现形态:“外部人看到的”组织结构和组织过程等;
  • 规范和价值观:“组织所说的”的理念等,包括战略、目标、质量意识、指导哲学等;
  • 基本隐性假设:“组织所深信和践行的”,包括潜意识的、暗默的一些信仰、知觉、思想、感觉等。

( 文化的三个层次,沙因,1984)

后面两层文化在精益敏捷中体现为生机型文化,是精益企业文化的重要部分,其主要特征是:

  • 成效导向:绩效评价以实际的用户和业务成效依据,而不是过程指标;过程度量则仅用来发现问题和推动改进;
  • 高度合作:个体之间、组织的各部分之间高度合作、相互支持、充分分享;
  • 鼓励连接:鼓励跨越职能、组织和层级的沟通连接,而不是设置阻碍;
  • 风险共担:风险与责任共担,而不是逃避责任或各扫门前雪;
  • 信息辐射:组织内信息顺畅流动,有效辐射,鼓励发现并上报错误与风险的行为,而非掩盖或阻挠;
  • 采纳新鲜事物:鼓励尝试新想法,并采取措施来限制潜在失败带来的损失,提供“安全”的试错环境;为组织带来新思想,新方法和新技术的传播者、先驱者及具有成长型思维模式、学习能力和领导力的人,会得到重视和培养;
  • 失败产生根因调查:当事情出现错误时,尝试去发现根因,采取措施优化系统,而不是寻找替罪羊或追究责任并惩罚。

(生机型文化的核心转变)

生机型文化主要实践,包括了相对“流行”的自组织团队、跨职能团队、持续改善、内在激励、适应性领导力等,还有如文化度量、Y理论、使命式指挥、信任但验证、非指责性事后调查、成长性思维性模式等。本篇文章将重点阐述生机型文化的一个实践:使命式指挥。

(生机型文化的主要实践)

什么是使命式指挥(Mission Command)?

我们先看一个来自麻省理工大学研究的使命式指挥的成功案例:

耐克旗下的两个工厂

A工厂:传统的控制型管理,员工制定产量、生产实践,统一安排工作,相对高度控制。

B工厂:员工自由选择搭档,制定团队生产产量,决定在出现问题时停掉哪条生产线,等等,相对自由。

结果:A工厂的生产效率为B工厂的一半,B工厂的制作成本比A工厂降低40%。因此,即使是在这样一个传统的服装制造业,对团队的组织方式赋予自由的时候,也是有可能让他们的效率比在高强度管理的情况下还要有更好的成就。

在这个案例中B工厂采用使命式指挥充分发挥团队潜力,从而得到更好生产成果。

使命式指挥替代命令和控制指挥,是高度信任的组织文化表现形式。

首先,企业或组织确定好使命并且说明使命的意图和原因,在大范围内形成一致目标;

然后,在一致目标使命下,赋予组织成员更多的自主权——也就是说在职权范围内,每人都有做决定和行动的自由,自行决定达成目标状态的细节;充分发挥个体的创造力,而不是试图控制。

用很形象的战场来比喻,战场上千变万化,很多情况下指挥官都必须靠自己的判断来决定军事行动,而不是完全听命于后方司令部的指挥。使命原则的关键在于建立一致性、实现自主性,必须坚定的把“人”放在核心位置。

为什么采用使命式指挥?

随着组织的快速发展,组织的规模不断变大,就形成了一个“复杂系统”。要想让整个组织快速动起来、提高效率,必须进行系统解耦,让组织中的每个单元独立高效运作,充分发挥组织中个体的能动性。高层管理机构的职责,应该聚焦于局部无法执行的任务,对局部职权进行辅助,实施使命式指挥。例如,年产值25亿美元的化工产品公司戈尔,成立65年来,从未有过亏损的时候,他们就是在没有管理层的情况下运作的。在戈尔公司:

  • 人们选择自己的工作;
  • 领导者就是吸引了跟随者的人;
  • 独立业务部门就是小型、自治且自给自足的;超过150人就拆分。

ThoughtWorks自身也是使命式指挥的践行者。对组织内各项工作,管理层发布使命——愿景、目标和价值观,具体达成目标的细节过程,由员工充分发挥创意完成。我们能展现出各种不同创新模式,得益于这种核心推动力。

如何采用使命式指挥?

在谈如何采用使命式指挥前,得先看看如何建立使命。

一. 如何建立使命?

1.逐层建立组织级战略

从建立使命的人来说,可以分为三层:高层管理、业务线投资组合管理人员、团队。

  • 首先高层管理设立组织级的愿景使命;
  • 业务线投资组合人员分解成业务目标使命;
  • 团队依据整体业务目标设定各自团队的具体目标。

比如,下面的精益价值树就是逐层目标分解。

(精益价值树)

也可以采用接球(Catch Ball)的方式,制定逐层组织级战略。

(采用接球的方式,制定逐层组织级战略)

2.不同类型的使命

通常,使命可以分成:业务使命、过程使命、技术使命、财务和预算使命。

  • 业务使命:上面的精益价值树是一个例子:根据精益企业中提到的业务地平线, 确定三条业务线的比例,然后对于H3类型的创新业务,高层管理需要确定创新的愿景、创新的过程;对于H2类型的拓展业务,需要确定年度的拓展使命和阶段性拓展使命,特别是商业模式;对于H1类型的稳定业务,除了驱动团队围绕以用户为中心的渐进性创新外,高层和业务线投资组合人员还需要确定未来生命周期的使命路线。
  • 技术使命:比如亚马逊的面向服务的架构,还有微服务、自动测试、移动优先、推进云战略等;CEO、CTO、CIO需要很关注这些技术使命。
  • 过程使命:比如:团队用精益敏捷方式开发产品,快速学习,快速反馈,创造对客户有价值的产品;具体可以再按精益敏捷成熟度分解成几个阶段性使命;过程使命需要与业务使命和技术使命紧密结合在一起。
  • 财物和预算使命:如按季度的滚动预算,要与业务和过程使命相互配合。

3.使命一旦确定,必须遵循

需要特别说明的是,使命一旦确定,必须遵循。在现实过程中,经常会出现不遵循使命的问题。碰到这种情况:

  • 首先分析不遵循的原因:可能是使命有问题,或者使命没问题但不想执行;
  • 如果使命有问题,需要立即修正;
  • 如果是执行的问题,需要严肃对待,否则企业和团队处于一切无所谓散沙的状态,一事无成。

典型的亚马逊的案例:

2001年,亚马逊遇到了一个难题:支撑他们网站运行的Obidos系统,是个巨大且铁板一块的“大泥球”,无法进行扩展,其制约因素是数据库。首席执行官Jeff Bezos将这个问题变成了机会。他希望亚马逊变成一个其他企业都可以利用的平台,最终目的是更好地满足客户的需求。因此,他给技术人员发了一封邮件,要求他们创建一种面向服务的架构。Steve Yegge对此总结如下:

  1. 所有团队以后都通过服务接口来暴露他们的数据和功能;
  2. 团队之间必须通过这些接口彼此通信;
  3. 不允许其他任何形式的进程间通信:不能直接链接,不能直接读其他团队的数据库,没有共享内存模式,不能有任何形式的后门;唯一允许的通信是通过网络调用服务接口;
  4. 采用什么技术都行:HTTP、Corba、PubSub、自定义协议,都无所谓;
  5. 所有服务接口,无一例外,都必须要一开始设计就考虑可外部化——也就是说,团队必须要有计划地做出设计,让接口能开放给外部的其他开发人员;不允许例外;
  6. 任何不这样做的人都将被开除。

Bezos雇佣了西点军校毕业的前陆军突击队员Rick Dalzell来强制实施这些规则。和这些规则一道,他还强制推行了另一个重要变革:每一个服务由一个跨职能的团队负责,团队要在服务的整个生命周期里负责其开发和运行。就像亚马逊的首席技术官Werner Vogels所说的,“谁开发,谁运维”。

这条规则和所有服务接口设计必须可外部化这一要求,一起产生了一些重要影响。正如Vogels指出的,这种团队组织方式“让开发人员接触到其开发软件的日常运作,也让他们每天接触到客户。这种客户反馈环对于提高服务质量非常关键”。

二. 如何使用使命式指挥?

1. 首先要建立跨职能的团队

首先,改变组织结构,建立去中心化的、跨职能的、目标高度一致的、松耦合的小团队。确保团队对他们正在工作的系统有清晰一致的理解,以更好地发挥主观能动性。团队一旦超过10人,群体的变动和协调就会变得难以管理,也变得难以达成决策共识,难以确保团队的每个人都对上下文理解一致。

(建立小团队)

比如,可以以API接口边界来划分团队边界。这种方式,我们可以将团队分布在全世界。只要每个服务都由一个同地点工作的、自主的跨职能的团队来开发和运维,团队之间就不再需要大量的沟通。

很有代表性的是,亚马逊的“两个披萨”组织结构。

随着组织的发展,最大的问题之一就是保持人与人之间及团队与团队之间有效的沟通。一旦将人员搬到另一个楼层、另一栋建筑或另一个时区,沟通有效性就会大大受限,要继续保持共识、信任和有效协作就很困难。为了控制这个问题,亚马逊规定所有团队必须能遵循“两个披萨”法则:团队应该小到两个披萨就够所有人吃——通常大概5到10人。

对团队大小的限制会产生四个重要影响:

  1. 确保团队对他们正在工作的系统有清晰一致的理解;
  2. 限制团队正在开发的产品或服务的增长速度——通过限制团队大小,我们限制系统所能演进的速度,这同样有助于保证团队对系统始终保持理解一致;
  3. 可能最重要的是,这让权力去中心化,带来了自主性,遵循了使命原则——每一个“两个披萨”团队(2PT)尽可能自主;团队领导者会和管理层一起决定团队所要负责的关键业务指标,称之为“健康函数”,进而成为团队进行实验的整体评价标准;
  4. 领导“两个披萨”团队可以让员工在一个失败不会产生灾难性后果的环境里获得一些领导力经验——这“有助于企业吸引和留住创业型人才”。

2. 建立团队的自主性策略

建立了跨职能的“两个披萨”小团队后,还需要建立团队的自主性策略:

  • 给予团队工具和授权,可将变更部署至生产环境,开展自运维:这看起来很明显,但很多传统组织会基于安全性为由,导致这一点在实际中很难执行,部署生产环境都要提申请走很多流程,生产环境的部署改革极其缓慢。在亚马逊、Netflix和Etsy这样的公司,变更部署下放到团队,特定的高风险变更,团队商讨措施。高层管理相信团队能够采取恰当的措施,并进行自动化测试。另外,我咨询过的一家公司,开始尝试授权团队做自运维,但也担心安全性问题,他们的措施是自运维的同时做好各种日志和流程的跟踪记录,出了问题可以立刻找到问题点,后续持续改进。这也是一种过度改进措施,先要勇敢地做起来迈出第一步;
  • 确保团队有权利选择自己的工具链:尽量让团队自主选择技术栈;在生产环境中,可以限制团队采用由内部IT部门或外部供应商提供的一致平台或基础设施服务,使团队能够向生产环境进行自主部署;
  • 确保团队不需要拨款审批就能进行试验:只要是在使命范围内的具体实验行动,应该有滚动预算的支持,不会因为资金预算问题阻碍验证新的想法;
  • 确保领导者专注于实现使命式指挥:领导者首先要敏锐地根据市场和用户变化,阶段式定义正确的使命,并有效的传达使命,同时协助建立跨职能小团队,采取各种形式提升人员的胜任力,营造充分发挥个人自主性的氛围,提高最小单元的有效性,并从这些组织单元中培养出新的领导者。

在使命式指挥中,团队有权利和责任对他们所处的特定场景下的成本和风险进行恰当的管理。而财务、项目管理办公室(PMO),治理、风险与合规管理(GRC)团队,以及其他集中式机构的角色,都要发生改变:他们指定目标成效,协助将当前状态透明化,并在需要时提供支持和工具,但不强制规定成本、流程和风险要如何管理。

3. 建立改善形

改善形是一种遵循使命原则,将实现那些成果的主人翁意识推向组织基层的一种方法。改善形为团队建立一致的目标, 并将其分解为一个个小的、渐进的成果(目标状态),能够逐步接近目标。改善形的关键特征是它的迭代性,以及能够驱动一种实验性方法来达到期望的目标状态 。改善形的迭代几乎过程产生效果是一组我们希望下个迭代能叨叨的可衡量的目标状态,它描述了我们要努力的方向,并且遵循使命原则。使命的具体目标跟踪管理也可以采用OKR体系。下面是一个团队利用改善形迭代式遵循使命达成目标的例子:

(利用改善形迭代式遵循使命达成目标)

最后要使使命式指挥真正起效,还需要“信任但验证”的机制保证,确保使命的达成。

著名的瑞典商业银行,给分行授予了高度的自主权,但是有一套非常完善的事后核算反馈成效体系,验证自主行动的效果,持续改进;给团队更多灵活支配使用预算的自主权,同时要定期监控预算使用的成效。

总结

为了让精益敏捷转型顺利和持久,做出精益敏捷的“神”,必须努力建设生机型文化。在生机型文化中,一个重要的实践是使命式指挥,在一致性使命的指导下,充分发挥每个小团队的自主战斗力,从而加快整个组织的响应能力,进而获得市场竞争力。


更多精彩洞见,请关注微信公众号:ThoughtWorks商业洞见

Share