[[154621]]

近日，一名有超過 15 年軟件開發經驗的軟件開發人員在 Hacker News 上提出了一個問題：如何才能成為一個好的技術***?該問題一經提出，在不到一天的時間內就獲得了 160 多條回復。關于技術***應該具備的品質和管理技巧，網友們提出了各自的看法和建議，本文擇要歸納如下。

如果不能從幫助團隊獲得滿足感，那么就不要成為一名***

技術***要忙于會議、計劃、打斷、團隊溝通、文檔等工作，永遠無法達到一個人單獨工作時所能達到的那種個體生產力。

技術***的工作不再是讓自己成為***的編碼人員，而是要盡可能地讓其他人成為***的編碼人員。工作分配也要以一種有利于團隊和個人成長的方式進行。要負責為團隊成員清楚障礙，讓他們的工作進入正軌。

技術***的滿足感來自新人的培養和成長。

將自己視為其他開發人員的導師

即使已經知道了答案，有時候也需要讓團隊自行決策。許多時候，正確的答案并不唯一。技術***的工作不是選擇正確的答案，而是確保團隊不選擇錯誤的答案。允許團隊作為一個整體自行決策有利于保持高漲的士氣，讓每名成員都更有自豪感和主人翁精神。

在有關技術問題上，團隊信任并依賴你的建議/觀點。作為技術***要了解團隊所開發的應用，了解該應用所涉及的領域，了解功能背后的技術，并編寫詳細的技術文檔。

有時候，技術***同時也是***工程師。這時，他所能為團隊做的最有價值的事情是在開始和結束時為團隊成員提供幫助。

有時候，技術***還是架構師。當解釋系統或代碼的行為時，他需要能夠快速改變高度。當同開發人員調試問題時，他要能夠深入技術細節;而當向 CEO 解釋計劃或成本估算時，他要能夠在一個更高的層次上談論系統。

隨時準備好回答團隊成員的問題

但當你有問題要問他們時要首先詢問他們是否方便。這很難做到，因為作為一名技術***，你有許多工作要做。但是，為了可以有更多的時間回答他人的問題及為其他人提供支持，可以將復雜的任務委派給團隊中更有經驗的成員。

很多時候，團隊成員的問題本可以在空閑或閑聊的時候提出。為此，引入可異步使用的生產力工具是一種更好的方式，比如，對于一些不太緊急的問題，可以借助 Trello 卡片或 GitHub 問題跟蹤器提出。不過，不管采用什么樣的溝通機制，關鍵是要獲得其他團隊成員的支持，讓他們在工作無法進行或完成的時候，可以很舒服地打斷你。

為了了解團隊成員，技術***要定期主動同團隊成員進行一對一的溝通。每名開發人員都是不同的，通過溝通可以了解到這種不同。

減少具體的編碼工作，但仍然要編碼

即使不做很多具體的編碼工作，也仍然需要監控和接受所有的 pull request，并利用這個過程，幫助初級開發者修改代碼。這是必須的，如果不編碼，那么開發人員會質疑你的判斷，不容易接受你的建議。

但是，作為技術***，你的首要任務是確保團隊成員的生產力，而不是自己的生產力。你要為整個團隊的輸出負責，如果那意味著零編碼，那么就不要編碼了。同時，這也意味著，即使代價是停下自己的工作，也要幫助處于困境中的團隊成員。

要謙遜

要相信，你的團隊所具備的能力和理解力都要超過你。

要承認，關于某個主題或組件，有人懂得比你多。成為一名優秀的***，并不需要事事都懂得比別人多。

如果團隊成員都將你視為權威，那么他們會害怕自己做決策。在這種情況下，你就成了障礙。

要誠實

當你知道答案的時候，就說出來，即使那意味著某些人要重做大量的工作。如果你不知道答案，也要說出來，不能不懂裝懂。你獲得了當前的職位，就說明你有資格，你永遠不需要向其他人證明你的能力。

除了上述這些討論比較多的觀點外，還有一些其它的觀點，比如，把令人愉快的任務分給別人，把令人討厭的任務留給自己;公開表揚，私底下批評;讓每個團隊成員都清楚地知道你對他們的期望;及時反饋和表揚;與非技術管理人員建立穩固的關系等等。還有一些行為是技術***應該避免的，比如，不要抱怨代碼庫有多糟糕;不要說“我們要重寫 XYZ”，技術債務要逐步解決;不要輕易提議使用可選的平臺和框架。不過，需要注意的是，不同的組織有不同的企業文化，對技術和技術***有不同的看法和預期，技術***要以此為出發點考慮問題。