Hi，我是阿昌，这次记录分析的是关于软件需求开发的时间管理方案。
前言
针对软件开发，每一个需求都会经历评审/开发/测试/上线/修复的环节都十分的重要。实际开发中很多开发把任务的顺序搞错了，更多地关注于紧急但不重要的事情，影响开发的质量，同时又造成问题处理不及时。
对于需求的产品经理都会针对每一个需求对应优先级的划分。
那在如此安排充实的情况，针对每一个新 业务需求开发、线上紧急Bug、需求优化，如何平衡应对是一个非常重要的能力。那在这种情况下，需求的时间管理方案就十分的重要了；不然就感觉每天忙得团团转但其实又真的没干什么，就向一个救火队员一样，哪里有火哪里跑，最后却收益甚微。
正文
美国著名管理学家科维提出的一个时间管理的理论：时间“四象限”法，把工作按照重要和紧急两个不同的程度进行了划分，基本上可以分为四个“象限”：
- 既紧急又重要
- 重要但不紧急
- 紧急但不重要
- 既不紧急也不重要
既紧急又重要
既紧急又重要，线上紧急Bug、对应非常重要紧迫有期限的需求安排等
1针对线上紧急Bug
针对线上紧急Bug最为重要，Bug其实也粉t0-t10级Bug，针对Bug是否影响操作主流程、影响用户的范围、影响系统功能的范围等来判断他是T几等级的Bug；
影响用户主流程应当最先考虑：
当一个Bug可能只影响到用户查询不了订单，因此就会想要用户无法打印发货，那只针对用户打印发货的功能有影响；
当一个Bug可能影响到用户的登录，那此事用户将完全无法使用我们软件提供的服务，那就是影响所以用户级别的t0Bug
当一个Bug他不修复可能会影响到扣减库存后显示的日志不够准确，那仅仅只是显示展示页面的问题，用户针对扣减库存的功能还是依然正常的使用
2非常重要紧迫有期限的需求安排
针对非常重要紧迫有期限的需求安排就针对这个时间段，针对这个软件系统可能出售直接的一个软件卖点，如果没有这个需求，可能就会流失一定数量用户的订阅；也可能流失一定数据用户针对某个商品氪金的期盼度等
不紧急但重要
不紧急但重要类型的事件，他一般没有一定影响，但它对后续 任务需求拆解的质量、任务开发的质量、任务开发的效率、任务开发流程的规范程度、需要后续复盘得出的问题点、个人针对某个技术框架分享分析等；
针对团队、个人有着各个方面的提升的事件，如下：
- 可能是在开发任务完成后提交测试的邮件来描述这次开发的功能，越详细就可以越让你在后续对需求回顾后你遗忘的需求点和测试点、涉及项目的发布点等；
- 代码的review，提升自己的代码编写能力
- 发觉新的技术组件
- 改进需求开发的产能速度
- 需求开发复盘
- 技术分享等…
紧急但不重要
紧急但不重要，意料之外的需求对接/安排、某些文件/邮件等的处理、某些分享问题会议、需要出席某一些的会议等..
1意料之外的需求对接/安排
可能是别的项目组有人想要跟你进行需求的对接和安排；
可能是测试突然让你修改数据库的数据进行它测试需求流程的推进；
可能是新来的小伙伴需要你对我们负责业务模块的培训等…
2某些文件/邮件等的处理
可能是产品需要你出一个针对某个Excel导入模型支持的表头信息文件等
3某些分享紧急问题会议
对某些分享问题会议，可以让大家快速避免紧急问题，来规避后续可能会出现的代码Bug和不能注意到的需求开发点，减少代码Bug的出现和后续某个需求逻辑的查漏补缺。
既不紧急也不重要
公司有趣的活动、一些可做可不做的杂事、不必要的代码优化等..
总结
上面说来事情的四象限的例子；且事情的重要性及紧急性就好比——巨石、碎石、沙子和水及桶。铁桶最大的容量，象征着在一段时间内，一个人的最大工作量;碎石象征着既重要又紧急的事务;石块象征着重要、但不紧急的事务;细沙象征着紧急、但不重要的事务;水象征着既不重要也不紧急的事务。
每个事情都有它的紧急度、重要度。
合理的理解拆分拆解对应的事情可以让我们在开发任务的时候游刃有余。