轻轻

国内IT公司病的有多重?技术圈交际花谈软件研发管理怪现状

在创业过程中,研发管理是很重要的内容。但是国内创业公司的研发管理却长期处于一种比较混乱的状态。国内创业公司的研发管理到底出了什么问题?技术人攻略的Gracia采访了素有“技术圈交际花兼娱记”称号的程显峰。从程显峰的口中,我们可以了解到国内创业公司在研发管理上的各种怪现象。

程显峰:@程显峰-Mars,蓝海讯通COO,MongoDB中文社区发起人,曾任积木盒子技术副总,Admaster首席布道师,混迹于安全、广告、云计算、大数据、互联网金融等多个技术圈。

文/Gracia

“什么时候采访我?”在GitCafe北京分部的开幕活动上,显峰半开玩笑半认真地问我。认识显峰的时间不算短,总在各种技术大会与小会上频繁碰面。过去一年多,他的工作状态算不上“稳定”,这不,刚离开高大上的互联网金融,投身APM的伟大事业。真要采访,得先选出一个可行的话题切入角度,他引用《人件》里提到的“高科技幻觉”,从传统工程的角度谈了谈对IT研发管理的看法,于是采访主题顺利地定了下来。

这通吐槽显然憋了很久,不乏“这个行业充满了骗子与强盗”的激烈言辞。我有点被惊到,常看他以典型的东北式幽默与人调侃,并不知道他原来如此严肃。在北五环外的东升科技园,我们从下午两点半,一直聊到天黑,期间换了3个场地。末了,他叹到:“为什么好好做技术这么难!”

显峰无需借此博眼球、搏出位,公开发表这些话给他带来的潜在风险远大过收益,观点犀利自然会赢得一些赞同,也难免招致对号入座的无端恨意。在乌合之众汇聚成的网络空间,谩骂而非理性的讨论是更为常见的交流方式。虽然在文字上做了些处理,我仍然对其可能带来的争议无比担心。发给他确认,几乎没做大的修改,仅回了个:“整体很流畅,但细节上的文字还不够平滑。”看,真是个对品质要求很高的人。

这些细节暴露了他的始终如一,也让我更加理解显峰的选择,不安定的背后,自有他严格的价值坚守。如果有机会,显峰希望去教小孩写程序,热爱学习的人是真诚的,他喜欢和这样的人在一起。

技术人攻略:你从什么时候起开始对对研发管理感兴趣?

我是学工程出身,本科就读于哈工大航天工程与力学系,研究生是悉尼大学的航天专业,期间受到了严格的工程训练。传统航空业的研发和制造体系非常完整,拿造飞机举例,悉尼大学的本科生就完全可以组装出可供销售的飞机,因为整个生产过程非常严格,任何一个扳手都有编号,有详细的记录和流程,不可能搞错任何东西。

虽然专业选择了航天,我对编程却非常热爱。从小学就开始写程序,那时候家里没有电脑,每次上机需要走40分钟山路。研究生期间,独立完成了完整的有限元分析软件,算是我在科学计算领域的一次实践。

回国之后,我加入的第一家公司Antiy,很重视底层技术,产品做得非常成功,但研发管理做得并不好。我在那期间学了很多软件研发历史,但在研发体系建设上,还是留下了许多遗憾。随后加入做互联网广告监测的创业公司AdMaster,当时公司正在筹建,人员来源多种多样,研发管理问题比较突出。我的职位是专职敏捷教练,配合技术负责人做团队建设,开始更深入地思考研发管理。

刚进入IT这一行时我很难理解,为何在传统工程和制造领域很平常的事情,在IT领域却是需要商量和悬而未决的。可靠性在航天等领域早已解决得很好,为何软件行业却一直解决不了产品质量问题。后来看了不少管理的书,发现IT研发管理的许多思想都是从建筑业、制造业借鉴而来,例如快速迭代、精益管理等概念。

结合工作实践,我逐渐发现了研发管理问题的症结所在。研发能力是工作的综合体现,内功水平是关键,任督二脉打通了,练什么都很快,至于到底用哪个套路,是很轻松的一件事。举个例子,大家通常说要做“敏捷转型”,认为自己是从传统软件研发转型成敏捷,关于二者的争论也显得像是泾渭分明的两派,但实际上不是。难道传统软件就不做配置管理吗?难道敏捷就不做测试吗?这两派理论有八成是一样的,即便在软件工程教科书里,也同样有关于质量控制、配置管理、迭代等理论,如果很好地去执行,同样可以达到不错的效果。

