任务看板要同时展示负责人和阻塞原因，关键做法是把两类信息拆成独立字段：负责人用人员字段承载，阻塞原因用专门的阻塞标记字段承载，并在卡片固定位置显示。这样既能一眼看到谁负责、卡在哪里，也能按负责人或阻塞状态筛选、汇总。下面按字段设计、卡片排布、填写规则、示例和验收检查五步展开，适用于使用看板管理研发或交付任务的团队。
要点总览（TL;DR）
- 负责人和阻塞原因要拆成两个独立字段：负责人用人员字段承载，阻塞原因用“是否阻塞＋原因分类＋补充说明”的结构承载，避免写进标题或备注导致无法筛选。
- 卡片上负责人放在顶部固定位置，用头像加姓名显示；阻塞标记用醒目图标加“阻塞·原因分类”显示，未阻塞时不出现，控制卡片信息密度。
- 阻塞原因由任务负责人在发现阻塞时立即填写，看板主持人在站会或巡检时复核，解除时及时改回并保留历史记录，长期未解除的阻塞按约定时限升级。
- 落地是否到位可按检查清单核对：字段独立可筛选、卡片两类信息可见、有人负责更新、阻塞数据能按原因分类汇总复盘。
- ONES 中可把上述结构对应到工作项自定义字段并在看板视图设为卡片显示项，具体字段类型与筛选配置需按团队实际使用的 ONES 核验。
先定字段：负责人和阻塞原因各自怎么承载
负责人和阻塞原因混在同一个字段里，看板就会失去筛选能力。常见错误是把“等接口联调，张三跟进”写进任务标题或备注，结果卡片上既看不出谁负责，也无法统计哪类阻塞最多。正确做法是让两类信息各有独立字段，各自承担不同职责。
负责人字段承载“这件事归谁推进”。团队需要先约定单人负责还是多人协作：如果任务只有一个主责人，用单人人员字段，避免出现两个人都以为对方在推进；如果确实需要多人参与，可以设一个“主责人”必填字段加一个“协作人”选填字段，看板卡片默认显示主责人。无论哪种方式，主责人必须唯一。
阻塞原因字段承载“为什么卡住、卡了多久”。建议拆成三个子项：是否阻塞（布尔值或枚举值）、原因分类（如等待外部依赖、资源不足、需求不明确、技术方案待定、审批未完成）、补充说明（自由文本）。原因分类用于筛选和汇总，补充说明承载个案细节，两者分工明确，避免把所有信息都塞进一段文字。
阻塞原因与任务标题、备注、标签的区别在于用途：标题描述任务本身要做什么，备注记录过程信息，标签用于跨任务的轻量分类，而阻塞字段是结构化状态，能被筛选、计数和追踪时长。把阻塞写进标签虽然能筛选，但缺少“是否已解除”的状态和补充说明，长期使用容易失真。
必填与选填的约定建议如下：负责人必填，任务进入看板前就要有主责人；是否阻塞必填，默认值为“否”；原因分类在标记为阻塞时必填；补充说明在标记为阻塞时建议填写，解除时保留历史记录。填写人方面，负责人字段由创建人或看板主持人指定，阻塞字段由任务负责人填写。
| 字段名 | 类型 | 取值 | 必填性 | 填写人 |
|---|---|---|---|---|
| 主责人 | 人员（单选） | 团队成员之一 | 必填 | 创建人或看板主持人 |
| 协作人 | 人员（多选） | 团队成员，可多个 | 选填 | 主责人 |
| 是否阻塞 | 布尔/枚举 | 是 / 否，默认否 | 必填 | 主责人 |
| 阻塞原因分类 | 单选枚举 | 外部依赖、资源不足、需求不明确、技术待定、审批未完成等 | 标记阻塞时必填 | 主责人 |
| 阻塞补充说明 | 多行文本 | 具体卡点、期望解除条件 | 标记阻塞时建议填写 | 主责人或协作人 |
在ONES中落地时，可以把上述结构对应到工作项的自定义字段：人员字段承载主责人，枚举字段承载是否阻塞与原因分类，文本字段承载补充说明。具体字段类型和可选值需要按团队实际使用的ONES配置核验，配置完成后在看板视图中把这些字段设为卡片显示项。
卡片怎么排：让两类信息一眼可见
卡片排布的目标是扫视即识别：看一列卡片时，先看到谁负责，再看到哪些卡住了。建议把负责人放在卡片顶部或标题下方固定位置，用头像加姓名显示；头像便于快速辨认，姓名在成员较多或头像相似时提供确认。如果团队习惯用颜色区分成员，可以用头像边框色或姓名底色做辅助，但颜色只作辅助，不能替代姓名。
阻塞标记要足够醒目但不过度抢占。推荐做法是：未阻塞时卡片不显示阻塞标记，保持界面干净；标记阻塞后，在卡片固定区域出现一个带颜色的标记，例如红色或橙色图标加“阻塞”字样，后面跟原因分类的简短文字，如“阻塞·等待外部依赖”。补充说明不一定要全文显示在卡片上，可以显示前若干字或仅在详情中查看，避免卡片被长文本撑开。
卡片信息密度需要控制。一张卡片通常保留标题、负责人、阻塞标记、截止日期和少量关键标签即可。字段堆得太多，扫视速度反而下降。判断标准是：站在看板前几秒内能否回答“谁在做、有没有卡住、卡在哪类原因”三个问题。如果还需要点开卡片才能知道，说明关键字段没有放到卡片上。
筛选与分组是卡片显示的延伸。按负责人筛选，可以快速查看某个成员的全部任务；按是否阻塞筛选，可以拉出当前所有阻塞项集中处理。分组可以按负责人分组，形成每人一列的负载视图；也可以按阻塞状态分组，把阻塞项集中到一个区域。两种分组方式对应不同场景：日常站会适合按负责人看进展，阻塞清理会适合按阻塞状态集中看。
- 负责人：卡片顶部固定位置，头像加姓名，颜色仅作辅助。
- 阻塞标记：固定区域显示图标加“阻塞”字样和原因分类，未阻塞时不显示。
- 补充说明：卡片显示摘要，完整内容在详情中查看。
- 筛选：至少支持按负责人、按是否阻塞两个维度。
- 分组：按负责人或按阻塞状态，按会议场景切换。
谁来填、何时更新：角色与流转规则
字段设计得再好，没人维护也会失真。阻塞字段的维护需要三类角色配合：任务负责人是阻塞信息的第一责任人，发现任务无法按计划推进时，当场把是否阻塞改为“是”，选择原因分类并写清补充说明和期望解除条件；协作人发现阻塞时可以提醒负责人，也可以在获得授权后补充说明，但不随意改动原因分类；看板主持人在每日站会或看板巡检时逐项复核阻塞标记，确认原因分类是否准确、补充说明是否足够具体，并推动解除。
更新时点可以归纳为三个节点。阻塞发生时立即标记，不要等到站会才补，否则看板在当天大部分时间里显示的是失真的状态。站会时复核，主持人按阻塞筛选拉出全部阻塞项，逐项确认是否仍在阻塞、解除条件是否变化、是否需要升级。解除时及时改回“否”，并在补充说明中记录解除方式和时间，保留历史便于复盘。
原因分类的口径需要团队统一。建议在启用前把分类清单定下来，每类给出定义和例子，例如“外部依赖”指需要其他团队或供应商交付才能继续，“需求不明确”指验收标准或范围尚未确认。分类不宜过多，五到八类通常够用；新增分类要经过看板主持人确认，避免每个人按自己的理解建类，导致汇总时口径不一。
长期未解除的阻塞需要升级路径。可以约定阻塞持续超过若干工作日（例如三个工作日）后，由看板主持人在巡检中升级给项目负责人或相关管理者，升级动作包括在卡片上标注升级状态、在站会上单独提出、明确决策人和决策时限。升级不是追责，而是把卡点交给有权限调动资源的人处理。
| 角色 | 主要职责 | 关键动作 | 时点 |
|---|---|---|---|
| 任务负责人 | 阻塞信息第一责任人 | 标记阻塞、选分类、写说明与解除条件、解除后改回 | 阻塞发生时、解除时 |
| 协作人 | 补充与提醒 | 补充说明、提醒负责人更新 | 发现阻塞时 |
| 看板主持人 | 复核与推动 | 按阻塞筛选逐项复核、推动解除、发起升级 | 每日站会或看板巡检 |
| 项目负责人/管理者 | 处理升级事项 | 协调资源、给出决策和时限 | 阻塞超期升级后 |
示例：一张卡片从阻塞到解除的完整过程
以下为演示情景，用于说明字段填写与卡片变化，不代表真实项目数据。
任务“订单查询接口联调”初始状态：主责人为李雷，是否阻塞为“否”，卡片显示李雷的头像和姓名，无阻塞标记。任务进行到联调阶段时，李雷发现对方团队的测试环境尚未就绪，当天无法继续。他立即把是否阻塞改为“是”，原因分类选择“外部依赖”，补充说明填写“对方测试环境预计周四就绪，需对方负责人确认时间”，期望解除条件写为“测试环境可用并能完成一轮联调”。此时卡片上出现红色“阻塞·外部依赖”标记，负责人仍显示李雷。
次日站会上，主持人按是否阻塞筛选，拉出包括该任务在内的阻塞清单。看到卡片信息后，主持人确认解除条件是否仍然成立，并询问是否需要升级。由于阻塞已持续两天，主持人按约定在第三天将其升级给项目负责人，项目负责人与对方团队沟通后确定了环境就绪时间。整个过程不需要点开每张卡片询问原因，卡片上的分类和说明已经提供了判断依据。
周四环境就绪，李雷完成联调后把是否阻塞改回“否”，原因分类清空或保留为历史记录，补充说明追加“已于周四解除，环境延迟两天”。卡片上的阻塞标记消失，负责人信息不变。复盘时按原因分类统计，可以看到“外部依赖”类阻塞的占比和平均持续时长，为后续排期提供参考。
| 阶段 | 是否阻塞 | 原因分类 | 补充说明 | 卡片显示 |
|---|---|---|---|---|
| 初始 | 否 | 空 | 空 | 李雷头像姓名，无阻塞标记 |
| 阻塞发生 | 是 | 外部依赖 | 对方测试环境预计周四就绪 | 李雷头像姓名，红色“阻塞·外部依赖” |
| 升级 | 是 | 外部依赖 | 追加升级记录与决策人 | 阻塞标记加升级标识 |
| 解除 | 否 | 保留历史 | 追加解除时间与说明 | 阻塞标记消失，负责人不变 |
完成检查：看板是否真的同时呈现了两类信息
落地是否到位，可以按下面的清单逐项核对。每项都对应一个可观察的结果，而不是主观感受。
- 负责人和阻塞原因分别由独立字段承载，阻塞信息没有写进任务标题或备注作为唯一记录。
- 负责人字段必填，且每个任务只有一个主责人；协作人作为选填字段单独存在。
- 阻塞字段包含是否阻塞、原因分类、补充说明三个部分，标记阻塞时分类必填。
- 看板卡片固定显示负责人（头像或姓名）和阻塞标记，未阻塞时卡片不显示阻塞标记。
- 看板支持按负责人筛选，也支持按是否阻塞筛选；分组可按负责人或阻塞状态切换。
- 阻塞原因有明确的填写人和更新时点，站会或巡检中有复核动作。
- 阻塞解除后有改回动作，补充说明保留解除记录。
- 长期未解除的阻塞有升级路径和时限约定。
- 原因分类口径统一，分类清单有定义和例子，新增分类有确认机制。
- 阻塞数据可以按原因分类汇总，用于复盘阻塞分布和持续时长。
核对时如果发现某一项不满足，优先回到字段设计和填写规则两节修正，再检查卡片显示配置。看板的价值在于让信息在扫视中被看见，负责人和阻塞原因各自独立、固定显示、有人维护，这三件事同时成立，看板才算真正把两类信息呈现出来。
常见问题
任务负责人和协作人都能改阻塞字段吗？
建议把阻塞字段的修改权限集中在任务负责人身上，协作人负责补充说明和提醒。原因分类是汇总统计的口径，多人随意改动容易造成同一类问题被归到不同分类。如果团队希望协作人也能直接标记阻塞，需要提前约定：协作人只改“是否阻塞”和补充说明，原因分类由负责人确认后再定。
阻塞原因分类设多少个比较合适？
五到八类通常够用，例如外部依赖、资源不足、需求不明确、技术方案待定、审批未完成。分类太少会把不同问题混在一起，汇总时看不出差异；分类太多则每个人按自己的理解建类，口径难以统一。建议在启用前把分类清单和每类的定义、例子定下来，新增分类经过看板主持人确认。
阻塞解除后，原因分类和补充说明要清空吗？
建议保留历史记录，把“是否阻塞”改回“否”，原因分类和补充说明保留或归档。清空后，复盘时无法统计哪类阻塞出现最多、平均持续多久。保留记录还能让接手的人了解任务曾经卡在哪里、当时是怎么解决的。如果工具支持状态历史，也可以依赖变更记录，但卡片上的补充说明仍建议追加解除时间和方式。
站会上按阻塞筛选拉出清单后，主持人应该确认什么？
逐项确认三件事：阻塞是否仍然存在、解除条件是否发生变化、是否需要升级。如果卡片上的补充说明已经写清卡点和期望解除条件，主持人可以直接据此判断，不必逐张点开询问。对于已持续多日的阻塞，按约定时限发起升级，明确决策人和决策时限，把卡点交给有权限调动资源的人处理。
团队规模较小，还需要单独设阻塞字段吗？
仍然建议单独设字段。人数少时口头沟通更快，但看板的价值在于让状态在卡片上可见，而不是依赖记忆和询问。哪怕只有几个人，把阻塞写进标题或备注也会让筛选和统计失效。小团队可以简化分类数量，例如先设三到四类，保留“是否阻塞＋原因分类＋补充说明”的基本结构即可。
