新加坡政府的数字化之路

在世界经济论坛发布的2014至2015年全球竞争力报告中,新加坡政府位列 “全球最有效率政府排行榜” 第二名。世界经济论坛评估全球144个国家政府的效率和竞争力的标准,在于政府开支的浪费情况、政府管制的负担及政策制定的透明度。

在最新的世界银行 “最容易经商的国家” 排行榜中,新加坡位居第二,在过去十年,新加坡一直高居第一。

2006〜2015的十年间,新加坡人均国内生产总值从全球第七名(六万美元)提升至第四名(八万五千美元)。反映贫富差距的基尼系数,也在过去十年间逐渐下降。

政府的效率、做生意的难易度、居民的生活质量,很大程度取决于政府为居民、企业提供服务的质量和效率。在这个信息量巨大、环境多变的时代,新加坡政府之所以能高效运转并取得一系列瞩目的成绩,科学技术无疑是关键要素之一。

新加坡政府数字化的历史

新加坡政府的信息和数字化始于1980年国家信息化委员会的成立(Committee for National Computerisation)。成立该组织的目标是使用信息及通讯技术来提高政府公共管理效率,主要专注于工作自动化以及办公无纸化。到了90年代,重心逐渐转向在公共服务内网集成和共享数据。

进入21世纪,政府对数字化的重视程度上升了一个新台阶。2000〜2003年间,新的电子政务计划(e-Government Action Plan I)出台。其愿景是在全球经济日益数字化的进程中,将新加坡发展为拥有领先电子政务的国家。

时任公务员首长的林祥源(Lim Siong Guan)先生还特别指出,电子政务(e-government)不仅仅是增加计算机设备、在网站上公示信息、象征性地为政府服务加个“e”,其核心是利用信息技术带来的优势,重新对政府工作模式进行全方位思考,重新设计工作流程,大幅提高政府对个人及企业服务的质量和效率。

自90年代末开始,全球互联网经济的发展呈现指数级增长。旨在创造领先电子政务的新加坡政府,在第一个计划启动三年后又推出了新的计划(e-Government Action Plan II),该计划的愿景是在2003至2006年间,打造一个网络化的政府,通过为用户提供易访问、集成化、有价值的电子政务服务,将国民紧密地团结在一起。

2006年,iGov2010年愿景诞生,计划从一个集成化电子政务的政府,发展为高度集成管理的政府。通过信息技术连接民众,提升服务满意度。该计划要求所有职能部门改进政务系统的后端流程,增强以用户为中心的服务能力。

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

最新的一份覆盖2011至2015年的电子政务总规划中,数字化道路由自上而下 “政府对用户” 的方式转向 “政府与用户” 。该计划最主要的改变在于,政府、民众、私企将展开合作与互动,共同为国家和民众创造最佳的信息技术解决方案。2014年,政府宣布由GovTech(政府科技部)启动 “智慧国家” 工程,通过全国范围的传感器进行数据采集和分析,更好地掌握各项目事务(例如交通状况、空气质量)的实时信息。

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

成就与不足

三十五年间,新加坡政府紧跟全球信息技术发展的节奏,不断调整电子化政务发展的规划设计,从实现自动化、到追求卓越、到集成化管理,再到政、民、企合作创新。2003年政府引入了 “SingPass ID”,个人可以一站式登录访问政府所有在线服务。到今天,用户已经可以用SingPass 获取六十多个政府部门的在线服务(例如申报个税、申请政府祖屋、查询社保),无需创建多个账户。同时,企业登记注册流程也全面自动化,一般情况下完成整个在线操作仅需15分钟,注册审批通过后会自动通知用户,企业主无需进行进度查询。

政府在数字化的进程中,也在逐步提升适应外部变化的能力,更加关注用户体验。例如人力资源部在2014年开始新建的外来家政佣工签证管理系统中,引入了用户体验评估机制。新系统是所有政府机构中第一次使用敏捷开发和项目管理方法的系统,做到了快速上线、持续交付、收集反馈以及持续改进。上线后,呼叫中心的客服电话减少了30%,用户不通过中介的自服务比率提升了15%,72%的参与反馈的用户为使用体验打了满分。该系统也在2015和2016年获得多个政府奖项。

在ThoughtWorks新加坡分公司工作的一年半里,接触到不少负责数字化项目的新加坡政府官员,其中不乏打破常规、承担风险、积极创新的领导人。我们经常在一些创新与科技会议上看到他们的身影,在谈话中听到他们对用户体验的关注,看到他们在组织中尝试新的方法和技术,并探讨组织变革和转型的路径以适应未来发展。GovTech(政府科技部)在从前身的IDA(信息发展局)分离转型后,更是将 “Agile, Bold, Collaborative”(敏捷、无畏、协作) 定为新组织的三大核心价值。

在科技迅速发展、用户期望值不断提高的今天,庞大的政府系统要完全跟上时代的脚步,也并非易事。李显龙总理在2017年2月24日的一个创投峰会上提到,“虽然我们在2014年末启动了 ‘智慧国家’ 计划,但其进展低于我们的期望。”

为了促进 “智慧国家” 计划的快速实施,2017年5月1日起,“智慧国家及数字化政府团队” 被纳入总理办公室直属管理。

但是,我们也观察到,政府部门以及国有企业的采购流程还未能较好的支持顶层期望的科技创新。例如,对定制化IT系统,采购方常常用超过半年的时间进行预先需求设计,以固定价格方式进行招标,再用几个月的时间来评选、确定服务商。从想法的产生,到落地实现,少则一年,多则数年,这与当前科技发展的速度形成强烈反差。此外,在固定价格合同方式下,服务商为了降低风险和成本,通常以拒绝变化、固定架构的方式来建造政务IT系统,减少了快速尝试、持续改进的机会,且为系统未来的升级改造埋下高额技术债务。

未来的挑战

新加坡这个城市之国仅有土地718平方公里,常住人口540万,94%居住于高层公寓,其中82%为政府祖屋。在这个人口密集且对政府服务高度依赖的国家,高效和智能的城市交通、良好的居住环境和医疗服务与这个国家的全球竞争力以及民众生活质量密不可分。

由于国土和人口数量较小,如果纯粹焦距于国内市场,提供数字化服务的企业发展空间非常有限。加之数字化项目通常投资巨大,对于本国特定、较难在别国直接复制的数字化服务,营利模式不明朗,对初创企业、私营企业及投资者没有足够吸引力。最简单的对比是,中国的巨大市场能够不断地吸引私营、初创企业和投资者开拓各种领域的科技创新和数字化服务。而新加坡特殊的地域特点进一步增大了政府提供多领域数字化服务的压力。

新加坡也是全球老龄化趋势最严重的国家之一。2012年60岁以上人口占15%,到2050年,60岁以上人口将超过目前老龄化最严重的日本,达到38%。从国际趋势看,为了提升生活质量和寿命,养老方式正在逐渐从集中化转向社区化。如何让庞大的老龄团体在社区内舒适、安全养老也成为这个国家未来发展的巨大挑战。

智慧国家计划

智慧国家计划旨在使用科技为民众创造更加舒适且充满意义的生活。通过利用互联网/物联网、数据分析和通讯技术,提升民众生活质量、增加商业机会、促进各种族团结。

智慧国家计划包括五大重点领域的数字化工程:交通、居住环境、商业效率、医疗和养老、以及政府服务。整个计划并不全部依赖于政府的工程建设。政府通过提供必要的基础设施、测试环境、海量数据、培训津贴、科研支持以及各种优惠政策来积极鼓励个人、初创企业以及成熟企业创新和实施技术方案,与政府各部门一同打造新加坡的智慧未来。

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

智能时代的政府数字化

世界经济论坛创始人兼执行主席克劳斯.史瓦布先生于2016年初出版了书籍《第四次工业革命》。这一次革命的核心进程是智能化和数字化,而且正以前所未有的态势和速度向我们席卷而来。一系列的新兴科技包括机器人技术、人工智能、纳米技术、量子计算机、生物科技、物联网、3D打印和自动驾驶,已经开始滲入和影响我们的经济和社会。这意味着政府数字化也必须在技术方案的选择上跟随时代的步伐。

麦肯锡2016年11月发表的一篇关于全球政府数字化的洞见中指出,数字化政府通常始于利用先进的科技重建四个核心能力:

  1. 数字化服务
  2. 自动化工作流程
  3. 基于数据的决策
  4. 通过与企业和个人进行数据共享进行创新

而实现这些核心能力的数字化建设,又需要四大运营和管理引擎来保障,包括:

  1. 具有远见和深度的发展战略
  2. 支持战略实施的组织架构
  3. 领导力/科技人才/组织文化
  4. 先进的技术和开发方法

谈到先进的技术和开发方法,就不得不提到新加坡GovTech下属的GDS(政府数字化开发团队)。这个组织的管理方式很像一家创业公司,各团队努力使用先进的技术、工具、开发实践以及敏捷项目管理方法完成产品的设计和开发。GDS里也有不少实验和原型项目,例如无人机、物联网、3D打印等技术,用于验证创新解决方案。

结语

从SingPass ID一站式访问政府服务,企业注册流程自动化,利用数据分析进行交通管理决策,政府数据共享以及创新验证这些事实中,我们能看出新加坡政府在数字化各项核心能力建设方面都取得了显著的成就。从国家总理,高级官员,到科技项目负责人,均能看到运营管理引擎持续改进的信息动态和行动。在这些核心能力的建设和组织/文化演进过程中,政府也提供给了科技企业和个人大量的机会,让我们对这个国家的数字化未来有更多期待。

新加坡政府的数字化旅程仍然在继续,新的问题和挑战也会不断出现。但其三十年来走过的数字化之路,以及其对政府效率和国家经济提供的价值,值得任何政府和企业深思和学习。


参考信息:

Department of Statistics Singapore :http://www.singstat.gov.sg/

Ease of doing business ranking – The World Bank:http://www.doingbusiness.org/~/media/WBG/DoingBusiness/Documents/Annual-Reports/English/DB17-Full-Report.pdf

Transforming government through digitization – Mckinsey&Company:http://www.mckinsey.com/industries/public-sector/our-insights/transforming-government-through-digitization

Singapore eGov Masterplans:https://www.tech.gov.sg/About-Us/Corporate-Publications/eGov-Masterplan

GovTech’s journey:https://www.tech.gov.sg/About-Us/GovTech-Journey

MoM won an award:https://www.tech.gov.sg/technews/digitalgov/2016/10/winning-gov-innovation

GovTech key values:https://govinsider.asia/innovation/agile-bold-and-collaborative-are-key-govtech-values-ceo/

Prime Minister Lee Hsien Loong’s comments on the progress of the Smart Nation Program:http://www.straitstimes.com/singapore/singapore-can-do-much-more-when-it-comes-to-adopting-new-technology-pm-lee

