主题：理想、激情、生存―― 一位技术管理人员的20年工作经历和感悟(四)

11. 建立规则

4 年前，我在读了大量的管理类书后，我得出了一个结论：那就是现代的管理源于西方，被日本发扬光大，再被台湾企业 Copy ，再逐步从东西方多个渠道传到中国大陆企业。我写了有 3 万字的文章发表在中心办的杂志上。不过今天我有新的想法，现代的管理思想有很多源于中国，实际上很多先进的理念都有老子的“道德经”孙子的“孙子兵法”和中国传统文化的影子。例如老子的“无为而治”，与 GE 的“学习型组织”；孔子的“三人行必有我师”和 GE 的“无边界管理”；百家姓中的“人之初，性本善”和 麦克雷格 (Douglas McGregor) 的“ Y 理论假设”；德鲁克 (Peter F Drucker) “发挥每一个人的长处设法使其短处不表现出来，因为人总是有弱点而且几乎不可能改变”几乎与中国的“扬长避短”如出一辙。等等。  说的

在总部并没有给我一些企业文化资料的情况下，我从已往的工作经历中感到了它的重要性，我自己写了中心企业文化的文本，主要选取了同创，海尔， GE ， HP ，北电网络的一些理念。为了大家能够接受，又选了一些漫画家郑辛瑶的哲理漫画做辅助，还选了早期由张蔚，沉冰主持的 CCTV “对话”节目定期放给大家看 ( 买的 VCD) 。用这些做为大家的日常行为准则和培训素材。针对每一条款，同时也做了案例说明什么是我们提倡的，什么是我们不提倡的，什么是我们不能触犯的“天条”。我的体会是一开始就把“游戏准则”说清楚，这样以后容易执行。实际上我在一一面试时会请面试者填一个“企业文化” 选择表，看看每一个人的选择，是否大致符合我们的要求，并且我根据他 ( 她 ) 的答案，会再交流一下各自的看法，对他说清楚今后中心的运作模式。

我们很难说有些行为准则一定是对的，事实上行为准则是根据公司的状况的一种选择和正确的运用。是公司利益和员工利益的一种平衡。我始终认为，没有最好的管理只有最合适的管理，在 A 公司行之有效的管理方法不一定在 B 公司有效，因为背景条件不同。

比如采用“团队合作”或“个人英雄”的做法。面对一个技术难题，在基本上都是新手的 Team 中，我们一定会多用“团队合作”，先大家讨论分析再 Debug 的做法，依靠大家的智能来解决问题。而对一个成熟工程师，我们多会用“个人英雄”的做法，因为可能对他来说，你还没讨论完，他已经搞定了，在这一阶段靠的是个人的力量。而后续，我们还是“团队合作”的思路，会要求他写出 Debug 的思路和方法，以做技术传承。有的工程师不愿意写出来，这就是我们的否决项。不愿意做技术传承的工程师，不能在这个中心工作，这就是我们的一个“天条”。

在建立规则方面，行为准则是一个最基础的东西。没有这些做共识，在做项目时会有很多磨擦产生，那个时候，一方面要解决技术问题，一方面再要讲基本观念就难了。因此在新手的培训期，要花大力气灌输。

第 2 层面的规则是组织架构，职责划分。中心的主要项目是主板和 VGA 卡的研发，我们成立了项目管理部，硬件研发部， PCB layout 部， BIOS 研发部，测试部，人员规划 50 人。我的打算是能够找到一些做为每个部的技术骨干，其它成员按公司要求招聘应届生。我也特别找了硬件方面很有功力的李兴中来做我的助手， BIOS 工程师一直没有合适人选。好在李兴中是软硬兼通，可以代管 BIOS team ，鉴于李兴中还 30 不到，不想管行政事务，只愿意处理技术问题，我们定下了项目管理部除了做 PM 的工作外，还兼管中心的各部日常管理和考核的职责。我写了各部的职责说明书，这样就因地制宜的形成了矩阵式管理架构。我的体会是职责划分的越清楚越利于项目组成员的执行，做事效率也越高，不会出现一件事多人重复做，或者一件事没有人做。有一些公司不愿意在职责划分上花些时间将其定义清楚，而是一味地要员工“主动”，那不是一个好的做法。“主动”仅应该体现在两人职责的交接处，没法写清楚的部分。“做我该做，说我该说”才是一个有序的团队。

第 3 层面的规则是研发流程，技术方法。我们又一次的 update 板卡的研发流程，这一次我们在研发流程中特别加了几个内容，一个是每一环节的工作输入和工作输出；另一个是每一环节的所需标准时间，这个时间是按一个成熟工程师做的时候需花的时间。当项目有差异时，在绩效考核时再评估；再一个是加了每一个子项目的责任人栏目。

