团队知识管理 by 阳志平

今天晚上，团队内部培训知识管理，跟写作课倒颇有渊源，给大家分享一点要点。

团队最佳知识管理实践

目前业界（一般提到业界，都是指硅谷互联网科技创业公司圈这个时间源头）的团队最佳知识管理实践是： Github + 一个支持Github的看板软件 + Slack
但因为，「一个支持Github的看板软件」，如 Waffle 、ZenHub 这些价格昂贵，所以并不合适国内使用。同时，国内的微信生态链太强大了因此，导致，国内目前最佳的知识管理是：「github/gitlab + 一个支持Github的看板软件 + 微信/类似竞品」
团队知识管理，侧重的是团队维护的共同记忆库。因此，这个记忆库建议也要遵从人类认知与记忆规律，这样才可以推行下去。一般来说，团队知识管理流程应该以人为单位，这样可以帮助你更好地记忆。
任何一个完善的团队内部知识管理系统或者流程都应该包括的组件：
- 1）新人使用指南：对任何一个新系统的简单介绍；
- 2）元项目：关于项目的项目，在此，申请、发起与修改团队内部知识管理的共识或者心理契约；
- 3）团队组织架构：团队的组织架构及每个人的职责分工，其中，特别指派一人兼任知识管理大使，此人最好细心且靠谱且处女座。
- 4）命名规则：团队共享的一套命名规则，最好基于组织架构来命名。
- 5）文档创建约定：团队共享的一套文档约定。
- 6）可复用模板示范：基于 wiki 或者其他树形结构组织。

团队知识管理中易犯的错误

子文件夹太多：
上过「认知写作学」的同学，应该深深地深深地明白了，有个 4x5 原理的存在！
因此，团队的子文件夹要尽量少、尽量少。

举个例子，常见的公司内部知识管理文件夹结构是：
安人心智集团-开智公司-成人教育事业部-开智写作课序列-认知写作学-认知写作学二期-认知写作学二期讲义
这个是典型傻帽行为，违背了人类认知习惯。那么，怎么精简？各位同学可以想想，咱们的「认知写作学」反复提及的一些规律。
简而言之，一键搜索+单文件结构。

上述目录，更合理的目录命名方式是：
course@openmind@writer002
其中，course 对应到组织架构，如开智公司下的「课程团队」；openmind 对应到「开智公司」；writer002 对应到「认知写作学二期」。
在实践中，一般 openmind 与course 还可以省略掉，
最后，这个目录命名即为：course@writer002
对应到电脑中的文件夹结构是：openmindclub.com => course@writer002
这样，多数子文件夹，可以控制在 4x5 结构以内。*
为什么鼓励大家用域名命名文件夹呢？此处善用了哪个认知写作学课提到的原理？
即，人类大脑是个先天的社会脑。当你意识到，自己的文章未来会分享出去，那么，你的记忆会更好。
有个有趣的认知科学研究，多年后，你回想自己是如何查找一篇文章的。
即使这篇文章，已经保存到你本地了。但是你依然记忆最深刻的是，当初你是如何通过浏览器，使用哪个关键词，找到哪个网站，然后再从那个网站通过哪个关键词，找到某条资讯的。
这是人类非常有趣的一个特质，如果用咱们「认知写作学」术语来说，就是，空间大于时间。
你的大脑非常善于记忆当初你的搜索路径，即使这篇文章你已经保存在本地了，但是你查找本地的效率远远低于上述查找效率。

因此，鼓励大家都用域名来命名自己的个人文件夹。而不要使用项目，更多使用域名。如：yangzhiping.com 就代表我的一切个人私人文件。其中，keynote.yangzhiping.com 就代表我的一切keynote文件。gist.yangzhiping.com 就代表我的一切笔记，这些笔记同时用gist方式自动同步。
用域名命名还有个好处，可以同步互联网上很多第三方服务，如 github，如gitbook，如更多。
人脑太喜欢脑补了。所以多用一键搜索而非子文件夹。一旦你给「gist.yangzhiping.com 」这个目录开设了一个子文件夹，比如，认知写作学相关的笔记，我都放在这个子文件夹下面。那么，你就想开更多的子文件夹，最终导致了一场知识管理灾难。并且，伴随你开的子文件夹越多，你就越糊涂，这个文件究竟该放到哪个子目录下？给大家看看我的子文件夹，很少做二级分类。

这个目录，在我的电脑中是： yangzhiping.com => paper.yangzhiping.com 写作课其实调用了200+ 篇博士论文，1000+ 美文图书库。但是这些博士论文，美文图书库，在我的电脑中一律是这样的：

