流程化之惑

发布时间:2010-6-17 14:44    发布者:贾延安
关键词: 流程
我是2008年2月份正式步入汽车电子硬件工程师的岗位的。当时汽车电子行业仍旧处在最兴盛的时期,整个中国汽车市场欣欣向荣,我带着憧憬和紧张的心情进入了一家世界200强的美国公司,该公司在中国新建了研发中心,正处在蓬勃发展期。之后经历了2008年下半年的经济危机,走过了2009年的萧条期,到如今又重新看到了繁荣的影子,从这短短的2年半的经历中,我慢慢开始理解和感悟怎样作为一名合格的工程师而工作,在此将工作经历中的一些感想分享出来。

进入企业之初,国内与国外项目同时在运行,企业很快从20多个人发展至80多个人。由于汽车电子企业本身质量控制体系的要求,在企业内部掀起了一股美国流程化的过程。公司由于扩张的需求,换了技术总监,从上到下开始推行设计的流程工作,开始追逐质量控制。但是,在多项目和扩张的背景下,国内客户的苛刻的时间开发节点仍旧要求所有的工程师必须去遵循。企业的扩张是以人数的增多与项目的增多为标志的,为了不停的占有市场份额,大量的报价开始启动。向国内客户报价的项目都是崇尚开发周期快和没有最低只有更低的产品成本的两大策略。但是由于过分追求完备的流程,失去了流程的本质意义,当我后来反思,这一进程不应该仅仅归纳为“流程化”,而是矫枉过正和流于形式的“过流程化”。

当时由于工程师的人手不够,我马上进入了实战,开始上手做胎压监测系统,包括传感器和接收器两个部分。胎压监测系统项目的前期研发工作已经在美国完成了,分配给国内工程师的主要工作是优化和生产。由于国内初期项目优化时没有相应的过程文件,而原负责的工程师并没有在初期完成这些流程文档,因此,我大部分的工作内容就是补齐这些文档,以应付美国工程师的检查。一般情况下,在设计与生产结合的初期,正是大量暴露问题的时候。第一个项目在贴装试生产阶段,经常出现设计与生产线的配合错误,所以经常需要到贴片的工厂去做支持工作,改进电路板布板。我的一个突出的感受是,既要保证很短的开发周期,又要追求过程文档的完整性和复杂性,以高标准的要求来督促所有工程师完成过程文档;与此同时缺乏经验丰富熟悉流程的工程师,且不给工程师消化参考文件的时间,这项工作不可避免的变成了形式主义泛滥的重灾区。由于国外的硬件设计过程的文档通常篇幅很长,格式较为复杂,涉及的知识面又广,文档中的大段英文说明与计算使得工程师去理解和掌握文件需要大量的时间,更不用说在国内项目上应用这样的格式。因此,这样的流程化要求在当时只能是以失败而告终。当时我接手的几个项目由于成本与客户自身的问题,大部分都夭折了。同样的,我身边的工程师也因为项目的苛刻时间要求,往往疲于应付各个时间节点,对应的大部分流程工作普遍流于表面,即使出现了设计问题也不能很好的完成追踪和检查。

经历了这个阶段以后,我与另外一个工程师合作为一家韩国的汽车公司做车身控制器。与国内项目不同,韩国的厂家有着自己严格的要求,对各个阶段的控制有着自己独特的检查机制。我被分配完成这些特殊的要求,在现有的设计基础上,完成客户对产品的一些独特的考虑。在这个过程中,我们做了一些有益的尝试,并不是将所有复杂的文件全部完成,而是根据客户的需求完成,这样大大加快了速度和沟通的有效性。当然我本人也花费了大量的时间阅读设计标准和学习与硬件流程。相对来说,这个阶段是比较顺利的,整个项目的进展也比较顺利。

这时,进入了残酷的2009年,经济环境的恶化导致了大量项目和人员的流失。此时,公司的战略重点慢慢转向了混合动力的方向,我因此被安排去做支持混合动力零部件开发团队的设计工作,主要内容是完成电路的验证和反馈。在这样的背景下,我得以在设计与验证的角度去参与国外工程师的项目研发,对于我本身来说又是一次重要的提高。面对各种的设计和支持任务,不同的要求不同的规范磨砺着我的设计视角。

