把项目收好尾：合格的收尾，对比人人都见过的那一种
大多数项目都是虎头蛇尾地结束的。交付物一交，团队便奔向下一个火场，收尾沦为一个没人打开的文件夹。这是一次错失的机会，因为收尾正是把一个完工的项目转化为组织真正可复用资产的环节。过去这一年，分布式团队人来人往，潦草收尾的代价更高了：当知识只存在某个人的脑子里，而那个人离开时，它就随之消失。下面就是有效的收尾与人人都见过的那种收尾之间的区别。
糟糕的收尾长什么样
糟糕的版本人们都很熟悉。验收是被默认的，而非被确认的——客户从未正式签字认可，于是几个月后有人对究竟交付了什么提出争议。未结的发票和一笔被遗漏的分包商承诺一直拖着，因为没人把财务清算归零。所谓的“经验教训”会议要么根本没开，要么变成互相推责的批斗会，少数诚实的洞见则消亡在一段聊天记录里。文件散落在各人的私有硬盘和邮件中。人们只是不再谈论这个项目，而大家误以为这就是完工。
签字认可是口头的或默示的，从未落于书面。
财务悬而未结；最终成本只是一个估计。
经验教训被跳过，或被当作攻击他人的武器。
记录散落在收件箱和个人文件夹里，而不在一个可查找的统一位置。
团队在任何人被正式释放或致谢之前就已解散。
合格的收尾长什么样
合格的收尾是有意为之且简短的。你对照真正约定的内容核验工作，取得书面验收，结清款项，在记忆尚新时记录所学，并把一切放到下一支团队能找到的地方。这一切都不需要繁重的流程——它需要的是有人负责到底，以及在团队散去之前开上几次聚焦的会议。
对照范围核验。 把最初的需求逐条走一遍，确认每一项是已满足、已延后，还是已正式取消。此时发现意外，远比在保修争议中处理要便宜得多。
取得书面验收。 客户或发起人签署的一份简短确认书，能堵上日后对“完成”含义争执不下的口子。
结清财务。 核对已承诺成本与实际成本，清掉未结采购订单，释放质保金，并记录最终数字。一个款项未结的项目不算关闭。
做一次诚实的复盘。 一个小时，有人主持，聚焦流程而非个人。写下两三条要保留的，两三条要改进的，并确保它们送达规划下一个项目的人。
归档到可查找之处。 把合同、图纸、审批、财务摘要和经验教训收进一个可审计的统一位置，使一个陌生人在一年后也能在其中找到方向。
检验收尾是否合格的诚实标准很简单：如果主持这个项目的人明天离开，别人能否重建出当时发生了什么、花了多少钱、下次应当如何改进？若答案为“能”，那就算关闭了。若这一切只存于一个人的记忆中，你就处于风险敞口之中——而在分布式团队里，这种敞口是实实在在的。
如果你的项目往往是渐渐消散而非真正收尾，XNM 的项目群与项目交付咨询服务 可以帮你建立一套行之有效、站得住脚的收尾做法。