Singapore Smart Nation Program:https://www.smartnation.sg/about-smart-nation https://cmp.smu.edu.sg/ami/article/20161108/singapore%E2%80%99s-vision-smart-nation

https://www.tech.gov.sg/Media-Room/Media-Releases/2017/03/Formation-of-the-Smart-Nation-and-Digital-Government-Group-in-the-Prime-Ministers-office

Aging problem in Singapore:http://brandinsider.straitstimes.com/hitachi/solutions-for-an-ageing-population/

The 4th industrial revolution:https://www.weforum.org/about/the-fourth-industrial-revolution-by-klaus-schwab

Government Digital Service Team:https://www.techinasia.com/ida-hive-govtech-singapore

Open data:https://www.smartnation.sg/initiatives/Mobility/open-data-and-analytics-for-urban-transportation

Share

十年

初识

第一次听说ThoughtWorks是在2004年平安夜的朋友聚会,正在和L公司西安办公室的小林聊天。远远地,好友Lims带着一位高个儿、着西装的男士走过来。小林碰了碰我,“这人是ThoughtWorks的”,“什么公司?”我问,小林又大声重复了一遍。“你好,我是郭晓,ThoughtWorks的,总部在芝加哥,我们正在西安筹建中国分公司”。Lims告诉我L公司和ThoughtWorks在合作一个软件园数字园区的项目。他跟郭晓提到我在一家大型ERP软件公司的西北区负责人力资源管理,在西安认识的人多,以后有要帮忙的,就直接联系我。

终于知道这个公司名字怎么写了,百度上的第一条便是Martin Fowler的介绍,他的著作以及他参与撰写的敏捷宣言,论坛中为数不多的几个贴子和回复中充满了对这位技术大牛的仰慕。但对ThoughtWorks的介绍却很少,中文网页上只有寥寥几条。完全没想到,这家公司跟完全没有IT技术背景的我能有什么缘分。那以后,郭晓打过几次电话,如何面试销售人员,哪儿的饭馆招待人不错云云。

要么沉下去,要么学会游泳

ThoughtWorks人才甄选中对文化适应性和价值观很看重,尤其当他们计划招聘中国区第一位人力资源管理人员的时候。该角色事关公司文化建设和价值观传播,这两项自然成了面试评估中丝毫不能妥协的维度。面试了若干应聘者、猎头推荐和我自己推荐的候选人,仍未找到合适人选。对ThoughtWorks的文化和扁平式管理,我是有很多好奇心的,于是试探性地向郭晓表达了我对这个职位的兴趣。郭晓已经认识我多时,除了英文,其他两项都没有担心。最终,他们决定在价值观、人力资源管理经验和英文技能三个主要维度中,降低对英文的要求,向我发出邀请。于是几乎一句英文都不会说的我就在2005年9月13日加入TW,开始承担People Lead(人力资源总监)角色,成了中国区本地招聘的第七位员工。

被Sid Pinney(时任中国区总经理)和郭晓(时任中国区副总)面试时的窘境一辈子也忘不掉。郭晓在尝试着逼我挤出了两三句英文后,还是不得不当了翻译。期间没有聊太多HR相关话题,就记得Sid听到我在第一家公司八年的工作经历后说,我保证你在ThoughtWorks会超过八年。Sid对我的印象是,尽管不太会说英文,但一点也不象大多数中国人那么shy,于是他愉快地对我的加入表示欢迎。

Sid说,以后他会回美国,我的工作主要向郭晓汇报,所以不用太担心英文。Too young too naive,入职第一天就面临阅读和回复英文邮件的尴尬。Sid还经常直接找我谈话,实在聊不下去了,就上Yahoo IM打字,有时两个人坐在办公桌对面却打字沟通的样子真心滑稽。英文写作以及口语这两项的快速通关过程相关惨烈。最初的几个月里,每天晚上一两点钟入睡都是常态。把一本商务用语背的烂熟,动画片《Monster Inc》和《Shrek》也看了无数遍。

入职第一天,刚设置好电脑,Sid和郭晓就迫不及待地把手上的HR工作扔过来,一份在其他公司看起来是机密的全员薪资表径直交给我处理,出人意料的没有考查期。Lims说,外企就是这样,招你进来做这个职位,就默认你是胜任的。

有在第一家公司时行政、财务、运营、信息化管理等各岗位的锻炼,以及随后第二家公司的HR工作经验积累,使得我在ThoughtWorks的People Lead工作能很快进入角色。入职第二周,开始准备校园招聘宣传和面试。第一次宣讲,相当忐忑,都不敢在最后环节设计Q&A,担心给出错误的答案,抹黑TW形象。

大多数情况下,办公室里只有负责行政的陈慧和我两个人,加上刚入职暂时没项目的几位程序员,我们一起做招聘。郭晓偶尔回到办公室,解答一些问题,工作几乎没人指导。随后,Sid又在我的职责里加入了优化行政和财务流程、提升效率的工作。那时候,除了写代码,我什么都做。没有培训、没人辅导、工作方向不清晰、克服各种困难的这段经历,常常让我想起这么一句话:“要么选择沉下去淹死,要么选择学会游泳”

