专栏名称: 乔诺之声
成就下一个行业领导者! 聚焦于战略、业务(研发、营销)、人力资源、财经管理等科学管理体系,为企业成为行业领导者提供关键学习与咨询服务。
目录
相关文章推荐
格上财富  ·  稻盛和夫:利他,才是最好的思维 ·  昨天  
简七读财  ·  美联储降息,美股却跌了 ·  2 天前  
上海创业直通车  ·  【上海市】张江国家自主创新示范区专项发展资金 ... ·  3 天前  
上海创业直通车  ·  【上海市】张江国家自主创新示范区专项发展资金 ... ·  3 天前  
上海科创汇  ·  公示|2024年青浦区技术改造专项资金拟支持 ... ·  3 天前  
51好读  ›  专栏  ›  乔诺之声

华为研发副总裁:研发没有一劳永逸【IPD在进化】

乔诺之声  · 公众号  ·  · 2019-06-13 20:45

正文

▪ 来 源:华为《管理优化》报,2018.08.31

▪ 作 者:张明安,时任华为公司无线产品线研发副总裁,现役华为高管顾问、乔诺商学院研发管理专家

▪ 关注乔诺之声,与优秀管理者同行

   

“我们管理层总希望某个软件技术能一劳永逸地解决类似问题,特别是虚拟化、云化、微服务这些技术,一上来情怀都特别丰满,但到最后落地都很骨感。”


本文作者1997年加入华为,2018年9月从无线研发副总裁/CTO职位上退休,21年间获得过华为公司最高管理奖“蓝血十杰”、国家科技进步二等奖,经历了我国通信产品从2G到5G的发展历程。


研发实力强大如华为,他依然能看到其中的不足,并公开讨论——也许这就是华为不断进步的关键所在。


在公司工作转眼二十年过去了,笔者一直在软件开发领域工作,很欣慰我们的软件开发成功地走向了敏捷模式,虽然敏捷岛之类实践最后又退回到了格子间,但迭代开发、持续集成这些实践的价值已经毋庸置疑,变成了我司主流的开发模式。

 

然而,软件开发的诸多基本问题仍然横亘在那里,没有很好地得到回答,特别是对软件开发效率的拷问一刻也没有停止过。

  

软件工程技术领域得承认,在废除了用代码行来度量微观的开发效率之后,一直没有找到普适的工程方法。大家比较熟悉的功能点,实践起来的确难以在不同业务部门之间拉齐,所以代码行仍然是IPMT投资决策中进行工作量评估的依据。


现在不断有声音质疑研发打埋伏,想做就把工作量估低点,不想做就估得高高的。然后安排各种讨论审视——这种不信任造成的管理层面的博弈,对效率的影响非常大。
  

客观来说,最早之前没有约束地牵引人均代码行产出,确实会引起代码堆砌,但是在持续集成中加上了对内存/CPU使用、架构腐化的度量约束之后,会实时触发代码的重构,这样产出的代码可以说都是“干货”,代码行用于工作量的评估是可信的。但依然不能用来做效率的度量,一个优秀的架构师用几百行奠定的代码框架,其价值远比几千行的特性代码高。


软件开发是创造性的智力活动,难以用一个或几个数字,线性地进行微观开发效率的衡量。信任,是效率的最大前提。
  

从大跨度时间的宏观数字上来看,R版本工作量从几年前的五六十万行,到现在的近百万行,而开发人力几乎持平,我们的交付效率、交付能力的确在提升,但是感觉竞争力还是不够,没有装多少有价值的特性,我们的效率到底跑到哪里去了?


笔者基于自己多年的软件开发经历,就这方面谈几点陋见,核心就是再次重复软件业界的老观点:软件没有银弹。
   
  

系统维度,软/硬/芯片垂直整合,既为我们构筑了性能、能效的竞争优势,也让我们对软件新技术的转化产生了“免疫力”。
  

某些新特性只有新的芯片支持,为了性能提升又对之前的加速器做了优化,这就从DNA上决定了为什么做块新单板,从下到上都那么大工作量,决定了无法做到理想的软硬件解耦、硬件即插即用PnP、新老单板兼容形成资源池等,也就无从做到真正的云化部署。


但我们管理层总希望某个软件技术能一劳永逸地解决类似问题,特别是虚拟化、云化、微服务这些技术,一上来情怀都特别丰满,但到最后落地都很骨感。
  

