今天早上打开电脑先后收到两封邮件。一封是《优特人》的编辑约稿的邮件，大意是希望能有几篇关于管理提升或ERP的文章，想想已经好久没有为《优特人》做点贡献啦！看后有点冲动想写上一篇，然后就动员了一下大脑，发现想写的挺多，却总是感觉找不到突破口。算了，想想再说！于是打开了第二封邮件，是一个失效分析的审核，进入链接打开《失效分析报告》，因为这个分析之前已经听说过，具体的问题和结论也早就知道了，所以没有过多关注细节，大致看了一下就准备点“同意”了！这时一个疑问让我停了下来：我印象中这个产品已经生产了很长时间了，为什么才发现有这个问题？带着这个疑问，我重新找到《失效分析报告》产品信息栏看一下究竟出问题的是哪个版本，几经确认是V3.00。V3.00？让我有些惊讶啊！索性打开UTRDS看一下历史版本吧！输入型号一查询，相关PCB还真有若干版本（V1.00、V1.01、V1.02、V1.03、V1.04、V2.00、V2.01、V3.00、V3.01），仔细数了一下近10个版本。

从V1.00到V3.00到底发生了哪些变化？是设计的改变带来了新的问题，还是最初设计时就已经存在这个问题？设计的变更就这样每天都在悄无声息的在我们身边进行着，而谁来为变更可能带来的风险埋单？

首先，工作习惯让我先去查看一下这个产品的相关评审记录，到UTRDS上找、在我电脑记录中找，最后确认相关评审只有一次，就是07年9月份的一次V1.00版原理图的评审，打开评审时的原理图，找《失效分析报告》中所提及的电路，找了几遍，奇怪啊！没有！只好找来V3.00的原理图对照着找，这时才发现V3.00中有这部分电路，而V1.00中确实没有。

后来知道，是产品需求变化，增加了一个报警功能，为此才增加了这部分电路。而这次出问题的也正是这部分电路。再仔细的对照了一下两张图纸，看一下还有没有其它的变化，结果又找到了一颗在V1.00中不存在的新的IC（认证日期09年7月）；还有一个继电器的型号也做了调整；电源部分电路做了较大的改动……。如果不是单板的型号是一样的，乍看上去可能会认为这不是同一型号的产品吧！评审时的样子已经全然无存啦！看到的完全是另外的一套图纸、另外的一种设计。不禁在想：评审通过后产品已经是“面目全非”“大相径庭”啦！

评审难道就是拿个通行证吗？过了关（评审点）就可以随心所欲的改啦！？如果把评审比喻为“驾考”，评审通过就是拿到了“驾驶证”啦！拿到驾驶证就可以在路上横冲直撞、为所欲为吗？当然不是，因为还有交通法规、交通警察啊！所以没人敢乱来。而我们的“交通法规、交通警察”对这样的变更没有有效的控制手段吗？

我们回过头来看一下IPD对变更管理的说明，在产品开发过程中的变更主要分为两种：一种是来自外部的变更要求，如：用户需求的改变、为了适应新的客户或应用范围等；另一种是开发过程内部的变更需求，如：设计缺陷的纠正、技术方案的升级、产品的优化等。IPD中有专门的《需求变更程序》，其中明确指出“项目经理参与需求分析，组织人员实施变更，制定开发计划，管理需求变更实施过程”、“涉及有关硬件和结构的变更开发，请同时参考《硬件开发程序》和《结构工程变更处理程序》”，按照《硬件开发程序》首先要进行的就是“变更评审”，与项目开发过程中的评审同等重要，并且明确指出如果是“方案级的变更”将以新项目或增项的方式重新开发。

先不去探讨究竟这样的项目走没走变更管理，但在这样大规模对原始设计进行改动的“硬件设计变更”过程中没有进行正式的“变更评审”是肯定的，没有“变更评审”就无法保证设计会符合所有的设计规范、设计准则（CHECKLIST），实际上面所举的案例刚好是对已有CHECKLIST不符合造成的设计缺陷。看到了吧！在变更过程中没有“变更评审”就很有可能把问题、缺陷、风险“变更”到产品中去。而这种不受控制的变更在公司是仅此一例，还是比比皆是？我想每个人心里都有自己的一个小算盘吧！

不受控制的设计变更就这样每天都悄无声息的在我们身边进行着，每个人都已经习以为常，而最终产品的可靠性达不到设计需求，返修率因此大幅度提高，甚至出现整批产品的现场更换等等，这些损失由谁来埋单？

公司是宽容的，所以公司的制度或机制可以回答这个问题：由公司埋单。研发是允许犯错误的，公司的宽容看上去无可厚非，但如果研发是在跳跃流程，是在不受控制的情况下犯着那些本可通过流程执行、细节的约束就可以避免的错误，而公司还在宽容，那就成了“纵容”！公司为此付出的成本既不会积累成功的经验，也无助于警醒他人，更糟糕的是大家争相效仿，屡试不爽，谁还把“流程”当回事！执行力（其实是执行意识）就在这样的“纵容”机制中一点点的消磨殆尽。

个人认为公司的变更管理不能有效实施、变更得不到有效控制的主要原因在于：

1.   我们的项目大部分阶段不明确。而在IPD中只有在维护阶段（C4）才提到了“变更管理”、“变更开发”，我们公司却是大部分项目整个生命周期都还没进到C4，一直在C2、C3这两个阶段徘徊（试样甚至初样在销售），变更也多在这两个阶段频繁的进行，而开发过程的几个评审点早已经过去了，没有哪个项目会再重走评审点。

2.   开发阶段的变更太多。意味着我们项目开发前期的需求分析还是不够细，市场部门反馈的用户需求信息还是不够全面和准确，产品的定位还是不够明确。造成总体方案、概要设计方案在开发阶段就要进行频繁的改动，而评审点评审的只是最初的设计方案。

3.   项目变更太随意。用户的一个电话、领导的一个建议、出差回来的一点体会等等，都可能会马上去着手更改设计，变更在无序和没有控制的状态下进行，难免改出很多问题，甚至重复着曾经犯过的错误。

4.   公司奖罚、考核的机制在牵引大家不顾一切的往前冲（赶快出产品啊！），机制决定了人的行为，行为有错吗？谁能回答这个问题？

所以研发的变更管理不但要抓，而且要好好的抓，还要保证产品整个生命周期都在有效的控制中进行，才能保证产品整个生命周期最大限度的满足用户的需求，为公司创造最终、最大的财务成功。

这些问题其实已经摆在我们面前很久了！可是很难解决或真的没有下功夫去解决吧！改善的路漫漫而修远，且充满坎坷啊！但已经知道了问题所在，相信那句话“每天进步一点点”，终有一天我们会有所改善。也希望能借这次“管理提升整体咨询项目”的推进，对这种种问题给出一个好的解决方案，但最终的推进还是要依靠我们自己。

最后想说的是：从V1.0到V3.0我们不要走的太快、太急、太随意！为什么我们总是有时间反复的解决、处理问题，却没有时间一次把事情做好？

 

在此要特别声明一点：本文只是为了用具体的事例来说明变更管理的重要性，不针对所选事例及相关人员，类似事例在公司里面还有很多，这里只是偶遇此案，围绕其做一下文章。同是也要感谢负责产品设计的同事对改版过程的介绍及提供的资料。