企业官网建设流程全解析

本文要处理的问题：当待办事项持续膨胀时，怎么用一套可复用的筛选口径，把清单稳定收敛到少数真正决定结果的任务上。

一、问题：清单越长，交付反而越差

多数团队的待办管理方式是把所有事都记下来，然后按紧急程度排序。这个做法在事项少于二十条时还能运转，超过之后就开始失效。

症状有三类：

其一，优先级的判断标准来自直觉，不同的人排出来的顺序不一致；其二，被排在前面的往往是回应成本低的事，而不是影响面大的事；其三，季度复盘时发现，真正推动方向的任务只完成了一部分，精力主要消耗在看起来都不错的零散事项上。

问题的本质不是执行力，而是筛选口径缺失。一份没有明确定义的排序，等价于没有排序。

有一个被反复引用的案例可以用来说明口径的重要性：1997年，一家科技公司回到正轨的头一件事不是开发新品，而是把十几条产品线停掉，只保留四类产品。这个动作的前提是先有一套产品边界的定义，否则无法判断哪一条线该停。

筛选的前提是先定义边界，而不是先排出顺序。

二、方案：价值参照、清单、回避项三层分离

工程上把待办筛选拆成三层，每层只对上一层负责。

- 参照层：定义长期价值判断，作为所有排序的上位依据；

- 清单层：承载全部待办，并完成首轮筛选；

- 回避层：记录明确不做的事项，以及遇到它们时的应对方式。

目录结构

task-focus/

├── values/ # 长期参照，变更需走评审

│ └── north-star.yaml

├── backlog/ # 全量待办

│ ├── items.yaml

│ └── score.py

├── avoid/ # 回避清单与应对预案

│ └── rules.yaml

└── review/

└── cadence.yaml

筛选配置

focus:

north_star: "长期价值判断的唯一上位依据"

backlog:

capture: all # 先全量收集，不做即时筛选

rank_by:

- impact_score

- reversibility

keep_ratio: 0.2 # 首轮保留百分之二十

second_pass:

keep: 1 # 第二轮只留一条

avoid_list:

enabled: true

require_preplan: true # 每条回避项必须配应对预案

cadence:

daily_minutes: 15

weekly_hours: 1

quarterly_hours: 3

yearly_days: 1

`capture: all` 这一项容易被省略。如果采集阶段就开始筛选，被淘汰的事项不会被记录，第二轮就失去了完整素材。

`require_preplan: true` 同样关键。只写不做的事，几乎必然会在三个月内被重新捡回来，因为缺少应对预案。

三、指标口径

口径不统一的后果是：两份看起来都很完整的复盘，放在一起没法比。

| 指标 | 计算方式 | 需要注意的地方 |

| 影响分 | 按对核心方向的作用强度打分 | 打分标准要外置，不能写在脚本里 |

| 可逆性 | 做错之后能否低成本回退 | 不可逆事项应单独标注 |

| 保留率 | 首轮保留条数 ÷ 全量条数 | 长期高于三成说明筛选未生效 |

| 收敛度 | 末尾执行条数 ÷ 首轮保留条数 | 目标值接近二十分之一 |

| 回避执行率 | 实际避开条数 ÷ 回避清单条数 | 低于八成说明预案不可用 |

| 核心指标占比 | 推动方向的任务耗时 ÷ 总耗时 | 与虚荣指标对照看 |

口径外置成配置文件之后，调整口径不再需要改动脚本，历史记录也能按新口径重算。

四、验证

筛选机制的问题往往不是准不准，而是稳不稳。同一份待办，隔一周再筛一次，结果差异过大，说明参照层没有被固化。

checks:

- name: 排序稳定性

rule: jaccard(week_a_top5, week_b_top5) >= 0.6

- name: 采集完整性

rule: captured_count >= planned_count

- name: 回避项预案覆盖

rule: all(item.has_preplan for item in avoid_list)

- name: 参照层变更

rule: north_star.version_unchanged_within_quarter

- name: 收敛达标

rule: final_count <= 3

参照层变更这一条容易被忽略。参照一旦每两周改一次，排序结果就会跟着漂移，到头来等于没有参照。

五、踩坑记录

坑一：把紧急当重要。紧急事项的反馈周期短，容易在排序里自动靠前。正确做法是按影响分排序，紧急度只作为执行时段的参考。

坑二：跳过全量采集直接筛。边收集边淘汰，会让被淘汰项不留痕迹，第二轮无法复核，也无法判断筛选口径是否偏了。

坑三：回避清单只写不做，不写应对。缺少预案的回避项，通常在一个月到三个月内失效。预案要具体到场景和话术。

坑四：用虚荣指标做验收。记录条数、完成数量这类指标看着在涨，但与方向无关。验收要用核心指标，比如关键任务的完成占比。

# 反例：按紧急度排序，且不做第二轮收敛

queue = sorted(backlog, key=lambda t: t.urgency)

plan = queue[:10]

# 正例：先过参照层，再两轮收敛，回避项前置拦截

queue = [t for t in backlog if allowed_by(north_star, t)]

queue = sorted(queue, key=lambda t: (-t.impact_score, t.reversibility))

first_round = queue[: max(1, int(len(queue) * 0.2))]

plan = first_round[:1]

plan += [t for t in first_round if t in must_do_by(avoid_rules)]

部署时还有一处细节：规则配置文件里的域名用 your-domain.test 这类占位统一管理，按团队分发到不同目录，否则单点改动会同时污染多个团队的筛选口径。

六、小结

从全量待办到一份能执行的清单，中间隔着的是一整套筛选口径。筛选机制的价值不在于把清单排得多好看，而在于让不同的人、不同的时间点排出来的结果能够相互对照。

顺序也应当反过来：先把参照定下来，再谈排序。