技术方法是指 PCB layout 规则，测试方法， Debug 工具 / 仪器使用方法，在写这些文档时，我反复强调了一种观念：这些文档是写给新手看的，要尽可能的写的逻辑清晰，深入浅出。让水平低的人也能看得懂，才是高水平。我还特别找了一些中科院的院士写的科普读物来给我们的工程师做参考。在写每一个测试方法时，我们规定先写需要的测试部件和被测物，再写每一个测试要点的操作动作；再写操作动作后的屏幕反映 ( 剪贴屏幕 ) ，再用斜体写下测试注意事项。这样一份测试方法，一个应届生看了就能做个 6~7 成，剩下的再问有经验的工程师就方便多了。这一方面相关的话题在后面的“技术传承”一节中还会介绍。

第 4 层面的规则是绩效管理。日常绩效考核主要是考核每个人的团队协作和部门公益性事务的执行情况。技术方面我们对项目的每个专业及每个阶段都规定了工作时间和工作品质的考核标准。例如，对主板的 EVT 阶段 ( 设计后第 1 次 ) 做的 Sample ，工作品质的考核标准是一开机就能点亮，功能全部实现，主要性能指针也均合格为优秀；一开机就能点亮，功能全部实现，主要性能指针经过 3 天以内的 Debug 可以实现为良好；开机点不亮，功能，主要性能经过 5 天以内的 Debug 可以全部实现为及格。 ( 制程问题除外 ) 。对主板的 DVT 阶段 ( 设计后第 2 次 ) 做的 Sample ，则除 BIOS 和 Driver 以外，所有硬件问题特别是 PCBlayout 问题都已解决为优秀；经过 3 天以内的 Debug 可以解决为良好； 7 天内的 Debug 可以解决为及格 ( 制程问题除外 ) 。

我们会半年更新一次这些绩效考核方法，对这些内容，开始工程师们不以为然，但慢慢地大家感到了一种方便，一种公平，发现也是一种了解自己水平提升自己的方法。

在我们的沙龙里，做真实的自我。

12. 管理方法

管理有 4 个境界，最高境界是“无为而治”用现在的语言就是建立“学习型组织”，到达这个境界的团队已经高度成熟，会自我调节以适应外部的变化达成目标。 第 2 境界是用电子和网络的手段，制定一系列流程，规则，方法让员工在既定的轨道里运行，使得团队不会出大问题。第 3 境界是仅有粗糙的，不俱备可执行细节的规章制度，执行起来需要个人比较大的弹性发挥才能做事或经常需要请示上司才能做事。第 4 境界是仅有的一些规章制度也被束之高阁，老板发号施令，公司员工基本上看老板脸色行事。这种公司中阶层人员善于揣摩上司的心态，适时调整数据，弹性解释事实；基层员工大多心存“你说你的我做我的” 弹性作业。

我根据公司的状况，希望在研发中心能做到第 2 境界。我比较推崇的管理方法是职责明晰，流程清楚，方法规范，公平竞争。从管理风格上我喜欢直面事实，不绕弯说出自己的观点，尤其是对技术问题。但是这种管理风格我发现效果不好，其负面作用要很长时间直到别人真正了解你才能消除。

管理靠流程，规则，方法这是管理的科学性一面，但管理还要面对人，而人的思想是千变万化的，要选择一种他能接受的方式去沟通，这就需要管理艺术。一个团队需要的这种管理艺术越少越好 , 如果每一个人都能直面事实，不要考虑“面子”，个人利益，为什么还要艺术呢？所以“直面事实”是我们的终极追求。

管理靠流程，尤其是关键流程不能省，我不止一次的碰到科学规律带给我们的惩罚，一个产品从研发到市场，要走过的路，恰似婴儿到成人。我们能做的只是少走弯路，我们不可能跨越某个阶段。当我们没有把试生产的问题都解决，当我们没有把该测的项目都测过，以侥幸心理对待，等待我们的结果往往是“欲速则不达”。当然，管理者要分析判断的是针对一个产品的状况，那些是“关键流程”以及如果要跨越某个阶段的风险评估。

管理靠细致，对作业面的所有工程师“心细如发”可能是共同的个性特质要求。硬件工程师在 Debug 一片板的时候，最基本的是先看有无连焊，虚焊，漏焊和错焊，这需要的就是心静心细。测试工程师在观察，描述一个 Bug 时，心细也是必要条件。因为有工程师在写测试报告时经常丢三落四，特别是把“ ---- 不能 Pass ”，漏写成“ ---- 能 pas ” 分析下来，也并不是不负责任，而是心粗。为此我曾对 2 位粗心的工程师做过一种培训，就是每天花一小时，让他们把一碗黑白混合的芝麻分开，开始几天分开的芝麻总有混杂，尤其是会混杂半粒的芝麻，经 2 周的时间，才真正半粒也不混杂。为了锻炼心静，我们还举行用筷子同时夹起三粒生花生米的训练。

管理靠方法，才能少出错误，我们的软件工程师有时一天 update 几次程序，可往往最后的一次更改，不是在上一次的程序上，错改到上上次的程序上，这是缺少版本号的管理。借助一些规范化的表格，比如设计文件 List ， Debug 分析纪录 List ，试生产 Check List ，测试项目 List ，测试表格等也会保证所做工作不被遗漏。

