Archived entries for 项目管理

推荐一篇文章 《经济学家如何排队》,还有一篇 《从经济学里的排队问题看效率与公平的矛盾》。

我随便说两句,如何给工作任务队列排序。

任务队列有几个排序原则: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-教你进行项目的优先级处理

最近两次客户IT经理打电话来很忿忿,因为有两个很小的大老板吩咐的问题我没有及时帮他处理好。大老板很有意见,认为我们是拖沓的合作方。

一件事是打印页面上没有byline信息,另一件事是某个推荐区块背景色覆盖需要往上拓展15px。 

接完电话后我都在2分钟内把问题处理掉了。

但是后果已经造成了,显然这事对于大家都很不合算。

前几天做了一个团队角色自我测试,很有意思。我分值最高的角色是主席和工兵。“工兵是很务实的组织者,他把决定和战略转化成详细的、可行的任务,这样人们可以具体操作。他关心的是可行性,他的最主要贡献是把团队的计划转化成可行的形式。他整理好目标,然后有条不紊地推进。如果给他一个目标,他会制定出一份进度表,给他一群人和一个目标,他会炮制出一个组织结构图。他的工作系统、讲求效率和方法,但有时不够灵活。他对玄妙的不能立即对眼前的任务有帮助的花样文章毫无兴趣。但与此同时,他热中于把自己的进程表和建议修改得尽善尽美,以适应一致同意的计划和系统的需要。如果有人不清楚到底做了什么决定、应该做什么,他一定会先去找工兵问。”

在项目团队合作中,我的确是这样的角色,每隔几天就更新进程表,随时能开出各种清单,从需要CDN缓存url列表到需要同步的数据表。分配分工,熟知所有人该干的事,给每个人发不同的任务列表邮件,邮件里排出优先级,列出每项的完成时限。

我自认为干得比较成功的角色类型,为什么会在小问题上栽倒呢。

实际上有一个叫两分钟原则。每天你需要处理的事物中,总有一些是两分钟内可以解决的,由于这些事太微小,可能你都不屑于把它们添加进任务队列,这些事加重你的记忆负担,数量累计后增加你的焦虑感,更重要的事,他们中的许多会被无限耽搁下来,因为你总在干这任务队列中当前重要的事。

如果有两分钟内能干完的事,立刻着手解决。

但是~~下一个会遇到的状况是:你的工作会经常被两分钟事件打断。你开着手机,开着邮件客户端,开着im。永远有人在你状态正好干得热火朝天的时候发给你一堆芝麻绿豆大的事。

原则是:

  • 每天只收2~3次邮件,早中晚各一次,收完邮件,立刻处理两分钟事件,其它的放进任务列表。
  • 干活的时候把IM标记为忙碌或离开状态
  • 从手机和IM来的芝麻绿豆事,暂时记着,处理邮件的时候一块干掉。

另外角色分工不同或出发点不同,所有人对于事务紧急程度的认识都不一样。如果对方不懂技术,他就会认为界面上的问题都是超紧急超碍眼的;如果对方是负责用户的,他就会觉得那些读者来信里的问题再SB也是性命攸关的。但可能开发团队正在火烧屁股拼命解决缓存、查询优化、后台bug之类看不见的问题,正在一边干一边骂。所以在开发团队中安排一个专门解决这类 部门配合(客户服务)问题的角色也是很必要的。


 



Copyright © 2007–2013. All rights reserved.

RSS Feed. powered by Wordpress a theme by Xiqiao.