敏捷在中国这十五年

题记:2002年3月,《程序员》杂志发表了《极限编程》技术专题。以此为标记,敏捷进入中国已经十六年了。这篇文章是熊节去年为《程序员》写的年终回顾文章,发表于《程序员》2018年第1期。

时至岁末,各种年度调查报告渐次登台。其中我注意到云栖社区发布的《2017开发者调查报告》中有一项数据:45.6%软件开发者所在的组织采用了敏捷软件开发方法,在各种开发方法学中位居第一。这个数字又让我联想起,CSDN在年初发布的《2016年度中国软件开发者白皮书》中提到,64%的受访企业采用了敏捷项目管理工具。虽然之前也曾经看到某些调查声称“98%的企业计划采用Scrum”,但我对于这些调查的采样范围一向存疑。云栖社区与CSDN的这两个报告,在我看来客观而坚实地明确了敏捷在当今IT行业的主流地位。

作为站在传统企业数字化前沿的咨询师,来自各个行业甲方的动向也给我同样的感知。在电信行业,浙江移动大张旗鼓地开展敏捷转型与DevOps体系建设,并与咨询师结对公开演讲,介绍自己的转型经验。在金融行业,渣打银行的敏捷转型已经进行数年,汇丰银行以敏捷理念构建他们位于西安的研发中心,招商银行的CIO陈坤德在金融科技峰会中正面提出“银行必须敏捷化”,新成立的民营互联网银行更是从诞生第一天就把短迭代、自动化、持续交付等敏捷实践植入在基因深处。在汽车行业,7月发布的《汽车销售管理办法》打破了传统4S店对销售渠道的垄断,乘用车主机厂纷纷上马在线营销或销售系统,欲与已在地平线露头的汽车电商一争高下,短迭代、微服务、持续交付同样是他们在数字化渠道建设中的主题词。在航空行业,海航集团旗下的科技集团把自己转型成PaaS云供应商,组织文化、工作方式全面对标互联网企业,敏捷岛、看板、信息可视化等硬件设施已经成为研发团队标配。看着各行业头部企业的动向,我感到现在已经可以放心地说:敏捷,已然成为不可逆转的时代大潮。

这股大潮在中国最初的涓滴潜流,大约要追溯到十五年前。2001、2002年,彼此互不相识的几组人,几乎不约而同地向中文世界引进与敏捷相关的资料。《程序员》杂志在2001年12月专栏介绍重构、2002年3月专栏介绍极限编程,是中文出版物中有案可查的最早的先行者。同在2002年,北京软件过程改进组织(PKSPIN)的成员唐东铭向人民邮电出版社推荐了Kent Beck的《解析极限编程》,后来这一套《极限编程丛书》于2002年10月出版。到2003年,《软件研发》杂志的创刊号大篇幅介绍敏捷方法,《重构》、《敏捷软件开发》、《自适应软件开发》等一系列重量级著作引进。今日的风起云涌,即肇始于当年的青萍之末。

饶有趣味的是,唐东铭本人在后来的职业生涯中一直没有机会亲身经历一个敏捷的项目。他的经历,映出了行业的发展历程。敏捷所强调的快速迭代、持续交付,对于植根政府和大企业内部信息化、仰赖“十二金”工程哺育的尚处幼年的中国软件行业而言,是太过超前了。时至2006年,在第十届国际软件博览会上,Martin Fowler做了关于敏捷方法的主题演讲,台下报以他的是困惑的眼神与尴尬的沉默。语言固然是尚未全面与国际接轨的中国软件业理解Fowler演讲的阻碍之一,更大的鸿沟还是在于观念与意识。对于其时的行业环境与技术环境而言,每两周一次迭代、每次迭代发布上线给用户使用,既不可能、也不必要。中国的IT业还没有做好迎接敏捷的准备。

决定性的转机发生在2008年前后。通信市场的争夺日趋白热化,4G相关产品的研发已经从原来先有规范后有产品,变成了规范产品同步进行,并且运营商也开始要求越来越多的定制功能。这种竞争态势,使各家大厂把应对需求变化、缩短交付周期放上了研发能力的优先级。从2005年底,诺基亚在杭州的研发中心已经开始试点敏捷,并把试点的成果带到了2006年与西门子合资的新公司里。2008年,诺西多条产品线开始大面积推广敏捷。同在2008年,爱立信也在大范围实施敏捷,将传统的功能团队转变为特性团队,用Scrum方法运作项目,并引入了持续集成实践。华为在印度的团队于2006年小规模试点敏捷,总部得知这一经验后于2007年开启一系列试点项目,并于2009年开始全面推广,特性团队、双周迭代、故事墙、持续集成等实践切实落到了基层。2010年落成的华为南京、上海两个新基地,都大量采用开放式办公区、敏捷岛的格局。在BAT气候大成之前,通信大厂是中国技术人才的重要源泉,这几家公司培养出的大量优秀敏捷教练与持续集成专家,为后来敏捷在行业里的广泛传播起到了推波助澜的关键作用。

