引子
对于每个软件系统，我们都可以通过业务和架构两个维度来体现它的价值。
尤其是软件开发人员，应该确保自己的系统在这两个维度上的实际价值都能长时间维持在很高的状态。
不过很可惜，他们可能更多情况只关注一个维度，而忽略另一个；
假如关注了错误的维度，这导致了系统价值最终趋降为0，非常可惜。
本文大纲
1、业务与架构兼顾的难题
2、业务与架构哪个更重要？
3、研发更需要关注什么？
4、可供参考的实践方案
1、业务与技术兼顾的难题
在我们日常工作中，业务迭代支持与系统架构技术优化就如同鱼与熊掌一样，不可同时兼顾。
“
case1：
当我们发现系统性能有些差，评估需要考虑优化一下，降低系统接口平响，同时提升用户体验...
但是这时候产品同学风风火火的跑过来说，最近有个业务改版需求/新业务功能需要紧急上线支持一下.....
Q：你会怎么办？
-- 要不技术优化的事，等这次需求完成后再说吧...
“
case2：
我们的每到年初就要做得技术规划，是不是总感觉计划赶不上变化...
每到年中、年末复盘时候，现实总会与规划大相径庭，要么是规划的事没有做或者换了个低成本方案简单实现了，要么是中途出现了一些新的事情打乱了原来的规划计划。
Q：重新来一遍，你会怎么来避免？
-- 规划 vs 变化
以上的情况工作中大家应该挺常见的，那遇到类似的问题我们应该秉承什么原则呢？有没有有效解决的措施呢？
2、业务与技术哪个更重要？
美国前总统艾森豪威尔提出个经典的“紧急/重要矩阵”。
“我有两种难题：紧急的和重要的，而紧急的难题永远是不重要的，重要的难题永远是不紧急的。
虽然有点老调重弹，但其中的道理依然成立。但实际情况确是：紧急的事情往往没那么重要，而重要的事似乎永远排不上优先级。
Q：哪个维度更重要？
在研发同学看来，重要级别一目了然：
重要的事：架构设计优化，让系统具有足够的“弹”性
紧急的事：业务迭代支持，让系统支撑业务持续发展
例如：日常业务迭代支持一贯紧急高优，但从架构设计合理性建设看来，似乎没有那么多关联；而系统技术优化看来很重要，但往往没有机会排的上期。
关于哪个更重要的讨论，当然仁者见仁智者见智
假如对于这个问题，由业务部门来回答，那就是业务更重要-系统支持业务迭代，保障业务正常发展很重要。
3、研发更需要关注什么？
我们可以试着将此四类情况做下排序：
1）重要且紧急
2）重要不紧急
3）不重要但紧急
4）不重要且不紧急
系统架构设计优化：重要（占据第1、2位）
业务迭代支持：紧急（占据第1、3位）。
但是我们日常工作中，业务部门与研发部门经常犯的错误就是将第三优先级的事情提到了第优先级去做。将重要的系统技术优化事项被业务迭代所排挤。
“我们研发人员经常会抱怨，没有时间来做技术优化，自我调侃为：“又在搬砖...”、“又在加班写BUG了...”
似乎我们忘记了：业务部门就是只盯着业务的，对于系统架构的评估和优化，本来就是研发人员的工作职责！
如何平衡好这两者的工作，是研发人员的晋级修养之路。
不要忽略系统架构的价值，假如有一天系统难以维护到只能推翻重来的地步，可以说是系统技术优化跟不上业务快速迭代，同时侧面说明了研发同学的本职工作做得不够格。
4、可供参考的实践方案
上面说了很多技术架构优化与业务迭代支持两者难以平衡的难题。那有没有可以平衡的好方法呢？
我从自身工作实践中整理一些经验，主要就是“总-分-总”的原则，供大家试用参考：
1、【总】项目立项，评估目标收益
做事要有价值，尤其技术优化类项目，一定要想明白收益点是什么，同时搞清楚投入产出的性价比如何。
这个阶段建议多花点时间，多调研分析下，建议目标尽量可量化，可达成。
【项目目标制定-示例】
项目：XX系统性能优化
目标：系统服务平响 <= 200ms（90分位值 <= 500ms）
2、【分】拆分细化，评估优化改造范围
确定目标后，需要将目标进行动作拆解，并评估每项动作的目标达成占比以及优先级。
功能点拆分注意要以终为始，保障不要偏离目标。
具体的方法可参考：
1）按流程逻辑拆分
2）按工作模块拆分
3）按数据流拆分
可能前期对于各个点的评估并不一定太准，允许后期调整，但不应该大幅度调整，否则需要重新做下考量。
【项目细化拆分-示例】
并发、服务依赖优化、cache、表结构拆分、表索引优化、逻辑优化（循环套循环）、Redis 大Key优化、资源隔离 等等
3、【总】归类收敛，规划可行的项目里程碑
功能评估按同一类型进行归类，将各子优化项拆分到日常业务迭代中去，或者穿插到各需求开发间隙中去，小步快跑，保障项目稳步推进。
【归类收敛-示例】
4、【保障】汇报跟进，项目迭代进度推进
可建立以每周为单位的项目汇报制度，召集相关同学定期例会跟进，项目进度&问题持续Review，保障项目整体推进进度。
项目进度汇报主要关注点：
总结：
很多人将业务与技术之间理还乱的关系称为“相爱相杀”，其实技术与业务并不是对立的，而是相辅相成的。
技术作为理论基础，业务作为实践去检验落地。我们所学的技术，业务是我们的落地点，业务成功了同样能反衬体现出技术价值。
