品质漫谈设计品质Word文档格式.docx

品质漫谈设计品质Word文档格式.docx

《品质漫谈设计品质Word文档格式.docx》由会员分享，可在线阅读，更多相关《品质漫谈设计品质Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

　　中小企業的〝產品企劃〞通常是老闆一手主導掌控，因老闆經常到處跑，市場与客戶狀況最了解，全公司沒有第二人比老闆更了解客戶，當然老闆說什麼就做（設計）什麼，這叫做〝人治〞，只要靠單人的感覺、意志做事，就存有較高的盲點、風險，這也是一種歷史軌跡，不容懷疑！

而〝法治〞是需要有流程概念，即最簡單的〝輸入（Input）—過程（Process）—輸出（Output）〞三階段，以產品規格訂定為例，輸入條件必然是：

1.市調結果2.現有客戶的反應3.科技的技術成熟度4.支援的週邊環境5.產品定位、策略6.我公司和他公司現況能力，而過程是需要把客戶要求品質和相關的品質特性分階段展開与相互配對相關程度，加上現況能力比較，於客戶角度就可以建立行銷策略、重點，從品質特性角度就可以建立〝規格特性比較表〞，最終的輸出即為簡略的骨架規格（另稱〝工程規範〞），再經整理和補充敘述，就成為正式的〝產品規格書〞；

中小企業因人才、時間限制，以上流程通常省略，而以老闆個人感覺與意志，很快訂出產品規格表（是〝表〞，不是〝書〞，請注意！

），這就是所有亂源之始！

2.設計品質做好，會影響開發進度

　　曾有一家上市通訊產品公司，老總有感設計品質問題很多，已影響正常營運，希望外部顧問能協助解決，為能提高研發人員共識，做了一些意見調查，居然大部份研發工程師提出〝設計品質做好，開發行程會延誤！

〞，而老總為了要求開發行程，居然也默認不再要求設計品質！

這種研發工程師〝設計品質做好，開發行程會延誤〞說法，於不同企業經常耳聞，這種似是而非的真實用意，應是設計工程師對開發時程的反彈，不是有意把設計品質做差，開發行程就可以如期完成！

從反向思維，反而是：

「品質做好，會增加成本嗎？

其實反而可降低成本！

」、「品質做好，會延誤交期？

其實反而對交期有利！

」、「品質做好，會影響效率？

其實反而能提升效率！

」、「品質做好，要多投入人力？

其實反而能減少人力！

」，請深入了解，設計品質做好，一開始就做對、做好，當然做錯、重來、修改的機會少了，就可不必投入額外資源（工程師人力），自然對開發時程有利，甚至還可以提早完成產品開發呢！

3.每日皆到責任工程師分別了解進度狀況，因此我可掌握開發進度

　　若訪談中小企業研發主管，〝你如何掌控開發進度？

〞，幾乎本節主題是他們的標準答案，好像每日分別到各處查訪、探班就可以掌控進度？

！

這叫上對下單線指揮（或指示），橫向整合完全透過主管傳達，不但無法与時又會失真，對整個專案發展沒有助益，案子複雜，阻礙愈嚴重！

科技產品的研發通常需要下列不同的團隊成員：

電子工程師、外形設計工程師、機構工程師、軟體/韌體工程師、安規工程師、測試工程師（含可靠度、驗證）、行銷工程師（或售服工程師），因此極需團隊分工合作，彼此要有高度即時溝通和默契，其間又需要有人去整合，不但要注意開發進度是否如期（依計劃進度）、問題如何解決、資源有否需調整，而且必符合原先訂定的產品規格，才能依〝產品定位、策略〞主軸方向行銷，所以團隊成員彼此要有溝通默契，而且主持人又要有很好的整合能力，開發進度才能在既定的軌道上，逐步完成！