招聘难度随着公司的发展而不断增大,品牌不够响亮,又地处西安,工作遇到了瓶颈,不时面临着招不来人就没办法接项目的僵局。直到两位具有猎头背景的招聘专员入职,招聘速度才逐渐跟上了业务的发展。但随之而来的,人力资源管理难度也直线上升。没有现成套路,使用其他国家分公司的方法有水土不服的风险,以前任职公司的方法更不能照搬。只能一边做,一边摸索,在为中国区建立各种体系的同时,小心翼翼守护着我理解的ThoughtWorks文化和价值观。偏偏官方的文字描述只有三个词:“Attitude, Aptitude, Integrity”。加之TW组织结构扁平,官民平等,发挥空间较大,反而常常使得我在处理一些事情的原则上有些犯难。

只有多学习,多理解体会。在现场与项目上的同事们交流学习我们中国区既有的文化,在公司与来中国支援的外国同事沟通探讨他国TW管理的方法。两位老大也创造机会促进我跟其他国家的同事接触。2006年,参加了在芝加哥的Away Day;2007年,在英国担当了三个月的HR Manager角色。通过这一系列的交流学习,我加深了对TW多年来沉淀下来的文化的理解和运用。

转岗到底难不难

担任People Lead近三年时,中国区成员已过百,办公地也迁址到北京国华大厦。ThoughtWorks中国区很年轻,资深成员少,我有幸被选入到第一期全球领导力培养计划(Global Leadership Development Program)中,美国人Matt Simons是我的导师,他在TW任职多年,先后担任过业务分析师,印度区总经理,全球人力资源总监等职务 。Matt非常认真的辅导我,通过定期沟通,帮我完成优势分析、360度反馈、领导力发展计划,还联系他国资深成员提供指导,我受益匪浅。Matt建议,要想在ThoughtWorks有更大的发展空间,同时促进自己有更大的能力提升,就必须进入主营业务中,深入到客户业务往来的一线,所以可以尝试转岗Business Analyst(业务分析师),然后Project Manager(项目经理),再后Client Principal(客户管理总监)。这,完全出乎我的意料。有几位LD Program学员已经是CP了,而我要再发展几年才可能到CP,公司这么培养我,付出也太多了吧,况且我能不能胜任?Matt却不以为然,你要是成功做了CP,再加上已有的运营类角色经验,对于公司的业务发展会有更大的助益。随后我也跟郭晓谈了这个计划,他更是举双手赞成。在这个事业发展的岔路口,两位老大就这样帮我做了一个重大的选择。

转BA就要直面其带来的挑战、压力。放弃熟悉的People Lead角色,软件开发是白丁,从零学起,难度可想而知。 心里还有个小算盘,招聘新人接替People Lead职位,我万一失败也回不去原来的职位。中断了HR的工作经验积累,再找个好工作也不容易了…… 各种风险一闪而过。但这已经不是第一次,在前任职公司时就有两次换岗位后从零做起的经历。也许命中注定,闪念之间,这次也没有太多犹豫。

内部系统Jigsaw开发是我做BA的第一个项目,从Shadow资深BA亢江妹开始。再一次进入大部分私人时间都用来读书、学习的苦修模式。最焦虑的时候,完全不能集中精力。遂向老大申请休假来寻求暂时的逃避。老大回复,“休假与否,问题依然在那,不如直面”。我也想过撑不住了就离开ThoughtWorks,还为此杜撰了一个悲情的场景,已经卸任回美国的Sid出现在我面前,我叹了口气说:“对不起Sid,我做不到八年了,辜负你的期望了“。

放弃就等于承认自己是loser,心有不甘,决定再咬牙坚持一段时间。两个月后,原来的PM,BA都被安排到了别的项目,随即接过了BA和PM的全部工作。此时的我已经学会梳理需求,写用户故事,画mockup和管理发布计划,算是跃过了第一道门坎。八个月后,我加入到一个真正的客户项目(国际派遣业务相关软件)中做BA,后来也同时担任PM,应付高标准严要求的美国客户,在频繁的沟通、谈判中,逐步地有了对此项工作更专业、更明确的把握和掌控。

打第二份工

中国区成员过百后,信息被充分的上传下达开始变得困难。有人提议成立一个组织,作为桥梁,一方面听取广大ThoughtWorker的意见与建议,一方面做为一个额外的渠道,分享和解读来自老大以及TW Global的重要信息。

于是3C(China Consultant Council)诞生了,由当时各项目团队里主动性强,对TW文化、价值观高度认同的十几位成员组成。大家轮流负责,收集运营中遇到的问题、区分优先级、组织讨论、汇集意见和建议,并研究解决方案。通过这样的形式,我们这些人被纳入了中国区的管理体系中,毫无怨言地接受了8小时billable之外的第二份工。

中国区老大郭晓开始思考领导梯队的建设,3C则提供了一个绝好的实验田。于是他悄悄行动起来,每月布置2~3篇Harvard Business Review,McKinsey Insignt英文商业文章的阅读任务,让之前只关注技术和项目的这群人开始学习企业管理。成员当中有徐昊和熊节,两位据传看书快于吃书的大侠。而且熊节还不断写博客、发表文章,对读过的商业文章撰写评论。这种来自同伴的压力,使得原本不爱读书的我也养成了阅读习惯。加之要在项目上应对挑剔的客户,多数晚上和周末都在学习、工作。想着在这样一个斗志昂扬、蓬勃向上的公司里,能持续得到业务的锤炼和能力的提升,多花点儿的业余时间也值啦。也许,痛并快乐着吧!

把走出舒适区当成习惯

在舒适区待的时间长了,生产力会下降,因为没有了因期限和期望造成的不安,可能会心安理得,自然就没有成长了。必须迈开步子,走出去。

grow comfort zone

