亂發脾氣會擴大問題，抓戰犯無濟於事；了解如何安穩地解決問題、避免問題再次發生，並讓出包的人意識到自己的錯誤才是最重要的。

只要專案出包，首當其衝的通常是團隊主管；他不僅要面對上層的壓力，還要思考下一步如何組織團隊解決問題。

如果處理過程情緒管理不當，或是方法錯誤，就可能衍生出更多問題，甚至讓類似的問題一再發生。

▋恢復理智，整理思緒

專案出包後，有些高層會先把主管找過去痛罵一頓。

只要是人都會有情緒，沒人在被罵完後還能保持好心情；但如果把情緒帶到接下來的緊急會議上，就可能把問題擴散的更廣。

試想，如果會議開場你直接把脾氣發洩到成員身上，他們會是怎樣的心情？搞不好罵完後，有些人直接辭職不幹了（這個狀況如今並不罕見）。

因此筆者建議：「無論多想罵人，先讓自己恢復理智，確保自己能心平氣和的處理問題後，再召開緊急會議。」

▋召集相關人員開緊急會議

主管，尤其是技術部門主管，他們在收到回報後，往往能很快判斷出問題是誰造成的；但很多時候：「出包的人，未必有解決問題的能力，抓戰犯，對解決問題也沒有幫助。」

筆者不建議在會議中把矛頭指向特定人士，比較好的做法應該是先讓與會人了解以下幾點：

1. 問題的嚴重性、影響範圍。
2. 問題有多緊急，需要在 XXX 時間內解決。
3. 我判斷問題可能源自於 XXX...
4. 我會跟你們一起面對問題！

待大家了解問題後，詢問是否有人熟悉這塊功能，並儘可能安排兩個人一起解決問題（Pair programming）。

在高壓的狀態下，一個人獨自面對問題容易鑽牛角尖，甚至情緒不穩崩潰；但多一個人在身邊，除了能給予不同的想法外，還能起到彼此鼓勵的效果（當然這也是看人）。

▋問題解決後

向高層回報問題已經解決後，如果還在上班時間，建議趁大家記憶猶新的時候，立刻開會討論：

1. 問題發生的原因？
2. 現有工作流程是否需要調整？
3. 這類問題是否有可能避免，如果有，我們該如何制訂標準？
4. 如果再次發生類似的問題，是否有更好的處理方式？

於會議結尾，記得再次感謝大家的辛勞；就算是出包的人解決問題，也不要吝嗇對他的感謝。

如果是加班解決問題，建議隔天再開會討論；要是硬在大家都很疲憊的狀態下開會，得出的結論通常沒有什麼參考價值。

▋等出包的人冷靜後

除非出包的人不想幹了，不然在出包當下，最緊張的應該是導致問題發生的人。

但如果第一時間找他問罪，他有很大的機率會把精力放在推諉卸責，而不是解決問題身上；所以建議等問題解決且出包的人冷靜後，再單獨找他約談。

談話過程中，除了讓對方認知到自己的錯誤，還要使他明白再犯可能要面臨的懲處。

有些主管在問題解決後就想說算了，但如果沒有適當的警告，可能讓出包的人認為犯錯也沒什麼大不了的。

▋想跟讀者聊聊

每個主管都有自己的領導風格，因此想詢問讀者，當專案出包的時候，你們的主管都是如何處理的呢？你認同主管的處理方式嗎？

又或者你本身就是主管，面對這種突發狀況，你是如何應對進退的呢？有沒有可以分享的小撇步？

歡迎大家分享自身經驗，或許你的留言可以幫助到有需要的人。

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 專案出包後是先抓戰犯還是抓問題？身為主管碰到問題，下一步建議可以這樣做｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

有時我們把時間拉長會發現，該做的事還是得做，如果當下不做只會讓未來問題引爆後更難收拾...

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

在前兩篇文章中（連結 1、連結 2），我們討論了團隊的聲音為何越來越少，以及主管權衡事情的角度。

而在這篇文章想跟大家分享，這些累積的問題是如何爆發的。

▋不患寡，而患不均

在一個團隊中，如果主管對每個人的標準都差不多，那至少可以維持基礎的平衡。

但如果出現了嚴重的偏差，比如：

