作为一个技术组的管理者，团队整体规模达到了80人，对于团队人才培养和团队建设有一些思考，现在我将分享它。1、需求生成开始带团队的时候，没有知识库的概念，公司内部也没有分享和整理的系统解决方案。大部分是word或者excel，甚至是文本文档，然后上传到svn上，一旦某个文件夹丢失，就算是知识库了。但是两年后，我发现这种杂乱无序的知识库分享方式有很多不足之处，比如搜索速度快，文档出错时无法同步更新等等。.根据我遇到的情况，公司需要建立一个统一的管理知识库。知识库必须能够真正帮助团队中需要帮助的每个人，而不仅仅是一个处理事情马马虎虎的正式知识库。数据毫无意义。然后，我梳理了自己的思路和要求：内容划分：将知识或信息进行分类，形成文档集或知识库。从知识信息的用途上分为：公司制度管理、通用技术、市场知识、产品规格及案例、入职培训等；信息安全：对于公司内部信息，特别是技术和市场相关的信息，如果有非常机密和敏感的内容，一定不能是SaaS，必须支持本地化部署；必须具有权限管理和有效的信息分类控制；内容格式：B/S模式，支持富文本，支持演示，支持脑图，支持绘图等；快速搜索：支持内容级搜索，不仅仅是搜索主题，而是必须能够支持内容搜索；形式交流：可以对内容进行评价和评论，更容易形成团队内部的交流，最好是类似于论坛的形式，相关人员可以发表相关意见和建议；分享方便：分享范围可控，分享时间有效性，支持密码、内部账号等；易操作：交付一定要简单，最好支持方便的用户认证等；成本控制：因为公司的数量在逐渐增加，成本最好尽可能的低，不限制人数和功能；易扩展：最好完全开源，易扩展，因为我们有一个内部需求，就是在日常项目执行的过程中，日常项目中的一些文档可以形成知识积累（产品经理的需求分析、prd等），因此需要提供便捷的知识库二次开放；2、技术选型其实最理想的交付是语雀和Thoughts（teambition内容管理），虽然也有腾讯文档和石墨文档等，其实从需求层面都可以用，只是更侧重于个人使用，但这些都是SaaS，私有化部署成本高得吓人。然后找到了支持本地化部署的MRdoc，但是这个版本是python，我们的技术团队都是java，技术栈错了。然后自己也看了开源的wiki，根据项目组的实际情况修改了代码，达到了想要的效果。推荐使用dokuwiki，简洁，可定制性强，支持权限，版本持续更新。最大的缺点就是编辑文档的操作性比较不友好。最终我们选择了非常符合我们企业需求的“无忧·企业文档”。Git开源地址：https://gitee.com/software-mi...PC端演示环境：http://knowledge.bctools.cn/从开始看到文档到完成用了半天时间的部署，文档支持还是比较不错的。部分图片：3.最后，一旦团队达到一定规模，内部信息流的有效性就会下降，尤其是在技能的传递和知识的沉淀方面。技术含量的沉淀和知识的转移必须有配套机制。要有分工，要有负责人。内容的组织必须有经验，对公司的背景特点有深刻的了解。公司制度由人事管理，通用技术由技术部技术专家管理，市场知识由市场总监管理，产品需求由产品总监管理。知识库建立到一定程度后，写作和分享对新人或其他会员确实有帮助。渐渐地，团队也会感受到知识库的作用，但这个过程比较漫长。我个人认为不可能调动大家分享知识的积极性。只有负责人+强制+鼓励才能真正建立知识库。
