推荐一篇文章 《经济学家如何排队》，还有一篇 《从经济学里的排队问题看效率与公平的矛盾》。
我随便说两句，如何给工作任务队列排序。
任务队列有几个排序原则：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-教你进行项目的优先级处理》
