程序员影响力指南

我过去在一家重视交付的公司工作。平时的工作很宽松，只要按照checklist把事完成就行了。我的薪酬和晋升与产品在市场上的表现，和我对公司的影响毫无关系。只要我按时交付，我就是棒棒的。

然后我在一家专注于影响的公司工作。只要对业务有影响，啥时候交付以及怎样交付就显得不那么重要了。我每6个月被评估一次，这意味着，我需要在这6个月中对我的影响进行准确，可量化的评估。

思考一下
在一个交付导向的公司，一个项目可能会持续三年，而我一直有在跟着项目走，看起来挺厉害的。
在一个影响导向的公司，如果我这一年没有啥成绩，我看起来就会很搓

在交付导向的公司，QA的作用是阻止那些明显不OK的东西继续工作。
在影响导向的工作，QA的作用是和工程师一起合作以确保功能正常工作。

在交付导向的公司，发布日是神圣的。
在影响导向的公司，只有当我们认识产品足够好的时候我们才会交付。

那家交付导向的公司曾经是500强，现在已经嗝屁了。
影响导向的公司还有滋有味的活着。

什么是影响？
最直接的答案是商业影响。赚更多的钱，省更多的钱，增加客户，增加交易数量，减少支持成本。专注在公司的首要目标上。有许多其他方式方法去影响公司，只要他们和这些目标紧密联系起来：

减少事故
修复重大BUG
在用户关注的领域增加表现力
让基础设施更加便宜/快速/稳定
构建可以帮助到他人的系统/架构
减少开发者的诊断/建造/交付时间
增加你雇佣的人的质量
指导他人（让他人承认你是有帮助到他们）

不是所有的事情都是可衡量的
修复一些影响特定特性的UI小故障并不容易被衡量，但它确实增加了整体的品牌度以及提升了用户对服务的感受。从长远来看，它将影响净推荐值。

净推荐值（NPS）又称净促进者得分，是一种计量某个客户将会向其他人推荐某个企业或服务可能性的指数。它是最流行的顾客忠诚度分析指标，专注于顾客口碑如何影响企业成长。通过密切跟踪净推荐值，企业可以让自己更加成功。

消除技术累赘，或者是让系统更加可靠也不是那么容易被衡量。如果你没有让你的系统更容易的延展，你的开发速度会因此受到影响而降低。所谓的艺术，是真正去挑选有用的东西，而不是简单的，做一个新的酷酷的东西。

代码审查会让你的Team变得更好，这个毋容置疑。

如果你认为这个很重要又不知道如何去衡量，和你的领导或者同事沟通下。看他们是否明白这个事情的价值。他们或许有一些对如何衡量这个事的小建议

虽然不少所有的东西都是可衡量的，你应该去设置一些衡量标准

为什么设立衡量标准？

看看以下人们经常在回顾自己的表现的时候说的话：

我可以准时把我的那块东西交付
我参与了公司的前端项目的架构回顾
成功的协调了移动端，前端，分析部门和QA
我参与了文化建设会议

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

接下去考虑这些问题：
让从产品页面到最终付款的流程缩短的10%的时间
参加了20个面试，增加了2个新组员
开了一个全球工程师会议。明确了3个需要重构的项目，2个已经完成，并且出错率下降了20%

这么描述的话，这些项目对于公司的影响力就比较明显了。

但是，我并不是PM啊
工程师和产品经理应该用最低限度的努力去构建产品。工程师每天盯着产品，看代码，改功能，修Bug.影像力在这个事情上，并不见得一定是做新产品。有影响力的事可以包括诸如UI修复，构建更可靠的系统，以及其他让产品更好用的事。举个栗子，识别在移动设备上的折叠，向下的关键动作，或者改进一个登录框，可能会对公司的关键指标产生很大的影响。这些都是工程师能识别、沟通和驱动的东西。

如何思考影响力
思考一下对公司价值的影响
你是写了一个规范，还是写了一个规范的服务并且改变了X
你审查了许多代码变更，还是在ABC都审查完之后，依然审查到了一些敏感的代码
你是发送一个调查，还是，你发送了一个调查，并且指出有问题的区域，同时让工具团队确信这个东西必须需要改进？
你是构建了一个系统，还是构建了一个促进了X的系统，同时被团队A和团队B都采用了。
你是跑了一个测试，还是跑了一个测试并且告诉大家，用户不喜欢在吃饭时间接受推送

如果不去思考你拥有的影响，你可能只是在浪费你和别人的时间，所以，思考下，在整个产品的开发过程中可能会有的影响力。

