保留粒度不取决于文档数量,而取决于下一轮接手的人能否在不联系原成员的情况下重建判断依据。如果项目还会在同一批页面上继续迭代,应保留到“能复现一次改动决策”的粒度;如果站点即将迁移、改版或整体交接给外部团队,则应保留到“能独立完成一次同类审计”的粒度。两种条件下要留下的东西并不一样,把两者混为一谈,往往会出现文档堆得很厚、真正需要时却找不到关键那一页。
这类项目的典型特征是:核心页面结构、栏目划分和转化路径基本稳定,后续工作以局部调整为主。此时文档的价值不在于记录全部过程,而在于让接手者明白某个页面为什么长成现在这样。
判断粒度是否够用,可以用一个简单测试:假设半年后有人想改动某个页面的标题写法或内容结构,他能否仅凭文档判断这次改动会不会推翻此前的结论。如果只能看到“某月某日调整了标题”,却看不到当时的对照对象、判断依据和放弃的方案,这份文档就偏粗;如果连每一次措辞微调都单独成文,又偏细,反而增加检索负担。
具体应保留的内容包括:
可以合并或删除的内容包括:中间过程的草稿版本、已经被推翻且不再影响现状的讨论、重复记录同一结论的会议纪要。合并时应保留结论和依据,删掉重复叙述。这样做的结果是文档条目减少,但每条都能回答“为什么”,后续检索时间会明显下降,接手者更容易在改动前先查历史而不是重新试错。
当项目结束后不再由同一批人继续跟进,或者站点要换域名结构、换内容体系、换运营方,文档粒度需要整体提高一档。原因很直接:新接手者没有共同上下文,无法靠口头补充理解一份只写了结论的文档。
此时应保留的不只是决策,还包括可复用的判断方法。例如,原团队判断某个栏目是否值得保留时依据了哪些数据口径、排除了哪些干扰因素、在什么条件下会得出相反结论。把这些写清楚,新团队才能在新的数据环境下做出自己的判断,而不是照搬旧结论。
需要额外补齐的内容有:
一个假设的例子:某站点在交接时文档只写了“栏目A流量低,建议合并”。新团队接手后直接合并,却发现该栏目承担着一条转化路径的入口,流量低但转化稳定。如果原文档写明“流量低但转化稳定,保留原因是转化路径依赖”,这次误判就可以避免。这个例子的重点不是数字,而是说明粒度差在“结论”和“结论加适用条件”之间。
与其凭感觉判断文档够不够,不如做一次检索测试:随机挑三个已经发生过的改动,让不熟悉项目的人只查文档,回答三个问题——当时改了什么、为什么改、如果现在要再改一次需要先确认什么。三个问题都能答上来,粒度基本够用;只能答出第一个,说明文档停留在操作记录层面;答不出第三个,说明缺少适用条件,交接后容易误用旧结论。
测试结果直接决定下一步动作:如果三个问题都能答,就只需按条件一或条件二补齐缺失项;如果多数答不出,不要急着补写全部历史,而是先补齐最近一次影响页面结构的决策记录,再向下追溯。这样做的原因是,越靠近当前的决策越可能被再次参照,历史越久远的记录被重新使用的概率越低,优先补近期的投入产出更合理。
有些信息不适合写进历史文档,也不该因为文档不够细就强行补录。例如个人之间的沟通习惯、临时性的口头约定、尚未形成结论的猜测,这些内容写进去会降低文档可信度,让接手者分不清哪些是已验证事实、哪些只是当时想法。
另外,账号权限、后台入口位置、第三方服务状态这类信息变化快,写在历史文档里很快会过期。更合适的做法是在交接时单独确认当前状态,而不是依赖几个月前的记录。文档粒度解决的是判断依据的留存问题,不是所有操作信息的存档问题,把这两件事分开,文档才不会越写越厚却越来越难用。
最后需要说明的是,保留粒度没有统一标准,它随项目是否继续、接手方是否具备同等背景而变化。先确定属于哪种条件,再用检索测试验证,比直接套用某个页数或条目数更可靠。