互联网大厂的敏捷起步也并非一帆风顺。2009年,百度把握住谷歌退出中国市场的机遇,全面对标谷歌,包括工程师的工作方式。从单一主干开发模式切入,百度大幅提高了研发过程中的自动化程度,把产品发布周期从几个月一次缩短到了每周一次发布。迟至2012年,腾讯某些产品还只能做到两三个月发布一次,通过模块解耦、提升自动化水平、拆分特性团队、持续集成等实践,得以逐步缩短发布周期,达到了每天能发布两个可用版本的水平。

不过互联网大厂毕竟身处在时代大潮的前沿,时刻接触海量用户真实的行为反馈,以及每一点转化率提升带来的直接经济效益,使他们有直接的动力不断缩短发布周期。大野耐一强调的“湖水与岩石”理论在他们这里得到了淋漓尽致的发挥:发布周期从几个月缩短到一两周,可以靠组织和管理的改变;从一两周缩短到一两天、甚至一天发布若干次,必然要靠技术和平台的积累。BAT自不待言,美团作为二线互联网大厂,也把技术视为自身核心竞争力。对技术人员的尊重不仅体现在管理技术双线并行的职业路径上,也体现在开放、平等、追求卓越的文化氛围上。对技术的重视带来的反哺,则是平台实力的大幅提升。借由高效的数字平台赋能,领先的互联网团队已经超越了“敏捷”的范畴,开发人员无需刻意考虑敏捷的实践,眼前的数据和背后的平台已经驱动着他们自然地按照极短的发布周期不断演进产品。

当互联网大厂以这样的高节奏从线上往线下席卷而来,各个行业的CIO们纷纷上马敏捷,看起来更像是在BAT收割之前的末路狂奔。已经被驱动起来的金融、汽车、零售行业,在一波与时间赛跑的敏捷浪潮究竟会剩下几家欢喜几家愁?有着大市场基数和高利润空间的教育行业,最近连续曝出令人不安的丑闻,这是否会成为政策放松管制、互联网竞争大举涌入的契机?医药行业树欲静而风不止,近有医药改革两票制全面触动流通环节即有利益、阿里健康倒逼医院改革,远处还有政府依托腾讯建设国家级医疗人工智能平台的愿景,医药行业的数字化、互联网化转型何时会进入快车道?航空行业谋求用数字化拉升资产效率,从民航维修、机场运营,到顾客体验、航线收益,再到搭建云生态平台,对未知场景、未知需求的快速感知和响应能力何时会排上航空业IT的优先级?这些可能都是我们在未来一两年内就会看到答案的事。

作为中国敏捷十五年发展历程的亲历者与推动者,透过敏捷被引进中国、被推介、被传播、被漠视、被抗拒、被接纳、被推崇、被转变、被淡化的过程,我看到了整个中国IT行业、乃至中国经济发展的缩影。今天敏捷成为最为广泛采纳的软件开发方法,背后折射出的是IT在国民经济生活中的地位提升、是技术人员从外包码农到企业核心竞争力的地位提升、更是中国经济在全球经济中的地位提升。过去十五年,来自美国的敏捷软件开发方法指导了中国的IT行业;未来,中国的IT行业需要什么方法来指导,这个问题可能要靠我们自己来回答了。


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

Share

浅谈敏捷离岸团队沟通

很多人说,要让团队敏捷, 先让团队坐在一起。没错,“坐在一起”这区区几个字,可以解决团队从沟通到信任到效率提升的不少问题。作为团队的业务分析师,我们很多时候都扮演着产品端和开发端的黏合剂,最理想的工作环境可能是坐在产品团队和交付团队中间;办公室就是大舞台,随时都能展现自己的十八般武艺,把“坐在一起”的效应发挥到极致。

然而,由于种种原因,我们不免会遇到跨文化、跨时区的离岸团队。当“坐在一起”的舒适圈被打破后,很多问题则接踵而来:“见都没见过的团队成员怎么建立信任?”、“人都找不到怎么高效沟通?”、“时区空间不一致怎么组织工作坊?”经历了一个离岸团队的从无到有,淌过了大大小小的坑,笔者将所见所得整理成本文,希望能对同样纠结于此的同行们有一点点裨益。

按需互访

“见都没见过的团队成员怎么建立信任?” 答案恐怕是“无法建立”。别怪我这回答太消极任性,对于远隔重洋甚至黑夜颠倒的离岸团队而言,留言和视频所带来的困惑和乏力往往多过友好度和安全感。尤其对于那些毫无离岸合作经验的客户来说,面对这份未知和“不可控”往往是自我保护甚至抗拒的。

合作双方的互访则是建立信任的捷径,通过这扇窗户,一方面可以了解双方的企业文化、工作习惯乃至个人的性格特点;另一方面能够利用面对面工作坊高效梳理规划,最大程度保证后续项目推进方向的正确性。在条件允许的情况下,在项目伊始就建立互访机制:

  1. 在项目的重要节点,例如合作初始、项目里程碑、检查点进行在岸交流;
  2. 设立双向固定互访周期,如每三个月/半年。

