一开机就能点亮，功能全部实现，主要性能指针 也均合格为优秀；一开机就能点亮，功能全部实现，主要性能指针经过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”变成一种习惯。这也是很多新手飞快进步的原因。
除了基础知识的补充，基本技能的培训，我们还尽量的争取让新手早日介入项目设计，这正如在球场上运动员在运动中才能进球。在设计中碰到问题并解决问题，那种印象要比听别人讲深得多。