为什么敏捷转型失败的案例很多,因为企业并不具备相应的内功,只想寻求解药,以为敏捷能有所帮助。实际上如果不打好基础,结果还是一样。具备这种内功的人,玩传统软件也会很好。航天、制造、金融行业并不过分强调敏捷,当然敏捷里的好东西,他们也能非常快地去借鉴。《精益软件开发艺术》这本书的作者来自波音公司,他们将其在制造上的经验应用于研发,对软件的驾驭能力相当高。

强调时髦的概念,对研发帮助并不大。比如知道了TDD测试驱动开发,对团队帮助有多大呢?TDD想执行好,要求对测试理论有深入理解,但大部分国内开发团队不仅不具备很高的测试水平,连测试是什么,如何测都不知道。这种情况下去推广TDD是没有意义的。

技术人攻略:根据你的观察,国内研发管理有哪些常见问题?


我观察到国内研发管理主要的问题有几个:第一是过于强调个性,缺乏共同价值观;第二是内功差,不重视软件质量;第三是很多从业人员眼界狭窄,拿无知当个性;第四是对技术缺乏敬畏之心;第五是整体气氛浮躁,擅长炒作概念而非脚踏实地做事。

IT这一行太推崇个性,过于强调创新,强调极客,而对于共同价值的坚守非常少。传统工程领域里,大家都遵照明确的规范和标准做事。软件行业的国家标准很落后,大家也都不执行,几乎每个公司都会自定义一套方法和流程,大家各说各话。个性的东西太多,达成共识的东西太少,导致软件行业的人很难树立共同价值观,以及清晰的研发过程。

我做软件咨询的时候发现,不少合作多年的团队,都未能在基本价值观上达成一致。例如自家产品到底能解决客户哪些问题,10个人能给出8个答案。我认为研发管理首先要解决的问题,是形成一个团队,这就要求大家必须有足够多共性。想要塑造有战斗力的团队,需要模仿军队管理,大家穿一样的衣服,迈一样的步子,用同样的方式使用工具,减少不必要的浪费和沟通。

建立共性的关键之一,是要对代码质量树立共同的认可规范。好代码必须干净、可维护、可测试性好、适宜阅读。如果在大规模项目之前没有就此达成统一,大家冲上去的时候,再说如何配合、包抄,只会被打得一败涂地。

关键之二,是要做好版本控制。版本控制是研发的基石,开发人员每天都要用,而即便很多资深程序员,对版本控制的使用方式依然很落后。版本控制最基本的要求是可回滚,但国内大部分公司做不到这一点。《精益软件开发艺术》这本书第0条就讲:代码必须在版本控制工具里。离开这个基础,其它的改善都是无用功。我原来一直在推Git,本质原因还是我们的内功特别落后,你看Github有多流行,就知道国外做得有多好。

技术人攻略:国内研发管理内功不足,除了版本控制,还体现在哪些方面?

除了版本控制外,调程序和测试的情况也不乐观。国内程序员调试程序大部分全凭拍脑袋,不能以程序的方式思考问题,不仅不具备调高难度算法的能力,也没有清晰思路去解决问题,更不会使用工具。

在互联网领域,测试的重要性远远被低估。合格的测试开发工程师应该既懂测试,又懂开发,还要能教育其它开发工程师。这种人在现实情况下很难找到,根据我面试的经验,能把最基本的单元测试要点说清楚的人都不多。

做互联网金融这段时间,我接触过国内很多第三方支付,都在测试上做得一塌糊涂。举个例子,开放平台让商家接入之前,需要提供一个虚拟测试环境。Paypal的正规做法,是给每个商家建立一个沙盒。而国内大部分厂商的做法,是让所有商家共用一个测试账号,往里面打一分钱。这一看就根本不懂测试理论,沙盒测试是标志性的东西,如果你到某个医院,发现那里没有显微镜,那就一定说明这个医院不具备做某些类型化验的能力。

电信、金融、制造业等传统软件开发领域,对软件质量重视程度很高。互联网领域最不重视软件质量,普遍采用的灰度测试,虽然能解决体验、交互流程上的问题,但并不能解决质量和正确性问题。测试能力是很基本的内功,做灰度可以,但不能对测试一窍不通还无所谓。这好比你有10发子弹,因为时间、资源所限,只能打1发。但如果你只有1发子弹,你就打,不要说别的不好,因为你根本不知道完整的方式该是怎样,只能灰度。

