公司研发效率的提升，涉及很多方面。
根据华为公司无线产品线的特点和实践探索，从大的方面讲，我们认为主要应该从提升管理水平、善用基层团队阵型和流程方法工具、培养从点滴做起提升效率的职业习惯这三方面来推动效率提升。
从三者关系看，管理水平的改进是提升效率的基础，与基层团队阵型、流程方法工具以及培养效率提升习惯是“道”与“术”的关系。
本文就先浅谈提升效率之“道”——管理改进（原文源自华为，2012年初次发表）。
我们的目标是人均销售收入提升、客户满意度提升、交付周期缩短、无效软硬件版本降低。
这是我们努力提升效率真正的目标和衡量标准，提升效率绝不能忘了公司整体经营目标和团队目标，不能单看一点。
以前我们谈效率，往往聚焦在某一点上，比如比较关注人均代码、人均单板、人均版本，这只是效率提升的一个度量纬度，要跟别的要素结合才有用。
比如，我们日人均代码量提升了20％，但如果都是无效版本，有什么意义呢？这是效率的提升，也是成本的更大浪费。
说起效率，言必谈人均代码量要提升，这是个误区。
同样一个功能模块，你用了200行代码，他用了100行，谁的效率高？
不是代码多效率就高，这是不对的。
点滴改进是重要的，又要考虑到全局和我们最终的目标。处理好效率、质量和快速推出的关系，根据不同目的各有侧重。
比如，对于需求稳定、变化较小的产品，采用稳健规范的开发管理方法，可以促进一次把事情做好，推出精品。
而对于需要快速满足客户需求、变化较多的产品研发，我们则需要考虑效率和速度的关系，采用迭代/敏捷开发可能更有效。
对目标达成要用什么方法、工具，各产品线可能各有特点，不一定都适用，只有对自己合适的才是有效的。
以前做工程，我们发现西方友商都会用一两周或更长时间仔仔细细做工勘、数据，开始看没有进展，但后面安装只用两三天就完成。
而我们是上来就猛干，后来发现工勘、数据不足或有误，然后重新再来一遍，后面的安装至少要用十天、二十天，效率孰高孰低不言而喻。
磨刀不误砍柴工，效率提升要从聚集一点一线转变为具有全景图，从局部某点上看好像效率降低了，但整体上看是效率提升了，这是非常重要的一点。
不能头痛医头，脚痛医脚。
事实证明从源头上提高效率，保证“做正确的事”，对提升效率的促进作用最明显。
各级主管要负责，明确工作目标、方向和职责，让大家知道为什么要这样做；传承公司核心价值观，带领下属做正确的事，聚焦目标、减少低效、无效的劳动，提高工作效率。
对于研发而言，要从需求、市场规划、构架设计抓起，确保把前端控制住。
MKTG通过与客户的密切互动，切实甄别紧急需求，尽可能减少产品开发后期的需求变动和计划变更，减少软硬件废弃版本、减少废弃特性，提高版本管理的效率；减少产品的开发维护成本、最终是为了减少客户的运维成本。
架构师、设计师、SE要聚焦在能够带来价值的工作上，提升前端设计质量，从而确保产品上网后的质量、可靠性、可维护性，避免返工和频繁升级。
在日常运作中，PL要能挡得住干扰，以便编程的人专心工作，连贯思路，提高工作效率。
无线的ROSA-RB项目引进业界先进的开发模式后，TR5后遗留问题缺陷率降低了30%、TTM改进了30％、平均生产率提升了49.6%，致命问题前移至开发前期及早发现，有效提升了整体效率，就是一个很好的例子。
此外，在与业界领先企业交流过程中，我们也学习到了他们很多好的管理方法，如走动管理、分享信息、分层授权、精简运作等，各级管理者都可以在日常运作中灵活运用。
1、学习沟通与思考，由“管”到“理”
主管要每天花一个小时与下一层主管沟通，走到项目中去，不要只坐着听汇报；每周花一天思考、梳理，避免“一将无能、累死三军”；每季度花一天与基层员工面对面沟通；向下属分享信息，统一方向和决策标准。
在走动管理和分享信息的前提下，充分授权。
2、倡导“管理者＝支持者”，去掉拐杖
主管要有“问题到此为止”的精神，杜绝简单汇总上传，自己发现问题、分析和亲自汇报；关注问题、变化，而非全部；定期审视组织结构，减少部门墙和内耗。
提高会议效率，改变议而不决、决而不行、行而不果的扯皮推诿，有效决策，减低无效过程。
3、运用“简单”和“做减法”原则
每级主管向下的关注点聚焦重要的几点，不要面面俱到。
同时，要学会“做减法”，学会分层决策、精简会议、精简报告、精简KPI。
随着公司的快速发展，我们常听到很多部门都在喊缺人，但看看研发体系目前已经有了近4万人的规模，如果我们效率提升10％，就相当于多出了4000人的资源。
这么多人可以干多少事情？在发奖金的时候，我们人均是不是就可以高一点？这里的成本和收益，我们是否考虑过？我们有没有从现状里挖潜力的经营意识？
欧洲某交付项目，几百个站点，我们派出30多人的骨干参加，而西方友商同样的工程量，只有4－5人做交付，双方效率、成本之间的差距是多么明显，我们是否发现了其中巨大的提升空间？
关注我们，成就更多行业善战者！
