“高級工程師承擔的工作”是一個很大的話題，我無法通過一篇小文章做到面面俱到。請您在閱讀本文時，記得以下幾點：

本文討論的“高級工程師”承擔的工作內容只是一種可能性。工作的方式很多，我們并沒有標準答案。

我基本上只在一家公司工作過，而這篇文章描述的也只是我的經驗，所以我的觀點可能有些狹隘。

“高級工程師”都各有千秋。本文討論的是Mozilla ladder中描述的P3/P4水平，也就是高級工程師和主管工程師，可能更傾向于主管工程師。

屬于高級工程師的工作內容

下列工作在我看來主要是高級工程師的工作，而不像是經理的工作。雖然管理人員肯定會承擔其中一些，尤其是創建新項目和將項目與業務優先級相關聯等。

所有項目的工作歸根結底還是要靠技術：幫助別人解決棘手的項目顯然是人為的互動，但通常，我們共同努力的問題還是有關計算機的問題！（“如果我們簡化設計的話，也許可以早點做完工作！”）

寫代碼。

代碼審查。

編寫和審查設計文檔。我認為“審查設計文檔”與其他審查任務一樣，就是“讓別人看看設計，幫忙改進設計”。

當團隊成員遇到困難時給予幫助。有時人們會被一個項目難倒，給予他們支持很重要！我認為這不是“神兵天降，將你的法術傳授給他人”，更像是“共同努力去理解他們試圖解決的問題，看看三個臭皮匠能不能賽過一個諸葛亮”。這也意味著你要與他們一起解決問題，而不是替他們解決問題。

保證項目的高質量標準。對于不同的人來說，“質量”意味著不同的事情（對我的團隊來說，這意味著可靠性/安全性/可用性）。通常我不贊同某人做出的決定時，我就知道要么是因為我知道他們不知道的事情，要么是有什么事是他們知道而我不知道的！所以，不應該對人家說：“你錯了，應該這么這么做”，我會試著提供一些他們不知道卻很重要的額外信息。而且我發現常常是我忽略了一些東西，實際上他們的決定是完全合理的！過去我偶爾會看到有些高級工程師為了強制執行質量標準，大吼大叫并不斷重復他們的意見，因為他們認為他們的意見是正確的，而我個人覺得這些方法并沒有用。

創建新項目。軟件工程團隊不是零和博弈！我認識的優秀的工程師都不會將最有意思的工作留給自己，他們會創造新的有趣且重要的工作，并給他人機會讓他們承擔這些工作。例如，我們團隊中有人帶頭重寫了我們的部署系統，結果非常成功，如今我們整個團隊都在研究新功能，在重寫部署系統后做新功能就更加容易了！

計劃項目的工作。即整理與傳達正在進行的項目的藍圖，并確保團隊成員可以理解你的計劃。

主動溝通項目的風險。這項工作的要點在于：及時發現項目進行中的問題，與其他工程師或經理進行溝通，并找出解決方案。

溝通是成功的必經之路！

做有利于團隊或公司的副項目。我看到許多高級工程師偶爾會做一些小型影響力很高的項目（比如構建開發工具/幫助設置策略等），最終可以幫助很多人更好地完成他們的工作。

了解項目與業務優先級的關系。

決定何時停止做項目。弄清楚什么時候停止某項工作是非常困難的。

我把“寫代碼”放在第一位，是因為我覺得大家很容易在不經意間就忽略寫代碼：）

有一件事我沒有提到，那就是“做估算”。我還不太擅長做估算，所以我對此了解的不太多，但我認為將來一定要在這方面多花點時間。

如果你想一下子做好上面所有的事情，那么會覺得好多，而且會讓你倍感疲憊。我認為一般來說，找出其中一部分工作，然后告訴自己“現在我要專注地做好X Y Z，如果我同事嘗試做A B C的話，我的腦袋會爆炸。”

不屬于高級工程師的工作內容

這部分有點棘手。

我不是說這些不是高級工程師的工作，我也不是說“我才不會幫助我的團隊創造一個良好的工作環境，這跟我有一毛錢關系嗎？”。我認識的大多數高級工程師都花了很多時間思考這些問題，并且還做了很多研究。

我之所以認為有必要在此畫條界限，是因為我的同事都對團隊和公司有很強的歸屬感與責任感（他們通常都會說：“這是我們要做的工作是吧？那好，我來做吧！ “）而且我認為讓大家主動承擔需要完成的工作往往會導致他們不堪重負、過度勞累、無法在他們的核心工作中做出真正的技術貢獻。因此，如果針對我們的職位創建一些界限，那么在大家忙成一團的時候，更容易決定應該尋求怎樣的幫助。實際上你畫的這個界限取決于你和你的團隊：）

這些工作中的大多數都是經理的工作。注意：管理人員的工作遠不止這里列出的事項（例如“創建新項目”），而在有些公司里，有些事情實際上可能是高級工程師的工作（例如sprint管理）。

確保每個團隊成員的工作得到認可；

確保以公平的方式分配工作；

確保團隊成員相處融洽；

建立團隊凝聚力；

與團隊中的每個人進行一對一的談話；

培訓新的管理人員，幫助他們了解他們的職責（盡管我認為實際上往往高級IC最終會承擔部分工作？）

承擔你沒有參與的項目的管理工作（在我們公司，這是領導項目的工程師的工作）

做產品經理；

Sprint管理，將每個人的工作融入項目程碑，組織每周一次的團隊會議。

明確的責任邊界很重要

我曾遇到過一個有趣的狀況。我跟一名經理談起我作為工程師，哪些任務不是我的工作，然后發現我們對這個問題的期待完全不同！我們談了很久，現在這個問題應該解決了，但它讓我認識到，一致的期待非常重要。

我開始做工程師時，我的工作很直接——寫代碼，完成項目，就足夠了。我的經理很清楚我的工作內容，并且會保證我的工作不會太復雜。但現在情況不一樣了！所以我認為，現在定義工作內容的責任更多在我自己：

我能做什么——即適合我的工作；

我想做什么——即我喜歡的，并且與我個人目標一致的工作；

什么對團隊或組織有價值。

至于工作的具體情況，每個人各不相同（并非每個人都有同樣的能力和興趣，例如我實際上不太擅長代碼審查！），所以我覺得溝通期望就更重要了。

不要承諾你無法完成或不想做的工作

我認為，從長期來看，拒絕我不能勝任的工作或者會讓我不愉快的工作是非常重要的！我發現，我似乎很容易同意或接受一堆我知道我不喜歡的工作（“哦，這對團隊有好處呀！”，或者“嗯……反正總得有人做！”）。雖然我有時會被迫接受一些不得不做的工作，但我覺得，讓團隊成員做合適的、喜歡的工作對于團隊的健康很有好處。

所以，我會接受不得不做的小任務，但我覺得敢于說出自己的心聲很重要的。 ：） 比如說：“可以，我會花許多時間做這件我不擅長或不喜歡的工作，但沒問題。” 而且，如果必須“有人”做，那么可能意味著我們需要雇傭或者培訓新人來填補這個空白 ：）

我還有許多要學習的東西！

雖然我覺得我對“高級工程師”有自己的見解（我已經有7年經驗了），但我仍然覺得我還有許多要學習，我也愿意聽聽別人如何定義工作的界限！