接下来说第四点，也是一个非常常见的误区。
1. 知识管理，请以输出为导向。很多人，尤其是一些收藏狂人，会下载无数本电子书，然后强迫症一样，搞无数个子目录，比如，按照「美国文学」、「日本文学」一路整理下去。这类收藏狂人极多。还经常在网上秀自己的知识管理体系。但是这是非常低效的学习方法。知识管理，请以输出为导向。
  
  简而言之，今晚跟同事培训时提及，知识管理的输出有三个层级：
2. 1）卡片层级：为知笔记、Evernote、ios的记事本都是这个层级。这个层级主要用于收集素材。我使用最频繁的是ios的记事本。
3. 2）文章层级：这个层级，主要用于输出自己的系统思考，对卡片的二级加工。
4. 3）图书与项目层级：这个层级，主要用于与同事协作，或者涉及到长时间的项目。
  
  多数人的误区是，误将卡片、文章、项目三个层级混为一谈。
  举个常见的误区，不少人在卡片层级也喜欢搞分享。分享你个头啊。一旦引入一个新的「认知操作」，如「分享」，那么就加大了你自己的「认知负荷」。我这个素材，该分享还是该隐私？
  这样你每次认知操作的时候，都认知负荷加重，从咱们写作课提到的「简单反应时」变为「选择反应时」。
  另一个在文章层面的常见误区是，人们高估了分类的意义，而低估了持续创作的意义。也就是，人们常常喜欢写很多子类，但是文章数量上不来。
  
  比如，我的不少同事的文件夹结构是这样的：
  我的工作文档-------项目1-----产品需求-------产品需求文档第二版
  我的工作文档———项目2——用户调研———北京用户访谈-----北京用户访谈001
  上过认知写作学，大家应该明白这个常见的文件夹结构坏在什么地方了。
  这样导致，每天花费大量认知操作在摆弄文件夹结构，而非专注输出。拖延症现象也容易高发。
  更理想的是，按照文档属性，比如，你将自己常见的创造的文档类型划分为：keynote、markdown、程序代码即可。
  举个我自己的例子：
  yangzhiping.com 是一级目录，代表着我的所有私人事务。book.yangzhiping.com 代表我写的书。下面分别是： seven：心智七讲 openmindcanon：开智正典一路下去......

这样我就可以快速定位与快速输出。每个不同层级的需求与侧重点非常不一样。

简而言之，

卡片层级：所有卡片都应该不分子目录，全部在一个下面，如ios的记事本，并且完全隐私，不要做任何「开放」、「可分享」与「可社交」的操作。
文章层级：所有文章，3个文件夹绰绰有余。一个用于撰写个人心得；一个用于工作文档；一个用于keynote演示。在这三个文件夹下面，不做任何再分类。

举个例子，我撰写个人心得的文档，全部放在我的博客的 drafts 这个目录下面。当我觉得还是草稿品质的时候，就草稿好了；当我一旦觉得成熟了，就发布出去，放在我的个人公开博客上。对应我电脑的目录是：yangzhiping.com => blog.yangzhiping.com
工作文档，则全部放在：「gist.yanghziping.com]
文章层级，开始涉及到团队共享、多人协作问题了，但协作需求依然不多。所以你多复制几份给需要的同事即可。而借助 gist 的超强功能，我实际上所有文章都已经自动历史版本了。
很多人在文章层级的知识管理误区是什么呢？误以为存在非常多的团队协作需求，所以反而写得少，想得太多。一个典型例子，大家可以观察自己公司的知识管理系统，你会发现，多数文档总是由20%-30%的同事贡献的。
所以，文章层级的知识管理重心依然不是团队协作，而是自己多写。同时有个简单方法分享给同事即可。gist是个极好的方法。

3、图书或项目层级：所谓图书，至少要写三个月以上；所谓项目，至少要几周以上或者三人以上。 这个层级的知识管理，才开始发生重心的转移，第一考量不再是个人战斗力，而是团队规范。
那么，我的建议是什么呢？请记住写作课反复提到的「人类最佳知识结构是树形结构」与「4x5原理」。所以，我的所有图书都统一是gitbook格式。有一些书用的是scrivener写的。这部分书同样可以借助一些开源工具，用git来管理。如这个工具：https://github.com/carsomyr/scrivener_starter 而安人心智团队内部，所有项目，都一个「wiki」。这个「wiki」是借助「gollum」来管理的。
无论gitbook还是gollum，都是可以不断复用的，同时格式都是统一的，都是基于git与github来操作，这样非常节省团队学习成本与沟通成本。最后就可以不断复用。