沙子、板砖和钻石

上下文

如果有一个需求澄清过程的话，很可能会有两种声音盘旋在会议室的上空。一种声音：我发的文档你提前看过了吗？你有什么不明白的内容吗？这个倒霉文档实在不想再花太多时间和精力了，我的事情太多了。另一种声音：需求能靠谱一些吗？一堆细节难道这不是该写的需求吗？真希望拍脑袋的想法少一些啊。

在这样的会议背景之中，往往会很容易陷入细节的泥潭。遇到一个问题会牵扯出新的问题，讨论新的问题又会牵扯出新的问题。一直聚焦在新产生的问题之上，毫无整体推进感觉。

需要一个需求明确度的概念，什么是讨论清楚了。

类似概念

我们从需求实现阶段的定义方式，来进行类比：

看板

• 想法池（Idea pool，已提出）→ 已选择（Selected） → 已分析 → 已设计 → 已开发 → 已测试 → 已上线。

Scrum的基本建议

• 待办（TODO） → 在办（Doing） → 完成（Done）

这些方式从需求实现角度，或研发过程价值增加过程对需求（0）到实现（1）之间进行灰度切分。这样就可以管理更细致的状态。比如待办（todo）我们可以看到工作的队列，从在办（Doing）我们可以看到在制品（WIP）数量等等信息，这样团队就可以实现更细致的管控。

关键特征

概念

这是对沟通内容进行明确度进行的分类：

钻石

• 细节完备
  • 对于当前的需求来说，没有任何细节的描述是缺失的。需求可以指导开发与测试最细级别的具体工作。
• 边界清晰
  • 什么是边界：需求边界是指可以清晰分辨出本需求覆盖的内容，哪些不是本需求覆盖的内容。边界清晰的另一个含义是本需求不存在需求范围蔓延之说，需求边界是锁死的。另外边界清晰的副作用是可以明确哪些是缺陷，哪些是新增功能。
  • 什么是模糊：清晰的反面是模糊。需求到钻石这个阶段任何的描述要不能有任何模糊的表述。如果研发人员认可这是钻石需求的话，他可以基于清晰的文档也可以基于脑中对于这个需求的理解。但不管怎么说需求的任何内容是清晰的。

钻石需求就如同晚上开车的近光灯一般，把所有覆盖的细节全部显现出来。那些没有照到的黑色地方，我们称之为……

沙子

• 存在未知潜在风险
  • 未经沟通，也未经拆分和估算过

这种需求就是灯光未能照到的黑色区域，黑色区域有可能是平坦的路也有可能存在某个让人意想不到的障碍。

板砖

• 粒度相似（经过拆分）
  • 未经过拆分的需求其实就是无法实施和管理的需求，拆分成合适粒度非常重要。
• 拥有估算
  • 如果不让开发进行估计的话，水有多深也是未知。估算一方面是形成大概工作量的手段，另一方面是管理风险的技巧。
• 风险可控（具有可实施性）
  • 虽然使用拆分和估算来控制风险，但风险也有可能从其他维度影响需求。

期望的需求沟通与实现的过程是这个样子：渐进式需求澄清

项目一开始，所有的需求都应该是沙子状态的，就如同我们要开车探索一片未知的大陆。需求的板砖状态就如同远光灯，让我们尽可能的确保已知的最远处风险是小的。近处我们需要确保更小的风险，因为车越快，我们打方向就不能太急。

角色

在需求校准会议中，两个关键角色分别负责推动需求状态的改变和确认需求的最终状态，其他角色则在支持并确认最终的钻石状态：

业务人员

或需求分析人员、产品经理

• 主要责任： 推动需求状态的改变。
• 具体任务：
  • 解释和传达需求的业务背景和目标。
  • 推动需求从沙子状态向板砖或钻石状态转移。
  • 记录需求进入下一个状态所需的信息或内容，并确保这些要求得到跟进。

研发人员

负责人或关键开发人员

• 主要责任： 确认需求的最终状态。
• 具体任务：
  • 评估需求的技术细节和可实施性。
  • 确定需求是否满足标准，是否可以从一个状态推进到下一个状态。
  • 对需求的最终状态做出确认，确保需求已具备清晰、可实施的标准。

过程

需求校准会议

在需求校准会议中，团队的主要目标是对需求的状态进行校准，同时状态的转变过程可能会在会议中或会议之外随时发生。以下是该过程的关键步骤：

