推荐一篇文章 《经济学家如何排队》,还有一篇 《从经济学里的排队问题看效率与公平的矛盾》。
我随便说两句,如何给工作任务队列排序。
任务队列有几个排序原则:1 优先级 、2 重要性 、3 利润 、4 稳定 、5 取悦客户(老板)、6……
依照不同的排序原则会产生不同的排序结果。
在处理不同类型事务和担任不同角色时需要参考不同的排序原则。
- 比如bug任务列表,依据应该是重要性。
- 比如任务分工排序,依据应该是优先级。
- 比如整体改版计划,依据应该是稳定和利润。
- 如果你是那某几个倒霉的部门经理,依据中别忘了取悦客户(老板)(用户)(投资人)列表无限中……
项目工程中,很多人搞不清优先级和重要性这两个衡量指标的区别。所以任务列表中这两列经常被混用。其实这不是由于他不够专业造成的,而是取决于他的立场,他是项目经理还是系统架构师,他是干开发的还是干测试的,他是IT部门还是市场部门。
转一个分级指标的范例:
以处理问题的优先等级来分类
优先级 (Priority) |
预计完成时间预设值 (Estimated Finish Date) |
应变措施 (Resolution) |
1 |
即日完成 |
立即修改完成 (Fix immediately) |
2 |
三个工作天内 |
下一个阶段结束前必须修改完成 (Fix before next stage) |
3 |
七个工作天内 |
产品推出前必须修改完成 (Fix before release) |
4 |
十四个工作天内 |
如果时间允许才进行修改 (Fix if available) |
5 |
本月内 |
在下一个版本再修改 (Fix in next version) |
以问题的严重性来分类
严重性 (Severity) |
指标描述 (Guidelines) |
范例 (Examples) |
高 (High) |
- 缺少主要功能,或者主要功能毫无作用
- 所产生的问题会导致系统停顿
- 所产生的问题导致无法进行下一步测试
|
GPF (General Protection Fault)、Crash、当机 (System Hang)需要重新启动来解决的问题 |
中 (Medium) |
- 主要功能运作不完整
- 所产生的问题会导致系统部份功能不正常
- 所产生的问题宿因严重但不影响下一步测试
|
Access Violation、Exceptions问题多数出于所有测试路径中的其中一个 |
低 (Low) |
- 功能运作正常,但会有一些不一致的情况产生
- 所产生的问题不会导致系统任何问题
- 所产生的问题不会影响下一步测试
|
使用的介面或者接口不一致或者不正确 |
微 (Minor) |
- 功能运作正常,可是有改进的空间
- 所产生的问题不会导致系统任何问题
- 所产生的问题不影响下一步测试
|
并未完全符合使用者习惯或者方便使用者 |
由这两张表格可见,优先级是在描述时间,影响的是进度,而 严重性 (Severity) 是在描述质量,影响的是稳定和架构。
我贴出这两张表的原因是 我要说的原则1:别想排出一个面面俱到所有人都满意的任务序列。排序列的时候牢记你的职位、分工和立场。
下面的问题就由于是我的原则,涉及我的角色和立场——外包技术服务项目的项目经理。
原则2 会对他人造成影响的排在最前面。 造成影响包括:
- 会产生报怨的任务。有些角色的报怨会产生严重的负面影响和压力。为团队和长远着想,优先把报怨解决在说出来之前,及时无法及时解决,展现一个姿态。
- 前置任务。如果某个任务的完成成为其它任务开展的前提条件,提前干完它。(项目经理的主要前置任务基本是是。。写邮件)
原则3 把容易看到成效的任务优先级提前。 包括:
- 快要完成的任务——“这座楼改完啦”的成就感 乘10倍 远远大于 “这个10座楼的小区改完啦”
- 同类未开展类任务中容易完成的——所以项目在进入密集开发的几个月后,技术人员会进入一个“干疲了”的状态,表现为开发效率下降,bug率提高,对优化和全局考虑的积极性下降。原因之一来自技术人员乐观天性导致的挫败感:需要干的事的数量、难度、复杂程序永远远远超出最初的想象。所以,优先开展容易完成的任务。
- 能实现收益回报的——优先搞点收益回报会令你在以后调配资源更得心应手。
原则4: 见这篇专业文章。《CARVER-教你进行项目的优先级处理》