艾森豪威尔矩阵下，为好架构持续斗争是研发人员的职责

艾森豪威尔的紧急/重要矩阵提供了一个框架来定位[[用逻辑论证证明架构价值高于行为价值的反直觉结论]]里两个价值维度该被如何排序：”紧急的难题永远是不重要的，重要的难题永远是不紧急的”——系统行为（功能是否能跑）是紧急的，但不总是特别重要；系统架构是重要的，但不总是特别紧急。四类事情理应按”重要且紧急→重要不紧急→不重要但紧急→不重要且不紧急”排序，而架构（重要）应排在行为（紧急）之前。业务部门和研发人员共犯的错误是把”不重要但紧急”的功能需求提到第一优先级去做，让重要的架构问题一再让位——但业务部门原本就没有能力评估系统架构的重要程度，这本来就该是研发人员自己的职责，平衡架构重要性与功能紧急性是研发人员不能外包给业务部门的责任。因此软件团队必须做好和其他部门”长期抗争”的准备：作为系统相关方之一，保护系统的可维护性是开发者角色不可缺少的一部分，公司雇你很大一部分原因就是要有人来做这件事；如果你是架构师，这项职责就更重——你需要创建出让功能更容易实现、修改更简单、扩展更轻松的架构。如果忽视架构价值，系统终将变得无法修改，这恰恰说明开发团队没有和需求方做足够的抗争，没有尽到自己的职责。