任正非按:在技术工作的客气是毒品,直面的批评、争论才是良药。

丁耘按:我们在CT领域取得的产品成功不是未来可靠的向导,我们必须要持续进步才能适应时代的客户需求、才能获得未来的发展。我们要清晰地认识到,面向ICT融合,在软件能力、效率和质量方面存在的挑战,在组织流程、作业环境等多方面存在的或多或少的不适应性和问题。

尽管我们在参考业界、反思自己的基础上,开展了软件能力建设并取得了部分进展,但要实现我们期望的目标还需要持续做出更大的努力,需要生产力持续的提高,在此过程中我们各级主管和专家在思想意识和行为技能上的转变是关键。

期望各级主管和专家阅读所附文章,不局限于文章中提到的问题建议,深入讨论影响软件研发效率、质量、业务发展的问题,讨论中多审视自己、少抱怨别人,天底下容易的是指责别人,难的是改变自己。组织的生命力恰恰在于自我进化能力。我们既需要坐而言,更需要起而行,从自己做起,坚持以客户为中心,通过点点滴滴、持之以恒的努力,持续有效改进,静水潜流实现ICT成功的转型。

作者:泥瓦客

近年,在从CT到ICT的转型的过程中,华为公司的研发如何能解放和发展生产力,大幅提升研发效率,是我们未来能否立足于强者之林的一个关键。

笔者以前曾在美国硅谷工作,和世界上最顶尖的软件工程师和计算机领域的牛人一起共事过,也先后带领过不同的团队交付了一些业界领先的企业级软件产品。

几年前进入华为,和几个做企业业务的产品线有些合作,在此过程中感到华为公司在软件产业的差距还比较大;和中国领先的互联网产品相比,在易用性、贴近用户和产品快速迭代等方面也落后不少。我们在软件研发领域的确存在不少问题,这些问题导致我们的IT软件产品质量比较低下、开发效率低、产品交付周期漫长,很是让人痛心。

因此笔者写下了这篇文章,希望能抛砖引玉,供大家思考。

1、架构设计SE与开发分离,一些架构师与专家基本不懂开发

一般各个产品线都会设有架构设计部,主要成员也会以各个层次的SE为主。这些SE也都曾是程序员,但通常因为长期脱离开发部门,主要精力都放在会议、胶片和文档的编写上,以致编程的能力基本丢失,新技术学习的机会也有限。

例如一个移动开发的SE,自己对怎么在Android、iOS上进行开发一点儿都不清楚。在这样的基础上,做好真正的架构简直是空谈。在硅谷成功的公司里,好的架构设计师一般是融入在产品团队中的,随时都能上手编程,而且编程能力非常强。

2、开发者多为低级别,比较难有技术积累

一般基层程序员在工作几年后,有能力的都被提升到PL、PM、SE等职位,员工也都想着被提拔,渐渐成为管理者。大家觉得,光做开发没有职业前途,永远都是在金字塔的底层。而在硅谷的公司,说话比较有分量、收入相对较高的有很多是在各层级中的技术佼佼者,他们备受尊重,干得也开心,不少人根本不愿意转做管理者。

编程其实是一门艺术,热爱和用心是非常重要的,也相应的容易出成绩。这就是为什么在计算机领域,如果做到顶尖程序员,一个人顶一百个很正常。如果程序员觉得没有前途,不思进取,而资质较好的很快又被提拔为管理者,那我们的软件开发将很难有技术和人才的积累。

3、多头管理

我司负责产品开发的部门有PDT、PDU等,相应的拥有PDT经理、PDU经理、架设部经理和SE、Project Manager、PO经理、RDPDT经理、Line Manager、Project Leader等多个角色。这种组织结构清晰地定义了每个Leader的角色,确保一个大的产品开发周期和质量有保证,同时保证开发的人力得到最合理的应用。