当有机会去到客户现场,该如何充分利用短短数周或是数日?从个人经验来看,你或许可以:

  1. 做好充分的行前计划:不要把它当成签证材料准备中的“例行公事”。海外出差费时费力,为了确保效果,必须提前沟通准备并了解项目干系人的工作/休假安排,重要会议提前发好会议邀请,最好以邮件形式确认你的计划。相信我,你一定不想像我一样,人都到了客户现场以为一切自有安排,才发现接头人马上要休长假,独留“一脸懵逼”的自己。
  2. 尽量结识多的人:哪怕你自认不是“交际花”,哪怕自己的英语不够好,哪怕ta算不上直接干系人甚至来自不相干的团队/部门;当你们未来有工作上的交集,有一面之缘也大大好过冰冷的邮件。
  3. 定期和离岸团队沟通:即使有完整的记录,出差回来一次性输出的效果恐怕也差强人意。就算再忙再紧张,也要定期与团队交流,沟通自己在客户现场的收获,了解团队的问题和想法,并及时反馈到客户现场的工作计划中。

当客户即将来访,该如何抓住深化合作的机会?

  1. 最重要的依然是计划:提前为客户来访的工作内容做好细致的安排准备,双方设置好来访预期和目标,最大程度利用好团队与客户成员共同工作的时间。
  2. 提升对客户的影响力:帮客户站得更高,看得更广。尽力帮助他们在来访过程中更好地感受我们的工作方式和文化氛围,甚至以我们为窗口,介绍目前国内市场上的先进案例和最佳实践。
  3. 为客户做好行前准备和安排:这包括签证准备、交通酒店及个人饮食过敏源等在内的各类生活细碎。很多客户并没有到访中国的经验,对这个陌生又熟悉的国家甚至存在很多误会和担心。我们可以简单准备一份包含城市介绍、物价水平等信息的行前小材料,让他们不至于在踏上飞机前对即将来访的城市一无所知。

搭建沟通框架

对于“坐在一起”的敏捷团队,沟通会在工作和相处中自然而然地发生。而当我们所处的是一个离岸团队,很多沟通问题则会因为物理位置、语言文化障碍、时差而被放大;最危险的可能是,你不知道你不知道;而某些沟通隔阂可能会在某些时刻产生致命的影响。在项目初始就定义好沟通的渠道和方式在这样的环境下显得尤为重要。简单来讲,我们最应该关注的是:谁和谁沟通,通过什么形式沟通,达成怎样的目标,要有怎样的沟通频次。

(在项目初始与客户达成对重要会议的一致理解)

(对团队成员之间的沟通渠道需要统一和确认)

巧用工具

“时区空间不一致怎么组织工作坊?”针对这个问题,恐怕不仅仅是需求分析相关的工作坊,离岸团队的种种限制对我们许多熟悉的组织技巧和习以为常的敏捷实践都提出了挑战。互访是类似昂贵的特效药,而真正要身体好,还离不开悉心的日常调养。合适的工具,则是这里的关键。

1.Always On:如果能有超过四个小时的工作时间重叠,Always on一定要有。实时视频能增加许多亲切感和趣味,拉近团队成员的距离;更能让包括站会、desk check在内的很多敏捷实践变得容易。有了Always On,信息不回抬头喊一喊,开会了朝屏幕招招手,方便直接,也算对得起客户给的“魔镜”名号。

2.远程协作编辑软件:市面上的远程协作软件让人眼花缭乱,在这里分享几个你也许正在寻找的:

  • Keynote-Collaborate Mode: Keynote算得上我们目前使用最为频繁的演示软件,而它的Collaborate Mode这项高能技巧好像并不是那么知名。协同编辑除了能在紧张的项目节奏中提高团队效率,还可以帮助在重要演示环节/工作坊中与客户进行快速确认。举个例子,如果有两人共同参加工作坊,一人作为组织者与客户交流,另一位则可以实时将产出记录到Keynote中,在工作坊结束前第一时间呈现给客户进行确认。

(只需点击标题右下方的Collaborate,输入你要协作编辑对象的iCloud邮箱,即可将当前文件分享给对方进行协同编辑)

  • RealtimeBoard: 如果让我列举“2017年度最好用工具”,RealtimeBoard一定榜上有名:它是我目前能找到的最好的sticker board,是组织远距离工作坊的最佳搭档。除了最常用的反馈会议、头脑风暴外,RealtimeBoard提供了许多针对不同场景的实用模板,例如用户故事地图, 产品演进路线。

(RealtimeBoard: 五花八门的实用模板)

(团队的第一次远程回顾会议)

3.即时通讯工具:每个人每天都要用到,自然必不可少。 在与海外客户的合作中,常见的主要有Skype, Lync(Skype for business), Slack,HipChat, Hangouts等。目前我们项目正在用的是Hipchat,比较突出的亮点是不用翻墙、可以与Jira, Github集成,缺点主要是记录保存时间较短。

4.项目资产管理工具:个人认为,离岸团队要比在岸团队更加注重文档,良好的文档整理能降低沟通成本,也让沟通有迹可循。关于用户故事/电子看板,常见的有Jira, Trello, Pivotal Tracker, Mingle;关于其他项目相关文档管理,一般使用Confluence, Google Drive, DropBox等。

文化互通

文化差异是每个海外合作团队所必须面对的。由于文化背景的不同,团队成员们有不同的语言体系、做事方式,继而对合作产生一些显而易见或者不知不觉的影响。它本身是一个中性词,甚至褒义词:两种截然不同的文化碰撞,让我们能够交到大洋彼岸的朋友,了解彼此的文化,是多么幸运的一件事。而它也有可能成为“问题”:因为缺乏了解,导致双方产生误解甚至不信任,影响健康的合作关系。