实际上软件根本不可能有某个万能技术,来消化硬件不断变化的问题,这就造成年年谈解耦,年年解不开的局面。跨硬件平台移植对IT界也是最头疼的问题,INTEL在手机上的故事就说明了这一点,抛开其终端芯片是否有竞争力不说,软件开发生态是其无法跨越的障碍跨越。


在过去二十年中,我们的硬件平台单看CPU,就从PowerPC,到MIPS,到ARM,再到自研ARM,操作系统从VxWORKS,到厂家LINUX,到自研LINUX,其他还有诸多代的DSP/FPGA等,现在都在网上运行着,我们的软件产品要保证所有这些产品的稳定、高效运行,既影响效率,安全也是大问题。
  

这其实是NFV的缘起,试图学习IT,把硬件归一,甚至白牌化,软硬件彻底解耦。 我们当然不能去迎合邯郸学步,丢掉自己的既有优势,去搞硬件通用化。但在努力跑得更快,保持优势的前提下,我们也确实需要积极向IT学习。
  

学IT、云化,不能简单照搬,描猫画虎,把一些功能搬到云上去就叫云化了,更要内化IT、云化的技术本质。改变软件以前只是把硬件跑起来的定位,软件要对硬件的开发形成约束力,在软件/硬件/芯片之间形成相对稳定的接口划分,不要把性能追求到极致,在性能与效率之间做好权衡。


软件自身更要充分借鉴云化、微服务化,在不同细分场景之间提炼最大公约数,通过把平台化、组件化的工作做精做细,不断地提高效率。
  

这样不只是我们的开发效率,客户界面的部署效率也会得到根本性提高。华为自身的硬件足够归一,跨代之间能够相互兼容,软件能够灵活升级。也就是说,除了硬件白牌化,客户希望通过NFV得到的,我们都能够提供给他们。这样我们也就不需要畏惧所谓IT的进攻了。
  
  

时间维度,我们的软件产品是不断地甚至快速地进行特性积累,这与业界很多软件公司是本质的不同,这决定了产品架构的腐化是一种必然,为克服腐化所付出的成本也随着时间越来越大。
  

硬件虽然多代并存,但还有生命周期,而我司的软件特性根本没有特性生命周期一说,即使某个特性上线后最终没有一个客户使用,也不能在后面的版本中去除掉。为此,多年来我们一直在为一个朴素的目标奋斗——升级特性不丢失,升级性能不下降。
  

这个目标的达成,或者说防止架构的腐化,一方面得益于敏捷带来的软件工程,如迭代开发、持续集成、全量自动化测试能力的建设。另一方面更为关键的是,需要一支长期稳定的基层软件架构队伍,有人长期看着某个模块,看得懂,吃得透。


他们在基层多年如一日,持之以恒地重构,坚持软件存量的控制,努力做到增加新特性,不增加静态代码,不增加消耗内存/CPU,是让我们的软件保持高质量、高效率的“笨”办法,并没有什么一劳永逸的软件技术。这次公司把基层编码骨干的职级提升上来,签发任命软件总工,是对他们压舱石般贡献的肯定与认可。
  

事实上,有了这个追求,他们自然会主动不断寻找业界新的编程技术、工具乃至理念。我们管理者,诸多不写代码的人,不要老替他们操心应该如何写好代码。不要像计划经济那样,总操心农民种什么,怎么种。
  

近几年,我们也不断引入尝试新的软件开发模式,比如按特性开发,服务/微服务,全功能团队,确实有效果,但没有普适性,这就是由我们软件产品的本质决定的。 如果没有人守着那个模块责任田,几个版本下来,解决一个网上问题,需要一屋子人的局面就必然会出现。


我们只需要保持开放的心态就好了,让新语言新技术新模式作为货架放那里,不要搞运动,不要搞一刀切。
  

为开发队伍如何多做些减法,这才是我们管理者该去努力做好的事情。


过旧硬件如何加快收敛?软件只增不减,增加一个新特性,需要扰动的代码、考虑的特性关联,也就越来越多。我们该如何建立起对产品特性做减法的机制?特别是在当下,针对细分场景的特性越来越多的情况下。
  

  

流程维度,基于不信任的管理理念,下游对上游的卡位,决定了流程管控措施日趋增加的内在必然性,要做瘦身熵减,只能通过系统外力给予额外的做功驱动。
  

公司践行日落法,研发体系也在大规模地进行流程精简。