flowchart TD
start1([开始]) 
short([近期需求])
long([远期需求])
out([范围外需求])
todo([责任人])
start1 --> bz[业务人员]
bz -- 推进 --> t{"`技术人员
确认状态`"} 
t -- 潜在风险 --> 沙子 
t -- 风险可控，粒度相似 --> 板砖
t -- 细节完备，边界清晰 --> 钻石
t -. 有阻碍 .-> 待办
沙子 -. 远期需求 .-> bz
沙子 --> out
板砖 --> long
板砖 -. 近期需求 .-> bz
钻石 --> short
待办 --> todo

1. 状态回顾与初始校准：
   • 会议开始时，业务人员和研发人员会共同回顾所有需求的当前状态，将需求卡片贴在表示当前状态的区域（沙子、板砖、钻石）。
   • 团队确认需求的当前状态，并讨论是否存在需要进一步细化或调整的内容。
2. 需求状态的动态调整：
   • 在会议中，团队根据讨论的结果，可能会立即对某些需求的状态进行调整。例如，如果某个需求经过详细讨论后被认为已满足钻石标准，则该需求卡片可以立即从板砖状态移动到钻石状态。
   • 同样，如果在讨论中发现某个需求的细节仍然不明确，可能需要将其状态从钻石或板砖退回到沙子状态，以进行进一步的澄清和处理。
3. 标记待办事项与后续行动：
   • 对于那些尚未达到预期状态的需求，团队会标记需要进一步工作的待办事项，并在会后跟进处理。这可能包括需求文档的更新、进一步的技术评估或与相关方的额外沟通。
   • 这些待办事项的完成可能会在会议之外进行，但团队会在下一次会议中重新审视这些需求的状态。
4. 会议总结与后续计划：
   • 会议结束时，团队确认所有需求的当前状态，并制定下一步的行动计划。具体责任人会被指定，以确保在下一次会议之前能有实质性进展。
   • 如果有需求的状态在会议之外发生了变化，团队会在下次会议中进行再次校准，确保所有人对需求的状态有一致的理解。

通过这种灵活且动态的需求校准过程，团队能够更高效地管理复杂项目中的需求状态，无论状态转变是在会议中还是会议外发生，都能确保需求的清晰和一致性。

相关概念

与故事地图的关系

沙子、板砖、钻石的需求状态概念与故事地图紧密相关，互相补充，提升了需求管理的有效性：

• 需求状态与故事地图：
  • 在故事地图结束时，所有需求都应达到板砖状态，意味着需求已经过初步拆分，并具备足够的明确性。
  • 在进入开发之前，一些关键需求需要进一步细化，达到钻石状态，确保开发顺利进行。
• 故事地图的结构与决策：
  • 故事地图通过二维方式展示需求的整体结构，帮助团队了解项目全貌并做出优先级决策。
  • 通过将需求状态（沙子、板砖、钻石）映射到故事地图中，团队可以清晰地看到需求的进展情况和成熟度。
• 沙子需求的管理：
  • 即使需求处于沙子状态，也可以通过附加假设或声明将其纳入故事地图。这使团队能够在需求尚未完全明确时，仍然进行讨论和规划。
  • 随着项目的推进，这些沙子需求可以通过进一步的澄清和细化，逐步转变为板砖或钻石状态。
• 互补性：
  • 故事地图提供了项目需求的全局视图，而沙子、板砖、钻石概念则帮助团队管理和细化每个需求的状态。两者结合，使团队既能从整体上掌握项目进展，又能确保每个需求被适当地处理和准备。

与 DEEP 原则的关系

沙子、板砖、钻石的需求状态概念为 DEEP 原则中的 “Detailed Appropriately” 提供了一个有效的落地方案：

• Detailed Appropriately（适当的细节）： 过去，这个原则缺乏明确的实施方法。现在，沙子、板砖、钻石的状态管理为不同阶段的需求提供了明确的细节标准：沙子状态的需求相对模糊，板砖状态要求风险进行了控制，并在钻石状态达到全面、详细的定义。
• Estimated（经过估算）： 板砖状态的需求必须经过估算，确保在开发前具备明确的工作量预估。
• Emergent（浮现式）： 需求大多会在项目过程中逐步明确，这已成为常态，除非在固定价格合同中。
• Prioritized（有优先级）： 敏捷方法本身强调优先处理最重要的需求，这与板砖和钻石状态需求的管理方式自然一致，无需过多解释。

这种结合确保了 DEEP 原则能够在实践中落地，使得需求管理更为系统和有效。

原子敏捷性的考虑

需求沟通的关键难点在于需求清楚了，和需求不清楚的非黑即白状态。如果所有版本的需求都明白清楚了，其实就是传统瀑布的需求实现方式。大部分的敏捷软件开发过程其实是平衡沙子、板砖、钻石需求在当前整体需求中的比例的过程。我们使用 更明确的灰度 原则来明确Detailed Appropriately（适当的细节）。增加了风险可控的板砖状态来实现交付计划的远光灯。

敏捷的需求沟通过程就是在平衡业务方与研发方，但很多团队已经变成一边倒的需求宣讲会议。在沟通的过程我们希望是一个双向沟通的过程，在这里使用业务需求方推动，研发实现方确认的方式让双方都拥有 更广阔的视角 ，当然这样的明确需求状态的方式也实现了 更强悍的纪律。