项目做完了，那个群和一堆文档怎么办

结论先行：项目验收之后，为它建的群、传的方案、开的会议、留的记录，多数单位处于没人管的状态——群不解散也不说话，文档散在十几个人的本地目录里。这些是项目的资产，收尾时该按三类分流：以后还要用的、将来要拿出来做证据的、本来就该清掉的。分流做在收尾那一周，成本很低；拖到第二年再找，往往只能翻聊天记录。

本文只谈项目收尾时协作平台上群与文档的处置方式，不谈项目验收的组织流程，也不谈协作平台本身该怎么选型。

项目结束时最容易拖的三件事

其一，群没有人解散。项目群里最后一条消息往往是「辛苦了」，之后三个月偶尔跳出一条系统通知。谁也不敢解散——万一下次还要问人呢。于是这类群会一直累积，一年下来几十个。

其二，文档没有归口。项目过程中的方案、报价、会议记录、验收单，散在个人电脑、聊天记录、邮件附件和平台文档里，同一个文件可能有四个版本，没有一个能被当作最终版。

其三，责任没有交接。项目做完了，客户那边还可能有后续问题。谁接、在哪个群里接、拿什么资料接，没人写下来。半年后客户来问一个当时的决定，接手的同事只能重新问一遍。

先分清三类东西

分类的动作要在收尾那一周做。理由很实际：清楚哪份是过程稿、哪份是定稿的人，还在这个项目里。过三个月，这个判断就没人能做了。

群的处理：三种做法与代价

多数情况下第三种更稳：把原有群设为只读或转入归档，另建一个服务期的对接群，成员按当前职责重新拉。这样历史记录留得住，日常沟通又不会被几百条旧消息干扰。无论选哪种，都有一条硬要求——要把结论性的内容从群里搬出来。群里做出的决定如果没有落到文档或表单里，这个决定实际上只存在于几个人的记忆里。

文档归档：归到哪、按什么命名、谁能看

三件事要一次定清楚，否则归档等于把文件从一个没人找的地方搬到另一个没人找的地方。

归到哪。统一归入团队共享的资料库空间，按「客户—项目—年度」三级目录，不要按文件类型分。按类型分（合同、方案、报告各一个目录）看着整齐，实际找的时候人记的是项目名，不是文件类型。

按什么命名。建议「项目编号_文档类型_版本_日期」，四个字段够了。版本字段不要用「最终版」「最终版2」这类写法，用序号加日期。

谁能看。按岗位授权，不按个人点对点授权。参与过项目的人离职、转岗之后，权限应当随岗位变化自动收回，而不是靠人工清理。对外协作的那部分文档单独放一个空间，与内部资料隔开——外部成员一旦进入内部空间，能看到的范围往往超出预期。

客户能看到的那部分要单独处理

项目收尾时，通常要把一部分材料交给客户：验收报告、操作手册、培训材料。这部分要单独走一遍，不能直接从内部资料库里分享出去。

• 确认分享的是「一份」还是「一个入口」。发一份副本，后续更新客户拿不到；给一个入口，目录里的其他文件也可能被看到。
• 带得走的和带不走的要分清。需要在客户那边留存的文件，允许下载；只供查阅的，限定在线查看。
• 谁看过、看了几次，值得记一笔。尤其方案类材料，这个记录在后续沟通里能省很多解释。

归档之后怎么才能被找回来

归档工作的验收标准不是「文件都放好了」，而是「一个没参与过这个项目的人，能不能在五分钟内找到需要的那份」。要满足这个标准，至少要有两样东西：一份项目索引（写明这个项目交付了什么、关键文档在哪、当时的负责人是谁），以及统一的检索入口。

实务上最容易漏的是索引。文件都归了档，但没有一张表告诉后来的人「这个项目有哪几份关键材料」。索引不需要复杂，一页纸：项目编号、客户、周期、交付物清单、留档位置、原负责人。这一页纸在交接时价值极高。

边界与前提

三点说明。其一，文中提到的目录层级、命名规则、保留期为参考做法，具体应按本单位档案管理制度与所属行业要求确定。其二，协作平台的空间权限、外部成员可见范围等能力，各平台实现不同，落地前需要按实际版本确认，并以本项目实测为准。其三，涉及合同与客户资料的留存年限，应以合同约定与法务意见为准，本文不作为依据。

深圳市奇摩计算机有限公司在交付项目时，会把「收尾清单」和验收单放在一起走——收尾不是项目之后的事，而是项目的一部分。

如果你手上正好有几个刚验收完、群还挂着没动的项目，预约咨询，可以先把这份分流表用起来。