銘文：
從前，刺蝟和小熊在森林裡相遇。
- 你好，刺蝟！
- 你好，小熊！
於是，一字一句，一笑一笑，刺蝟被小熊打到了臉上…
以下是我們的團隊負責人以及 RAS 產品開發總監 Igor Marnat 的討論，內容涉及工作衝突的具體情況以及管理衝突的可能方法。
我們在工作中遇到的大多數衝突都是按照與上面銘文中描述的類似的場景發展的。 有幾個參與者，一開始對彼此都抱有很好的態度，他們試圖解決一些問題，但最終問題卻沒有得到解決，而且由於某種原因，討論參與者之間的關係被破壞了。
生活是多種多樣的，上述情況也會改變。 有時參與者之間的關係最初不是很好，有時甚至沒有一個需要直接解決的問題（例如，在銘文中），有時在討論之後關係仍然與開始之前相同，但是問題最終沒有得到解決。
在所有可定義為工作衝突的情況下，有什麼共通點？
首先，有兩個或多個側面。 這些各方可以在組織中佔據不同的位置，處於平等關係（團隊中的同事），或者處於不同的層級結構（老闆- 下屬），可以是個人（員工）或團體（在團隊之間發生衝突的情況下）。員工和一個或兩個團隊），等等。 衝突的可能性及其解決的難易度很大程度上受到參與者之間信任程度的影響。 雙方越了解，信任程度越高，達成協議的機會就越大。 例如，與至少有過幾次面對面互動的人相比，從未面對面互動過的分散式團隊的成員更有可能在簡單的工作問題上遇到衝突。 因此，在分散式團隊中工作時，確保所有團隊成員定期面對面見面非常重要。
其次，在工作衝突的情況下，各方需要解決對一方、雙方或整個組織都很重要的某個問題。 同時，由於情況的具體情況，各方通常有足夠的時間和多種方式來解決（正式、非正式、會議、信件、管理決策、團隊目標和計劃的存在、層次結構的事實等）。 這與解決組織中的工作（或非工作）問題的情況不同，例如解決一個重要問題：“呃，孩子，你來自哪個地區？！” 在街上，或來自銘文的衝突。 在解決工作問題時，工作流程的品質和團隊中解決問題的文化很重要。
第三，衝突的決定性因素（從我們討論的角度來看）是進程各方無法獨立找到適合各方的問題解決方案。 這種情況需要第三方（外部仲裁者）的介入。 這一點看似有爭議，但本質上，如果衝突局勢在沒有外部仲裁者介入的情況下得到了成功解決，問題得到了成功解決，雙方關係也沒有惡化，這才是我們應該努力的情況。 我們很可能根本不知道這樣的衝突，或者在衝突解決後我們會偶然發現。 團隊能夠獨立解決的問題越多，效率就越高。
衝突的另一個值得一提的特徵是決策過程中的情緒強度。 衝突不一定與高情緒層次有關。 參與者不必大喊大叫、揮舞手臂，局勢本質上就會變成衝突。 問題沒有解決，存在著一定的情緒緊張（也許沒有明確地向外表達），這意味著我們面臨衝突的情況。
是否有必要介入衝突局勢，還是讓衝突順其自然，等待問題自行解決比較好？ 需要。 你並不總是有能力或能力完全解決衝突，但在任何情況下，在任何規模的衝突中，你都可以採取成年人的立場，從而讓你周圍的更多人也參與進來，減輕衝突的負面後果。衝突並為其解決做出貢獻。
在看一些衝突情況的例子之前，讓我們先來看看所有衝突共有的幾個要點。
在解決衝突時，重要的是要站在爭鬥之上，而不是置身其中（這也稱為「採取元立場」），也就是說，不要成為解決過程中的一方的一部分。 否則，聘請外部仲裁員協助裁決只會強化一方的地位，而損害另一方的利益。 在做出決定時，重要的是它在道德上得到各方的接受，正如他們所說的「購買」。 所以，即使當事人對這個決定不滿意，至少也真誠地同意執行。 正如他們所說，能夠提出不同意見並做出承諾。 否則，衝突只會改變其面貌，陰燃之火將留在泥炭沼澤下，並在某個時候不可避免地再次爆發。
第二點與第一點部分相關，即如果您已經決定參與解決衝突，請從溝通和研究背景的角度盡可能認真地對待它。 與各方單獨交談。 對於初學者來說，分別進行。 不要滿足於郵件。 對於分散式團隊，至少透過視訊連結進行交談。 不要滿足於道聽途說和目擊者的報告。 了解這個故事，各方想要什麼，為什麼想要它，他們期望什麼，他們以前是否嘗試過解決這個問題，如果不解決會發生什麼，他們看到什麼解決方案，他們如何想像雙方的立場另一方，他們的想法是什麼，對或錯，等等。 以開放的心態，將所有可能的背景加載到你的腦海中，假設每個人都是對的。 你不在衝突之中，你在衝突之外，處於一種變換之中。 如果上下文僅在貼文主題中可用，請至少閱讀其全文以及與其相關的主題和文件。 讀完後，仍然用你的聲音說話。 您幾乎肯定會聽到郵件中沒有的重要訊息。
第三個要點是溝通的一般方法。 這些都是很平常的事情，不是宇宙性的事情，但它們卻非常重要。 我們不會試圖節省時間，我們會與所有參與者交談，我們不會批評這個人，但我們會考慮他行為的後果（不是“你很粗魯”，而是“也許這些人可能會被冒犯”） 。這件事」），我們提供保全面子的機會，我們親自進行討論，而不是在隊伍前面。
衝突通常是由以下兩個原因之一引起的。 第一個與衝突時一個人處於成年人的地位還是兒童的地位有關（更多內容見下文）。 這是由於他的情緒成熟，管理情緒的能力（順便說一句，這並不總是與他的年齡有關）。 第二個常見原因是工作流程的不完全，造成了參與者責任分散、各方期望不透明、流程角色模糊等灰色地帶的情況。
因此，在解決衝突（以及任何其他問題）時，管理者必須牢記三個角度：短期 - 立即解決問題/衝突，中期 - 最大限度地減少發生另一次衝突的可能性出於同樣的原因，而且是長期的－在團隊中培養成人文化。
我們每個人都有一個內在的孩子，大約三、四歲。 他工作時大部分時間都在睡覺，但有時會醒來並控制自己。 孩子有他自己的優先事項。 對他來說重要的是堅持這是他的沙箱，他的母親更愛他，他的機器是最好的（設計是最好的，他編程是最好的，...） 。 在衝突的情況下，孩子可以按玩具、跺腳、敲碎鍋鏟，但他無法解決成人的問題（解決方案架構、自動化測試方法、發布日期等），他不會考慮好處為了隊伍。 可以透過讓陷入衝突的孩子打電話給大人來鼓勵、安慰他並讓他上床睡覺。 在衝突情況下開始討論之前，請確保您正在與成年人而不是兒童交談，並且您自己處於成年人的位置。 如果你目前的誠實目標是解決一個嚴重的問題，那麼你就處於成年人的位置。 如果你的目標是跺腳並折斷肩胛骨，那麼這是一個幼稚的姿勢。 讓你內在的孩子上床睡覺並打電話給成年人，或重新安排討論時間。 一個人做出情感決定，然後尋找理性的理由。 孩子根據孩子的優先事項所做的決定不會是最佳的。
除了衝突時的行為之外，兒童或成人的立場也取決於一個人準備承擔的責任程度。 我不止一次遇到過的程式設計師的幼稚立場的極端表現是這樣的：我編寫了程式碼，將其發送以供審查 - 我的工作完成了。 審查者應該審查並批准它，QA應該檢查它，如果有問題，他們會讓我知道。 奇怪的是，即使是相當成熟和有經驗的人有時也會這樣做。 天平的另一端是，一個人認為自己有責任確保他的代碼可以工作，經過測試，經過他親自檢查，已經成功通過審查（如果有必要，與審查者聯繫，討論問題是沒有問題的）通過語音等）並且已被抑制，QA將在必要時提供幫助，將描述測試場景等。 在正常情況下，程式設計師要么從接近成年的階段開始，要么隨著經驗的累積而移動到那裡（前提是在團隊內培養了正確的文化）。 在極端情況下，他繼續工作，通常採取幼稚的立場，然後他和團隊週期性地出現問題和衝突。
對任何管理者來說，在團隊中培養正確、成熟的文化都是一項重要任務。 這需要很長時間和每天的努力，但結果是值得的。 有兩種方法可以影響團隊文化：以身作則（肯定會被遵循；團隊總是仰望領導者）以及討論和獎勵正確的行為。 這裡也沒有什麼深奧或非常正式的東西，只是在討論問題時，注意這裡可以做一些事情，強調你注意到它是正確決定的，表揚，在發布審查期間注意等等。
讓我們考慮幾種典型的衝突情況，從簡單到複雜：
與工作問題無關的衝突
工作中常會出現與工作問題無關的衝突。 它們的發生和解決的難易度通常與參與者的情緒智商水準、成熟程度直接相關，而與工作過程的完善或不完美無關。
典型例子：有人不常使用洗衣機或淋浴，有人不喜歡，有人悶熱，有人開窗有風，有人太吵，有人需要安靜工作，以及很快。 這類衝突最好不要拖延解決，不要讓其順其自然。 它們不會自己解決，而且會分散你每天工作的注意力，並破壞團隊的氣氛。 幸運的是，解決這些問題通常不是什麼大問題——只需與忽視衛生的同事平靜地交談（當然是一對一），為喜歡安靜/涼爽的人提供舒適的座位，購買吸音耳機或安裝隔間即可， ETC。
我在工作中多次遇到的另一個例子是團隊成員心理不相容。 由於某種原因，人們根本無法一起工作；每次互動都會以醜聞告終。 有時這是因為人們對一些緊迫問題（通常是政治問題）持有極端觀點，並且不知道如何讓他們脫離工作。 說服他們互相容忍或改變他們的行為是一項相當徒勞的任務。 我遇到的唯一例外是思想開放的年輕同事，他們的行為仍然可以透過定期對話逐漸改變。 通常，透過將他們分成不同的團隊，或至少提供很少的工作重疊的機會，可以成功解決問題。
在所有上述情況下，值得與所有參與者親自交談，討論情況，詢問他們是否認為此案例中存在問題，詢問他們認為解決方案是什麼，並確保他們參與製定此方案決定。
從優化工作流程的角度（我提到的中期角度）來看，這裡能做的不多；唯一優化的一點是在組建團隊時考慮相容性因素，而不是把人提前在一起誰會發生衝突。
從團隊文化的角度來看，這種情況在文化成熟的團隊中很少出現，因為人們尊重團隊和同事，並且知道如何獨立解決問題。 此外，在高度信任、人們一起工作很長時間和/或在工作之外頻繁溝通的團隊中，此類衝突更容易解決（通常是自動解決）。
與工作問題相關的衝突：
這種衝突通常是由兩種原因同時引起的：情緒因素（其中一名參與者沒有處於成年人的位置）和工作過程本身的不完美。 也許我遇到的最常見的衝突類型是開發人員之間的程式碼審查或架構討論期間的衝突。
我在這裡重點介紹兩個典型案例：
1）在第一種情況下，開發人員無法從同事那裡獲得程式碼審查。 該補丁已發送以供審核，但沒有任何反應。 乍一看，雙方並沒有什麼明顯的衝突，但仔細想想，這卻是頗有衝突。 工作問題未解決，其中一方（等待審核）感到明顯不適。 這種情況的一個極端子類型是在社區或不同團隊中開發，而審閱者可能對這段特定代碼不感興趣，由於加載或其他情況，可能根本不關注審閱請求，而外部仲裁者（雙方共同的經理））可能根本不存在。
在這種情況下有幫助的解決方法恰恰與長期觀點、成年人的文化有關。 首先，智能活動有效。 你不應該指望掛在審閱上的程式碼會引起審閱者本身的注意。 我們需要幫助審稿者註意到他。 Pingani 幾個人，問一個關於syncape 的問題，參與討論。 顯然，強求弊大於利，你需要運用常識。 二是前期準備工作做好。 如果團隊了解發生了什麼以及為什麼，為什麼需要這段程式碼，設計已經與每個人提前討論並達成一致，人們更有可能關注這樣的程式碼並接受它用於工作。 第三，權威發揮作用。 如果您想接受審查，請自行進行大量審查。 透過真實的檢查、真實的測試和有用的評論進行高品質的評論。 如果你的暱稱在團隊中廣為人知，那麼你的程式碼就有更大的機會被注意到。
從工作流程的角度來看，這裡可能的改進是正確的優先排序，旨在幫助開發人員實現他和團隊的目標（審查其他人、寫信給社群、為程式碼附上架構描述、文件、測試、參與與其他人的討論）社群等），防止補丁在隊列中掛起太長時間，等等。
2) 代碼或設計審查期間發生衝突的第二種常見情況是對技術問題、編碼風格和工具選擇的不同看法。 在這種情況下，非常重要的是屬於同一團隊的參與者之間的信任程度以及一起工作的經驗。 當其中一位參與者採取幼稚的立場並且沒有嘗試傾聽對話者想要向他傳達的訊息時，就會出現死胡同。 通常，另一方提出的方法和最初提出的方法都可能成功，原則上選擇哪一種並不重要。
有一天，我團隊的一位程式設計師（我們稱他為 Pasha）準備了一個補丁，其中包含對套件部署系統的更改，該補丁是由鄰近部門的同事開發和支援的。 其中一位 (Igor) 對於部署軟體包時應如何配置 Linux 服務有自己的強烈意見。 這個意見與補丁中提出的方法不同，他們無法達成一致。 像往常一樣，最後期限已經過去了，必須做出某種決定；他們中的一個人必須採取成人立場。 帕夏承認這兩種方法都享有生命權，但他希望他的選擇能夠通過，因為無論是第一種還是第二種選擇都沒有任何明顯的技術優勢。
我們的討論是這樣的（當然，談話持續了半個小時，非常概括）：
- Pasha，我們的功能將在幾天內凍結。 重要的是我們要把所有事情整合在一起並儘快開始測試。 我們怎樣才能通過伊戈爾呢？
— 他想要以不同的方式設定服務，他為我留下了評論...
- 有什麼，大的改變，大驚小怪？
- 不，工作了幾個小時，但最終沒有區別，無論哪種方式都會工作，為什麼這是必要的？ 我做了一些有用的東西，讓我們接受它。
- 聽著，你們討論這一切多久了？
- 是的，我們已經原地踏步一個半星期了。
- 嗯...我們可以在幾個小時內解決一個已經花了一周半時間的問題而不這樣做嗎？
- 嗯，是的，但我不想讓伊戈爾認為我屈服了...
- 聽著，對你來說哪個更重要，是發布一份聲明以及你的內部決定，還是殺死伊戈爾？ 我們可以阻止它，但是，有一個很好的機會透過釋放來飛過。
- 嗯…當然，擦伊戈爾的鼻子會很酷，但好吧，釋放更重要，我同意。
- 伊戈爾的想法對你來說真的那麼重要嗎？ 說實話，他根本不在乎，他只是想在他負責的事情的不同地方有一個統一的方法。
- 好吧，讓我按照他在評論中的要求去做，然後我們開始測試。
- 謝謝你，帕夏！ 我確信你們兩個中你會更成熟，儘管伊戈雷克比你年長:)
問題解決了，版本也按時發布了，Pasha並沒有感到太大的不滿，因為他自己提出了一個解決方案並實施了。 伊戈爾總體上很高興，因為… 他的意見被考慮了，他們按照他的建議做了。
另一種本質上相同的衝突是專案中技術解決方案/函式庫/方法之間的選擇，尤其是在分散式團隊中。 在其中一個定位為使用C/C++的專案中，事實證明該專案的技術管理人員堅決反對使用STL（標準範本庫）。 這是一個簡化開發的標準語言庫，我們的團隊非常習慣它。 事實證明，該專案更接近 C，而不是 C++，這並沒有給團隊帶來太多啟發，因為管理階層盡了最大努力，招募了非常酷的球員。 同時，團隊中的美國部分，無論是工程師還是經理，都在公司工作了很長時間，已經習慣了現有的狀況，對一切都很滿意。 團隊中的俄羅斯部分最近在幾週內聚集在一起（包括我）。 團隊中的俄羅斯部分絕對不想放棄通常的開發方法。
兩大洲之間開始了無休無止的書面討論，三四個螢幕上的信件來來往往，有集體郵件和個人郵件，從程式設計師到程式設計師和經理。 正如通常的情況一樣，除了作者及其熱心支持者之外，沒有人讀過這麼長的信件。 聊天氣氛緊張，跨屏交流著不同方向的想法，包括STL 的技術優勢、它的測試結果如何、它的安全性如何，以及總的來說，有它的生活是多麼美好，沒有它的生活是多麼可怕。
這一切持續了相當長的時間，直到我終於意識到我們正在討論問題的技術方面，但問題實際上不是技術問題。 問題不在於 STL 的優點或缺點，也不在於沒有它運作的困難。 問題是組織性的。 我們只需要了解我們工作的公司是如何運作的。 我們之前都沒有在這樣的公司工作過的經驗。 問題是，在程式碼開發並發佈到生產環境後，支援是由來自其他國家的其他團隊的完全不同的人處理的。 這個由數萬名工程師（總共）組成的龐大工程團隊只能提供完全基本的最低限度的技術手段，可以說是最低限度的。 任何超出公司實際制定的工程標準的東西將來都無法得到支持。 一個團隊的水平是由其最弱成員的水平決定的。 當我們了解之後 真正的動機 在美國團隊的行動下，這個問題被從議程中刪除，我們一起成功地開發並發布了使用該公司採用的標準的產品。 在這種情況下，信件和聊天的效果並不理想；需要多次旅行和大量的個人溝通才能達成共識。
從工作流程的角度來看，在這種特殊情況下，描述所使用的工具、對它們的要求、添加新工具的限制以及此類限制的理由將會有所幫助。 這些文件大致對應於《軟體開發經理手冊》的重用策略和開發環境段落中描述的內容，該手冊於 。 儘管年代久遠，但它完美地描述了此類軟體開發的所有主要活動和規劃階段。 有了這樣的文檔，就可以輕鬆討論產品中可以使用哪些組件和方法以及原因。
從文化的角度來看，顯然，具有更成熟的立場，各方嘗試傾聽和理解同事行為的真正動機，並根據專案和團隊的優先順序而不是個人自我採取行動，衝突就會更容易、更快地得到解決。
在另一場關於技術解決方案選擇的衝突中，我也花了相當多的時間來理解其中一方的動機（這是一個非常不尋常的案例），但當動機明確後，解決方案就顯而易見了。
情況是這樣的：在一個20人左右的團隊中出現了一位新的開發人員，我們暫且稱他為Stas。 當時，我們團隊溝通的標準工具是 Skype。 後來證明，Stas 是開放標準和開源軟體的忠實粉絲，並且只使用來源公開且使用公開描述的協定的工具和作業系統。 Skype 不是這些工具之一。 我們花了很多時間討論這種方法的優點和缺點，嘗試在不同的作業系統上推出 Skype 的類似產品，Stas 試圖說服團隊切換到其他標準，親自透過郵件給他寫信，親自給他打電話、買第二台專門用於Skype 的電腦等。 最後，我意識到這個問題本質上不是技術或組織問題，而是意識形態問題，甚至有人可能會說是宗教問題（對斯塔斯來說）。 即使我們最終連接了 Stas 和 Skype（花了幾個月的時間），該問題仍會在任何後續儀器上再次出現。 我沒有真正的手段來改變斯塔斯的世界觀，也沒有理由試圖改變一個在這種環境下完美運作的團隊的世界觀。 這個人和公司的世界觀完全是正交的。 在這種情況下，一個好的解決方案是組織起來。 我們把斯塔斯調到了另一個團隊，在那裡他更加有機。
在我看來，這種衝突的原因是某個人的個人文化（他有強烈的觀點不允許他妥協）與公司文化之間的差異。 在這種情況下，這當然是經理的錯。 最初讓他參與此類專案是錯誤的。 Stas 最終轉向一個開源軟體開發項目，並在那裡表現出色。
由開發人員的幼稚態度和工作流程的缺點引起的衝突的一個很好的例子是，在沒有完成定義的情況下，開發人員和 QA 團隊對工作的準備情況有不同的期望。該功能已轉移至QA。 開發人員認為編寫程式碼並將功能扔給 QA 就足夠了 - 他們會在那裡解決它。 順便說一句，他是一個相當成熟且經驗豐富的程式設計師，但那是他對品質的內部門門檻。 QA 不同意這一點，並要求向他們展示和描述他自己檢查過的內容，並要求他們提供測試腳本。 他們過去曾遇到過該開發人員的功能問題，並且不想再浪費時間。 順便說一句，他們是對的——這個功能確實不起作用，他在發送給 QA 之前沒有檢查代碼。
為了解決這個問題，我請他向我展示一切確實有效（它不起作用，他必須修復它），我們與團隊進行了交談，並討論了完成的 QA 定義（他們沒有做到這一點）寫作，因為我們不想讓這個過程過於官僚化），好吧，我們很快就與這位專家分道揚鑣了（讓大家鬆了一口氣）。
從工作流程的角度來看，這種情況下可能的改進是存在完成的定義、支援每個單元功能和整合測試的要求以及開發人員執行的測試的描述。 在其中一個專案中，我們透過 CI 期間的測試來測量程式碼覆蓋率水平，如果添加補丁後覆蓋率水平下降，則測試將被標記為失敗，即只有當有新的測試時才能新增任何新程式碼。
另一個典型的衝突例子與工作流程的組織密切相關。 我們有產品、產品開發團隊、支援團隊和客戶。 客戶對產品有疑問並聯絡支援人員。 支援人員分析問題並了解問題出在產品中並將問題轉移給產品團隊。 產品團隊正處於繁忙時期，發布即將到來，因此客戶提出的問題票證與分配到的開發人員的其他票證中丟失了，掛起數周而不引起注意。 支援人員認為開發人員正在解決客戶的問題。 客戶等待並希望他們的問題得到解決。 事實上，還沒有發生任何事情。 幾週後，客戶最終決定對進展感興趣，並向支援人員詢問事情進展如何。 支持需要發展。 開發人員渾身一顫，查看了票單列表，發現了一張來自客戶的票。 閱讀客戶的票證後，他了解到沒有足夠的資訊來解決問題，他需要更多的日誌和轉儲。 支援人員要求客戶提供更多資訊。 然後客戶意識到一直以來沒有人在解決他的問題。 雷聲也將襲來…
在這種情況下，衝突的解決方案本身是非常明顯且線性的（修復產品、更新文件和測試、安撫客戶、發布修補程式等）。 重要的是要分析工作流程並了解誰負責組織兩個團隊之間的互動，以及為什麼這種情況首先成為可能。 在這個過程中需要解決的問題是顯而易見的 - 必須有人在沒有客戶提醒的情況下主動監控整體情況。 來自客戶的門票應該會在來自開發商的其他門票中脫穎而出。 支援人員應該了解開發團隊目前是否正在處理其票證，如果沒有，何時可以開始工作，以及何時可以預期結果。 支援和開發應定期溝通和討論票證狀態，調試所需資訊的收集應盡可能自動化等。
正如在戰爭中敵人試圖攻擊兩個單位之間的交界處一樣，在工作中最微妙和最脆弱的點通常是團隊之間的互動。 如果支援和開發經理夠老，他們將能夠自己修復流程，否則，流程將繼續產生衝突和問題，直到有經理介入才能解決問題。
我在不同公司多次看到的另一個典型例子是，產品由一個團隊編寫，自動整合測試由第二個團隊編寫，而其運行的基礎設施則由第三個團隊負責。團隊。 執行測試時總是會出現問題，問題的原因可能是產品，也可能是測試和基礎設施。 就誰應該執行問題的初步分析、文件錯誤、解析產品日誌、測試和基礎設施等達成一致通常是有問題的。 這裡的衝突非常頻繁，同時又很統一。 在情緒強度較高的情況下，參與者常常會陷入幼稚的境地，並在系列中開始討論：“我為什麼要修補這個”，“他們更容易崩潰”等等。
從工作流程的角度來看，解決問題的具體步驟取決於團隊的組成、測試和產品的類型等。 在其中一個專案中，我們引入了定期值班，團隊每週一次監控一項測試。 另一方面，最初的分析總是由測試開發人員完成，但分析非常基礎，產品也相當穩定，所以效果很好。 關鍵是要確保流程透明，各方都有明確的期望，並且情況對每個人來說都是公平的。
衝突是組織中的一個問題嗎？您的團隊中經常（或週期性地）發生衝突是一個壞兆頭嗎？ 一般來說不會，因為如果有成長、有發展，有某種動力，那麼就會出現以前從未解決過的問題，而在解決這些問題時，可能會出現衝突。 這顯示有些領域需要注意，還有需要改進的地方。 如果衝突經常發生、難以解決或需要很長時間，那就不好了。 這很可能是工作流程不夠精簡和團隊不夠成熟的跡象。
來源： www.habr.com