承认并沟通合作双方的文化差异永远不会太早,在项目开始前/初期就应该主动地向客户介绍我们的文化:这包括了大文化,即国与国之间的文化差异,例如中国人可能会相对内向,不说话并不代表没有关注讨论;也包括了小文化,即组织和团队的文化差异,例如我们会相对自管理,不存在传统的上下级观念。

我们总是在谈论良好的团队氛围对项目成功的重要性。良好的团队氛围永远不是从单纯的工作沟通中来的,而是必须来自于每一个活生生的人。当团队成员之间建立起个人关系,很多问题都可以迎刃而解。

(当遇到文化碰撞,团队里需要有人挺身而出)

以上寥寥几点来自笔者有限的项目实践,不免有所遗漏或有待商榷。但毫无疑问的是,离岸团队需要更用心和精巧地经营,而成功也往往离不开各个角色的配合与贡献。


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

Share

从汽车贴膜看专业团队

前几天去给新车贴膜,体验了一把什么叫“专业团队的专业服务”。

听老板说这家店刚开张两个月,但是团队并不是新组建的,而是已经在一起配合了很久。这从后来的整个过程,也看得出来。整个过程我几乎一直站在旁边,虽然被冻得够呛,也被老板怀疑我是在监工,说了好几次让我放心,绝对做到令我满意。但我其实是在观察,或者说是在学习,因为我觉得他们同样作为一只专业服务团队,比我们更敏捷,也更精益。

在制品限制(WIP Limited)

汽车美容这种工作,由于存在场地限制,天然就满足精益中的WIP Limited。像我这次来的这家汽车美容店,只有三个工作台,也就形成了最自然的WIP Limited。就算是有再多的活,再多的车需要贴膜装饰,也只能排在外边,整个团队最多也只能工作在三台车上。

这种天然的WIP Limited存在,也限制了大家并行工作的最大车数。那为了获取更大的利润,也就是为更多的车服务。大家的关注点自然而然的就落在如何以最快的速度完成每一台车的贴膜装饰过程,也就是我们常说的单件流和Lead Time。

自组织全功能团队

(自组织全功能团队)

为了尽量缩短每一辆车从开始装饰到完成交车的整个过程,也就是缩短单个车的Lead Time,我观察到整个团队是在以一种几乎完美的方式协同工作。

首先,所有的工作被高度并行化。例如我的车最多的时候有四个人在同时施工,一个人在缝真皮方向盘套,一个负责贴车左侧窗户的膜,一个负责贴车右侧的膜,一个负责贴前后挡风的膜。

其次,大家并没有清晰的角色划分,缝方向盘套的人在完成了手头的工作后,立刻自觉的加入到贴膜的工作之中;而两侧的膜贴完后,两名工人立刻开始帮车打蜡和做内饰清洁;整个过程自然而连贯,完全自组织,不需要人安排和督促。

所有人都掌握了缝方向盘套、贴膜、打蜡、内饰清洗的工作技能,并没有严格的角色分工,很难说清楚谁是贴膜师,谁是打蜡师,他们每个人都像一个专业的全栈工程师。你也很难说清楚整个过程的流程,是先做贴膜,还是先做内饰清洁,整个过程已经被高度优化过,环环相扣,环环相融,无论是时间还是材料的浪费都被降到了最低。

Leader VS Manager

不用担心,这不是发生了意外,而是在做“新车去异味”项目。而这个一头扎进充满烟雾车厢的人就是这家店的老板。是的,他还是我上面提到的四名“工人”之一,分别完成了缝方向盘套,新车除味和右侧的贴膜工作。

在我的眼里,他就是一个称职的Leader。凡事冲在前面,以身作则,勇于承担一些困难甚至危险的工作。而不是坐在舒服温暖的办公室里指点江山。有了这样的老板,这样的Leader,员工们自然也干的格外起劲。而对于作为客户的我,自然也对这样的团队平添了一份信任和钦佩。

质量内建

关注Lead Time并不代表做的越快越好,更不意味着忽略质量,毕竟残次品也是一种常见的浪费。这不,在我的车几乎贴膜完成的时候,工人在做复检过程中发现左后窗户的贴膜有了一个小气泡。

老板在亲自检查、确认无法修复的前提下,二话不说直接将已经贴好的膜撕掉,重新亲自上阵贴了一个新的给我。整个过程迅速而敏捷,还保持了较高的质量和水准。

总结

一个小时之后,我的车焕然一新。

不得不佩服这样一只专业的团队和那个令人钦佩的老板。他们的技术是那样的全面而专业,整个团队的协作是那样的高效而自制。

而回顾整个过程,让我对于自己的团队有了很多反思,对于精益软件开发中的很多概念也有了更深刻的理解和认同。


更多精彩内容,请关注微信公众号:软件乌托邦

Share

企业竞争力的双引擎:数字化与敏捷

[摘要]

企业的成功既需要数字化也需要敏捷化。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷化是天生一对,不能只选其中一个。数字化、敏捷化如何评估?如何才能更加数字化、敏捷化?

