工程师硬通货系列二：需求平稳落地

本篇内容与第一篇相辅，核心依然是全局意识。上节侧重代码角度，本节侧重需求实现过程。本质上相通，没有需求，代码也就无需变更。

工程师的日常工作便是不断的实现各种需求，所以本篇把这块单独强调，也为了后续章节铺垫。

在产品眼里，任何一个待开发的功能都是 P0 级别；每个 feature （哪怕只是个神奇的脑暴）都决定公司能不能上市。工程师要做的不是去接受 PM 的指示，而且是要了解 PM 需求，去具象化需求内容。

每一个需求对我们来说都是工作量，有明面上的（需求实现），有附带的。而往往后者是无底洞，上线的“客服工作”会拉跨我们整个的工作节奏，杂事缠身。等你把所有的暗坑都填平的时候，这个 feature 也快下线了……

需求实现只是对一个码农最基本的要求，干净利索、不留尾巴才是一个工程师的素养。

如何对接需求？最快的方式就是砍掉需求。当然，我们不是消极怠工。在追求最高人效比上，PM 的意识与工程师应该一致的。

首先，应该明确 PM 是什么，但更重要的是为什么。产品为什么要这么做？预期的目标是什么？哪些数据表明这些目标达成了？如何去收集这些指标？

然后，去判断需要哪些人配合，去协调哪些资源。显示资源列表（比如，几个人多少天、需要什么部门配合），用工程数据辅助 PM 定位需求的优先级。

第三，明确效果预期（比如 DAU 提升 1%），尝试判断预期是否合理（积累数据经验，锻炼自己对“性价比”的敏感程度，逐渐让自己的判断变得客观、有效、权威。进而，可以硬性的角度，对 PM 的脑暴进行判分）。

第四，合理化解决方案，以最大化人效。80/20 原则，好钢用在刀刃上。比如，复杂的方案预期提高 30%，较复杂方案预期可以提高25%， 简单方案可能提高10%。是否无须一步到位，先用简单方案快速试水。

核心：明确 PM 需求是什么，更重要的是为什么。而且，为什么不一定推导成是什么。

确定了需求，就是排期、实现、测试、上线。排期是我们对项目、对自己最大的负责。一旦上线，所有的变动、客诉、数据异常…… 会为你提供无限多个修福报的机会，杂事缠身，你的生活会就此无序！所以，干净利索、不留尾巴是需求平稳落地的另一个关键。

首先，新的 feature 不可能让所有人都喜欢，甚至会刻意损害到某些用户。如何去引导用户，出现问题如何快速界定原因：bug 还是 feature。我们要做的不只是开发功能，更应该考虑后期如何应对反馈，提高响应效率。

其次，如果新 feature 某个关键功能出了 bug。我们应该如何跟用户解释？应该如何修复数据？修复如何快速？那么我们可能要考虑，我们要不要准备修复脚本，我们是不是需要操作幂等，数据操作该不该记录审计 log……

第三，代码的执行可视化（参考上一节）。不要让自己自己辛勤写出来的代码，直到下线那天才发现一直没有运行“对过”。

第四，最小化验证尽量止损。前期做足了准备，我们就可以上线了。但是，正因为各种指标可能会出现难以预期的变化，我们需要逐步扩大功能的影响范围。比如，放量给 1%、10%、20% …… 的用户，发现异常及时回滚。

• 在上线前，先想好自己应该关注哪些指标：性能指标、数据指标、上下游服务指标

• 上线过程，关注指标，逐步放量

• 遇到任何异常、疑似异常，及时回滚

不要把明眼可见的工作留到上线后，排期预留 buffer（项目的可控期，只限于上线前）。万一需求紧急上线，也应该争取 PM 的承诺，争取收尾的 buffer。