人的天性容易趋利避害、避重就轻、文过饰非，这是人的心理决定的。尤其是做项目时，心存杂念，一心二用，出差错那是必然的。所以在研发项目中 check 机制的建立是必要的。检查者不是全部重复设计者的工作。重要的是要将全部设计环节中的要点找出。要在其工作输出的重点上检查，这正如铁路巡道工，他在漫长的铁轨上主要是检查铁轨的结合处的螺栓松动与否，并不是等效的在每一米铁轨上平均花时间。根据不同情况，检查时这几点可供参考：要用与执行者不同的方法进行核算；进行试验 / 测试确认；进行新设计与已有成熟设计的类比；对设计文件的审查特别要注意与设计实物的相符合；要设立一些简单易行的验证方法；检查者要做文字记录并保存；检查者要和设计者进行良好的人际沟通，要充分了解其设计思路。

研发工程师的工作特性是需要安静少被打扰，以利于他的思考；而且工程师又往往爱面子 ------ 虽然这不见得是对的。因此借助网络的管理是很好的方法，因为透过网络传递信息，过滤了人的情绪化，而且文字有追溯性。除了 Email ，我们用了 TUTOS 系统来实时管理研发项目中发生的问题和传递信息。这实际上是一个类似 BBS 一样的网络软件，只是具有更多的管理功能，如按项目设置成员和权限，问题目前是处理状态还是已解决状态，并且任何人发布新信息时， TUTOS 系统会有 mail 自动发给相关成员，提示去 TUTOS 系统中看。

在各种研发电子文文件的管理上，先是做好了科学的分类，并且有专人来定期整理和更新，当资料越来越多，后来又考虑开发象搜索引擎一样要能够有方便的搜索功能，这样可以大大方便有效利用，只惜这件事没做完。

对不同层次的研发工程师需要不同的管理，对有项目经验的工程师我基本上是做目标管理，仅看结果；对新手则要更多的关注过程，否则也许就会“翻船”。 . 我对项目管理的成败判定标准是：设计一块主板，如果出现了原理性的错误；或者如果 schedule 延迟了 10 天以上，那一定是管理问题，而不是设计者的技术问题。

对不同专业的研发工程师需要不同的管理，比如对测试工程师，他们工作中对创新要求并不高，更重要的可能是细心和逻辑分析力。我给测试工程师 3 个目标：第 1 个目标是能够按时并一次将被测主板的存在问题都测出来；第 2 个目标是能够对测出的问题做原因分析；第 3 个目标是对测出的问题给出解决方案。完全达到这 3 个目标，可能他需要在这个专业上做 8 年以上。同时为了让测试工程师知道自己处于何水准，我们设计了 2 个考核指针：用每一测试项目所花时间与标准测试时间之比来考核其工作效率；用一次 bug 测出率来考核其工作质量 ( 这个指针得出，需要该产品后续的测试结果，故不是实时考核指针。 )

我们曾经做过全年的统计，在研发阶段和量产阶段对那些看表面现象是技术造成的问题做分析，结果令大家都很吃惊的是有 70% 的问题是在管理环节可以避免的，只有 30% 的问题确实是当时对技术掌握不够造成。我最近接触了一些国内 IT 公司的总裁，发现真正认识到研发中心缺管理的不多，实际上是国内 IT 公司研发中心不仅缺技术同样缺管理。

 

13. 技术传承

当没有其它激励时，几乎任何一个人都是，当他总是在向别人分享他的知识，而得不到别人的知识反馈，慢慢地他会停止这个行为 。所以技术传承要做的好，就要保证技术双向传播，技术共享，各取所需，共同提高。

因为新人多，有经验的工程师少，中心采用了两种培训模式。一种是将研发 PC 主板的硬件技术分成十几个专题，每个专题的题目一般都定得很具体，界定范围，避免泛泛而谈，力争将一个小问题讲深讲透，能够对设计有指导作用，确定题目和内容主要由我和几个有经验的工程师来做。包括新人每人研究一两项，研究时间是利用做项目以外的时间，花 2~3 个月的时间。然后每人轮流讲给大家，会前 2 天将内容发给大家。会议形式是讨论会，会上鼓励提问题，充分交流，报告者自己也可提出自己没有理解的部分的问题。一轮讲完后，再来有延续性的第 2 轮。几年下来，每人都成为某个分支的一技之长者，大家也花较少的时间学到了较多的技术。一种是师徒制，这是传统的方法但也是有效的方法，同时徒弟的进步也纳入双方的绩效考核。徒弟技术能力不够，总是在请教师付，他怎么样使别人一直愿意教他？他可以帮师付分担一些数据收集，整理以及在过程中的一般测试，试验。让师付去把精力放在技术深层次问题分析和思考上，以加速问题的解决。

