团队和过程是维护知识结构的必需。

团队：“知识 - 团队 - 沟通”的闭环

团队结构与沟通结构，显然是一个映射关系。相比于团队内部，不同团队之间的沟通肯定相对不便，效率和准确性都显著较低。

而知识结构和沟通结构，也是一种相互制约的关系。这个关系就是康威定理¹描述的关系，定理中所说的产出结构，其实就是按照知识结构形成的。

知识、团队、沟通三者的关系，形成了某种循环。通过改善团队和沟通结构，可以帮助知识结构的改善。同时逐渐改善的知识结构，也会促成沟通和团队的进一步改善。如下图所示。

所以我们认为，根据“产品线”制定的团队结构需要重新安排。根据上下文定义、应用与领域分离的原则，我们重新设计了团队结构，并开始了“团队种子->虚拟团队->实体团队”的团队构建之路。

过程：知识需要重整

知识的来源是我们的产品同学。产品同学产出的知识，与开发需要的知识，结构上并不一致²。

1. 产品同学描述局部。较少归纳与系统其他部分的关联。
2. 产品同学描述过程。较少定义涉及的概念和规则。
3. 产品同学描述增量。他们关注功能的增加和变化，较少关注遗留和现状。

这样的关注角度和知识结构有它的价值，但对研发来说是不适合的。 我们需要一个重整知识结构的过程，将产品同学输入的片段知识，重新整理并归纳到我们，这个过程就是“需求分析”。根据我们的团队结构和与产品同学的合作模式，我们认为这个“需求分析”应该是：“应用触发领域驱动的需求分析”。

也就是说：需求分析由应用团队触发，因为产品同学的输入在应用（也就是目前大家都习惯的“产品线”概念）；但随即转交给相应的领域团队，由领域团队作为中枢推进和控制后续分析工作的进行。这个过程跟我们此前谈到的，应用知识与领域知识的关系相匹配——区别应用知识与领域知识。

（后文继续，讲讲领域团队的工具）