人类的进化进入了一个新阶段。科技已成为我们日常生活中不可缺少的一部分, 大部分人离开科技就无法生活。不仅如此,我们对科技的需求还在日渐增长。你能想象一整天不用Wi-Fi、Facebook、Instagram、谷歌或智能手机吗? 对大多数人来说,这肯定难以忍受吧。 我们需要来自各种网站、应用的即时回应。亚马逊、京东等公司已用“翌日送货”乃至“一小时内送货”(只要送货地址在范围之内)这样的服务宠坏了我们。我们需要吸引眼球、容易使用的界面,想我们所想、专为我们而创造的服务。

现在每一个公司都在寻求数字化转型。图1显示了2017年1月至本文写成期间,谷歌搜索“数字化转型”的趋势。很明显,大家对这个话题的兴趣在上涨。

图 1 谷歌搜索“数字化转型”(英文)的趋势

虽然技术是数字化中必不可少的一部分,但它并不是全部。数字化也需要转换商业模式、流程、文化和思维。非技术的部分可以用一个词来总结:敏捷。要适应客户不断变化的需求,就要保持敏捷。

图2显示了2017年1月至本文写成期间,谷歌搜索“敏捷转型”的趋势。可见,“敏捷转型”和“数字化转型”的搜索趋势都是在2014年开始上升的。

图2 谷歌搜索“敏捷转型”的趋势

数字化转型和敏捷转型有很强的关联。举例来说,亚马逊是数字化企业的领头羊,它本来只是一个电子商务网站,但现已成为市值两倍于沃尔玛的巨头。亚马逊没有把利润回报给股东,而是不断投资于创新,创造更好的客户服务。它是为客户而存在的。同时,亚马逊也是敏捷方面的领头羊。杰夫·贝佐斯提出的控制团队人数,以及他著名的“两个披萨”高效团队原则,都是在谈敏捷。

企业的成功既需要数字化也需要敏捷。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷是天生一对。坦白来说,根本不能只选其中一个。

“数字化”和“敏捷”是动态的、没有终点的比赛

想要数字化转型的企业往往一开始就问什么是“数字化”。虽然对它的定义众说纷纭,但在一些方面存在共识——比如,“数字化是关乎客户的”。数字化的目的是改进客户体验,让他们在达成自己的目标时投入更少。你对客户的服务越好,来找你的客户就越多,这就是真理。

但是,数字化没有一个黄金准则。有一个手机应用,不一定就是数字化公司。其他公司也有他们的数字应用,但并没有因此领先。不过如果你的数字应用很烂,那你就不能算是数字化公司。“数字化”的最低标准是有的,但没有最高标准。

企业和科技都在不断进步,数字化企业的最低标准也在不断提升。不断会有公司打破常规,抬高标准。今日的巨头很可能明日就辉煌不再,如博德斯、柯达等等。企业也是有半衰期的,平均寿命是18年。如果五年来你的公司还在同一个行业,做同样的事情,方法完全不变,就要特别小心了——你需要“颠覆自己”,不然就会被他人颠覆。

沃伦·巴菲特在2015年警告大家小心企业衰退的三要素,告诫波克夏下一任CEO必须与傲慢、官僚主义和自满作战。即使是波克夏这样一家收入超过了新西兰GDP的公司,也要小心谨慎,更不用说其他公司了。对付这致命的“三要素”的方法是公开、透明、激情,这也都是敏捷的基础价值观。

“数字化”(Digital)是个形容词,不是名词。你不能指望数字化有个标准,静态不变。这是一场动态变化的、没有终点的比赛,赛道上有很多竞争者。你需要以竞争对手为基准,来自我衡量。你能做的,只是比他们“更加数字化”。

同理,敏捷也不是个名词,没有最敏捷,只有更敏捷。在这个数字化时代,更数字化、更敏捷的企业才是赢家,也只有赢家才可以生存。

那么,到底是什么需要更数字化、更敏捷?

如果数字化和敏捷的都是形容词,它们形容的名词是什么?这个问题很重要,因为它定义了数字化转型的大框架。在这个框架下,需要找到数字化最少、最不敏捷的地方,让它们更加数字化,更敏捷。名词是你希望数字化、敏捷化的个体或组织。这个组织可以是企业也可以是政府。

图3 数字化、敏捷化的领域

那么,是什么构成了组织?组织运作的部分都是什么?它们是渠道、职能部门、外部合作伙伴、雇员、技术和领导力(见图3)。

渠道——渠道是组织与客户互动的渠道。渠道可以完全是数字化的,也可以物理与数字并存。好的渠道应该做到有用、有意义、知识丰富、无缝、统一、迅速。作为一个客户,我想与企业中那些了解组织也了解我,同时可以提供优质、迅速服务的人互动;我不想跟不同的人,还有讨厌的聊天机器人不断花时间去解释我的需求;我希望立即得到我想要的服务;我费的力气越少,我的感受就越好;不要让我费劲去想、花时间去等。

职能部门——组织中的各个职能部门齐心协力满足顾客的需要。有些可能在一线接待客户,有些可能在后台做不同的工作,有些可能负责管理与合规等等。不管怎样,他们的工作可以更加数字化、更加敏捷。他们的流程如何?采用什么步骤?可不可以省略或者自动化?有没有其他更简洁的方法达到同样效果?职能部门之间的合作能不能改进?职能部门能不能合并或重组,以精简流向客户的价值流?能不能给职能部门更大的权力去更好地服务客户?

