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

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

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

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

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

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

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

他们

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

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

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

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

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

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

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

疑问

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

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

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

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

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

答疑

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以,我被洗脑了吗?

也许你可以这样认为。

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

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

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

比如,敏捷的:

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

不敏捷的:

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

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

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


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

Share

找到新的自己

题记

我自认为职业阅历已经足够丰富,在加入这家奇葩公司之前,从业十五年,在全球最大的软件服务公司锻炼了技术能力,在全球最大的咨询服务公司做到了咨询总监,横跨技术咨询、业务咨询、管理咨询及实施服务。

涉足过多个行业领域,服务过全球最大的云计算和大数据厂商,最后还冲动的作为技术合伙人将一个小科技服务公司做到估值两个亿。

从前的职业经历都是在不断的奔跑,奔跑的目标也很清晰,就是拿单子,做项目,每天被数字追着。很少有时间和心境去思考,直到遇见了这个奇葩的公司。让我感觉触碰到了人生最本质的价值,找到浮躁时代的那一抹平静,找到那种内心的自由和释放。

一、初见

和ThoughtWorks的相遇是一个机缘巧合,当时的我正处于事业的低谷,事业做的很顺利,项目越做越多,团队越来越大,但是由于人性的变化,创业却失败了。我对人与人间的合作信任产生了巨大的质疑。

当猎头找到我的时候,我是第一次听说这个公司的名字,手上已经有两个很不错的选择。当时猎头说的一句话让我对这个公司起了一定的兴趣,“这是一家很有情怀的公司,和以前你待过的公司都完全不一样”。基于多年做管理咨询的习惯,我对这个公司进行了调查研究,从官网到知乎,从水木到GitHub,我发现这真的是一家有意思的公司。

她是敏捷的创始者之一,她的技术人员都认为自己非常的牛逼,IT社区对于她的认可度非常的高,面试极其困难。

她规模不大,二十年了,全球不到5000人,她特别关注公益事业。

她的员工四处演讲,写书,各个都散发着自我的激情,观点犀利,表达直接。

她在市场上早期所承接的项目都不是大型项目,但都是难啃的技术骨头。

她更多不像一个公司,而像一个社群,一堆有情怀的人,攒在一起用公司的组织形式在快乐的玩耍。

我快速的做完了背景研究,两个标签闪烁在脑海,“技术卓越,开放多元”,这是我那个时刻所向往和喜欢的。

同时,我也迅速的识别出了她的挑战,过去的市场品牌定位以及她的基因,导致她在客户心目中是一个纯技术的专家、是一个工程能力的定位。而这样的强标签,则削弱了她在战略咨询和其他方面的能力。而这些如果补充上来,她将如虎添翼,在技术主导的数字化转型时代将脱胎换骨,独树一帜。

我做了一个对ThoughtWorks战略方向发展的报告,提出了我自己对于ThoughtWorks应该如何去转型,加强哪些方面能力的建议和规划。

接下来,我与公司的中国区总经理张松进行了沟通,这个视频沟通长达三个小时,深入探讨了关于ThoughtWorks应该如何去发展的话题。在谈话的过程中,我感觉到了他的正直和情怀,以及对于公司的一种愿景,这一点深深地吸引了我。

随着面试的深入,我陷入了一定的纠结,纠结的原因很简单,这边的薪酬是我五年以前的薪酬,比起我同时刻拿到的Offer低非常多。

我找了个机会,参加了一次咨询团队在北京的活动。团队在活动中分享做敏捷咨询的一些经历和故事。过程中,我观察到了一些有意思的现象,比如,我能感觉到,这个公司的每一个人都从内心里是自由的,所以他们无所畏惧,敢于表达,并且也会互怼。

我记得最后一次沟通,我和咨询团队的Lead通了一个很长的电话,我们谈起在战略方面的愿景,谈到了在ThoughtWorks已经具备的技术领导者的形象上应该如何去加强以及现在业务模式的一些需要完善和改变的地方。

谈得越多,我就越认为自己这样的经验和能力的人,是最合适的帮助ThoughtWorks去发展,去变革,去壮大的人选,甚至还没有加入就已经有了一些使命感。

经过十多年的纯商业化公司的冲锋陷阵,每天被数字逼着跑,被业绩追着狂奔,最后自己也变成了唯数字论,目标导向的领导,我需要一个相对自由的空间去思考,去沉淀。从一开始我就定义这是有很大风险的,毕竟文化相差太大,让战略咨询这样大家认为飘在天上的思维方式和一个以工程能力、代码至上的文化结合,不异于新的创业。