构思阶段
这个重要吗？为什么？
如何衡量这个产品是否成功？
这个成功与公司的关键目标联系的紧密吗？
如果你做了这个得到了结果X，你知道如何继续下去吗？如果你不知道如何处理的结果（特别是一些不期而至的结果），思考一些其他对于如何衡量影响力的有效信息并且去试着继续下去。别只是假设成功。

计划阶段
这个真的是MVP么？还是这个只是超功能了？
在你打算花6个的时间去做一个完整的系统的时候，你能花2周时间做一个工程计划以试探这个项目是否OK?
你需要一些设备/工具去帮助理解成功/失败吗？
在多快的时间内，你会知道这个项目是否值得去继续？

执行阶段
当你完成一个功能，试试先。你觉得他们会按照设想的运转吗？有什么需要改变什么？从用户角度来看，哪些是不对的或者是不理想的？
你有任何让蓝本变得更好的建议吗？如何去更快的验证这个建议？

在着手/测试/调试阶段
多早你会知道你的系统被准确的设置了？
多久检查一次结果？等了4周后最后发现一个试验并没有正确设置真的挺浪费时间的。
你有结果吗？结果有告诉你怎么做?
实验失败了吗？太好了。。你学到了点啥？谁需要知道？

这难道不是收获运气吗？
思考下你所在公司在表现审查方面的侧重点。你会因为交付得到奖励，还是因为影响力得到奖励？
目标是奖励那些做出好的决策的人。运气可能包括在我们做的任何事情里面，思考下接下去的2个场景：

中二工程师

团队A：出色的计划，然而项目并没有成功
团队B：出色的编程技巧，然而项目的影响力有限
团队C:对系统的架构层面的思考，导致4个团队不得不重写他们的接口。一种使当前系统更好的方法被丢弃，只是因为它不够酷。

幸运工程师

团队A :做了很多短期实验，小部件产量增加了10%
团队B：重做了页面，废弃的手推车降低了5%
团队C：重构后端堆栈，页面加载时间减少20%

不是所有的人都是那个幸运儿，幸运儿总是会做一些聪明的决策，她会挑对项目，会去区分哪些值得做，并且会去评估最后做的工作的价值。

而中二工程师只是在一些错误的事情上面白白的花费力气。

你是否会提升短期的视野?那么长期项目呢?
为短期项目，我提倡一种平衡的方法。如果你开始了一个长周期的项目，明年你会有很大的收获，但是公司只会在意你短期的产出。短期项目可以让你快速成为MVP。而公司应该用一种组合的方式去设定长期，中期和短期目标。比如70%的时间放在半年周期之内的项目上，20%放在1年周期项目上，10%放在更长久的项目上。根据你的情况和你的行业进行校准，同时根据产品和公司的生命周期进行评估。

如果是做长期项目，把他们做的棒棒的。有时候你需要做一个数据库因为你会看到在接下去的一年内你的表现会是向下的。有时候你需要一些新的东东去释放新的机会和业务线。

思考如下问题：

这对业务重要吗？以何种方式?你能说服你的同事这个项目比目前手头做的远远重要的多吗？
有没有一种更简单、更短、更酷的方式来实现你所做的事情?
有没有一种在构建整个系统之前快速测试假设的方式方法？你最不想要的结果，可能就是在新的机器学习基础设施上工作一年，并训练人们去习惯它，到最后却发现那些玩意对销售结果一点也起不了作用。
公司的其他部门是否会继续使用“遗留”技术并改进它，以至于当你使用新技术时，你会有两个运行良好的系统？也许小步迭代会比直接引用开新产品线更安全？
这个项目的所产生的影响与投入的时间成比例吗？如果不成比例，那为什么要去做呢？

如果你决定做一个项目，设立明确的里程碑并且确定你们正在坚实的朝着目标走去，若不仅仅是，我们还做着呢。经常问自己-我们是否还在正确的路上？

这是否意味着你要惩罚失败？
我们对于失败的定义可能不一样

实验表明,系统的改变不会改善业务并不是一个失败,只要你从你的客户或你的产品中学到了东西
实验表明，你跑了4周，只是发现你错误的设置了系统并且需要重新运行的时候，这只是执行层面上的失败
大项目的失败总是心塞的。思考为何他会失败？有没有一些你本可以做的一些让这个事更成功的事，或者在他失败前提前知道？这属于失败管理，为什么这个项目开始并且为什么他没有被重新评估并且被停止？

我不惩罚失败，我从风险和成功中收获。做正确的决定并且执行到位会让你更容易接近成功。

原文出处

https://medium.com/@erand/we-are-all-product-owners-an-impact-guide-for-engineers-76a2b4342c74