因此研發主管或專案主持人（ProjectLeaderorProductManager），應有定期的專案檢討會議（ProjectReviewMeeting），科技產品每週至少乙次，由團隊成員分別上台報告開發進度、問題概況、對未來影響評估等，主持人要能利用專案計劃管控軟體（如PERT/CPM），依實際狀況用人工或電腦去評估整體計劃的瓶頸在那裡，可否符原預期，有否復原預備計劃（RecoveryPlanorBack-UpPlan），團隊成員間的問題如何化解，提高問題解決能力，於非會議時間，不同屬性工程師應保持高度機動的〝問題檢討〞（BugReview），二人与以上不限時間、地點即可相互討論，相互激盪思維才能產生創新突破的解決方案，這就是如何掌握開發進度的方向，細節再另行說明。

4.設計工程師會詳細測試所有設計樣品，以保證設計品質

　　本小節主題聽起好像正確，若沒有進一步第三者的測試，那就是問題所在，很簡單：

〝設計者是球員，測試鑑定者是裁判〞，若同1人當然看不出問題！

這種球員兼裁判於中小企業的研發單位到處可見；

記得台灣於1970年代，剛開始接受國外代工，當國外客戶詢問如何保證產品品質時，當時的企業主經常會答覆：

我們每一位作業員就是檢驗員，自主檢查保證好產品才出貨！

乍聽之下也好像很合理，如果沒有品保單位，全權由生產單位負責〝質〞和〝量〞的話，那也是〝球員兼裁判〞，事情是做不好的！

其實這兩種說法的本質是一樣，只是時間、人物和單位不同而已，這叫〝歷史重演〞，到處在我們的社會上演，更何況中國大陸的社會發展，也正在走台灣的歷史，因此我們可以很清楚看到中國大陸的機會在那裡，從設計品質角度，設計工程師完成產品某部份開發，當然要自行確認（稱〝Self-Test〞or〝Pre-Test〞），若自己認為可行或滿意，就需交〝專業的驗證測試者〞，其有更專精的儀器、設備与人才，從使用者環境与可能的意外狀況，給予客觀評價，球員和裁判本來就是不同人，說得更嚴謹是〝被告和法官〞決不可以同1人！

因此於設計樣本的驗證測試單位必然是獨立的不同族群，於不同節次會有更詳細的說明。

5.設計樣品由老闆親自審視，若可以即交生技單位進行生產準備和試產

　　中小企業的設計審查由老闆親自操刀，是很普遍的事！

但要知道老闆身兼多職對產品審查當然憑感覺，不夠深入，縱使有召集會議，只要老闆先表意見，其他人只有配合逢迎的份，以前曾提過〝只要單人決定，就存有較高的風險！

〞，因為每人皆看不到自己的盲點，只有從多元角度各表看法，經分析、比較方為客觀，上述人治的設計審查，也應予法治化，即事前設計要查核項目（CheckList）、產出為何、參考或測試資料、該項目的責任者等，予制度化，於審查時由責任單位分別報告審查看法，相互討論，此階段是否符預期標準（目標），老闆全程參加，最後才發表意見与最終裁決；

至於何時可試產的決定，除了依開發流程外，最重要的是不可以有未知的設計問題，否則生產越多問題就越大，就虧大了！

當然做可否試產的決定，基本前提必須完成產品驗證測試工作，不同階段有不同的目的和驗證範圍，其報告參考價值高。

6.試產良率是工程單位（製工/生技/產工）的責任，和研發設計單位無關

　　產品開發過程就如同跑接力賽一樣，從產品企劃→研發設計驗證測試→試產→試銷→量產，而試產良率狀況，也可以了解未來大量生產是否穩定，大致可看出此產品是成功（暢銷）或失敗（滯銷），從系統產品而言，良率和各工程單位有直接關係（如ME/IE/PE等），自然就認為試產良率是工程單位的責任，此為〝似是而非〞對流程概念不清所致，試想〝試產良率〞就是前流程的設計品質總體績效表現，理論上是沒有設計問題，只有生產熟悉度与零件問題，所以試產良率至少應有穩定量產水準良率的八成以上才對，若明顯差異太大，即可解讀為設計尚不成熟，自然是研發設計單位的責任，甚至可以用〝試產良率〞為〝設計品質〞的績效衡量指標，雖然試產也是設計和工程單位的責任交接時段，畢竟設計幾近交棒，而工程正好要接棒，所以其（試產）良率才是設計單位的成續單，許多公司不明白其道理，反而把良率低怪罪於工程單位，無怪乎設計品質怎麼做也做不好！

