轻量级研发知识管理--如何帮助研发人员建设过程资产

“研发知识与经验按说应该成为科技企业的宝贵财产，而实际并非如此，造成这样局面的原因并非对知识的重要性缺少认识，研发经理很明白其重要性。到目前为止，研发知识管理失败的原因在于没有解决：如何将适当的知识在研发人员需要此知识时提供给他。”这是国际知识管理领域的权威Michael E.McGrath（IPD的前身PACE理论的创立者）说过的一句话，代表着研发知识管理所面临的困惑，这种困惑在中小型企业尤其是初创型企业表现的尤为明显。本文试图从知识管理的角度出发对如何解决或者缓解这种困惑做一个探讨。

一. 知识管理的概念

要解决这个困惑，我们首先要明确知识管理要做什么？知识管理把“隐形知识显性化”，是一项涉及知识库、过程资产、环境和交流等元素的整合过程，所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言，所谓隐形知识，通常指的就是在那些业务人员和技术人员脑中的蓝图，把握这些蓝图的人就能形成一定的工作节奏，而无法把握这些蓝图的人如果加入到团队中，可能不但适应不了这个节奏，还会打破已有的节奏。这就是我们要进行研发知识管理的目的所在。

个人知识的层次一般认为分为6个层次，具体可参见我的另一篇博客：《工具系列之OneNote--关于团队的知识管理平台》。

我们可以看出客观的认知到知识创新对知识管理要求逐步提高，大家可以做一下判断看看自己所处的环境中知识管理处于以上哪一个层次？

个人认为可能一般处在3~4层的环境会比较多，到第5层对知识管理而言已经是比较高的层次，而本文的初衷就是如何提升自己团队的知识管理层次，根据客观现状进行过程改进。对研发团队而言，通常技术人员都不擅长进行知识的管理，因为知识管理是需要成本的，包括知识转移的成本、知识转化的成本和知识保存的成本。层次越高所需要的成本就越大，国内环境下技术人员开发工作通常都已经是超负荷，再让他们花时间去进行知识管理通常是很难操作的。但正如前面讲到，知识管理是一件必须要做的事情，这就需要我们找到平衡点，即能把知识管理这一过程转动一起，又不会给研发人员带来过多工作量，这就是本文称之为“轻量级研发知识管理“的原因。

二. 轻量级研发知识管理的思路与目标

如果研发团队中出现以下症状或表象就说明研发知识管理是欠缺的：

• 没有文档记录导致过程资产丢失
• 开发人员个人素质要求偏高
• 交接困难，新员工难以熟悉现有模块的设计思路
• 缺少设计评审，设计问题延后暴露

面对以上问题，轻量级研发知识管理的思路主要有两个方面。首当其冲的是过程资产建设，过程资产建设是一个组织级别的活动，对研发管理而言重点关注：

1. 知识服务于业务：从具体业务出发管理研发知识，而不是从技术出发。技术人员进行知识梳理的过程中（尤其是刚开始的阶段）往往习惯于从技术本身出发来看问题，导致梳理出来的东西只有技术团队内部有限的几个人能看懂，个人认为是不对的。业务领域模型才是一个系统的核心，技术只是这一模型的一种实现方式，技术人员梳理的知识同样也要让产品线、项目线能够参与讨论和总结。
2. 系统运作与界限：关注系统的运作流程及其服务提供的界限。对多团队协作的研发过程而言，系统集成是团队之间协作的根本任务，如何定义系统之间的服务边界，并把这些边界梳理成统一接口进行维护是团队作为服务提供者对外所需要暴露的知识；对内而言，各个服务清晰的逻辑流程是确保团队内部高效运作的基础。
3. 通用库：通用功能、模板和流程。通用库包含的内容可以有很多，代表性的有过程资产定义的格式和团队交流采用的信息传递模板（如Word、Excel等文档的样式和风格、基本章节的划分和定义）、工作流程（如下面讲到的评审会议的召开方式、频率）以及在团队和组织级别进行提取的通用功能（如各个系统都能使用和适配的登录注册功能）。

另一个主要思路是评审。对研发团队而言包括两方面的评审过程：

1. 设计评审：通过需求分析会议，研发人员明白怎做什么之后就要考虑怎么去做，这个阶段就是要进行系统设计。系统设计的开展方式上可能由相对资深的研发主管主导，也有可能是团队中的任何负责某块功能的开发人员。无论哪种方式，当系统设计的成果出来之后、正式启动代码开发之前，设计评审是必须要有的，以确保设计中是否有业务逻辑上的纰漏以及在开发团队成员之间达成一致。
2. 代码评审：当一个阶段的代码已经基本开发完成并提交测试，是时候大家一起坐下来进行代码评审的时候了。代码评审通常的方式是同级评审（Peer Review），包括代码走查、代码审查等形式并灵活运用各种重构手段确保代码的质量。

通过加强过程资产建设和评审，轻量级研发知识管理的目标在于形成“老人做新产品，新人做老产品”的研发良性循环。

三. 轻量级研发知识管理的流程与实践

轻量级研发知识管理之所以轻量，是因为其只包括了两个工作流程和五个工程实践，这些流程和实践都很容易进行实行和推广。下面结合本文第二部分的思路对具体的做法进行展开：

1. 工作流程

工作 流程包括设计会议流程和代码质量保证流程，流程中的某些步骤和 表现形式将在实践部分进行介绍。

• 流程之设计会议。设计会议的通用流程如下，其中根本的要求就是要进行系统模型分析和确定服务边界：

• 流程之代码质量保证。代码质量保证的通用流程如下，其中重点把握代码评审部分：

2. 工程实践

工程实践的产出是代表着知识管理思想的具体产物，包括：

• 模块责任制：模块责任制的初衷是确保知识管理过程的完整性，无论领域模型、业务流程还是其他多个知识方面都通过业务模块这一基本单元进行组织。模块责任人负责整个模块的知识管理，在具体文档的组织上也建议一个模块维护一份文档。模块责任制的示意图如下：

• 领域模型：按照领域驱动的设计思想包括Domain、Repository等内容，其中最常用也最必要的就是数据模型，一般通过数据库建模达到这个目的，如下图中使用PowerDesigner设计的效果图：

• 时序图：统一建模语言是用来对软件密集系统进行可视化建模的一种语言，常用的用例图、时序图、状态图和活动图等都一定程度同时面向业务和技术，其中时序图主要展示业务间的详细流程，同时显示了流程中不同对象间的调用关系和调用顺序。结合“系统运行和边界”的知识管理思想，时序图能够详细描述前端调用接口，定义接口名称、调用方式及输入输出条件；同时也能描述后端各组件之间的调用关系及调用顺序，直观展现了业务模型，个人认为是UML中最适合做研发知识管理的一个必备工具。下面是用Astah UML工具制作的时序图示意图：

• 通用库：建设通用库或者说IPD思想里的共有构建模块（CBB）无疑是研发过程中的一项最佳实践。通用库的表现形式可以有代码的工具库、基础功能的组件库等。下面是Java代码的工具类库使用说明文档的目录示例，通过文档对该工具类库的定义和使用进行说明：

• 团队代码评审：Code Review很多团队都在进行，结合“模块责任制”实践，我们可以以模块为Review的基本单元，采用定期（建议一周一次）的集体式（包括团队所有开发人员）的方式进行评审，开展方式上重点关注的几方面可参考下图：

四. 小结

研发知识是核心资产，本文通过两个工作流程和五个工程实践试图寻找适合目前团队最合理的研发知识管理模式。研发知识管理需要我们结合组织或团队的实际情况梳理合适的流程和实践，同时贵在坚持。