最近一个月感觉很明显，需求迭代明明都排足了时间来开发，然而最后都是赶工完成。原因是经常被一些事情打断，一天到了傍晚时候才开始真正做当天的需求。
| 分类 | 排期之外的琐事 |
|---|---|
| 排障类 | 1、产品/运营同学报的前端BUG 2、接口报错，但要前端排查调了哪个接口 |
| 答疑类 | 3、后端问前端调了哪个接口，或前端校验逻辑 4、回答框架使用问题 |
| 支持类 | 5、技术对接与文档约定 6、配合联调（未识别到前端工作量的需求） 7、框架维护，可能会在需求方提测前支持 feature 或 bugfix 8、有些小CR需求没排期，看前端改动量很小，就友情支持给做了 |
| 沟通类 | 9、需求讨论（非评审，可能在评审前，也有在开发阶段讨论） 10、接口定义不清，前后端二次沟通 |
对于这些事情，我似乎没什么原则，非要给优先级的话，肯定排障类是第一。其他事情基本都会及时处理，导致正常的需求开发被打断或推迟。我是这样想的，如果是我在找别人，我肯定希望对方尽快回复尽快处理。
上回看到有人提到了 MECE 原则 (相互独立，完全穷尽)，2x2矩阵(四象限)是其常用的分类方法，我把处理工作分为两个维度。横轴表示做事的紧急度，纵轴表示做到什么程度，试着将上述琐事对号入座。
然后将其所属分类对应到四象限中，得到更 general 的分类。
以上自己不成熟的思考，未经过时间考验，不一定正确。今后遇到事情还得具体来看，但总比没有原则好。