认清它，承认它，然后改变它。
1. 现状
团队知识沉淀，在前文介绍过的传统软件行业中技术团队的发展(现状篇) 背景下，十有八九都是属于"重要但不紧急"的事情——说起来非常重要，但在实际执行过程中都是被作为最低优先级，总是说事后会补，但最终往往是"later is never"。
对于传统软件行业技术团队而言，往往一个项目下来，除了需要对外交付的最终软件制品和甲方明确要求的验收资料之外，很少会有执行过程信息被留存下来。
这里面最典型的就是项目中遇到问题做决策时的考量 —— 每个决定是怎么做的，为什么最终选择了这个解决方案？解决过程中又遇到了些什么问题，又是怎么解决它们的？
这种做事方式导致的典型结果就是：
- 同一个问题，团队里的每个人各自为战，都得从零解决一次，解决质量完全取决于当事人的当下能力。
- 团队缺少知识的沉淀和传承，问题始终在低维度横跳，缺乏进一步精进的可能性。
- 每个人都在喊忙，陷入低层次的问题循环中。
以上并非为了批判，更多的是表明一个事实，而最终目的是为了解决问题。因为这才是我们的目标。
按照经典的80/20定律，任何一项工作里，占据着八成份额的工作其实都是重复性的，属于不得不做，但价值并不高。我们只有不断优化处理这部分的方式方法，才能节省出更多精力来直面那两成的高价值难题。
为了让目标更为集中，方便问题讨论，本文以下部分只关注技术团队中，对于问题解决方案的沉淀，探讨如何确保问题以团队的视野去解决，去沉淀，去精进。
2. 方法
对于解决知识沉淀的问题，一个指导性的思路就是以团队的视角去看待问题，用团队时间来衡量问题的解决，最大限度避免团队时间的浪费。（团队时间 = 每个人为团队工作的时间 * 团队人数）
如果同一个问题，团队成员A解决一次之后，团队成员B因为不知道这个背景而被迫自己又从零解决了一次。那么在这整个过程中，针对该问题所付出的团队时间就出现了浪费。
以上指导思想之下，具体的执行办法其实很简单： 以企业WIKI作为主要工具，将团队知识承载其上，并在之后带领团队不断对其进行完善。
上述方法的前半部分“引入文库/WIKI来记录团队知识”这一点并不难想象到，本文接下来部分主要探讨的是“如何确保这项措施不会半途而废，让团队内部在认知和行为上形成对于知识沉淀的重视，让事情向好的方向发展”。
3. 最佳实践
3.1 以身作则
这一点最重要。 这是笔者过去四年，将知识库从技术团队内部一步步推广到整个集团公司，所坚持的最根本原则之一。
行动才是最具有说服力的。从此刻开始，作为负责人的你，对于组员反馈到你这里的问题：
- 不要再直接告诉他答案，先将解决方案放在文库，然后把文档地址发给对方。
- 并且嘱咐对方，如果有什么注意事项，在评论区补充一两句。
- 上面这一步肯定会有很多人答应地很好，但最终他们什么都没有做。这一点很正常，所以你需要持续性地重复上面的操作，不断宣讲，刻意引导。
通过以上方式，就能够逐步建立起第一批的种子文档，这些直接诞生于真实场景下的必然具有相当的生命力，以它们为基础，可以：
- 为核心骨干减轻工作压力。相较于原本口传心授，必须到场的问题解决，以文档作为缓冲的问题解决流程，可以确保每个问题的解决都能留下些许积累，这样待下次类似问题出现时候，这些文档可以帮助核心骨干挡住一些外部压力，规避过往每次都必须拿脸接怪的尴尬。
- 实现"解决一个问题"向"解决一类问题"的转换准备。通过将问题和解决方案记录下来，除了为下次问题复现时的快速解决提供基础外，我们也可以借助不断增多的问题样本，从中发掘出更深层次的问题本质，实现解决方案的升华。
- 辅助实现人员筛选。正如"好的架构是演化出来的"一样，好的文档也是需要多次迭代的，那么在这个迭代过程中，愿意主动参与进来的人，一定是富于团队协作精神，擅长思考总结的。对其的资源倾斜有助于团队的良性发展。
3.2 晓之以理，不如诱之以利
直接制定公司制度，要求从明天开始，自上而下每个人都要做好知识沉淀，记录好每个问题的解决方案，研发过程数据做好留存，这样的实现路径看着是既爽又解气，想想都有点小激动。
但可惜的是，现实肯定不会是这么童话。
对于传统软件行业技术团队而言，因为开发流程不规范，事情多且杂，自动化程度低，人治现象明显，人员待遇偏低等等问题，导致领导对于下属的控制力其实很低 —— 你再BB我就离职，这点工资我在哪干不是干，而且还能再多涨点薪水，岂不美哉。
另外知识沉淀也有其特殊性。知识沉淀最典型的方法就是写文档了，如果你上来就搞什么激励制度，那么非常容易出现的一种现象就是凑字数，凑篇数。
任何一项制度一定需要有相应的检查机制，一篇经过精心准备，遣词造句，良好结构布局的文档，相较于一篇直接从外面复制来的博文，前者所花费的精力完全不是一个数量级。如果只是粗暴地以篇幅计算，那就会陷入典型的劣币驱逐良币的尴尬境遇。 而且文档这种东西，更需要主观能动性的参与，一味强压只会造成应付式的交差，增加优秀作品的发现难度，反而不利于整个团队知识沉淀的推进。
所以，知识沉淀的起步和发展阶段，不适合强压。我们需要因势利导，吸引团队成员参与：
- 引导组员针对某个经常会发生的问题写下第一篇解决方案汇总文档。并在之后问题再次发生类似问题时候，引导他对文档进行优化。并且让他自己切身感受到因为对这项知识的不断沉淀，对其自身的益处——这件事情不再需要他亲身介入，即使时隔数月，之前写下的文档也能让他快速回忆起来部分细节。
- 针对组员编写的解决方案文档，按需发给有着类似需要的组员，并引导他们进行完善，最终形成针对某一类问题的集中讨论，形成头脑风暴。
最终形成如下的问题协作模式：
- 先在文库搜索，看是否有相关话题；
- 没有相关记录的，自己解决完了在某个相关话题评论区，或者单开个文档记录下。
一类问题，团队视野下集思广益，解决沉淀个4，5次，以后即使全部换上新人，问题也不会闹出圈。
3.3 切勿急躁
我们做事时候经常犯的一个错误就刚开始时候的热血上头，恨不能一天24小时全部铺在上面，并且预期颇高，巴不得一周内落地，第二周看到效果，第三周就能开表彰会了。
事情肯定不会是这么完美，尤其是当你是在一张已经满是涂鸦的纸上作画时。
万事开头难，欲速则不达。
时刻提醒自己，知识沉淀就是个持续优化，逐步加速，先慢后快的过程。
- 首先要承认一个事实：知识沉淀这种着眼长远的行为，与人性弱点中的短视是天然冲突的。与个体而言，作为理智选择结果的知识沉淀，是需要持续地刻意练习才能内化为下意识行为。我们需要有与之进行长期斗争的心理准备。
- 针对同一个问题，个人确实因为其视野和能力问题导致解决方案比较简陋，但我们可以以团队视野去看待问题，将简陋的方法先沉淀下来，给后面的组员一些提示，通过不断的积累，再逐步优化出最佳方案 。
- 文档格式不重要，内容也不重要，重要的是先记录上去。刚开始的时候文档数量少，所以针对问题经常找不到解决方案是很正常的；我们现在只要求数量，质量不做要求，什么文档格式，内容的严谨性，科学性，句式的华丽优美，存放位置都是扯犊子（人都要饿死了，你跟我这讨论萝卜上的花应该怎么雕才更有食欲？）； 数量都上不去，讨论质量没意义 。
- 多多鼓励组员主动编写文档的行为，积极回复每一次的组员反馈。引导他们“不用太高标准要求自己，我们要的是持之以恒更新”； "坚持一个月，每天一篇 VS与一天更新一个月的数量"，我们更希望是前者。 是的，这一点直接借鉴自开源社区建设；笔者也是一直建议，如果团队内部一直是各自为战，野蛮生长，那么推荐直接借鉴开源社区的建设思路，启动团队改造计划。
3.4 一些技巧
- 在经过一段时间的集中建设，文档数量上来后，针对文档搜不到的问题，一来需要继续完善文档数量，二来也需要对组员进行培训，传授他们提取关键字的能力，第三就是一条非常具体的建议 —— 回想下你当时为什么没有搜到对应的文档；然后将搜过的关键字补充到文档 labels 里。
- 鼓励组员编写文档的时候，将参考链接带上。一来文档编写是个技术活，不少人缺乏将问题描述清楚的换位思考能力，所以不如将参考文献放上来，为后来的组员减少一些资料搜索，对比印证的时间，这也是团队的一次进步。
4. 最后
把自己过去多年为了推进流程规范化做的事情说给一位朋友听，朋友很疑惑地问我：“怎么感觉你就像是在哄小孩”？
也许吧，但最终我想要的是结果，其他的，都只是手段罢了。
5. 参考
- 传统软件行业中技术团队的发展(现状篇)
- 传统软件行业中技术团队的发展(团队破局篇)
- 传统软件行业中技术团队的发展(个人破局篇)
- “能够高效地自我复制”是传统软件行业公司中高级人才认定的关键