有人在一个工程流程的讨论下留了个问题，值得认真回答一遍。大意是：拖慢工作的那种摩擦，每个看板都能看见——周期时间、交付周期、一个 PR 排队等了多久。但真正拦住问题的摩擦，哪儿都不显示。它的价值只在事故复盘里露一次脸，而且没人会把那次事故倒推回“本来能拦住它的那一步”。于是问题来了：当反对它的那一方手里有数字，支持它的这一方只有一个故事，你怎么替那句“等等，要不要先确认一下”辩护？
很多本来有用的流程步骤，就是这么被砍掉的。而修法比听起来简单。
你吵不过一个不存在的数字
假设你向管理层提了一个风险，然后什么也没发生。常见的建议是“沟通得更好一点”——换成业务语言，说得更有说服力。有时候这确实是症结，换个说法就解决了。但很多时候，对方完全听懂了。他们选的那个功能身上挂着一个收入数字，你提的风险只是对“某天可能出事”的猜测。今天能数出来的收益，几乎每次都赢过以后可能发生的成本，你论证得再好也一样。
你吵不过一个不存在的数字。但你可以去找一个出来——这跟“想办法更有说服力”是两件不同的活。
你的经验本身就是一个数字
不少工程师漏掉的一点是：如果你干这行有些年头了，你手里很可能已经有那个数字，只是你没把它当成数字。
有人这样跟我讲过。他没法证明自己的系统之所以稳定，是因为一直把某个依赖保持在最新版本。但他从经验里知道，更新落后了，后面会疼得多。这已经不只是直觉——他见过跳过这些更新的团队后来发生了什么，那是真实的信息。只是它还没被换算成业务能拿来比较的形式，比如小时，比如钱。在你把它换成这些单位之前，对方没有任何东西可以拿来权衡。
把它变成一个数字
按我的经验，“这只是一个故事”的那一侧，几乎总能找到某种数字。可以看两个方向：
- 现在的时间 vs 以后的时间。今天花一小时，去避免以后可能几小时的宕机？这个数字很好用。但如果涉及的时间很小，那也说明了问题——也许你根本不需要这次暂停。
- 现在的成本 vs 以后的成本。企业听得懂钱。如果你能给一项改动标上金额，它能影响很多决定，宕机造成的收入损失就是个很有力的数字。但如果算出来成本很低，那同样是个信号：这次“要不要先确认”也许并不必要。
这一点很重要。如果你诚实一点，数字让你砍掉一个步骤，和让你保留它，是一样容易的。
有时候答案是“不是现在”
还有一件事，是工程师最容易跳过的。“要不要先确认”的答案有时候是“要”，后面跟着一句“但不是现在，我们有更优先的事”。
做工程的很容易钻进隧道视野，只盯着决策的技术面。但一家企业不只是技术，还有销售、用户、客户、钱。那个新功能可能是拿下一个大客户与否的分水岭，可能留住一个已有的客户，也可能你正在被竞争对手抢用户、需要尽快止血。而一个不完美的功能，往往能先把用户留住，之后再变好。
所以即便从技术上你确实该做某件事，也可能有充分的理由不在此刻做。
看整个生意
说到底就一件事：你不能只讲技术论证，你得把整个生意想进去。这也是为什么我认为工程师多了解业务侧如此重要——这样你推动的那些决定，才不会只朝技术那一头偏。
（作者在做一个面向小型工程团队的风险情报工具 Merge Lantern，会在每日简报里标出哪些待合并的 PR 最需要资深工程师过目。）