技术工作的一二三之价值观方法论

写在前面：

梁宁前一阵有篇十万+的文章，《比能力重要 1000 倍的，是你的底层操作系统》，里面提到的情绪是推动人的基础。但每个人都不一样，每个团队和业务的状态也不一样，上天没有给予卓越操作系统时，如何给出高出水准的性能呢？

公司业务在快速发展，每天每时都会遇到新的问题或者揭出旧的债务。日日救火，兵来将挡水来土掩，看上去工作充实，但浮于表面的事务带不来任何成就感。依赖人的能力不如依赖体系的运转，依赖流程制度不如依赖文化精神。从快餐走向内功的过程，需要价值观方法论的支持。

价值观是缺哪补哪，面对当前团队和业务的状态，结合自己的过往经验，技术团队做事的准则如下：用户价值为导向，面向解决问题，以数据驱动，死磕。

用户价值为导向。

价值观第一条是用户第一。技术团队面对的用户包括每一位 C 端用户，也包括公司内部每一位同事。

        技术工作体现在 C 端用户价值上的，除了落地业务需求之外，最突显的是技术指标伴随的用户体验。APP 下载时间是不是够短、启动的是不是够快、运行是不是稳定、操作是不是流畅，这些甚至从用户还没有体验到完整的产品功能就已经开始影响着用户对 APP 使用的感受。功能完成只是技术工作的起点，用户体验的路永无止境。

        对于内部支撑，由于开发流程的短平快，功能落地大多受技术实现的影响更重。正例是近期的云集需求，在用户购买后需要发送短信通知并在后台标记发货。三天卖出去 2600 单，如果都手工处理，一是用户收到短信的时间不可控，体验较差，一是内容运营的同学恐怕要疲于奔命在重复操作中。

技术同学支持的价值就在于此，尽可能减少重复工作，不管是周末加班还是挤出优先级都是值得的。反例是 H2 的管理后台，数据实现的痕迹过重，很多功能没有考虑到操作体验，将过多的数据信息暴露在运营同学面前，造成困惑不说也容易出错。虽然这些有各种各样原因，但对于新增功能，我们应当在操作体验和内部业务使用上多考虑一点，节省同事们的时间，同样是用户价值。

面向解决问题。

对于价值的体现，有时候很难界定，一件事情是否有价值，价值高低多少都需要有评判标准。换个角度看，那就是这件事情是不是解决问题，这个问题影响了多少人，这样对于技术面对的很多工作都可以有了答案。比如我们做重构的价值在哪里，是不是解决什么问题，如果没有就不要做。

同样换个角度看，如何去找有价值的事情，那就是去看看哪里有问题。主动去体会产品中、工作中、团队中或者自身的方方面面，也许会发现这个世界大有可为。船长多次提到，不要做只感动自己的事情，能够为用户为团队解决问题是技术这个工种的安身立命之本。

以数据驱动。

评估工作结果往往是很难的事情，尤其是在专业性较强的岗位，隔行如隔山，能够让其他同学理解是不太容易的事情。但是数字大家都看的懂，趋势上升下降、幅度大小，是好是坏一目了然。数据指标也有大有小，比如在 CS 交互的核心指标上，平均响应时间是个最终方向。其中可以拆解到 DNS 解析、建联时间、服务器首包、整体延迟，每一个新的数据都提供了新的工作的思路和方向。再往下沉，服务器首包可以拆解为接口慢响应的平均比例到核心接口的慢比例，继而跟业务逻辑设计、数据库、缓存设计等挂钩。

每当数据下沉一级，会像是发现一个新大陆，但也更聚焦，结果会更明确。因此，在工作中遇到坎的时候，想办法提炼数据，琢磨它们，数据有时会说话。

死磕。

价值观的第四条是使命必达，我希望用更重的语气来表述这一点。在近期的沟通中，有些同学会为了 KPI 的数字讨价还价，无非想让这件事更轻松地达到。数据是我们用来衡量价值的方向，它是起点和结果，但也只是过程，是为了我们创造用户价值要迈过的一个个跨栏，过于看重反而会忘记了最初的目标。

很多技术指标我们并不知道行业中大家都做到什么样，但是清楚这些指标代表着哪些价值，因此我们只能自己挑战自己，定下一个可以跳跳摸得到的点，迈过去再冲向下一个。日常的工作常常是已知的过程，产品同学捏碎需求，我们按步实现。但是在跳一跳的努力中，全部是需要去探索的事情，不知道有什么方法，也不知道能做到什么结果，我们要克服那些未知，就要带着死磕的勇气。

在这之后，往往凤凰涅槃。