* 和其他所有人

我曾在一家重视交付的公司工作。我对交付的定义比较宽泛——它意味着完成一系列定义我工作的清单。我的薪酬和晋升与产品在市场上的表现或我对公司的影响无关。只要我按时交付，我就做得很好。

我随后在一家专注于影响力的公司工作。无论我发货的内容或时间如何，只要对业务有影响就没关系。我每 6 个月会被评估一次，这意味着我需要在这 6 个月内产生真实、可衡量的影响。

想一想这件事的含义：

在船公司，一个项目可能需要 3 年，而我不断进步。

在影响公司，如果我一年没有产生有意义的影响，我就不会晋升。

在船公司，QA 的角色是阻止工程部门发运明显损坏的东西。

在影响公司，QA 的角色是与工程团队合作，确保正确的功能正常运行。

在船公司，发布日期是神圣的。

在影响公司，我们在认为产品足够好，能够对用户产生积极影响时发货。

这家船公司曾是一家财富 500 强公司。它现在已经不存在了。

影响公司在这里，发展得很好。

什么是 Impact？

显而易见的答案是商业影响。为公司赚更多的钱，节省开支，增加客户数量，交易数量，降低支持成本等。专注于公司的主要目标。

有很多其他方式可以影响公司，只要它们与这些目标相关：

减少事件
修复产品领域的一系列重大漏洞，以提升用户体验
在用户可感知的领域提高性能
使基础设施更便宜/更快/更稳定
构建系统和框架，帮助他人更快地构建事物（并被采纳）
减少开发者诊断/构建/发布的时间
增加你雇佣的优质人才数量
指导（并让被指导者承认你帮助了他们）
等等。

并不是所有东西都可以量化。

修复一堆影响特定功能的 UI 故障可能不容易量化，但确实会提高整体品牌情感和用户对你服务的享受。从长远来看，这将影响净推荐值。

消除技术债务或使系统更可靠并不总是可衡量的。这仍然是关键且有影响力的，因为如果不让系统易于扩展，你的开发速度会减慢。关键在于选择那些真正有帮助的东西，而不是重构成“炫酷的新技术”。

进行代码审查可以帮助你的团队变得更好，通过教会其他人关于代码的新知识，同时推动高质量标准。

如果你认为这很重要但不知道如何衡量，和你的经理或同事谈谈。看看他们是否理解此时这样做的价值。他们也可能会有关于如何衡量影响的建议。

虽然并非所有事物都可以量化，但你应该培养一种倾向于测量的偏见。

为什么偏向于测量？

考虑以下通常出现在人们自我评估中的陈述：

“我按时交付了我的功能。”
“我参与公司内部前端项目的架构评审。”
“帮助协调移动和前端工程、分析和质量保证。”
“我参加文化设定会议。”

这些是清单项目。它们是你可以产生影响的方式，但不是你实际产生的影响。

现在考虑这些例子：

“从产品页面直接启用结账流程，以增加 10%的购买量”
“我们以前每条产品线需要 20 分钟，且 20%的时间这个过程会失败，这意味着我们需要重新运行它。经过我的改动，我们能够在 10 秒内同步新的产品线。我们再也不需要碰这个过程了。”
“我在这个学期参加了 20 次面试，导致了 2 名新员工的入职。”
“我为所有客户工程师安排了一个同步会议。我们确定了 3 个需要重构的领域。其中 2 个已经完成，崩溃率下降了 20%。”

很明显，这些项目对公司产生了影响的原因。它们要么提高了业务指标，要么节省了时间，让人们可以专注于其他事情，或者总体上改善了公司。

但我不是首相！

工程和产品管理应该在以最小的努力构建正确的产品上保持一致。工程师每天都在关注产品，我们阅读代码，经历部署、变更和修复的过程。具有影响力的事情不一定是新产品。它们可以是用户界面修复、更稳定的系统，或者使产品更易于使用的东西。例如，识别在移动设备上折叠以下的关键操作，或改善登录漏斗以直接将用户转入被放弃的结账流程，可能对公司的关键指标产生重大影响。这些都是工程师可以识别、沟通和推动的事情。

如何思考影响

考虑一下你们公司重视的影响：

你是“写了一个规范”，还是“为一个改变了 X 的服务写了一个规范”？
你是“审查了很多代码变更”，还是“审查了敏感代码变更并被 A、B 和 C 寻求审查事务”？
你是“发出了一份调查”，还是“发出了一份调查，识别了关键问题区域并说服工具团队将其加入他们的路线图”？
你是“建立了一个系统”还是“建立了一个促进 X 的系统，并被 A 和 B 团队采纳”？
你是“进行了测试”还是“进行了一个测试，告诉我们用户不喜欢在午餐时间收到消息”？

如果不考虑你所产生的影响，你可能只是在浪费自己和他人的时间。