一个工程师应有技术专长，但更重要的是一个工程师要想具备一技之长，应该有一些基本能力。分析能力就是其一。这么样养成面对问题先分析的习惯？有这样一件事：中心规划了要开发一个加密软件，作为主板的附件。我记起几年前看过的《王选文集》其中的“软件规划”，内容是我迄今为止最有实际指导价值的。我就请我们的一位同事去买，也特别对他说，重点是要看其中的“软件规划”。他是复旦的应届毕业生，跑了一趟上海书城和科技书店，就说买不到，就说没有办法。我当时说给你 3 天时间，买到后再来上班， 3 天都买不到，就不用来公司了，他委屈的要哭。结果在同事的鼓励下，还是又去想办法了。结果第 2 天就买到了。我相信这件事对他刺激是很大的。这里面就存在着对一个任务“分析”的问题。 ( 当然还包含着做事的观念 )

* 为什么要买这本书？

* 有几种方法可买到此书？（应该有 10 种以上方法，你能想到几种呢？）

* 各种方法需要的时间为多少？

* 各种方法钱的花费为多少？

* 对各种方法，先用哪种，后用哪种？

* 哪种方法综合效果最好？

* 当买不到书时，有何变通方法？

这是一件工作中的小事，但良好的习惯靠平时养成。做任何事，当你能够理性地去进行分析，往往就成功了一半，相反，则埋下了失败的因子。有时，即使是成功了，也是一种运气而已。再举例。

在量产的产品中，我们多次碰到这样一个问题：对于主板上的某一个 chip ，有些生产日期的产品在主板做高负荷的测试时，会有批量不良，分析发现是因为这颗 chip 在不同生产日期，因其制程的微小差别和电子元器件本身的“温飘”，造成住板上某个输入或输出的信号偏差超出容许范围。对这类情况，有人认为这在设计阶段不可能被发现的，所以要在产品生产后做比较多的做高负荷测试以后，才会抓出这些问题。应该是这样吗？硬件工程师 在设计时，是不是应该考虑到 chip 参数的上 / 下限的极端状况呢？在承认书中是不是应该明确 chip 参数允差范围？研发部门 . 做测试时，是不是应该做各种在承认书允差范围内的测试？这样都做到了，设计余量足够，问题就会少发生，只会发生超出承认书允差的不良，而这种不良是应由 Chip 供货商 / 制造商来承担的，这可以在签订商务合同时来约束。经过这样的分析，我们可以有这样的结论：设计者应充分考虑 Chip 参数偏差的“上 / 下限”的线路情况，设计端的测试部分应能作参数拉偏极限试验。量产时是不应做这样的测试的，否则问题暴露在制造端，花费的成本就太高了。

类似这样的事例，我们都把它做成了案例，不仅现在用，也作为今后培训新人的教材，因为这些事情绝不是发生在 1~2 个人身上。。

不论对于哪一类专业的工程师，分析能力都是至关重要的。多角度的思维，特别要有逻辑的去分析：要细致地观察现象，按事物发展的客观实际，立论有据，推论合理，不能跳过问题去下结论。要循序渐进，由表及里，不是浅尝辄止。如 1 块 VGA 卡测试时发现花屏，换了 memory 就好了，问题就这样结束了吗？远远的没有，要清晰地描述发生问题的现象：如所用配置，操作的动作，屏幕显示；再去分析真因是原材，设计还是制程带来的问题？ 针对原因要有对策，现在怎么办？今后怎样预防，怎样根除？

有没有分析能力是判断一个低阶技术人员和中阶技术人员的分水岭。分析能力的强和弱是中高级人才的判断标准之一。

“授人以鱼，不如授人以渔”一个成人 IQ( 智商 ) 是基本不能提升的，而 EQ( 情商：综合的分析 / 应变能力 ) 是可以锻炼培养的。我们在传授技术的同时更注重传授方法。把追求“ Know-how ”变成一种习惯。这也是很多新手飞快进步的原因。

除了基础知识的补充，基本技能的培训，我们还尽量的争取让新手早日介入项目设计，这正如在球场上运动员在运动中才能进球。在设计中碰到问题并解决问题，那种印象要比听别人讲深得多。

我后来还兼管了工厂的工程部，用这套办法稳定了技术队伍并由此吸引了很多周边同行厂的工程师来加盟。那些在别的公司互相提防，技术封闭的环境下工作的同事，到了我们这种开放的环境，激发了很大的学习和工作热情。

14. 怎样留人

人在不同的层次要求是不一样的。 1999 年在一个 IT 年会上，王选教授说，他当时开发激光照排技术的动力是看到排字工人那么辛苦，有一股要把他们从繁重的体力劳动中解放出来冲动。他说从来没想到有奖金啊荣誉什么的，他还说”市场的成功才是对研发人员的最大激励”。这一点之所以记得这么牢，是自己十几年前也是这么想。那时没有生存的压力，又受了那么多年的教育。甘于清贫，乐在奉献是那几代知识分子的行为准则。现在说这些，连自己都觉得是在唱高调。

自我需求金子塔理论马斯洛 Abraham Maslow 提出了人有生理，安全，社会，尊重，自我需求这些由 a 至 e 由低级至高级的全面需求，它形同金子塔。这些需求对人来说是逐步的分阶段的

a) 生理需求包括食物温暖住所；

b) 安全需求稳定的环境工作人身安全；

c) 社会需求亲情友情爱情；

d) 尊重需求自我意识增强需要别人的尊重；

