如何应对随机情况

由于你不是老板，享受不了老板的特权，所以你的产品很可能被源源不断的出于 好心却带来破坏的建议所伤害。不幸的是，当产品变得更重要更接近发布点时，你收 到的建议也会变多，因为通过内部测试过程你的产品获得了更多的曝光。你无法摆脱 这些建议，但你可以使它们不会干扰或“打乱”你的团队。随机情况感觉就像你在阶 段2 时有个人跑过来扔了一个 18 面的色子，然后说“情况变了，改去阶段 13 吧”。

这通常不是你的错。随机情况的来源有很多，最常见的就是新的特性需求，也可 能是公司的优先级发生了变化，甚至还可能是你被强制接受某些大规模的基础设施变 更。你必须要从容应对这些随机情况并设法照常推进业务。

为了应对新的特性需求，你可以创建一个简单的共享文档来集中记录它们。将文

深入探讨这些应对职场政治的诀窍和技巧超过了本书的范围。在我看来有些人天生就

请咽下狗屎三明治并撰写新的产品需求文档。切记重置你的时间表，并忘记这么做将 对你的团队造成极不公平的后果。

所有这些策略也适用于应对大规模的基础设施变更。这里还有一个关于如何与你 所依赖的基础设施打交道的经验法则：你需要坐在火车中部。基础设施项目就像一列 驶进城里的大型的、轰轰作响的火车。启动这类项目需要很长时间，且多数情况下它 们都声势浩大、一意孤行且极不讨人喜欢。如果你位于火车前列，即基础设施的早期 使用者，你将遭遇Bug、肥胖笨拙的婆娘和偶然出现的卡曼格·希亚跑车——没有一 样是有趣的事情。所以你不会想成为一个重大基础设施项目的早期使用者。

另一方面，如果你挂在火车尾部则很有可能被敲打鞭策。管理层会问：“你为什么 还不移植到X 呢？”你的系统很可能开始出现一些滑稽的故障。对你的旧的基础设施的 支持将慢慢消失，总体上你将处在一个很不舒服的境地。所以你不会想挂在火车尾部。

你需要的是坐在火车中部——刚好靠近拥有鸡尾酒和椒盐卷饼的休闲车厢。找到 两到三个可供参考他们进展的团队。当发现某个团队切换到新基础设施的过程相当轻 松，那么你也是时候切换了。新基础设施的文档资料这时很可能比较全面了，但你还 是可以请求那个成功切换的团队来指导你完成整个切换过程。你从用户那边获得的指 导几乎总是比你从基础设施开发者那边获得的指导要好。