"我足夠幸運到和一個充滿激情工程師的小團隊一起工作，他們真的在意他們的客戶。如果你不那么幸運，你可以把這封信分享給你的工程師團隊。"

親愛的工程師們：

你的工作不是寫代碼。

我明白。你認為你被雇來寫代碼的。實際上，你的整個面試過程是圍繞著你寫的代碼怎么樣。我確信你做的非常好了。

不過，這不是你的工作。

你的工作是為我們的用戶改善產品。如果你想為產品獲取技術，那么你的工作就是以提高公司的主要績效指標的方式來為用戶改善產品。老實講，你對第二點不會一直有太多的控制權。然而，你應當對***點有大量的控制權！

當然，如果你想做好工作，就意味著你或許不得不改變你當前的一些行為。

首先，你需要確保你寫的代碼（順便提一句，寫代碼仍然是在你工作時要做到的主要部分之一）是按照期望在運行，甚至在用戶的機器上。

你知道嗎？我們的用戶很可能沒有、為高分辨率配置的巨大 Thunderbolt 顯示器的全新 MacBook Air，也沒有運行著***的 Chrome？我確認過。他們當中大部分人使用的是超過 4 年的筆記本上的 IE 瀏覽器，因此有時候你開發的東西在他們的機器上運行不正常。他們仍然是我們的用戶，為他們改善產品仍然是你的工作，因此要確保你寫的代碼在一定規模的環境下運行正常。

實際上，你通常需要確保運行在生產環境上的代碼。我真的不關心你的代碼是否運行在本地。如果你的代碼只是運行在本地，那么我唯一的選擇就是連同你的電腦一起賣掉，這樣用戶就能使用我們的軟件了，這真的行不通。

為了避免這種情況，你需要檢查生產環境上的變化。每一次都如此。記住，你的工作不只是發布，而是為我們的客戶發布一些代碼來改善我們的產品。如果你沒有檢查它是否按照期望運行，你就不知道它將來是否正常。

當然，為了檢查生產環境變化，你將需要確保代碼真正被合并以及推送到了生產環境。我的意思是，如果你只是讓修改數小時或數天處于未推送狀態，你就不能真正檢查生產環境上的變化。推送你的代碼，整合到生產環境，然后運行，確認一下。

如果你處于不能做持續部署（Continuous Deployment）的環境里，很明顯是很難做到的，不過這個理論仍然值得堅守。無論什么時候，當你的代碼整合到生產環境里了，你都要負責到底。確信它按照既定方式運行——讓我們的產品對用戶變得更好。

另一件需要記住的地方就是，有時候用戶做了讓人驚奇的事情，這意味著，你的代碼運行在***條件下的測試，是遠遠不夠的。你需要確保你的代碼甚至在錯誤情況、沒有數據，以及當用戶做了點擊回退按鈕、錯誤地使用了兩個賬號等一些你可能沒有期望到的操作時，能夠做一些合理的響應。

這不容易，這意味著你將不得不花時間考慮我們用戶可能要做的不同操作。但是，這是你工作的重要一部分，因為如果他們經常找不到 bug、或臨界情況、或死角，將為用戶極大地改善產品。

你的工作中還有一項重要的部分。你需要確保我們能夠衡量我們是否都做好了工作。這意味著添加指標和分析，便于我們測試修改帶來的效果。如果你期望你編寫的代碼能夠提高用戶參與度（在某些地方提高用戶體驗），那么你需要有一種方式來了解你是否做到了。你該怎樣知道工作完成了？正如我上面提到的，在你為用戶改善了產品之前，你的工作是沒有完成的。

我知道你在想什么。這將花很多時間！我的效率將大大降低！

不是這樣的。你將更加有效率，因為你將真正忙于你的工作。如果你拿寫的代碼少了來說事，那么這是管理上的失敗，我為此道歉。我們需要在你開發功能的需求上花更少的時間，在自己反思為用戶改善產品上多花些時間。如果我們不是這樣的，我強烈建議你要求我們這樣做。如果我們仍然拒絕，你應當辭職，找到讓你做真正工作的環境。這不是多此一舉，而是為了用戶讓產品變得更好。

請不要覺得我在找你麻煩。你不是唯一一個應該做這份工作的人，為用戶把產品做得更好，是我們所有人的工作。做為產品經理、用戶體驗設計師和經理，全面理解我們的用戶是我的工作，我能夠幫你理解如何為用戶改善產品。這也是 CEO 的工作，找到讓我們通過為用戶改善產品來賺錢的戰略。

不管我們工作上的頭銜是什么，我們的工作都是一樣的——為我們的用戶把產品做得更好。每一次。開干吧。

謝謝大家，

你們的產品經理

英文原文：Your Job Is Not to Write Code

譯文出自：http://www.labazhou.net/2014/11/your-job-is-not-to-write-code/