继西安有了两位兼职Office Principal(办公室负责人)几个月以后,北京公司的OP选择了肖然和我,当时我俩都在北京公司天字一号项目中忙的不可开交,本身工作已经饱和。但这些年来,待在拓展区、挑战焦虑区已经养成一种职业习惯。所以担子来了,也就接着了。2011年底任职,最初的10个月里,项目少,运营复杂度低,又有经验丰富的老大主导,没觉得有什么困难。随着业务结构复杂度增加,规模变大,老大的工作重心又转向全球,肖然和我在运营分公司的重担才真正显现出来。由于此时我俩都被客户项目缠身,遂商议由肖然多花精力在客户项目,而我则更多负责公司运营。

此前每年绩效评估时收集的反馈中总少不了“工作效率很高”这一条。但自从真正承担OP职责后,发现时间管理变低能了。不但工作量大,而且棘手的事情接踵而来。肖然离开公司以后(8个月后又重新加入),不但得把他负责的项目管理工作接过来,还要管理整个北京公司,日子更加艰难。硬把负责本地客户交付业务的施韵涛拉入伙,而他也早已分身乏术。我个人的技能不足、时间又严重短缺、再缺乏得力的人分担,把我推到焦虑区的火焰上反复炙烤。同时,自己负责的项目上,成员间沟通不畅、客户抱怨交付进度…… 公司里,项目人员安排出现了冲突,面试官意见不一致,坚持自我原则时把同事说哭了,有人要求特殊照顾,有人找我谈离职,TechOps团队被物业刁难…… 常常被各种难题压得喘不过气儿来。每天勉强控制着情绪,徘徊在崩溃的边缘。以至于有两三次跟老大谈话时,刚就一件事情被追问了几句,眼泪就夺眶而出。屋漏偏逢连阴雨,慢性胃炎、颈椎病也接连来袭。医生诊了诊脉,一边写药方一边说:“工作压力很大吧?吃药不解决根本问题,心情调节好,病才能好。”

2012年岁末的一天,从早到晚经历了十三件棘手的事情。晚8点,结束最后一个电话会议时,已经不想再说一句话。默默将那十三件事情写下来,放在电脑的桌面,起名叫”What a shitty day!”。安慰自己,下次再遇到困难时就看看这篇日记,只要能比这一天强一点点,就应该开心。当然了,万一真的比这天还糟,那就再写一篇把它替换掉吧。

不记得在焦虑区待了多久,大概几个月之后吧,不再每天工作到很晚,救火的事情也逐渐减少。转眼看看身边,有了一群能干的小伙伴,他们能自如地做好团队建设,处理好跟客户的关系,更多地为公司的发展做切身的考虑并认真的履行职责。终于又逐步回到了拓展区,开始有纪律地安排自己的时间。睡眠充足,精神抖擞。摸爬滚打中技能提升自不必说,关键是悟出了怎样从这类困境中走出来,如何从被动解决问题,到腾出脑力和精力去主导方向、规划。秘诀就是:不要一个人战斗,要培养出很多跟你一样强,甚至比你还强的同伴。很多时候,即使自己快被压垮了,仍然要鼓足精神去鼓励、推动其他人走出舒适区。

我辅导的Leader如果正在遭遇跟我当年一样精疲力尽的境遇,我就会分享这样的经验:越忙越累的时候越要培养接班人,这才是你从出困境的真正希望;想在技术或领导力上攀登新的高峰,也要培养接班人,这样放手时才够负责任。要识别多个培养对象,因为不是所有人最终都愿意承受拓展区和焦虑区带来的压力和挫折。不幸的是,强势风格也会产生负作用,有几位较资深的同事由于承受不了我的期望、鼓励、压力,甚至是逼迫和责备而选择了离开ThoughtWorks。

自信    勇气    坚韧

Sheryl Sandberg的《Lean In》对我最大的帮助有两个:假装自信,直到变得自信;指望每个人都能够喜欢你,将会阻碍到你的脚步。

自信分为两个方面,一方面来源于“Knowledge, Experience和Exposure”。想象你要与客户的十几位资深高管开会讲解方案,如果你从来没经历过这个场面,自然容易焦虑、不自信,见多识广是让自己提升底气和自信的不二法门。另一方面,谦逊也会导致不自信。在一个跨国公司里,你会发现与其他国家的同事相比,中国人过度的谦逊会妨碍你展示优势,同时也会错过你本可以得到的机会。所以,在一个机会来临的时候,即使当时的能力不足,只要是拼命跳起来就能摘到的果子,就要去争取,争取到了就要苦练,出色地完成任务。而在ThoughtWorks这样一个结构扁平、发展空间大、快速成长的组织里,最不缺的就是机会,就看你够不够主动。

2013年5月,在公司的一次新兴市场领导力培养计划(EELD)见面会议中,每个人用五分钟分享过去半年以来在领导力发展的历程。我选了三个关键词:Confidence, Courage, Resilience(自信、勇气、坚韧),没有什么比这三个词更能描述我过去半年的心路历程。

自信问题容易克服,而勇气和坚韧却是知易行难。承担领导角色,在拥有影响力的同时,也伴随着损耗人品的事情发生。进行艰难的绩效改进谈话,辞退绩效改进失败的伙伴,推动别人走出舒适区,做出让部分人不开心的决定。也有在沟通工作任务时,失去耐心爆出责骂之言。感知到自己开始变得不被很多同事喜欢,我的心情低落到谷底。在信任的人面前哭泣发泄了几次后,我开始隐藏自己,把艰难的事情都推给韵涛和郭晓。2013年3月,郭晓升任全球CEO,中国区有了胡凯、张松两位新的总经理,我转向Head of China Operations的角色,负责中国区运营效率,顺理成章的由一线躲到幕后。几位领导在面对艰难和阻力时做决策、沟通、推动执力的勇气时时刺激着我,但我依旧低调行事,小心翼翼不敢发表不同意见,晃晃悠悠在这个角色上找不到方向。为了让自己显得还有价值,把更多精力转向客户关系管理,接过了一个大客户的CP职责,绕了好大的弯子,给我四年前制定的领导力发展计划划了个句号。

2014年9月的一天,在美国拜访客户,跟在客户现场工作的于晓强聊天,他问我:“你不像以前敢做敢说了,为什么不做回自己?” 我惊讶地盯着他,不知该说什么。晓强是那种很有主意、从不妥协于权威的典型技术大牛,曾经坚定地以为强哥也属于讨厌我的那群人中的一员。这次意外的谈话移走了我心里的最后一块阴霾。是啊,我需要拿出勇气,恢复斗志,做正确的事,干嘛过于在意是否被喜欢。

Head of Operations角色只在北美和印度两个区域有先例,而各国家市场和业务重点各有差别,几乎无法参考。好处是发挥空间非常大,坏处是你可能不知道应该做什么,优先级是什么,什么才是这个角色的价值。但这一次没有再进入焦虑区,因为舒适区已经足够大,所有的挑战都只落在拓展区。

2005~2015。

整整十年,停留不是因为拒绝变化,而是因为在这里每天都不同。

整整十年,伴随着中国区从区区几名成员,到如今600多人的豪华团队,我们同心协力、栉风沐雨,披荆斩棘,一路走来。

十年里,开心和顺利的日子真的很多,也把挫折赐予的成长和拼搏赢得的成果作为回忆深深的藏在心底。

谨以此文来感谢ThoughtWorks带给我精彩的十年。

十年后的今天再会!TW不老,我亦年轻。

 

Share

实战:持续交付中的业务分析

在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中,软件的开发和交付是迭代式进行的。在这样的项目团队中,BA(业务分析师)通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下,从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。

那么在这样的敏捷项目中,BA如何能够适应这种交付模式,完成高质量的业务分析,协同团队为客户交付高价值的软件呢?

项目背景

ABC公司是一家知名的国际性会计师事务所,业务规模庞大,分支机构遍布全球170多个国家。

ThoughtWorks受邀对其“全球派遣服务(International Assignment Service)”业务部门提供IT解决方案,以及软件系统的开发。该系统包括收集其客户的全球派遣雇员的报税数据,以及管理ABC公司税务咨询师对这些数据的进行审核、汇算和出具报告的业务流程;逐步替换其目前已远远不能满足业务和性能需求的遗留系统。

该系统主要有两类用户,一类是ABC公司客户方被派往不同国家工作的雇员(以下简称Mary),这些雇员使用该系统填入报税需要的数据。另一类用户是ABC公司的税务咨询师(以下简称Kim),负责审核、处理Mary提交的数据。

BA在该项目中面临的主要挑战

  • 该项目为分布式开发,ABC公司的决策方在美国,而ThoughtWorks的开发团队在中国,沟通反馈周期有时较长。
  • 由于ABC公司对用户体验的重视,需要频繁交付软件,以便收集用户反馈并及时调整解决方案和后续开发计划。这大大缩短了从收集需求、开始分析到进入开发的周期,增加了分析中出现缺陷的风险。
  • 当开发过程中发现问题时,无法马上与客户取得沟通,开发进度可能会受到影响。

识别业务价值

业务分析的重要性在于首先做正确的事情。理解客户的业务,关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。

而我们面临的困难是,客户提出的需求,往往都是直接的软件功能,而不是需要解决的业务问题。如果BA只专注于针对客户需要的功能进行系统分析,就丧失了帮助客户优化解决方案以及改进业务流程的机会。

如何寻找业务价值?

以敏捷开发方法中的用户故事为例,找出客户要解决的业务问题的一个简单办法是,用以下方式概括每个用户故事的内容:

As…(角色),I want to…(完成什么样的功能),So that…(解决什么问题,带来什么价值)

“So that…”说明了该故事的业务价值,即要解决的业务问题。准确的寻找业务价值将有利于我们设计出最适合的“I want to”,这很可能优于客户直接提出的功能要求。

需要注意的是,不要把解决方案或功能当成该用户故事的价值。以ABC公司业务系统中的一个用户故事为例,BA对该需求业务价值的了解程度将直接影响到解决方案的优劣。

作为(As…) 我想要(I want to…) 以便(So that…) 是否阐明了价值?
Mary 即时浏览我的行程统计数据 了解我在各个国家或地区停留的时间以及从事的活动
Mary 即时浏览我的行程统计数据 我可以迅速地检查我所输入的在各国家或地区停留时间及从事活动的数据是否正确(以保证我可以依照法律要求提交准确的报税数据)

在该用户故事的两种不同表述中,由于第一种表述只说明了需要的功能,没有说明业务价值,在功能设计时,我们可能会将“行程统计数据”的内容设计的过于详细而造成浪费,使用户不明白此功能的意图。而第二种表述的业务目标就非常明确,可以帮助我们更加容易地设计出适合的解决方案。

此外,BA在了解客户的业务问题时,最好请客户提供一些真实案例/场景来证实其观点并加深自己的理解。

