1_华为是怎样开发硬件的

目录

前言

此文章转自微信公众号硬件十万个为什么

最近很多朋友咨询的一些硬件问题，发现朋友们没有仔细的看datasheet，也没有好好的做电路分析。我讲一讲华为是怎么做硬件开发的，给正在做硬件开发的朋友一些启示。说的不对的地方，大家批评指正。

曾经2007年，刚工作2年的时候去一家小公司去面试。当时考题，我感觉我做得很好，面试的时候，对方对我也很认可。但是他当时说：“我需要招一个，在大公司待过的，最好知道硬件开发流程和规范的。虽然你题答得不错，但是我们需要一个有丰富经验的，最好在华为待过的。”

当时，我就在想“华为的规范和流程是啥样的”，就一直想去看看。之前对华为的面试一直都不是很感兴趣。之后，就很想有机会去华为看看。2008到了华为。

我能想到的华为硬件开发的几个不一样的点，跟大家分享一下，想到哪写到哪，欢迎大家批评指正。

1.文档，评审，设计

当时刚入职时，三个人做一个电路板。虽然电路复杂一些，还是有一些人力过剩的。所以，我就被安排去写一个PCI转UART的逻辑。

我当时是新员工，也急于表现自己，利用周末的时间，估计用了一周的时间，就写完代码，开始仿真了。我以为我的导师兼主管会表扬一下，结果没有，他说：“你为什么没有召集大家讨论？然后再写方案，评审？然后再动手写代码？”我当时是没有理解的，觉得我一个人就搞定的事情，为啥要这样劳师动众？

现在反思：

第一、 从主管的角度，不知道新员工的个人能力，你能把做的事情讲清楚了，他才放心。

第二、 从公司的角度，有一套流程来保证项目的交付。那么则不再太依赖某个人的个人能力，任何一个人的离职，都不会影响项目的交付。这也是华为最了不起的地方，把复杂的项目拆得非常细碎，这样不需要特别牛的人来交付项目。这是为什么华为的工程师的收入是思科的N分之一。

第三、 从效果角度，毕竟一个人的想法是有限的，把想法文档化的过程，就是整理思路的过程；讨论的过程，就是收集你自己没有想到的过程。正式的评审，是大家达成意见的过程。提前讨论，让相关的人都参与到你的设计中，总比你设计完了，被别人指出一个致命的问题要强得多。

就是因为华为把一项工作拆散了，所以沟通，文档，评审，讨论，变得非常重要。

这个工作模式的缺点，也是显而易见，沟通成本高，工作效率低。

2.华为的硬件领域的人员构成

在华为内部里面，人员角色非常多。硬件的人是对产品开发阶段，端到端负责的。

做单板硬件工程师，可以涉猎最多的领域，同时也是工作内容最杂，接触人最多，扯皮的最多的工种。

但是也因为有人专门负责画PCB、EMC、电源、逻辑，原本硬件工程师应该做的领域。那么硬件工程师就武功尽废，变成“连连线”。

其实不然，正是由于每个人都是一个小的领域，没有人统领，所以一个好的硬件经理的作用非常的重要，是贯穿所有领域和全部流程的关键角色。

正如原来华为内部论坛上有一个人比喻的，硬件工程师更像是处理器里面的“Cache”，是所有环节的中转站。

大公司把人的分工分的这么细，也是防止某一拨掌握了太多公司的核心技术，出去单搞了。

3.华为的流程

其实华为的流程，很多人都知道IPD流程是从IBM来的，同时华为也去咨询过爱立信，爱立信的硬件开发，完全没有流程一说。

我个人理解：IPD流程已经在华为变种，结合了中国人的特点，华为的企业特点进行了变通和优化。如果华为僵硬的套用IBM的这套流程，也必定不会这么成功。

那么概括一下华为的硬件开发流程：

需求分析→总体设计→专题分析→详细设计→逻辑详设→原理图→PCB→检视→粘合逻辑→投板→生产试制→回板调试→单元测试→专业实验→系统联调→小批量试制→硬件稳定→维护。

流程的根本在于，这个环节做好了，再进入下一个环节。所有的环节其实跟其他公司并没有太大的区别，只不过严格把握了进入下一个环节的考核条件。令硬件工程师最纠结的是“没有个节点跟’投板’对应”。

华为支撑IPD流程的系统是PDM（又名爬的慢）

PDM的中文名称为产品数据管理（Product DataManagement）。PDM是一门用来管理所有与产品相关信息（包括零件信息、配置、文档、CAD文件、结构、权限信息等）和所有与产品相关过程（包括过程定义和管理）的技术。

华为所有的器件资料，产品部件，工具，文档，原理图，PCB，逻辑代码等都存在这个系统上。

但是系统过于庞杂，其实比较难使用，跟服务器归档、SVN归档、也容易搞混淆。

4.归一化

器件归一化

硬件工程师一般都能够理解，在一个板子上面的，尽可能的选择成本更低的器件，选择更少种类的器件，便于集中采购，同时也便于加工。但是其他公司可能没有对器件归一化的工作做得那么细致和严格。

第一， 由于华为整个公司使用的器件种类非常的多，所以如果减小一个器件编码，带来的收益是十万人民币到几百万，而其他公司可能达不到这个高的收益。所以如果能减少一个编码，宁愿选择可能成本更高的器件。但是这个也需要按照每年的器件直接成本收益*器件发货数量，与编码成本+加工成本差异，进行对比的。不过器件归一化之后，器件的价格又可以跟供应商重新谈价格，这个收益是迭代的。所以，有时即使是成本占优，也会倾向去器件归一化的结论。例如，逐步去除了5%精度的电阻，归一化到1%。

第二， 器件归一化，都是需要进行专题分析的。因为也有工程师为了归一化，对电路原理没有充分分析，导致的归一化带来“问题引入”。所以，当时我的部门当时有一个表格，“器件归一化分析.xls”的excel表格，把每个器件，原来选型，归一化的选型，更改的原因，都做好记录和原因分析。一是让每个做归一化的员工都充分考虑分析，二是问题都有记录，便于评审，三是出了问题，好打板子。

单板归一化

除了器件归一化，更高一个层次的归一化，就是单板归一化。（单板这个概念，我稍微澄清一下，我刚到华为的时候，也觉得这个词很奇怪。因为通信设备，都是机框，背板，加各个功能模块的电路板，各个功能模块的电路就叫做“单板”，硬件工程师，一般也叫做“单板硬件”）

单板归一化带来的好处，首先是电路的种类少，电路的种类少的好处有两个：一是生产成本降低，二是硬件维护成本降低，三是软件开发和维护的成本降低。

第一、单板归一化的先决条件首先是处理器归一化。其实，华为的有的产品这点做得其实不好，X86、MIPS、ARM、PPC全部都用个遍，所以一个硬件平台，需要配备各种软件人员，操作系统搞N套，VxWorks和Linux，BIOS各种配套。

第二、单板的归一化，要注意产品的衍生。第一个版本的机框上的单板所实现的功能，如果后续的产品可以使用，应该直接可以用，不需要再开发。如果不注意这点，第一个版本的单板，到第二版本时，发现不能相互借用。反过来，再修改第一个版本的电路板，来适应新版本。有时问题更糟糕，就是完全不能兼容，只好重新开发。单板的规划显得非常重要。

第三、单板归一化时，虽然电路部分兼容了，但是结构件不兼容。对于市场人员的配置来说，仍然是两种配置。一样是失败的。

平台归一化

那么如果发现不同的硬件平台的架构雷同，功能类似。那么机框也可以归一化。只需要制作不同的电路功能模块，就可以实现不同的功能需求。

但是不同的硬件形态都是有他存在的意义的，如果强行归一，市场未必会接受这种事情的发生。例如用一个运营商的平台去归一一个企业应用或者家庭应用的产品，可能就未必能够成功。

网络架构归一化