1. 同樣是犯錯，有些人輕描淡寫帶過，而某些人則是被嚴懲。
2. 同樣是功勞，有些人藉此升官發財，而某些人卻被賦予更重的任務。

只要有人的地方，就一定會有「親疏遠近」，主管跟其中幾個人特別要好也是人之常情；但如果差別待遇的太明顯，那團隊內部肯定會出現問題。

就像這名工程師在爆炸前有提出最後一個問題：「如果有做不好的地方，我會持續改進。就算在會議上被點名檢討，只要是自己的問題，我就會虛心接受，並在下次做得更好；但為什麼我提出的問題，專案經理都沒有改進？」

結果沒想到主管回他：「不要總是在檢討別人，你要加強溝通技巧啊！」

在聽完主管的話後，工程師理智斷線，怒吼道：「好！我閉嘴！反正我說的話都沒人在聽！」並且在當天遞出辭呈。

如果主管對下屬過度雙重標準，那團隊的流動率會相當高。

▋專案經理的後續發展

也許讀者覺得專案經理這麼混，一但離開公司肯定四處碰壁，但實際上在不久後他也遞出了辭呈，並成功跳槽到另一間薪水更高的公司。

其實這位專案經理並不是沒有專業能力，而是因為受到主管的庇護而不需要認真發揮實力；如果一個人發現自己就算很混也能立足，那大多數的人就是能混就混。

▋主管最後怎麼樣了？

因為專案經理離職，所以他需要暫時代理這個職位；為了避免更多的工程師離職，他重新規範需求規格該有的元素；並且開始面試新的專案經理、工程師。

有沒有覺得這些事情很熟悉？

對！其實就是上一篇提到，主管想解決問題時所需要做的事。有時我們把時間拉長會發現，該做的事還是得做，如果當下不做，只會讓問題在引爆後更難收拾。

▋筆者的想法

發現問題 ➝ 承認問題 ➝ 解決問題

團隊中不乏能發現問題的成員，而解決問題的方法也很多，比如：「將大問題切割成小問題、定期回顧問題處理狀況、獎懲機制明確……」隨便 Google 都有一堆解答。

既然能發現問題，解答又不難找，為什麼團隊還是有這麼多問題？

從筆者的角度來看，應該是卡在「承認問題」的環節；換而言之，「人」才是造成問題無法解決的根本原因。就像在這個案例中，如果主管能適時地做出決策，也許故事的發展就不同了……

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 工程師：「好！我閉嘴！反正我說的話都沒人在聽！」(3)｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

站在主管的角度，他要做的是權衡出一個對部門(自己)最有利的方案，而不僅僅只是從事情的對錯來決策...

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

在上篇文章中，我們提到團隊改善的聲音越來越少，最後淪為一個形式的問題。

今天讓我們來了解，為何有些主管在收集到成員對團隊的建議後，選擇忽視成員心聲，甚至把問題放著不管。

▋對錯重要，還是穩定重要？

假使今天有工程師提出問題：「專案經理寫的需求規格太過模糊，裡面沒有交代前因後果，甚至連一些判斷的邏輯都沒有寫，這樣每次在實作前都要先跟他討論一次，我覺得非常浪費時間。」

上面問題的責任歸屬很清楚，根本的原因就是「專案經理缺乏撰寫需求規格的專業能力」，理論上我們只要請專案經理跟工程師溝通，協調出怎麼樣的需求規格是可以接受的，那問題就解決了。

但如果我們把上述的情境加上如下前提：

1. 專案經理已經在公司做了 5 年，過去的專案也都順利結案。
2. 工程師才進來 6 個月，有些東西還在摸索。

我想整個問題就會變複雜了，以這個案例來說，主管也在會議上要求專案經理寫出更詳細的規格；但一個月後，規格依舊模糊，完全沒有改善的徵兆。

這類問題常發生在老鳥身上，他們認為：「自己過去這樣做都很順利，今天來了一個小毛頭就要我配合他進行調整，憑什麼？」

▋不是沒有解決方案，只是很難推動，以及想不想推動

主管不傻，他當然也知道解決方案；但就像是上面的例子，如果你硬是要專案經理改，如果他不爽不幹了，許多他手上正在進行的專案都會受到影響。