在产品创建过程中考虑影响的方式各不相同。

在构思阶段

这重要吗？怎么重要？为什么？
你将如何衡量成功？
成功是否与公司的主要目标一致？
如果你这样做并得到结果 X，你知道该如何继续吗？如果你不知道如何处理结果（特别是如果结果与预期不符），想想你还想测量哪些其他信息来理解发生了什么。不要仅仅假设成功。

在规划期间

这真的是最小可行产品，还是说这设计得过于复杂了？
你能在两周内创建一个技术债务版本，以看看这个概念是否可行，然后再花六个月时间构建完整系统吗？
你需要对任何东西进行监测以理解成功/失败吗？
你多久会知道这是否是一个值得追求的方向？

执行期间

在构建功能时，尝试一下它们。你认为它们会按预期工作吗？你会改变什么？从用户的角度来看，有什么感觉不正确或不理想的地方？
你有什么建议可以让原型更好？有什么建议可以更快地测试这个概念？

在启动 / 测试 / 监控期间

你多久能知道自己是否正确设置了系统？
你打算多久检查一次结果？等了 4 周才发现实验设置不正确是浪费时间。
你有结果吗？它们告诉你应该做什么？
实验失败了吗？太好了！你从产品或客户身上学到了什么，可以帮助公司做出更好的决策？谁需要知道？

这难道不是一种有利的运气吗？

考虑一下你们公司的绩效评估强调什么。你是因为行动（发货）而获得奖励，还是因为进展（影响）而获得奖励？

目标是奖励那些做出良好决策的人。我们所做的一切都涉及一些运气，但想想以下两个人在连续三个绩效评估周期中的表现。

工程师的工程师：

术语 A：很好的计划，项目没有成功。

术语 B：出色的编码技能，项目影响很小。

术语 C：对系统的架构级思考，导致 4 个团队不得不重写他们的接口。一个改善当前系统的方法被抛弃，因为它不够酷。

“幸运”的工程师：

术语 A：进行了大量短期实验，Widget 生产增加了 10%。

术语 B：重新设计了网站，放弃购物车减少了 5%。

术语 C：重构后的后端堆栈，页面加载时间减少了 20%，导致跳出率下降 5%。

没有人会那么幸运。“幸运”的工程师正在做一些明智的选择。她选择了正确的项目，找到了验证某事是否值得做的方法，考虑工作时心中有最终结果。

工程师的工程师正在把一些惊人的技术能力浪费在错误的事情上。

你是否支持短期观点？长期项目呢？

我提倡一种平衡的方法，偏向于短期。如果你从长期的角度出发，你会有很多明年可能很棒的事情，但公司可能没有足够的时间来实现它们。如果你从短期的重点开始，你就会找到加速项目的方法，完善你的 MVP，迅速识别错误的方向并终止它。公司应该定义长期、中期和短期投资的组合。一种组合可以是 70%的项目在 6 个月内产生影响，20%在 1 年内，10%是长期的。根据你的情况和行业进行调整，并根据产品和公司的生命周期进行评估。

至于长期项目，做好它们！有时你需要创建一个新的数据库，因为你可以看到你的基础设施在一年内会崩溃。有时你需要研究一种新技术，这将解锁新的产品机会和业务线。考虑以下几点：

这对业务来说重要吗？具体是指什么？你能说服与你合作的其他人认为这比你现在手头上的其他事情更重要吗？
有没有更简单、更短，或者说不那么酷的方式来实现你正在做的事情？
有没有办法在构建整个系统之前快速测试假设？你最不想要的就是花一年的时间在新的机器学习基础设施上，并根据人们的偏好进行训练，结果却发现这些并不能推动销售。
公司其他部分会继续使用“遗留”技术并加以改进吗，以至于当你完成新技术时，会有两个运作良好的系统相互竞争？也许渐进式的改进比新鲜事物更好且干扰更小？
一个大项目的影响是否与所需时间成正比？如果不是，那为什么值得去做？

如果你决定追求一个项目，设定明确的里程碑，并确保你在每个里程碑上都在取得实际进展，而不仅仅是“还在努力”。不断问自己——这还合理吗？

这是否意味着你惩罚失败？

我们对失败的定义可能不同：

一个实验表明，系统的变化不会改善业务，只要你对客户或产品学到了些什么，这就不是失败。
一个你进行了 4 周的实验，结果发现你设置错误，必须重新进行，这就是执行上的失败。
一个持续一年的项目失败是很困难的。考虑一下为什么它失败了？有没有什么你可以做的，以使其更成功，或者更早地了解到它会失败？这也是一种管理失败——这个项目为什么会开始，为什么没有重新评估并停止？

我不惩罚失败。我奖励冒险和成功。做出正确的选择并执行得当会给你更高的成功机会。