这个说法是我自己想的，早在08年的时候，华为就在讨论“云管端战略”了，当时不是很理解。当我们一个运营商平台部门，跟“服务器”的部门合并的时候，似乎理解了点什么。

当X86处理器足够强大的时候，所有的运算，不管是否性价比最高，都送到云端进行处理，那么所有中间的存储和计算都显得不重要了。那么整个网络的结构，就是终端+管道+云存储和云计算。

既然计算和存储设备都是一样的，那作为运算和存储的设备，也就不需要那么多样化了。这时网络存储设备，和服务器就显得尤为重要。

这也是华为成立IT产品线，做重点战略投资的重要原因。

所以现在也就不需要那么多网络节点和网络平台了，只需要超强的处理和存储能力和宽广的通道，多样的终端。

5.硬件工程师的核心竞争力-专题分析

早期，我大中华自研的潜艇，都是海蓝色的，跟军舰一样颜色“蓝灰色”。后来我大海军去参观前苏联的军事演习，发现俄国人的潜艇不是蓝色的，是黑色的。于是回来大讨论，为啥俄国人的潜艇是黑色的。猜想：一定是黑色在夜里面不容易被发现，所以油漆成黑色的。于是全国油漆大运动。 后来才知道，原来俄国人的黑色不是油漆，是黑色的橡胶，消声瓦。于是我们也贴橡胶，可是我们贴了橡胶之后就潜艇跑不动了，因为我们的潜艇的动力不如别人。（以上故事纯属虚构，如有雷同，请把发生时间改为清朝。）

为啥在这里说这个照葫芦画瓢失败的故事呢。我觉得很多硬件工程师有个误区，觉得自己的核心竞争力是在于会使用几个软件（cadence、Protel），画画原理图，画画PCB。我早期的一份工作就这样，最大的本事就是照葫芦画瓢，抄Demo板，抄以前成熟的电路，如果碰到了新的电路设计，一般是按照参考电路先画出电路，再通过调试，去尝试，碰到问题，再去解决问题。

那么现在的观念是，硬件工程师最值钱的地方是在于懂硬件原理，懂得电路分析，模电数电原理，电磁场理论，而不是会使用画图软件。

那么华为是怎样做电路设计的呢？为什么会有专题分析的说法呢？为什么电路设计的时候要做专题分析？

第一、 例行的，每个电路一般都会做几个必选的专题：电源、时钟、小系统；把每个管脚怎么用，怎么接，对接的管脚的电平是否满足要求，都需要文档化，分析清楚。在选用新器件的话，对应硬件工程师的工作量还是比较大的。但是如果是其他公司，直接按照推荐电路设计就完事了。电源专题，需要分析电源需求，每种电源的电压范围，电流需求，动态响应，上电时序；时钟专题，针对每个时钟的输入的电平标准，频率，抖动等参数，时钟时序，并按照各种时钟解决方案进行优化；

第二、 当电路设计过程中，碰到一些新的问题，之前团队中没有接触过的问题，或者认为是重点，难点的内容，会专门做这个问题点的专题分析：例如我们做过的一些双BIOS启动，摄像头的红外LED的驱动，主备倒换啊，之类的，就会把一个问题点分析透，然后再动手做画原理图。

第三、 那么在开发硬件的时候，Demo只是作为参考，每一个依据都是来自于datasheet，除了看芯片的数据手册之外，还要仔细查看数据手册的勘误表errata，核对datasheet与Demo的差一点，如果器件有checklist还得核对checklist。曾经开发AMD的时候，datasheet、Demo、checklist，三个文档对不上的情况。也出现过，一个比较难复现的问题，后来查看了Errata，发现是厂家芯片升级了，修正了bug，而我们还在采购老版本的芯片。

第四、 由于项目本身有交付时间要求，那么在有限时间内其实不可能做到每个问题点都做得深入透彻。那么问题来了：

是怎么做到的呢？首先，每个项目都有《问题跟踪表》，而硬件团队由于事情非常的杂，所以把这个表要用的非常好，不然丢东拉西很正常。我曾经把这个表应用到家里装修。这个表的原理很简单，就是记录，问题内容，责任人，完成状态，完成时间。但是只要你坚持用，你会发现，你问题不会跟踪丢，做事情会比较有条理，而且会有成就感。用了这个表以后，发现问题之后，先记录下来，即使现在不解决，那么也会识别他要不要解决，什么时候解决。其次、问题分优先级，任何项目都是带着风险前进的，那么识别出高风险的问题，优先解决高风险的问题，带着低风险的问题继续走。这也是华为电路设计中“0欧姆”电阻用的比较多的有一个原因，识别出风险之后，但是又分析不清楚，或者来不及分析，只好做兼容设计。这里不得不感慨一句，在你的设计过程中，你马虎对待，没有分析清楚的问题，最后一定会暴露出来。

所以，在“菊花厂”做硬件工程师，“专题分析”是设计硬件最核心的工作，而不是画原理图。

通过这个方法，用1_{2个月做电路分析，而用1}2周时间画原理图，取代了，画图，调试，改版，再调试，在改版的形式。

多快好省，是不可能同时实现的，那么硬件工程师有责任做很好的折衷和权衡。

6.器件选型

关于“器件选型规范”

在进入华为的时候，当时整个公司都在“规范”运动，什么都写规范，人人都写规范，什么任职、绩效、技术等级都看规范。（大公司用KPI来引导，容易搞成“运动”）。

所以当时，按照器件种类，很多人写了各种器件选型规范。当时，原理图评审的时候，听得最多的就是“规范就是这样写的”，这里面有一些问题：

1、写规范的人不一定水平高，或者写得不细致，如果出现错误那就更是害人了。

2、规范有时抑制了开发人的思维，什么都按照规范来，不一定适合实际的设计场景；例如我需要低成本设计，但是规范强调的是高质量，就不一定适用。

3、有了规范之后，也会导致部分开发人员不思考，例如晶振要求在50MHz以上，放pF级的电容进行电源滤波，而低于50MHz的不用。大家都不想为什么，自然也不知道为什么；再例如网口变压器防护，室内室外，按照各种EMC标准的设计要求，直接照着画就可以；但是很少有人想为什么，也不知道测试的结果怎样，等实际碰到困难时就抓瞎了。的确在有的时候提高了工作效率和产品质量，但是工具也发达，人也就越退化，这是必然。

4、有些器件的选型，不适合写规范，因为器件发展太快，有可能等你规范写好，器件都淘汰了。例如：在X86处理器进入通信领域了之后，处理器选型规范就显得多余。

规范确实能带来好处。但是，并不是所有工作都适合用规范来约束。硬件工程师要能跳出“参考电路”、跳出“规范”，从原理思考问题和设计。

当然规范还是非常有用的一个手段，是大量的理论分析+经验积累+实践数据的精华。我觉得当时我看得最多的规范，是《器件选型的降额规范》，这是基于大量试验，实际案例，总结出来的器件选型的时候，需要考虑的内容。

例如：规定选用铝电解电容的时候，需要考虑稳态的工作电压低于额定耐压90%；而钽电容，稳态的降额要求在50%；而陶瓷电容，稳态的降额要求在85%；因为这里考虑了一些器件的实效模式、最恶劣环境（高温、低温、最大功耗），稳态功率和瞬态功率的差异……等等因素。

器件选型需要考虑的因素

在华为的PDM系统上，器件都有一个优选等级“优选”“非优选”“禁选”“终端专用”等几个等级。

工程师可以根据这个优选等级来直观的感受到器件是否优选。

那么器件的优选等级，是考虑了哪些因素呢？

1.可供应性

特别是华为这样厂家，有大量发货的产品。慎选生命周期处于衰落的器件，禁止选用停产的器件。我2005年时曾设计过一个电路，设计的时候就是拷贝别人的电路，结果加工的时候发现器件根本买不着，由于器件停产了，只能在电子市场买翻新的器件。