但它带来的问题也显而易见,就是各个角色在产品开发过程中有不同的想法和意见,可能出现多头指挥,让开发人员无所适从,沟通的成本也非常大。同时,这种复杂的管理结构对需要快速迭代的IT软件开发也会带来很大制约。大家看看微信的起家史,应该能感觉到,对于一些相对独立的、需要快速迭代的IT软件产品,往往在一个比较强的(产品)经理带领下的一个扁平化的团队效率会高很多。

4、沟通成本高

由于组织复杂,中间层较多,各种各样的任务从上面下来,落实的方法就是各种各样的会议,所以现在很多研发员工的不少时间都被各种各样的规划、研讨、问题回溯、客户支持等会议占用。员工笑称:白天是用来开会的,晚上加班才有时间编程序。针对于不同的组织和项目,能尽快找出相应的沟通节点并能有效地减少这些沟通节点,是一个项目和部门领导需要经常思考的问题。

1、IPD流程不太适合需要快速迭代的软件

公司引入的IPD产品开发交付流程给公司带来了巨大的收益。但时代在发展,技术在演进,IPD流程更适合偏硬件的产品开发,为了保障产品质量,开发交付的周期较为漫长。从基层员工的角度,IPD流程节点的很多环节,如为完成CLINT减少Warning的数字、DTS值减少等僵化的指标,实际上反而可能会加大产品的风险,降低产品质量。

2、安全红线耗费资源巨大

安全红线的目的是防止产品出现安全漏洞,初衷是好的,但执行起来相对比较僵化,效率也低。试想一个互联网产品为了过安全红线一个版本等一两个月,根本无法生存。

建议参照一些先进公司的方法,把安全意识教育和SDLC(安全开发生命周期)融入到员工日常开发习惯中,在开发的同时进行测试和督促整改,对于一些红线达标比较好的部门,可以适当放松以加快交付,检查出问题,相应的问责机制要严格。把安全意识充分融入到开发者的血液中,让安全红线检查“形同虚设”。

1、没有时间抬头看路

开发员工长期在上述流程、组织问题和客户支持的压力下加班加点,几乎没有时间“抬头看路”,只会用一些比较老旧的技术,也不太会站在巨人的肩膀上前进,走了不少弯路,消耗了更多的资源。

互联网时代,MOOC提供了大量实时、实用、先进的网上课程(包括免费的和收费的),如Coursera、Udemy、Pluralsight、Stanford Online、edX、YouTube相应的Channel等,想要学的课程几乎什么都有。

现在的计算机技术日新月异,新的思想、方法、工具等层出不穷,例如Java语言是2000年左右在企业软件领域崛起的,几乎成为很多平台、服务端软件的必选,但随着大规模分布式架构、云计算的兴起,它的短板,如内存管理/GC不可控性、多线程或是异步对IO的控制效率,过度依赖较为重载的OOP等问题,如果使用不当很容易造成灾难性问题。

Google内部渐渐把它们有些后台软件都迁移到了他们自己发明的更为先进的Go语言环境下。Dropbox更是两年前开始使用了比Go还先进的Rust语言,无缝迁移了90%以上的云存储平台。试问,我司有几个人用过甚至是听说过这些语言?我们的研发员工如果不去不断地提升,怎么可能赶上时代的步伐?怎么能开发出质量好的产品?

2、技术任职资格效果不佳,传帮带困难

理论上,技术任职资格是用来给搞技术的人提供晋升通道的。但实际应用上,虽然有破格提拔机制,总体上还是按资排辈,评委也大多是由有较高级别技术任职资格,但对现在技术并不太了解的管理者担当。

同时,任职从申请、技能鉴定考试到做答辩胶片、答辩,消耗了员工不少时间和精力。硅谷的公司一般在这方面比较灵活,技术通道由360 Review和与其工作密切相关的主管直接评价、申请和授予,有些员工在28-33岁左右已经有了非常高的技术职级和地位。

因为技术晋升通道不顺畅,能力较强的员工渐渐离开了开发岗位,较多时间沉浸在文档、胶片和会议中,新来的年轻员工过几年又在走同一个循环。是否可以彻底打通技术升值通道,鼓励有能力的人带新人,同时完善奖励机制,在及时激励和长期激励上下功夫,让研发人员看到技术发展空间,乐于编码,留住人才。

