[转]关于公司级别的知识库的建设的一些看法。
从毕业到现在，在软件这一行做了接近一年的时间了。现在对于在公司内部建设一个健全的知识库的体系有一些看法。
公司现在正在准备CMMI3级方面的一些建设。平时也搞一些CMMI方面的培训。
在软件生产过程的改进方面，公司要产生大量的过程文档，规范软件开发的过程。
同时，就在想，能不能在规范这个过程的同时，建设起来公司自己的一个知识库呢？
首先就是为什么要建设这个知识库：
所谓的知识库，就是对知识进行管理。现在一般的作外包的软件公司，人员的流动性比较的大。通常是有新人一批一批的进来。老员工也会有一定程度上的流失。在没有一个好的知识管理的情况下，无形当中造成了比较严重的知识的流失。每一次新人的培训都要花费公司比较大的精力。而且没有一个比较统一规范的培训过程。在培训这一方面的花费不说、很多在做项目的时候遇到的一些特殊问题的解决方法也不能再没有知识库的情况下得到有效的积累。等到后面又来了新的项目的时候，往往很多东西还得再来一遍。浪费很多的时间，也就是钱。所以除了软件开发过程文档以及规范以外，对于软件开发的一个公司组织级别的知识库也是 比较有必要的。
然后是需要讨论一下公司的这个知识库的组织形式。在我看来，这个知识库需要有几个方面的功能。
其一：组织库能够收集公司在培训、项目当中属于公司自己的那一部分知识并且可以加以保存归纳。在以后的培训和项目中可以方便的进行有体系的查询及获取。
其二：组织级的库能够回答新人或者老员工在不熟悉的领域遇到的问题。然后加以整理。
其三：组织级的库能够收集一些源代码级别的属于公司自己的问题解决方案，在以后的其他项目中可以凭借这些轻易的完成一些工作。
其四：组织级别的库如果能够有行业中一些开源的框架和代码的使用积累，就更好了。这个开源不是指STRUTS之列的大家都知道的东西，而是指在一些领域有特别的功用的一些处理方式。大家都认可的处理方式。
其五：建立起来公司内部的组件级别的知识库。
这对以上的一些观点和需求，考虑了一下实现的方式：
1、 在文档类型的知识库的组建上面，可以采用weiki的方式进行组建。不过这样的话，可能需要专门的人员负责进行收集组织和归纳。然后也要号召公司的员工进行知识的贡献。然后就是在项目的开发过程中间增加一条过程，那就是项目的问题解决方案的收集。
2、 在源码和组件级别的知识库的组建上面，需要结合文档知识库以链接的方式给出源码和组建的使用方法、心得以及源码组件本身。
上面的这些想法可能有很多的不合适的地方，请大家指教。谢谢。
公司现在正在准备CMMI3级方面的一些建设。平时也搞一些CMMI方面的培训。
在软件生产过程的改进方面，公司要产生大量的过程文档，规范软件开发的过程。
同时，就在想，能不能在规范这个过程的同时，建设起来公司自己的一个知识库呢？
首先就是为什么要建设这个知识库：
所谓的知识库，就是对知识进行管理。现在一般的作外包的软件公司，人员的流动性比较的大。通常是有新人一批一批的进来。老员工也会有一定程度上的流失。在没有一个好的知识管理的情况下，无形当中造成了比较严重的知识的流失。每一次新人的培训都要花费公司比较大的精力。而且没有一个比较统一规范的培训过程。在培训这一方面的花费不说、很多在做项目的时候遇到的一些特殊问题的解决方法也不能再没有知识库的情况下得到有效的积累。等到后面又来了新的项目的时候，往往很多东西还得再来一遍。浪费很多的时间，也就是钱。所以除了软件开发过程文档以及规范以外，对于软件开发的一个公司组织级别的知识库也是 比较有必要的。
然后是需要讨论一下公司的这个知识库的组织形式。在我看来，这个知识库需要有几个方面的功能。
其一：组织库能够收集公司在培训、项目当中属于公司自己的那一部分知识并且可以加以保存归纳。在以后的培训和项目中可以方便的进行有体系的查询及获取。
其二：组织级的库能够回答新人或者老员工在不熟悉的领域遇到的问题。然后加以整理。
其三：组织级的库能够收集一些源代码级别的属于公司自己的问题解决方案，在以后的其他项目中可以凭借这些轻易的完成一些工作。
其四：组织级别的库如果能够有行业中一些开源的框架和代码的使用积累，就更好了。这个开源不是指STRUTS之列的大家都知道的东西，而是指在一些领域有特别的功用的一些处理方式。大家都认可的处理方式。
其五：建立起来公司内部的组件级别的知识库。
这对以上的一些观点和需求，考虑了一下实现的方式：
1、 在文档类型的知识库的组建上面，可以采用weiki的方式进行组建。不过这样的话，可能需要专门的人员负责进行收集组织和归纳。然后也要号召公司的员工进行知识的贡献。然后就是在项目的开发过程中间增加一条过程，那就是项目的问题解决方案的收集。
2、 在源码和组件级别的知识库的组建上面，需要结合文档知识库以链接的方式给出源码和组建的使用方法、心得以及源码组件本身。
上面的这些想法可能有很多的不合适的地方，请大家指教。谢谢。
评论
简单的说，对事不对人，如果buaalijie的理论在我的公司，会把大家带的做一些对开发无益的事。如果o6z的理论在我的公司，大家会把这个理论当作老大，但是不会有人去搞任何事。
所以，还是o6z的理论好点，起码不会做太多无益的事情。
差不多有同样的感觉，个人认为做什么事情都是从[开始]开始的，路是要一步一步走的。如果[老太太的仓库]尚且没有，我们在什么地方来发挥我们的管理作用呢，我们学一大堆的管理方法在什么地方实践呢？
一点个人建议--
有点规模的公司Portal和SharePoint可以做平台，知识管理垂直+水平。垂直的结构：组织单元A->A下属组织单元B->B下属项目；水平的结构：专业知识社区，跨多组织单元的项目...
每个项目内部的知识管理，项目经理可根据知识管理平台提供的功能按自己的习惯风格和项目的实际性质组织和管理
Charon提到的自上而下未必绝对，上家公司我们从4人的小team发展到40个人的部门，从最开始只有4人用的team portal，到后来发展演进成部门portal,包含了部门制度，部门公告，部门内所有项目文挡管理，知识社区，娱乐社区.....，到后来公司经理觉得这个东西好，要求其它部门都必须有这么个东西...
相比较而已，bug管理系统是属于那种必须写的。而wiki则是完全可能看大家的自觉性。
有的team会写得勤快些，有的则更新比较慢。
光wiki就有好几个在跑。因为以前的功能不够，所以后来又买了confluence，但迁移知识则是比较麻烦的。
知识库的建立必须是高层推动,并且与员工考核紧密结合的. 否则,往知识库里面提供素材的就只能是雷锋同志,难以持久.
而且,知识库也不是单独存在的.我们现在基本上是以trac为项目管理的核心平台,需求/bug/知识点都是围绕在这个上面,与svn也有一个比较好的接口.
"黑猫白猫,抓住老鼠就是好猫",我这种思维有可能太肤浅,但我想这也是最实际的.首先我们可以先定义出知识库的范围和用途,比如第一步,我就是用来收集公司在软件开发过程中形成的经验\资料\技术改进,之后再一步步深入.就像软件开发一样,迭代进行.毕竟在没有经验时,我们只能尝试.
最后我想问下ozzzzzz老师,当知识库建立后,如何让知识库具有人气,大家能形成互动,让知识能长久,持续的传递.
知识库不需要人气，特别是公司级别的知识库应该是隐形的。也就是说这个只是库，应该是同项目管理工具，bug管理工具，需求跟踪工具，等其他工具结合在一起，并在后台起作用的。
说实际的事情，办实际的事情，起实际的功效，也就是一切以实际出发。而另外一些的问题根本就在于不能解决实际的问题，而只是他们希望能够解决实际问题。这里我们必须明确，该是什么问题，就解决什么问题。人员流动显然是一个管理的问题，企业文化的问题，你觉得使用知识库来解决，仅仅就是一个肤浅可以表达的，难道这就是最实际的？
而所谓定义知识库的范围，绝对是和企业的生产流程以及企业规划，并且直至企业文化、战略目标相关联的。而且在我看来，你的开放过程可以迭代，但是你的管理的修改却不能迭代，至少不能经常性的去迭代。这就是最大的实际。只有这样你的做法才能落地。
最后我还要明确一点的是，知识库不是为了知识可以长久保存（档案库才是作这个的，而按照他们的行为方式，知识库最终也仅仅是会成为一个档案库），而是应该将知识的新陈代谢纳入一个具体的规划，并且促进旧知识的淘汰，新知识的总结。而知识库的使用应该更多是间接的，因为工作中遇到的问题，更加应该依靠生产管理和技术问题去解决。这一点你也可以从惠普等已经建立了知识库的组织看到，他们大多数都是使用知识库来作培训和知识更新。而知识传递效率的提高，唯一有效的方法就是建立一个更加个性化的方言系统。
"黑猫白猫,抓住老鼠就是好猫",我这种思维有可能太肤浅,但我想这也是最实际的.首先我们可以先定义出知识库的范围和用途,比如第一步,我就是用来收集公司在软件开发过程中形成的经验\资料\技术改进,之后再一步步深入.就像软件开发一样,迭代进行.毕竟在没有经验时,我们只能尝试.
最后我想问下ozzzzzz老师,当知识库建立后,如何让知识库具有人气,大家能形成互动,让知识能长久,持续的传递.
首先我们必须要对CMM的一些背景问题作分析，这是因为这个问题表面上不涉及cmm，但是很多人的思考问题的过程和分析问题的方法，都是受CMM强烈影响的。我们这里只需要对一个方面的问题进行思考，CMM究竟衡量软件开发能力的，还是衡量软件开发过程中质量相关要素的，还是衡量软件开发工作质量的。而回答这个问题后，大家必须要明白问题都具有领域，而解决问题的最佳方式是在这个领域中作出针对性的解决，而相关领域的方法仅仅是一种优化。
回到知识库这个问题，是首先要解决什么是知识，然后要分析知识如何才具有价值，接着是分析如果增值这些价值，而具有价值的知识是如何被得到是使用的需要建立一个可以观测的流程。同时我们还要知道，知识是必须建立淘汰机制的，也就是说当一个知识已经被众多人所知晓和使用之后，就必须将其固化为一个不依靠个人的解决工具，从而淘汰旧的建立新的。如果这个工具具有使用范围，范围的大小决定其下一步的具体形态。当范围大到一定阶段的时候，这个知识将形成一种模式，而范围小到一定程度的时候则程序化为一种库函数化的被包装的黑盒实体。也就是说知识最终的结果都是被物化为一种方法或者一种具体化的工具。这些都是在知识库建立中需要考虑的问题。
知识库作用是不可否认的，这点O6Z也没否认。而另外的一个问题，其实是说建了文档库或者Wiki就把叫做知识库的做法的问题。如果再深入一些，更主要的问题，什么才叫做知识，如果不知道什么叫做知识，那么建再多的库都不知道自己在建什么。事实上，本人真的不知道什么叫做知识。
所以，建议buaalijie不如说建立一个交流的平台，否则，“知识库”这么大的命题给别人质疑你带来了很大的机会。包括你后面对这个东西的推广，如果在公司内部有人质疑你的成果，你如何证明你做的是对的呢？如果不能证明这件事是对的，如何能得到老板支持，又如何能够推广呢？
对于buaalijie提到的“书本是否还需要印刷”，从极端环保的观点是“不要”，从文明延续的角度，我觉得“只要不是抄袭的，都可以印”，从我个人的观点，“随便你，反正我不看”
其实，对自己的内部需求，和我们在项目前期和客户沟通建立数据仓库应该有些类似的，很多客户想上来就要数据仓库，其实讨论下来，不要说数据仓库、数据集市，连报表汇总都很难说清楚。
建议先从小处实际入手：
对新员工的话，是否已经有明确的入手指导(文档、事例、例程等等)？还是实际只能口口相传？(那种让人看不明白的文档当然是不能不算的，但也不是说希望新人只是看文档就能明白一切)
BTW:对CMM实现，我认为，国内企业在成本上是很难真正实现的。很明显的问题就是，客户不买单的实际问题。
首先:
关于中毒的这样一个说法的前提是CMMI是毒药。就是说这是一个不好的东西。我认为这种看法过于偏激。
没有十全十美的事物。从任何一个方面来讲，说一个东西完全是错的都不对。更何况是一个经过很多人验证实施而且取得了成效的东西。具体的问题我们后面再讨论。
第一点，所谓成熟的软件开发过程根本就不存在，这一点在我的关于cmm的几个讨论贴已经有所陈述，这里我想做个提示。实际上软件开发过程应该是高度适应开发的具体软件，而不是相反，所谓没有银弹。而进一步说具体被开发的软件，如果有高度相似性，则其开发的过程则也就具有高度相似性。而只有如此，才可能具有cmm所要求的最基础的稳定性。而恰恰由于软件的知识熟悉，也就是低生产成本，高开发首产品成本的属性，不断的建造具有高相似性的软件，本身就是一件反软件开发基本原理的事情。而cmm所强调的所谓成熟度，实际上就成为了软件开发能力的相反。这一点同我所分析的cmm各个级别的内在要素实际上是相反的结论相符合。
一段话讲得倒是很有“大道理”。但是，（可能我的看法也很偏激）我觉得ozzzzzz可能自己并没有十分的了解CMMI中“成熟的软件开发过程”的说法的意思。成熟的软件开发过程的重点在于“过程”，而非是指“软件”。举一个例子。（简单的过程定义）
一个公司做的是对日的项目。长期的两地协作开发。需要一个有效的，稳定的沟通 协作开发的过程。那么“异地联络方式”“BUG处理方式”等等都是需要决定的，如果公司在这一方面已经很有经验了，有一套成熟的异地协作开发模式，以及相关的交流用的文档和过程文档，那么按照CMMI的思路，把这样的一套方法定义完成，在组织级别推广开来，使公司在这一方面所消耗的资源达到最小。（题外话，貌似敏捷的开发方式的目标是要消除浪费，不知道这样讲对不对。）那么在实践之后，这个过程被确定下来，并且在实施过程中在不断的加以完善。 这样就完成了在沟通方式上面的一个过程的定义。
但是，需要指出的是：“优质过程的复用”，不等同于“相似性的软件再造”。“方法”和“结果”是两个东西。同样的。CMMI所要求的稳定性也在上面的例子中也体现出来，要求的是过程的稳定，和做的项目，出的软件成果是没有关系的，事实上就是不管什么样的软件项目，如果需要异地的协作开发，好的交流方式总是合适的。（虽然执行的时候根据项目的规模等等所要求的力度不一样。但是规则并不等于没有变通，CMMI其实是有很完善的调整机制的。）说了这么多，就是想说明一个事情：“能力成熟度模型”指的是：“做事情的方法上的成熟”，而并非“建造具有高相似性的软件”。做事的手段和我正在做什么事情是扯不到一起的。
可能就有这样一个问题，你建立这个知识库，收集那么多的资料，不就是为了复制么？答案是：“知识库让你站在前人的肩膀上”。现在的科学家们都站在牛顿时代的科学家的肩膀上。
实际上也就是说表面上稳定而条理化的cmm开发过程，其实是内在混乱的开发方式。这一点在国内众多的cmm企业实际上已经显露的很明显了。楼主所说的“工作一年也是什么活儿都干的，编码、测试、设计。”，就是一个很好的例子。
基于前面的理由这样一点是不成立的，至于国内的企业内部的混乱，我认为是人的问题。以人为本，总是强调这个，出了问题就不强调了，开始找制度的问题，典型的逃避责任。至于我说的什么都干，我一个新手，什么都不会，不什么干一些，了解一下行业的整体状况，我觉得是十分应该的。
说点题外话，实际上开发过程的不稳定性，并不排斥针对开发过程的开发具有稳定性。这也就是敏捷存在的基础，也就是我多次强调的敏捷很多时候更加是一种思想，而不是一种开发过程。
认清这一点，就可以理解实际上面向开发过程的辅助知识库，应该是一种提供对开发过程开发调整的知识系统，而不是面向开发的过程系统知识库。有点绕口，但是意思还是可以理解的。
我赞同一种观点，“在过程中消除浪费。”忘了在哪儿看见谁说的了。 在这一点上，其实和我前面讲的差不多。“对开发过程开发调整的知识系统”这个在CMMI中由EPG来执行。“面向开发的过程系统知识库”这个里面收集的应该是对于每一个过程的最佳实践。还是举个例子，接上面的例子。
异地开发模式，交流的时候可能需要一些文档，（不要告诉我打个电话给你就行了，你全部记住了，绝对不会有问题。软件开发当中最重要的的确是人，但是最不可靠的也是人，这个不关乎于人的能力的强弱），那么怎样来写这样的文档，在文档中部署一些什么样的交流地内容，怎样才能让所有的相关人员一看就明白，怎样才能保存证据？（做软件的也是要挣钱的，而交流的内容多半关乎到你能拿到多少钱，口头上的证据是没有效果的）。如果双方有一个成熟的交流过程了，在过程文档库中有大家都使用的文档，那么这一点很容易就能完成。
就好像做项目的时候讲这个：“hibernate”那个“spring”，还有什么“ROR”，这些东西其实也是最佳实践。（顺便提一下，不要说没有什么最佳实践。）
第二点，知识库的建立应该是谁的职责？实际上基本的cmm教学就已经明确阐述了，cmm的建设应该是由高层推进的。而知识库，特别是开发过程面向的知识库，更加应该如此。
而企业知识库的建立绝对不是一个团队所能够完成的，实际上可以说根本就不是一个企业所能够完成的。一个面向开发的知识库，必须建立在软件利益相关责任人的共同参与。而这项工作，只能在开发主体的高层大力推动下才可能进行。也就是说，不管一个人学习能力再强，只要其不具备企业决策职位，就不可能真正的推进此知识库的建立。
光是高层的推动，所有的人当你不存在就好了。光是一个公司搞，其他公司站在那儿冷笑就好了。只有大家都重视，事情才能办好。从来就没有想过一个人可以把这个搞起来。（题外话：关于“The one”这个问题，我再三强调我是一个人本主义者，而正是由于我是人本主义者，所以我才说我们不需要“The one”----救世主）而且我也说了，我只是提出这样一件事，让大家讨论讨论。
第三点，人是任何工程学的核心要素，抛开人的工程学就是伪工程学。而所谓人员流动性过大的问题，恰恰是开发过程混乱的一个显著特征，也是管理能力低下的显著特征。而在一个管理能力和开发过程都存在这样严重问题的组织内，希望通过建立一个知识库来挽回局面，显然是没有抓住主要矛盾。
偏激的观点，明显的带着有色眼镜看人。“人是任何工程学的核心要素”没有错，“而所谓人员流动性过大的问题，恰恰是开发过程混乱的一个显著特征”这一点毫无根据，人的去留和公司的各个方面以及自己的各个方面都有关系，说是开发过程混乱的显著特征明显的就是信口雌黄。“也是管理能力低下的显著特征”倒是可以说也许是一个方面。“希望通过建立一个知识库来挽回局面，显然是没有抓住主要矛盾。”这个则是属于完全的臆测。小孩子都知道要全面发展。
第四点，所谓知识库是反文档的。这里需要我们大家对知识库的基本概念有最基本的理解。简单的说，知识库不是知识的数据库，而是知识的数据仓库。
同时我们还需要理解什么是知识。知识来源于经验，是可以被传递的经验。经验来源于人的实践，被传递也是在人之间进行。所谓企业的知识积累，实际上应该是企业中集体人群的知识共同积累。而由于知识的传递性，保证其效率则成为基本的要求。而大家看到人月神话里面强调外科手术团队的建设，也就有这个方面的因素。
通过文档传播知识无疑是一种有效率的扩展方式，但是我们也应该明白温伯格的“稀薄的果酱”的道理。而作为一个开发企业，知识的传递并不是以扩大知晓面为前提，而是应该以加深知识传递效率为前提。
同时我们还应该注意，知识的来源是经验的沉淀，而经验的载体只能是人。而扩大知识产生的一个最有效方式，也就是扩大经验的积累，明白的说就是稳定人员构成的长期存在。
而文档由于其同步性的先天性不足，其投入的资源必须得到最严密的控制。也就是说，文档必须控制在刚刚好的地步，才可能将其维护成本控制住。否则看似无关痛痒的一个小小冗余，就会造成后期维护的数量级的递增。而随着对知识的积累的进行，文档的数据将会逐步减少，理想化的情况是降低为“0”成本付出，也就是没有任何文档。
我只是想问一下：“书本是否还需要印刷？”
知识库可能需要一定的人力来维护，需要耗费资源，但是我认为这比，在主要技术人员更动，重新摸索来得快，效率高；原理跟写好一个程序的注解一样。其实internet就是一个大知识库，不知道反对者是否使用google来查询需要的资讯。知识库其实就是每个公司自己的特殊方向的信息库。
其实作为一项结论性的观念大家必须时刻牢记。软件开发是一项人的智力产品生产，软件工程是一个工程学科，这里唯一真正存在的要素只能是人，妄图抛开“The one”这个要素的做法，都是违背基本的原理，实际上也是违背基本的人类道德底线的。
前面已经解释过，在这儿只想说：“对不起，让你误解了”。
实施知识库,需要公司有制度保障,否则大家都没有劲头(我现在就是这样,搭了一个media wiki,没用起来),
采用积分制,定期评选,也可以和考核机制挂钩.
另外就是,公司越大, 越有建设的必要,让知识流动起来,而不是孤岛.
楼主如果有什么好的知识管理工具,可以交流一下,我目前在试用confluence.
我现在也没有什么好的知识管理工具。
最后想说一些自己的观点：人不是生下来就会跑的，没有人敢说没有文档我可以做得比你好（当然，你说的对象不是我，是和你有同等资历能力的人）。而且XP与敏捷确实不失为好的方法或者说思想，但是和CMMI一样，需要正确的认识。而不是一棍子打死。其实敏捷所要求的团队的能力水平不是现在国内的软件开发团队都具有的。国内大部分的团队如果硬要敏捷，抛弃过程的话，我觉得会死的比较难看。
扯了这么多，突然发现和知识库越来越远了。。。。。。
我觉得应该这样问：
知识库到底该不该建设？
如果建设的话，应该怎么建设？
如果不建设的话，为什么？
首先，建设知识库需要成本，主要是人力成本；
其次，知识库的建设需要一个较长的周期，才能到达一个能产生收益的临界点。
管理层来看，简单的说，就是在现在投入成本去建设一个未来（不知何时）能带来一定收益（无法详细估算）的东西。这种东西对于管理层（尤其是营收压力比较大的管理层）来看是没有任何诱惑力的。所以很多公司宁愿把成本花在招人也不花在知识库的建设上
是的,还不如建立一个自己的知识库.
呵呵，人民币严重贬值后就会这样
知识库可能有东西不是你需要的，如果从来没人需要，就是知识库这个机制没有建立好。找到需要的东西，可以运用搜索技术什么的。
不知道"什么注释是一种味道"，请解释， :-)
而且我认为注释永远不会消失。
我还是认为这个东西不是什么新鲜概念，都是些想赚钱的公司，造出来的一些概念而已，显得十分高深，背后的道理千年来一直都有，也就是换个实现方法。我不知道如何让知识库知道你需要什么，而避开人的主动性，可能这个有点高深。我一直认为，知识库的执行实施需要人参与，这个是最最关键的难点，由于人性的弱点，如何让人们能够共享自己的知识，同时让大家互相获得好处，这个才是关键。武打小说里面为什么会有秘籍，都是自私惹的禍。因此知识库的建立，其实重点已经不是实现他的技术本身了。如果大家都是10几万一个月，大家都是衣食无忧，工作都是兴趣爱好的话，那样建立知识库将是个简单的事情。
首先楼主所在的公司是典型的cmm企业，或者叫混乱而无序的人力密集型企业。在这样的企业中高度存在着无序的软件开发过程和充满不稳定的人际关系，而知识库的建立显然没有一个好的基础资源支持。
楼主很年轻，而且不从事第一线的开发工作。从根本上说其自身能力和资源配属就不可能完成持续的知识库的建立。
第三，楼主对于知识库的作用认识还很不清楚，有片面夸大知识库作用的倾向，希望以知识库代替人和组织的工作。
第四，知识库本身的建立应该是在知识积累和归纳的基础上，而不是建立在文档的积累和归纳的基础上的，严格的说知识库是反文档化一套运行支持系统。
o6z有点偏激了吧,尤其是第三条. 知识库的价值是显而易见的, 不知道o6z有没有具体的知识库解决方案.或者说能实施的路线图,包括工具,方法,制度保证等
1，有多少东西是网上查不到的，必须搬到自己的知识库中；如果网上的资料就很全，为何不用网文快捕之类的软件做成一个专题书籍呢？这样省时省力。
2，公司有多少人愿意喜欢写文档，如果强制要求会有多大效果？wiki真的合适吗？
3，培训资料的整理还是很有必要的；这个的工作量不大
4，学习的成本代价也很高，还是老人带新人好；有效果也容易实施；公司应该完善这方面的制度
5，我先问一下楼主，个人的知识库的建设有什么心得？
说的是啊,知识库里的内容应该是使用频率高的,不容易获得的,也可能是零散的,否则都去整理知识,没人干正事了.
个人知识库我是用mybase管理的,网络资源我使用得乐书签,一点经验.
知识分为显性知识和隐性知识。显性的知识是可以通过wiki来记录的，我感觉
软件开发企业最需要知识库了,说的好听点,我们都是知识工人,依靠这些来创造价值.
wiki最起码在以下几个方面体现价值:
1. 信息共享,比如faq,文档资料,通讯录.这样大家在一个地方积累,很多问题不需要互相询问了.
2. 积累领域知识.
3. 作为项目组的沟通工具.
实施知识库,需要公司有制度保障,否则大家都没有劲头(我现在就是这样,搭了一个media wiki,没用起来),
采用积分制,定期评选,也可以和考核机制挂钩.
另外就是,公司越大, 越有建设的必要,让知识流动起来,而不是孤岛.
楼主如果有什么好的知识管理工具,可以交流一下,我目前在试用confluence
当然不是所有知识都是只通过人于人之间的之间交流传递的,但是请注意就软件开发能力来说,还就是处于原是社会。作为一个技术人员，一个最核心的特点是起社会的属性，也就是其在一个团队game中所进行的行为。而其是否积极，是不是愿意尝试新技术，是不是在不断的提高自己，是不是会闭塞，这很大程度上是受其团队文化的影响，而进一步说企业文化的偏见必然导致个人技术的偏见。
显然是没有解决好几个逻辑的问题。
第一如果主要技术人员不更动，这个资源的付出，是不是一种浪费？
第二如果主要技术人员必然会更动，那么究竟是在什么时候更动，是否有能力避免这个更动？
第三如果这个更动是不可避免，那么是否建立一个知识库是最便宜的选择？
天要下雨，人要嫁人。知识库是一个比较便捷的尝试。
但是是不是最便宜的呢？企业经营的目的是什么，动机是什么，驱动是什么？难道是柿子捡软的捏，活捡容易的干？
而恰恰很大程度上来说，如果知识库沦落到程序的注释的田地——注释本身就是一种味道，这个知识库的建立的动机，本身就说明这个企业有着基础性的文化和开发方法的缺陷。
知识库是起到一个辅助作用。我打个代码注解的比方，只是一个比喻而已。建立一个知识库，类似于建立一个事件，过程的注解。例如，建立一个病人档案系统，其实也是一个知识库，实习医生，可以根据这些信息，学习到一些知识。注解本身是程序的知识库，目的是让人明白你的程序干什么，也是一种知识的传递。
注释是一种味道，这个意思你是不是明白？程序的知识库永远也不会是注解，因为注解永远是应该被清除的。
至于所谓的病案系统，严格意义上是一个档案系统而不是知识库。本质上的区别，展示了你对于知识工程的看法的立场。
internet怎么会是一种知识库？假若真的是一种知识库，那么你还有什么必要建立自己的知识库呢？
而且最关键的是，以这种方式和动机建立起的知识库，必然会走向类internet，这个时候究竟是知识工程的进步还是后退呢？
某种程度可以这么认为，它能提供给我需要的东西，迅速而便捷，只是它不是针对某个专业领域，因此需要企业针对他们的业务领域建立特定的。
既然如你所说是针对企业的业务领域，而internet也很便捷，那么你完全可以选择一种搜索方式，而不是建立一个自己的知识库。所谓作最便宜的选择。
关键其实还是在于对知识库的基础概念的认识问题，或者是是最基本的生产活动的认识问题。为什么一个老太太天天在家里积攒的不知道猴年马月才能排上用处的杂物，不能被称为仓库就是这个道理。因此我在一次强调，知识库不是知识的数据库，而是知识的数据仓库。
而一旦公司的知识库按照老太太的思路建立起来，起本身就必然会成为一个信息库，而不是知识库。
也许是知识库定义太狭窄，而我没有认识透彻。不管知识库，知识仓库，目的是提供一个知识信息传递平台而已，能够将前人的知识很好的继承传递；在我需要得到信息的时候能够得到，而不是自己去摸索，我觉得他的功能已经达到了。我没必要去研究万有引力，因为书上都说了；我看营销书籍，学习营销手段。书就是一个传统的知识库，只是现在把知识库放进电脑，用现代方法进行处理，提高效率而已。其实就这么简单，没什么高深的技术，模式，思维。
知识库的建立绝对是一门高深的技术，需要使用复杂的思维方法，推导和分析出不断自我完善的模式。
知识库的作用，不是在于存储知识，而是在于对经验进行分析和归纳。知识库的目的不是在于传递知识，而是对知识的传递方式作出优化，对知识内容作出规例，对知识的积累作出指引，也就是说知识库是知识传播平台的一种制定系统或者制定方式，而非知识传播平台本身。
同时请注意，知识库绝对是一种信息的新型承载方式，而不是传统意义上的书的扩展或者现代化的包装。因为无论从什么意义上来说，书都不会主动的提供给你需要的知识，而不需要你自己去摸索。
所以我才一再强调，知识库是知识的数据仓库而不是知识的数据库。
当然不是所有知识都是只通过人于人之间的之间交流传递的,但是请注意就软件开发能力来说,还就是处于原是社会。作为一个技术人员，一个最核心的特点是起社会的属性，也就是其在一个团队game中所进行的行为。而其是否积极，是不是愿意尝试新技术，是不是在不断的提高自己，是不是会闭塞，这很大程度上是受其团队文化的影响，而进一步说企业文化的偏见必然导致个人技术的偏见。
显然是没有解决好几个逻辑的问题。
第一如果主要技术人员不更动，这个资源的付出，是不是一种浪费？
第二如果主要技术人员必然会更动，那么究竟是在什么时候更动，是否有能力避免这个更动？
第三如果这个更动是不可避免，那么是否建立一个知识库是最便宜的选择？
天要下雨，人要嫁人。知识库是一个比较便捷的尝试。
而恰恰很大程度上来说，如果知识库沦落到程序的注释的田地——注释本身就是一种味道，这个知识库的建立的动机，本身就说明这个企业有着基础性的文化和开发方法的缺陷。
知识库是起到一个辅助作用。我打个代码注解的比方，只是一个比喻而已。建立一个知识库，类似于建立一个事件，过程的注解。例如，建立一个病人档案系统，其实也是一个知识库，实习医生，可以根据这些信息，学习到一些知识。注解本身是程序的知识库，目的是让人明白你的程序干什么，也是一种知识的传递。
internet怎么会是一种知识库？假若真的是一种知识库，那么你还有什么必要建立自己的知识库呢？
而且最关键的是，以这种方式和动机建立起的知识库，必然会走向类internet，这个时候究竟是知识工程的进步还是后退呢？
某种程度可以这么认为，它能提供给我需要的东西，迅速而便捷，只是它不是针对某个专业领域，因此需要企业针对他们的业务领域建立特定的。
关键其实还是在于对知识库的基础概念的认识问题，或者是是最基本的生产活动的认识问题。为什么一个老太太天天在家里积攒的不知道猴年马月才能排上用处的杂物，不能被称为仓库就是这个道理。因此我在一次强调，知识库不是知识的数据库，而是知识的数据仓库。
而一旦公司的知识库按照老太太的思路建立起来，起本身就必然会成为一个信息库，而不是知识库。
也许是知识库定义太狭窄，而我没有认识透彻。不管知识库，知识仓库，目的是提供一个知识信息传递平台而已，能够将前人的知识很好的继承传递；在我需要得到信息的时候能够得到，而不是自己去摸索，我觉得他的功能已经达到了。我没必要去研究万有引力，因为书上都说了；我看营销书籍，学习营销手段。书就是一个传统的知识库，只是现在把知识库放进电脑，用现代方法进行处理，提高效率而已。其实就这么简单，没什么高深的技术，模式，思维。
知识库可能需要一定的人力来维护，需要耗费资源，但是我认为这比，在主要技术人员更动，重新摸索来得快，效率高；原理跟写好一个程序的注解一样。其实internet就是一个大知识库，不知道反对者是否使用google来查询需要的资讯。知识库其实就是每个公司自己的特殊方向的信息库。
当然不是所有知识都是只通过人于人之间的之间交流传递的,但是请注意就软件开发能力来说,还就是处于原是社会。作为一个技术人员，一个最核心的特点是起社会的属性，也就是其在一个团队game中所进行的行为。而其是否积极，是不是愿意尝试新技术，是不是在不断的提高自己，是不是会闭塞，这很大程度上是受其团队文化的影响，而进一步说企业文化的偏见必然导致个人技术的偏见。
而说
第一如果主要技术人员不更动，这个资源的付出，是不是一种浪费？
第二如果主要技术人员必然会更动，那么究竟是在什么时候更动，是否有能力避免这个更动？
第三如果这个更动是不可避免，那么是否建立一个知识库是最便宜的选择？
而恰恰很大程度上来说，如果知识库沦落到程序的注释的田地——注释本身就是一种味道，这个知识库的建立的动机，本身就说明这个企业有着基础性的文化和开发方法的缺陷。
internet怎么会是一种知识库？假若真的是一种知识库，那么你还有什么必要建立自己的知识库呢？
而且最关键的是，以这种方式和动机建立起的知识库，必然会走向类internet，这个时候究竟是知识工程的进步还是后退呢？
关键其实还是在于对知识库的基础概念的认识问题，或者是是最基本的生产活动的认识问题。为什么一个老太太天天在家里积攒的不知道猴年马月才能排上用处的杂物，不能被称为仓库就是这个道理。因此我在一次强调，知识库不是知识的数据库，而是知识的数据仓库。
而一旦公司的知识库按照老太太的思路建立起来，起本身就必然会成为一个信息库，而不是知识库。
知识库可能需要一定的人力来维护，需要耗费资源，但是我认为这比，在主要技术人员更动，重新摸索来得快，效率高；原理跟写好一个程序的注解一样。其实internet就是一个大知识库，不知道反对者是否使用google来查询需要的资讯。知识库其实就是每个公司自己的特殊方向的信息库。
第一点，所谓成熟的软件开发过程根本就不存在，这一点在我的关于cmm的几个讨论贴已经有所陈述，这里我想做个提示。实际上软件开发过程应该是高度适应开发的具体软件，而不是相反，所谓没有银弹。而进一步说具体被开发的软件，如果有高度相似性，则其开发的过程则也就具有高度相似性。而只有如此，才可能具有cmm所要求的最基础的稳定性。而恰恰由于软件的知识熟悉，也就是低生产成本，高开发首产品成本的属性，不断的建造具有高相似性的软件，本身就是一件反软件开发基本原理的事情。而cmm所强调的所谓成熟度，实际上就成为了软件开发能力的相反。这一点同我所分析的cmm各个级别的内在要素实际上是相反的结论相符合。实际上也就是说表面上稳定而条理化的cmm开发过程，其实是内在混乱的开发方式。这一点在国内众多的cmm企业实际上已经显露的很明显了。楼主所说的“工作一年也是什么活儿都干的，编码、测试、设计。”，就是一个很好的例子。
说点题外话，实际上开发过程的不稳定性，并不排斥针对开发过程的开发具有稳定性。这也就是敏捷存在的基础，也就是我多次强调的敏捷很多时候更加是一种思想，而不是一种开发过程。
认清这一点，就可以理解实际上面向开发过程的辅助知识库，应该是一种提供对开发过程开发调整的知识系统，而不是面向开发的过程系统知识库。有点绕口，但是意思还是可以理解的。
第二点，知识库的建立应该是谁的职责？实际上基本的cmm教学就已经明确阐述了，cmm的建设应该是由高层推进的。而知识库，特别是开发过程面向的知识库，更加应该如此。
而企业知识库的建立绝对不是一个团队所能够完成的，实际上可以说根本就不是一个企业所能够完成的。一个面向开发的知识库，必须建立在软件利益相关责任人的共同参与。而这项工作，只能在开发主体的高层大力推动下才可能进行。也就是说，不管一个人学习能力再强，只要其不具备企业决策职位，就不可能真正的推进此知识库的建立。
第三点，人是任何工程学的核心要素，抛开人的工程学就是伪工程学。而所谓人员流动性过大的问题，恰恰是开发过程混乱的一个显著特征，也是管理能力低下的显著特征。而在一个管理能力和开发过程都存在这样严重问题的组织内，希望通过建立一个知识库来挽回局面，显然是没有抓住主要矛盾。
第四点，所谓知识库是反文档的。这里需要我们大家对知识库的基本概念有最基本的理解。简单的说，知识库不是知识的数据库，而是知识的数据仓库。
同时我们还需要理解什么是知识。知识来源于经验，是可以被传递的经验。经验来源于人的实践，被传递也是在人之间进行。所谓企业的知识积累，实际上应该是企业中集体人群的知识共同积累。而由于知识的传递性，保证其效率则成为基本的要求。而大家看到人月神话里面强调外科手术团队的建设，也就有这个方面的因素。
通过文档传播知识无疑是一种有效率的扩展方式，但是我们也应该明白温伯格的“稀薄的果酱”的道理。而作为一个开发企业，知识的传递并不是以扩大知晓面为前提，而是应该以加深知识传递效率为前提。
同时我们还应该注意，知识的来源是经验的沉淀，而经验的载体只能是人。而扩大知识产生的一个最有效方式，也就是扩大经验的积累，明白的说就是稳定人员构成的长期存在。
而文档由于其同步性的先天性不足，其投入的资源必须得到最严密的控制。也就是说，文档必须控制在刚刚好的地步，才可能将其维护成本控制住。否则看似无关痛痒的一个小小冗余，就会造成后期维护的数量级的递增。而随着对知识的积累的进行，文档的数据将会逐步减少，理想化的情况是降低为“0”成本付出，也就是没有任何文档。
其实作为一项结论性的观念大家必须时刻牢记。软件开发是一项人的智力产品生产，软件工程是一个工程学科，这里唯一真正存在的要素只能是人，妄图抛开“The one”这个要素的做法，都是违背基本的原理，实际上也是违背基本的人类道德底线的。
首先楼主所在的公司是典型的cmm企业，或者叫混乱而无序的人力密集型企业。在这样的企业中高度存在着无序的软件开发过程和充满不稳定的人际关系，而知识库的建立显然没有一个好的基础资源支持。
我承认我们的软件开发过程现在是做得不好，而且用混乱来形容也不是很过分。但是我们在努力改进，哪一个企业公司不是这样过来的？美国国防部让卡耐基梅隆大学做SW-CMM来评估之前，替他做项目的那些公司有很多还不是一样。可能现在我们说要进行知识的管理是早了一些，在没有一个成熟的软件开发过程之前，做这样一件事情的困难会有很多，甚至会失败。但这并不影响我们讨论知识管理这样的一个东西。
顺便问一下，什么叫“典型的cmm企业”没有听说过这样的一个概念。。。。[CMM]=[混乱而无序的人力密集型]？据我所知，貌似CMM叫做“能力成熟度模型”。
楼主很年轻，而且不从事第一线的开发工作。
不明白这个你是怎么看出来的？工作一年也是什么活儿都干的，编码、测试、设计。
从根本上说其自身能力和资源配属就不可能完成持续的知识库的建立。
我的确是很年轻，也没有什么经验，我一个人说实话什么也干不了，软件开发本来就是一个集体活动，我想没有任何一个人敢拍着胸脯说我能一个人做一个团队能做到的事情。至于要搞知识管理，请不要忘记，我们是在一个团队里面。而且不会的东西学学就会了，没有做过的事情做做就明白了，人总是会成长的嘛。
第三，楼主对于知识库的作用认识还很不清楚，有片面夸大知识库作用的倾向，希望以知识库代替人和组织的工作。
我对知识库的认识确实不是很清楚，如前面说讲的也只是有感而发，很多的观点也很片面，应该多多学习。但是有一点要说明的是，我绝对没有[希望以知识库代替人和组织的工作]的意思。确切地说，我自己觉得自己反而比较像一个人本主义者。之前公司搞CMMI的培训，我也和别人争论过过程重要还是人重要还是结果重要，讨论过软件行业需不需要“The one”。
但是、针对于像外包类公司的特殊性，和短时间内由于公司规模的影响，不可改变的人员的流动性强的特点，我还是要提出建设一个积累知识，抑或说是问题解决方案[以文档为主]的这样的一个建议。如果能实现[人]的积累，那当然是更好的事情了。
第四，知识库本身的建立应该是在知识积累和归纳的基础上，而不是建立在文档的积累和归纳的基础上的，严格的说知识库是反文档化一套运行支持系统。
同上所说，所谓的反文档化是什么样的一个意思呢？就是在人的水平的提高的基础上达到人的积累。但是为什么我要提出一个对于文档的积累呢？我想知识的积累应该是有一个过程的吧？要读的书都没有，读什么？不知道这样理解对不对？[知识的归纳和积累]应该是以人为单位的吧？要在企业中形成积累就是要以另外的形式存在，而不应该是人，因为人具有最大的不可确定因素。[虽然说到了最后，所有的东西都应该围绕着人来展开，但是不得不提，我觉得，这个需要时间，而且我们不应该依赖于“The one”]
最后，还是请大家多多指教，向大家学习。谢谢。
首先楼主所在的公司是典型的cmm企业，或者叫混乱而无序的人力密集型企业。在这样的企业中高度存在着无序的软件开发过程和充满不稳定的人际关系，而知识库的建立显然没有一个好的基础资源支持。
楼主很年轻，而且不从事第一线的开发工作。从根本上说其自身能力和资源配属就不可能完成持续的知识库的建立。
第三，楼主对于知识库的作用认识还很不清楚，有片面夸大知识库作用的倾向，希望以知识库代替人和组织的工作。
第四，知识库本身的建立应该是在知识积累和归纳的基础上，而不是建立在文档的积累和归纳的基础上的，严格的说知识库是反文档化一套运行支持系统。
我个人建议将 wiki 作为基本架构，可以链接到各种不同的资源去。参考一下 Mozilla Developer Center，它本身就是一个知识库。
Boss问你下面这几个问题，你怎么回答？
建设这个要花多少资源？
多长时间后能带来收益？
能带来多少收益？相比投入利润有多少？
风险有哪些？
如果投入石沉大海后，责任谁来承担？
这个问题我已经遇到过了，我的BOSS到没有让我统计这些，可能他自己有一些对比吧。
以上的这些问题要回答的话，统计数据也不是很困难的一件事情。至于说组织上看完统计数据之后没有接受我的提案，那也应该不是这件事情不能做，只是事情有轻重缓急、权衡之下没有做而已。
然后就是关于知识库的建设问题其实也并不是一定就是这个样子的，我只是提出了自己的一些看法，如果这样做给公司带来了非常大的负担，导致公司运作产生一系列的问题的话，那么不做也罢。这个其实也是看决策者的。我觉得。。。
但是貌似“如果投入石沉大海后，责任谁来承担？”这种问题没有什么讨论的必要。如果我是决策者，那么责任就是我来承担。
Boss问你下面这几个问题，你怎么回答？
建设这个要花多少资源？
多长时间后能带来收益？
能带来多少收益？相比投入利润有多少？
风险有哪些？
如果投入石沉大海后，责任谁来承担？
首先，建设知识库需要成本，主要是人力成本；
其次，知识库的建设需要一个较长的周期，才能到达一个能产生收益的临界点。
管理层来看，简单的说，就是在现在投入成本去建设一个未来（不知何时）能带来一定收益（无法详细估算）的东西。这种东西对于管理层（尤其是营收压力比较大的管理层）来看是没有任何诱惑力的。所以很多公司宁愿把成本花在招人也不花在知识库的建设上
铁打的营盘流水的兵。。公司要发展人来人往的什么也不管的话应该是成长不起来的。如果想要发展短时间的痛一下的话忍一忍就过去了吧。。。
2，公司有多少人愿意喜欢写文档，如果强制要求会有多大效果？wiki真的合适吗？
就这样一点来说，大概大家都不喜欢写文档。但是好像大家都喜欢写Blog，不知到为什么。
在公司内部推行文档资料的收集我也感觉很有难度。不过如果在项目内的解决方案的收集形成了
一个制度的话，还是比较可行的。因为项目内的事情大家比较容易接受去做这样的一件事情。
而在项目外的资料的收集，可能还是要有一定的动力（奖励？）才比较好推行。
不过我觉得老员工带我的时候总是说：“有一个现成的文档让你看就好了！”，我觉得这个也许可以形成动力。因为这样可以让老员工带新人的成本迅速的降低。
至于wiki这样的一个形式，我也不觉得是很好的。因为在很多方面，我也觉得wiki不适合。例如搜索方面。
4，学习的成本代价也很高，还是老人带新人好；有效果也容易实施；公司应该完善这方面的制度
这一点我觉得如上面所说的，老人带新人的成本如果能再降低的话，也不能说不是一件好事。事实上就是平时大家都很忙。我就经常遇到有问题而又找不到人问的情况。很多问题也确实在网上解决不了。
5，我先问一下楼主，个人的知识库的建设有什么心得？
关于我自己的个人知识库的建设，说来比较的惭愧，整理得比较的乱，可能就我自己认得，因为我的资料本来就不是很多、而且我也大概都知道在哪儿，所以分了一下目录存放了一下。这一点确实做得不好。
第一点，网上很多东西是查不到的，公司很多资料是专有的。
第二点，写文档不是愿意不愿意的问题，是如何管理好的问题。
第三点，没有问题是简单的，只有如何能做好。
第四点，知识库就是为了增进知识共享，降低成本。
1，有多少东西是网上查不到的，必须搬到自己的知识库中；如果网上的资料就很全，为何不用网文快捕之类的软件做成一个专题书籍呢？这样省时省力。
2，公司有多少人愿意喜欢写文档，如果强制要求会有多大效果？wiki真的合适吗？
3，培训资料的整理还是很有必要的；这个的工作量不大
4，学习的成本代价也很高，还是老人带新人好；有效果也容易实施；公司应该完善这方面的制度
5，我先问一下楼主，个人的知识库的建设有什么心得？
首先，建设知识库需要成本，主要是人力成本；
其次，知识库的建设需要一个较长的周期，才能到达一个能产生收益的临界点。
管理层来看，简单的说，就是在现在投入成本去建设一个未来（不知何时）能带来一定收益（无法详细估算）的东西。这种东西对于管理层（尤其是营收压力比较大的管理层）来看是没有任何诱惑力的。所以很多公司宁愿把成本花在招人也不花在知识库的建设上