敏捷在中国这十五年

题记: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

从汽车贴膜看专业团队

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

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

在制品限制(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

敏捷团队需要专职QA么?

敏捷QA对职业发展的担忧

最近和组内的QA聊起以后的职业发展,发现一个有意思的事情,有说想转BA的,有说想转开发的,有说想转型作PM的,还有想以后往咨询方向发展的。很少有说想在团队里面继续作QA的。QA这个角色难道就这么没有吸引力么?为什么都想转型或者自己出去单干呢?和组里几个QA聊了之后,发现主要因素在于对QA职业发展的担忧,觉得敏捷团队对专职QA的需求并不大。

记得我刚工作的时候还是有独立测试团队的,那个时候分工很明确,我就负责windows mobile(现在叫windows phone)上应用的自动化测试,我的这个职位叫做SDET,说通俗点就是自动化测试工程师。我们这个团队大概有10人,测试完毕后将结果汇报给测试经理。由于产品复杂,需要大量的测试工程师以保证产品能顺利发布。随着更多功能的加入,测试团队的人数也在增加,这段时间是QA最有价值感的时候,产品的发布最终都由你来把关,你可以根据兴趣来选择以后做一个性能测试或者安全测试工程师等等,有明确的发展路线。

但现在越来越多的公司选择了敏捷转型,适应变化和快速交付可工作的软件成为了团队的关注点。从开发和用户的角度看,他们会很乐意接受这个变化,客户可以不断看到新功能,开发可以把精力从繁琐的文档和流程上释放出来,发挥想象和创意来提供更好的解决方案。可对于QA来说,敏捷带来了什么好处呢?之前定期有一个可测的稳定版本,详细的需求文档就是我们参考的对象。现在要对一个不断变化着的对象来进行验证,也没有一大段时间来设计自动化框架。我们怎么来保证质量呢?

敏捷QA的测试职责

在敏捷的团队中,质量是由团队所有人来保证的,我刚开始听到这句话就像听到敏捷宣言一样,知道这有道理,但具体怎么做呢?如果质量是团队的责任,那么专职的QA干什么呢?

首先我们来看在敏捷团队经常用来保证测试用例达到平衡状态的测试金字塔,简单来说我们可以把更多的测试放在单元和服务级别,因为这些用例更易维护和执行,运行效率也更高,可以参照Martin FowlerTestPyramid

在这个框架下,很容易让人产生这样的误解。

1. 开发负责单元测试,不需要QA参与

跟组里的开发讨论过“是否需要QA参与到审查单元测试覆盖率”的问题,开发通常会觉得用处不大,因为有专门的工具比如:Cobertura, Jacoco, Istanbul等。这些工具的检查范围通常包括

  • 行覆盖率(line coverage):是否每一行都执行了?
  • 函数覆盖率(function coverage):是否每个函数都调用了?
  • 分支覆盖率(branch coverage):是否每个if代码块都执行了?
  • 语句覆盖率(statement coverage):是否每个语句都执行了?

而QA的检查可以弥补单纯的代码级别的覆盖。比如异常处理和边界值的情况,代码级别的覆盖会检查语句是否执行了,但是不能检查这段逻辑是不是写了。下面列举出几种常用的检查方法:

  • 等价类:把程序的输入域(所有可能的输入数据)划分成若干部分,然后从每个部分中选取少数有代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中其他值。
  • 边界值:边界值分析法是对等价类划分的补充,它是对输入或输出的边界值进行测试的一种测试方法。我们这里所指的“边界值”是相对于“输入等价类”和“输出等价类”而言的,稍高于其边界或低于其边界的一些特殊情况。
  • 决策表:在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作,判定表很适合于处理这类问题。
  • 因果图:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

有的QA会发现这些通常是用在黑盒测试里的方法,其实把这些覆盖尽可能的在单元或者服务级别来实现是一种既有效率,结果反馈又快,又可以直接作为回归测试的一种很好的途径。

在项目的实践中我们可以看到QA参与到单元测试的审查有以下好处:

  1. QA可以审查单元测试的覆盖率,来调整单元测试以及后续接口测试和回归测试的覆盖率。之前做的项目都是开发独自写单元测试和接口测试,QA也独自写自动化回归测试,后来发现有很多的重复覆盖,这也是种浪费。如果能结对来做单元测试,是种更高效的方式。
  2. QA可以更清楚代码对各个模块的影响,这样可以有针对性的设计回归测试,比如之前项目有个小的改动,QA没能在很短的时间进行回归测试,导致产品发布后遇到了问题。有人会说自动化覆盖所有回归测试不就行了么?理论上是这样的,但现实中有很多限制,只能通过手动验证来完成回归测试。这种情况下,精确定位回归测试的范围变得尤为重要了。
  3. QA对系统构架、开发语言能有一个学习的过程,这有利于自动化回归测试的搭建。

2. 开发更适合设计自动化测试框架和接口测试,因为他们写代码更有效率

如果说自动化测试和接口测试的目的是比谁写代码的效率更高,那么的确这些事情应该由开发去做,但是作为QA,参与其中的作用在于分析需求以及从客户的角度来设计用例。

敏捷团队越来越多的应用行为驱动开发(BDD)来覆盖基于服务和UI的测试。

1、QA会和PO,BA,DEV,UX一起合作,分析软件的需求,然后将这些需求写成用户故事。开发者负责填充这些故事的内容,测试者负责检验这些故事的结果。通常,会使用一个故事的模板来对故事进行描述。

故事的模板:

  • As a 角色
  • I want 特征
  • so that 利益

比如:

As a mobile App user

I want to recharge the Mobile phone number with credit card

so that I can have fee to give a call

2、每一个story有可能会有不同的场景,可以用下面的模板来描述在什么环境下发生了什么事情,结果如何。

  • Given [上下文]
  • And [更多的上下文]
  • When [事件]
  • Then [结果]
  • And

比如:

Scenario: Recharge with Credit card successfully

Given I logged into the Mobile App

When I go to Recharge page

Then I can see the recharge option listed

And I can see the Mobile phone number input box listed

When I input the phone number

And I select the recharge option as “Credit card”

And I input the Credit card number

And I click the Recharge Button

Then I can see the “Recharge successfully” message shows

3、QA会和DEV一起合作来实现这些story的自动化测试,常用的工具:

  • Cucumber (Ruby framework)
  • SpecFlow (.NET framework)
  • Behave (Python framework)
  • JBehave (Java framework)
  • JBehave Web (Java framework with Selenium integration)
  • Lettuce (Python framework)
  • Concordion (Java framework)

3. 开发交互进行基于UI的测试就行了,不需要专门的QA进行测试

如果说基于UI的测试就是执行测试用例,那么的确不需要专职QA来做,但是在敏捷的团队中基于UI的测试大部分是以探索性测试来完成的。怎么设计好的探索性测试用例才是专职QA的价值所在。

有人说探索性测试就是手动测试,有的说是随机测试,有的说就是把自己当用户来使用软件的测试。

什么是探索性测试?下面是wikipedia上面的定义:

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, who coined the term in 1984,[1] defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.

看完这个解释更迷惑了,探索性测试到底是什么东西?

举个简单的例子,我们聚餐的时候有时候会玩猜数字的游戏,主持会写下一个数字,大家轮流猜,主持会提示大了或者小了。那么下一个人会根据这个提示来继续猜,直到有人猜中这个数字。这其实就是探索测试的原理,每次都会根据之前的结果来设计下次的数字,那个被猜数字就是defect,每一次猜测都是测试用例。如果你想用最少的次数来猜中这个数字,就需要有高效的方法,探索测试也是如此。

敏捷QA存在的价值

以上简单的描述了在敏捷团队中,QA在测试中的职责:

  • 审查单元测试的覆盖率
  • 和开发结对搭建基于服务和UI的测试
  • 探索性测试

其实QA还有很多面向客户的职责,比如需求澄清以及产品演示,会在后续的文章去讨论。

随着敏捷的项目越来越多,对QA的需求不是越来越少,而是越来越高,QA需要像一个好的家庭主妇一样,能里能外,在团队内部能更好的平衡测试设计,在外部能更好的体现产品价值。在一个快速变化的时代,在持续快速交付的情况下保证质量是一件很困难的事情,解决这个问题就是QA存在的价值。


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

Share

项目管理中的敏捷实践

作为项目经理,我们经历了不同的项目,却总是受限于相似的困局。比如以下三个典型难题:

  • 团队目标不一致
  • 团队成员不熟悉
  • 信息发布不流畅

倘若我们任由问题存在,而不在每次项目中进行总结和提炼,就会反复的徘徊于丰满理想与骨感现实当中。

敏捷思想和实践能够为我们提供一种可能性,帮助我们解决在项目交付过程中遇到的具体难题。

敏捷的项目管理——追求最大价值的成功

当我们提到敏捷的项目管理,就得先说说瀑布式开发和迭代式开发的区别。

(图片来自:http://t.cn/R9IjtIs)

大家都知道瀑布式开发的特点是大批次、缓慢流动、在每一阶段追求工作完整,但因其缺乏并行迭代的概念,对变化的响应必然很慢。而迭代式开发则恰恰弥补了这个弱点。在迭代式开发过程中,整个开发工作被组织为一系列短小的、固定长度(在ThoughtWorks通常是2周)的小项目,我们将其称为一系列的“迭代”。每一次迭代都包括了需求定义、需求分析、设计、代码实现与测试。

采用这种方法,开发工作可以在需求被完整地确定前启动,并在每次迭代中完成系统的一部分功能开发工作,再通过客户的反馈来细化需求,并开始新一轮的迭代。

ThoughtWorks的敏捷开发通过逐步细化、迭代前进的方式,分阶段地将需求予以实现。比如说,我们先从整体功能规划中定位出一小部分核心功能,打造能基本运转、对用户有价值的最小可用产品(Minimum Viable Product,MVP),然后迅速迭代开发,听取用户反馈,及时调整功能规划。

我曾在一次培训中听到同事谈到敏捷团队与西游团队的相似性,他认为唐僧师徒可以被看作敏捷中的全功能团队:团队有共同的目标——取到真经;他们历经了九九八十一难,好比九九八十一个迭代,每次打怪成功都是完成了一次交付;在不断迭代的过程中,这个团队不断地收集反馈、持续改进,一步步地完成了最后的目标。取到了真经,意味着完成了项目的交付,同时使得团队能力得到质的提升。这是一个美妙的结果。

项目成果的交付和团队能力的提升,这是项目经理在项目管理中最希望达成的目标。 传统项目管理的定义是:“在有限资源限定的条件下,实现或超过设定的需求和期望”。一句话概括了传统项目管理的铁三角:需求是范围,资源包括时间和成本。

那么这个定义是正确的吗?

大家都看过电影《泰坦尼克号》,如果我们套用上面这个“范围、时间和成本”定义的框架,《泰坦尼克号》会被判断为一个失败的项目。为什么呢?这部电影在拍摄过程中多次延期,预算也超出很多,无论从成本还是时间来看,这都是一个失败的项目。可是我们都知道,《泰坦尼克号》直到现在仍然是一个难以超越的票房神话。

由此可知,左图的“传统项目管理铁三角”概念忽略了“价值”这一重要因素。右图的“敏捷项目管理铁三角”强调,团队应得到来自市场的真实反馈,以此来帮助敏捷团队持续不断地、尽早地交付有价值的软件。

在追求价值交付过程中,我们越来越多地发现敏捷项目管理中有着至关重要的一环——人,也就是我们的团队。价值是人创造的,是为人服务的,很多敏捷实践都围绕人展开。我们试图找到一种通用的方法来最大限度地发挥人的能量。未来社会最有价值的人,是以创造力、洞察力、对客户的感知力为核心特征的,我们相信这样的团队能创造最大的价值。

下文将以我在ThoughtWorks的项目经历为例,讲述ThoughtWorks日常交付项目中主要使用的敏捷实践是如何帮助团队实现最大价值的。

用户故事

用户故事(User Story)是敏捷开发的基础,它从用户的角度来对需求进行描述。软件开发是为了实现产品的商业价值,满足用户需求。只要需求足够明确,所有人都了解其具体内容,团队就能简单有效地把需求转化成可实现、可测试、能够发布的代码。为了实现这个目标, 需要找到一种方法来描述需求,让所有人都能对任务的范围有一个共同的认知。这样团队对任务完成会有一个共同的定义,不会出现“你做的不是我所要求的”、 “我忘了告诉你这个需求”等类似的问题。

用户故事体现了用户需求以及产品的商业价值,同时定义了一系列Acceptance Criteria(AC)。只有团队完成的工作符合这一系列的AC时, 才算真正完成了这个用户故事。一个用户故事通常包括三个要素:

  • 角色:谁要使用这个功能;
  • 活动:需要完成什么样的功能;
  • 商业价值:为什么需要这个功能,这个功能带来什么价值。

用户故事可以有不同的展现形式,以下是其中一种:作为一个<某种类型的用户角色>,我要<达成某些目的>,只有这样我才能够获取<商业价值>。

所以用户故事一旦被确定,那么它所要实现的功能、需求范围、所需工作量也就随之确认了。之后开发人员所要做的就是根据这个用户故事的内容进行开发,只有当所有AC被覆盖到,测试人员完成测试,发现所有功能是可测试的、可运行的,这个用户故事才算完成了。

估算和迭代计划

估算(Estimation):团队在动手开发一个用户故事功能之前,应当对实现这个用户故事所需要的工作量有清晰的认识。如Martin Fowler所说,”Estimation is valuable when helps you make a significant decision”。只有当团队对达成一个目标的工作量以及完成它之后的“收益”有明确的认知, 才能做出明智的决定。

当团队在为工作排定优先级、制定迭代计划时,业务分析师需要知道每个用户故事的成本,团队成员需要知道每个用户故事的价值。有很多种估算用户故事工作量的方法,其中一种就是把完成这个用户故事所需要的点数(根据用户故事的复杂度估算)写到对应的故事卡上。估算可以帮助团队以不同的方式,对实现即将开始的用户故事、未来的架构方向和代码库的设计,有更好的理解。一个迭代能完成多少个点数是能估算出来的。也可以使用一些工具统计出过去每个迭代所完成的点数,比如燃尽图。

只要整个团队共同协作,估算本身也可以变成一种很有意义的活动。它有助于团队增进理解,并保证团队每个人都对要交付的需求范围和价值达成共识。让评估变得更有趣的是,通常不采用简单连续的数列,比如1,2,3,4,5等——而是采用一种近似菲波拉契数列的形式,像1,2,3,5,8,13等(正如《达芬奇密码》里面看到的),这样当数字越大、相邻数之间的间隔就越大,使得团队更容易区分哪个故事更小、哪个更大。

在做迭代计划(Iteration Planning)时,团队需要从客户价值维度和技术风险的角度来排定优先级。下图中是常用的工具之一——需求优先级矩阵。

迭代会议和功能演示

敏捷宣言里面有一条:客户协作优于合同谈判。在敏捷团队中有一个角色叫做业务分析师(BA),其核心职责是确保业务需求的清晰和透明,保证开发团队对业务有足够的理解,并将这些待完成的用户故事按照优先级排列出来,以任务卡的形式来驱动团队的开发。

迭代会议(IPM)通常发生在每个迭代的第一天,团队成员一起制定迭代计划。这个会议由BA主持,大家一起同步几个方面的内容:

  • 下一个迭代的用户故事;
  • 对下一个迭代的期望和计划;
  • 风险的评估和总结。

不同的人对需求有着不同的理解,所有团队成员都要对用户故事所有相关内容、所要实现的功能、满足哪些条件用户故事才算完成达成一致。迭代会议的主要产出是下一个迭代中需要完成的用户故事,这些用户故事即为下一个迭代所要完成的主要目标。

功能演示(Showcase)是敏捷开发流程中的又一个实践,通常发生在每个迭代的最后一天,目的是演示可工作的软件。团队把一个迭代中开发好的功能给相关人员演示,并收集反馈,以便在下一个迭代中可以对变化作出快速响应。

站会和用户故事开卡

简单地说,站会(Standup)是团队在一起快速地开一个会(通常在物理墙前),成员逐个更新自己的状态。更新包含以下几个方面:

  • 昨天完成的工作;
  • 今天计划做的工作;
  • 面临什么阻碍,需要什么帮助;
  • 自己手头用户故事的进展,是否存在技术风险。

既然是快速的会议,站会的时间就不宜过长,10分钟左右为佳。建议团队成员站着开会,因为研究表明,当人们坐着开会的时候,会议的时间会被无形中拉长。

这里有一些实践原则:

  • 团队成员都要参加站会,轮流主持,谁迟到了都不等——仪式感很重要。
  • 站会的时候,每位团队成员围绕故事卡进行更新。介绍一种有意思的实践——使用Token(也就是使用一个实物作为”令牌”,准备发言的人首先取得”令牌”,发言完成后将“令牌”传给下一个人。令牌要醒目,可以是毛绒玩具,也可以是一顶帽子)。

用户故事开卡(Story kick-off):在每个用户故事开发之前,要确保BA、DEV和QA对用户故事理解一致。这个沟通活动通常表现为由DEV讲解这个用户故事要完成的功能及AC,一旦发现任何疏漏,BA及时补充。DEV有任何疑惑也需及时提出来,当场确认,使这些功能得以正确实现。在后续开发中如果碰到任何疑惑,也应及时找BA了解清楚。QA会严格按照AC来验收用户故事。

代码审查和回顾

代码审查(Code Review) 开发团队在完成每天代码之后,会聚在一起评审当天的代码,这样做有几个好处:

  • 团队经过一天高强度的思考与编码,适当地停下来,看看其他人写的代码,同时将自己的代码讲解出来,往往能获得一些意外的灵感,或许能解决自己面临的阻碍;
  • 互相了解设计思路,获得更好的建议和进行思路重构,提高代码质量;
  • 及早发现潜在缺陷,降低事故成本:如果这个时候发现代码的坏味道和一些需要改进的地方,代码审查结束后可以花少量时间作出更改;
  • 促进团队内部的知识共享。

回顾(Retrospective):回顾会议的目的是通过新的沟通形式唤起大家对团队的集体意识,指出团队或个人在一段时间内的不足并列出对应行动。持续而有效的回顾和反馈,可以保证团队关心生产力和效率,了解自身的不足,这将成为团队持续改进的起点。

回顾的关注点也多种多样,除了“项目开发”之外,还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。在坚持回顾的同时,需要做的还有保证回顾的有效性。应根据团队建设目标的发展变化,不断调整回顾的关注点和形式,确保回顾能够有针对性地发现团队的缺陷并转化为实践。长期有效的回顾和正确的回顾产出,还能够不断提升团队内部的安全感和信任度。

回顾的形式和方法非常多,最常见的是“Well & Less Well”。

最大程度的可视化

看板源于精益生产实践,敏捷将其背后的可视化管理理念借鉴过来,形成了具有自己独特风格的可视化管理工具。

在敏捷项目里,挂在墙上的“人人可见的大图表”是一种普遍的实践,它被用来共享项目的状态并将之可视化。比如表示项目状态的物理墙,这样的物理墙通常包括三个元素:时间、任务和团队。

除了表示项目状态,项目团队还会可视化其他的元素,比如团队应坚持的规则、项目上的经验分享以及项目的里程碑。

一般来说,通过有关联的团队和个人之间相互协商,可以识别出未来一段时间里各自的活动,以及相应的、对成功的衡量方式,然后将其可视化出来,每段时间再回顾和调整一次。有了这样的可视化,团队会更加容易对齐目标,并不断培养和加深责任感。

可视化带来的好处是:

  • 日常工作透明,将迭代过程中所有的故事卡可视化出来,团队成员可以随时知道当前需要完成的工作以及将要完成的工作。由于人对视觉反应更灵敏,可视化的故事墙能立刻聚焦团队的注意力。
  • 将迭代过程中遇到的问题暴露出来,可以促进团队成员在工作中一起积极讨论解决方案。
  • 团队也可以根据现在的进度以及遇到的问题,了解需要哪些帮助,更好的分配资源,减少开发进度被滞后的风险。

沟通计划

敏捷里面的自组织团队其实是敏捷的结果,而不是先决条件。实施敏捷的过程也是打造自组织团队的过程。每个团队成员在面对“做什么、怎么做”的问题时,也会以自组织的方式去解决。每一天,团队中的每一个人都要其他成员保持协调。为了保持同步,我们会创造基于敏捷实践的沟通机会,这个也是实施敏捷的过程之一。

在ThoughtWorks有一个非常有名的活动叫Inception。Inception是启动软件设计和交付项目的方法,通过集中式、互动式的设计工作坊,帮助客户在最短时间内对项目范围达成一致,快速进入项目交付。而Inception的一个产出就是沟通计划(Communication Plan)。比如在这个沟通计划中会讨论:以什么频率、什么形式作项目的更新,比如说每周五以周报的形式作一些主要信息的更新;站会和迭代会议什么时候召开,需要邀请哪些人,比如说业务负责人,技术负责人等等。

以下内容都会在沟通计划中定义清楚:

写在最后

回到文章开头的部分,我认为可以将敏捷实践和解决方案做如下对应:

团队目标不一致

  • 用电子墙和物理墙展示用户故事、需求全景图、项目进度燃尽图;
  • 通过迭代会议和功能演示会议对齐迭代计划,项目进度、识别项目风险。

团队成员不熟悉

  • 基于敏捷实践,创造更多的沟通机会,比如回顾会议、代码审查和站立会议。通过不断地创造这样的沟通机会让团队成员更加默契。

信息发布不顺畅

  • 共享信息,制定沟通计划;
  • 最大程度的可视化。

文中提到了很多类型的敏捷实践,这些实践需要贯穿到团队的日常活动中去,持续的实施和改进。行为心理学研究认为:21天以上的重复就会形成习惯。任何一个动作,重复21天就会变成习惯性的动作;任何一种想法,重复21天、或者重复验证21次,就会变成习惯性的思维方式;任何一种信念或者有益的实践,经过团队持续验证,它一定会成为团队的信念和实践。

剑道中有这样一个心诀:守、破、离。

  • 守:最初阶段须遵从老师教诲,认真练习基础,达到熟练的境界
  • 破:基础熟练后,试着突破原有规范让自己得到更高层次的进化
  • 离:在更高层次得到新的认识并总结,自创新招数、另辟新境界

项目管理者中的大多数人都处于“守”的阶段:他们学习、吸收了前人的项目管理经验,带领自己的团队有序地开展项目交付工作;但是他们经常困惑于某些在管理中反复出现的问题,苦于找不到有效的解决方法,不得不在新的项目中重复之前的困惑;

有的项目管理者已经达到了“破”的层次:他们能够以全局优化的角度去总结自身项目管理的经验,并通过学习、分享及各种交流平台去开阔眼界、拓宽思路,借鉴或改良项目管理的方式方法,使之更适用于团队;

而所有项目管理者的最高目标则是“离”:随着项目经验的不断积累、对管理的思考日渐加深,对项目管理有了新的、更高层次的、属于自己的独特认知,并将其应用在实践中,独辟蹊径,使整个项目管理思路焕然一新。

希望越来越多的项目管理者能够达到更高的阶段。这是我们在项目管理中不变的追求。


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

Share