e) 自我需求要求自我实现有独立的精神和人格对事物有深刻的认识力。

自我需求就是一种最好的激励。怎样使得大家有工作激情，我的体会是首先要从招聘开始。多年的经验表明。如果一个人做他喜欢做的事，可以省掉很多管理上的要求。他的进步也会很快。我的副手李兴中就是，从中学开始就喜欢电子和计算机有很多知识和动手能力是在工作前就具备了。上班在做设计，下了班休息一下，大部分时间还是在研究计算机技术，工作的内容就是他的爱好。所以选择“做我所爱，爱我所做”的人是最合适的。可是，在目前的社会条件下，大多数人还是为了生存，或者说是为了生存的好一点，才来做 IT 。象本人就是，完全就是为了家庭和孩子能够有一个良好的生活水准。虽然也很勤奋的工作，但我的感觉和李兴中是不一样的，我是靠对一种家庭和职业的责任在支撑。

对处于不同需求阶段的工程师首先要对他们心态的了解。比如对从农村来的应届生，他可能最需要的就是一份不错的工资和稳定的工作，他不怕辛苦。而上海本地的应届生他们没有那么大的生存压力，可能不愿意工作太辛苦。在工作安排时要做相应的考虑，前提当然是，一份耕耘，一份收获。

对已在其它台资公司做过几年的工程师他们可能最需要的是做项目标机会。我们就要尽可能给他这个机会，否则就会留不住人。

对资深的工程师来说，就要有技术上继续进步的机会或者向管理位置发展的机会。我在对技术骨干的态度和做法可能是我做成一些事和他们愿意长期跟我的原因。我的做法是看到有潜质的工程师会专门去有意识的去观察和给他机会锻炼。我往往会破格提拔，以给其大剞量的刺激，激发其潜质。这方面我是做的比较成功的。在同创时从维修工程师一下提拔为测试部的主管的李兴中；在深圳海尔科技将优秀软件工程师宋雅松的工资提的比我还高，让海尔总部领导也说，从没一个部门领导能够为员工做到这个状况，还有在我兼管 ABIT 工厂工程部时发现的 PE 顾峰源。远远不止这几位，事实上这些人确实是出类拔萃的，不论在那家公司都会脱颖而出。

为了大家对工作对技术有热情，在开技术研讨会时，为鼓励发言，我们采用发言计分，纳入日常绩效考核；我们还自编了随机抽取发言人的小软件，以保证公平性。

我们也制定了不同级别的职务说明书，上面列清楚了要掌握的专业知识 / 技能，做项目的能力，语言表达及写作能力等具体的要求。让大家有明确的努力目标。特别是坚持不论资排辈，而是看每人的绩效确定奖励。在这样一种环境下，一批人得到了个人能力的大幅提升。

对成熟工程师我经常提一些需将技术知识贯穿起来的问题，以激励他们把技术融会贯通。象“在计算机上当你按下一个‘ A ’字，键盘有了什么反应，信号怎样传给主板上的南桥， CPU 又起了什么作用？显卡怎么样接受信号传给显示器”？“为什么在主板不能开机时，既能通过改电源电路硬件解决，也能不改电路硬件而通过改 BIOS 相关参数解决”？还有“为什么 PC 有 BIOS ， OS ， Driver ， AP 4 类软件？为什么 TV 没有？”

在珠三角，长三角这两块热土，就外部来说有着大量的就业机会，就内部来说对工程师们公司种种的不适应，造成工程师们的频繁流动，其结果于自己于公司大都不利。我在这 2 个地方都工作多年，所管的研发团队都保持了优秀人材的相对稳定，总体流动比率大大低于同行平均水平。总结起来也觉得并不是很困难的事。第一，一份中等或以上水准的薪水是首要条件，毕竟大多数工程师没有达到“住”无忧的经济水平；第二，有想做的事可做；第三，有技术可学，毕竟市场竞争激烈；第四，所在的部门公平，人际关系简单。如果再提一点高要求，那就是个人有发展空间，公司有发展前景。

15. 两岸工程师

我接触过一些台湾中年工程师，他们谦逊，内敛，专业，礼貌，心态平和。和大陆台湾中年工程师比较，两者对工作的观念方法，处事原则相差不大。而以青年工程师比较，大陆和台湾两者对工作的观念方法相差很大。

目前中国处于社会变革的时期，整个社会显得浮躁。大陆的青年工程师已极少有人愿意“十年磨一剑”。往往做了一年项目助手，第二年就想做主要角色，第三年就要做 Leader 。而且一旦达不到个人目标就频繁跳槽，致使成不了真正的技术精深的专家。而台湾的青年工程师即便是一个普通的测试职位也往往愿意一做十年不改行，成为专家级的工程师。

