任务视图筛选做得好不好，关键不在条件设得多细，而在每个视图是否对应一个明确的角色和决策。本文按“先定用途、再拆条件、统一口径、落实维护”的顺序，给出可直接照填的视图需求清单、筛选条件三层表、字段取值规范表、责任表和上线检查清单，帮助团队把随手点选的筛选固化成可复用的共享视图。
要点总览（TL;DR）
- 任务视图筛选先定用途：每个视图对应一个角色和一个具体动作，用途写不出来就不建。
- 筛选条件拆成固定范围、可变条件、排序与显示三层，与/或关系必须写明，避免同一视图结果对不上。
- 字段口径要统一：日期写清截止还是创建、是否含当天；人员区分负责人与参与人；状态用集合并说明是否含已完成。
- 共享视图需要创建人、确认人、维护人和检查频率，命名采用“范围+条件+用途”结构，避免越建越乱。
- 上线前用已知任务验证结果，并按检查频率回看条件是否失效。
先定视图要回答的问题
筛选条件是从用途推导出来的。同一个项目里，开发成员关心“今天该做什么”，测试负责人关心“哪些任务卡在待评审”，项目经理关心“本周哪些任务到期”。如果先打开筛选器逐项勾选，很容易做出几个条件相似、结果重叠的视图，用一段时间后没人说得清哪个该看。
建议先按角色和场景列需求，每个视图只写一句用途说明。用途说明要能落到一个具体动作，例如“用于每日站会前确认本人当天要推进的任务”，而不是“用于查看任务”。用途写不出来，说明这个视图暂时不需要建。
常见的视图需求可以这样起步：
- 我的待办：成员每天开始工作时确认本人名下未完成的任务。
- 本周到期：项目负责人检查本周内到期任务的推进状态，提前发现风险。
- 待评审：评审人集中处理等待评审的任务，避免评审环节积压。
- 阻塞项：团队负责人识别被阻塞的任务，协调资源或调整计划。
个人视图与团队共享视图要分开管理。个人视图服务于个人工作节奏，条件可以随个人习惯调整，不需要团队确认；共享视图会被多人引用，条件口径一旦变化会影响所有人的判断，因此需要团队负责人确认后才能发布。判断标准很简单：这个视图的结果会不会在会议、评审或汇报中被引用，会，就按共享视图管理。
本节的产物是一份视图需求清单，至少包含三列：视图名称、使用角色、要回答的问题。清单确认后再进入条件设计，可以避免后面反复改条件。
把筛选条件拆成三层
可维护的筛选配置有稳定的结构。把条件拆成固定范围、可变条件、排序与显示三层，接手的人能快速看懂这个视图在什么范围内、按什么条件取数、以什么顺序呈现。
| 层级 | 作用 | 常见字段 | 写法要求 |
|---|---|---|---|
| 第一层：固定范围 | 限定视图取数的边界，通常长期不变 | 项目、工作项类型、状态集合 | 范围尽量收窄到必要的最小集合，状态用集合表达 |
| 第二层：可变条件 | 表达这个视图真正关心的筛选逻辑 | 负责人、优先级、截止日期、标签、迭代 | 每个条件写清字段、取值和与/或关系 |
| 第三层：排序与显示 | 决定结果的呈现顺序和信息密度 | 排序字段、显示列、分组方式 | 排序字段与视图用途一致，显示列只保留决策需要的 |
固定范围层决定视图的“底盘”。例如一个迭代内的任务视图，范围应限定在该迭代对应的项目和工作项类型上，状态集合覆盖从待处理到已完成的全过程，再由第二层条件筛出当前需要关注的部分。范围层如果放得太宽，后面每加一个条件都要额外排除无关数据，条件会越写越复杂。
可变条件层是视图之间差异的主要来源。写条件时要明确条件之间是“同时满足”还是“满足其一”。例如“负责人是本人”与“截止日期在本周内”通常是同时满足；“优先级为高”或“标签为阻塞”则可能是满足其一。与/或关系不写清楚，不同的人配置出来的结果会不一致，这也是同一视图在不同成员那里结果对不上的常见原因。
排序与显示层经常被忽略，但它直接影响视图能不能用。按截止日期升序排列的视图适合排查到期风险，按优先级排列的视图适合安排处理顺序。显示列只保留做判断需要的字段，列太多会让视图退化成一张需要逐行阅读的表格。分组方式也要与用途匹配，例如按负责人分组便于分工确认，按状态分组便于发现积压环节。
本节的产物是筛选条件三层表，每个视图占一行，分别填写范围层、条件层、显示层的具体配置。这张表既是配置依据，也是交接文档。
字段与取值怎么写才不产生歧义
筛选结果不准，多数时候不是条件设错，而是字段和取值的口径没有统一。同名字段在不同人理解里含义不同，配置出来的视图自然对不上。下面几类字段需要特别写清楚。
| 字段类别 | 需要写清的内容 | 取值示例 | 注意事项 |
|---|---|---|---|
| 日期类 | 用的是截止日期还是创建日期，是否包含当天 | 截止日期 ≤ 本周日（含当天） | “本周到期”要说明周起止口径，跨时区团队还需统一时区 |
| 人员类 | 区分负责人、参与人、创建人 | 负责人 = 当前用户 | “我的任务”默认指负责人，若含参与人需在视图说明中注明 |
| 状态类 | 用状态集合，说明是否含已完成 | 状态 ∈ {待处理, 进行中, 待评审} | 只写单个状态会漏掉流转中的任务，是否含已完成要显式说明 |
| 标签与自定义字段 | 统一命名规范，避免同义多值 | 标签统一为“阻塞”，不混用“被阻塞”“卡住” | 标签值需要有人负责清理，否则会持续膨胀 |
日期类条件的歧义最隐蔽。“本周到期”如果没有说明是否含当天，周一早上看到的结果可能比周五少一天。涉及截止日期的视图，建议在视图说明里直接写出完整口径，例如“截止日期在本周一至周日之间，含周日”。
人员类条件要先确认视图服务的是谁的工作。以负责人为条件适合个人待办；以参与人为条件适合协作场景，但结果会包含大量只需要知会的任务，容易稀释重点。创建人条件一般用于追溯，不适合作为日常待办视图的主条件。
状态类条件建议用集合表达。一个“待处理任务”视图如果只筛“待处理”一个状态，进行中的任务就不会出现，而实际工作中成员更关心的是所有未完成的任务。是否包含已完成状态要在视图说明中写明，避免有人以为视图漏了数据。
标签和自定义字段的问题在于值会不断新增。需要约定命名规范，例如统一用词、统一大小写、避免近义词，并指定一个人定期合并重复值。规范确定后写入字段取值规范表，作为新建视图时的参照。
角色分工与视图维护
视图越建越乱，通常是因为没有人对视图负责。共享视图从创建到退役需要四类角色：创建人负责初始条件和命名，团队负责人确认共享视图的口径，维护人定期检查条件是否仍然有效，成员在使用中发现问题时提出修改。
| 视图名称 | 创建人 | 确认人 | 维护人 | 检查频率 |
|---|---|---|---|---|
| 我的待办 | 成员本人 | 无需确认 | 成员本人 | 按需调整 |
| 本周到期 | 项目负责人 | 团队负责人 | 项目负责人 | 每两周 |
| 待评审 | 测试负责人 | 团队负责人 | 测试负责人 | 每月 |
| 阻塞项 | 团队负责人 | 团队负责人 | 指定轮值成员 | 每月 |
命名要统一。建议采用“范围 + 条件 + 用途”的结构，例如“迭代内·未完成·每日待办”，让成员在视图列表里一眼看出差异。命名重复或含义相近的视图应当合并，合并前先确认原视图是否仍被引用。
检查频率与视图的时效性相关。依赖迭代、日期等会变化条件的视图，检查频率要高一些；条件稳定的视图可以按季度检查。检查时重点看三件事：条件字段是否仍然存在、取值是否仍然有效、结果是否还符合用途说明。字段被重命名、状态被调整、标签被合并，都会让旧视图悄悄失效，而界面上往往不会报错。
成员反馈渠道要简单可用。可以在团队例会上固定留出反馈时间，也可以指定维护人为接收人。反馈时要求说明“哪个视图、什么条件下结果不对、期望看到什么”，维护人据此判断是修改条件还是调整用途说明。
视图固化和共享时，工具本身的支持程度会影响维护成本。ONES 提供工作项视图相关能力，团队可以把上述三层条件配置为可复用的视图并在团队内共享，让成员打开同一视图看到一致的结果；具体可用的筛选字段、条件组合方式和共享范围以实际使用版本的配置界面为准。把视图清单和责任表与工具中的视图配置对应起来，维护人检查时就有据可依。
一个完整示例：迭代内待处理任务视图
下面以一个迭代内的任务跟踪为例，演示从用途到配置的完整过程。示例中的字段和取值按通用项目管理工具的能力编写，实际配置时替换为团队使用的字段名称。
用途说明：供迭代内的开发成员和项目负责人在每日站会前确认本迭代尚未完成的任务，识别到期风险和阻塞情况。
第一层：固定范围
- 项目：当前迭代所属项目
- 工作项类型：任务
- 状态集合：待处理、进行中、待评审、已阻塞（不含已完成）
第二层：可变条件
- 迭代 = 当前迭代
- 负责人 ∈ 迭代内成员（个人使用时改为负责人 = 当前用户）
- 条件关系：以上条件同时满足
第三层：排序与显示
- 排序：截止日期升序，同日期按优先级降序
- 分组：按负责人分组
- 显示列：任务标题、负责人、状态、优先级、截止日期、标签
这个视图能回答的问题是：本迭代还有哪些任务未完成、分别由谁负责、哪些临近截止日期。它不能回答跨迭代的长期积压情况，也不适合用来评估成员工作量，因为视图只覆盖当前迭代且不含已完成任务。需要看历史完成情况时，应另建视图并调整状态集合。
需要随迭代切换调整的部分是迭代条件和成员范围。迭代结束后，视图应切换到新迭代，成员范围随之更新。如果工具支持按“当前迭代”动态取值，可以省去手动切换；否则维护人需要在迭代切换时更新条件，这也是该视图检查频率设为每两周的原因。
上线前的完成检查
一套视图筛选是否可用，可以按下面的清单逐项核对。全部通过再向团队发布，能减少上线后的反复修改。
- 用途与负责人：每个视图都有写清楚的用途说明和明确的负责人，用途能对应到一个具体工作动作。
- 条件无歧义：每个视图的条件都能在三层表中找到对应配置，与/或关系已写明。
- 字段口径明确：日期类条件写清字段和是否含当天，人员类条件写清是负责人还是参与人，状态类条件用集合并说明是否含已完成。
- 取值规范统一：标签和自定义字段的取值符合命名规范，没有同义多值。
- 共享视图已确认：共享视图经过团队负责人确认，命名符合统一结构，与已有视图没有明显重叠。
- 维护机制到位：每个共享视图都有维护人和检查频率，失效条件的处理方式和成员反馈渠道已告知团队。
- 结果验证：用一组已知任务验证视图结果，确认没有漏项和多余项，排序和显示列符合用途。
检查通过后，把视图需求清单、三层表、字段取值规范表和责任表放在团队可访问的位置，新成员建视图时可以直接参照。视图上线不是终点，按检查频率回看条件和结果，才能让这套视图在迭代推进中持续可用。
常见问题
个人视图和团队共享视图需要分开管理吗？
建议分开。个人视图服务于个人工作节奏，条件可以随个人习惯调整，不需要团队确认；共享视图会被多人引用，条件口径变化会影响所有人的判断，需要团队负责人确认后再发布。判断标准是：这个视图的结果会不会在会议、评审或汇报中被引用，会，就按共享视图管理。
同一个视图在不同成员那里结果不一致，通常是什么原因？
常见原因是条件之间的与/或关系没有写明，或者字段口径不统一。例如“负责人是本人”与“截止日期在本周内”是同时满足，而“优先级为高”或“标签为阻塞”可能是满足其一。另外，日期类条件是否含当天、人员类条件用的是负责人还是参与人，这些口径不写清楚，不同人配置出来的结果就会不同。建议回到筛选条件三层表和字段取值规范表逐项核对。
迭代切换后视图需要手动调整吗？
取决于工具是否支持按“当前迭代”动态取值。如果支持，视图可以自动跟随当前迭代，维护人只需关注成员范围；如果不支持，维护人需要在迭代切换时更新迭代条件和成员范围。这也是依赖迭代的视图检查频率要设得高一些的原因，建议每两周检查一次。
视图上线后，怎么发现条件已经失效？
字段被重命名、状态被调整、标签被合并，都会让旧视图悄悄失效，界面上往往不会报错。维护人按检查频率重点看三件事：条件字段是否仍然存在、取值是否仍然有效、结果是否还符合用途说明。同时保留简单的反馈渠道，成员发现结果不对时说明“哪个视图、什么条件下结果不对、期望看到什么”，维护人据此判断是修改条件还是调整用途说明。
视图数量应该控制在多少？
没有统一数量标准，判断依据是每个视图是否对应一个明确的用途和负责人。如果两个视图的条件和结果高度重叠，应当合并，合并前先确认原视图是否仍被引用。视图清单确认后再进入条件设计，可以避免同一批任务重复建多个视图。