1、研发办公环境

在硅谷先进的软件公司里,MacBook Pro/Air是标准配置,方便携带,随时随地编程。很多软件及移动开发调试都在家里、公司、食堂随时可以进行,包括编程、编译、Review和提交;数据库、各种Library、工具和Docker等都可以在本地的OSX/Linux环境下运行。需要的话,也随时可以跟公司内部服务器通过命令行互联,进行文件、代码的传输和测试。

笔者在硅谷工作时认识一个美国小伙子,他基本都是深夜在家里写代码,白天几乎看不到人,但效率和质量都很高。而我们的大部分研发人员,都被局限在公司内部拥挤嘈杂的敏捷岛,用着桌面云进行着低效开发。

2、代码库管理、Review、Checkin和Bug Tracking工具

基于Web/Git的Review和Checkin的相应工具差距非常大。通过源程序的Review审批和Checkin的机制,可以很快传递能力和互相学习,提升代码质量。同时,在任何一个时间点,任何一个高级工程师或是领导都可以通过这些工具来了解员工真正在代码上的贡献和价值,审查进度和版本分支,进度和质量也好把握。以笔者的经验,这是最好的传递技能的工具之一,往往有一个能人,很快就能把一批年轻人的能力带起来。

我司一般用的是内部开发的DTS bug tracking的工具,比较死板,总体和上述提到的最新的Git源程序管理工具、Review工具、自动化和Nightly Build、敏捷管理工具无法无缝地连接在一起。

3、知识资源的获取

由于公司内网Proxy权限问题和受限于大家英语水平的原因,大部分员工还是习惯于使用百度进行程序、库、方法和问题的搜索。但由于共享性差,同时技术水平与美国相差比较大,所有能在百度上找到的好的资源非常有限,质量也较差。美国软件开发人员已经把诸如StackOverflow、GitHub和Google作为学习和资源分享不可分割的一部分。

1、整体观点还是同意的,部分点比如网络权限、开发流程、工具等现在很多部门已经优化了,跟互联网公司也差距不大了,不过管理团队臃肿与问责机制的严苛,跨部门沟通成本高,安全红线与IPD流程的繁琐确实仍是相对严重的问题。不过随着公司整体对IT化的思考,应该会越来越好,部分部门有可能在2-5年内赶上业界主流互联网公司的研发效率。

2、很多研发的同学都抱怨过,聪明的人都去做管理了。根源还是研发团队的作战方式。一个项目需要那么多人,必然需要有管理,就有所谓的管理者,管的人越多,管理者做技术的时间越少。要转变开发的模式,班长的战争。如果都是一个个的小团队,就不需要那么多的所谓的技术管理者了。

3、这些问题其实5,6年前我们内部早已经发现,如今从一个外界来的专家身上也提出了。因为以前我们的人员、组织快速膨胀,其中最难的问题:骨干员工都提拔去当官、当专家、专家不碰代码的情况确实存在。随着这两年我们的人员、组织逐渐稳定、任职上的牵引,让骨干员工深耕一线开发岗位,核心骨干负责架构代码、核心模块代码、产品的设计正在成为现实,只要坚持下去,研发扁平化组织我们也会实现。

4、总体陈述较客观。不过华为毕竟是硬件公司,任总说改进也最好是小步前进。企业网项目将是后起之秀,现在比消费者项目稍微落后点,请你海归回来也是想获得些新的理念获得改进提高,但炸掉研发金字塔有些过火。

5、这是由华为公司两大基因决定的!

基因一: 基于不信任的管理

假定了一个团队或者一个员工个体,没有办法自动地按要求完成任务,一定要有外力的干预和指导,才能保证航行在正确的轨道上。不信任的假定,造成了领导很焦虑,员工被干扰。领导焦虑哪一步没看住就要出问题,所以比如各种对齐,各种进展报告,各种回溯会。