大陆工程师频繁跳槽最主要的表象原因是外部机会多。其次就是薪水低，学不到技术，公司环境不好。事实上频繁跳槽，在上个世纪的 80~90 年代台湾也是这样的状况。最根本的原因是经济上的压力，眼看着房价节节上升，十年不吃不喝也买不起房，这时应遵守的职场伦理就被丢在了脑后。而所在的公司因为前期投入的培训费还没收回，薪资自然是慢慢的加。这样跳槽就在所难免，“存在就是合理”既然他到外面公司能有大幅度的提薪，为什么原公司就不能做到呢？可能就是这口“气”咽不下去，结果多数还是双方受损，所以如果大环境不变这是公司和个人还继续要承担的阵痛。

大陆年青工程师从学校的教育到社会的现实看到的都是极端的功利性，因此学技术也还是为了改变目前的处境。当公司看出这种风险，又不愿意大幅度加薪，采取的方法就是，技术封闭，技术分段，这就形成了不良循环。

来自草原的人，来自东北大地的人性格大都粗圹，来自江南水乡的人性格往往细腻。地域对人的性格是有影响的。台湾工程师的技术封闭，不太愿意分享还有原因是地域差异带来的个性差异；一般的说大陆工程师比台湾工程师更愿意与外界交流。因为即使都是台湾工程师，他们之间的交流也不多。这从两岸的专业技术网站上也能看出，大陆的技术网站上有很多技术深层的东西。如 [url]http://www.embed.com.cn/[/url] ； [url]http://www.21ic.com/[/url] ； [url]http://www.pcbtech.net/[/url] ； [url]http://www.csdn.net/[/url]

中国文化教育与西方教育最大的区别是缺乏一种建立在逻辑分析基础上的思维。从中国文化传统中演变而来的教育带有过强的“艺术性”，目前中国教育中和报刊上的“隔靴搔痒”文章，是一种不好的示范和引导。台湾工程师比较早的吸取了以西方和日本的在逻辑分析基础上的先进方法，在精细思维，执行层面的细微处体现了长处。

两岸工程师共有的一个问题就是，现在很多公司应届毕业生从学校一出来，就到了研发部门，缺少对新产品的生产制程知识和经验，设计的产品不利于批量生产。原来国企培养应届毕业生，都是先在生产线工作 1 年左右，优秀的选拔到技术科 ( 工程部 ) 再 1~2 年左右，再选合适的到设计所 ( 研发部门 ) ，这样选拔出来的工程师才能研发出方便量产的产品。就硬件工程师来说，不应跳过这一重要环节。

大陆优秀人材在台资企业没有归属感，因为台企虽然都大幅投资建厂，但一个普通的台湾人，就因为他是台湾人就可以做主管，而大陆人材即使很优秀也只能做课长。很难做上去。更不要说象在大陆企业优秀人材有股票等的利益分享。

16. 吃亏是福

我的副手李兴中在公司中总是在忙，请他帮忙的人多，他又是来者不拒。不论是研发中还是生产线上发生的技术问题，他都会帮着做，他跟大家交流时说，看起来是吃亏了，别人在休息，自己还在做事，但是正是因为做了很多 Debug ，才积累了很多经验，否则仅知道原理，没有实际经验，设计的产品还是会又很多不符合生产制程的问题。后来李兴中主导设计的几款 PC 主板的市场返修率，大大低与公司平均市场返修率，这些产品是在同样的生产线，同样的人，同样的材料和同样方法生产的。

我们有一个结构工程师，本职工作事情不多，而我们的测试任务有时很忙，人手不够，我请她帮忙做，每次都是比较勉强。后来因其它原因离职。在应聘新工作时，因结构工程师要经常到模具厂参加试模具，人家看她一个女孩，有那么文弱，都不愿意录用，后来她转应聘测试工程师倒是被录用。这才对原来的多付出，有了新的认识。

我们中心开会，不论是技术研讨会还是项目 schedule 安排会，我都要求会议的纪录要在会后 1 小时内整理完毕发给相关同事。开始助理对有些技术的内容记不下来，我坚持要他做到。他是学软件的，这就逼着他要了解相关的硬件技术，几年下来，他就成了可独当一面的 PM ，而且后来还被别家公司挖去成了研发部门的经理。

一般来说，员工总是追求高薪，但有时未见得是好事，因为你拿了高薪，工作的压力也一定更大，而且在其它同等条件下，你的市场竞争力会降低，而且那个高薪，如果是老板为了解决一时之需，那就更不好了。在公司状况不好时，裁员也是被先考虑的。

总的来说年青的时候，多做事，多经历一些磨砺，即使有些不公平，也不要去计较，不是没一次投入都有回报，但你总是在投入，终是有回报的，抱着这样的心态去面对工作，总会收回所有的投入的，这就是上天不负有心人。

 

17. 设计输入

我们往往要的是一个好结果，这是没错的，但好的工作输出来源于好的工作输入，这常被人忽略。软件行业有一句著名的格言：“进来的是垃圾，出去的还是垃圾”，把好输入关是极其重要的。所以特别把 3 年前在我们中心杂志我写的一篇文章贴在这里。

这里讨论的产品以 IT 行业的板卡和整机为主，也包括软件。设计输入是确定所设计产品的市场、用户、功能、性能、时间等目标，开展产品设计的依据，也是以后验证产品设计是否能达到规定的要求，评定设计质量优劣程度的依据。

