对于每个软件系统，我们都可以通过业务和架构两个维度来体现它的价值。

尤其是软件开发人员，应该确保自己的系统在这两个维度上的实际价值都能长时间维持在很高的状态。

不过很可惜，他们可能更多情况只关注一个维度，而忽略另一个；

假如关注了错误的维度，这导致了系统价值最终趋降为 0，非常可惜。

在我们日常工作中，业务迭代支持与系统架构技术优化就如同鱼与熊掌一样，不可同时兼顾。

当我们发现系统性能有些差，评估需要考虑优化一下，降低系统接口平响，同时提升用户体验...

但是这时候产品同学风风火火地跑过来说，最近有个业务改版需求/新业务功能需要紧急上线支持一下.....

Q：你会怎么办？

-- 要不是技术优化的事，等这次需求完成后再说吧...

我们每到年初就要做的技术规划，是不是总感觉计划赶不上变化...

每到年中、年末复盘的时候，现实总会与规划大相径庭，要么是规划的事没有做或者换了个低成本方案简单实现了，要么是中途出现了一些新的事情打乱了原来的规划计划。

Q：重新来一遍，你会怎么来避免？

-- 规划 vs 变化

以上的情况在工作中大家应该挺常见的，那遇到类似的问题我们应该秉承什么原则呢？有没有有效解决的措施呢？

美国前总统艾森豪威尔提出个经典的“紧急/重要矩阵”。

我有两种难题：紧急的和重要的，而紧急的难题永远是不重要的，重要的难题永远是不紧急的。

Q：哪个维度更重要？

在研发同学看来，重要级别一目了然：

重要的事：架构设计优化，让系统具有足够的“弹”性

紧急的事：业务迭代支持，让系统支撑业务持续发展

例如：日常业务迭代支持一贯紧急高优，但从架构设计合理性建设看来，似乎没有那么多关联；而系统技术优化看来很重要，但往往没有机会排的上期。

关于哪个更重要的讨论，当然是仁者见仁智者见智

假如对于这个问题，由业务部门来回答，那就是业务更重要-系统支持业务迭代，保障业务正常发展很重要。

我们可以试着将此四类情况做下排序：

系统架构设计优化：重要（占据第 1、2 位）

业务迭代支持：紧急（占据第 1、3 位）。

但是我们日常工作中，业务部门与研发部门经常犯的错误就是将第三优先级的事情提到了第优先级去做。将重要的系统技术优化事项被业务迭代所排挤。

我们研发人员经常会抱怨，没有时间来做技术优化，自我调侃为：“又在搬砖...”、“又在加班写 BUG 了...”

似乎我们忘记了：业务部门就是只盯着业务的，对于系统架构的评估和优化，本来就是研发人员的工作职责！

如何平衡好这两者的工作，是研发人员的晋级修养之路。

不要忽略系统架构的价值，假如有一天系统难以维护到只能推翻重来的地步，可以说是系统技术优化跟不上业务的快速迭代，同时侧面说明了研发同学的本职工作做得不够格。

上面说了很多技术架构优化与业务迭代支持两者难以平衡的难题。那有没有可以平衡的好方法呢？

我从自身工作实践中整理一些经验，主要就是“总-分-总”的原则，供大家试用参考：

做事要有价值，尤其技术优化类项目，一定要想明白收益点是什么，同时搞清楚投入产出的性价比如何。

这个阶段建议多花点时间，多调研分析下，建议目标尽量可量化，可达成。

【项目目标制定-示例】

项目：XX 系统性能优化

目标：系统服务平响 <= 200ms（90 分位值 <= 500ms）

确定目标后，需要将目标进行动作拆解，并评估每项动作的目标达成占比以及优先级。

功能点拆分注意要以终为始，保障不要偏离目标。

具体的方法可以参考：

可能前期对于各个点的评估并不一定太准，允许后期调整，但不应该大幅度调整，否则需要重新做下考量。

【项目细化拆分-示例】

并发、服务依赖优化、cache、表结构拆分、表索引优化、逻辑优化（循环套循环）、Redis 大 Key 优化、资源隔离 等等。

功能评估按同一类型进行归类，将各子优化项拆分到日常业务迭代中去，或者穿插到各需求开发间隙中去，小步快跑，保障项目稳步推进。

【归类收敛-示例】

可建立以每周为单位的项目汇报制度，召集相关同学定期例会跟进，项目进度 &问题持续 Review，保障项目整体推进进度。

项目进度汇报主要关注点：