共享状态减少询问成本
别名: 状态可见 · 工作状态 · status awareness
概念解释
共享工作状态（shared work status）让依赖者能看到任务处于何阶段、由谁处理、下一步和阻塞是什么，而不必逐个私聊询问。它减少的不是所有沟通，而是为获得基础协调信息而产生的重复打断——同一个问题被问了 N 遍，答案却只有一份。
机制
协作中的不确定性会触发"现在怎么样了"的私聊。每一次询问都要打断正在执行的人，而且只让提问的这一个人获知答案，同样的问题会在其他依赖者身上重演。这背后是建立共同基础（grounding）本身的成本：两个人要就一件事达成共同理解，需要一轮问答完成"接地"，而私聊式沟通把这轮成本摊派给每一对"执行者—依赖者"关系，人越多摊派次数越多。把状态附着在工作对象本身而不是某次对话上，相当于把接地过程从逐对进行改成一次广播——所有依赖者读同一份状态，各自完成接地，不需要执行者重复解释。
但这个机制只在状态本身足够具体到能直接支持行动判断时才成立，这是它最容易被误用的地方：如果状态只是一个笼统标签（"进行中"），依赖者读到它之后仍然不知道该等、该催还是该接手，于是状态反而制造了新的追问——"进行中具体是什么意思，卡住了吗"。真正省掉询问的是状态与下一步动作和更新时间绑定：一条"等待对方评审，已提交两天"比"进行中"多出的两个字段，正是把接地成本从"要不要问"降到"看一眼就够"的关键差异。
共享状态减少询问的收益也不是均匀的，而是与依赖者数量成正比：只有一个依赖者时，公开状态和私下告知一次的成本几乎相等，建看板、加字段的额外工程投入未必划算；依赖者越多，同一次更新省下的重复解释就越多，这是它在多人协作、多团队下游的场景里价值最大的原因。
怎么研究
- 范式：对比有无对象级状态时的询问频率、打断次数和依赖等待时长；可用工作区意识（workspace awareness）研究里常用的日志加访谈组合——先从系统日志统计私聊追问的对象与时间点，再回访问这些追问原本能否被已展示的状态回答。
- 接地成本操纵：控制状态字段的具体程度（笼统标签 vs. 绑定下一步动作和时间戳的字段），测参与者读到状态后是否还会追问，用来判断某类状态设计是否真的完成了接地，还是只是把追问推迟了一步。
- 变量：状态可见性、状态更新时间、状态具体程度、依赖者数量、追问量、等待时长、计划变更次数。
- 方法论注意点：追问消息减少也可能是依赖者放弃追问而不是被状态说服，需要额外检查他们对结果的预期是否仍然正确——只统计消息量会把"死心"和"被回答"混为一谈。
边界
这条经验规律在依赖者分散、彼此不共处一室、只能通过异步渠道获取信息的团队里效果最明显；在物理同处一室、频繁同步交流的小团队里，谁在做什么本来就靠环境线索和随口一句话自然传播，额外搭建状态看板的边际收益很低，投入产出比往往不划算——这也是为什么状态看板类工具在分布式和跨时区团队里的采用率明显高于同城小团队。
状态类别的数量也是一条分界。当状态字段被设计成少数几个、每个都对应明确的下一步含义时，广播式接地能够成立；一旦为了追求精确而把状态拆成几十种细粒度子状态，读状态本身变成一次需要解释的认知负担，接地成本从"要不要私聊"转移成了"这个状态到底什么意思"，收益被侵蚀。
高频微小变化和探索性工作也不适合完全公开：变化太快时，状态永远落后于当下，公开等于持续制造噪声；探索阶段本身没有稳定阶段可归类，强行填入固定状态字段反而是失真的信息。敏感个人状态则涉及另一层——公开粒度过细会变成监控，这不是接地成本问题，而是隐私边界问题，两者不应该用同一套论证处理。
怎么落地
- 按任务显示负责人、当前阶段、下一步动作、阻塞原因和上次确认时间——缺任一项都可能让状态退化成笼统标签，达不到省询问的效果。
- 让状态更新嵌入提交、审批或交接这类本来就要做的动作里，不要求执行者额外去填一张独立报表。
- 给依赖者订阅变化的能力，而不是要求他们主动刷新页面或反复回来查看。
- 状态类别控制在个位数以内，每个类别都能直接回答"我现在该等、该催还是该接手"。
- 验证办法：统计重复状态询问、依赖等待时长和因状态误判导致的计划变更是否下降，并抽样让使用者解释自己刚才据此作出的决定——如果解释和状态字段对不上，说明状态没有真正被用来做判断。