项目
人机协作工作流的落地
把方法装进一个真实团队, 并且能测出它是否起作用
在一个真实工作团队里导入人机共创方法, 并建立度量, 使「有没有用」成为可回答的问题而不是主观印象。
背景
常见的失败路径
我们观察到方法导入通常这样失败:
- 培训完就结束。讲了两小时, 没有进入日常工作, 三周后回到原样。
- 只有热情的人在用。方法变成少数人的偏好, 而不是团队的做法; 一旦这些人换岗, 全部归零。
- 无法判断是否有效。团队觉得"好像顺一些", 但说不出哪里顺; 于是遇到压力时最先被放弃。
★ 第三条是根源。没有度量的改变无法被守住——因为它在争夺资源时提不出证据。
设计思路
从观察实际工作开始, 而不是访谈
请团队里用得好的人实际做一遍, 我们在旁记录。多数关键动作他自己不会主动提及, 因为它们已经变成习惯。
提取判据, 而不是提取技巧
技巧无法迁移, 判据可以。我们要拿到的是"他凭什么认为这个产出可以用"。
度量与方法同时上线
★ 我们不接受"先用起来, 以后再看效果"。度量在第一天就要存在, 否则三个月后没有基线可比。
委托与保留
委托: 记录的收集、判据检查表的执行、评测数据的汇总。 保留: 判据本身的制定与修订、以及是否继续采用的决定。
系统架构
本项目的"架构"主要是流程与度量, 而非软件系统。
一、方法层
基于人机共创框架裁剪出该团队的版本: 保留五步骨架, 步骤内容按其实际工作替换。
二、检查表层
每一步落成可勾选的完成判据。检查表刻意做短——超过五项就没人填。
三、记录层
判据、否决理由、失败案例的存放位置与格式。与知识资产项目共用同一套结构, 使沉淀可被检索。
四、度量层
四个指标, 全部可从记录中直接得到:
- 返工率——产出被推翻重做的比例
- 判据缺席率——多少次协作在动手前没有写下判据
- 沉淀复用次数——上一轮的记录被下一轮实际引用的次数
- 可接手性——由未参与者复述判断链条的成功率
五、固化层
其中被证明稳定且重复的环节, 按Agent 设计方法固化为 Agent。★ 固化必须在方法稳定之后, 顺序反了会把错误的做法凝固下来。
Agent 流程
导入过程本身按五步组织:
- 观察——记录团队当前的实际做法, 不做评判。
- 理解——与团队一起明确: 现在最大的痛点是什么, 什么样的改变算成功。★ 判据在这一步定, 不在事后定。
- 假设——提出两到三种可能的方法裁剪版本, 各自标注适用前提。
- 验证——在真实任务上试跑, 且由未参与提取的人执行——这是检验方法是否真的可传递的唯一方式。
- 沉淀——把成型的版本、被否决的版本及理由写入记录层, 并交接维护责任人。
输出案例
★ 以下为度量看板的格式示意, 数值为构造。
协作方法度量 · 第 6 周 · 团队 A (7 人)
指标 基线 (导入前两周) 本周 说明 返工率 记录不足, 无基线 可测量 ★ 基线缺失本身是发现: 导入前团队没有记录返工 判据缺席率 — 下降 检查表使这一项变得可见 沉淀复用次数 0 出现非零 第一次出现上一轮记录被下一轮引用 可接手性 未测 首次测量 由未参与者复述判断链条 本周观察: 判据缺席主要集中在紧急任务上——压力下最先被跳过的正是判据。这与方法本身的设计预期一致, 需要在流程上给紧急路径单独设计最简判据, 而不是要求人"更自律"。
迭代计划
阶段一 · 基线: 在不改变做法的前提下先测两周。★ 没有基线的改进无法被证明, 而基线只能在改变之前取得——错过就永远补不回来。
阶段二 · 单点导入: 只在一类任务上导入完整五步。判据: 该类任务的返工率与判据缺席率出现可观察的变化。
阶段三 · 可传递性: 由未参与提取的成员独立执行。判据: 可接手性指标; 若不可传递, 说明提取的是技巧而非判据, 退回阶段二。
阶段四 · 固化与移交: 稳定环节固化为 Agent, 维护责任移交团队内部。★ 移交完成的标志是我们退出后一个季度指标不回落。