如何保证架构设计的灵活性与可扩展性

近些天最为火爆的段子莫过于RD（工程师）与PM（产品经理）的拳打脚踢了，我们先不纠结事情的起因与谁对谁错，单从架构设计的角度漫谈一下如何保证与PM沟通的流畅性，以及如何做到架构设计的灵活性与可扩展性，以应对后续不可避免的需求变更，减少迭代开发工作量，保证迭代开发的可控和系统的可维护。

矛盾的产生

众所周知，RD与PM之间在工作层面上，往往存在着矛盾。其实不仅是RD与PM，不同子系统的RD与RD之间，都有可能在工作层面上存在一定的不一致。从《矛盾论》的角度而言，对于这个问题，我们需要辩证地加以分析，产生不一致是必然的，需要经过基于数据、经验、竞品等“理”来相互抛出各自的观点，最终实现一致性。经过这个争论的过程（纯技术争论，跟个人恩怨完全无关），可以达到最终一致性，从而得到最为符合业务发展的结论。

那么为什么不同团队、不同角色的同学会产生不一致性呢？其实道理很简单，就是在于其视角的不同而造成。不同的同学，如果仅从个人所负责的系统的易维护性上加以考虑，夹带个人私货，那么最终的一致性是无法实现的。因此同时具备技术和产品视角，并能对上下游梳理得比较清楚的成员在团队中很重要，因为所谓的顾全大局、所谓的公正公平，是无法脱离业务实际发展阶段、已有技术实现框架等而孤立存在的。

需求评审阶段的良好实践

很多RD都会比较头疼于与产品同学讨论需求方案，反之亦然。其根本原因就在于双方无法换位思考，站在对方的角度去了解对方的诉求，或是无法建立互信从而共同推进业务向前发展。

其实在沟通前，双方都要有一个共同的目标：推进业务的发展。任何夹带私货的行为都应该受到谴责。