发现人们实际执行的工作流
需求不会等在会议里被收集。它们散落在行动、变通做法、记录和分歧之中。
类型： Learn + Build 语言： Python（标准库） 前置要求： 阶段 14 第 47 课 预计时间： ~70 分钟
学习目标
- 将当前工作流建模为带证据的有序行动。
- 区分直接观察与报告或推断出的行为。
- 定位摩擦、交接、权限和隐性状态。
- 让不确定主张保持可见，而不把它们变成需求。
从当前系统开始
不要从询问人们想要什么功能开始，先重建现在发生了什么。
每一步记录：
| 字段 | 示例 |
|---|---|
| 执行者 | 值班工程师 |
| 触发器 | 生产告警到达 |
| 动作 | 打开告警，然后搜索仪表盘 |
| 输入 | 告警载荷和部署记录 |
| 输出 | 候选服务和负责人 |
| 摩擦 | 在三个工具之间切换上下文 |
| 权限 | 事故指挥官批准写操作 |
| 证据 | 屏幕录制、事故日志、runbook |
工作流比屏幕大得多。它包括等待、复制粘贴、边路沟通、批准、错误恢复，以及人们已不再注意到的步骤。
证据有强弱
使用简单的证据阶梯：
- 直接行为： 观察、追踪、录制或系统事件。
- 产物： 工单、runbook、日志、表单或完成的输出。
- 报告的行为： 某人描述自己如何工作。
- 推断： 团队得出大概发生了什么的结论。
四者都有用，但只有前两项直接证明当前行为。给其余项打标签，避免置信度悄悄膨胀。
mermaid
flowchart TD
T[触发条件] --> A1[参与者行动]
A1 --> H[交接]
H --> A2[下一位参与者行动]
A2 --> O[结果]
E1[直接证据] -.支持.-> A1
E2[产物] -.支持.-> H
E3[报告的行为] -.支持.-> A2搜索四类事物
- 摩擦： 重复劳动、延迟、重新输入或恢复。
- 隐性状态： 带在记忆、聊天或个人笔记中的事实。
- 权限： 被允许作出关键变更的人或系统。
- 例外： 正常工作流不再正常的情况。
AI 功能常在交接和例外处失败，因为只塑造了 happy path。
不要把分歧平均掉
两位用户可能因为充分理由执行不同工作流。理解它们是否代表以下情况前，保留变体：
- 不同角色；
- 不同风险级别；
- 旧流程和当前流程；
- 专业水平差异；
- 真正的策略分歧。
平均后的工作流可能谁都描述不了。
动手构建
实验为每个工作流步骤保存证据，验证顺序与置信度，计算直接证据比例，并写入 outputs/workflow-evidence.json。
bash
python3 code/main.py
PYTHONPATH=code python3 -m unittest discover code/tests -v加入一条部署记录缺失的例外路径。保持主顺序不变，并记录分支从哪里开始。
练习
- 不采访任何人，仅用日志重建一个工作流。
- 访谈一名用户，为仍缺直接证据的每个主张做标记。
- 加入一条权限边界和一个故障恢复步骤。
- 建模两个工作流变体，不把它们合并。
- 找出一项移除可见步骤、却让隐性工作原封不动的拟议功能。
延伸阅读
- Nuseibeh and Easterbrook, Requirements Engineering: A Roadmap，尤其讨论了把需求获取视为解释、建模和验证，而非简单采集。
- Gotel and Finkelstein, An Analysis of the Requirements Traceability Problem，了解为何保留需求与其来源的关系如此困难。
拿去用
保留 outputs/workflow-evidence.json。下一课会把观察到的摩擦和不确定性转成假设地图。