对于关键器件，至少有两个品牌的型号可以互相替代，有的还要考虑方案级替代。这点很重要，如果是独家供货的产品，是需要层层汇报，决策，评估风险的。

2.可靠性

散热：功率器件优先选用RjA热阻小,Tj结温更大的封装型号；处理器选型，在性能满足的情况下，尽量选择功耗更小的器件。但是如果是Intel这样垄断的器件，你也只有忍受，加散热器，加风扇。

ESD：所选元器件抗静电能力至少达到250V。对于特殊的器件如：射频器件，抗ESD能力至少100V，并要求设计做防静电措施。（注：华为是严格要求，禁止裸手拿板的。我本来也不理解，后来我带团队之后，发现兄弟们花大量的时间在维修单板；我们的团队就非常严格要求这一点，看似降低效率，其实还是提高效率的。至少不用总怀疑器件被静电打坏了。）

所选元器件考虑更高的湿敏等级。

安全：使用的材料要求满足抗静电、阻燃、防锈蚀、抗氧化以及安规等要求。

失效率：避免失效率高的器件，例如标贴的拨码开关。尽量不要选择裸Die的器件，容易开裂。不要选择玻璃封装的器件。大封装的陶瓷电容不要选择。

失效模式：需要考虑一些器件的失效模式是，开路还是断路，会造成什么后果，都需要评估。这也是钽电容慎选的一个重要原因。

3.可生产性

不选用封装尺寸小于0402的器件。尽量选择表贴器件，只做一次回流焊，就完成焊接，不需要进行波峰焊。部分插件器件不可避免选用的话，需要考虑，能否采用通孔回流焊的工艺完成焊接。减少焊接的工序和成本。

4.环保

由于华为大量的产品是发往欧洲的，所以环保的要求也比较严格。由于欧盟提出无铅化要求，曾经整个公司的几乎所有的硬件工程师都在做无铅化的整改。

5.考虑归一化

例如某产品已经选用了这个器件，并且在大量出货的时候，往往有时这个器件的选型并不是很适合，也会选择，因为不但可以通过数量的增多来重新谈成本，还可以放心的选用，因为经过了大批量的验证。这也是为什么倾向于选用成熟期的器件，而慎选导入期和衰落期的原因。

6.行业管

某一个大类，例如：电源、时钟、处理器、内存、Flash等等都是有专门的人做整个公司的使用的规划和协调，提前进行市场调研，分析，编写规范。他们会参与到新器件的选型上来。

7.器件部门

专门有器件部门的同事，会分析器件的失效原因，可靠性分析，拍摄器件的X光，评估器件寿命等等工作。

8.成本

如果在上述因素都不是致命的情况下——上述的因素都是浮云，紧盯第八条。

百度文库上面有很多文档关于《电子元器件选型规范》，有兴趣的同学可以看一下.

7.白板讲解

团队开发文化，那是华为中央硬件部的老大最自鸣得意的管理方法。团队开发文化，在多人协作的开发项目中还是非常有效的管理方法。
个人觉得“白板讲解”是团队开发文化中最精华的内容。

把一个电路原理讲清楚，一般是在其他企业或者开发团队中，很少做的事情。但是有一个原则，如果你不能够把道理讲清楚，那么你一定自己没有搞清楚，或者没有理解到位，或者，其中，一定有什么内容是你忽略的内容。那么最后一定，出问题的地方就在这。也学这有点墨菲定律的意思。但是，讲清楚，一定可以帮助你成长。如果你掌握了某一个知识点，拿出来讲解给大家听，那么你一定会是掌握的最清楚的那一个。

白板讲解的好处之一：深刻理解细节，当多人讨论的时候一定把原理讨论得更透彻，一是确保设计是正确的，同时也保证达到整个团队的最高水平。

我在10年的时候，因为那时候项目停滞，我就专门把开关电源那个部分的每个细节，都拿出来讲解，一共讲了10次左右，后来把Buck电路的每个细节都讲一遍之后，我觉得对开关电源的原理才有了稍微透彻一点的理解。然后再把10次讲解的内容整理出来，就成了一个《单板电源是怎样炼成的》的教材。同时增加了电源调试经验丰富的老魏同学的经典案例，组成一个比较完整的电源教材，在公司内部广为传播。

白板讲解的好处之二:很多很多的讲解，组成一次培训，很多的培训就是一套教材。整个团队讲解越多，技术积累就越深厚。

曾经有一段时间搞PCI协议的逻辑，同时也有另外一个同事同时在看。我由于已经上手开始调试了，同时也做了各种仿真，所以对整个协议的理解还是比较清楚的。而另外一个同事的主要手段就是看代码，和协议原文，所以他并不是理解代码写的原因（因为逻辑写作的时候，有一些技巧性的内容在里面，例如：如何利用基地址寄存器，确定存储空间的大小）。

当然，他开始讲解的时候，我就没有作声，因为当时我们都是新员工，主管都看着，别人组织的讲解，也不好抢了别人风头。后来由于他讲的内容有太多的错误，我实在看不下去，就指出他的错误。他当然不服气，表示他是正确的。

但是事后他又向大家表示，他原先的理解是错误的。

这件事情之后，我的项目经理（PM），跟我说：白板讲解，最厉害的地方其实不在于大家把问题搞清楚。而在于，“白板讲解”是一场比武，它能让团队里面的每个人做技术攀比，促进大家不断的提高技术。同时，也是在主管面前，谁水平高水平低，一目了然。

*白板讲解的好处之三：在团队内部是最有效的技术比试，是骡子是马拉出来溜溜，别整天文人相轻，考评时相互不服气。有本事的，没本事的，一拿出来讲，全部都清清楚楚。

一个团队，甚至一个公司，一个国家，它的成功或者失败都是由这个国家的绩效考评体系，人才选拔体系决定。白板讲解给团队的技术排名提供了最有利的数据支撑。

研发团队大都气氛沉闷，状态不好的时候疲疲沓沓，开发周期拖延，效率不高，好像这是绝大多数企业的研发现状。

为什么这样呢？因为相互之间不交流，人是社会人。整天埋头写代码的团队，肯定是问题很大的团队。如果坐在一起，面对面，或者背对背，都需要qq、或者espace这样交流，一天一个团队不说一句话。那自然大家人情冷漠。

虽说白板讲解是技术比试，但是大家都心态open的话，其实这样的比试也是相互促进感情的一个重要手段。

白板讲解的好处之四：有效改善组织气氛的重要方法，增进团队成员之间的技术认可度，只有愿意表达自己观点的团队才是有战斗力的团队。

我现在自己创业，其实发现华为的那一套，讲解，培训，例会，跟踪，其实还是最有效的。

毕竟华为是根据中国人的特点，长时间，多人，多团队，多项目实践出来的非常成熟的一套研发管理办法。自然华为的办法适合大公司，也有其一定的自身问题，但是，再没有更好的办法之前，这些手段不失为很好的方法。特别是白板讲解，去美国硅谷一些大公司、小公司看过的话，一定发现这些公司的工程师办公桌旁边都放着一块白板。只要一讨论问题，就是“来画一下”。

白板讲解的好处之五：白板讲解的重要特点就是“用白板”，用白板的好处，就是避免口头表达的传达一次的误差；把讲的内容一条条记录下来，便于梳理思路；通过大面积的白板展示要讨论的内容，便于更多人都参与到讨论中来。

另外我对白板讲解还有自己的几条建议：

1. 当你的团队还没有白板讲解的，你可以勤于找别人讨论问题，达到白板讲解的效果。

2. 如果你带团队，还没形成白板讲解的氛围。可以先僵化，再优化。先强制大家养成习惯，体会到其中的好处，再让大家自发自动的进行讲解。

