信息混乱的一个根本原因是“没有所有权”。
人员被分配到项目。项目结束（或被取消），人们继续前进，文件留下来聚集“灰尘”并成为信息混乱。
这很难预防。wiki vs. sharepoint 并没有解决混乱，它只是改变了用于积累混乱的技术基础。
让我们看看杂乱无章
技术设计信息/架构文档。旧的无所谓。有当前的，有无关的。维基。
去年过时的设计信息——嗯——已经过时了。
会议纪要、行动项目等。行动项目成为开发冲刺中某人待办事项的一部分，或者，它们可能永远不会完成。积压是 wiki 项目。其他一切都是历史，可能很有趣，但通常不是。如果它没有创建 sprint backlog 项目、更新架构或解决开发问题，那么会议可能是浪费时间。
项目计划和路线图。sprint backlog 很重要——这就是“计划和路线图”所渴望的。如果你必须用路线图补充你的计划，你可能应该放弃计划，只使用 Scrum 并保持积压工作是最新的。
最初的计划是某人对项目启动时间的猜测，对当前的项目团队来说并不是很有趣。
组织业务管理信息 - 旅行、预算信息、员工人数信息等。这是高度结构化的东西（预算、组织）和非结构化的东西（“旅行”？）
你需要多少历史？没有任何？最好是维基。财务或人力资源系统是它所属的地方。但是，在大型组织中，会计系统使用起来既困难又麻烦，因此我们创建了辅助信息源，例如带有过期预算数字的 SharePoint 页面，因为真实的预算数字隐藏在 Oracle Financials 中。
包含业务分析、需求等的项目页面。这是您的待办事项。你的项目路线图和你的需求和你的分析应该是一个单一的文件。在维基。
历史很少重要。某人在项目开始时对需求的概念不再重要。最终形式的需求演变成什么比任何历史都重要。这是维基资料。
太老了是多老'？
我曾与拥有 30 年历史的软件的客户合作过。该软件——显然——是相关的，因为它正在生产中。
但是，文档全是垃圾。该软件已得到维护。它充满了变更控制记录。“原始”规范必须仔细地重写每个变更控制。由于变更控制文档可能非常普遍，查看更改应用位置的唯一方法是阅读源代码，然后——从中——对当前状态规范进行逆向工程。
如果我们只能通过对源代码进行逆向工程来理解一个 30 年前的应用程序，那么，扔掉 30 年前的那堆纸。没用的。
维护完成后，“原始”规格已贬值。
如何清理它？
如果您创建了 wiki 页面或 sharepoint 站点，您将永远拥有它。当你离开时，你的替代者永远拥有它。
每位经理对其员工创建的每条信息都负有 100% 的责任。他们必须删除东西。弱解决方案是“归档”东西。这只是在没有“D-word”的情况下说“删除”的一种礼貌方式。
清理工作必须是每个经理的持续责任。如果他们不记得它是什么，或者他们为什么拥有它，他们应该被要求（或“鼓励”）删除它。在过去两年中未访问的所有内容都应该毫无疑问地存档。10年前的一切都只是无关紧要的历史。
这很痛苦，而且似乎不是创造价值的工作。毕竟，我们从事 IT 工作。我们的工作是“编写”软件，而不是删除它。除非迫于开火威胁，否则没有人会这样做。
存储成本相对较低。清理成本似乎更高。
如何停止电子邮件链？
拒绝参与。创建一个“打破链”活动，专注于用 wiki 更新（或共享点更新）替换电子邮件链。
确保您的 wiki 提供链接并且比电子邮件更快地编辑。
你不能强迫人们放弃一个非常非常方便的解决方案（电子邮件）。您必须使 wiki 更有价值，并且几乎与电子邮件一样方便。
提升 wiki 上的价值。弃用电子邮件链。拒绝回复电子邮件链。拒绝通过电子邮件接受“待办事项”行动项目。