做一个“卓有成效”的工程师_最新动态_新闻资讯_程序员俱乐部

　　英文原文： We are All Product Owners! An Impact Guide for Engineers

　　是做一个按部就班交付任务的工程师，还是做一个知道怎么完成具有真正影响力的事情而获得优秀考评的工程师？一个以交付为导向的公司和一个以影响力为导向的公司，哪个更长命？Facebook 前员工、Lyft 增长工程主管 Eran Davidov 通过举例和分析对比表达了他的观点。

　　我曾经在一家以交付为导向的公司工作，以交付为导向的意思是说，我的工作是通过一个清单来定义的。我的待遇既不是由产品在市场中的反响效果来决定的，也不是我在公司里的影响力来决定。只要我能够及时交付，就算是很好地完成了我的工作。

　　后来，我到了一家以影响力为导向的公司。他们并不在意我交付了什么或什么时候交付，只要我所做的事情对业务产生了影响力就可以了。我每六个月接受一次考评，要想获得好的考评结果，在这六个月内我必须要产生可衡量的影响力。

　　我们先来比较一下这两种公司之间的不同。

　　在以交付为导向的公司（姑且称其为S公司），一个项目可能会持续三年，在这期间我需要持续跟进项目。

　　在以影响力为导向的公司（姑且称其为I公司），如果我在一整年内没有产生有意义的影响力，那么就算是毫无进展。

　　在S公司，QA 的作用是防止工程师交付有问题的东西。

　　在I公司，QA 的作用是与工程师一起工作，确保功能特性能够正常运行。

　　在S公司，发布日期是非常严格的。

　　在I公司，只有当我们认为产品好到可以给用户带来正面影响力的情况下才会发布产品。

　　S 公司曾经是一家 500 强公司，但现在已经从地球上消失了。

　　I 公司仍然健在，而且还活得有声有色。

　　什么是影响力？

　　简单地说，影响力就是指业务影响力、为公司赚更多的钱、为公司省钱、发展公司的客户、提高公司业务量、降低客户支持成本，等等。这些都是公司的首要目标。

　　当然，为公司带来影响力的方式有许多，只要它们是基于以下这些目标。

• 减少意外事件
• 修复产品的漏洞，给用户带来更好的产品
• 在用户看得到的地方提升表现力
• 降低基础设施的成本，让它运行得更快、更稳定
• 构建系统和框架，用于帮助他人更快地完成他们的工作
• 减少开发人员花在诊断、构建和交付上的时间
• 招聘更多更好的人
• 成为导师
• 其他

　　并非所有的事情都是可量化的

　　通过修复 UI 问题给某个功能特性带来的影响是难以简单地进行量化的，不过这的确提升了品牌的情感体验和用户的舒适度。从长远来看，它会影响到净推荐值（net promoter score）。

　　偿还技术债务或者让系统变得更加可靠所带来的影响力也是难以简单地进行量化的。不过它们确实非常重要，因为如果你的系统缺乏可扩展性，就会拖慢开发速度。问题的核心在于，要做有用的事情，而不是盲目地采用新技术进行重构。

　　代码审查可以让你的团队变得更好，在提升质量的同时，也让其他人学会了如何编写更高质量的代码。

　　如果你认为一些东西很重要，但不知道如何对它们进行量化，那么可以与你的上司或同事讨论这些事情，看看他们是否能够了解其中暗藏的价值，或许他们能给出一些建议。

　　正因为不是所有的事情都是可量化的，所以我们要有所偏重。

　　为什么要这样？

　　下面是人们在进行自我评估时会提到的一些东西。

• “我及时地交付了功能。”
• “我参与了公司前端项目的架构评审。”
• “我帮忙协调移动和前端的开发、分析和质量保证。”
• “我参与了文化布局会议。”

　　以上这些只是可以产生影响力的方式，而并非你所产生的影响力。

　　现在再来看看其他的一些例子。

• “直接从产品页面开启结算流程，增加了 10% 的购买率。”
• “原先同步每个产品线需要 20 分钟，而其中的 20% 会处理失败，需要重新处理。经过我的修改后，现在可以在 10 秒钟内完成产品线同步，不需要再进行返工处理了。”
• “我参与了 20 场面试，招到了 2 个新员工。”
• “我给所有的客户端工程师安排了一个交流会，找到了三个需要进行重构的地方，其中的两个已经完成重构，出现崩溃的几率被降低到 20%。”

　　以上几项之所以对公司来说是有影响力的，是因为它们要么增长了业务指标、节省了时间、节省了人力资源，要么让公司得到了全面的提升。

　　但我不是产品经理！

　　工程和产品管理都应该明白，他们要用最少的成本开发出正确的产品。工程师阅读代码，部署代码，修改代码，修复缺陷。对于他们来说，有影响力的事情未必就是要开发出新产品。它们可以是指对 UI 的改进或者构建更稳定的系统，总之就是让产品更加易用。比如，识别出用户在移动设备上做出的不太明显的操作，或者改进登录过程，直接把用户定向到结算流程，这些对于公司的关键性指标都有重大影响。这些事情都是工程师能够去做的。

　　如何理解影响力

• 你“编写规范”，还是“为某个变更服务编写规范”？
• 你“审查很多代码变更”，还是“审查敏感代码变更，并被其他人找去审查其他的东西”？
• 你“做问卷调查”，还是“做问卷调查，找出关键问题所在，并说服基础设施团队把它加入到他们的路线图中”？
• 你“构建了一个系统”，还是“构建了一个系统，解决了X问题，并被其他团队采用”？
• 你“运行了一个测试”，还是“运行了一个测试，然后得出用户不希望在午餐时间接收消息的结论”？

