"我足够幸运到和一个充满激情工程师的小团队一起工作，他们真的在意他们的客户。如果你不那么幸运，你可以把这封信分享给你的工程师团队。"
亲爱的工程师们：
你的工作不是写代码。
我明白。你认为你被雇来写代码的。实际上，你的整个面试过程是围绕着你写的代码怎么样。我确信你做的非常好了。
不过，这不是你的工作。
你的工作是为我们的用户改善产品。如果你想为产品获取技术，那么你的工作就是以提高公司的主要绩效指标的方式来为用户改善产品。老实讲，你对第二点不会一直有太多的控制权。然而，你应当对***点有大量的控制权！
当然，如果你想做好工作，就意味着你或许不得不改变你当前的一些行为。
首先，你需要确保你写的代码（顺便提一句，写代码仍然是在你工作时要做到的主要部分之一）是按照期望在运行，甚至在用户的机器上。
你知道吗？我们的用户很可能没有、为高分辨率配置的巨大 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/
