实现很容易被看见，找答案通常不会。
团队会估算开发、测试和评审，会讨论交付速度和周期。但在真正开始做之前，往往已经有人花了不少时间翻文档、确认归属、追溯历史决定，或者在陌生的系统里找入口。
这些时间很少被单独记录。它们被当成准备工作，散在会议、消息和临时询问里。可没有这些工作，后面的实现根本无法开始。 产品越成熟，这部分成本通常越高。
知识并不只存在于文档里
一提到知识管理，大家很容易先想到“是不是文档不够多”。文档当然重要，但组织里的知识还藏在数据模型、命名方式、历史工单、发布记录、团队习惯和个人经验中。
熟悉产品的人知道该去哪里看，甚至不需要解释原因。新加入的人却必须先把这张内部地图一点点拼出来。
很多时候，答案并不是不存在，而是没有人知道它在哪里。找不到的知识，在工作中和不存在没有太大区别。
团队会重复创造自己已经拥有的东西
这种情况很常见：问题出现了，大家找不到现有机制，于是开始设计新方案。过一段时间，另一个人发现系统其实早就处理过同样的问题。
这不一定是谁判断失误。大家只是根据当时能拿到的信息，做出了合理决定。 真正失效的是组织把已有知识带到决策现场的能力。
重复组件、重复字段和重复规则，有时不是工程能力的问题，而是已有答案太难被发现。
查找成本之所以隐形，是因为它太碎
它很少完整占据一个下午，更常见的是二十分钟翻旧工单、一次临时询问、一场确认归属的会议，或者等某位休假的同事回来。 单独看，每一段都不算昂贵。加在一起，却可能吞掉几天。
因为这些时间散在日历和对话里，组织通常只看得到“开发用了多久”，看不到在开发开始前，团队已经花了多久寻找方向。
很多速度问题，其实更早就发生了
交付变慢时，团队通常先优化开发流程、测试方式或计划方法。这些改进可能有用，但真正的堵点也许出现在更前面。
如果团队连几个基本问题都不能快速回答——规则放在哪里、谁最了解这个功能、当初为什么这么做——那么后面的流程再顺，也很难真正快起来。 让知识更容易找到，往往会顺带让实现变快。
为后来的人设计
人员会流动，项目会变化，熟悉系统的人也会离开原来的团队。
真正能留下来的，不是某个人记得多少，而是组织让多少知识变得可以被找到、被理解，也值得被信任。
文档、清晰命名、明确归属和可导航的系统结构，本质上都在做同一件事：减少后来的人重新摸索的时间。
每一次成功实现之前，都先要有人找到让这次实现成为可能的答案。