臺資企業到大陸，短期主要是為了低價勞動力和降低其它營運成本，中長期是為了占領大陸的市場和在大陸的生存發展。因此臺資企業對大陸技術人員是低技術的定位，他們并不想讓大陸技術人員真正掌握高端技術。臺資工廠紛紛遷移大陸，造成島內工廠大批中低階員工的失業對臺灣研發工程師刺激很大的，這幾乎牽扯到臺灣家家戶戶，控制高技術向大陸轉移也是臺灣政府的政策。因此在臺資企業學不到深層次技術也是正常的了，而且一旦發現大陸工程師的快速成長，出于自身利益的保護，也必然要利用機會、采取一些手段來遏制這種勢頭。?
臺資企業在大陸的管理干部換人是頻繁的，我了解的一些公司部門主管基本上一年換一個，并且還有同時派了2個主管來，讓下面的工程師無所適從，還有一些臺干依靠權力在做管理，這都給工程師都留下了不好的感覺。在人際關系方面，臺資企業有與國企一樣的弱點。我在ABIT蘇州研發中心常務副總經理位上一做4年多，而且還兼職ABIT的工廠——“羅禮科技”的工程部協理，是個例外。這不僅是指時間，還指職務，在臺資企業大陸的干部，一般做到課長就已經碰到了?“天花板”，這實際上也是大陸優秀人材把臺資企業作為跳板的原因。?
臺資企業到大陸，公司高階干部清楚的認識到這是企業長期發展的必需動作，但中層和以下干部多數沒有做好這個準備。他們還是沒有做長期的打算，也不和大陸員工做比較深入的交流，他們的交際圈子還是臺灣人，并沒有想融入當地社會。
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年代臺灣也是這樣的狀況。最根本的原因是經濟上的壓力，眼看著房價節節上升，十年不吃不喝也買不起房，這時應遵守的職場倫理就被丟在了腦后。而所在的公司因為前期投入的培訓費還沒收回，薪資自然是慢慢的加。這樣跳槽就在所難免，“存在就是合理”既然他到外面公司能有大幅度的提薪，為什么原公司就不能做到呢？可能就是這口?“氣”咽不下去，結果多數還是雙方受損，所以如果大環境不變這是公司和個人還繼續要承擔的陣痛。?
大陸年青工程師從學校的教育到社會的現實看到的都是極端的功利性，因此學技術也還是為了改變目前的處境。當公司看出這種風險，又不愿意大幅度加薪，采取的方法就是，技術封閉，技術分段，這就形成了不良循環。?
來自草原的人，來自東北大地的人性格大都粗壙，來自江南水鄉的人性格往往細膩。地域對人的性格是有影響的。臺灣工程師的技術封閉，不太愿意分享還有原因是地域差異帶來的個性差異；一般的說大陸工程師比臺灣工程師更愿意與外界交流。因為即使都是臺灣工程師，他們之間的交流也不多。這從兩岸的專業技術網站上也能看出，大陸的技術網站上有很多技術深層的東西。如?http://www.embed.com.cn/；http://www.21ic.com/；http://www.pcbtech.net/；?http://www.csdn.net/?
中國文化教育與西方教育最大的區別是缺乏一種建立在邏輯分析基礎上的思維。從中國文化傳統中演變而來的教育帶有過強的“藝術性”，目前中國教育中和報刊上的“隔靴搔癢”文章，是一種不好的示范和引導。臺灣工程師比較早的吸取了以西方和***的在邏輯分析基礎上的先進方法，在精細思維，執行層面的細微處體現了長處。?
兩岸工程師共有的一個問題就是，現在很多公司應屆畢業生從學校一出來，就到了研發部門，缺少對新產品的生產制程知識和經驗，設計的產品不利于批量生產。原來國企培養應屆畢業生，都是先在生產線工作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合適?
“江山易改，本性難移”也許硬著頭皮改了個性，他的優點也隨之消失。與其化大量時間去修身養性，不如揚長避短去做符合個性特質的事。?
轉自TOM論壇
posted on 2007-03-26 08:56
matthew 閱讀(565)
評論(1) 編輯 收藏 所屬分類:
所感所悟