3. 在华为的朋友（或者其他大公司的朋友），如果是技术屌丝，那还得多在主管面前多讲解；如果你已经有机会给领导汇报了，那还是多联系PPT。因为PPT的本质还是白板。当然讲的内容要是主管感兴趣的内容，认可的内容，“以客户为中心”——你懂的。

4. 一开始，你得克服自己的心理，有可能这个内容是你还不懂的，一定要敢于问，敢于讲。不能因为技术羞耻心阻碍自己的技术进步。一方面，多看资料，勤学习新内容，功夫要实在；另一方面，要勤讨论，只有讨论才能知道自己的技术不足，理解错误或者不到位的地方。跟不同的人交流多了，你就是这群人中，最懂的那一个了。

5. 另外还是多利用互联网，多在QQ群，论坛里面问问题。也许有人嘲笑你，说这是低级问题，可是你问多了，自然就进步了，因为每个人都是从低级来的。

6. 在华为，有主管强制每一个项目组成员，是不是讲解了。在其他公司可能没有这样的环境和氛围，就靠你自己勤于讨论。

我计划我的孩子以后上学了，他到学校学到的东西，都讲给我听，这样才保证他是理解了。

白板讲解，看似简单，其实里面的哲学还是挺深刻的，看各位理解到什么程度了。

8.问题攻关

因为世界上没有完美的东西，所以就算再高的水平开发出来的产品也不可能像蒙娜丽莎一样完美无缺。所以不管大问题，还是小问题，都可能有问题。

第一部分、网上问题造成的三种后果：

1. 网上事故
2. 网上问题
3. 单板返还

1.网上事故

最严重的当然是“网上事故”，网上事故一般是造成“安全事故”、“客户损失”、“客户投诉”。等等情况。

最严重的网上问题，自然是“安全事故”，危机客户人身安全。

例如曾经有一个海量级发货的设备，曾经因为修改背板时，动了一条电源线的走线。这个电源线，被修改后，隔着绿油与机框的金属件，碰在一起。由于绿油本身有一些绝缘的作用，所以在研发测试和生产测试的过程中并没有暴露这个问题。

但是由于在运输过程中，震动等原因，造成绿油在此过程中被磨损。在客户出上电后，有的设备出现的了短路，发生了烧板的情况。

液态光致阻焊剂（俗称绿油）是一种保护层，涂覆在印制电路板不需焊接的线路和基材上。目的是长期保护所形成的线路图形。

这是非常严重的情况，如果着火，发生火灾，在运营商的机房，那是非常严重的事故。

但是，这种问题发生的时候，已经各种机框和单板发往五大洲，上百个国家。去解救这个问题，付出了非常惨重的代价。

网上事故的另外一种情况，是造成运营商的业务中断；按照话费一分钟0.6元计算，一个省的运营商的用户都是千万级，甚至亿级的。如果造成客户的一分钟的业务中断，带来的损失，如何计算？

正式由于这个原因，所以大多数运营商的设备，都有备份机制。例如核心侧设备的内部交换模块，一定是1+1冗余备份的；如果是DSP资源，一些信令处理单元一般都是N+1备份的。这样如果出现单点故障，既不影响用户业务，也不影响设备的容量规格。

第三种情况，就是客户投诉。有可能虽然没有造成什么严重的后果，如果客户投诉了，这个问题也会比较严重。例如，新机框和新单板邮寄到运营商处。这是出现了，电路板插不进去的情况，自然客户会非常恼火，觉得非常影响公司的品牌形象。那这个事情就会非常大。或者很早以前，任老板在现场的时候，某四川移动的领导，说“你们的设备还不如大唐好看”。于是，结构部的人就倒霉了。

2.网上问题

如果网上出了问题，那么一定通过一些手段，例如原先设计好的一些“可维护性”、“可测试性”的软硬件设计，尽量的去定位问题。

当然这些措施都不能影响客户的正常业务。

另外，会有一些寄存器，或者一些日志，去查看设备异常的记录。还可以查看一些设备的“临终遗言”。临终遗言，会利用处理器复位前，向存储区域存储的关键信息，便于后续去发现和解决问题。

3.单板返还

一线交付的人员一般都会抱怨：“你们研发都是三招：复位，下电，换单板”。

其实网上问题分析，如果已经用上这三招了，那说明这个问题已经比较严重了，说着基本上是硬件问题了。

可是“单板返还率”是非常重要的KPI，决定着大家的“考评”。所以维护人员都希望单板不要返还，或者不要记入指标。如果真的硬件已经不能正常工作了，那么一定会操作这个单板返还到实验室，进行失效分析，找失效原因。

以上不管是哪个级别的问题，哪怕是实验室发现的一些问题，都非常重视。因为如果任何一个问题，都可能造成不可预见的效果。所以对每个问题都刨根问题，分析彻底。

另外就是在做一些试验（EMC、环境），或者在测试的过程中，发现和暴露的问题，都会当做网上问题一样重视，进行一些问题的攻关。为什么呢？

因为有一个理论，问题越早解决，所付出的代价越小。

问题攻关的三个信条：

1. 凡是“实验室”问题，如果不解决的话，一定会在网上出现。
2. 凡是出现过的问题，一定可以被复现。
3. 凡是不能复现的问题，一定是没有找到复现的规律。

案例1、当时有一款NetLogic的处理器（NetLogic的网络处理器来自RMI。RMI收购了处理器创业公司Sandcraft，它本身又被NetLogic购买。后来NetLogic被博通收购），出现了器件失效的情况，但是网上还没有出现类似的情况。

但是，有没有找到规律，是如何让器件失效的。于是双方进入了扯皮阶段。但是通过X光照射，发现失效的器件是焊盘开裂。但是是什么让焊盘开裂呢？当时怀疑了应力，高低温。试了各种措施，但是始终没有答案。

后来大家讨论和试验的过程中，就有同事发现，单纯的低温和高温，都不足以引起器件失效。但是当高低温经历次数过多之后，器件失效的概率明显提高。后来这个同事通过多次试验，反复地使用热风枪和液氮，加速器件的老化。就非常容易出现焊盘开裂的情况。

当拿着这个结论再去找Netlogic时，对方只能投降，承认问题，同意修改器件的工艺。

非常说明问题的两件事情：

第一， 后来实验室出现故障的单板，基本都是厂家改进工艺前的问题。

第二， 另一个发货量很大的产品，在2年后，网上出现大规模这个问题的单板。

案例二、如果在试验中发现问题，一定会把问题分析清楚，或者把问题解决掉。也许这个问题解决很难，经历时间很长。但是这个问题一定把记录下来，根据优先级把问题最后解决掉。

例如曾经一个同事在做试验的时候，发现三极管有漏电流。

理论分析之后，由于三极管作为开关管使用，所以理论分析不可能产生这么大的电流，导致电压变化；把三极管更换成MOS管，也无济于事。

由于这个漏电流是在低温的时候才会出现的。所以当时就用液氮，让三极管处于极其低温的状态（-10度以下），试验中温度情况也差不多在这个范围（-40度到0度）出现问题。

但是经过两周的试验，都没有找到规律，偶尔会复现一下问题，完全没有规律。

我跟那个同事觉得非常费解，当时就观察天气，觉得这个三极管的漏电流感觉与天气有关。如果阴天，就容易复现，如果晴天就完全不复现。

通过这个规律，我们开始怀疑“湿度”作祟。

后来，我们通过增加器件的湿度，果然非常容易复现问题。

把我们的结论去找厂家，厂家确认SOT封装的器件，在高湿度低温的前提下确实会有漏电流的现象。这个漏电流不是通过PN节流走的，所以跟PN节的漏电流的规律完全不符合。

而是从SOT32的塑料封装上漏走的电流。

后来通过调整电路参数，规避了这个问题。

所以整个分析和试验的过程，哪怕是极端的环境条件下的问题，也绝不放过。

其实产品的问题攻关，就是这样的，扎扎实实的解决每一个问题之后，产品质量才有试制性的提升。

形式：

