项目

人机协作工作流的落地

把方法装进一个真实团队, 并且能测出它是否起作用

在一个真实工作团队里导入人机共创方法, 并建立度量, 使「有没有用」成为可回答的问题而不是主观印象。

人机协作工作流落地项目的结构: 左侧是观察到沉淀的五步方法循环, 右侧是并行的度量轴, 列出返工率、判据缺席率、沉淀复用次数与可接手性四项指标, 两者以虚线相连, 表示度量与方法同时上线。

背景

常见的失败路径

我们观察到方法导入通常这样失败:

  • 培训完就结束。讲了两小时, 没有进入日常工作, 三周后回到原样。
  • 只有热情的人在用。方法变成少数人的偏好, 而不是团队的做法; 一旦这些人换岗, 全部归零。
  • 无法判断是否有效。团队觉得"好像顺一些", 但说不出哪里顺; 于是遇到压力时最先被放弃。

★ 第三条是根源。没有度量的改变无法被守住——因为它在争夺资源时提不出证据。

设计思路

从观察实际工作开始, 而不是访谈

请团队里用得好的人实际做一遍, 我们在旁记录。多数关键动作他自己不会主动提及, 因为它们已经变成习惯。

提取判据, 而不是提取技巧

技巧无法迁移, 判据可以。我们要拿到的是"他凭什么认为这个产出可以用"。

度量与方法同时上线

★ 我们不接受"先用起来, 以后再看效果"。度量在第一天就要存在, 否则三个月后没有基线可比。

委托与保留

委托: 记录的收集、判据检查表的执行、评测数据的汇总。 保留: 判据本身的制定与修订、以及是否继续采用的决定。

系统架构

本项目的"架构"主要是流程与度量, 而非软件系统。

一、方法层

基于人机共创框架裁剪出该团队的版本: 保留五步骨架, 步骤内容按其实际工作替换。

二、检查表层

每一步落成可勾选的完成判据。检查表刻意做短——超过五项就没人填。

三、记录层

判据、否决理由、失败案例的存放位置与格式。与知识资产项目共用同一套结构, 使沉淀可被检索。

四、度量层

四个指标, 全部可从记录中直接得到:

  • 返工率——产出被推翻重做的比例
  • 判据缺席率——多少次协作在动手前没有写下判据
  • 沉淀复用次数——上一轮的记录被下一轮实际引用的次数
  • 可接手性——由未参与者复述判断链条的成功率

五、固化层

其中被证明稳定且重复的环节, 按Agent 设计方法固化为 Agent。★ 固化必须在方法稳定之后, 顺序反了会把错误的做法凝固下来。

Agent 流程

导入过程本身按五步组织:

  1. 观察——记录团队当前的实际做法, 不做评判。
  2. 理解——与团队一起明确: 现在最大的痛点是什么, 什么样的改变算成功。★ 判据在这一步定, 不在事后定。
  3. 假设——提出两到三种可能的方法裁剪版本, 各自标注适用前提。
  4. 验证——在真实任务上试跑, 且由未参与提取的人执行——这是检验方法是否真的可传递的唯一方式。
  5. 沉淀——把成型的版本、被否决的版本及理由写入记录层, 并交接维护责任人。

输出案例

★ 以下为度量看板的格式示意, 数值为构造。

协作方法度量 · 第 6 周 · 团队 A (7 人)

指标基线 (导入前两周)本周说明
返工率记录不足, 无基线可测量★ 基线缺失本身是发现: 导入前团队没有记录返工
判据缺席率—下降检查表使这一项变得可见
沉淀复用次数0出现非零第一次出现上一轮记录被下一轮引用
可接手性未测首次测量由未参与者复述判断链条

本周观察: 判据缺席主要集中在紧急任务上——压力下最先被跳过的正是判据。这与方法本身的设计预期一致, 需要在流程上给紧急路径单独设计最简判据, 而不是要求人"更自律"。

迭代计划

阶段一 · 基线: 在不改变做法的前提下先测两周。★ 没有基线的改进无法被证明, 而基线只能在改变之前取得——错过就永远补不回来。

阶段二 · 单点导入: 只在一类任务上导入完整五步。判据: 该类任务的返工率与判据缺席率出现可观察的变化。

阶段三 · 可传递性: 由未参与提取的成员独立执行。判据: 可接手性指标; 若不可传递, 说明提取的是技巧而非判据, 退回阶段二。

阶段四 · 固化与移交: 稳定环节固化为 Agent, 维护责任移交团队内部。★ 移交完成的标志是我们退出后一个季度指标不回落。