7.〝量產性〞即設計樣品經仔細調整与測試，且全部合格者

　　當我們用心去訪談10個公司研發設計主持人，問与如何把量產性設計進去，幾乎將近八成以上的主持人，會回答〝保證所有樣品測試皆合格〞即表示有量產性，此膚淺認知可以說完全不了解〝量產性〞特質，它就是很容易大量生產且不易出錯，例如：

1.螺絲愈少愈好，甚至沒有2.調整愈少愈好3.作業時間愈短愈好4.疏失機會愈少愈好5.產品特性愈穩定（標準差小）愈好6.容易測試、偵測愈佳7.愈方便維修愈佳8.傻瓜都不會做錯更好9.少用人工，多用自動化更佳10.模組化拆裝容易，減少失誤更好。

於本文曾說明的設計品質範圍七個項目，若相互有衝突時，研發單位通常會犧牲〝量產性〞，因為通常研發人員較不了解生產且〝好生產〞的受益者是生產單位，和研發單位的績效考核無關，只有極少數非常精緻的研發機能才會在意量產性問題，進而會根據以往生產經驗，整理出查核表做為設計準則之一（DFM,DesignforManufacture），於產品驗證亦列入必查核事項之一，但因產品線的量產性差異大，所以查核表（CheckList）建置應考慮不同產品的適用彈性，目前世界級公司已如此做，國際大型台商正在建立中，除了查核表建置外，於產品量測特性部份，若設計樣品足夠（10件以上），宜利用統計概念計算製程能力（Cp&

Cpk）与超出規格的機率，此亦為量產性衡量方式之一。

8.〝別單位提出一卡車問題，他們行由他們設計好了！

我不幹可以吧！

〞

　　當設計品質不佳（其實事前考慮不周詳所致），於設計審查時提出一堆問題，研發當事責任者，工作壓力過大，就造成情緒性反彈，通常較常見的有：

〝我不幹了〞、〝給你們設計〞、〝你們行，你們來做〞、〝為什麼不提早告知〞、〝不行，那我改規格〞、〝你們不會測，那樣做是不對的〞、〝你們亂測，我不予回應〞、〝你們不按正常使用，東西弄壞還要求對策〞等，因此除了物性設計外，設計者本身的人格特質也很重要，希望是成熟的不情緒化、抗壓性好、EQ高、開放性不封閉思維、能廣納資訊胸有成竹，反之就很難溝通，只要火車頭（研發）不動，只有原地踏步再急也沒有用，故研發更需要有人文、社群等活動，增進人與人的交流、了解、接納、欣賞、尊重的特質，無形中對創新与解決問題會有很大助益，工程師容易陷入技術框架內，若能適當引導有市場（商機）概念与管理（人性）能力，將可成大器承擔科技產品事業責任者，回顧國內外成功的科技企業主，幾乎都是工程師（技術）出身，加上敏銳的市場概念和優良的管理能力！

有眼光的企業主，不應只強調研發單位的技術能力，需設法輔以人文和市場概念。

三、何為正確的〝設計品質〞觀念和執行方法

1.如何建立產品規格

　　前負面表列的產品規格以〝人治〞建立是不好的，那麼如何建立才適當？

於此先說明建立流程於下：

市場要求之

分析和評估

►

工程規範

（簡要總整理）

產品規格書

（詳細說明）

產品驗證測試

評估計劃書

∙1.1市場要求之分析評估，從市場調查了解〝市場環境〞、〝事業機會〞、〝技術趨勢〞、〝競爭資訊〞、〝市場定位〞進而訂定產品各種可量化的目標，目標尚需進階檢討才定案，此產品目標含：

使用者定義、使用者環境、產品機能目標、使用性目標、時程目標、維修目標、品質目標、可靠度目標、成本目標、投入資源目標等。

∙1.2工程規範，即經上述分析評估与競爭公司產品比較後，訂定的初步規格，為表列式，視產品複雜度，此工程規範大約3±

2頁，表達產品規格概況。

∙1.3產品規格書，為對每一項規格項目詳細說明（含定義、接線、量測、程序、允許標準、參考標準），以資訊電子產品為例，其規格書內容至少