做QA應該是水無常形，兵無常法。Checklist、指標僅僅是冰山一角，最關鍵需要建立的是人對產品質量態度和責任感。我們經常分享結果（模板、流程），為什么做和如何思考做這個事的思維方式更加值得分享，明白當初為啥做這個事，才可以促進態度和理念的復制，否則只能模仿形而失去了最重要的神。當然，各個優秀實踐，可以作為一種案例可以進行貨架化知識管理，便于查詢。
§實踐篇§
Ascend P1 是我司的第一款旗艦機，高層期望開始創造華為的品牌，責任重大，同時AP+modem第一款商用，HAP 5.2 首款商用，首款LCD/TP一體式來料，華為最薄設計，N個固件新器件…… 困難重重。 最要命的是，Ascend P1 半路接手，同時要求項目提前計劃2個月上市，跟著項目組走過了最瘋狂的一段時間，本著找到關鍵的20%，重點突破，小循環逐步改進的工作思路，做了不少嘗試，有好的結果（我們贏得了100萬，），也有不好的結果（改版次數多，VS試制流程執行不到位），回首看看，有的也有失，簡單總結一下給大家分享，歡迎各位方家批評指正。
一、 確定項目質量工作的思路：
認清現狀:
1、 上海團隊第一次做智能機，能力不足（北研團隊軟件人均問題單修改能力是1.5個/天，上海團隊最多就是1個/天），項目團隊對項目保質按期交付還是存在疑慮。
2、 Ascend P1是華為公司第一款旗艦機，余總及其重視并且要求提前上市，提出提前2個月交付的要求，并許諾200萬項目交付懸賞獎（100萬/月），版本經理比較狂熱。
換位思考，明確工作思路：
“項目團隊不是不希望改進和提升，更多的時候是他們遇到問題不知道如何去改進。”
終端是強項目交付牽引，但是項目運作又是強資源矩陣（至少目前是），項目交付應該還是第一位的，整個項目團隊的成員都還是希望能夠按期交付，按質量要求交付。
新軟件平臺，新硬件平臺，新項目定位，一定會遇到問題，而且是一堆的問題，拿著質量的要求、標準去要求團隊達成，是一種質量人員的做法；融入到項目運作中，切實的協助項目組識別關鍵問題，解決運作過程中的問題，也是一種質量人員的做法。
項目按期交付，拼命往前沖的大勢無法阻擋，那我寧可選擇融入到項目團隊中，實實在在的將產品質量做好，切切實實的將項目運作過程中的問題解決。雖然將面臨一堆的問題，但是我陽光總在風雨后，不經歷痛苦，哪能感受幸福。 ^_^
找到問題關鍵的20%，集中優勢兵力重點突破，采用小循環的方式逐步改進，成為和U9200一起奮斗過程中的主要工作思路。
二、 扮演好幾個角色：
1）剎車人（狂熱隊伍中的冷酷者）
如果說質量中最不愿見的是“變量”，項目管理中最不樂見的是“變更”，那么項目運作過程中最害怕的是“狂熱”，團隊一旦開始狂熱，如果不及時的剎車，那么項目運作必然失控。
前段時間我們HR祈宇，和我交流時說：“如果別人離職，我可能還會想法挽留一下，但是你小子太冷酷了，要么不干，要干就一定想清楚了，而且是無法被動搖的。” 沒錯，在狂躁的項目運作過程中，你一定要冷靜，甚至冷酷，要仔細觀察，認真分析，撥開迷霧看到本質，因為真相只有一個。
? 音頻TDD改版
TDD是系統性問題，TR4A后出現了反復，修改音頻問題，結果導致射頻性能出現了下降，因為需要提升射頻性能，達到公司要求的余量要求，急著要改版。
要保證修改的有效性，因此直接回的郵件“不同意改版，需要將修改方案評估清楚”（可惜原郵件找不到了 ^_^）,拉上射頻有線、天線、音頻、硬件基帶的人一起評估修改方案，現場討論中發現了幾個新問題，重新進行方案驗證……
Tips：
各部門的研發兄弟都有一個向上的心，都希望自己的領域沒問題，往往容易犯顧頭不顧腚的毛病。我們希望各領域優秀，但是我們更加希望產品是優秀的，因此就需要取舍和平衡，作為PQA應該系統的去思考問題，要引導產品達到最佳的平衡，當然建議在平衡的前提下，也可以獲取某方面的最優化（賣點、亮點）。
在交付壓力的牽引下，一定會想方設法的去趕試制，但是多次試制更多的可能是帶來資源的耗費，畢竟華為公司每個項目上的資源并不充分。要冷靜對待問題，珍惜和把握每一次機會。
心若冰清，天塌不驚；
萬變猶定，神怡氣靜；
塵垢不沾，俗相不染；
虛空甯宓，渾然無物；
無有相生，難易相成；
份與物忘，同乎渾涅；
天地無涯，萬物齊一；
飛花落葉，虛懷若谷；
千般煩憂，才下心頭；
即展眉頭，靈臺清幽；
心無罣礙，意無所執；
解心釋神，莫然無魂；
水流心不驚，云在意俱遲；
一心不贅物，古今自逍遙！…… ——《風云》中聶風的冰心訣
豐田的案例：
大家都知道豐田汽車公司，可能這家公司是當今社會被人研究最多的企業之一。該公司的經營和管理哲學獨樹一幟，其中最著名的管理模式是“豐田生產方式”（TPS），業界稱為“精益生產”。“豐田生產方式”的核心是PDCA。有人說，當一個典型的美國公司遇到一個問題的時候，如果這個問題必須在一年內解決，該企業會用3個月來做計劃，用另外3個月來執行，再用6個月來做微調，處理遺留問題。而豐田在面對類似形勢的時候，會用11個月來做計劃，用1個月來實施（根本不會留下任何遺留問題）。這種說法雖然比較夸張，但是它體現了豐田對于PDCA的獨特理解和經驗總結。豐田人認為：計劃至關重要！只有徹底的計劃（從多個角度全面了解了形勢、準確地發現了問題產生的根本原因、考慮可能發生的各種變化、以及參與者的認可或者上級的批準后），實施、檢查、處理的結果才能高效達成預期的目標。
?
2）公正的中立人(公正公平，但是一定要保持中立)
質量人員在華為的定位是中立的，因此總會有這樣那樣的糾紛問題要質量人來仲裁，希望得到中立的評價意見。當然在研發內部出現類似情況仲裁還可以，因為我們畢竟還呆在研發區。但是對于出現跨研發領域的時候，和大供應鏈體系（制造&采購）交流的時候，供應鏈體系經常認為我們是屬于研發體系的，容易存在略帶敵對的和我們交流。如此情況下，我們應該如何的處理？
?
Tips:
我分享一下我的做法：
1、首先是澄清具體問題，不要和對方陷入到度量指標，考核指標的漩渦中去（影響產品的具體問題都已經解決了，指標不滿足要求也難）。
2、對于問題要制定應對措施和具體責任人，從問題后續的實際表現去評估活動是否有效和相應的進展（避免出現活動做了，但是沒有效果）。
3、該踢一腳的還是要踢一腳（忍無可忍無需再忍），當時言辭要客觀，避免采用主觀類的語言（這個時候就需要體現質量人的專業素養了 ^_^）。
?
U9200-1 TR6直通率問題 案例：
TR6的時候最容易遇到的就是因為直通率問題，制造體系和產品較勁。U9200-1 爬坡后，為了解決直通率問題，研發體系一直是有人制造現場的（具體的派兵布陣也有一個小實踐，在后面和大家分享），組裝段的一次直通率從爬坡的20%，一直穩定到了85%以上，而且還有不斷上升的利好趨勢。當時因為SMT段的一次直通率低，而且不穩定，直接導致全工位一次直通率就被拉到了80%以下，而且極不穩定。
客觀公正的給制造體系的各位老大分析了一下U9200-1的直通率趨勢，和TR6的一些要求，SMT段的問題很快得以控制和解決。
?
我發的郵件：
制造體系回復的郵件：
鄒總的郵件：
?
制造代表主導直通率提升:
三、 一點點實踐，一點點認知：
1） 關于產品質量評估：
產品質量評估是QA是一定要做的，但是如何做，各地有各地的模板，各人有各人的習慣，我的思考和寫作方式分享給大家，請各位方家拍磚。
質量評估對于領導們來說，是希望看到一份產品質量狀態的全貌，能夠包含產品各方面的完整信息，它除了用于領導的監控，其實也應該是很夠很好的引導版本經理規劃后續的重點工作，因此可以聯合版本經理一起來寫，在寫的過程中，同時也是對項目狀態的一個梳理。第一期可能比較困難，當時后面的只要逐漸更新即可。
我們寫一份報告，首先需要列清楚需要體現的維度，然后是收集寫作素材（往往會有現成的素材），最后再用客觀語言來表述。原始的素材不一定需要重新開始，往往周圍的領域已經有人在做了，因此要注意積累渠道和信息源。 積累人脈和渠道的最好方式是分享，將你的工作成果和他人分享（包括業務部門的人），尤其是提供信息給你的那些兄弟，并且要心存感激。 —— 有感于李志《其實你不懂項目管理》
對于產品質量狀態，我通常會從如下的角度思考，當然針對不同的項目背景，所處階段進行調整，這個需要從實踐中積累經驗。
?
需求實現：在TR4之前需要重點關注，尤其是軟件需求。可以聯合SQA做些事情，Ascend P1就很感謝于姐姐，組織軟件、測試、SE等領域做了三次需求實現梳理&排序，明確下來哪些必須在啥時間點完成，哪些需要CCB裁剪。因為需求的顆粒度不同，很多細節上把握不到，Ascend P1需求評估會上明確哪些可以裁剪、哪些必須實現后，對于實現過程中的細節問題，允許通過CCB的方式進行裁決。（對于渠道銷售的可以參考操作，對于運營商定制的，一定要和運營商PK，北京這點應該做的挺好，上海火候還差點。）
軟件單元測試：現在項目都敏捷了，單元測試如何做，如何評估充分性，沒有啥心得，我一般都咨詢SQA。
硬件單元測試：主要關心沒有測試通過的項目，對于新器件的驗證情況也需要重點關照，我沒有現成的Checklist，更多的是和開發人員、器件組負責人交流驗證方案和結果。建議多看看硬件組器件相關的案例，測試對于器件替代的方案，供應商器件出廠的測試要求，帶著疑問去和器件組的兄弟們交流（我作為QA參加過LCD、音頻的器件組工作，梳理過音頻流程、整理過音頻小組的運作方式。），花點功夫在平日，積累交情的同時也能學到不少東西。
硬件測試（含可靠性測試）：除了關注測試的結果和發現的問題以外，我更關心的是測試的覆蓋度（所有用例是否都覆蓋，V試制和VN試制是否都完成應該的測試覆蓋）和問題發現趨勢（如果前幾次測試沒有問題，但是后面有問題，一定會追問一下為什么），歷次修改方案也需要和測試用例進行一個比對，防止方案遺漏。Ascend P1 這個工作其實是我提供想法，工具表單的支撐，數據整理工作基本上都是硬件測試接口人做的，需要感謝一下陳雪蓓MM。
軟件測試：前期更多地都是關注DTS上的問題，Ascend P1因為和Ascend D1是同軟件平臺，所以修改問題評估的時候一直是一起評估的，盡管工作量大點，至少避免了遺漏。其實還有一個不同軟件版本的關系樹可以參考，軟件組兄弟應該是有在維護的，我前期基本上是通過交流獲取方法，去確定評估方案，最后看到這個樹的時候，后悔了好一陣子。這個樹可以幫助QA理清楚問題評估方案，以及關鍵問題的修改合入策略，簡單有效。
準入測試、Beta測試、現網測試：這個是測試經理制定的，只是在方案確定的時候，需要和測試經理交流一下，我是借用的信息。就是在識別和評估發現的主要問題上和測試經理交流了不少。
Ascend P1測試這塊的信息基本上都是測試經理錢群JJ總結的，非常全面&完整，我就是應用&提煉。
試制問題：DFx or 試制代表手上有非常完整的試制問題清單，最好Review一下，根據經驗判斷一下那些是TOPn和必須解決的。我有幾年制造端產品質量管控的經驗，所以判斷相對比較容易，其實就是判斷此問題是否影響產線效率，因為產線進行的是機械的、重復的操作，簡單的才不容易出錯，高效的才容易落實，對于產線問題處理要記住“簡單就是美”，所以解決方案重點要思考工具&方法的輔助，盡量減少配置或者選擇。其他的問題比例、危害度之類的需要辨證的看，不要被數字欺騙，PQA有機會還是多去產線轉轉，經驗還是需要積累的。
Ascend P1 有一個關于返工的優秀實踐，對于產線上出現的故障機維修后，統一升級軟件到PT測試之前，然后直接往下走流程，深得制造兄弟的喜愛，因為沒有那么多狀態需要控制。對比北研的返工升級方案，每個測試工位的工具都有返修流程設置，我們研發的角度想，是給了你很多的選擇，可以從不同的工位進行返工，但是我們似乎忘記了，產線玩的是海量制造，不是手工作坊，原則越多，產線不同的產品狀態越多，越不容易控制，越容易出現疏漏。如果簡單的到只有一種返工方式，那么我們核心需要改進的點就是如何減少返工，而不用關注如何增加返工的途徑。
物料問題&器件驗證：影響產線的制程問題從試制問題清單中單獨拎出來，還要關心的是器件驗證的情況（新器件引入&器件替代），直接在PDM上看BOM編碼的發放情況就能知道器件驗證的進展，然后有針對性的去咨詢相關的責任人。
問題單：P1這個軟件新平臺到目前為止一共發現了14K以上的問題，分布在P1、D1不同的子版本上，還是花了一點小心思的，后面再細講。對于質量評估而言，要體現一個整體的趨勢（問題發現趨勢，遺留問題趨勢，DI趨勢……），根據展示即可。不要忘記了，調處你認為最關鍵硬件、軟件、制造類問題明確的寫出來。
市場：這個基本上是版本經理在關心，我了解相關信息，只是用于調整相應活動的開展方式。質量評估上基本不涉及。 ^_^
收集完數據后，就需要整理成文章了，可以看看下面兩個膠片，學習一下應該如何匯報和延時，附了一份早期的產品質量周報。
?
一份好的質量評估報告，其實是可以被復用的，我寫的P1質量報告就被用于給余總萬總的匯報，EDCP發貨的評估。一份好的質量評估報告，首先要有一個好的框架，第一份可能困難點，但是后面的話就是不斷對信息進行刷新。（多么希望后續產品的信息可以集成化在一個系統中，方便查詢和展示）
?
2）項目問題&風險跟蹤：
對于FP時代，產品開發規模小，一個項目組例會就可以Cover，但是我們已經步入了智能機時代，開發Ascend P1 這樣一款旗艦機，曾經開玩笑的和版本經理數過人頭，FP的30個人，已經演變成了300人以上的隊伍，還是一個項目周例會解決問題的效率會比較低下。
P1 采用的實踐是每日站會的方式，各領域代表將各領域前一天的工作進行總結，將這一階段的主要問題進行反饋，五角經理輪流主持（雖然能夠起到練兵的作用，但是也有不好的地方。），統一寫在白板上，進行信息共享和展示（不知道會不會有信息安全隱患^_^）。
項目問題、事務、風險統一跟蹤，采用Excel自帶的共享工作簿功能（不會的同學自己百度、Google，打電話給我也行 ^_^），項目組全員共享，每個責任人對自己任務進行進展更新，支持多人同時更新。
?
待改進點：
1、 項目在一開始的時候還是有一個FMEA的項目風險跟蹤表，我是中期介入的，沒有很好的延續用起來，盡管我將遺留的未關閉問題已經放到共享工作簿中，但是后面的監控沒有做起來，執行效果不是很好。
2、 每日站會的效果不錯，但是五角的主持風格和思路不太一致，內容更新上延續起來比較差。
3、 各領域的信息匯總各領域代表各有風格，信息不能很好地實現對接，靠單人力進行拉通，工作量巨大。
?
改進建議：
1、 各責任人需要將跟蹤起來，項目POP可以作為跟蹤責任人。最關鍵是，要跟蹤的事務和項目各領域代表日常工作銜接起來，利用這個牽引各領域代表開展項目工作。
?
2、 五角都比較新，能力需要培養，如此方式可行，但是要統一會議主持的規范化內容（具體哪些塊內容需要問），在白板上的謄寫規則也要有大的定義，更換周期不要太頻繁，雙周或者一個月換一個比較靠譜（雖然說68天是讓人養成一個習慣的建議時間，當時偏長了因此借用以前高考中的一個推薦記憶方式7天一學習周期，7天一復習周期，隔2周一個再復習周期）。
?
3、 各領域的日常事務跟蹤和項目的能夠進行匹配，最好統一使用項目集成跟蹤表的格式，便于后續的復制粘貼，如果能夠實現系統化就好了（PLM項目的時候，有幸和三星顧問交流過，三星當前基本上用的就是一個系統進行項目任務的跟蹤，羨慕中）。
?
3）DTS問題：
DTS 問題單是每個QA都需要關注的，那么應該怎么看？
1、 問題單看是要看的，對于智能機那么多問題咋整，首先要學會的是增量的看。DTS問題單號都是體現了一定的順序，上次看到哪個了，下次從下面一個看起。或者借助工具標示出來哪些是新增的。（自己寫了一個小工具，后面會有共享）
2、 問題要學會分類看，可以按照當前責任領域看，可以按照問題模塊看（雖然測試和研發的分類不太一樣，當前填寫的也不準）。
3、 對問題狀態有變化的需要關注，特別是狀態往回退的。（當然都可以借助于工具）
但是最最最重要的，是將產品的問題單跟蹤和統計規則歸一，過多的方式，只能夠產生混亂，大量的時間浪費在澄清和扯皮中，對我們已經被壓縮的不能再壓縮的進度是一種極度浪費。
?
我們在Ascend P1上都做了什么？
?
A、問題單作為數據源的運用：
1、 問題單統計工具歸一：
軟件有軟件的統計方式，測試有測試的統計方式，產品有產品的統計方式，OK，我們首先做到的就是工具表歸一化，做了一個工具表，這個世界平靜了。其次，統計規則統一，P1、D1軟件類問題合并在一起統計（優先將試制提的問題直接剔除，其他的評估時候再判斷），評估為不修改、非問題的直接不統計，問題單繼續走。
?
2、 問題單排名方式歸一：
以前做QCC的時候，有一位同事說過，如果要讓這個活動搞起來，就要讓馬賽起來，要形成競爭。OK，規則和統計方式已經統一了，按照資源組的方式（軟件細分到各小組），進行當前問題單狀態排序，每天通報。工具相對比較傻瓜化，自己先發幾期，后面找一個慧通的兄弟，教會他使用方法，都是他來發，軟件問題就這樣活性競爭起來，大家也知道如何做了。
?
3、 問題單評估記錄歸一：
智能機問題實在是多，P1、D1新平臺旗艦機，問題尤其多14K啊，排序找重點問題，通過會議紀要的方式記錄，后面跟蹤有困難。OK，沒問題，會議紀要照發，但是每個問題單的結論統一記錄到工具表單中，評估結論直接放在里面，便于查詢、篩選，狀態也一目了然，簡單&直接，大家都喜歡。
上面說的天花亂墜，其實就是一個Excel表+Vlookup函數，所有需求都搞定，而且盡可能采用自動化處理，每天0.5-1小時工作量，大家方向很一致。
原來還想再優化優化，現在看來要留給后面的有志之士了。 ^_^
?
B、DTS 問題單數據如何展示：
數據源既然已經有了，如何用呢? 做一個有心人，看看我共享的“咨詢工具”系列吧，里面會給你靈感的。
1、 展示問題發展趨勢：
最常見的展示方式，大家大家最愛用，大家也都能看得懂。
到底哪種趨勢比較適合P1，我下了不少功夫，北研M860、C8860、U8860、S8600、U8600的數據圖形我都做過，大家不妨也看看，其實用用R版本度量工具，一切其實很簡單。
2、 展示研發和測試的PK：
折線圖也可以這樣用哦，研發解決問題和測試發現問題可以這樣對比，是推研發解決問題還是測試發現問題，很清晰。
3、 展示研發解決問題的速度：
地層圖的使用，這個是和總體組一個GG學的，研發能力基線也可以得到驗證哦。
?
C、關于DTS問題單，不得不說的痛：
1、 步驟之長世所罕見：
我經歷的那么多家公司，我們終端用的流程真可謂歷史之最，大量的問題單采用的是13步，基本上是業界的2倍。增加了那么多審核&確認的步驟，是為了啥？問題單我的理解，就是驅動研發工作的一種工具，研發人員日常的工作就是解單，慎重合入，其實控制一個合入入口就可以了，將問題修改方案的評估做在平時，為啥還要體現流程，結果現在問題單反而流不起來了，過TR點還要催單，純粹的人力浪費。走一個問題單，需要多少人力成本，不知道有沒有人算過。
?
2、 必填項填不準，如何利用數據：
和軟件開發的兄弟交流過，問題模塊分析，居然軟件和測試的不太相同，那應該如何去正確理解呢？是不是需要培訓？ 同時也折射出一個問題，測試能力問題，如何判斷這個是一個問題，是測試的必備能力，但是現在似乎差好幾口氣。
DTS原始數據上那么多的問題點，數據分析如何進行？ R版本度量工具基本上是有力使不上。當前的DTS數據我對它是又愛又恨，真的像是一盤沒有絞肉的麻婆豆腐，真希望有哪位大俠可以像《中華小當家》中演的那樣，創新改良后作出一盤沒有絞肉的夢幻麻婆豆腐（大豆做絞肉）。
從DTS問題中折射出的測試問題：
?
1、 測試只管發現問題，不管判定是不是問題：
海思的測試同事曾經很好奇地問過我，終端的測試很奇怪，判斷是否是問題居然說是研發來做，研發的時間最寶貝，這個不是應該測試來完成么? 因此在海思能夠看到測試的兄弟，整出來各種腳本，測試工具，羨慕啊，啥時候我們也可以才這樣？
過年前，P1的問題發現比較少，因此嚴重反饋過幾次，導致結構問題大量上升，結果后來一打聽，原來測試開展了外包和華為測試的大比武，大搞自由測試求單，是我們的用例發現不了問題，還是我們的測試用例不完整，那為什么不在10幾K的用例開開刀，改良改良呢？ 3-4重交互后發現的問題，是否可以將解決的程度降低？
以前李小龍曾經說過，做小靈通的時候總共的用例才1K，但是已經比CDMA FP的幾千條用例發現的問題多了。其實，測試用例是貴精不貴多，如果是界面全覆蓋，那想辦法自動化即可，對于交互類的問題，可以人工測試，哪些是常用的交互，哪些問題是用戶最關心的，800熱線、FFR退機，都可以找到線索。
?
2、 只關注了數量，忘記了質量：
如何去評判測試的質量，其實很簡單，看看對于測試提交的問題，多少個問題研發是需要修改代碼的就行了。那么我們P1 一共有14K多的問題，我簡單的統計過，對于已經關閉或者撤銷的問題，已經表示是問題解決的應該不超過60%。HAP平臺也的進行總結的時候統計過，一共處理過8K的問題單，但是需要改動代碼的不超過40%。 那么剩下的那些問題都是咋整的？ 這些問題是不是浪費了呢？ 我沒有仔細去分析過，建議測試總結的時候可以看看。
4）試制現場質量控制：
?
幾個現象：
1、 大家都很忙，各忙各的，一旦是重大項目，各部門都出差，出差日報就滿天飛，后端的兄弟很郁悶，到底應該看那份信息，哪份信息最準確？
?
2、 DFx或者試制代表統籌組織，但是“布朗運動”比較明顯，問題攻關全面開花，對于本次試制而言到底哪個問題需要重點解決，優先解決？兄弟們很困惑。
?
3、 我們在現場改善了很多東西，需要落實的要求很多，EMS的技術員一個人接口我們很多人，我聽誰的？EMS的技術員很郁悶。
?
4、 我們落實了不少方案，效果咋樣，有沒有新增問題，產線報表、數據咋沒有人看呢？
在Ascend P1上的實踐：
產線跑不順，出現的各類問題無非是物料、制程、設計三類。物料問題直接進行篩選，和供應商明確后續的交貨和驗貨要求，基本可以告一段落。制程問題關鍵是看提升員工的熟練度和核心工位操作的正確性，這個是需要一點點看，一點點糾的，只看報表而不在現場是解決不了問題的。設計問題一旦出現，必然是高比例的不良，那攻關一定避免不了。針對上述的認知，進行了如下人員布局：
? 跟線人員分為兩個職能組：巡線組和攻關組，各設立組長一名。
? 巡線組：量產爬坡EMS配得都是新手，因此要加強巡線動作，重點關注關鍵工位的操作正確性和可能由于操作、夾具不良導致的潛在問題。巡線組比較辛苦，跟著實際生產班次走。
? 攻關組：負責關鍵遺留問題的攻關。
? 信息交互方式：每日9:00早站會，小組長將兩組信息總結并交流互通，制定新一天的工作計劃。
? 改進效果確認：每日產線問題的梳理，各種問題的趨勢判斷，識別需要重點關注的問題（之前是我主導，后續教會DFx或者試制代表）
? 成果及時落地，關鍵工位識別，相關注意事項增加到偉創力IPQC的巡檢要求和操作指導中。
待改進點：
當前試制開工會關注度不足，每次試制需要關注啥，上次遺留的哪些問題已經解決，具體落實了哪些措施和活動，哪些問題不解決，一定要試制前達成一致。
試制的資源是有限的，試制的次數應該是需要受限的，版本經理需要珍惜每次一試制機會，QA能夠制止試制，當然是最好的。^_^
?
5）EWP分析
EWP分析的目的應該有兩個，1）早期發現問題，將后續會影響故障率的問題扼殺在搖籃中（判斷準確需要經驗）；2）解決的問題作為經驗優化到設計規則或者經驗案例中去，未解決的遺留問題合并到FFR改進中跟蹤。 當前我們更多關心的是第一個目的，這個無可厚非，也是正確的，但是我們手頭的資源是有限的，問題一定要排序解決，不能全線作戰，否則一旦產品過多，紊亂場面無可避免。（北京楊海波EWP分析經驗不少，可以咨詢。 上海沒有專職團隊對EWP負責，對資源的利用和配置要求更高。）
文章來自網絡，版權歸作者所有，如有侵權請聯系刪除
精益六西格瑪讓我們的質量、效率、成本、管理上了一個臺階，并得到了美國質量協會、中國質量協會等單位的獎勵和認可。”
———上海貝爾某某公司
?