与此同时,国内的项目开始爆发出前期设计的问题。人员的流动也加剧了流程化的转变。当公司的管理层经历了巨变,对质量控制的要求从“过流程化”一下子转换到了“去流程化”——为了降低流程对工程师时间的占用,领导们决定将质量控制过程降至最低限度,将对工程师造成工作负担的所有“复杂”的问题,甚至包括那些必须的合理的部分重要流程环节的过程文档全部省略,进而完全漠视整个开发流程。这往往发生在项目的开发前期,“去流程化”的项目虽然在开发前期超前的完成预计的时间节点,但是陆陆续续暴露出来很多的调试问题,为后面的质量管控埋下了无数的炸弹。再加之人员的不断变动,新接手的工程师无法从项目文档中获取足够的信息,因此,每一次工作交接都意味着从头开始,在产品的调试实验中发现非常多的问题,只能完全推翻原有的工作,项目交样的时间点被不断延后,设计不断从头开始,版本越来越多。缺乏流程的工作方式其最大风险就在这里。

流程化的意义在于进行设计过程的质量控制,而许多公司的组织形式想要完全实现完整的流程控制要付出相当大的努力和时间;现实的限制在于项目的开发周期往往很短,而有经验的工程师并不多而且不一定能够快速的适应文档化的工作;由于高校的培养模式使得毕业生大部分缺乏实践能力,课堂上的知识陈旧而脱离实际,大部分公司并没有足够的技术和人才的积累。通过我在博客上收集到的网络同行的意见,我觉得重点并不是要不要流程,而是对于流程的理解。

所谓流程,特别是设计的流程,是在设计的各个阶段加入了各种定性与定量的工作去考核与评判,虽然工作量加大了,但却多了评价设计的指标和追踪过程的手段,更是对工程设计人员的一种保护。在流程中的产品功能、性能、可靠性和负荷,在各个阶段都是冻结和有据可循的东西,例如,元件的可靠性预测、模块的故障树分析、故障模式影响分析、元件热分析和模块的最坏情况分析等。在样品的每个阶段测试中发现的问题,可以通过流程文件的结果复核,给设计者一条快速的途径去查找设计失误,而不是从头到尾去猜测潜在的问题点。另一方面,流程更是一种强大而有凝聚力的工作方式,使得在不同环境下养成不同工作习惯,拥有不同知识背景的工程师,可以在同一个平台和设计方法的范围内去完成设计任务。这一点很大地避免了由单个工程师的技术特点决定产品特性的情况发生,对于一个追求长期发展的公司,在一定人员流动率下能够保持设计开发的稳定,实施流程控制是必须的。引入流程控制的方法,不一定要在环节上一步到位,可以在各个不同的阶段进行更新与扩充,考虑内容和问题再不断添加和细化。例如,在最坏情况分析中,初期可采用参数估计的简易的极值分析法,可靠性分析考虑使用元件失效率的计数法,热分析考虑简易的元器件热估算的方法。

在一个公司的研发部门中,决定流程和设计成败的关键一点是工程师的平等意识,这点似乎常常被大多数的管理者所忽视。面对同一个设计的回顾检查的会议,虽然有经验的工程师可能与经验较少的工程师的话语权不一样,但必须保证每个工程师都有提出质疑的权力,并且在讨论过程中仅局限在设计内容和技术探讨的范围内,以避免在不断的升级和绽放火花的过程中变成工程师之间的意气之争,伤及彼此的面子。

对于致力于提高产品质量的设计公司,流程化的设计过程是不可或缺的。根据重要的节点不断的扩充流程的内容,完善公司的知识积累,在项目运行中不断去纠错,这是设计流程正规化、设计能力提高的必经之路。经过这一阶段的发展,公司就能在设计上积累持续的竞争力,并不会因为一定的人员流动失去持续前进的动力。

以上是我个人的一点点看法,希望能与各位工程师同行学习探讨。

作者:朱玉龙
本文地址:https://www.eechina.com/thread-13107-1-1.html     【打印本页】

本站部分文章为转载或网友发布,目的在于传递和分享信息,并不代表本网赞同其观点和对其真实性负责;文章版权归原作者及原出处所有,如涉及作品内容、版权和其它问题,我们将根据著作权人的要求,第一时间更正或删除。
kbgyzp 发表于 2010-6-18 00:02:23
当一个公司不具备流程化条件时强行进行流行化只会影响效率,使员工抱怨。
srxz 发表于 2010-6-25 09:01:50
xuexie le  duo xie
您需要登录后才可以发表评论 登录 | 立即注册

厂商推荐

相关视频

关于我们  -  服务条款  -  使用指南  -  站点地图  -  友情链接  -  联系我们
电子工程网 © 版权所有   京ICP备16069177号 | 京公网安备11010502021702
快速回复 返回顶部 返回列表