1. 设计输入的基本内容

根据 ISO9001 的规定，产品的规划阶段的工作内容均为设计输入的基本内容，如表 1. 列出了各类产品的设计输入内容。在实际项目执行中，特别是规划阶段，设计输入的内容不是一次确定的，也不是一方确定的，它往往需要多次双方协商或反复才能确定。表中的内容是指最终形成的文件。具体如下：

表 1. 各类产品的设计输入

阶段 板卡类产品 整机类产品 软件类产品

A 用户需求 用户需求 用户需求

可行性分析 可行性分析 可行性分析

B 产品标准 / 规格（ SPEC ） 产品标准 / 规格（ SPEC ） 用户说明书

规划 用户说明书 用户说明书 软件需求分析

C 合同要求和技术协议。 合同要求和技术协议。 合同要求和技术协议。

项目任务书 项目任务书 项目任务书

Schedule Schedule Schedule

1.1 用户需求：

1.1.1 用户的分类

有几类用户，一类是外部用户（委托设计）；一类产品是由本公司下达，此时公司就是用户；另一类是合作设计。当用户有充分、完整、清晰的图文要求时，是最佳状况，但实际情况往往不是这样，这就需要产品规划者通过有效沟通，将用户的口头要求或不完善需求进行图、文化的完善，要牢记口说无凭。还要充分考虑终端市场用户的需求。要有“用户的成功”才是我们的成功的概念。

1.1..2 用户需求包括内容

* 功能和性能要求，功能是回答这个产品有什么用？性能是回答这个产品怎么样 ( 包括技术指标、 MTBF)?

* 适用的法律、法规、专利、标准和规范要求；

* 适用的以前类似设计提供的信息（这是指既使用户没提到，但以前的实际经验证明应做到的设计要求）；

* 运行、安装和使用；

贮存、搬运、维护和交付；

物料参数和环境；

处置要求。

设计和开发所必需的其它要求（ Design Kit ,Sample ， Software Kit ect. ）；

应注意，在软件和服务产品的设计和开发中，最终使用者要求的和直接顾客要求的输入，可能特别重要。这类输入应以贯穿后续验证和确认能进行有效试验的方式来表达；

时间要求；

合同要求和相关技术协议。

1.2. 可行性分析报告

可行性分析报告的目的是从设计项目的市场、用户、技术、经济、社会等方面论证其可行性。它包括用户需求分析和市场、技术调研。要多用表格形式来表达。

1.2.1 市场调研

* 市场在哪里（市场容量，细分市场和前景）？

* 用户在哪里（谁需要我们的产品）？

* 用户需要什么样的产品？

* 我们的优势在哪里？（技术 / 价格 / 品牌 / 时间 / 地利 / 政策 / 资金）

* 竞争对手状况（技术状况和市场份额）？

* 我们的目标（技术水平和市场份额）

1.2.2 技术方案

* 采用什么原理、方法、外观、架构、算法、语言；

* 采用什么主芯片、结构、电路、模块、接口；

* 技术关键、难点、重点；

* 关键元器件配套状况（量产否，供货周期，有无成熟应用，厂商实力）；

* 与其它方案的比较；

* 标准化、系列化、专利、兼容性、可靠性；

* 易用性、工艺性、维护性，在线升级；

1.2.3 人员和设计周期

* 需要什么样的人员组合；

* 符合目前人员的状况吗？

* 增加人员可否提高速度？

* 产品设计组外需那些外部支持？

* 开始和结束时间

1.2.4 投资和损益分析

* 设计费用（工资、材料、样板、专用仪器、夹具、模具、差旅费、购专用技术、外包、其它）；

* 产品材料成本；

* 市场推广费用；

* 生产费用；

* 利税；

* 损益平衡点（指销售多少台可收回所有投资，如果是附送产品，要估算其带来的附加值）；

* 敏感性分析（技术、市场、竞争对手变化带来的风险，如何抵御？战争、自然灾害等不可抗拒力带来的风险）；

1.2.5 法规法律的可行性

符合法规、法律、环保规范 , 符合销售市场的民俗、宗教习惯。

1.3 制定产品标准或 SPEC

按照国家 / 国际 / 行业的相关标准制定自己的产品标准； IT 行业有其技术、产品更新快的特点，往往很难制定产品标准，这时可以根据用户需求和可行性分析报告，制定 SPEC ，包括功能和性能，还应包括包装、环境、 MTBF 、安全、环保及引用的标准、规范。 SPEC 要用定制的表格形式；特别强调要经用户签字确认。

1.4 用户说明书

用户说明书要用非专门术语的语言，充分地描述其具有的功能及基本的使用方法；并能够说明特定的情况下的应对方法和注意事项。应特别注意下列各点：

1.4.1 用户说明书应在设计产品前就写，而且是尽可能的完善，这是成功研发产品得到的宝贵经验。特别是对未设计过的新一类产品，在设计产品前就写，是至关重要的（否则极易设计出不符合用户需求的想当然产品）；

