公司最近在搞复盘，这里主要谈谈科研复盘。复盘的目的是如何实现科研管理从形式到内容的转变。

从形式上来看，公司这些年科研输出需要哪些文档，需要进行哪些评审等都已经有流程去支撑，通常情况下可以保证形式上的完整性。

刚到公司的时候也发现了这个问题，形式上的完整性并不能保证产品质量以及过程输出件的质量，曾经提出过这种流程和方式过于形式，要重视内容质量建设。那时候并没有得到公司老板足够重视，认为形式有了内容也差不多。到目前为止，问题已经凸显出来，公司意识到要保证产品和过程输出件的质量，光靠形式上的流程和要求是不够的，本质上还是要在内容上下功夫。

那么如何在内容上下功夫？

首先，统一架构语言。
在讨论的过程中发现一个很重要的问题，也就是公司这么多年以来，其实并没有一个架构统一的语言，所以我们在做架构设计的时候，都是个人按照自己的理解来进行方案设计，这就造成了架构设计的随意性，以及沟通的偏差。

按照以前我做架构的经验，一般来说首先要进行架构的定义，那么什么是架构？最通俗最简单的说法是，架构就是系统有哪些模块组成，以及模块与模块之间的关系。我们就是利用这些模块来实现产品或者系统的业务功能。

每个公司对架构的术语可能都有自己的定义，譬如我在hw公司的时候，我们是按照系统、子系统、模块、组件来进行分层定义。不同公司都有自己的一些标准，但本质上底层的逻辑是类似的。我们先不讨论这种差异性，不管采用哪种方式，在团队内部都要保持一致的认识，用同一套语言去支撑输出和沟通，这套语言先形成共识，只要跟标准说法差异不大而且不会产生误解，那至少可以达到能够相互理解的目的。

所以统一语言很重要。根据目前公司的现状和一贯习惯，我觉得能够被接纳或者是说沟通顺畅最好的建议就是系统或产品、业务功能模块、基础平台与公共组件，形成“产品-模块-组件”的三层架构定义模式。
其中，产品与模块主要是面向用户可理解的业务层面的内容（偏向于概念模型），而组件是面向程序员实现层面的技术组件（偏向于实现模型）。

其次，理清复盘的两大方向。
从科研管理这个视角来看，我认为主要包含两大部分：第一部分是业务复盘。第二部分是架构复盘。

对应到我们的科研管理流程上来说，业务复盘主要是TR1阶段，主要是偏向用户侧。从产品定义、原始需求、产品需求、设计需求来看需求满足度，以及从需求到设计的一致性。这里的输出主要是什么呢？主要是需求跟踪矩阵、典型用户场景、用例图或业务设计方案，原则上需要包含用户测试用例和产品测试用例，但关于测试这一块先放在一边。

架构复盘主要是对应于TR2和TR3阶段，主要偏向于实现侧。从系统架构或者说是产品架构到模块架构，再到平台和公共组件，需要分层输出架构设计方案。对于系统架构或者产品架构，主要包含几张架构视图，理论上是要包含4+1视图，但是从目前我们产品的现状来看，我认为主要输出业务视图（功能）、架构视图（逻辑）、部署视图（物理），如果TR1阶段的用例视图和业务设计方案输出比较好，应用视图（使用）则是可以暂时省略的。为什么要输出这几个视图呢？主要是为了回答系统或者产品有哪些业务功能（业务视图）？是如何实现的（架构视图）？以及我们如何部署（物理视图）？最后用户如何使用的（应用视图）？系统或产品除了输出上面几个视图之外，还有按照我们业务视图的模块把模块的架构再分层打开，各自输出模块的架构设计方案。

最后，众神归位，形成公司知识财富。
业务复盘和架构复盘的输出都需要经过专家的专项评审，通过评审也确保理解的一致性，还有保证最终交付件（包括如代码等实现）的一致性。该重构重构该优化优化，不停的迭代形成高质量的内容。所以也需要成立一个或者多个专家评审团，并实现专家个人绩效评估的闭环，这是一个机制的问题，这里就不多做说明。

在上面的描述中，我并没有说这些内容放在什么文档里面，因为现在我强调的是内容，至于内容是应该由哪个文档来承载，这只是一种承载形式，只要形式符合质量管理和配置管理的要求就可以了，因为那仅仅只是形式。

最后也就是三点强调：
第1个就是输出的内容需要经过专家评审，才能形成了高质量的文档，毕竟大多数的人都是普通人，我们需要借助专家的力量。

第2个就是输出的内容承载在哪篇文档上，这根据公司的科研管理要求和质量体系要求来落地，形式上可以满足就行。

第3个根据上面的复盘，我们需要把该流程化的东西、该形成模板的内容、该形成规则的都总结固化下来，纳入到公司管理体系中，这是举一反三。

如此复盘，供科研管理复盘参考。