1. 攻关组：任何问题攻关，为了表示重视，一般都会成立个什么问题攻关组。就是把相关的人，还有有经验的人走组织起来，一起参与讨论，这样可以拓宽思路，同时丰富经验。避免钻牛角尖，或者无头苍蝇。

2. 例会：重大的问题攻关，一定是每天例会，把前期讨论的问题汇总跟踪，把每项措施对应的结论记录下来，明确下一步的措施。

3. 日报：这种问题攻关，一定是领导重视的，所以每天都会发布进展。当然领导也会看，偶尔也会发现很久没有进展，之后会调配资源，协调兵力。

4. 总结：问题解决之后，一定把中间的九九八十一难，整理成案例、培训，给大家分享。这样所有的同事，虽然没有亲身经历这个攻关过程。可以通过分享，学习相关专业知识，和问题解决的思路。得到提升。

问题攻关是痛苦的，问题突破了也是非常有成就感的，痛并快乐着。

最后两句话：

1. 越是不舒适区，其实就是你成长的机会。

2. 越是困难的时候，越是要咬牙顶住；只要你坚持，你离成功永远都只有一步之遥。

9.会议

1.华为的会议的特点

对“华为的会议”的特点的一些阐述。

1. 首先大公司就是“会多”，因为公司大，部门多，人的职责划分的细，所以一件事情，需要很多人参与。容易出现扯皮的事情。我刚到华为时，非常不适应，什么都写文档，什么都评审，什么都开会；所以不适应这么多会议，开会时就会无聊，所有的贪食蛇的最高纪录都是那段时间破的。

2. 任何事情还是有主要负责人的，华为给予负责人足够的权利，所以能够推动事情的发展，协调到资源。例如行销有足够的强势去推动研发实现客户的需求。产品经理、客户经理的能量还是很大的，能够跟研发的部长直接进行对话，推动研发干这干那。

3. 所有问题最终都是会记录，跟踪，保证完成的。这就是为什么哪怕有些设备的质量，性能并不能让客户足够满意的时候，客户还愿意用华为的设备。就是这个原因，运营商都喜欢用华为的设备。一个问题出来了，还没确定是哪家的问题，华为的兄弟就冲上去了。联通2个人参加会议，华为6个人来参加会议，通过试验举证，证明是Juniper设备的问题。然后给出充分的报告告诉客户，这不是我们的问题，这是XXX厂商的问题。

4. 林子大了，什么鸟都会有。所以推、拖、赖的事情自然总是有发生。这就需要强大而明确的绩效评价体系，去引导员工去主动承担任务，而不是去划清界限。这种“划清责任”的事情也不可避免。否则就是三个和尚没水喝。（注：华为的这种凡事充分讨论的做法，在电信运营商的领域是适用的，放在消费者领域、甚至企业IT领域往往会不适用的，因为没有足够的利润率去支撑这么做。所以说的一些华为的一些优点）

5. 在开会的过程中，经常人们容易进入误区，或者过于发散，或者过于保守。在产品定义阶段的会议，往往都有人提醒，发散的时候不要收敛；在问题解决的会中，往往会提醒，不要过去发散，聚焦问题。这个能够提醒大家的人往往就非常重要。当然有时也会流于形式，各位朋友可以点击原文链接看案例《华为帮孙杨调整游泳姿势》，会议中不断有人提醒聚焦，但是大家还是比较发散。

2.《罗伯特议事法则》

什么是《罗伯特议事法则》

一百年前有个好小伙子,名叫享利.马丁.罗伯特,二十五岁,中国人叫愣头青。他毕业于西点军校在南北战争期间奉命主持一个地方教会的会议。结果呢——搞砸了。人们争个不亦乐乎，什么结论都没有。总之一塌糊涂。这个会开了比不开还要糟糕。这个小伙子呢，有点一根筋。说我要研究一下，弄个规则，否则我就再也不开会了。他研究上下几千年的开会讨论，有一个结论：人大概是特别爱争论的一个动物，最难被道理说服的动物，分歧一旦出现。很难在短时间内靠语言交流说服对方。否则吵个几天几夜都不会有结果。而且越吵越觉得自己有道理，对方是个笨蛋。所以双方找到共同点达成一个结论一定要有一个机制。他把这个研究当作一个战争一样。把人的争论本性当作敌人。最后这个小伙子打赢了。

打赢的结果是1876年罗伯特议事规则。他自费出版买了一千本到处送人。1915愣头青罗伯特成了将军，他修订了这规则。一开始人家不重视，嘴上没毛说话不牢的小家伙行吗。唉，没想到，真行，他们一实行这个规则，吵架没了，会开下去了。墨水瓶，板凳也不乱飞了。结果罗伯特议事规则成了世界上最通行的议事规则。

会议常见问题。

1. 跑题：一开头，我给你们讲个故事，这一讲，就讲到中饭了。

2. 一言堂：这一个一言堂呢，是领导者爱讲话，一讲就全他讲了。第二个呢，农村有一些特别爱讲话的。也有从来不讲话的。爱讲话的只要一讲话，基本就是他再讲，不会给别人讲话的机会。

3. 野蛮争论：一讨论问题，就说你上次多报了五元钱，你不是好孩子，怀疑别人的品德。一百句话中抓住人家一个词不放。甚至打起来。会议就没法子开了。

4. 打断：不得打断别人的正当发言。

罗伯特议事法则的一条就是：主持人来解决以上问题。

但是一般的企业往往，领导出现的时候，主持人是不会去提醒领导，“你跑题了”，“你一言堂了”，“你不应该打断别人的正常发言”，这就是国外的科学的一些理论和方法到了中国往往不适应中国的土壤，不能生搬硬套的典型案例。

其实在华为，已经能够在大多数会议中，做到发生“跑题、一言堂、打断、不文明”时，有主持人去提醒，并拉回到正轨上。但是一些会议也做不到，比如：领导比较强势，领导自己是主持人，主持人是个马屁精，一些政治敏感问题，就不能去破坏和谐。此处不展开细说。

那么华为是怎么去解决这些问题的呢？

1. 公司定了大的基调“以客户为中心”，所以领导再大，大不过客户，客户需求一律允诺，一律搞定。所以大家都是为了搞定客户，当大家在原则性的问题上不会有大的分歧。

2. 绩效导向，一切是按照结果去评价绩效的。所以在一些问题上，如果领导提出了某个方案，但是可能存在重大隐患时，底下人是有责任去提醒和反对的。否则造成重大严重后果后，领导跑不掉，一样会修理底下的人。都是拴在一条绳子上的蚂蚱。当某个同事提出跟领导不同的意见时，并有价值时，会从绩效结果上去认可这个兄弟。这就是教育员工，鼓励提出反对意见，鼓励纠正领导的错误。

3. 教育主管。华为提倡狼文化，所有的主管能够被提拔上去，一般都是狼性十足，能讲会说，精力旺盛，在开会时balabala一顿，与员工沟通时也是balabala一顿自己说得爽。那么就会容易造成一言堂，或者跑题。那么在主管培训的时候，都会教育带团队的人，要会倾听，会交流，沟通时要把握节奏和分寸。

3.减少无效会议

我曾经支持过CCB的网络建设一段时间，当时刚去的时候，跟他们的IT规划部，开了一个会。

当时，开会时就是典型的“一言堂”，他们一个领导过来，一顿狂骂：“你们华为的设备怎么怎么不行，你们思科的设备也是狗屎，你们西门子服务太差。。。。。。”，建行的人，还有设备厂商的人都被骂蒙了，就听他一顿牢骚，骂完设备厂商，开始骂自己的员工“balabala”。然后所有人都不知道这哥们想干嘛，这哥们也讲不出自己想要什么样的设备，性能和服务。然后气愤愤就走了。

一言堂、跑题、不文明，这些都不是致命的，最致命的就是“无效会议”。当这位领导走了之后，大家继续按照自己的思路，方法，继续讨论，然后花2分钟讨论一下，怎么应付这位领导。

所以我们开会时需要的，但是如何开的有效是有套路的。

那么如何做到呢？

1. 例行会议，有议题。例如周会，一周例会的议题做事先的安排，不是很随意的说一下。订好议题，订好每个议题的时间，保证不跑题。

2. 会议要有纪要，每次开会的会议主持人，会议纪要人都明确。会议纪要是很重要的一件事情，也需要很高的技巧，即需要有效参与会议讨论，有需要记录下关键要点，不记流水账。

3. 会议纪要，要分为：结论（会议结论不随意更改）；遗留问题（要符合SMART原则），要有责任人，要求完成的时间等等。纪要有模板，提醒大家纪要要符合SMART原则。

4. 勤跟踪，要闭环。所有的遗留问题，在下次会议的时候都会回顾，看看是不是完成了，有没有拖延，直到有个交代。当然，如果返现任务安排有问题，根据评估也会进行问题的关闭和挂起。

5. 所有的决议都是需要有理有据的，不能是拍脑袋。因为事前拍脑袋，事后就会拍大腿。然后就有人拍屁股走人了。这样就不会决议是下级服从上级，少数服从多数。

当然，这样的话就会存在效率问题，因为有些问题就会因为短时间研究不清楚，决策不下来。这是就有了CCB(这个CCB不是建设银行的意思，CCB(Change Control Board) 在CMMI(Capability Maturity Model Integration)中，是“变更控制委员会”的含义，CCB可以由一个小组担任，也可以由多个不同的组担任，负责做出决定究竟将哪些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会会同样决定在哪一些版本中纠正哪些错误。CCB是系统集成项目的所有者权益代表，负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。至少会保证，决策的决议是集体的智慧。)

10.兄弟文化

无兄弟，不研发——共同奋斗的快乐

2014年11月份，我从南京招来了一批实习生，全部是90后，其中有些朋友家境也还不错。这段时间，我跟他们一起赶进度的时间，基本上没有周末，基本上每天晚上都很晚。我原以为小伙子们会抱怨太辛苦，但是今年的年度总结会上面，看到小伙子们反馈的都是“收获”、“进步”，是我有史以来最具“正能量”的年度总结会。

大家之所以这么拼，是为什么呢？因为兄弟们一起奋斗，在奋斗的路上有人陪伴不孤单，大家相互之间配合顺畅，相互鼓励，相互帮助，相互激励，同时，也相互竞赛。

我曾经在一家研究所工作的时候，虽然在一家国有企业工作，工作非常稳定，收入非常稳定，但是我当时还是挺拼的，有时搞得也很晚。虽然也得到了组织和领导的认可，最后我还是选择了离开。

“干好干差，收入差异不大”，这是我离开的一个原因。我离开的另一个重要原因就是——孤独，当你工作到很晚，看到别人都早早回家，或者去玩了，其实你在坚持的路上，走不了多久。独自努力坚持的时间不是靠毅力，因为这就是人性。

当你在夜里搞定某个问题时，你最大的快乐，其实就是有人可以告诉。当你发现，只有你一个人在乎结果，或者别人并不在乎你是否在乎结果的时候，你还是会沮丧的。

在华为的时候，如果有兄弟还在加班，会要求主管不要提前走。因为奋斗的路上，不能孤独。主管留下，一定不是简单的陪伴，而是要在具体的问题上给予帮助，或者看一下问题是否需要加班，是否在做正确的事情，是否正确的做事（在方向、和方法上给予指导和帮助），避免做无用功。同时让愿意付出努力的兄弟看到，有人支持你，关注你。

一个好的主管，一定不能在你回家睡觉去了，而你的兄弟在做无意义的努力，这是最伤士气的。

当然，我不是倡导加班，是倡导把事情做好，按时间把事情做；倡导大家共同努力把事情做好，而不是一部分人努力贡献，一部分人混日子，拿着相同的收入，甚至倒挂。

曾经我华为的主管跟我说过：“任正非认为自己做得最自我认可的一件事，就是把钱分好了，分的公平”。所以，现在我们轻松行的责任也是要把钱分好，分的公平。

团队作战，人尽其用

华为有句话是：“知识密集型企业”。由于文革影响，导致中国40岁~60岁人才匮乏，工程技术没有足够的积累；由于大多数大学生在大学期间没有找到自己的人生方向，迷失在星际争霸、魔兽争霸、传奇、英雄联盟这些游戏之中，中国的工程师的技术能力相对美国的工程师，往往会觉得起点低，起步晚，工程知识积累不足。所以我们的单兵作战能力其实远远不及硅谷的工程师。那么我们可以通过拆解，可以把一个相对复杂的工程，分配给多个工程师协同作战，所以“知识密集”这个词，类比于“劳动密集”应运而生。

相互之间的配合能力，项目管理的分配，就显得尤为重要。但是再好的分配和管理，都不可能完美，每个人的责任都不可能划分的那么精确。这就需要兄弟文化，每个人在团队中都找到自己对应的位置和责任，当责任不清晰时，能主动分担，主动担当。如何能让团队中的成员做到这点呢？绩效导向就显得尤为重要。（这个问题最后又归结到把钱分好）

“败则拼死相救，胜则举杯相庆”，
有了这样的兄弟情怀，才能有最终的项目成功。

管理，重要的是理，然后才是管

有的项目管理者，抱怨“管不动，或者不好管”。其实原因在于你是否深入到团队中去。

有一些华为很高层的领导，可以给一些项目具体的指导，而且意见高明，所以才能让下属信服。“宰相必起于州府，猛将必发于卒伍。”，这也是有些外企到了中国，仍然玩职业经理人这套，往往行不通。

作为一个好的主管，不是只是去要求进度、质量的结果，必定是能够帮助你的下属达成你下达的目标，这样你的下属才能信服你，愿意跟着你干。

不要只是下达“攻下那个山头”的命令，而是下达命令之后，能够帮助你的下属，分析敌情、提供情报、指导战略，最终达成“攻下那个山头”目标任务，然后给予奖赏。

如此成功几次之后，你的下属已经具备攻下山头的能力之后，你可以放心交给他一些任务之后，再帮助他挑战更高的目标；当他能够挑战更高的目标之后，他自身也就具备了更高的价值，其实这个过程中他会感激你，信服你，愿意跟着你干。所以兄弟文化，不只是吃几顿饭，喝几顿酒（吃饭喝酒自然还是必须的），而是切实的工作上的帮助和关怀。

所以帮你的兄弟“理”清楚了，自然也就不需要“管”了。如此长久之后，大家之间就是兄弟情怀，而不是劳资矛盾了。

做刘邦，不要做项羽

无论你自身有多强，你都需要大家一起作战。

任正非说过：“我一不懂技术、二不懂外语、三不懂法律”，但是人家做到了世界500强，一定不只是靠他自己一个人能力强，靠的是一个精英的智囊团队，靠的是这个智囊团齐心合力，大家共同的理想和目标，共同的核心价值观，靠的是向心力，靠的是一个又一个的成功团队的复制。

君子性非异也，善假于物也。

刘邦之所以战胜项羽，就是因为他有兄弟们。

11.测试

从进度的角度对比华为和小米的测试

上图是小米UI的一周进度图。按照小米UI每周发布的进度，周四一天的内测。我按照华为的流程怎么套都套不出来。

疑惑点在于：

1. 内测是指开发人员自测试，还是测试人员的测试？
2. 如果是指开发人员自测试，那么测试人员在哪里测试？
3. 如果是测试人员测试，那么开发人员的自测试呢？开发转测试的点在哪里？

华为背景的朋友一定会问：测试人员怎么可能用一天的时间完成测试？

也许有人说，小米的效率就是高。那么我们来看一下华为的测试流程，你就知道是否可以压缩到一天完成相关的测试。

首先说明一点，华为的软件部门，包括UI、或者网站的开发团队也是按照小步迭代进行开发的，在产品稳定后，新增需求会拆分成细小的版本，进行最短周期的开发测试。也可能华为的拆解需求的能力弱于小米，但是这里我们单纯谈测试流程。

华为测试经历的阶段

测试是产品开发过程中必不少的环节,在华为的研发人员中,有近三分之一的人员是测试人员,华为的测试体系在国内算是起步较早,大概经历了这样几个阶段:

1. 青铜器时代: 手工作坊式测试

   1996年研发测试团队成立

   手工作坊方式的研发过程和测试

2. 铁器时代：IPD和CMM阶段

   1998年华为与IBM合作，开始引进IPD流程

   1999年左右引入CMM理念

   产生IPD-CMMI流程

3. 火器时代：PTM阶段

   2004年在IPD基础上开发PTM流程，自动化测试规模开展

   2006~2007年左右PTM趋于完善

4. 集团军时代：IPD-RD-I&V阶段

   2008年左右开始推广敏捷，研发组织演变为PDU方式

   引进迭代开发模式，形成IPD-RD-I&V流程

   系统集成与验证流程：IPD-RD-I&V

   (I&V：Integrationand Verification)

项目经理编写《项目计划》，开发人员产出《SRS》，这时测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。 项目管理论坛

《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理和系统工程师，测试组长需要根据评审意见修改《测试计划》，并上传到VSS上，由配置管理员管理。 项目管理者联盟

项目管理者联盟.

待开发人员把《SRS》归纳好并打了基线，测试组长开始组织测试成员编写《测试方案》，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发人员，测试经理，测试组长，测试成员和系统工程师，返回评审结果。测试组长组织测试成员修改测试方案，直到评审通过后才进入下个阶段――编写测试用例。

测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要通过开发人员，测试人员，系统工程师的评审，测试组长也需要组织测试人员对测试用例进行修改，直到评审通过。

在我们编写测试用例的阶段，开发人员基本完成代码的编写，同时完成单元测试。转测试部后直接进行系统测试。测试部对刚转过来的测试版本进行预测试，如果软件未实现CheckList清单上的10％，测试部会把该版本打回。否则，软件转测试部进行系统测试。根据《测试计划》进度安排，测试组长进行多轮次的测试，每轮测试完成后测试组长需要编写测试报告，其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中的风险等等，这时测试人员就修改增加测试用例。待到开发修改完bug并转来新的测试版本，测试部开始进行第二轮的系统测试，首先回归完问题单，再继续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结束。在系统测试期间，测试人员还需要编写验收手册，验收用例和资料测试用例等。

修改问题单，直到满足规定的缺陷密度，才能够通过相关TR点。

如果验收发现的缺陷率在SOW规定的范围内，那么验收成功。如果超过规定的缺陷率，需要质量回溯。

SRS：需求分析文档；

HLD：概要设计文档；

LLD：详细设计文档；

1.单元测试(UT)

单元测试的对象是LLD中所划分定义的程序单元或模块，它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。

UT的目的，是通过函数运行来检查模块代码对于LLD文档的顺从性，验证每个函数的输入输出响应，与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位，下一个实现单位是模块，从测试的角度看，希望UT完成后，每个函数都牢固可靠，下一步的IT测试将聚焦在函数之间配合能否实现分配需求，而不用担心函数本身的输入输出响应问题。

单元测试比较适合开发人员做。

2.集成测试(IT)

集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试，集成测试应依据HLD，主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合，至少为两个。

IT的目的，是根据模块设计对模块的分解，从已验证的函数开始，逐层向上集成，得到一个可运行的模块。

IT可以由开发人员做，也可以由测试人员做。

不难看出，UT是面向每一个单元的测试，IT是测试单元之间的接口，可以把UT/IT归为“单元级”测试。

3.系统测试(ST)

CMM定义的系统测试：系统测试是针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试，即不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书，更确切的说，是模块需求规格说明书，所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后，每个模块是牢固可用的。

4.模块间接口测试(BBIT)

BBIT为模块间接口测试，验证模块之间的接口能不能配合，有时和联调混在一起，其实目的并不相同。BBIT的目的，是根据系统设计对系统的分解，从已通过验证的模块开始，逐层向上集成，得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试，一个验证模块，一个验证模块间的接口。

以上UT/IT/MST/BBIT一般由开发人员完成，系统基本可以运行起来了，测试人员可以开展SDV、SIT、SVT了。

5.系统设计验证(SDV)

SDV虽然属于测试人员开展的系统测试，但是有点偏灰盒测试，因为SDV验证各子系统的配合是否满足设计需求（DR），对内部的实现还是关注的，验证多个模块集成以后是否满足设计需求。

6.系统集成测试(SIT)

SIT也是验证设计需求是否得以满足，与SDV不同的是，SIT完全把系统当作一个黑盒来测试，不关心内部具体的实现。实际应用中，SDV和SIT 虽然都属于系统一级的测试，往往由不同项目组（子系统）的测试人员分别测试，他们只关注各自的子系统，所以还是把SDV和SIT归为“子系统级”的测试比较好。

7.系统确认测试(SVT)

SVT是验收测试，其测试对象是产品包需求OR。产品包需求给出了产品的范围，从产品可能的应用环境的角度刻画系统，SVT的目的就是确认（或验收）产品包需求给出的各种应用场景产品均能满足。

即使是网页开发项目，外包项目，终端的项目，华为的测试仍然会经历以下几个测试阶段：

SIV：System Integration Verify 系统集成验证.

SDV：System design Verify 系统设计验证.

SIT：System Integration Test 系统集成测试.

SVT：System Verification Test 系统确认测试（系统模拟测试）.

迭代结束后，在正式对外发布前，会将历次迭代实现的所有Story再做一次测试，测试 的主体在测试人员，包括功能、非功能，并要给出测试报告。这个活动就称为SIT或发布测试。

如果Story 测试、迭代SDV测试都自动化了，则本次测试主要是执行自动化用例、如前 面有测试不充分，则补充测试，以及详细性能测试。如果用例自动化程度不高，则本次测试会 刷选部分用来进行测试。测试结束后需要给出测试报告。
SIT测试重点： 所有迭代开发完成后，由迭代开发团队中的测试人员完成对全系统进行回归测试，达到TR4A的质量标准。遗留问题要满足TR5的DI（缺陷密度）目标。

不可思议的小米5%

雷军说：

在改革开放之后，强大的硬件的生产、制造、设计、研发的能力给了中国公司巨大的机会。再加上全流程优化,在小米过去的创业时间里,研发、制造、维修、服务、市场、渠道,全部加起来只占了小米营业额的5%，或者商品零售价的5%。

首先华为工程师的平均收入应该是低于小米的，器件采购的成本也应该是低于小米的，制造的产线也应该是低于小米的，因为有自己的产线。

那么华为的成本花到哪里去了呢？

那么我们看华为的硬件测试过程，就知道成本出在哪里了。

1. 全程测试参与的流程：

在项目开始的阶段，测试人员就开始参与需求分析，对产品的可测试性、测试方案等等因素进行评估。

2. 多层级的测试与试验.

对于电路的设计，会进行单元测试、整机测试、小批量试制、HALT试验、环境试验、EMC试验、热测试、进入生产环节之后会进行HASS试验。特殊的设备还会进行盐雾试验、硫化试验。整机结构还会进行：跌落试验、挤压、扭曲等等。

HALT（Highly accelerated life test）高加速寿命试验。HALT是一种发现缺陷的工序，它通过设置逐级递增的加严的环境应力，来加速暴露试验样品的缺陷和薄弱点，而后对暴露的缺陷和故障从设计、工艺和用料等诸方面进行分析和改进，从而达到提升可靠性的目的，最大的特点是设置高于样品设计运行限的环境应力，从而使暴露故障的时间大大短于正常可靠性应力条件下的所需时间。

环境试验是为了保证产品在规定的寿命期间，在预期的使用，运输或贮存的所有环境下，保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用，以评价产品在实际使用，运输和贮存的环境条件下的性能，并分析研究环境因素的影响程度及其作用机理。

HASS应用于产品的生产阶段，以确保所有在HALT中找到的改进措施能够得已实施。HASS还能够确保不会由于生产工艺和元器件的改动而引入新的缺陷。

硬件工程师最怕HALT试验，因为会超越器件的限制范围去进行测试。但是为什么要这么做呢，其实是找到整个设备的最薄弱点，然后对最薄弱点进行改进。但是由于超出了器件的允许的工作范围，异常的情况特别多，原因也复杂。但是按照规范必须分析清楚，并给出优化措施。这是非常烧脑的意见事情，很多经典的问题都是HALT试验过程中产生的。

12. 硬件的知识管理与分类

电子硬件知识是极其庞杂的，每一个细分领域都可以钻研很深，可以成为某一个人的一辈子的工作，例如EMC工程师，互连工程师，电源工程师，可编程逻辑工程师……电源工程师又可以细分：一次电源、二次电源……分别作为职业。

在硬件领域，由于大量的知识是隐形知识，如果只知道书上写的那些东西，是不能成为一个合格的硬件工程师的。就是因为知识体系的庞大，加上隐形知识众多，所以硬件工程师的知识体系是庞大的。是需要管理的。

曾经有一位网友利用电影在硬盘的管理，来阐述他知识管理的观点；

观点：分类有重叠不如不分类。网友的观点：电影的分类，大家一开始都按照演员进行分类，比如成龙，甄子丹……；但是分类之后，发现多人的怎么办？如果有一部片是由多人合演的，如何分类呢？后来随着收藏的演员目录增加，只通过演员的名字进行分类，会很难找到你需要找到的内容，后来又在演员文件夹的外面增加一个公司：北京制片厂……；公司太多了，又想分类：动作冒险；……

这位网友的观点：“既然无法分类，那么就不要分类，我们依赖搜索。”

知识多了还是要整理的，靠搜索不行；

如果你收录到本地的一些知识，如果不整理的话，那么不能建立起你的知识体系，也就是说你对哪一块，需要重点掌握，哪块只需要了解，没有概念；而你常用的工具或知识跟你不常用的工具和知识，查找需要的时间是相同的；当你学习某一项知识时，这个知识点与其他的知识点之间是没有关联的，因为你没有把知识系列化，或者没有做整合。

如果你的硬盘一样，经常看的影片，你应该需要有快速找到它的途径；而不常看的，你是不是只需要保留个种子；而从来不看的，或者只会看一遍的，变态的、难看的、不清晰的，你其实都可以删除。

上图是我整理的硬件工程师所处的一个地位，同时也是一个硬件工程师所需要的知识领域；

有句话说：“硬件就是连连线，软件就是敲敲键”。可就是连连线，所需要考虑的因素非常多，在大公司的话需要打交道的人也非常多。

上图画了一个车的形状，硬件工程师是这个车的主体，电源、逻辑、互连是硬件工程师密不可分的组成部分，是硬件这辆车前进的必备条件（一些小项目，或者一些公司并不做这样拆分。）

最下面一条是支撑合格车前进的道路，是支撑这辆车能够前进的必备条件。这些领域的知识是硬件工程师必备的，例如：生产跟线，器件sourcing、器件失效分析，这些事情即使是在人员拆分很细的大公司，硬件工程师仍然是这些事务的责任主体；而一些公司，没有相关领域的人，就是硬件工程师自己去做的。

车头是系统设计和产品设计，这些引领硬件方向的思考也是硬件工程师必须要考虑的，因为你不理解业务和产品的场景，又如何选一款适合的处理器？如何知道内存需要多少带宽和速率？

以前我经常说，硬件工程师，如果一个装修工程的木工兼包工头，是整个装修的灵魂，决定了项目的水平高低。所以硬件工程在自身电子领域的知识积累之外，还需要积累一些其他领域的知识，所以这块外围的知识掌握的程度是需要跟核心知识体系进行区分的。因为一个人的时间和精力有限，不可能掌握所有的知识，但也不能完全不懂。

知识管理不只是知识分类和整理；

首先，知识管理不只是罗列目录，他必须是有内容的，也就是大家常常说的，必须是有“干货”；一个再完善和再完整的知识框架的目录，都是没有用的，因为你只需要找到你最需要的那部。如果文件夹都是空的，那就更没用了。

而且我也觉得知识管理，必须是目标为导向。不能为了整理而整理。所以这个知识体系的目录，我倡导是先有问题点或者知识点，积累到一定数量之后，形成你最需要的一个知识体系。

如同，你先有N部你经常观赏的电影，然后再进行分类整理。而不是你先去建立一堆空的文件夹。

例如上图中，进入了一个学习，利用，创新，积累，共享的一个有效循环。

那么，我说说《硬件十万个为什么》的由来，我当年刚进入华为时，在华为的导师是一个项目经理，也就是我主管的主管。他很忙，但是他也很有责任心。没太多时间辅导我，他想出了一个办法：让我每周给他提3个问题，他一定会安排在周五给我解答；我有时为了给他提问也比较费尽脑筋，因为不可能提一些太低级的问题；因为我提问也不是那么好回答，他也要花一些时间去学习，并仔细的答复。我觉得试用期间，这个“每周三问”对我深入掌握一些单点知识非常有效。等我带新员工的时候，正值华为大发展，我一个项目组里面17个人，有4个老员工，其他都是新员工，根本没法一对一辅导。我当时就用了“每周三问”这个办法，这个办法很有效：

1. 强迫新员工思考问题；
2. 新员工碰到障碍，有地方可以提问；
3. 面对新员工各式各样的问题，老员工为了回答也需要提高和学习。

慢慢的，新员工成长起来了，问题也没有那么好回答；我就不再区分新员工和老员工，大家都可以问问题，轮流来回答问题，自然轮到回答问题那位同学非常的痛苦，工作上进行调整，预留一些时间。

后来我发现：为什么不能把我们的问题都整理到一起？当我把每周的问题整理到一起17个人，一周3问题，总共是51个问题；我们坚持了半年（后来我调到市场部门去锻炼，所以后来没有坚持下来）；总共大约1000个问题积累下来，知识领域涵盖硬件的各种领域：电源、时钟、处理器、逻辑、电平标准、接口协议……

当我把问题分门别类整理出来时，反向生成目录，一个大惊喜：一个完整的硬件工程师的知识体系完整的呈现在我的面前。

但是一个很有意思的情况，就是往往在华为内部的技术论坛搜索硬件问题，往往就会搜索到我们整理的这个文档，因为大家碰到的问题往往都是类似的。

所以一句广告词说明了知识管理的真谛：“重要的不是拥有一切，而是需要的就在手边”。我们不只是需要一个完整的知识框架的概念，我们最需要能解决我们现实的问题。

《硬件十万个为什么》虽然积累了相当多的问题，但是这些问题哪怕再全，仍然是碎片化的。它虽然能解决一些具体的问题，但是不能形成知识框架。

经典教材和原理知识，需要系统化；

还在华为时，我曾经尝试过，整理出《硬件的十八般武艺》，涵盖硬件工程师必备技能，分别由大家一起参与，完成基础知识的一些系统化的培训材料：电源、时钟、处理器、高速互连、分立器件、JTAG、内存………基础知识的系统化，完备的掌握，是必须的，否则你无法完成你的工作，更无法说出色完成工作了。

如同AV有句名言：“为人不识武藤兰，看遍毛片也枉然”。所以一些基础知识是必备的，否则你连“骑兵”“步兵”的含义都不懂，又如何去准确的下片？培训和教材，要分“入门”和“提高”；要分别针对不同的层次的需求。