国内的创业者天天看TechCrunch,知道美国的市场、机会、商业模式,唯独别人的研发流程不了解,所以只会抄袭一些表面的东西。媒体总是报道Facebook一夜成名,但很少有人知道,在这家公司刚开始壮大时,就从Mozilla挖了一位非常资深的专家去负责工程。这些经验丰富的人是团队的定心丸,前进路上有多少坑,他们早就踩过了。研发有本质的客观规律,不能因为你年轻,你创新,就逾越这些规律。

技术人攻略:你提到的从业人员眼界狭窄,表现在什么地方?

从业人员不怎么看书,是这个行业普遍存在的问题,最多看点讲程序开发的书,所以有文化的程序员特别少。作为完整的人来讲,基础文化结构的缺失,导致大部分程序员看问题很偏激,没有常识,不知道历史,还总拿无知当个性。

例如做技术选型时,看好某门技术,就要用到项目里,这其实是非常幼稚的行为。技术选型一定要考虑团队的驾驭能力,考虑能不能持续招到懂这门技术的人,以及最重要合作伙伴用了哪些技术,你选的这门技术能不能同他们高效沟通等非技术因素。

研发管理90%的问题,30年前在美国已经出现过,好好看看经典书,90%的问题能解决得挺好。不要总觉得自己是世界上第一个遇到这个问题的人,差不多你都快成为世界上最后一个遇到这样愚蠢问题的人了。干了多年研发管理的人,都没读过研发管理经典的书,是很可笑的事。

我经常说,想去研究软件考古学。软件的历史比较年轻,可考证的东西又比较多,能研究出相对清晰的历史、来源、派系,帮助我们了解行业的发展过程。《人月神话》这本软件工程经典书,就是讲软件开发的历史,程序员知道历史后,会更有兴趣去思考整体的行业脉络。

上大学时,我们会从各种空难事故中,学习飞机设计失败的教训,例如某个部位为什么要这么设计,是从哪一次空难开始改进的。航空工业能发展成现在这样,不是由几个小屁孩拍脑袋做成。在大体理论框架没有突破的前提下,许多改进都是基于已有经验,对细节的精益求精。任何行业都需要积累,研发管理也类似,我们需要对行业历史有所了解,要传承,而不是完全去创新。计算机行业理论框架突破并不多,并且能得图灵奖的理论,跟大部分撅着屁股干活的人没啥关系,所以还是老老实实把这些经典理论继承了,对你的帮助更大。

至于为什么要读那么多其它方面的书,除了能提高人文素养,还能帮你解决自身的问题。国外软件业大师,在思考自己行业问题时,常常能旁征博引其它行业的案例,例如引用一本护士学的书、一本机车修理的书,或一本建筑电气的书。各学科反复交叉会带来启发性思考,可能你这个行业的难题,在其它行业就不是事儿,帮助你开拓新思路。

技术人攻略:对技术缺乏敬畏又如何理解?

国内一些程序员懒、没有开阔的视野,对于技术缺乏敬畏之心,觉得自己什么都懂,不需要特别谦虚去学技术,一幅老子写代码天下最牛逼的样子。问他行业里有没有偶像,回答没有,问他知道业界谁做过什么东西,回答不了解。这种人是行业祸害,拉低了行业平均水准。

开发人员能不能成长,只要看有没有追求就可以。面试时我通常会问几个问题,例如最近学了什么?通过什么途径去学习?看哪几本书?都是谁写的?他还写过什么书?关注什么开源项目?谁写的?他还做过什么项目?这几个问题如果能很清晰回答出来,说明面试的这个人是有追求的,起码有吹牛的追求。如果一个程序员连吹牛的追求都没有,是很失败的。

那这群人为什么如此骄奢淫逸?因为拿钱太轻松了。互联网公司程序员离资本非常近,光今年上市的公司就大概有20家,行业发展得实在太好。国内互联网已经快15年没有寒冬了,包括2008年金融危机时,企业融资可能受点影响,但程序员的薪水一路水涨船高。除了干IT,有几个刚毕业的人能拿到上万工资呢?金融行业能拿到,但不需要IT这么多人。