避免分析错误

在实际工作中,我们发现有以下两个方面的分析工作容易被BA忽略,而做出错误的决定。

    1. 客户要求实现某些现有业务流程或遗留系统的功能

例如,客户需求的功能,是当前遗留系统中已经使用多年、且未收到过任何抱怨的功能。所以客户和BA往往认为这个功能是合理的,忽略了深入的分析和思考。而这种思考不全面而做出的决定可能会与可以预见的新功能产生冲突。

在ABC公司的遗留系统中,用来收集报税数据的问卷内容是通过excel表来维护的,而Mary在前台也是通过下载excel问卷,填写完毕后再上传。

在新开发的系统中,问卷被改为在线方式,并辅助以其他必要功能提升Mary的用户体验和满意度。但由于客户方的员工都是财务背景出身,非常喜欢使用excel表,而之前用excel表维护问卷内容也被证明是非常有效的,所以客户坚持在新系统中延用这种方式。经过仔细的分析,我们发现在针对提高Mary用户体验的新功能上线后,使用excel表维护问卷内容将大大增加维护的工作量及错误率,而这与项目的相关目标背道而驰。ThoughtWorks在列举了问题的细节后,说服客户采用了新的解决方案。

    1. 客户要求利用新的IT系统改变当前的业务流程

客户发现目前的业务流程有不合理的地方,希望在新的IT系统里直接改变这些流程。如果不经过仔细的分析,这种做法可能会很危险,业务流程的盲目改变可能会对一部分用户造成麻烦,为客户实施该软件形成强大阻力。那么了解清楚目前这些流程存在的价值和原因事关重要,从而可以帮助我们为客户提供科学的、逐步优化其流程的IT解决方案。

在ABC公司的业务流程中,Kim和Mary之间的一些交流是通过邮件来完成的。这里存在两个业务风险:1)Kim和Mary交流的重要信息被散落在各自的邮件里,系统无法记录,在遇到法律问题时,难以划分责任;2)Kim和Mary可能会使用邮件发送一些保密性较强的内容,如果发错,后果不堪设想。

在开发新系统时,客户要求我们增加了一个消息功能,使Kim和Mary之间的交流可以方便地在系统内部完成。该功能上线后,很好地化解了这两个业务风险,同时收到了Mary这类用户的良好反馈。然而这对该会计师事务所在某些国家分支机构里的Kim这类用户的工作却带来了不小的影响。由于之前使用邮件系统,Kim可以将Mary的邮件转发给相关的同事,并利用邮件丰富的功能进行结果的跟踪。而新上线的消息功能达不到邮件的所有要求,所以增加了他们的工作难度。此外,由于Mary对这个功能的青睐,发送消息的数量远远超过了在使用遗留系统时发送邮件的数量,超过了客户想提高Mary的满意度而在短期内所能承受的代价。

在遇到以上问题时,我们与客户一同分析,提出了折中的解决方案,花费了较少的代价将消息系统和客户的邮件进行集成,同时帮助客户制定了对此项业务流程改进和配套IT解决方案的蓝图。

理清需求优先级

在频繁上线的项目中,其中一个重要的实践是确定需求的优先级,使得重要的功能能够先被开发出来投入使用以便及时收集用户反馈。一般的做法是要求客户排好需求优先级,然后与项目相关成员一同制订迭代开发和上线计划。但由于客户决策方所处角色以及思维角度的局限性,对优先级的评定可能存在盲目。建议BA参照以下价值维度帮助客户对优先级进行评定。

从客户价值维度分析需求优先级

需求价值维度分析图

价值维度 说明
愿景目标 该功能点是否契合项目的愿景和业务目标?与项目目标的契合程度越高者优先级越高
时间限制 客户的业务是否有一定的时间表?如果该功能点必须在某时间点前投入使用,则该需求必须被排入相应时间的发布计划中
市场卖点 该功能点是否是吸引特定目标用户的卖点?如果客户的资金存在问题或者需要市场的快速认可,则可以考虑将该需求列为高优先级
有无替代方案 该功能点有无方便的替代方案?如果有简单易行的替代方案,则该需求的优先级较低
客户内部政治因素 该功能点是否存在客户内部的政治因素?例如某功能只对小部分用户提供价值,但会决定客户内部某个重要组织对这个项目的投资和评价,则可以考虑将该需求列为高优先级
投资收益 该功能点的开发成本和客户所能获得的收益是否匹配?例如客户某工作流程浪费了一个小组人员大量时间,但对其他部门或工作环节无影响。如果开发相应的软件功能造成的投入大于客户在一定时期内可以节省的资金,则该需求的优先级较低
技术依赖性 其他需求是否依赖于该功能点?如果依赖于这个功能点的需求优先级高,那么该功能的优先级应更高

技术风险对优先级的影响

除了来自客户方面的决定因素,我们还应考虑技术实现方面的影响。如果一些技术风险较高的功能可以先进入开发阶段,则问题会尽早地被暴露。开发人员在项目早期解决这些问题会有利于开发成本的节约。所以除以上客户价值维度外,应再参考以下矩阵来权衡需求的优先级。

需求优先级矩阵

客户价值维度和需求优先级矩阵并不是优先级高低的计算器,而是与客户以及团队沟通交流的工具。不同项目的影响维度也会有所不同。由于各项因素的复杂性,客户价值维度和技术风险因素需综合考虑,不可以权重来计算。BA可以与客户对以上因素的内容达成一致,使得客户在评定需求优先级时可以快速、准确地做出判断。同时,通过对价值维度的分析,我们将有机会清晰地了解到功能优先级高或低的原因,以便我们能够准确地编制项目开发和上线计划,并合理地划分用户故事范围。