但是,最终我还是迅速的做了决定,我很清楚的记得,我的入职时间是2015年11月21日,11月第三个星期一。

二、纠缠

在原来的服务型公司,我既是销售,又是售前,又是Enterprise Architect,所以在这个角色的工作上,基本不需要融入,而且过去这么多年跨行业,跨业务的沉淀,让我快速的可以产出各种方案。

这过程中,我跟不同同事间的合作,大部分验证了我在前期调研的内容,同时也发现了特别多的有意思的故事。

我印象特别深刻的,是一个公司内部普遍传唱的段子。我们公司是一个特别有情怀,而且特别极客的公司。比如说,有客户请我们去做敏捷咨询,但是我们的顾问去了现场,待了半天然后就找到客户负责人,说,“这样吧,我们这个项目我觉得可以再看看。我观察了一下,你们的水平目前差距有点大,如果这么继续下去,也浪费你的钱,也浪费我的时间。”

这样短短一句话,就充分说明了这个公司的工程师文化,是真正价值导向的,潜台词是,我们不仅是冲着你的钱来的,我们是要对你的结果负责的。当然,这样的场景,是不可能出现在任何一个纯商业化公司的,这个顾问如果这么做了,可能第一件事情就是卷起铺盖走人了。

当然,这个项目的确就暂停了,但是第二年,客户又找回来了,这是个奇葩的乙方公司。

接下来就对接各种售前,包括售前体系的构建,每天忙碌着,也在观察和思考。这个公司很有意思,没有权威,每一个人都能自由的发言,互怼的氛围极其浓烈。群发China邮件,乃至群发Global邮件的事情屡见不鲜,越是领导者,越被各种拍砖。最长的邮件,可以有上百层楼高,各种声音,各种见解,大家各抒己见,不管你是BA还是DEV,不管你是行政还是业务,不论你是北京还是西安。

这个时候,碰上了#博客大赛#。这真是一个神奇的活动,我记得看到《MD脑洞》的时候,一下子唤醒了我沉睡多年的另一个自己。

我从小是一个文少,一直喜欢写东西,但是自从工作以后,不是代码就是PPT,跑的太快以至于忘了沉淀和总结。

而且短短的两个月我也更加坚定的意识到,其实ThoughtWorks是一个比较纯洁的技术伊甸园,大家沉浸在技术的海洋里,对于外界的行业、格局,了解的并不是很多。但是,这是优势,也是挑战。我连着写了三篇《从Accenture的三次大转型到EMC的转型失败看TW在国内企业IT服务市场的机遇》,我很久没有写这样总结性的文字,所以这个过程很享受,比写PPT写汇报材料更加的能够体系化自己的思维。

我记得当时,最后完结篇的时候,我写了一句话“为了坚持我们的情怀,必须努力让ThoughtWorks变得更好,让每一个TWer活的更好,在我们向客户倡导创新的时候,我们自己也要学习进步。”

写完这个文章后,我感觉到了我们文化的魅力,快速的有很多同事评论,加我沟通。我在经历了十几年的数字文化后,感觉在找回失去的自己。分享原来这么的快乐,总结原来这么的有影响力。

然后就一发不可收拾,写了30多篇《凯哥讲故事》系列,从售前体系到战略规划,从企业架构到管理实践,在内部也引起了一定的影响力,对自己更是一种回顾和总结。这是工程师文化和管理咨询文化的碰撞,这是极客世界和商业运作的交汇。

在这个磨合的过程中,熟悉我司的能力,组织,运营和体系,熟悉我司的同事,各种有趣的文化,这个过程我更多的像一个千帆看尽的过客,带着教练的思维在想哪里需要改进,哪里有问题。

这个公司对于每个人极其尊重和信任,没有什么审批流程,践行着敏捷的一切宗旨,而每一个个体的行为也充分体现了对这份尊重和信任的珍惜。

没有一般的外企那种邮件文化,实践的是深度的协作和沟通,深信只有信息的全面一致,对目标的深刻认同,才能够在后续的协作中更加高效。

坚信直接的反馈是最好的合作和成长,每天的站会都可以提出你的看法,每个项目结束都有一个回顾,大家坦诚公开的给其他人,给项目和自己予以反思和建议。

