项目管理中的快与慢
来源:互联网 发布:动态ip绑定域名 编辑:程序博客网 时间:2024/05/02 01:16
最近我们组内一位项目经理同我讨论他为什么在最近开始的一个项目(项目已经开始了2个月左右)中做的非常累,在公司的咖啡吧他向我描述了他目前的工作场景一些工作场景:任务输入多、所有事情都需要PM去跟踪落实、这个项目又是公司的旗舰产品不得半点马虎和松懈。听完他的描述后,我给他描述了以下两个场景由他考虑以后的项目管理工作是否需要改变。
场景一: 作为项目经理我们每天可能会从不同渠道接收到不同的需求、变更、bug,甚至是客户投诉,抑或是线上问题反馈,然后项目经理立即响应每一个输入,这里说的响应是指立即将任务分配给相关的开发同事进行修改和后续的测试人员验证。我们先来看看如果把这些任务立即分配出去的情景可能是这样的一个画面:项目经理每天通过某个任务/bug工具甚至邮件或IM向项目组同事分配若干个任务,每个任务的截止时间基本上是越快越好(英文里的:ASAP),然后团队成员每天手头的任务可能会被打断若干次,很多事情都是部分完成,是真正完整做完的任务少之又少,过不了几周整个团队会感到疲惫不堪、男默女泪。同时项目经理也会感觉到整天是在救火,疲于奔命;感觉到团队生产率低下,深深的陷入到 micro-management 的泥潭中,这样的工作方式看起来是很快的,因为每个任务都在第一时间分配下去了。
与之相对应的另外一个可能场景二是:不同渠道汇集而来的任务、bug、投诉需要第一个接收到信息的人或者是某一个接口同事记录到团队的任务流工具中(例如:JIRA,Bugzilla,Redmine等),然后项目经理召集相关同事(如开发、测试、需求负责人等)定期的review这些任务(根据具体情况可以使每天、每周或每两天都可以),把这些新接收到的任务和目前团队正在做的事情统一排一个优先级,并且尽可能少的去中断团队成员目前手上的工作而切换到一个新的任务上,一旦某位同事完成了手头工作就去系统里面选取一个还没有被人开始做的最高优先级的任务来做。经过一段时间后团队就能自发进行任务选取了,项目经理也有更多的时间去观察和改善团队其他方面的事情了。这样的工作方式看起来好像很慢,因为每个任务到达后都不是第一时间分配出去的。
以上举例的两种场景你更喜欢那种呢?是立即分配任务型,还是让团队自己按优先级选取任务型?相信大部分人期望是第二种,如果你目前的工作情形是第一种画面,那么请考虑一下是否得尽快建立相应的流程机制来规范了,更重要的是能够把团队围着项目经理转变成团队围着任务优先级而转。
PMBOK上说项目经理~75%左右的时间是花在沟通上,那么我认为项目经理开始一个新的项目时,需要尽快通过沟通在团队内部建立基本的任务处理流程、内外部的沟通渠道是至关重要的,而不至于陷入救火是常态的情景中,也就是说项目经理需要创建一个大家可以高效工作的流程和环境。
- 项目管理中的快与慢
- 快与慢 0
- 快与慢
- 思考,快与慢
- 思考,快与慢
- 一生,快与慢
- 思考,快与慢
- 学习过程中的快思考与慢思考
- 快与慢[By tina]
- 快衰落 与 慢衰落
- 分页语句的快与慢
- 项目沟通管理中的问与答
- 软件项目管理中的几个问题与分析
- 数据仓库中的慢变化维度和快变化维度
- iOS_使用金山快盘管理项目
- 试论项目管理中的冲突与沟通管理
- 验证快就是慢、慢就是快
- 编码,快与慢:开发者和过度自信心理学
- 历史记录
- 约瑟夫环
- 条码扫描二维码扫描——ZXing android 简化源码分析
- vb报表的设计
- Android自定义照相机实现
- 项目管理中的快与慢
- Opencv2 学习笔记<一>:cv::Mat数据访问方式
- 应用位运算 c语言实现比较:
- HTML那点事之【基础标签(01)】
- 整倍递增进位
- HDU 3311 Dig The Wells(spfa+压缩DP,5级)
- 带参数的main函数
- larbin配置
- Uva 11121 Base -2