好拳法很重要,但会出招更重要

  做软件开发的圈里流传着这样一句话:刚进项目的时候,每个开发人员都想把项目树立成一座丰碑,但做着、做着却发现那是一座墓碑。在敏捷开发日益盛行的今天,到底应该如何推行企业级的敏捷开发?广联达软件股份有限公司(以下简称广联达)推行敏捷开发的故事,告诉我们丰碑和墓碑往往就在一线之间。而老板支持、员工买账、适时分步变革、沟通与激励配合则是跨越成败交界线的关键要素。

  加班似华为合唱叶满江红曳广联达是一家致力于建筑信息化的软件公司,成立于1998 年,聚焦于行业客户,经过十多年发展,产品的种类和数量从单一的预算软件发展到工程造价管理整体解决方案、工程项目管理整体解决方案、招投标管理整体解决方案、教育培训四大业务的30多个。

  2008年,全球遭遇国际金融危机的时候,广联达的年产值2 亿多元,有3条产品线(2条工具软件、1条管理软件),4 个主要产品,有28万多使用者,有160名研发人员。

  “那时,我们产品的BUG比较多,稳定周期相当长,一般正式发布的产品的稳定周期为两到三个月。产品开发完了,测试人员却不敢懈怠,得不断测试,不然不敢交付用户。而且,需求变化快,产品发布后,马上面临修改。答应客户的产品交付时间一推再推。公司第一次实施IPD(集成产品开发方法)后,没有收到明显的效果,大家对开发方法不再有信心,研发能力已经无法支撑公司去把握新的市场机会。我们的程序员很难有休息的时候,加班强度非常大。”广联达研发副总裁卢旭东向记者回忆说。

  即使程序员满负荷地加班加点,广联达当时的产品发版情况还是很糟糕。“当年我负责一个产品推迟了一年才上市!这给公司经营带来的影响是难以想象的。”因为不能保证在可预知的时间内发版,研发部和开发部的冲突非常激烈,当时研发部承受着非常大的压力,卢旭东笑称自己现在稀松的头发就是当时严重掉发所导致的。心情有多悲壮?卢旭东回忆,年底公司年会上他们项目组表演的节目就是合唱《满江红》,唱到一半项目经理就哭了。

  “当时我们能承受的压力已经到了极限。普通的激励已经不起作用了,开发的兄弟跟我说‘让我睡觉就行了’。可想而知,当时的环境多么迫切地要求我们必须做出改变。”

  但到了2010年,广联达的这种情况却发生了翻天覆地的变化:公司5月在深交所成功上市,预计年产值4 亿多元,主要有四条产品线、7个主要产品,种类涵盖管理类、工具类、互联网类,有33万使用者、280个研发人员,产品的发布周期稳定,能全面满足市场营销计划。“从2009年开始,我们全面按100%计划交付,并且有的工具类产品甚至做到了提前交付,甚至还有27 个研究、孵化类产品项目积极探寻市场机会。”是什么让广联达的软件研发发生逆转?

  答案就是敏捷开发。

  “敏捷不仅在产品研发管理中实施,其核心价值观更进入了公司日常管理的很多环节包括产品孵化、流程改进等。”卢旭东说。

  关键是定位其他都是浮云

  推行敏捷开发的企业很多,但成功的却寥寥。老板支持、员工买账是成功推行敏捷开发的重要前提,广联达是怎样做到的呢?是如何说服所有人愿意“冒险”变法的呢?“目标和定位是最关键的,其他都是浮云。出发点不同,想的办法就是不一样。我们并没有盲目地去学习、推行敏捷,而是先研究敏捷与所有人的关系。”卢旭东说,“我们用市场营销的思路,认真研究了对我们的最终客户(软件用户)公司高管、产品线人员(研发人员)而言,推行敏捷对他们到底意味着什么,他们会得到什么、要付出什么。”

  敏捷推进小组分析,最终客户大多不愿意参与产品的研发,只关心产品能否按时按量交付,认为提供高质量的产品是广联达的份内事;公司管理者关注的是公司的整体运营,如何开源、节流,如何实现企业运营高效率,但比比皆是的失败案例也让他们对推行敏捷心有余悸;产品线的人关注的是单个产品的准时交付,要推行新的工作和管理方法,他们担心会因为改变工作习惯而降低生产力,会产生抵触;而从研发管理的角度看,敏捷推进小组他们并没有实施敏捷、推进自动化测试的经验。

  “用户的需求不断地在变、一直在变,甚至快于开发,而且,用户自己也不清楚他要什么,那怎么办?我们必须快速满足客户,甚至牵引用户的需求。要做到如此,必须推行敏捷,具体的实施步骤是……”计算机专业出身,大学课程只有软件工程得了90分,其他课程只是及格的卢旭东用自己对敏捷的理解,用管理者听得懂的语言来解释敏捷———它是应对激烈竞争和快速需求变化的一种商业模式而非产品开发方法。

  “我们将所有利益相关者都视为客户,把敏捷推进小组定义为一家为客户提供敏捷咨询的商业公司,最高目标就是通过尽早和持续地交付有价值的软件来满足客户,总体规划、分步实施、持续交付价值。我们认为敏捷的核心思想就是精益,以保证目标和客户价值为基础,不断追求最佳的投入产出比,将优秀管理实践和开发实践相结合,以人为本,持续优化。”卢旭东说。清晰目标量化需求先试点

  看得懂燃烧图、会极限编程、知道

  Scrum,即便是敏捷开发的“大牛”,也并不意味着能带领整个团队做到企业级的敏捷开发。后者除了需要有对敏捷的正确认识,更重要的是有正确的实施方法和策略。广联达的一套做法是,先分析客户(所有利益相关者)的需求,并具体化、量化成可衡量的目标,慎重选择试点,通过学习和实验建立对敏捷的认知,通过测算投入产出比说服客户接受试点,推进小组全力参与,形成结果后进行总结并与客户确认价值,之后再进行小规模推广,同时持续对其他团队进行辐射影响(分享方法和经验),持续交付价值并持续与客户确认,巩固成果,最终促成客户产生自适应团队,进入持续优化的良性循环。

  “我们首先要清晰地了解客户的需求:最终用户要什么,公司想要什么,产品线想要什么,程序员要什么,把答案列清楚之后,再去跟他们确认,问这些是不是他们想要的,能不能量化。这样实施的目的和目标就很清楚了。”卢旭东说。

  广联达有一个负责持续推进公司开发方法改进的固定组织———PMO(项目管理办公室)。他们以PMO为基础组成3~5人的敏捷小组,选择一个小的项目为试点。“我们做第一个敏捷实验时,我和4 个部门经理,扎到一个项目里做了4 个多月,最后成功了。”卢旭东介绍说。

  广联达的企业文化很开放,敢于变革,这对他们推进敏捷开发非常有利。对于文化不那么开放的企业,卢旭东建议要首先保证项目成功,让最直接的客户受益,再跟公司说应该怎么推广敏捷,以点带面,发散辐射,激发不同产品线的员工的内在驱动力,从而产生规模效应。这个过程中数据、知识的积累很重要,方法要可传承、可复制、可持续优化,而且最重要的一点是坚持,坚持变革,坚持共赢。

  从变革与我何干到全部买账

  广联达是如何试点第一次敏捷,并推广变革的呢?广联达的方法是搞一次目标统一行动,用‘意义’来领导,让大家关注目的。

  现在做软件开发方法有很多派系,有人支持传统瀑布式,有人支持敏捷,有人支持CMMI,有人支持ISO9000。程序员都各有所好,各持己见。“我们的做法是用变革管理的思想来指导,关注目的,用“意义”来领导。首先,明确我们共同的目的是什么,哪种方法能实现目的。没有哪种方法是绝对最好的,互补的和适合的是最重要的。我们在公司内部做了关注目的和目标统一的活动,不管你是敏捷派、我是CMMI派,到公司就是一个派。不管是什么派,只要能融合在大平台下,解决问题就成。”

  还有一个重点是找到目的和敏捷的契合点,做真正需要的,而不是自己感兴趣的。有的程序员对敏捷非常热衷,对某些具体实践活动(比如自动化测试)非常感兴趣,只做他喜欢的,并不关注项目目的。卢旭东提醒说,这样的人和想法其实是非常危险的。因为企业推行敏捷不是某一个人的事,必须要结合客户需求做产生价值的事情,做支持企业成功运营的事情,才能让大家觉得靠谱,而不仅仅依靠某些人的个人兴趣做事。

  推行敏捷是个不断变革的过程。在变革管理方面,卢旭东深有体会。他认为只要按照正确的方法,任何变革都可以慢慢让所有人接受。广联达的实践将变革管理分成选择变革、准备变革、为成功变革做计划、实施变革以及测量和持续变革五个阶段。

  做变革准备有两个重点:一是消除“与我何干”的想法,让所有人都知道变革对自己的意味着什么;二是“买账”,让大家从心理上认可变革的风险和影响,达成共识———即使失败我们也认了,那就干吧!

  变革是一个过程。广联达有其推行变革的变革曲线模型。卢旭东提示,如果宣布变革之后,马上开始推动变革是不可行的,应该有一个沟通、倾听、反馈的过程,而且要挖掘被动变革者担心的问题,寻求共赢,逐渐把被动变革者从关注损失转变到考虑共赢的状态上。“这是一个很细微的人性的变化,但不关注它,你就可能失败得很惨。”

  对于这个环节中沟通的重要性,卢旭东用两个程序员做结队开发的实际例子向记者做了说明。小张和小丁两人做结队开发,但一天小丁却来和卢旭东哭诉说小张欺负他,说小张自己不写程序,天天让小丁写,小丁写完小张还挑刺。卢旭东找小张谈过之后发现了问题所在,原来小张有自我保护意识,认为小丁来跟他结队是领导对他有意见,派人来跟他学完之后要开掉他。听完,卢旭东哭笑不得,跟俩人说明了实际情况,解决了问题。虽然这是一个很小的例子,但却铁铮铮地说明了沟通的重要性和变革过程的复杂性。当人们从变革中得到收获,就会不再对抗,而是会主动、持续推进变革。

  关注客户价值袁辅以有效激励

  为了更好地推进敏捷,广联达还调整了激励方式,奖金的一部分放到年底来发,将外部客户满意度作为考核的主要指标,不再用传统的方式,用按时交付的指标拿开发来衡量需求、拿测试来衡量开发。这样整个开发团队的目标一致,才能发挥更大的合力。

  同时在推敏捷的伊始,广联达就定义了内部客户的概念,按照价值链排序,公司内部在自己后面的那个人就是自己的客户,因为他更靠近外部客户,那个人满意是自己重要的考核指标,所以这就使得所有人都主动去想客户为什么不满意。在外部目标统一的情况下,很容易形成一个很好的自适应团队。例如,开发人员为让自己的客户———测试人员满意,就会提前不断与做测试人员和做需求人沟通,提前进行很多开发阶段的质量风险控制活动,如此一来,很多BUG在开发阶段被修正,提高了整个开发过程的效率和质量,让产品开发更敏捷。

  “我们没有因为实施敏捷做任何的人员调整,还是原来那拨人,但敏捷小组的交付效率要比对比组高2.63%。原来我们做一轮回归测试需要10.5人天,而现在用自动测试加一些手工探索一天就可以快速回归15轮。”

  一天,卢旭东在跟董事长做一个专项工作的汇报时,出乎他的意料,董事长竟然对他说:“你应该再敏捷一点,尽早地迭代交付价值。”在广联达,敏捷已经逐步成为一种价值观,深入人心,越用越顺。
……
关注读览天下微信, 100万篇深度好文, 等你来看……
阅读完整内容请先登录:
帐户:
密码: