一、导读

    Would you buy an automobile made by a company with a high proportion of recallsould that change if they told you they had cleaned up their acthat does it really cost for your users to find your bugs for youem>

       你是否愿意购买一个返修率很高的的厂家所生产的汽车厂家声明它已经作出了改进，你的态度是否会改变为你找出程序中的Bug，你真正损失的是什么–引自《C 陷阱和缺陷》

    一转眼毕业三年了，前几天看《C陷阱和缺陷》又看到这句话，颇有感慨。在我们选择一个产品的时候，为什么潜意识里会觉得外国产品好真的是因为贵大家才觉得好，或者是纯粹的崇洋媚外后，深刻体会到，很多国产电子产品质量确实有待提高，与美日德大厂产品确实有差距。产品生命周期中的很多因素都会对产品质量造成影响，但笔者作为一个嵌入式软件开发人员只能从自身的经历来浅谈研发环节对产品质量的决定作用。

    工作三年时间，在两家公司工作过，暂且称刚毕业进入的公司为A公司，工作两年后进入B公司。A公司原是德企子公司，后被国企收购，整个研发体系仍然沿用原德企的流程。B公司自成立之初就完全的中国基因，经过多年发展也有自己的一套研发管理体系。A和B企业都是行业内的大公司。

二、开发设计流程

    几乎所有的企业都会说质量是企业的生命，笔者所呆过的公司做质量相关培训的时候也总会拿出一张图，就是bug发现的阶段和解决bug的成本。比如在coding阶段的bug，几行代码解决了，几乎没什么成本；而设计后期的bug，可能会导致重新设计和设计延期，明显成本增加；上市后的bug甚至可能要召回，即使软件问题升级版本解决，对公司信誉的影响也是不可估量的。

    笔者很幸运在毕业的时候进入一家具有非常完善体系的公司，并在工作的两年内有幸作为软件开发部分的PL（Project Leader）参与到项目开发中，其研发管理观念和研发管理流程至今留下深刻印象，而B公司虽然也具备一套研发管理流程，总体上和A公司无太多差别，下面主要以A公司的开发过程进行叙述。总体上研发设计分为A、B、C和D四个过程，

1. 机会获取

    机会获取通常指开发新产品的机会，对于ODM公司（如笔者所在A公司）也就是拿到的客户的项目，其它类型公司则可能是根据市场需求立项，一般的开发者可能不会参与到这个过程，毕竟项目未确定之前，不会投入太多研发人力。

2. 需求分析

    项目一旦确定要立项做下去，那么就要开始进入产品设计阶段，而第一步就是需求分析。需求，就是对要实现产品所有细节的定义。需求必须是清晰明确的，因为它描述的就是整个产品要达到的标准或指标，对产品任何一个细节的定义模糊就意味着无法设计，比如要做一个手机，规定要做6英寸的屏幕，这就是很模糊的定义，6寸是16:9还是4:3080P还是720P亮度要求多少模糊的需求定义将使得无法进行开发。笔者所在的A公司为ODM，在机会获取阶段就拿到客户的需求，由客户确定。笔者跟其它做消费类电子的同学沟通，他们一般是产品经理根据调研确定下来需求。另外需求必须是可实现，如果定义一些指标根本就超出的公司的能力或现实 会的技术水平，那么就是无用的需求，没有任何意义。在机会获取阶段，一般会有资深工程师和公司其它团队一起分析客户需求，不然的话你拿到订单却做不到也是无用。比如，要做一款能用意念控制的手机，显然现在的技术水平是无法实现的，就是不合理的需求。

    需求分析是开发者对已确定的产品需求进行理解，然后和客户或产品经理沟通，必须理解正确，不然任何一点的理解偏差将会做出一个不符合要求的产品。因为需求描述的就是要做的产品形态，所以是极其重要的一步。笔者在A公司的时候，部门经理曾经对笔者说过，一个好的项目流程，需求阶段基本要占一半甚至以上的时间，需求的任何不明确或者理解偏差都会导致后边开发设计做无用功。因为ODM是需求由客户定义，开发者就是要做好理解和客户逐条确认，以防偏差，一般来说，需求完全明确之后，才投入开发的。

    在研发管理流程上，需求分析后是要review（评审），review就是对需求的确认，防止开发者理解有错或者偏差，这一步是同样极其重要。笔者在A公司的时候，拿到的需求文档一般有十来个，全是英文，然后一句一句的去理解，用Excel编 ，详细描述每一个要求，然后将做完的需求文件召集review，由内部其它人员提问，然后再跟客户开会进行review，逐条确认理解是否正确，整个需求分析和review下来花了相当多的时间，最后输出需求分析文件、review文件和修改记录等进行存档。有时产品经理一下子定完所有细节有很大难度，也不可能面面俱到，边开发边定义有时候也是迫不得已，可大的方向总是要明确的，软件功能还好，改起来相对容易，设计硬件的需求，一旦有问题可能PCB和模具都要重新设计，成本非常大的。据笔者了解，国内不少公司项目开发，需求说改就改，改来改去，整的开发者死去活来，前期功夫没下足，后期质量也不会怎么样，总是要付出代价的。

3. AD/DD设计

    当需求分析完就要进入设计阶段，设计自然是为了满足所有的需求，这也侧面说明需求分析为什么重要，当需求都不明确变来变去，导致设计不得跟着变化，直接表现就是开发者不停的改，然后永远加不完的班，永远改不完的bug。

    AD 就是Architecture Design，架构设计。也就是根据产品进行软件框架设计，既包含整个系统架构图也包括每个模块的结构，比如的系统分层框图，以及每个应用的状态机以及状态迁移条件。一般只要不是第一次开发产品，公司都会有软件架构，尤其是有一定积累的公司，其软件架构相对稳定，同类产品并不需要重新设计架构。如小米的MIUI，所有小米手机都是MIUI，通用的框架，无论是红米还是小米都差不多，所以架构设计一般不会浪费多少时间。架构设计完同样需要review，尤其是各个模块的状态机设置以及状态迁移条件是否合理，都需要反复review修改，最后输出AD设计文件和review记录。

    DD就是Detail Design，也就是每个模块的详细设计，在AD设计阶段，模块的状态机已经确定，DD设计就是要做详细的设计。在大学的时候都学过程序流程图，在实际工作过程中却很少用到，笔者在A公司无论是AD还是DD设计，都要求使用EA（Enterprise Architecture） 进行设计，其中DD主要是交互图，要设计到每个函数以及调用关系。

    在通过EA输出AD和DD设计文件后，仍需要用文档对设计进行描述，如状态机解释和函数的功能，然后进行review。然后review，尽可能的找出考虑不到的地方，最后归档。

    AD/DD设计这一步也将花费相当多的时间，毕竟这就是一个产品的技术实现模型，如果说需求阶段占了一半时间，那么设计将占剩下时间至少一半。在A公司的时候总经理说过，做开发最忌什么都没想上来就写代码，然后代码修修改改最后乱七八糟，永远补不完的Bug，当时笔者并没有什么体会，工作一段时间后才感受深刻，连需求都没弄清就直接写代码，不是漏了这个就是忘了那个，虽然实现了功能，可代码规范性和健壮性都不够。

4. 功能实现

    其实在AD和DD设计完之后，整个方案就已经有了，连函数名都有了，接下来就是将设计变成代码，这个过程其实并不长，只是用代码将已经烂熟于心的设计写下来而已，一般一个人只会负责一部分，即使编码不是那么熟练，也花不了多久。编完代码还是要进行review，因为代码逻辑已经在设计阶段review过，代码review也就比较省时间，更多的是看代码和AD、DD设计是否相符，然后就是代码规范性。review通过就要进入调试阶段，调试的过程中，需要进行unit test(单元测试)，测试函数和模块的功能是否满足要求，尤其是对一些异常数据的处理。其实如果严格按照当初的设计和编码规范做的话，代码一次通过概率就比较高，调试花时间并不多。

    整个功能实现完成后，要输出review记录和unit test测试结果归档。接下来就要交付给软件测试。软件测试会会根据需求编写test case，同样也会review合理性，最后输出测试 告，有问题改问题。

5. 设计冻结

    从名字上也可以看出，这个阶段要对所有的硬件和软件进行冻结，不能再改了，尤其是硬件，已经做了EMC/EMI等实验，像机械结构也已经开模了，改动的成本很大。笔者在A公司的经历中，硬件和结构是可以冻结的，软件通常会随着后边的量产和实际环境使用发现一些Bug,还是要改的，但这个阶段即使微小的改动，也需要很多流程审批，一些大领导签字，其实这也逼着将所有的问题在前面解决。

6. 量产

    当设计冻结以后，做了生产计划认证后开始试产，然后产能爬坡，最后大规模量产。在这个过程中，开发者的任务相对少一些，主要对生产中一些的问题进行支持，遇到不良品进行分析，是个例还是设计问题，通常过了产能爬坡后，就基本很少有问题，研发的任务也基本结束，后面也只是对反馈回来的不良件进行分析。

三、杂谈

    Review：在A公司入职培训的过程中，曾经说到过流程的最终目的就是要保证设计质量，无论你是刚入职的新人还是工作多年经验丰富的专家，最终做出的产品质量几乎相同，而很重要的一个措施就是reveiw。当你做一个设计或者一点改变，总是要面对大家的质疑，所以都在尽可能的想的全面，毕竟会议上总是被问的哑口无言也是很没有面子。虽然在A公司内页不能保证百分百的符合规范和流程，但通过严格控制后，确实后期很少出问题。

    以上只是笔者作为嵌入式软件工程师所经历过的，一个管理完善的公司其实是体现在方方面面的。在A公司的时候听老工程师说，当刚被收购过来的时候，招聘了大量的中国人，开发习惯乱起八糟，原来成熟的框架说改就改，才一两年的时间就爆发大规模质量问题，损失挺大。后来就又将原来的整个研发管理体系严格要求起来，质量问题很快就下降很多。

    笔者也见到过德国人留下的文档，单一个EEPROM管理就用ppt做了几种管理方案，给出不同方案的优缺点。而换成中国人，执行力很多时候会打折扣，在不停的严格监视下，还是不是松懈一下，但毕竟有了管理，还是比自由发挥好太多太多。

    除了对研发过程控制，还有很多其它方面管理，如风险控制、缺陷管理，还有一些方法论如P（plan）、D（do）、C（check）、A（action），所以质量管理体系是一个体系，研发只是其中的一个环节，在很多小公司，人员有限、资源有限和水平有限，很难有一套完整的质量管理，所以相对来说大公司产品质量一般会比小公司好点，而国际大公司的产品则更好一点，当然也不是绝对，国际上也有很多召回案例。

四、结语

       上面主要是在A公司的经历，而B公司也是行业内大公司，据说产品质量还是不错的，可笔者在B公司里面，开发流程和A公司差不多，但执行的确实差强人意，以至于产品上市后出现一些问题，笔者解决过程中发现很多都是可以在开发过程中避免的，只是对单个人过于依赖，一个人的一点错误出去就是一个问题，每上市一个产品研发就背负一份负担，而在A公司的时候，一旦量产大家都觉的终于结束了。

    工作三年了，无论技术还是经验都经历了一个阶段，有必要对所学所经历进行总结，以此篇开启博客生涯。