这个问题，我第一反应是那个笼子里的新猴子总被被老猴子打的故事。群体环境中这一种不加改进的经验传承，每进到一个环境，接受既有事实和游戏规则，是一种本能的思维惯性。
比如关于产品需求的开发流程。
一种典型的需求沟通流程是这样的，BA或者产品经理在搜集整理了客户或业务部门的需求后，产出产品原型图和需求文档，然后组织业务部门和研发部门相应人员在一起沟通，各自提出问题、解答问题。经过几轮会议的梳理，终于完成确认可以开始开发了。
大多数人都习惯和接受了这套路子。
在系统的中早期阶段、功能逻辑比较简单等前提下，一群经验和能力比较一般的人这样去干，是说得通的、也是有效的。
当然这样的描述，未免会给人很不舒服的感觉，没有人愿意被划到“一般人”的行列。但这样的评价应该算是客观的。
但是我一直在尝试打破这种惯性。系统到了一定阶段后，不应该再走这种看似正常的流程。
产品扯上设计心理学等一系列经验性科学，有它的玄幻性，系统因为架构这种工程特性也有它的复杂性，运营更因KPI有它的破碎性。产品形态只是系统的脸面，但是谁最终对系统负责是IT界的一个辩证性难题。
系统开发出来是给人用的。这好像可以作为系统的第一性原理。那么需求的响应和实现，也与人息息相关。
根据周爱民老师在《大道至易》系列书籍中的阐述，从“架构师能力模型”部分，我觉得可以得到这方面的一些答案。
架构师能力模型：
系统架构模型：