離職預告期是給善良的人來遵守的，筆者曾遇過提離職後，直接請連續假到離職日的人。

很多人會想如果再找一個專案經理，慢慢取代他手上的工作不就好了；但實際上部門編列的預算，未必能夠再多聘請一個人。

上面講了這麼多，只是想透過實際案例讓讀者們了解；站在主管的角度，他要做的是權衡出一個對部門(自己)最有利的方案，而不僅僅只是從事情的對錯來決策。

如果主管只是想悠閒混日子，那他可以繼續放任專案經理；但假使想徹底把問題解決，他就需要做多手準備，比如：

1. 深入了解每個專案，萬一專案經理離職，他可以暫時代理這個位置。
2. 律定需求規格該有的元素，讓工程師可以順利作業。
3. 開始面試新的專案經理，確認專業能力符合需求。

▋假使你是主管，面對這個問題你會選擇哪一條路？

就像上篇文章提到的，很多問題都是綜合因素所造成；今天所舉出的這個例子，應該也在很多公司不斷上演。

站在旁觀者的角度，我們知道怎麼做才是「正確」的；但站在當事人的角度，因為問題還沒有大到讓團隊無法運作，在動力不足的狀態下很多人會放棄決策（因為做出決策後，自己接下來幾個月都會很累）。

人，容易因為需要太多努力，而拒絕改變。

在下一篇文章中，筆者會跟大家分析工程師真正的引爆點，以及主管後續的故事。

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 工程師：「好！我閉嘴！反正我說的話都沒人在聽！」(2)｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

當主管詢問大家：「團隊還有哪些地方可以改善？」時，你會主動提出自己觀察到的問題嗎...

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

這個情緒話的標題，真的是筆者在現實職場中聽到的。

我打算以這個標題做一個系列文（目前預計有 3 篇），讓你了解是什麼樣的問題，才導致工程師情緒失控用這種方式表達自己的不滿。

▋主管在徵詢團隊成員意見時，是真的想改善？還是做個形式而已？

在部門會議時（ex：週會、月會），有些主管會詢問大家：「團隊還有哪些地方可以改善？」

相信大部分主管是想透過這個問題與成員討論，進而讓團隊的運作更加順暢；但通常只有一開始的 3~5 次會有人提出哪些地方需要改善，隨著時間推進，會越來越沒有人提出問題。

一但發生上述情境，這個問題就會淪為一個形式，象徵會議的結束。

▋沒有人提出要改善的地方，是真的沒有地方可以改善了嗎？

我相信一定有團隊在經過多次磨合後，已經摸索出最適合當下的運作模式，即使遇到新問題也可以快速應對。

但這種團隊真的是「極少數」，實際上大部分團隊的狀況是：「過去的問題尚未解決，新的問題不斷誕生。」

明明問題一直存在，甚至越來越多，為什麼反而沒有人提出來呢？

▋是什麼原因，導致後來沒有人提出問題？

以筆者過去的經驗來說，在發生以下的狀況後，即使對工作再有熱情，也會逐漸被澆熄：

1. 問題在被提出來後，並沒有明確地商討出彼此能接受的解決方案。
2. 往往只有階級高、資歷深的人提出的建議才會受到重視；而基層、資歷淺的人所提出的建議容易被當耳邊風。
3. 技術人員所提出的建議，有時會被以「你不懂專案管理、這不是你應該插手的事」為由否決。
4. 即使討論出解決方案，也不是每位團隊成員都會遵守執行。

冰凍三尺，非一日之寒。很多問題都是綜合因素所造成的。

▋大家可以想一想

我相信這個問題不只筆者碰到過，應該絕大多數的團隊都曾遇到，或正在面臨類似的狀況。

說一句實在話，團隊問題並不是光靠基層努力就能解決的，畢竟現實生活不是連續劇；如果管理層不覺醒，問題會一直存在，甚至變得更糟糕。

下一篇文章中，筆者會分析為什麼有些主管選擇忽視成員心聲，甚至把問題放著不管。

這些明眼人都知道會對團隊帶來負面影響的問題，為什麼他們還是做了？真的是因為昏庸無能嗎？

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 工程師：「好！我閉嘴！反正我說的話都沒人在聽！」(1)｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。