持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第11天，点击查看活动详情
特别喜欢钻研技术的开发一般都不喜欢做业务，笔者认为一般有以下两点原因：
1、业务开发本身找不到准确数字支撑业务的技术产出量化（比如技术可以说优化系统耗时提升xxx毫秒)
2、业务需求比技术需求更难做，技术可能只钻研深入一个点即可，但业务不同，需要全方位考虑每个点，不然牵一发动全身，动得不对就是故障。千辛万苦选出了最佳方案，最后仍会被质疑：
Argue1: 你改动点那么小，为什么用了那么多时间？
业务需求特点就是时间比较紧迫且质量要求比较高（多为P0)，做业务需求从来最费时间的节点不在最终那几行代码上，而是在需求背景了解需求是否合理，不合理处如何转化变为合理；需求合理后，设计者要了解熟悉并考虑上下游各方向影响，设计多种方案，提取多方数据，与多方沟通可能影响并达成共识后才转化为正式方案，也就是大家最终看到那个“简单”的版本。要知道那个版本是经过N轮考虑和讨论后，才达到既满足需求又改动最小的方案。
比如客户端SDK想重构线上某个API，需要后端配合设计，作为一个后端，你要做的不是直接上去就设计，而是了解：
1.1 端上该API使用现状和重构后目标是怎样？
1.2 对自己服务端影响有哪些影响? 如何解决？
1.3 对其他服务端影响有哪些影响？如何解决？
1.4 对线上已使用该API调用方有哪些影响？如何解决？
1.5 端上现有方案如何？方案是否需要改进？
1.6 服务端方案应该是?...
作为一个后端设计，如果前5个问题没有解决就开始自己的设计，那你的需求很大概率会带来事故或故障。
Argue2: 为什么只做了几项工作？其他时间都去哪里了？
剩下的时间基本上是一些平时多与业务相关琐碎工作无法量化，记不进去最终绩效：包含排查线上问题（做业务同学这块占比尤其多，大家有问题第一时间一定会找你），修改线上问题、线上oncall...，这种也没法量化的工作比例很大。
如：线上封板不能发布，业务催促要上线
如：业务排查手册、分享
如：需求调研、数据收集、没前端资源自己写
如：报警排查手册、业务系统维护（系统稳定后被转给其他人维护）
如：日常Oncall & 日常业务对接给产品过需求、给业务排查线上问题、业务QA对接人（开发&线上&测试）
这些工作算不上重点工作，但哪件都不能少，但这些事情都直接与业务系统相关，绝对占用开发不少时间。