美国每7、8年,就会经历一次经济周期,而国内这一代程序员没有经历过寒冬,所以不珍惜自己的工作,不知道自己真正的价值在哪里。出来混终究是要还的,大量发行货币必然导致通货膨胀,只是时间早晚问题。从经济学角度讲,市场有了泡沫,需要经历一次大萧条,把泡沫挤压干净,才能变成更健康的环境。经纬合伙人已经写信,让大家做好过冬准备,如果资本持续注血,繁荣的假象就会持续得更长,如果市场找钱很困难,那大批互联网公司就会死掉,释放出大量人员,工资水平马上就会下来。

研发工作非常辛苦,需要踏实态度和长期努力,通过日复一日的艰辛劳动才会有所收获。国内浮躁氛围很难培养出好的工程师。但换个角度,工程师价格高了,对真正有乐趣从事这一行的人来说,还是好事。

从趋势上看,技术学习也正在发生变化,在校学生如果心态够开放,通过参与开源社区快速获取经验,在学校里就能练就很好的内功。这群人一旦成为一个小气候,可以直接和毕业5年左右的人竞争。尤其是当经济形势不好的时候,那些得过且过的人会很危险,终究有一天,他们会拿起书本去学习,知道自己根本不值那个价。

技术人攻略:这种行业普遍存在的浮躁心态,带来了哪些不利影响?

我们生活在一个非常功利、信仰缺失的时代,人们只想快速获取财富,很难有正确的价值坚持。用博弈论解释,这种浮躁走向了囚徒困境,类似日本、德国这种成熟社会,大家做事都不浮躁,整个社会能达到比较高的均衡。而在一个浮躁社会,没按规矩的人走得更快,于是那些按规矩做事的人就吃亏了。这种浮躁其实把大家都害了,把行业也害了。

IT现在和钱离得比较近,所以病得挺重,整个行业里充满了骗子与强盗。大家努力的方向不是提升自己,而是只要能获得钱的事情都会去做。任何时代都有骗子,但一个国度里大部分人都是骗子,是不正常的,还是应该实实在在创造一点价值。

热衷于炒作概念,是行业浮躁的表现之一。前几天参加一个研讨会,讨论了半天,才发现这群人不是在玩大数据,而是玩“数据”。因为以前根本没有数据,决策主要靠拍脑袋,现在有数据了,就觉得自己与时代划上了等号,想裹着这个外衣去挣钱,真是无知者无畏啊。好多人觉得有Hadoop集群了,上了硬件了,从政府那里拿到钱就牛逼了。可对数据没有理解,不知道怎么用Hadoop发挥价值,有钱也没有用。云计算也类似,被地方政府当成了房地产来搞,涌进许多根本不懂这个行业的人。

这种浮躁会导致软件研发竞争优势下降,我们在圈子里有讨论,如果做高端基础软件,硅谷研发成本会比国内更低,能雇佣更高素质的人才,有更好的配合,以及更确定的产出。国内拿到钱的互联网公司,将来可能都会去北美建立研发中心。贵不贵是一说,还有值不值的问题,为什么中国建研发中心不值,这是一个很耐人寻味的问题。

互联网行业看上去门槛低一些,创业相对容易,但总要设置一些门槛给竞争对手,所以还是要有自己的积累。我以前曾喷过阿里这样的公司,觉得他们做的东西不够专业,但后来我改变了观点,他们能坚持这么长时间,能把云计算推到这样的高度,就算走了一些弯路,也是值得敬佩的。这些实实在在的创业者,才是业界的良心。

技术人攻略:根据你做敏捷咨询的经验,实施技术团队过程改进的最大困难在什么地方?

最大的困难在于建立起团队成员对你的信任。许多敏捷实施失败的原因,就是因为程序员不信你,特别是团队资深的人不信你,基本一定会失败。从事敏捷咨询行业的人,许多并不是技术背景,他可以讲一大堆方法论,但程序却写得乱七八糟。所以想做好技术团队的过程改进,至少你得是个懂技术的人,首先要向团队展示出自己的技术能力,才有机会去解决困扰他们的问题。

管理大师德鲁克曾说过:“你度量什么,就能改善什么”。在具体过程改进实施中,我喜欢从细节着眼,寻找一些善于实施,又能见到效益的改善。比如我经常会用到一个方法:度量程序员的时间花在了什么地方。如果大家都是靠猜测,管理不好也不奇怪。