合作伙伴——在全球化的今天,没有企业能独立生存。企业需要与伙伴或供应商合作。企业拥有的是哪种关系?是一方需要不断与另一方协商、再协商才能达成合作的关系,还是互利共赢的关系?合作伙伴能否很容易地纳入其中?信息可以顺畅地跨组织分享,还是有很多交流摩擦?沟通不畅、合作不佳,相关的职能部门就需要花时间等待,最终损害的是客户体验。

员工——有满意的员工才有满意的顾客。工作环境如何?工作环境是促进学习和分享,还是加剧孤立?员工需要每时每刻坐在桌前,还是可以在任何地方工作?举例来说,工作现在越来越移动化,员工可能不在桌前,而是用电子设备完成工作。出差和请假申请可以用电子软件批准。不过还不止于此。考虑一下能不能倾听员工的声音,提高员工参与度吧!考虑提供一个能为不同工作需要,提供不同合作空间的数字化职场吧!

技术——这点可能让人惊讶,不过技术管理及操作自身就需要数字化和敏捷。很多时候,信息技术被认为是要花钱的,我们会抱怨为什么一个系统要投入那么多人力,一个改动要花那么长时间。但是,如果我们相信科技是业务成长之源,那就在源头多投资吧:投资工具,也投资相应的人才,使用最新的技术。让你的IT系统成为“持续成长”的系统,而不是“老旧”的、衰退不能用的系统。顺便一提,英语里“老旧”一词是个多义词,它只有在形容IT系统时才作贬义词用。如果你的系统确实很“老旧”,那么,制定更新换代的计划——考虑一下DevOps(开发与运营一体化)模型,或者云端,或者微服务,或者敏捷与持续交付吧。

领导力——或许领导力改变的时候才能发生最深层次的改变。我并不仅仅指领导者,而是说人们领导组织的总体方式。它包括战略、计划、决策、预算、治理和绩效管理。领导者获得了准确的信息吗?雇员愿意提供信息吗?各层领导都愿意倾听吗?不论个人还是组织本身,都在持续学习吗?牢记沃伦·巴菲特的告诫,时刻警惕:傲慢、官僚主义和自满。

你有多数字化,多敏捷?

如上所述,数字化和敏捷是形容词。它们没有静态的定义,而是相对的概念。没有人能说一家公司满足了一组固定的条件,就是一家数字化公司。因此,不要问“我们是不是数字化”,而要问“跟竞争对手或以前相比,我们的企业数字化程度更高了吗?”。另外,数字化包含很多层面,你的企业可能在一个领域非常数字化,但另一个领域却做得不够。这种情况也不能长久。比如说,渠道十分数字化,但员工和技术的数字化成都非常低,就不明智。对于敏捷,道理也是相似的。敏捷也是一个相对的、包含多个层面的形容词。

在这里,我提出了一些衡量数字化和敏捷程度的评估方法,因为这是与时间、与对手赛跑,所以是相对评估。你可以有一些绝对的评估方法,不过即便如此,它们也是在相对场景下才合理。图4展示了这套评估方法。

图4 衡量数字化和敏捷的程度

我想强调这些评估方法只是为引出讨论而提出。当然没有适用于所有组织、所有领域(也就是前面讨论过的渠道、组织单位、合作伙伴等等)的一套标准评估方法。不同的组织和领域,侧重会有不同。因此,我提供的只供参考。

制定一套评估方法的时候,弄清楚你的目标对象非常重要。对渠道,评估对象是客户。一个企业更加数字化(或更加无缝等等),它的转化率就会更高。对职能部门,可以用订单、交货单等等作为评估对象。对员工,评估对象就是员工自己,人才招聘、员工发展才是最重要的。

另外,我的评估没有考虑“方法”,也就是说我并不关心你在使用什么技术。你如何做好顾客工作,达成效果才是最重要的。

这个数字化评估框架,原型是基于电商平台制定的。如果你有一家电商平台,而它比其他电商平台更数字化,我会期望你有更高的客户转化率,更低的客户投入,更高的交付履行速度,更高的推荐精准率,以及更高的客户推荐率。

评估敏捷化程度,我用的是同样的准则。评估的对象主要是变化:对变化的反应有多灵敏,变化后质量有多好,发货速度有多快,团队结构应对变化的速度和效率如何,以及学习速度有多快。

重申一下,我要强调这些评估方法只是为了引出讨论。你需要根据你的组织和领域进行调整。

如何更数字化、更敏捷

渠道,职能部门,外部合作伙伴,员工,科技,还有领导力等领域都可以变得更加数字化、更加敏捷化。虽然每个领域都有细微的差别和独特之处,数字化和敏捷化的方法是相似的,思维也是相似的。我总结了这些不同的方法帮助你变得更加数字化、更加敏捷化(见图五)。这是数字化者和敏捷者的职业工具。

图5 变得更加数字化、更敏捷的方法

先谈谈更加数字化的方法。当然这仅仅是个简介。

首先,利用数据。不要猜测,猜测会带来不必要的风险。你的设计和决策都必须基于相关的、无偏见的数据。设计在线或离线系统时,思考可以获取或收集数据的方法,当然不能侵犯客户隐私。思考在渠道、产品和服务中可以嵌入哪种智能来减少客户投入。

第二,设计思维是研发新产品和新功能时常用的。设计思维是与客户共情,了解需求以及反复改进可行的解决方案,永远追求客户认可。这与传统意义上“我什么都知道”的象牙塔思维的设计是不同的。不断收集数据、信息反馈,设计也持续迭代、改进。

第三,思考你怎样能利用科技民主化。不要限制顾客的操作,相反,向顾客和合作伙伴开放技术,让技术成为顾客的工具箱,顾客可以自行组合工具自助服务,满足需求。这包括开放应用程序接口,公开成果或提供其他自助服务的功能。这就是赋权,给客户赋权。

第四,反思你的价值主张。你还能向客户提供什么?你能更好地在客户和合作伙伴之间建立连接吗?你能重新包装你的产品,或者和合作伙伴的产品重新组合?这就是改变商业模式,它常常需要组织结构的变革。

最后,寻找将你的产品变成平台的机会。利用效应帮助客户放大商业生态系圈。这当然并不容易,需要清晰的价值主张、投资和市场,才能跨越引爆点。需要精心策划,才能保证生态系圈中有一个健康的网络平衡。

踏上数字化之旅,首先你需要变得更敏捷。没有敏捷就不能开始,这就是为什么我们经常看到新企业在做老企业想做却做不到的事情。老企业被官僚主义和自满绊住了。数字化在于改进商业科技的硬件和软件,但是敏捷在于改变员工和领导的心性。

敏捷之路开始于谦虚和勇气,在于承认我们不是什么都知道,而且我们愿意不断学习和适应。学习需要如饥似渴,对现有的所有智慧进行消化。学习也在于不断验证假设和猜想,不断调整,寻找可行的方法。

与敏捷很相似的是精益系统思维。分析整个价值流,去除浪费和瓶颈,或许还要重新设计价值流。精益系统思维常常和设计思维一起使用,但是前者更着重于后台合作,后者更着重于客户触点。

有了科技民主化,权力就会被下放。权力不再集中,相反,决策权会交给前线——创新最多的组织边缘。这对于很多组织来说,需要进行引导和赋权。过去,决策是由几个大人物掌握的,但是现在由很多小人物做决定,为顾客提供更好的服务。

引入颠覆性商业模式,需要改变组织和团队结构。这合乎情理,因为每一个商业模式都有相关联的组织结构。这是现实生活中的康威定律。不过商业模式在变,组织结构也在变。在企业结构方面没有万用灵药。组织结构是动态的,让自治的团队发挥才智满足客户需求,比让你的员工在循规蹈矩恪守工作流程要好得多。

如果数字化平台可以利用客户及其社交群体的网络效应,利用员工的网络效应也是一种创新。提供让不同职位的人合作的机会,这会让你的员工更好地了解公司,也能发掘更好的工作方法。这也能创造更强的归属感,而归属感正是传统企业中缺乏的。

为什么你不够数字化?

最后说一句,苹果公司推出iPhone的时候,诺基亚在研发上花的钱是苹果的九倍。钱和资源并不是关键。除了科技方面投资不善,我怀疑(并无证据)诺基亚当时有潜藏的傲慢、官僚主义和自满。如同每个个人一样,其实就是那句再普通不过的俗语:“骄傲使人落后。”

如果组织中存在某种显而易见的问题,鼓足勇气提出来吧。这个世界不需要假的数字化、纯粹的口舌之劳、或用来装饰门面的数字化。你需要有勇气,坚持,看到问题的核心。问题经常出在人心,也就是为什么敏捷需要先行于数字化,而勇气需要先行于敏捷。

所以,抛弃旧方法,系统地开启数字化的工作,在走向数字化和敏捷的进程中也要运用数字化和敏捷。有了这份勇气,你会得到丰厚回报的。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


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

Share

Offshore敏捷交付团队QA生存指南

跨地域性的offshore敏捷交付一直以来都是一个充满挑战的工作,对于需要与各种角色进行交互的QA而言更是如此。我在2016年初进ThoughtWorks时就经历了这样一个项目。此间个人也经历了从忐忑不安到得心应手。现在此离岸项目已经交付完成,我也想总结一下这一年来的项目生存实践。

项目背景

客户:澳洲大型电信公司Digital部门,我所在的电商产品部门下有3个交付团队和1个Devops[1]团队,每个交付团队有3-4个开发,1-2个QA,1个IM[2],BA[3]则是按项目分配且全部都在Onshore。

系统与架构:基于AWS部署的Oracle的内容管理和电子商务系统,系统较重,且需要通过中间件从核心系统拿到数据。

QA职责

  1. 参加需求评审和技术评审会议,与BA讨论AC[4],与开发讨论实现方案。根据需求和技术方案制定测试策略。
  2. 准备测试数据,测试数据大多来自于第三方系统,可以自己手动创建,有时需要其他团队帮助。
  3. 对已开发完功能进行测试,即测试故事卡。
  4. 负责新功能上线。QA需组织系统发布启动会议,完成集成测试和回归测试,在上线后对系统进行主要功能的回归测试。

项目困难

