點選藍色“常柱”關注，一起成長
這是公眾號2020年的第 040 篇原創內容
在技術團隊工作過程中，經常會反覆出現一些的經典的問題，這些問題會嚴重影響團隊的工作效率，同時也會給團隊的士氣帶來重大的影響。接下來，我們來討論一下這些問題發生的具體場景，造成的問題原因，以及如何預防和解決這些問題方法技巧。
今天來討論第 4 個常見問題：在軟體開發過程中，一個問題的影響範圍被過於誇大，給團隊造成不利影響，這個時候你該怎麼辦呢？
問題被過度誇大
這與其他幾點有一定的關係，“萬事都著急”和責怪某個人。當有人開始放大一個錯誤或問題造成的影響時，可能會點名羞辱到團隊中的人。當他們正試圖儘快的解決當前的問題，當被別人放大和指責時，他們一定會感覺到不安全。小題大做，可能適得其反。
我經歷過產品經理和專案經理在團隊會議上挑出某個開發人員來討論一些不太嚴重的問題，這些問題被描繪成完全阻礙進展的重大失敗。
團隊成員看到了這一切後，他們會感覺到不被尊重和不安全，因為事實不是這樣，這些純粹是誇大其詞。這樣就會造成團隊內部的對立狀態發生。
這也可能是由系統演示過程中遇到的 bug 引起的。如果演示偏離了主題而偏離了所演示的特性，這種情況尤其可能。對於不熟悉開發的人來說，常常會掛在其他小細節上，而這些細節反過來又會給負責人增加壓力引爆情緒。
背後的原因
為什麼這個過度誇大問題會是影響團隊效能和士氣的一個重要原因呢，主要是有以下幾點：首先，在演示和反饋要保持在關鍵主題上。如果演示沒有回到主題上，它將大大降低反饋會議的有效性，保持焦點是至關重要的。
不讓演示反饋集中注意力會減少對實際感興趣的領域的反饋和響應，反而會收集一些可能已經知道的不相關的反饋(比如指出當我按下按鈕時 B 部分沒有出現等)。
第二，在開發期間，在主要功能被實現之後，對瑣碎的調整的誇大會讓開發人員完全失去積極性。它忽略了成就的重要性，並把它變成了消極的。
第三，這些型別的過度反應鼓勵繞過適當的問題分類和反饋。提出這個問題的人試圖引起的反應是，這是緊急的，最重要的是，在正常的工作流之外。這就反饋到了 "一切都很緊急 "中的許多相同點，包括難以跟蹤成本和問題。
第四，在開發過程中，把細節問題過度誇大是無意義的。如果產品距離釋出還有幾個月的時間，就沒有什麼事情是這麼緊急的。例外的情況是當一個演示正在準備中，在這種情況下，應該安排一些時間來進行特別的打磨工作。
第五，這類誇大對問題的關注，會讓團隊變成 "我們與他們 "的防衛態度。他們會開始以一種減少這種情況發生的機會的方式來操作。他們可能會減少溝通，降低對提出這些問題的人的關注度，或者停止做任何高於和超出分配的工作，這樣他們就不得不減少處理這種情況。這些都不是理想的結果。
解決之法
對於問題的反饋和影響範圍的評估，我們需要有一個合理體系做管控。一邊要避免將團隊的精力浪費在非核心問題上，也同時要避免誇大的問題給團隊造成不安全感的產生，影響了團隊的效能和士氣。你可採取以下一些策略：
第一，在專案演示/反饋會議期間明確你或你的團隊中的某個人是會議的主角。這樣明確職責，快速確認要演示的的功能範圍，並圍繞確定的範圍領域進行有效的對話。
第二，在專案演示期間，要和需求方宣告當前為 demo 版本，一定會存在一些問題。用合理方式明確強調系統仍在開發中，並優雅地將會議再次引導到正確的主題上，避免被小問題誤導。當然，小問題也及時記錄在案，以便後續的跟進和解決。
第三，在正常的開發過程中，當問題被過分誇大的時候，一定要識別出來，並引起注意。從長遠來看，這是無益的，也是有害的。每個人都需要保持對專案和問題的看法。
第四，不去猜測提出這樣問題的人的動機。我們姑且認為他們是由於外界的壓力，或者是對開發流程不熟悉。
總之，不管是哪種情況，都要認識到，把瑣碎的事情當做緊急的事情提出來，尤其是用不尊重的方式提出來，是不可接受的。在團隊內要呼籲減少這種行為，或者以其他方式遏制這種行為的發生。
最後的話
無論什麼情況，在工作中提交和反饋問題一定要實事求是，不要過分的誇大問題，更不要用不尊重人的方式去反饋問題。
因為，過分的誇大問題的影響和嚴重性，只會造成團隊之間的不安全和不信任，增加團隊成員之間的對立性。
小題大做，往往適得其反，因為高效的團隊需要安全的環境和彼此的尊重與信任。