但一个问题单七八个环节,一个TR点几十人参与,一篇文档评审上百人,怎么就没人主动提出精简?怎么就慢慢复杂到这个程度了?历史上,大规模地进行流程精简也已有若干次了。为什么流程系统自身没有精简的内驱力?
  

“过点”在公司是具有丰富内涵的一个词语,与“拉通”可以媲美。


流程是环环相扣,段段相连的,我们一直倡导不让污水流入下一个环节,因为质量理论说,上个环节的污水,流到下个环节,会产生10倍的PONC(质量成本),所以“过点”设卡应运而生。原本“不让污水流入下一个环节”是每个环节的自我要求和追求,渐渐演变成每个下游环节对上游环节的零容忍,出现一个问题,就增加相应的检查项。
  

以SE的系统设计为例,让一个SE在3个月内再努力,即使给他更多时间,让他写到伪码的程度,到了编码阶段,还是会发现设计的缺陷,文档的不足。


笔者曾解剖一个文档检视案例,项目组为了把SE的问题堵在前面,各派一些骨干去参加文档检视,这样若干项目组相加起来就是近百人;流程还要求SE必须对每个意见是否采纳给予明确的回复,哪怕是学习咨询、疑惑澄清类的意见,这样他基本上就是疲于应付,反而没有时间思考设计本身。
  

但这种检视,是否就把所有的设计缺陷消除了?可能未必。产品开发是创造性的劳动,其基本要义就是产品开发是渐进明细的过程,上个环节的“不合理之处”,必然需要在下个环节的细化过程中才能被检验、被发现。
  

“不能把污水流入下游”,“零缺陷”,这是一种原则性的要求,但不能成为在流程设计中,必须收敛到零的具体实际操作。如果这样,必然会不断强化下游对上游的围追堵截,增加各种烦琐的CHECK操作。


我们还是要相信人的主观能动性,下游在工作开展中,对上游不合理的反馈,肯定会促进相关人员不断提高自己的工作水平和质量。流程每个环节的设计目标,不应该是让某个残留缺陷数字无限去收敛到零,而是让人的主观能动性得到最大的发挥。
  

类似问题总是历史循环往复,管理者总希望用几个数字,并且还是线性可比的数字,就能把人、把团队区分开来。这种牵引下,才有现在几乎所有项目都能精准无误地做到零偏差的奇观景象;而且提前交付也不一定是好的,无法区分是前面估计不准确,还是团队努力达成的。

 

五星评定已不足以区分,只有再加指标,搞六星、七星来评比。从业务本质上,在没有影响客户交付的前提下,偏差5天的一定就比3天差吗,这些数字是线性可比的吗?把这些数字搞成线性的,就会牵引队伍为了遗留缺陷率,过点之前停止测试,问题单暂缓提交的现象。
   
  

综上所述,软件没有银弹,没有某个技术,或者某个开发模式、某套流程能够一劳永逸地解决效率问题。


但我们的管理者又总在试图寻找银弹,希望用几个线性数字就能衡量软件开发效率,区分考核,希望某些技术、某个模式能让我们效率倍增,而且还要年年增加。


即使当下轰轰烈烈的效率运动,又有减法做成加法的迹象,各种访谈、研讨、汇报,比着看各种“减”掉的数字……这些做法其实反而损害了效率,导致各方面都在不断地做加法,不断地折腾基层开发队伍。
  

因此,我们需要回归业务本质,聚焦在宏观经营层面上审视投资效率,收旧约新,多做减法,微观上则要放开放活,无为而治,不搞规定动作,团队、个体的活力也就自然激发出来了。 




6月28-30日,我们特别邀请到本文作者张明安老师,联合多位华为原研发高管,通过案例分享和实战演练还原华为IPD管理精髓,帮您构筑自己的研发竞争力:



3天2夜,产品管理团队学习共识

多位20年以上华为研发高管亲授与辅导

学习内容研讨,工具应用评审,模拟演练输出


1. 学习制定中长期产品线战略、实现产品与技术路标规划

——实现业务目标“XXX亿”落地,不再脚踩瓜皮

2. 学习制定基于市场需求与投资决策的产品开发立项管理

——提高立项质量,打造明星产品

3. 学习制定产品上市规划,全面部署产品“生“与”养“

——保障走好产品价值变现的最后一公里

识别二维码,报名咨询

 


了解课程详情请点击文末“阅读原文”,或直接致电400-698-6188。