在这里,只要你有想法,你可以自驱动的提出来,如果你的想法能够得到一部分人的认同,就会有人加入你,我们内部称为“黑工”,就可以成立一个全功能团队,把这个想法付诸实现,如果对于社会,对于公司有价值,公司就会支持你这个团队。所以我们很多的内部系统都是“黑工”自己实施的。

现在很流行的互联网协作工具“金数据”,就是我司的几个同事的一个想法和坚持孵化出来的。

我们坚信每一个人都是正直的,在每一件事情上都尽到了自己最大的努力,即使失败,也是一次成长的机会,对人的尊重和重视,是我司的核心竞争力。所以,我们的面试的确也很严格。

过程中,我也发现了特别多的我司的不成熟的地方,比如运营,比如体系,比如结构,作为做了十年的企业级管理咨询的顾问,我很清晰的知道这些问题带来的结果就是,在很多时候为了达成彻底的理解和一致,效率不高,难以做到像前东家那样的规模。

所以那个时候内心里始终有一个声音在悄悄的说,“也许你就在做一个社会创新实验,最终你可能是不属于这里的,因为你要做更大的事情”。

但是另外一个声音又在告诉我“为什么一定要做到那么大规模化呢,你难道要回到从前的生活?那你为什么要来?”

我们的规模在扩大,我们的业务在多元化,我们的市场竞争和压力越来越大,这个过程中,会有很多的不确定性和碰撞,这也就是这个磨合的过程会非常纠结的原因。

这就像一对恋人,各种爱恨情仇的纠缠。我听到一些反馈,说凯哥很有韧性,这些韧性来自于内心对于这种自由文化的热爱,来自于对于这个特殊组织和群体内心的认可。

三、融入

经过近十年的咨询生涯的职业训练,我是一个抓大放小的人,我非常的目标导向,在职权影响力为主,绩效导向的纯商业化公司,只要把市场,项目开拓出来,严格的管理机制会找到人跟上去填,跟着你,按照你的战略、方向和方法把具体的工作执行下去,非常的高效。所以,相对于外部的客户沟通,市场拓展,在团队内部的关怀、成长和沟通方面,我的精力投入有限,特别是团队的具体的沟通,没有那么细节,我大部分的时间和精力都花在了外部拓展上。

而这里就不是这样,这是一个影响力大于职权影响力的社群,如果程序员不愿意去做一件事情,中国区的总经理可能拿他都没有办法。

在加入后第一年,结合战略咨询的方法论和敏捷精益的优势资产,我提出了Digital Discovery的敏捷IT规划的方法论帮助客户快速的启动数字化转型,小步迭代,快速奔跑。

我们的服务从原来仅面向开发人员技术人员的敏捷转型走向了面向企业管理层的整体数字化转型服务。

但是,这里的同事们很多都是纯技术出身,没有多年职场的历练,缺乏对于国内企业服务市场的了解,所以非常单纯。

一些在原来的环境看来都是心照不宣的规则,在这里很难被理解。

比如有一次给高管做数字化转型培训,机会难得,来的客户领导可能又有变化,所以议程和内容都要机动设计和调整。但是时间又非常紧张,没有充分的时间和团队去对齐,我只能快速的给他们介绍清楚我的布局和思路。对于大家的建议和想法,我又没有时间去详尽的解释。

由于没有充分的理解意图,所以在做培训的过程中,我偶尔会用纸板提示时间和节奏,在ThoughtWorks这样一个极度自由多元,乃至八卦的文化中,我很快的背上了中国区第一“控制狂”的名声。

这是文化的差异,就像一个火扔到了一个冰堀,这种冲突是剧烈的,是爆发的,是需要时间和经历去磨平的。

在我负责中国区数据业务后,又类似于一个创业,走出传统优势业务的舒适区,去打造一个新的品牌和业务。面临着市场的激烈竞争,这个过程很难稳扎稳打,如何在快速奔跑的同时又不至于散架崩塌,能力建设、团队培养、招聘、服务,这些事情势必和原来的做法有一些差异,所以,也导致了一些对于我和团队的一些传言,导致我不得不通过群发邮件的那种近乎幼稚的方式来说明。

这个过程我非常的纠结。有的时候我甚至感觉自己是一个人在战斗,没有人理解我。

但是,我清楚的知道,我有时候恨得牙痒痒的,咬牙切齿的东西,也就是我司那最宝贵的东西,这个东西的名字叫“Diversity”。

