|
11.建立规则 在总部并没有给我一些企业文化资料的情况下，我从已往的工作经历中感到了它的重要性，我自己写了中心企业文化的文本，主要选取了同创，海尔，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.管理方法 我根据公司的状况，希望在研发中心能做到第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公司研发中心不仅缺技术同样缺管理。 |
|
|
