任务列表视图的设计顺序是：先明确这张列表要回答谁的问题，再选列字段并排优先级，然后确定分组、排序与筛选口径，接着配置行内操作与批量动作，最后用真实数据试跑，检查可读性、可维护性和权限边界。本文按这六步展开，并给出一份可直接套用的研发迭代示例和上线前检查清单。
要点总览（TL;DR）
- 设计顺序是用途先行：先定使用者角色和要回答的1–3个问题，再选列字段、定分组排序筛选、配置行内操作，最后用真实数据试跑检查。
- 字段按必选列、条件列、舍弃列三层取舍：标识、标题、状态、负责人、截止时间进必选列，长文本和附件放详情。
- 分组维度不超过两层，共享视图用字段排序保证一致，个人视图允许手动调整；默认筛选固化常用范围，避免每次重新找。
- 行内操作只放改动频繁、取值简单、误改代价低的字段，批量修改要有条数确认和失败反馈。
- 视图需要明确设计负责人、口径维护人和清理周期，上线前逐项核对用途、字段、口径、排序、操作、权限与维护。
先定用途：这张列表回答谁的什么问题
列表视图最常见的失败，是从“把所有字段都放上去”开始。字段越多，扫读成本越高，使用者越难在几秒内找到自己关心的那一行。设计的第一步应当是把列表还原成一个具体的使用任务：谁在什么频率下打开它，想解决什么问题。
识别主要使用者角色时，可以从四类人入手：执行人关心“我今天要做什么”，负责人关心“这个迭代整体推进到哪了”，项目经理关心“哪些事项有延期风险”，跨部门协作者关心“我提的需求处理到哪一步”。同一批工作项，这四类人打开列表时的问题完全不同。
让每个角色写出打开列表时要回答的1–3个问题，再按高频、低频区分。高频问题决定列表的主任务，低频问题可以通过筛选或进详情解决，不必占用默认列。需要强调的是，同一工作项可以配置多个列表视图，各自服务不同问题，不需要用一张列表满足所有人。
这一步的产出是一张用途说明表，作为后续字段取舍的依据：
| 角色 | 要回答的问题 | 使用频率 | 对应列表视图名称 |
|---|---|---|---|
| 执行人 | 我本周有哪些任务、哪些快到期 | 每天多次 | 我的待办 |
| 负责人 | 本迭代各状态分布如何、谁的任务积压 | 每天一次 | 迭代任务总览 |
| 项目经理 | 哪些任务临近截止仍未完成 | 每周两三次 | 延期风险清单 |
| 跨部门协作者 | 我提交的需求当前处理到哪一步 | 每周一次 | 需求跟进 |
列字段怎么选：必选列、条件列与舍弃列
字段取舍可以按三层判断：必选列、条件列、舍弃列。必选列是支撑扫读的基础字段，包括工作项标识、标题、状态、负责人、截止时间。这几列让使用者在不点开任何一条记录的情况下，判断“这是什么、谁在做、做到哪了、什么时候要”。
条件列按角色或阶段出现，例如优先级、所属迭代、所属模块、工时。它们对某些视图是刚需，对另一些视图是噪音。判断标准是：这个字段是否直接影响该视图使用者做下一步决定。负责人视图需要优先级来判断先做哪条，执行人的个人待办则未必需要迭代字段。
舍弃列指不适合横向铺开的内容：长文本描述、附件、评论记录。这些信息放进详情页，列表只保留一个可点击的标题入口。把它们塞进列里，会挤压其他字段的宽度，也会让行高失控。
列的可读性同样需要处理。列宽按内容长度分配，标题列最宽，状态、优先级等枚举字段收窄；列顺序按阅读路径排列，通常是标识、标题在前，状态、负责人在中，时间类字段在后；字段显示名使用团队统一的业务叫法，避免同一字段在不同视图里叫法不一。
字段口径统一是容易被忽略的一条：状态、优先级等字段的取值集合在所有视图中保持一致。如果一张视图用“进行中”，另一张用“处理中”，跨视图对比就会失真。这一步的产出是字段清单表：
| 字段名 | 类型 | 是否入列 | 入列理由 | 显示顺序 |
|---|---|---|---|---|
| 工作项标识 | 系统编号 | 是 | 便于口头和文档中引用 | 1 |
| 标题 | 短文本 | 是 | 识别工作项内容 | 2 |
| 状态 | 枚举 | 是 | 判断推进阶段 | 3 |
| 负责人 | 人员 | 是 | 明确责任归属 | 4 |
| 优先级 | 枚举 | 条件 | 负责人视图需要，个人待办可省 | 5 |
| 截止时间 | 日期 | 是 | 判断时间压力 | 6 |
| 所属模块 | 枚举 | 条件 | 按模块分工的团队需要 | 7 |
| 描述 | 长文本 | 否 | 进详情查看 | — |
| 附件 | 文件 | 否 | 进详情查看 | — |
分组、排序与筛选：让列表有稳定的阅读顺序
字段决定“看到什么”，分组和排序决定“按什么顺序看”，筛选决定“看多大范围”。三者配合，才能让使用者每次打开列表都不用重新找位置。
常用分组维度有状态、负责人、优先级、迭代或模块。选择依据仍然是视图用途：迭代总览按状态分组，能一眼看出各阶段积压；负责人视图按负责人分组，便于分配和平衡负载；模块视图按模块分组，适合按业务域推进的团队。分组维度不宜超过两层，层级过深会让列表变成折叠迷宫。
排序规则要区分默认排序与手动排序。默认排序按截止时间、优先级等字段自动排列，优点是稳定可预期，缺点是使用者无法按自己的习惯调整。手动排序适合需要人为排优先级的场景，但每次新增工作项都可能打乱既有顺序。多数团队的做法是：共享视图用字段排序保证一致性，个人视图允许手动调整。
筛选口径要明确默认筛选和可切换筛选。“我的任务”“本迭代”“未完成”这类常用范围应固化为默认筛选，使用者打开即见；临时性的范围调整通过可切换筛选完成，不修改视图本身。共享视图与个人视图分开管理：共享视图的筛选规则由视图负责人维护，个人视图由使用者自行调整，避免个人改动影响团队口径。
空结果和超长列表需要提前处理。空结果时给出提示，说明当前筛选条件下没有匹配项，并提示可放宽的条件；超长列表通过分页或分批加载控制单屏信息量，同时保证排序稳定，避免翻页时顺序跳动。这一步的产出是视图规则说明：
| 视图名称 | 分组维度 | 排序规则 | 默认筛选 | 共享范围 |
|---|---|---|---|---|
| 我的待办 | 按截止时间 | 截止时间升序 | 负责人=当前用户，状态≠已完成 | 个人 |
| 迭代任务总览 | 按状态 | 优先级降序 | 迭代=当前迭代 | 团队共享 |
| 延期风险清单 | 按负责人 | 截止时间升序 | 截止时间<今天，状态≠已完成 | 团队共享 |
行内操作与批量动作：列表不只是看，还要能改
列表如果只能看不能改，使用者就要为改一个状态反复进出详情页，操作成本会迅速累积。行内操作的设计原则是：改动频繁、取值简单、误改代价低的字段，允许在行内直接修改。
典型行内动作包括状态流转、负责人变更、截止时间调整。这三类字段取值简单，修改后立即反映在列表上，适合行内完成。优先级调整也常放在行内，但需要确认它是否会影响其他视图的排序结果，避免使用者改完后列表顺序突然变化而困惑。
批量选择与批量修改适合周期性整理场景，例如迭代结束时批量关闭已完成任务、批量调整负责人。批量操作的风险在于一次影响多条记录，因此需要确认提示，明确显示将修改的记录数量和字段新值；执行后给出成功与失败的数量反馈，失败项保留原值并说明原因。
有些操作必须进详情完成：修改长描述、上传附件、填写评审记录、补充验收说明。这些内容在行内编辑会破坏列表的扫读节奏，也不利于完整填写。判断标准是：操作需要较多输入或需要上下文时，进详情；操作是单值切换时，留在行内。
操作后的反馈同样属于设计内容。保存成功给出轻量提示，保存失败说明失败字段和原因，列表在操作后按当前排序规则刷新，而不是跳回顶部。这一步的产出是操作清单：
| 动作 | 位置 | 触发条件 | 风险控制 |
|---|---|---|---|
| 修改状态 | 行内 | 有状态流转权限 | 按状态机允许的流转路径提供选项 |
| 变更负责人 | 行内 | 有分配权限 | 提示新负责人当前负载 |
| 调整截止时间 | 行内 | 有编辑权限 | 修改后即时刷新排序 |
| 批量关闭 | 批量 | 选中多条且状态允许 | 二次确认，显示影响条数 |
| 编辑描述与附件 | 详情 | 打开工作项 | 保存前校验必填项 |
角色分工与交付物：谁定规则、谁维护视图
视图设计不是一次性工作。没有明确责任人的团队，视图会越建越多，字段口径逐渐分叉，最后没人说得清哪张列表是准的。因此需要把设计、维护和使用三类责任分开。
视图设计负责人负责收集使用问题、定义字段与规则，通常由团队里最熟悉工作流的人担任，例如项目经理或技术负责人。字段与状态口径的维护责任人也应由同一人或明确指定的人承担，负责在流程变化时同步更新取值集合和视图规则。团队使用者按约定使用共享视图，个人视图自行管理，不随意修改共享视图的筛选和分组。视图评审与定期清理可以按迭代或季度进行，合并重复视图、下线无人使用的视图。
在工具层面，ONES 的工作项视图支持配置显示字段、分组与筛选条件，并可将视图保存为共享或个人视图，这与上述“共享视图定口径、个人视图留弹性”的分工方式相对应。具体可配置的字段类型和权限范围，以团队实际使用的版本为准。
| 角色 | 职责 | 交付物 | 检查时点 |
|---|---|---|---|
| 视图设计负责人 | 收集问题、定义字段与规则 | 用途说明表、字段清单、视图规则说明 | 视图上线前 |
| 口径维护责任人 | 维护状态、优先级等字段取值 | 字段口径说明 | 流程变更时 |
| 团队使用者 | 按约定使用共享视图 | 使用反馈 | 日常使用中 |
| 视图评审人 | 定期清理与合并视图 | 视图清理记录 | 每迭代或每季度 |
一个完整示例：研发迭代任务列表
以下示例为演示性质，用于说明设计过程，不代表真实项目数据。场景设定为一个两周迭代内的研发任务跟踪，团队约十人，按模块分工。
用途与角色：执行人需要一张“我的待办”，回答“我今天做什么、哪些快到期”；负责人需要一张“迭代任务总览”，回答“各状态分布如何、谁的任务积压”。两张视图共用同一批工作项，但字段和筛选不同。
字段与顺序：标题、状态、负责人、优先级、截止时间、所属模块。标识列保留在最前，便于站会时口头引用；描述和附件不进列，进详情查看。
分组与筛选：迭代任务总览按状态分组，默认筛选“迭代=当前迭代”，排序按优先级降序、截止时间升序；我的待办按截止时间排序，默认筛选“负责人=当前用户、状态≠已完成”。两张视图分别保存为团队共享和个人视图。
行内操作：状态、负责人、截止时间允许行内修改；批量关闭在迭代收尾时使用，执行前显示将影响的条数并要求确认。描述补充和验收说明进详情完成。
取舍说明：这张示例没有把工时和故事点放进默认列，因为团队在迭代内主要按任务粒度推进，工时数据在复盘时另行统计。可迁移的规律是：默认列只保留支撑当前视图主任务的字段，其余字段通过条件列或详情承载；共享视图固定筛选口径，个人视图保留排序弹性。
上线前的完成检查
视图配置完成后，用真实数据试跑一轮，再逐项核对以下检查项。每一项标注通过或待改，待改项明确责任人和修改时点。
- 用途检查：每个视图能对应到明确角色和1–3个问题，没有“什么都放”的万能视图。
- 字段检查：必选列齐全，标题列宽度足够，没有长文本或附件列占用横向空间。
- 口径检查：状态、优先级等字段取值在所有视图中一致，显示名统一。
- 排序检查：默认排序稳定，新增工作项后列表顺序不出现意外跳动。
- 操作检查：行内动作有保存反馈，批量修改有二次确认和失败提示。
- 权限检查：共享视图与个人视图范围清晰，使用者只能修改自己有权限的字段。
- 维护检查：明确视图评审周期和清理责任人，重复视图有合并计划。
全部检查项通过，并且用真实数据试跑后使用者能在几秒内定位到自己关心的行，这张列表视图才算达到可用状态。后续流程变化时，回到字段清单和视图规则说明同步更新，比直接在界面上零散调整更容易保持口径一致。
常见问题
团队已经有默认的任务列表，还需要再建多个视图吗？
需要看使用问题是否已经被覆盖。如果执行人、负责人和项目经理打开同一张列表时，关心的是不同问题，一张列表很难同时满足：字段堆多了扫读变慢，字段少了又不够用。这时可以按角色拆出2–3张视图，例如个人待办、迭代总览和风险清单，共用同一批工作项，各自配置字段与筛选。
拆分的判断标准是问题是否高频且稳定。偶发的查看需求用临时筛选解决，不必单独建视图，否则视图数量增长后反而增加维护负担。
共享视图和个人视图应该怎么划分边界？
共享视图承载团队统一口径，字段、分组和默认筛选由视图负责人维护，使用者按约定使用，不随意改动；个人视图留给使用者按自己的习惯调整排序和临时筛选。
划分时可以把“本迭代”“未完成”这类团队共识范围放进共享视图的默认筛选，把“只看我负责的”“按截止时间排”这类个人偏好放进个人视图。这样团队对比数据时口径一致，个人日常使用又保留弹性。
批量修改任务时怎么避免误操作？
批量操作的风险来自一次影响多条记录，控制手段主要有三点：执行前显示将修改的记录数量和字段新值，要求二次确认；执行后反馈成功与失败的数量，失败项保留原值并说明原因；对状态流转这类有路径限制的字段，只提供当前状态允许的批量选项。
批量修改适合周期性整理场景，例如迭代收尾时批量关闭已完成任务。日常的单条调整留在行内完成，减少批量入口被误用的机会。
列表视图上线后，什么时候需要重新调整？
常见触发点有三类：流程变化导致状态或字段取值调整；使用者反馈找不到关键信息或默认排序不符合实际阅读习惯；视图数量增长后出现重复或长期无人使用的列表。
调整时回到字段清单和视图规则说明同步更新，比直接在界面上零散改动更容易保持口径一致。可以按迭代或季度安排一次视图评审，合并重复视图、下线无人使用的视图，并确认共享视图的筛选规则仍然有效。
列表里放不下所有信息，哪些内容应该进详情？
判断标准是内容是否需要较多输入或上下文。长文本描述、附件、评论记录、评审和验收说明适合放进详情页，列表只保留可点击的标题入口；状态、负责人、截止时间、优先级这类单值字段可以留在列中甚至行内修改。
把长内容塞进列会挤压其他字段宽度、抬高行高，破坏扫读节奏。列表的目标是让人快速定位到那一行，完整信息在详情里查看和填写。