用张松的原话就是:

我们需要的是一片茂密的森林,而不是一颗参天大树,所以我们必须鼓励和支持那些不一样的声音和方式,而不是一家独大,一家之言,即使这样会带来一些损失和低效。

而且,如果你不足够在意团队的成长,不足够关注他们的快乐,你对他们的付出和投入不够,在一个每一个个体都自由的环境,产生一些不理解和误解那不是很正常的么?

当然,我也体会过,如果能够从内心深处,从思想上统一,从目标愿景上达成一致,那么这支聪明的队伍发挥出来的能量和创造力,也是不可想象的,能给你很多惊喜。

我自己就在被慢慢的改变,我感觉我从一个观察ThoughtWorks的社会实验者,逐渐转变成了ThoughtWorker,我会带着ThoughtWorks的词语,用我们的眼光来看待事物。

我从原来唯一追求“Make a Great Business”到同时追求“Be a Better Man”,这是一个修炼的过程。

我可以在团队成长的必要试错和短期的商业利益前选择前者。

我能够做到用更加耐心的方式和团队沟通。

我可以心平气和的面对一些传言和误解。

我愿意站到幕后,支撑着团队的发展,从自己干,到“手把手的带着你干”,从“我往前冲,兄弟们跟我上”到“你们只管往前冲,有问题我来填坑,我给你们做好保障”。

我看到团队的一些小的成长,欣喜若狂,比我自己拿下大客户还高兴。

我会花更多的时间去在内部交流和分享。

​这一切也带来了很大的成就感,不同于纯商业回报的价值感。

在这一切的变化下,新的业务也逐渐有了起色,而慢慢的和团队也建立了信任。

信任是,交流的细节和只言片语已经不那么的重要,我们抓大放小,用最高效的方式交流。

信任是,我们有着共同的愿景和目标,一个眼神就会前仆后继。

信任是,我们相信彼此是战斗路上背靠背的战友,即使有争执,那一定是为了团队和业务。

信任是,一切的过程都是可以动态变化的,最重要的是你想做,你要做。

信任是,只要是你挖的坑,我就敢跳;只要你敢跳,我就敢接盘。

信任是,我们有着永不言败的精神,我们都自带鸡血。

信任是,我们有着开放共享的情怀,我们相信,共享的是经验和知识,提高的是整体的能力。

信任是,我们有着协作共赢的信仰,相信只要做正确的事情,就会有支持。

很多人说,我的精力无限,激情无限。的确,我的过去的经历告诉我,人生就是一段历程,那么最美的是沿途的风景,所以有限的时间,要有更多的有意义的经验,要产生更多的价值。

我经常说一句话:“在这个高速发展的商业时代,ThoughtWorks之后再无ThoughtWorks”。

所以,我非常珍惜,呵护,这一段在这个神奇土地的时光,要尝试一切的可能,一切正确的道路。

我清楚的知道,他是什么样子,取决于你怎么理解和怎么看他,而你的所有的投入和经历,都会是一段宝贵的财富。

这两年,那个被数字追着狂奔的孩子,放慢了紧绷的神经,虽然忙碌依旧,但是思想是自由的,他可以去思考,可以去总结,可以去沉淀,可以去发现,可以去探寻一切的可能。

在这里,可以超越一般的等级森严,格局固定的大企业,自由的思考,自由的发言。

在这里,你可以按照自己的想法,自由的寻找塑造另一个自己,比如我们的职位,角色之间没有鸿沟,你可以自由的在适当的时候选择自己的岗位,于是从市场总监到数据分析师,从办公室后台工作到一线业务分析师,从开发尝试咨询,从办公室总经理去挑战交付总监,一切都只关系成长,一切都只关注成长。

在这里,可以跳过唯数字论的绩效,去寻找更有意义的价值。

在这里,可以放下以前的内部格局的敏感的神经,放开手的去做事情。

在这里,保留着资本和经济势不可挡的大潮下,2B企业中,对于每一个个体最大的尊重和自由。

这里的每一个人一直在追求技术卓越,技术卓越是什么,也许就是不断地超越自己,不断地找到更好的自己。

做真实的自己,做正确的事情,用正确的方法。

在这里,我找到新的自己。

用此文来纪念这过去的800多个日夜,和即将进入四十的我。


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

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&amp;amp;lt;&amp;amp;gt;(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