借助价值维度分析,管理客户期望值

有些客户的决策人可能会依据自己的喜好划分优先级,这对于项目能够按目标成功交付造成一定的风险。此外,客户在功能的设计和验收阶段也容易对单个功能追求完美,造成额外工作量,增加项目范围。而这部分额外工作可能并不合理或者价值较低。长期如此,团队在开发过程中将逐渐偏离项目目标。如果能借助优先级维度对这些额外需求进行分析,则可以提供更有说服力的依据,帮助客户做出正确决定,达成BA和项目经理对客户期望值的有效管理,从而降低交付风险。

发挥团队其他成员在业务分析中的作用

在频繁交付的项目中,如果BA独自承担业务分析工作,难免会出现疏漏。ThoughtWorks曾与ABC公司的IT部门合作完成其业务系统的一些集成工作。在合作过程中发现,ABC公司IT部门的开发人员在业务分析中参与度很低,由此造成了如下问题:

  1. BA需要写大量需求文档,故从需求分析到软件交付的周期较长
  2. 设计缺陷的发现滞后
  3. 在需要频繁交付的情况下,解决方案质量较差,方案优化能力较弱

而ThoughtWorks的开发人员由于在业务分析中的参与度较高,则有效地避免了以上问题。

开发人员如何参与分析

开发人员是软件功能的实现人员,对方案的实现工作量有较准确的估计。在明确项目目标或业务问题后,BA如果能够和开发人员一同分析解决方案,将更有效地为客户找到兼顾成本和效果的方案。

在收集到客户需求后,BA可根据业务价值对需求进行分析,判断客户提出的功能或解决方案是否能很好地满足该业务价值或要解决的业务问题;或者按照自己的理解设计出满足该业务价值的功能或解决方案。

完成上述工作之后,BA应与开发人员就需求和业务价值进行充分沟通,验证功能实现的可行性,同时积极探寻更优方法。如果开发人员提出符合业务价值的不同方案,BA则可以要求开发人员提供一些关于开发工作量、方案优劣、技术风险方面的比较数据,从而帮助自己有效地与客户沟通并挑选最佳方案。甚至可以根据分析结果帮助客户调整该需求的优先级。对于技术难度和风险较高的功能点,建议邀请资深开发人员参与讨论。

与开发人员沟通中遇到的挑战与解决方法

由于上述方法需要与开发人员大量沟通,有些BA在应用以上实践时也遇到了以下挑战。

    1. 开发人员缺少参与业务分析的热情

在ThoughtWorks,大多数开发人员都喜欢积极思考、主动为业务分析提供帮助,大大减少了需求分析上的漏洞。然而在ABC公司的IT部门中,开发人员很少主动为业务分析出谋划策,尤其是团队中资历较浅的成员,甚至不愿意参与解决方案的讨论。团队成员的优势没有得到充分发挥,开发人员只管按需求埋头苦干,结果功能和解决方案的问题往往在测试或者验收阶段才暴露出来,不可避免地造成了浪费。

站在开发人员成长的角度,从ThoughtWorks实践来看,积极地理解业务、思考解决方案能够更快地提高技术能力。故此BA可以找出一些实际案例,协同项目经理与团队各成员进行沟通,鼓励大家积极参与业务分析,逐步形成开发人员与BA协作的良好氛围。

    1. 开发人员容易就客户需求或解决方案产生争论

开发人员在积极参于分析的过程中,有时会对软件功能的价值吹毛求疵,在细节上与BA产生较多争论,使BA在应付开发人员的问题以及与客户求证答案之间疲于奔命。

解决此类问题,可采取以下方法:

  • BA在收集需求时,尽可能充分地了解客户要解决的业务问题,以便能够快速回答开发人员的问题
  • 面对开发人员对解决方案的质疑时,应保持良好的心态,清楚地了解开发人员顾虑的问题和原因
  • 如果自己掌握的信息确实不能证明现行方案的合理性时,协同开发人员,找到更优方案并与现行方案进行优缺点比较
  • 将新旧方案与客户沟通,则可快速帮助客户做出判断

不要忽略测试人员在业务分析中的贡献

由于测试人员所处角度和对细节的关注,往往可以发现一些功能细节的设计漏洞。所以在用户故事进入开发前,BA与质量保证人员对相关业务价值进行充分沟通,会在功能进入开发之前为BA创造更正设计缺陷的机会。

做为质量保证人员,如果充分了解功能背后的业务价值,相对于只了解功能需求,将可以写出更加完善的测试用例,提高测试覆盖率。这会为交付高质量的软件把好最后一道关。

结语

业务分析是困难的,特别是我们面对未知领域的时候。如果只是简单地按照客户的具体需求进行软件开发,那么我们交付给客户的价值将非常有限。然而识别业务价值、帮助客户分析需求优先级、保障团队协作,将有效提升团队对软件的设计能力,解决客户真正的业务问题,交付更大价值。

作为一名业务分析人员,当您在尝试以上实践时,可能会发现自己对客户业务的理解变得更加深刻。在与客户的沟通中,也能够更加容易地提出有价值的问题以及建议,从而提升客户对项目团队的信任,为成功交付项目打下良好基础。

*注:“客户价值维度”的概念由ThoughtWorks咨询师李光磊提出。在此对李光磊表示感谢。


Share