　　如果你做了事情，却不提及它们所产生的影响力，你可能只是在浪费自己和他人的时间。

　　在产品的不同阶段，影响力有不同的表现方式。

　　在构想阶段

• 这个想法很重要吗？为什么？
• 你如何衡量成功？
• 产品的成功是否与公司的首要目标一致？
• 如果你得到结果X，你知道该如何继续吗？如果你不知道该如何应付这样的结果，那么就想想你还需要得到哪些信息才能够了解究竟发生了什么，而不只是盲目得认为自己已经成功了。

　　在计划阶段

• 这就是 MVP（最小可行产品）吗？有没有过度设计了？
• 在花六个月构建完整的系统之前，能不能先在两周内做出一份科技财务报表，验证一下这个概念是否足够好？
• 你还需要哪些信息来帮助你判断产品成功或失败的可能性？
• 需要多少时间才能知道产品是否有利可图？

　　在执行阶段

• 在构建功能特性时，要对它们进行测试。它们是否能够按照预期的方式工作？需要作出哪些修改？从用户的角度来看，有哪些不对的地方？
• 你能不能提一些建议，把原型做得更好？或者更快地验证概念性想法？

　　在启动、测试和监控阶段

• 最早在什么时候你可以知道系统已经被建好了？
• 你检查结果的频率是怎样的？如果要等四周才能发现一个实验性错误，无异于浪费了很多时间。
• 你从中得到什么结果了吗？它们告诉你应该做什么吗？
• 实验失败了吗？如果失败了，你从产品和客户那里学到了哪些东西可以帮助公司做出更好的决策？哪些人需要知道这些信息？

　　一切都是运气？

　　想想你们公司的考评更注重什么，是行动（交付）还是进展（影响力）？

　　考评的目的是为了奖励做出正确决定的人。我们所做的每一件事情里都有运气的成分，不过先让我们来看看下面两个人连续三期的绩效考评。

　　一般工程师：

　　第一期：做了很好的计划，但是项目没有出成果。
　　第二期：优秀的编码能力，但项目只有很小的影响力。
　　第三期：从系统架构层面出发，让四个团队重写了他们的接口。要让当前的系统变得更好，最好的办法是重头开始，因为它确实不够酷。

　　“运气”工程师：

　　第一期：进行很多短期的实验，提高了 10% 的产量。
　　第二期：对网站进行重新设计，降低了5% 的遗弃率。
　　第三期：重构后端的技术栈，降低了 20% 的页面加载时间，增加了5% 的跳出率（bounce rate）。

　　其实没有人会那么幸运的，只是“运气”工程师做出了更聪明的选择。她选择了正确的项目，并验证某些事情是不是值得去做。在评估工作时，她总是能把最终结果考虑在内。

　　而一般的工程师在错误的事情上浪费了很多高大上的技术。

　　短期还是长期？

　　我比较注重短期目标。如果你关注长期目标，或许要到下一年才能看到成果，而你的公司有可能都撑不到下一年。而如果你关注的是短期目标，你会想办法让项目有所进展，不断改进最小可用产品，识别出错误的行动方向并立即终止它。一个公司应该要同时制定多种目标，包括长期的、中期的和短期的。比如 70% 的六个月目标、20% 的一年目标和 10% 更长期的目标。这个取决于你的实际情况和业界的发展状况，并且要根据产品和公司的生命周期进行评估。

　　要把长期项目做好！有时候，你需要去创建一个新数据库，因为你预见到基础设施将会在一年内崩溃。有时候，你需要研究新的技术，以便解锁新的产品机遇和业务线。想想以下这些问题。

1. 这对于业务来说是不是非常关键？它属于长期、中期还是短期的？你能否说服其他人跟你一起工作，让他们相信这件事比其他的更重要？
2. 有没有更简单、更短期的方式可以达成你的目标？
3. 能否在构建整个系统之前先验证你的构想？你可能花了一年时间搭建机器学习平台，用于训练人们的购买意愿数据，结果却发现这样做并不能给销售带来任何提升。
4. 会不会存在这样的情况，其他人使用“老旧”的技术，并不断做出改进，而你使用了新技术，结果同时存在两个相互竞争的系统？或许循序渐进式的改进要比采用新技术更好，具有更小的破坏力。
5. 大型项目的影响力和它所耗费的时间是否成正比？如果不是，那么还值得去做这个项目吗？

　　如果你决定要推进一个项目，那么就设定清晰的目标，并确保真的能够达成每个目标，而不只是说“还在努力”。与此同时，不断问自己，这样做还有意义吗？

　　惩罚失败？

　　我们对于失败的定义或许不太一样。

• 如果一个系统变更未能给业务带来提升，只要你能够从中更好地了解你的客户和产品，那么它就不算是个失败。
• 一个运行了四周的实验，最后你发现是因为没有正确地进行设置，需要重新运行，那么这就是一个执行层面的失败。
• 长期项目的失败会有很多原因。思考一下为什么它会失败？你是否原本可以做一些事情让它更成功一些，或者更早地发现它会失败？这其实也是一个失败管理问题——为什么会启动这个项目，又为什么没有反复对它进行评估并适时停止它？

　　我不惩罚失败，我只奖励成功和承担风险的行为。正确的决策和良好的执行力会让你更有机会获得成功。

　　我在说的是哪一类型的公司？

　　大部分公司的失败不会只是因为一两个原因，以交付为导向的公司之所以失败，是因为它还存在其他的问题。我这里所说的以影响力为导向的公司是指 Faceb，而我目前的公司 Lyft 也是以影响力为导向的。