Offshore的项目中存在的主要困难来源于三个方面:时间不同,空间不同,文化不同。

  1. 澳洲时间比国内早三个小时,算上各自午饭时间,与onshore团队的工作重合时间可能不到5小时,一旦过了澳洲的下班时间,有问题需要找onshore的团队就会很困难。
  2. 澳洲距离远,国内团队和澳洲团队只能通过视频会议、邮件、即时聊天软件等方式进行远程沟通交流。
  3. 基于国内的网络环境,在与澳洲团队工作的时候,网速、VPN都会对沟通和工作效率产生影响。
  4. 澳洲距离国内坐飞机大概要13个小时,较长的路途决定了不会有很多机会和预算让两地团队频繁的出差、相互交流。
  5. 同时由于不在一个地方工作,几乎没有比如团建活动,茶歇等能够促进团队成员互相了解、建立良好团队关系的机会,这对于敏捷团队的建立是非常不利的。
  6. 澳洲是移民国家,虽然相对于欧洲国家人们的思想更开放,更能接受不同的文化,但中西方文化的截然不同还是会在某些场合带来一些意想不到的问题。而且如果彼此双方对对方的文化完全不了解,交流起来也会缺乏共同话题,难以建立同属感。

生存指南

为了减少时差带来的工作时间重合度不高的问题,国内团队相应会提前上班时间,并且在非工作时间内也会注意澳洲团队是不是有紧急的问题需要解决,时刻保证澳洲团队能通过电话顺利联系上国内团队。

做好每天的工作计划,在有限的共同工作时间里,把需要澳洲团队帮忙解决的问题设置较高的优先级,然后预计会有阻碍或者依赖的工作点要优先提出来。而作为QA,我们应该合理利用共同的工作时间,把需要与onshore团队沟通的任务比如需求澄清, 故事启动,客户展示等工作优先完成,把可以独立完成的测卡工作优先级相对降低,这样就不会因为某些流程必须要两岸团队共同完成而阻碍。

网络环境的不同有时候会给测试工作会带来很多不便。为了最低程度降低网络环境带来的影响,首先我们要依赖于Techops团队搭建稳定可靠的VPN,再者作为QA在测试过程中如果遇到一些奇怪的问题,在分析问题原因的过程中应该考虑到网络的因素,必要的时候可以请onshore团队帮忙测试排除网络因素。

在解决两地团队相隔较远的问题上,我们制定了定期派遣项目人员去客户现场进行知识传递的计划。对于时长6周的现场出差,出差人员一定要提前做好计划,定时追踪知识传递的进度,在客户现场要尽可能的多了解项目的有关知识并和onshore团队建立良好的关系。作为QA,首先,一定要找到客户的质量经理一起安排好自己六周的知识传递计划并定时追踪进度。然后在客户现场需要找到一个onshore 的QA和他一起结对工作,在这个过程中你会很快的了解到一切关于QA的流程和工具,包括测试环境、测试数据、CI工具、Bug管理工具等等。同时,QA也需要找到一个对系统十分了解的开发工程师给你仔细讲解系统的架构和技术实现。最后,在知识传递过程中一定要学会记笔记,快速准确的把有用的信息及时分享给自己off shore团队,以个人带动团队共同成长。出差在客户现场,还有一点很重要的就是要利用面对面的机会与onshore团队建立良好的同事关系。茶歇和下班后的聚会都是很好了解对方的文化背景,兴趣爱好,建立团队认同感的机会。

虽然敏捷团队提倡“工作的软件高于详尽的文档”, 但是对于分隔两地的团队来说,有时候详尽的文档恰恰是提高沟通效率的必要手段。比如一个团队共享的wiki就能够帮助团队在不知道从谁获取知识时高效的查找到所需信息。作为QA,在离岸交付团队中,我们更需要注重测试的文档化。比如我们不仅应该详尽的对每张故事卡的测试案例和测试步骤文档化,而且还要记录测试环境的配置和测试工具使用说明,甚至有时为了使团队知道Bug如何重现,我们需要把重现步骤用截图的方式记录在Bug里。总之,在离岸交付中我们提倡并强调把自己所掌握的知识第一时间文档化分享给大家。

最后,为了提高团队的融洽度,获得彼此的信任。团队成员不仅要在技术等硬技能上体现出专业性,还要提高自己的软技能,学会怎样与有着不同语言,信仰,文化的同事进行无障碍沟通。这就需要首先努力提高自己的英语水平,适应不同的口音,再者要了解对方国家文化习俗,如果能在节日时送上祝福,或者闲时聊聊对方的文化,都能使对方感到亲切,获得认同感。同时,我们也要适时输出自己的文化,创造一个多文化的融洽的工作环境。

短短一年多的离岸交付因为限制很多,无法像在其他项目上一样积累足够多的经验,但在这个过程中,我在不断的突破限制、找到最佳实践的过程中也获得了个人能力的提升。现在我把这些经验总结出来,希望能帮助到现在或以后有相同工作场景的小伙伴们。

注:

  1. Devops: Development&Operations, 负责环境搭建,流水线配置,部署等工作。
  2. IM:Iteration Manager, 敏捷团队中负责管理迭代工作
  3. BA:Business Analyst, 业务分析师
  4. AC: Acceptance Critiaria, 故事或需求的验收标准。

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

Share