然后制定各种管控流程(包括IPD),设定各种管控角色,这些东西都需要员工参与,员工就写胶片开会,为各种流程上缴交付件,向各种管控角色汇报。话分两头讲,这一点也不能说是领导完全不对,他其实触动了华为的另一个“传统”(这段可能有些人不爱听)。

我们设想一下,文中提到的那个白天不出现,晚上写代码的哥们,怎么保证他是按需求和设计在编码的呢?怎么审计?怎么考核?怎么跟踪?其实答案很简单,那个哥们必定是个极客,而极客是免运维的。而我司的研发定位,绝大部分基本就是程序员而已,这能不管理吗?这就像手动挡和自动挡,既然选择了开手动,那为了适应不同速度的换挡干预就是必不可少的,否则起步后永远挂1挡就是快不了。

现状嘛,我司是需要大量手动挡的开发人员,只要按部就班做好自己的事情就行,这是批量化标准化作业的要求。极客嘛,当然也是需要的,但很少,这些人单独管理就行。

我觉得公司推了这么多年的所谓敏捷开发流程,其实也是要建立在精英团队基础上,几个人简单思想一碰撞,各自都能清楚的理解和心中有数,就能按时完成任务对接起来,这是很高技巧的,也不是2,3年能掌握的,如果一个团队大部分员工刚写了2年代码,工作还需要别人指导,早上像模像样的开个早会,会上各种问题从9点开到11点,这不叫早会,这叫罚站。这也不叫敏捷,这叫保姆式开发。

基因二:组织复杂,各自为政

华为缺少扁平化管理,层级多,通道多。这样复杂的组织机构,造成了信息沟通对齐非常困难,每个组织机构又有自己的考评,都要考虑自己的团队建设和发展,价值呈现。

人都有趋利的本性,必然会希望更多坚持对自己发展和价值有利的,而放弃那种不太出彩又要大体力投入的。但活在那里,总要有人干,很多事情都不是一两个leader能确定的,小leader也不能什么事都升级给大leader,显得自己无能。于是就讨论划域定界再讨论争议升级开会对齐拉通再讨论裁决拍板……甚至于,这种决策过程花费的人力和时间甚至超过真正做事情本身。这还是组织自上而下没太大分歧的情况。

如果赶上不同通道的组织之间分歧很大,那决策和研讨时间又要再翻几倍了。我甚至见过有领导感叹自己指挥不动下面的人的情况,并不是因为指挥不动,而是多个通道的要求不同,下面不确定要怎么动。

其实话说回来,说难听点,这叫多头管理多通道管理,说好听一点,这不就是管理上的民主吗?因为民主,所以才争吵啊,所以才决策慢啊,要是一个老专家或者老领导一发话,大家都照办,那是效率高,是不是又要有人抱怨专政了?

这两个基因,在华为这种大公司,不太可能改变掉,局部试点是有可能的,比如搞搞精英团队,或者在某些项目上试点扁平化,都是有可能的,至于全面改变,不现实。而且真的改成那个样子,还指不定出什么更大篓子。

6、首先肯定要直面批评。但是:1)不能用纯软件互联网公司的开发模式来套用一个有深厚硬件开发任务的公司。美国的洛克希德马丁公司也不会纯粹这样玩;2)不能用一个小作坊模式的开发团队来要求8万人研发的大公司,高通也不会容忍你半夜在家写代码白天不来; 3)美国公司的问题也挺多,容易让擅长拍马屁的印度人上位,长久下来谁优谁劣不好说。有病治病没病辞退。

7、问题是存在的,不过没有那么严重,世上没有理想的环境,各家都有各家的问题。说Java过时这种无谓的语言之争的说法格局就太小了。我在华为PaaS部,开发用Go、Python、Java各种语言,代码review是Gerrit,公司还经常会请Go、Scala的作者在公司做培训,全公司可以接入参加。华为很大,没有完美的环境,心态很重要。

8、写的很真实到位,尤其是LM/PL不编码、SE不会编码等现象还是比较普遍的。组织分散、会议多、协调多也是顽疾。这两年研发显率提升在工程、方法上进步较多。在怎么让编码人员能够长期在编码岗位上发展,是要好好研究解决。