1.4.2 站在用户的角度，根据 SPEC 和用户需求编写用户说明书，一份好的说明书应易读易用，让最普通水平的用户读后都能够正确、快速、无误操作的使用；

1.4.3 对一事物的描述，人易接收的程度依次为三维动画，二维动画，图片，表格，公式，文字（有语音辅助更好）。编写用户说明书要充分考虑这个规律；

1.4.4 轻重要分开，逻辑要清楚。如对应用软件的使用说明要明确的表叙：用户应进行的实际操作；屏幕有那些反应；有什么要注意的事项。对这些不同的内容，可用不同的字体、颜色、段落来区分；

1.4.5 当说明书内容很多时，可分为基本功能和高级功能，前几页是基本功能，让用户可迅速使用；

1.4.6 说明书的外观、格式应符合企业的 CI 形象；

1.4.7 说明书应在产品发表时和在研发过程中必要时更新，一般来说，变更越少，体现产品规划越高。

1.5 项目任务书

除了在规划阶段（ 1.1 ― 1.4 的内容和 1.6 的内容）给产品规划人员下达的上述内容任务书，这里的项目任务书是指经确认，可立项设计的项目；

项目任务书内容包括项目名称、设计组成员、启动和结束（可分几大阶段）的时间。

1.6 制定 Schedule

Schedule 的三要素是人、事、时间，要制定完整的具体的，直到 MVT 阶段设计输出的项目 Schedule 。并在执行中适时更新，以符合当前状况。要借助于项目管理软件，以实现科学规范的管理。； Microsoft Project 是一种功能强大而灵活的项目管理工具，可以用于控制简单或复杂的项目。它通过各种图表能够安排和追踪所有的活动，从而对进度了如指掌。而且现在，通过安装在公司的 intranet 或 Internet 上的 Microsoft Project Central ，可以比以往更为方便地与有关人员交换项目信息。如它可以实现子项目的关联性；子项目的重要等级等等。

1.7 特殊性

以上是一个通常项目的设计输入，对特定的项目会有些不同，如有的软件项目需要“软件需求分析”（不是指“用户”）。

2. 设计输入的评审

计算机软件行业有一句著名的格言：“进来的是垃圾，出去的还是垃圾”把好输入关是极其重要的。

2.1 设计输入评审的参加人员

设计输入的评审应有用户（或代表）、管理者、产品规划工程师、产品设计师、测试工程师、采购、销售人员参加。

2.2 设计输入评审的要求

对设计输入的内容应分别进行评审，不完整的、含糊的和矛盾的要求应予以解决，没有遗留问题，再进行下一步的工作。这也是 ISO9000:2000 版的要求

2.3 设计输入的存档

应将确定的设计输入按文件管制的规定存档并保持。

18. 扬长避短

除非经历一个人生大劫，否则人的个性特质是基本不会改变的。有时看起来是改变，那可能只是因为外界的压力，暂时的收敛。

象我的个性是属于面对不合理的事是“疾恶如仇”，说话是直面事实，不怕得罪人；做事是追求完美，一追到底，风风火火，速战速决。象我这类人，在处理一些事的时候，一定有可取之处。如果要说负面的那就是易“得罪人”，工作要求高，给别人较大压力。我处理事时，他第一次出差错，我会和颜悦色地让他注意，第二出同样的差错，我会言词严肃，第三次还出同样的差错，我会忍不住严辞厉色。“对事不对人”作为一种管理理念是对的，但事是人做的，不把做事的方法说给他，不把责任心强调，不分析为什么多次出现这样的问题说给他听，怎么可以？这样对了解我的人而他又有一定承受力，没什么不良后果。但对脆弱的人往往是受不了。我承认在任何情况下都应该和颜悦色，但做不到，我仔细想过我为什么这样，原因应该是两条，一是个性使然，一是强烈的责任心。两者去掉任一条，都不会象我“那么‘顶真’，象做自己的公司一样”，这是我的同事经常说我的话。而且我自己发现，我一激动，思维会特别敏捷，前后事情会在脑子里面全部激活起来。

对多次出同样的差错的人我做过分析，一个是责任心不够；一个是做事的方法或技术没掌握；还有一个不被人注意的原因是，他的“联想能力”能力不够，我发现一些人，确实不是前两个原因出错。主要是他脑子里面不记事，上周的事他记不住，面对眼前的事也不会作相关联想，这样的个性特质往往也不具备并行作业的能力。

实际上，一贯的“和风细雨”式的管理和平时“和风细雨”加上偶尔地“暴风骤雨”式管理，都是一种管理风格，没有对错之分，只是一种选择，因为各种管理风格都有大量的成功案例。

不同特质的人，应该选择做不同的事。有的人爱说话，善于口头表达，也许做 FAE 合适；有的人心细，观察力强，也许做测试工程师合适；有的人心静，做的住，也许做 PCB layout 工程师合适；有的人富于创意，善于“自来熟”也许做 PM 合适；有的人富于创意，善于“自来熟”也许做 PM 合适

“江山易改，本性难移”也许硬着头皮改了个性，他的优点也随之消失。与其化大量时间去修身养性，不如扬长避短去做符合个性特质的事。