| 概述 | 预计耗时 | 预计发布 | 实际发布 | 最后一次修改 |
|---|---|---|---|---|
卓越工程师与普通工程师的细节差别
在执行过程改善工程能力
工程师的日常，离不开写代码做项目。在这个过程中，好的工程师和一般的工程师，表现上是有差异的。要知道在软件领域，好的工程师相较于普通工程师，能带来的价值可不是简单的线性关系，极有可能是数十倍、数百倍的生产力差距。为什么会有这样的差距，那就得从他们的日常细节说起。
在第一篇文章里，我们总体陈述了高效工程师需要理解的三个要点。今天我们由行动出发，看看高效工程师在日常是怎么做的。这里将包含四个要点，分别是：投资迭代速度，测量关键指标，尽早验证想法以及改善项目评估的技巧。
投资迭代速度
这一部分其实和尽早验证想法是相互照应的关系。为了尽早验证想法，我们就不得不做一些取舍。这样的后果就是，我们需要去迭代功能，因为不是所有的功能都一次到位。
很多时候你会遇到陈年老项目，极有可能已经放弃了迭代，只维持基本的功能。这样的项目，连重构可能都是奢望。对于此类项目，已经有够多的文章描述过对他的态度，这里不进行多的阐述。只要记住一点，迭代中才能学习。
为了达到迭代的速度，需要我们对工具做一些投资。无论是基本的开发软件，还是便捷的操作，都需要我们去达到一定熟练度。如果可以的话，优化你的debug工作流。做好项目的自动化测试、自动化发布以及版本管理。
很多工程师会认为，做到了工程上的优化便够了，于是忽略掉了非工程师瓶颈，实际上后者可能带来的影响更大。首先，如果你的项目依赖上下游，他们没有就位，你迭代再快也没用。其次，很多项目需要资源支持，获得上级的支持也非常重要。当然，接受批评远比接受许可来的更直接。
总体而言，在迭代上做投资，要求我们一要熟悉自己的工具，如开发语言以及开发环境。二要不断审视，去优化工作流。如版本管理，CICD等的思想的运用。三要留意非工程瓶颈，做好人与人之间的沟通协调。
测量才能改善
这句话是管理学里面的名言，我最近的多篇文章也出现了这句话。如果你想改善某件事，则一定记得去测量其关键指标。在项目开发中，测量指标有两个好处。一个是能够衡量开发进度；另一个是敦促自己思考：手上项目的价值点是什么，如果他的价值无法衡量，是不是就没必要做了，还是说有什么忽略掉的点。
选择指标，也不意味着什么指标都行。这个观点我也在多篇文章中提到，甚至未来的一篇文章，将会对其展开成一个小故事。从我个人的经历来说，知道测量什么指标，不该测量什么指标，对于一个组织来说，是非常要命的问题。这甚至比所处赛道、资金以及人才更重要。
衡量什么，就会得到什么。如果去衡量了一些容易获得，但没什么用的指标，反而会加深组织的认知负担，将组织引向数字陷阱。最典型的，我有一个朋友所在的公司，对于新产品的核心KPI为DAU，这个指标和他们每个月的奖金绑定。
为了达成这个指标，他们做了很多有损于用户但容易达成指标的事。例如将另一个产品的核心功能强制迁移到这个产品；例如在现金流产品中设置引流并强制跳转。所有人，包括工程师的绩效考核，都是依靠对DAU的贡献进行评估。这种情况，导致了很多短视的行为发生。这么做你说对吗？数字确实在短时间内提升了，但产品的长期留存却很糟糕。长周期的特性迭代，也以短期不能带来DAU提升被否决。实际上，这个产品的人员变动频繁。短期目标通过抹奶油的做法达成了，却由于竭泽而渔，死在了下一个DAU目标上。当资源倾斜停止，这个DAU指标回落飞快。
那么我们应该测量什么呢？衡量价值交付而非时间、衡量变化率而非切片数字、衡量细节而非总体。测量每周的生产力产出，而非每周的工作时长。测量产品的点击停留率，而非点击率。测量网站的99%分位响应时长，而非平均响应时长。测量bug的暴露数，而非bug的修复数。测量周注册用户数，而非注册用户总数。测量分层的用户活跃数，而非用户活跃总数。
数字也会撒谎。不同的数字，你用不同的角度去解读它，完全可以产生对立的结论。因此，请对数据持有怀疑态度。为了增加数字的可信度，可以从以下方面入手。数字存档，留下数字记录。对于实时数据来说，构建工具流以保证数据准确度。交叉着从多个角度去验证数据，当数据异常时，尽早诊断数据。
尽早验证想法
这点和加快迭代速度其实是相互印证的。传统的瀑布流工作法的弊端：大家写好规划再来开发，以至于交付时需求变化，产品无法使用的例子数不胜数。通过尽早验证想法，可以减少浪费，也可以尽早修正航线。AB测试这些也都是老生常谈，这里不再赘述。
想专门挑一个点来说，就是作者提到的单人单点项目。这类项目其实对于数据挖掘、算法类还是很常见的。因为毕竟不像构建大型网站或大型APP，这类模型需求往往一个人能够覆盖住核心部分。其缺点就是，你的代码风格和约定写法，除非在别人的基础上改，否则很难知道有无更高效的写法。同时，也会增加其他人的维护难度和风险。
对于单点项目，作者建议寻求及时反馈。保持开放心态，接受反馈也是成为一名更好工程师的前提。闭门造成，拒绝接收建议，认为自己最牛的工程师，往往会被视为技术怪胎。没有人愿意和这样的人合作，也没有人乐意在这样的人手下工作。
写代码前写文档，优先设计并开发交互界面或接口，早注释常注释，寻求code review，寻求团队内其他成员的建议，在争议项目启动前，先赢得广泛的支持。这些都是很重要的细节，用于区分一般工程师和卓越工程师。
改善项目评估的技巧
对于商业世界来说，一个具体的时间将给人稳定的预期。没有人想听到苹果说，下一次发布会不定期。也没有人想看到，一个博主的文章或视频，三天打鱼两天晒网。对于工程师来说，即使评估项目再难，也得给出一个具体的时间。一方面是给到业务部门稳定的预期，另一方面也是在需求变化之时，能够评估变化的成本。
项目评估，原作者也给出了很多有用的建议。毕竟是是纵横硅谷十多年的老司机，值得我等小辈学习。最简单的，是分解项目到最小单元。还有，让真正做这件事的人去评估，而不是上级在外面开空头支票，让执行者倒排期。也可以参考历史数据，或者是多方面数据结合来排期。
评估出来的时间，一定是这个事情的实际耗时，而非某个人想让他花多少时间，无论这个时间是更长或者更短。将结果看作概率分布，而非具体时间。当然，也要留意锚定效应，更要留意人月神话。加人在软件开发领域，并不会让项目完成得更快。最后，无论如何给评估设定时间窗口，在时间窗口到了以后，给出一个数据。允许其他人怀有异议，挑战你的排期。
即使我们前面做得再好，也有可能项目会延期。无论是成员休假，或者外部环境变化，都是需要面对的事实。如何应对可能的项目延期，是通过加班吗？
原作者的答案是不。首先要了解加班的局限性。增加工作时长，并不会显著增加产出，反而会降低单位时间内的生产力。其负面作用却是显著的，首先会让团队成员身心疲惫，也会让团队的灵活性丧失。还有一点，当你发现项目可能延期时，事实上你可能比预期的更落后。退一万步来说，加班冲刺即使勉强达标，也会留下沉重技术债。
怎么做才能改善。当你发现项目延期时，首先需要确认是什么因素导致的，让每个人都理解延后的原因。并且检查这样的事未来是否会再发生。在开始之初，准备切实可行的计划表以及里程碑，非常重要。当你发现不能按时交付时，放弃时间节点，优先交付核心功能；或者放弃项目，减少沉默成本也是一种选择。
小结
这部分内容比我预想得多，导致了发文的延期。这就是一个活生生的项目评估失败例子。从中学到的东西，正是本文想传达的。测量你的进度指标，去投资你的交付速度，改善项目评估技巧，这些正是卓越工程师的小细节。