9、导致研发质量不高的原因还有一条:过量的外包开发人员,通常是一个PL带着100人的团队,95个都是外包的。完成任务和用心做事儿的差别还是很大的,PL也根本管不过来,代码质量自然不高。

10、说一个几天前来我司某基地出差来的见闻:邻桌某PL在和别人espace语音,话间大意:我们组那个A童鞋,能力可以说是最强的,但他有个很严重的问题,他不会展示自己,他做的很多高质量的工作,但是无法很好的向领导展示。所以他的这个上半年绩效不能给太高。。。坐在旁边“无意”听到谈话的我一脸懵逼,内心一紧,又是个悲催的汪啊。

11、一个小小PL,平时既要听资源领导,也要听业务领导的,两个老大的意见经常还不一致,一言不合就吵起来,做下属的都要累死了,实在左右为难啊。为什么在一个PDU内部还要搞矩阵管理呢,实在降低效率增加扯皮,是为了安排人员岗位吗。

12、关于先进研发工具、平台甚至开发语言,确实作为研发作战武器是至关重要的,目前公司研发能力中心、各产品线在开源应用和向外界学习的过程中,都在引入试点,希望扩大规模,公司是倡导的。我们基层干活的也需要多看看外界软件、硬件设计、开发上的一些新工具、新平台、新方法,测试,使用。

13、这篇文章和其后的讨论,让我联想到一本书《失去的制造业  日本制造业的败北》,其中分析日立、NEC和三菱干不过三星的原因,和当前的市场状态蛮像的。

日本人在DRAM产品上80年代到90年代取得了巨大的成功,占据了核心供应商位置,市场占比达到80%。但在市场需求来源从高可靠性的大型机转向低成本的PC过程中,因为执着于高可靠性的制程、工艺、一致性、良品率等指标,长期按三星的两倍甚至更高的运作成本在销售DRAM,盈利微薄,最终完全退出了DRAM市场。

ICT领域的商业价值在向软件、生态系统或者平台型的提供者转移过程中,如果我们也始终执着于过去在通讯领域,为高可靠性产品开发而建立的组织、文化、流程,那在新的商业地图上,我们的版图终究会缩减下来。

14、领导以为给个人就能编码,不知道编码才是所有事情的核心,所以各个产品不停的重复犯错,所以公司各级每年都要开狗屁没有用的质量大会

15、对于研发工程师的定位在西方公司和中国公司之间确实有着巨大差异,本人曾经工作的美国企业和欧洲企业,美国工程师和欧洲工程师50多岁还在写代码,做测试的比比皆是,并且都在项目、组织中享有重要地位;相比较之下,国内连40多岁的程序员都很鲜见。

16、我认为还没有挖到根上,很深的一个根因,那就是PBC牵引太强,绩效结果应用太强,绩效结果简直决定员工的一切回报!!现在PBC牵引太强了,如果能力强的员工不去搞与代码无关的事情,就会没有很好的绩效。为啥?因为现在的绩效管理是“人与PBC比”、“人与人比”。。。

PBC是死的,一般员工都会看好,但人是活的,你要超过别人,你必须搞点其他与代码无关的事情,结果一搞就搞多了。研发普遍有一种认识,搞定周边部门远比搞定代码要难度大。久而久之,写代码的绩效就差了,谁还愿意写。

因此,要从根本上解决软件开发的问题,必须要解决利益分配在执行层面的问题,也就是绩效管理问题,写代码的取消相对考评、采用绝对考评!!!减少考评结果的应用,比如只关系晋升,不关系奖金!!所谓流程的问题,根本就是表面现象,虽然也需要解决,但这种解决,我认为只是持续演进和适配的问题!!!

17、任何一个企业都存在自身的问题,每一个企业都有他独特的文化,华为能发展到今天说明目前的方式是适应华为的,你真正从华为工作过10年以后你再出来看看,外面的大部分企业都和华为有很大的差距。炸掉研发金字塔后又如何重建呢?