我曾经装过一个软件,记录自己使用电脑的行为,例如统计每天用了多少时间上微博、聊QQ、写邮件,还是写代码。真正把时间记录下来之后,才发现实际结果和自己的感觉大相径庭。社交要消耗大量时间,非常影响工作效率,所以后来我把IM都关掉,集中处理工作。

一个管理良好的团队也是一样,想要改善需,就必须要有动力。作为管理者,你必须刺激团队成员身上的动力,给他们一面镜子,照出来他们背后的魔鬼,这样才会有改善的基石,这也是建立信任的其中一步。大部分程序员都很尊重事实,当他发现每天5个小时都花在聊天上,自己就会想办法去改善。逐渐实行这样能见到效益的改善,就会获得团队信任。

好多找我做咨询的人,容易关注一些表面现象,比如敏捷实施的各种方法。在我看来,表面的东西只占20%,真正想做好过程改进,必须花很多时间做基础工作。比如上面提到的对团队工作时间的测量,对你的改善目标,提供了强有力的数据支撑,是非常基础的改进工作。敏捷是一个方法论,在团队内功真正得到提升之前,那些方法没有任何用处,而且高深莫测的方法,会让大家感觉到不确定,容易对此起反抗。

实际工作中,许多咨询顾问不会花精力,去做看上去没有科技含量、很琐碎、不为人知的事情。就像刚刚谈到的大数据行业现状,大家在会上讨论着大数据的建模、分析、如何出漂亮报表,但80%的脏活累活,是要把数据有效地进行搜集和整理,它是简单的体力活,但做不好的话,根本没有后面这些故事。过程改进也类似,绝大部分工作就是普通工作,没有太多技术含量,也没什么值得可说的,但必须把这些基础打好,才会有后面的故事。

国外谈论敏捷的,都是有20多年工作经验的人,敏捷宣言发起者,都是业界大牛。而平时工作中,我常接触到一些许多没什么工程经验的人在实施敏捷,并且在各种业界大会上,沾沾自喜地分享他们的经验,所以我后来也很少参加敏捷的这些会了。我怀着一颗敬畏的心,去读大师的作品,思考我工作中的不足。我感觉自己做的工作都很普通,都是大师们说过的,很普通的那些事情,值得分享的不太多,失败倒是有很多。

技术人攻略:你从什么时候成为技术圈的交际花?你工作跨的圈子很多,是否会影响知识的积累?

我也不知道从什么时候开始成为交际花,大概是2011年初,我翻译了《MongoDB权威指南》那本书之后,参加了很多技术交流活动。在这些活动上,遇到了不少志同道合、真正热爱技术的人,让我感觉很踏实,于是就更愿意参加社区活动。

客观地说,许多活动的内容和组织都还有很大的提升空间。大家感觉日本的技术做得应该不怎么好,但我最近看了一本日本的技术刊物,发现他们的技术讨论很深入,国内罕有。我之所以会去各个技术会议当出品人和主持人,是因为不想作为批评者旁观,而是主动推动这些事情的发展,促成技术交流的气氛。

离开上一家公司之后,许多做互联网金融的公司都给我打电话。我会问他们一个问题:技术能给你们公司带来什么?在我看来,大部分互联网金融公司处在初期阶段,还远远没到拼技术的时候。他们拼的都还是业务,业务做得好,技术外包一个,都能撑过去。

现在加入的这家公司做APM应用性能监控,提供的是纯技术产品。我个人更希望在一家不浮躁,纯粹以技术为价值导向的公司工作。云计算快速发展,已经到了踏踏实实给大家创造价值的阶段,我希望通过公司提供的SaaS,让大家用得更舒服、更省钱。

我一直很喜欢跨领域学习,对很多东西都有好奇心。大学本来是航天工程力学系的,却因为研究工业自动化系统,获得了电气工程学院的Rockwell奖学金。尝试新东西在我看来不是障碍,而是乐趣。

工作以后,在不同圈子认识了不同的人,在互联网金融圈认识的人,如果一直待在广告圈,是无论如何也遇不上的。在各个圈子有朋友之后,可以做一些融合的事,比如想知道金融里面安全怎么做,就会有很多安全圈的朋友给我出主意。当然,在不同圈子太多,单一的业务上说不上特别精通,但我个人积累的重心一直放在技术上,一直在认真研究和探讨自己感兴趣的东西,从来没有放弃过对积累的追求。

评论