技术 Spike：为何、是什么、何时用、如何做

Tech Spikes（技术 Spike） 是在产品开发中用于探索如何解决棘手问题的一种有用活动。它帮助你从当前开发流程中暂时抽离，提升理解、降低不确定性。

这份实用指南将分别说明：为什么要做技术 Spike、什么是技术 Spike、何时使用以及如何开展。

---

为什么要做技术 Spike

在开发新技术时，你几乎总会遇到一些不投入探索就无法得出答案的技术问题。
这些问题会给推进带来不确定性，使你难以进行计划、估时、拆解任务、识别风险并与干系人沟通。有时你甚至不知道该如何解决问题。

技术 Spike 为你和团队提供了一种方法，在正常工作流之外，去消除或至少减少围绕某个技术问题的不确定性。它为你在交付产品/平台的过程中切换到探索模式提供了“许可”和结构。

（Tech Spikes 草图）

---

什么是技术 Spike

理解为什么要存在技术 Spike 有助于我们定义它：

技术 Spike 是在产品或平台交付过程中，为了提升在期限、预算与技术要求下成功交付所需功能/特性的信心，而对问题与可能解决方案进行探索的一种活动。

其关键特征包括：

• 限定的探索时间（时间盒，timeboxing）
• 目标是探索、研究并加深理解
• 通过尝试实现一个或多个备选方案来开展工作（通常编写实验性代码）
• 不承诺交付所探索的功能或结果

值得强调的是第 3 点：要尝试去实现某个备选方案。正是通过认真开发和测试你的方案，你才能真正降低不确定性。动手做真实工作还能打破无止境的讨论与争辩。对实际解决方案的尝试——通常是写代码——是技术 Spike 与纯研究、设计或架构讨论之间的重要区别。

---

何时使用技术 Spike

当你意识到某个任务或特性存在不确定性，并且你不清楚如何完成、何时能完成，或者即使完成了也不确定能否满足技术干系人的要求时，就应使用技术 Spike。

当推进方案的唯一或最佳方式是对方案进行试验时，也应使用技术 Spike。

日常中，最常触发技术 Spike 的情形包括：

• 工程团队无法估算实现某个任务/特性/功能所需时间，因为尚不清楚应如何解决。
• 工程团队还无法拆分任务。有时先尝试部分解决一个复杂技术任务，可以帮助将其拆分为更小、更易管理且可估时或可分配的子任务。
• 同一技术问题存在多种可行解，且不清楚哪种最合适。
• 团队对某项新技术不熟悉，但它看起来或确实是最佳解法。
• 某位干系人对你的拟议方案缺乏信心。
• 团队无法就最佳方案达成一致。

不适合做技术 Spike 的情形：

• 问题规模很大，需要启动新的项目/计划/团队时。此时研究项目、原型（Prototype）、概念验证（PoC）或最小可行产品（MVP）可能更合适。粗略原则：如果一个技术 Spike 将消耗超过发布/里程碑预算或团队精力的 5–10%，需重新评估其是否合适。
• 技术 Spike 不是用来理解客户/用户需求的；请使用设计冲刺（Design Sprint）。不过，这里有灰度地带：你可能会用技术 Spike 来探索会改变用户体验的解决方案，因此也许需要再次验证其是否适用于用户/客户。
• 技术 Spike 不适合纯粹的架构或研究。这点可能有争议，但如果你没有通过写代码或使用技术对实际方案进行试验，那你只是在做更多架构/设计工作。

---

如何开展技术 Spike

开展技术 Spike 与处理团队的其他任务很相似。步骤如下：

1. 识别需要技术 Spike： 同时明确触发因素，因为它会影响后续的开展方式。
2. 定义验收标准（Acceptance Criteria）： 你需要什么样的产出？希望获得何种层次的理解？
3. 设定时间盒（Timebox）： 在多长时间内获得足够的理解，从而回到正常的规划与估时？
4. 分派成员： 谁来做？全队上阵还是某个人负责？
5. 动手实践： 开始对方案做实验。尽量少做纯桌面研究与讨论。
6. 撰写结果文档： 记录这次技术 Spike 的主要收获与结论。

有时你可能需要延长时间盒。如果要延长，请基于已有收获重新校准。
有时你可能提前完成技术 Spike。那就太好了！

※新西兰全搜索©️版权所有

敬请关注新西兰全搜索New Zealand Review 在各大社交媒体平台的公众号。从这里读懂新西兰！️