关于公司级别的知识库的建设的一些看法。

从毕业到现在，在软件这一行做了接近一年的时间了。现在对于在公司内部建设一个健全的知识库的体系有一些看法。

公司现在正在准备CMMI3级方面的一些建设。平时也搞一些CMMI方面的培训。
在软件生产过程的改进方面，公司要产生大量的过程文档，规范软件开发的过程。

同时，就在想，能不能在规范这个过程的同时，建设起来公司自己的一个知识库呢？
首先就是为什么要建设这个知识库：

所谓的知识库，就是对知识进行管理。现在一般的作外包的软件公司，人员的流动性比较的大。通常是有新人一批一批的进来。老员工也会有一定程度上的流失。在没有一个好的知识管理的情况下，无形当中造成了比较严重的知识的流失。每一次新人的培训都要花费公司比较大的精力。而且没有一个比较统一规范的培训过程。在培训这一方面的花费不说、很多在做项目的时候遇到的一些特殊问题的解决方法也不能再没有知识库的情况下得到有效的积累。等到后面又来了新的项目的时候，往往很多东西还得再来一遍。浪费很多的时间，也就是钱。所以除了软件开发过程文档以及规范以外，对于软件开发的一个公司组织级别的知识库也是 比较有必要的。

然后是需要讨论一下公司的这个知识库的组织形式。在我看来，这个知识库需要有几个方面的功能。
其一：组织库能够收集公司在培训、项目当中属于公司自己的那一部分知识并且可以加以保存归纳。在以后的培训和项目中可以方便的进行有体系的查询及获取。
其二：组织级的库能够回答新人或者老员工在不熟悉的领域遇到的问题。然后加以整理。
其三：组织级的库能够收集一些源代码级别的属于公司自己的问题解决方案，在以后的其他项目中可以凭借这些轻易的完成一些工作。
其四：组织级别的库如果能够有行业中一些开源的框架和代码的使用积累，就更好了。这个开源不是指STRUTS之列的大家都知道的东西，而是指在一些领域有特别的功用的一些处理方式。大家都认可的处理方式。
其五：建立起来公司内部的组件级别的知识库。

这对以上的一些观点和需求，考虑了一下实现的方式：

1、 在文档类型的知识库的组建上面，可以采用weiki的方式进行组建。不过这样的话，可能需要专门的人员负责进行收集组织和归纳。然后也要号召公司的员工进行知识的贡献。然后就是在项目的开发过程中间增加一条过程，那就是项目的问题解决方案的收集。
2、 在源码和组件级别的知识库的组建上面，需要结合文档知识库以链接的方式给出源码和组建的使用方法、心得以及源码组件本身。

上面的这些想法可能有很多的不合适的地方，请大家指教。谢谢。



知识库是好东西，但是为什么很多国内的软件公司都没有呢？
首先，建设知识库需要成本，主要是人力成本；
其次，知识库的建设需要一个较长的周期，才能到达一个能产生收益的临界点。
管理层来看，简单的说，就是在现在投入成本去建设一个未来（不知何时）能带来一定收益（无法详细估算）的东西。这种东西对于管理层（尤其是营收压力比较大的管理层）来看是没有任何诱惑力的。所以很多公司宁愿把成本花在招人也不花在知识库的建设上


有几点想法：
1，有多少东西是网上查不到的，必须搬到自己的知识库中；如果网上的资料就很全，为何不用网文快捕之类的软件做成一个专题书籍呢？这样省时省力。
2，公司有多少人愿意喜欢写文档，如果强制要求会有多大效果？wiki真的合适吗？
3，培训资料的整理还是很有必要的；这个的工作量不大
4，学习的成本代价也很高，还是老人带新人好；有效果也容易实施；公司应该完善这方面的制度
5，我先问一下楼主，个人的知识库的建设有什么心得？

第一点，网上很多东西是查不到的，公司很多资料是专有的。
第二点，写文档不是愿意不愿意的问题，是如何管理好的问题。
第三点，没有问题是简单的，只有如何能做好。
第四点，知识库就是为了增进知识共享，降低成本。



2，公司有多少人愿意喜欢写文档，如果强制要求会有多大效果？wiki真的合适吗？

就这样一点来说，大概大家都不喜欢写文档。但是好像大家都喜欢写Blog，不知到为什么。
在公司内部推行文档资料的收集我也感觉很有难度。不过如果在项目内的解决方案的收集形成了
一个制度的话，还是比较可行的。因为项目内的事情大家比较容易接受去做这样的一件事情。
而在项目外的资料的收集，可能还是要有一定的动力（奖励？）才比较好推行。
不过我觉得老员工带我的时候总是说：“有一个现成的文档让你看就好了！”，我觉得这个也许可以形成动力。因为这样可以让老员工带新人的成本迅速的降低。

至于wiki这样的一个形式，我也不觉得是很好的。因为在很多方面，我也觉得wiki不适合。例如搜索方面。


sofire 写道

4，学习的成本代价也很高，还是老人带新人好；有效果也容易实施；公司应该完善这方面的制度


这一点我觉得如上面所说的，老人带新人的成本如果能再降低的话，也不能说不是一件好事。事实上就是平时大家都很忙。我就经常遇到有问题而又找不到人问的情况。很多问题也确实在网上解决不了。


sofire 写道

5，我先问一下楼主，个人的知识库的建设有什么心得？

关于我自己的个人知识库的建设，说来比较的惭愧，整理得比较的乱，可能就我自己认得，因为我的资料本来就不是很多、而且我也大概都知道在哪儿，所以分了一下目录存放了一下。这一点确实做得不好。


mvmouse 写道
知识库是好东西，但是为什么很多国内的软件公司都没有呢？
首先，建设知识库需要成本，主要是人力成本；
其次，知识库的建设需要一个较长的周期，才能到达一个能产生收益的临界点。
管理层来看，简单的说，就是在现在投入成本去建设一个未来（不知何时）能带来一定收益（无法详细估算）的东西。这种东西对于管理层（尤其是营收压力比较大的管理层）来看是没有任何诱惑力的。所以很多公司宁愿把成本花在招人也不花在知识库的建设上

铁打的营盘流水的兵。。公司要发展人来人往的什么也不管的话应该是成长不起来的。如果想要发展短时间的痛一下的话忍一忍就过去了吧。。。


呵呵，果然楼主是刚毕业没多久的，对管理层很乐观的话，可以把你的意见提上去，看看Boss怎么答复。

Boss问你下面这几个问题，你怎么回答？
建设这个要花多少资源？
多长时间后能带来收益？
能带来多少收益？相比投入利润有多少？
风险有哪些？
如果投入石沉大海后，责任谁来承担？


这个问题我已经遇到过了，我的BOSS到没有让我统计这些，可能他自己有一些对比吧。

以上的这些问题要回答的话，统计数据也不是很困难的一件事情。至于说组织上看完统计数据之后没有接受我的提案，那也应该不是这件事情不能做，只是事情有轻重缓急、权衡之下没有做而已。

然后就是关于知识库的建设问题其实也并不是一定就是这个样子的，我只是提出了自己的一些看法，如果这样做给公司带来了非常大的负担，导致公司运作产生一系列的问题的话，那么不做也罢。这个其实也是看决策者的。我觉得。。。

但是貌似“如果投入石沉大海后，责任谁来承担？”这种问题没有什么讨论的必要。如果我是决策者，那么责任就是我来承担。


知识库的话，不同类型的文档应该有不同的组织方式。比方公司文档和 CMMI 文档的组织方式和公司内部项目的 API 文档就不一样。最糟糕的情况就是创建一堆的目录，文档只管往里面丢，既不提供索引和查询，文档之间也没有链接，这样的知识库简直就是知识的坟墓。

我个人建议将 wiki 作为基本架构，可以链接到各种不同的资源去。参考一下 Mozilla Developer Center，它本身就是一个知识库。


知识库的话题我很有兴趣讨论，但是看了楼主的帖子，我很悲哀。
首先楼主所在的公司是典型的cmm企业，或者叫混乱而无序的人力密集型企业。在这样的企业中高度存在着无序的软件开发过程和充满不稳定的人际关系，而知识库的建立显然没有一个好的基础资源支持。
楼主很年轻，而且不从事第一线的开发工作。从根本上说其自身能力和资源配属就不可能完成持续的知识库的建立。
第三，楼主对于知识库的作用认识还很不清楚，有片面夸大知识库作用的倾向，希望以知识库代替人和组织的工作。
第四，知识库本身的建立应该是在知识积累和归纳的基础上，而不是建立在文档的积累和归纳的基础上的，严格的说知识库是反文档化一套运行支持系统。