作者 | Podge O’Brien 編譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

基於我多年來所經歷的離職面談，下面我將總結出幾點最可能會“逼”走優秀工程師的原因及解決辦法。雖然表面上來看，這都是些不太嚴重的問題，但隨著時間的推移，它們會逐漸將人們壓得喘不過氣，直至絕望離開。

不會構建軟體的領導

要問什麼最讓工程師感到悲傷？那必然是高高在上的領導（工程經理、主管、副總裁）不瞭解他們每天在面臨什麼問題，也不瞭解從頭構建一些功能和軟體的難點。

解決方法：讓公司的工程經理、主管或副總裁起碼每個季度用大概一週的時間，學會構建和交付功能。他們要學的不能是像更改一行文字這樣簡單的功能，而要是積壓中的客戶功能，整個流程應控制在三天左右，並且這些領導應該以團隊合作的方式工作。

招聘太多且不同層級的領導

一旦你的管理層人太多，勢必將決策推向更高層，也就必須開會決定，可討論越多，團隊層面的對接指導就會越少。舉個例子，當一個上級經理想要完成某件事時，他可能會跟下一個經理溝通不暢，而低效的溝通將導致團隊不知道他們應該做什麼。

解決方法：扁平化你的組織，儘可能減少管理層人數。

無窮無盡地“開會”

一旦有人不知道需要做什麼，不確定軟體是如何製作的，並且團隊之間存在許多支援關係，就召開會議，製作甘特圖讓員工遵守時間表。隨後，就要召開更多的會來審查是否根據甘特圖推進。期間如果又有什麼懸而未決的問題，就又要開會“碰一碰”解決。

解決方法：在設計你的組織時，儘量減少團隊之間的協作，同時確保團隊內部要有高度協作。

讓定義軟體的過程變得痛苦

如果工程師必須承擔起找出需要構建的工作，並獨自構建功能以完成工作，這必將導致逆反心理。軟體開發應該是一個團隊共同努力的工作，如果團隊中沒有產品人員和其他重要職能來幫助協調工作，團隊內部成員就會產生不滿情緒。

解決方法：找到一種分擔工程師負擔的方法，例如在建立工單時，至少需要 3 個人花 10 分鐘討論工單，確保所有相關細節都囊括其中，包括描述變化是什麼、將如何測試等。在我看來，這 3 個人最好是工程師、測試人員和產品人員，即產品人員應該領導並提供需要構建的環境，開發人員詢問其中的具體功能，而測試人員則提問該如何測試。如果對需要做什麼沒有達成共識，工程師就不會開始構建軟體，但查詢資訊不應僅由工程師負責。

讓交付軟體變得痛苦

寫完工單並不代表就萬事大吉，現實中仍有許多“意外”。如果開發環境不相容，工程師就不能在本地開發，或者很難在開發環境中測試更改。如果測試不穩定，或者軟體經常無緣無故停止工作，這對工程師來說無疑是一種挑戰。

解決方法：根據你的製作之路有多艱難，有以下幾種方法可以解決。

1、啥也不做，放任擺爛。不過我不建議這個方法，因為這可能會對你的工作構成生存威脅。

2、開始花時間解決這些問題，大概從 20% 的時候開始，分析問題所在並制定計劃解決問題。

3、對工單進行最佳化，尤其是在維護現有程式碼的情況下。

讓工程師計劃他們的工作

讓他們提前一個月完成工作計劃，一個月後如果他們沒有按時完成，就責怪他們不善於預測未來的事情。

解決方法：別讓他們計劃了。我分析了我參與過的每一個使用這個方法的團隊，其中 99% 都是沒用的。所以從我的經驗來看，這行不通。如果你需要日期，我會推薦一種更現代的方法，例如預測。

過於小的團隊

有些公司中，存在一些僅由三名應用工程師組成的團隊，採用專門負責製作功能的模式，其他運營和 QA 工作都是在團隊之外完成的，平時來看似乎沒什麼問題。可直到有一天其中有人請假了，另一個也請病假了，僅剩的那個工程師就要獨自揹負高效的重擔和巨大的壓力。長此以往，這個人就會崩潰離開。

解決方法：確保團隊至少要有六個人。

向其他團隊借人

如果你是一名工程師，當公司需要完成一些工作時，你被調到其他團隊，這可能會令人感到低落和沮喪，因為這說明你沒有多少時間來發展成為一名專業工程師。

解決方法：要讓團隊長久存在，有一個使命，那就是不要到處調動人員。

結語

以上就是一些在我看來很常見的工程團隊存在的弊病，同時我也給出了相應的解決方法。雖然有一些方法看起來很簡單，但真正實施起來很難——因為你生活在一個系統中，而改變系統，特別是基於人類的系統，是非常複雜的。

所以最後，有句話我想送給你：如果你不能“改變”你的公司，那就“改變”你的公司。

原文地址：https：//blog。hulacorn。com/2021/09/08/how-to-drive-away-your-best-engineers/