從整車開發項目會議中的「問答團」現象看管理效率

07-17

新朋友標題下方【飛靈汽車網】↑訂閱

來自：德拓諮詢

「忙」幾乎是所有管理者的工作常態，如果問自己每天都在忙什麼，「不是在開會，就是在開會的路上」會是一個形象的寫照。無論是企業管理，還是項目管理，會議都是不可缺少的方式之一，否則日常工作中解決不了的問題沒有上升的通道和共同決策的平台。但是如何把會議開得更有效，卻是一個值得研究的題目。本期管理案例分析將通過描述一些項目會議中的典型現象，由此對大家熟知的問題管理和會議管理展開一些討論。

不管是高層管理者，還是基層管理者，每天可能都需要參加不同層面不同類型的各種會議，臨時會議或固定會議，項目層面、業務部門層面或公司管理層面的會議等等。如果統計一下自己每天在會議中的時間，可能會嚇一跳；如果會後再跟蹤檢查這些會議的結果，可能會驚出一身汗。

在整車開發的項目管理會議中，常常會這樣的場景：

某公司級項目會議就要開始了，項目負責人A總闊步走到自己座位上，環視了一下四周，然後深深的嘆了口氣才坐下，習慣性的抱怨道：「該來的沒有來，不該來的倒是來了一大群」！助理小B抬頭一看，果然會議室里早已座無虛席，不少小夥子站在門邊/過道，煞是熱鬧！當小B拿著出席人確認表逐一確認與會領導的出席情況時，發現果然又有好幾個重要領導都沒來，得到的回復是派人代為參加了。

由於缺席的領導還不算太多，A總指示會議照常開始，可是隨著會議按照一個個議題進行，小B發現每個議題都拖延時間，會議越來越難控制：

1）雖然有明確的會議議程卻經不起領導們不停的發散，一旦跑題了很難再把話題拉回來；

2）大家習慣性的把會議當成了討論問題的場所，而一旦討論起技術問題又爭執不休，很難達成一致；

3）需要決策的問題的分析不完整不清晰，不滿足決策的條件，導致提交到會議上的問題得不到決策；

4）由於對情況不了解，有些部門領導會帶上多個「隨從」；還有些領導則選擇性不參加，由「會議專員」代為出席，大部分情況下這些專員們並沒有被授權代為決策，所以通常會把「這個問題我不能決定，我需要回去請示下我們領導」、「這個問題我要回去確認下」掛在嘴邊，只能做「二傳手」或「郵遞員」，問題因此常常被掛在「空中」很長時間，沒有人真正承接落實解決。

一個典型的現象是，不管是大管理者，還是小管理者，總是抱怨會議太多工作太忙沒有時間了解項目進展狀態和問題，項目管理決策會議中常常不能立即回答或解決會議中提出的問題，為了以防萬一，便把所有可能涉及的相關人員都帶上，組成「問答團」參加會議。常常一走進會場，會看到黑壓壓一屋子人。

一、項目中常見問題的分類

在日常的工作中，管理者們每天都要與各種問題打交道，事實上項目問題管理也符合「二八原理」的規律，80%的問題不應該靠開會解決，而應該建立工作層面的協同工作機制，通過日常溝通來解決；在需要靠開會解決20%的問題中，15%的問題可以納入項目的會議機制，通過召集項目層面相關人員開會討論解決；只有5%的問題是項目層面解決不了的問題，需要納入公司相應的決策機制，上升到高層管理會議來決策。

管理中常見的問題按照類型可分為：技術問題、管理問題、流程問題。導致問題的根本原因主要有三種：能力不足、資源配置不合理、決策不及時有效。如果我們總結一下常見問題和導致問題的根本原因及其相關性，可以用一張表來體現（如表1）。

表1 項目管理常見問題及導致問題的根本原因

如果要在整車產品開發的項目中把紛繁複雜的各類問題有序地管理起來，可藉助成熟的問題管理和會議管理方法。

二、問題管理和效率

提到產品開發的問題管理，越來越長的問題清單有木有？這些問題帶來的一堆設計變更報告以及散落在車間待報廢的零部件有木有？誠然，如果問題解決一直「不得其法」，更沒有相應的問題管理機制加以支撐，最終的後果有可能會使管理人員把大部分時間耗費在組織問題討論或跟蹤問題過程中，而問題的關閉率卻遲遲得不到提高。

作為管理者，需要對問題管理的三個層面有一個清楚的認識：

● 單個問題的管理：圖1為產品開發過程中的問題管理方法示例。

● 項目級問題總體管理：在管好單個問題的解決過程的基礎上，項目上需要應用開口問題清單對所有問題進行總體管理，通常應該指定專人負責問題解決的整體狀態跟蹤管理。

● 公司級問題管理則須聚焦在推動問題的決策上，應該建立相應的問題上升和決策機制。

在這裡我們先對產品開發過程中的問題管理方法做一個簡要的概括（如圖1所示）：

圖1 產品開發過程中的問題管理方法（示例）

1）提出問題

當問題被發現時，首先提出問題的人要對問題進行客觀、準確的描述，並提交問題整改的要求，包括對問題關閉時間的要求。