18、在工程师文化这一块,我们确实做得很不够,如果纯技术员工都觉得很痛苦,没出路,长久肯定会导致人才流失,优秀的人才吸引不来,自己的好员工都想逃离。但我觉得这个是整体导向的问题,而不光是HR思路问题,比如任职资格,本身在HR政策上就是为了牵引员工技术提升的,只是在执行上,被论资排辈和“管理者优先”的思想给害了,关键还是文章里说的,我们从上到下没有给予顶尖程序员的成长空间和足够的牵引,希望能引起公司的重视。

19、电信级的安全、稳定要求与消费级的快速迭代和快速适应调整天然就存在矛盾,如果用电信的思维去管理必然导致以上问题,但我们的基因就是电信级的严谨;要想在消费领域有效突破唯有破釜沉舟大胆启用外部新人,同时挑选一些内部仍有变革思想和欲望的员工组建新团队,以新带旧实现转型;突破既有的电信级研发管理框架启用新流程,人与流程适配才能有所作为!

20、软件开发模式不是一种就可以包打天下,因此还需要针对不同的软件开发进行适当的定制化和调整,包括组织、流程、环境和工具:如文中所提的互联网应用软件,其体量、周期短,因此势必要调整为快速迭代的敏捷开发模式。如果是开发体量大、周期长的通信底层软件,可以应用稍厚重的软件开发流程。

还有一个观点不太认同,“IPD流程不太适合需要快速迭代的软件”,这里不应该是IPD流程,而是在IPD流程体系下的软件开发模型,对软件开发怎么走起到决定性的还是下面的软件开发流程(CMM or 敏捷等子流程)。事实上IPD流程框架只解决如何将产品开发作为投资来管理。

21、公司很多的软件项目给项目组留的时间非常短,经常是3到6个月就要出产品。从另一个方面讲,就是前瞻性不够。产品不需要的时候根本就不布局。等产品要的时候,跟本不给时间做探索。这样做出来的产品质量可想而知。过去成功的产品,基本上都是提前布局(悄悄的布局),等产品要的时候基本路都走通了。这个时候说三到六个月就可以从容应对了。

海思现在的做法也是一个技术样片加一个产品样片,中间相差半年到一年,这就非常合理。好的软件架构是需要时间去探索和磨合,不是一上来就百分之百能做好做对。而且将来还需要不断的重构。Google的主力产品每一年到一年半就要做一次大的重构。如果不重构,工程师自己都觉得他维护的产品会落后。当然我司的产品也在做持续改进,但意思好像不完全一样。我们更多的关心的是竞争力,人家关心的是架构可持续发展。

22、程序猿、攻城狮文化的建设首先需要在晋升通道要畅通,让更多的人留在专业岗位上,才能真正的出现沉淀、传承和创新。如果每个人都想着往管理岗走,意味着一圈又一圈的轮回,竞争力就更无从谈起。

23、楼主用硅谷的互联网软件开发模式,跟华为的ICT行业嵌入式软件开发模式来比较,是不是有些南辕北辙了呢?互联网软件是全球集中控制(如Google),系统发现bug后,能够在线低成本实时更新版本,你甚至都没有感觉,人家就悄悄的整完了,因此敢玩敏捷试错,可以每周甚至每天更新版本。由此也就产生了与之对应的新的开发模式。

CT嵌入式软件,发布之后是随硬件发货遍布到全球各地,发现bug就要到现场批量召回/替换/整改,你得跟客户道N次谦,做好N个应急切换方案,才敢去干,成本非常高昂。我司主力产品每年都是上百万级别的,“敏捷试错”一下试试,每个错的代价最低都是千万美刀起步吧?你敢玩儿吗?你的客户让你这么玩吗?IPD流程根本就不是为了敏捷试错,而是为了高可靠性而打造的。

拿互联网的开发模式跟嵌入式ICT软件的IPD开发模式来比较,有些牛头 VS 马嘴了吧?当然,改善下程序猿们的工作环境,工作氛围,让大家身心健康的工作,我还是举双手支持的,但一上来就要比照互联网软件的开发模式来整组织、动流程,咱是不是先悠着点儿呢?