做事要按任务优先级

还记得上学那会，考试时是按照什么策略来答题嘛？

---

大多数人的答复可能是按照你会的来答题，即容易的，则优先级高。每每考试完，反馈说题目没有做完，丢分了！你爸妈或者老师用河南话说“傻啊，先做恁会的！”

---

现在想想考试时先做容易的题目，这种场景下你肯定将所有考卷上的题目看完了，对于题目的难易和会不会做，你心中有数了！然后再从头到尾过第二遍消灭掉相对难一点的题目，渐渐地，最后攻关拿下更难的题目，最难的放在最后。这种策略能保证你及格甚至是在良好的情况下走向优秀。

---

换个角度来看，这种策略还待改善。

当你领导给你安排一项任务：验证EC单，验证EC单是有讲究的有学问的。如果你按照上学时考试答题那种策略，先整体看下EC单都是解决什么样的bug，各个bug需要构造什么样的方法进行验证，然后将容易验证的EC单先验证完了，剩下难验证的EC单。

对于版本质量来说，验证什么样的EC单才可以确保版本质量。一般来说，严重级别的bug单对验证版本质量是否有问题更加重要则优先级更高，一般级别的bug单对版本质量则一般(因此提单时故障单的级别要按照所发现的bug对版本质量的影响来定)。

注意：严重级别的故障单不一定难验证，容易验证的故障单不一定级别低。EC的级别在于bug对版本质量的影响，单子是否容易验证主要是构造方法的难易。

试想一下，故障单容易的优先验证了，但其bug是否修复并不影响版本质量的高低。验证EC单应该采取能提高版本质量的策略来验证EC单，整观EC单的严重级别，然后相同级别的再看EC的难易。更能提高版本质量且容易验证的EC单优先级最高，更能提高版本质量且难验证的EC单优先级次之，能提高版本质量且易验证的EC单优先级再次之，能提高版本质量且难验证的EC单优先级放最后。

---

做事要看任务的优先级，而不是容易程度。

但是怎么识别任务的优先级呢？且看下回分解：做事如何识别任务的优先级？