2）採取臨時措施

問題發生以後應立即採取行動，首先通過採用臨時措施，降低問題的影響或者避免問題在短時間內繼續發生。如果該問題可能會對設計產生影響，則需根據問題所產生的影響程度決定是否需要向公司提交正式的變更請求和成本影響報告。

3）確認問題並達成共識

問題責任人接收到問題以後，需要和提出人就問題的理解達成共識。對問題進行優先順序判斷並制定初步的問題關閉計劃。

4）分析問題的根本原因

要解決問題，首先要對問題進行根本原因分析，這是問題管理中最重要的一個環節。完成這一步，問題解決的進展狀態可視為50%。

問題分析樹是一個很有用的根本原因分析工具，借用最近網路上很火的霧霾分析樹（圖2）可以非常形象地說明它。

圖2 問題分析樹示例（圖片來源：網路）

5）制定永久解決方案

只有找到問題的根本原因才能真正制定長效的解決方案並明確問題關閉的時間計劃。如果解決方案會對項目的成本和時間造成影響，則需要根據流程獲得公司批准。這一步完成的標誌是方案驗證已完成並發布了技術文件。

6）驗證方案的有效性

問題能否得到徹底解決取決於方案的有效性能否保證。很多時候關閉了的問題又在另一個時間或地點換了另一種形式被打開，這實際上表明方案的有效性沒有真正被驗證。所以後續持續跟蹤和檢查也是必要的管理工作。

7）確認保持措施的有效性

在整車產品開發項目中，這一步完成的標誌是方案實施後設計功能得到了驗證，工藝過程能力也得到確認。有時解決方案在某一個狀態下的體現有效了，並不意味著所有狀態下都能保持措施的有效性，尤其是在產品批量生產前發現問題導致了設計變更的情況下。

8）總結並關閉問題

所有的問題管理都應該遵守PDCA原則，在最終關閉問題前需要做好經驗教訓總結。

做好問題管理是提升問題解決效率的關鍵。單個問題的管理並不難，難的是一個項目中各個系統在不同時間段出現的問題可能相互關聯和影響，所以問題統一歸口的總體管理和整體狀態跟蹤管理非常重要。同時，應通過定期組織Lessons Learned Workshop，把在解決問題過程中所積累的技術或管理上的經驗或教訓總結轉化成相應的知識、技術規範或流程標準。

解決問題既要治標，更要治本。從技術層面上講，治標是臨時措施，治本是永久措施；從管理層面上講，治標是解決技術問題本身，治本則需要完善流程和管理體系，在技術問題解決的基礎上完善設計規範和標準，理順流程和組織不匹配的問題，建立相應的問題管理機制，防止相同或類似的問題重複發生。

三、會議管理和效率

雖然80%的問題不應該靠開會解決，但是工作層面解決不了的問題仍然需要通過開會來協調解決。在項目管理中，會議是問題上升和決策機制的載體。

一個會議是否有效率，主線能否被hold住，取決於會議是否有個核心「中場控制」、參會的人員是否能夠不帶隨行人員也能把問題講清楚或現場解決問題。

「問答團」現象在某種程度上反映了會議組織要求不明確、會議層級不清的問題；「因為會太多忙不過來而不參加會、派代表但不授權、參會不解決問題」的現象則可能反映了資源、能力、組織、職責分工等方面的流程和管理問題。會議管理本身可以從以下幾個方面改進：

● 會議的主題要清晰，必要時阻止會議議程之外的討論，要避免討論範圍擴散變成「座談會」、「茶話會」導致會議時間難以控制，更要避免一個會議延時導致一連串會議受到影響；

● 會議的準備要充分，會議組織者尤其要對議題材料中支持決策所需要滿足的條件把好關；

● 對參會人員要有明確的要求，提前把會議內容信息推送到參會人員，明確參會人員在會議中的角色和職責，需要決策的事項必須在會議上落到實處。

決策會議上能否形成有效決策，關鍵是會場上有沒有決策的靈魂人物，其次取決於決策條件的滿足情況。在決策條件不滿足的情況下，決策者有時需要對存在未來不確定性的方案進行風險決策。科學決策並不意味著要等所有的信息放在桌面上才可以決策，「度」的把握是考驗決策者的，既要避免「完美主義」，又不能簡單地拍腦袋決策。

實踐體會

會議為什麼會這麼多呢？因為每天都會有各種層出不窮的問題，當工作層面不能有效地解決問題的時候，必然要沒完沒了地開會來討論這些問題，再通過層層會議向上提交，然後陷入反覆不下的決策等待中。尤其是當上升到公司層面的問題得不到及時有效的決策時，常常對整個項目的進程產生重大影響。

技術類問題的判定相對是清晰的，管理類和流程類的問題卻常常攪在一起，很多時候流程成了推脫問題的替罪羊。導致這些管理弊病的原因很多，需要從流程、資源、能力、組織機構、職責分工等方面系統性地診斷分析。在金字塔的管理架構中，中層人員基於流程和業務原則解決管理問題的能力則是提升管理效率的關鍵要素。

精簡會議，提高效率是管理工作的永恆主題。