qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

项目管理杂谈

项目管理有个前提,资源稀缺,如人力、时间、资金等。比如,有一个政_府官员,有一笔拨款,于是上了一个政绩项 目,这类项目一般不缺资源,所以也不需要进度管理,做啥时候就啥时候,更不用项目管理软件。如果进度拉长可以增加预算,于是得到更多灰色收入,那么效率可 能是一种负担。我不是危言耸听,你看中国有多少.gov的僵尸网站?

  项目管理 vs 人的管理

  其实,标题的意思是,项目管理过程中,关注于项目,还是关注于人。是人适应项目,还是项目适应人。

  偏向于人的管理,即人本管理,我认为,对于像软件这种思考型行业更有效。因为思考型行业的管理,本质是人脑的管理,人心的管理。人脑的管 理,就是将人的智商充分发掘出来,高效率地工作;人心的管理,就是让员工自动自发、培养其责任感和热情。管理是因为不协调才需要约束,如果大家自动自发、 有责任感,还需要把管理挂在嘴边吗?

  最好的管理,是员工感觉不到被管理

  任何外在的手段,无非是让其产生压力、恐惧,如被淘汰、降薪、加班,通过这种力来推动项目。但人的效率,只有在充分自由的环境下才能够发 挥。引力(激励)比推力更有效。《人件》比任何项目管理工具书,更能从根本上解决问题。

  项目的风险,往往来源于人的风险,如沟通不畅,上下不齐心。

  信任本身就是一种约束,监督会加强团队的隔阂。

  激励比控制更容易规范员工行为。

  如果说在项目管理和人的管理间找到一种关系,那就是:设定目标,然后站在执行者的角度考虑问题。

  项目管理的前提,是人的管理。人的问题解决后,再来谈管理项目。

  项目管理,本质上是关注如何在有限的资源下,达到设定的目标。所以,它涉及到成本管理、进度管理和人力管理等资源方面,范围管理和质量管理 等目标方面,以及达成目标所需要的沟通管理和采购管理。

  成本管理 打个比方,计算器可以为我们DIY电脑时省钱吗?

  人力管理和沟通管理:关键是处理人的关系,关注当事人的利益

  范围管理:也许写在纸上大家也就明白了

  质量管理:决定于流程和执行力度

  采购管理:就看PM的商务沟通水平了

  也许,项目管理软件,最后会简化到一个进度管理和任务分配工具,而进度管理,往往Excel甘特图更实用。

  当然,我说的是中小型项目,大型、规范的项目和团队,可能就很依赖于项目管理软件来做进度。

  完成项目,需要一种方法,这种方法可能就依赖工具,也许工具本身就提供一种方法。工具有一定的使用环境,就如同我以前一篇文章中, 谈到的一段经历:

  Bug管理

  Bug管理,这两年,我们经历了三个阶段。

  先说说使用环境吧,因为这是 决定一管理软件是否适合的最核心条件之一。

  人员:有开发人员和不懂软件的业务人员 问题主要是业务员提出

  距离:原来一年大家在一个办公室,后来IT部和业务部分,距离约1km

  项目:旅游电子商务网站,包括前台和后台。这类网站重业务和用户体验,技术上没难度

  最开始,使用的是Bug管理系统JIRA 用了约一年,基本上是推,业务人员不适应,最后我觉得反馈一个问题很烦琐,自己主动废弃了。

 后来,使用Excel,当然这是为bug管理定制的Excel,执行一个月就觉得不行,因为问题汇总、截图等不方便,简单问题这样汇报似乎也太累。

  最后,使用Foxmail邮件用得非常顺,特别是业务部和我们分开情况下。因为邮件有三个特性很受用:抄送人,延迟执行,贴图。

  有些很小并且及时的问题,直接通过QQ完成。

  反正,在我们这个小团队,最后一种方式,直到现在都觉得很适合我们。

  其实,在Bug管理的背后,有一个非技术支撑:信任。我们的重点不在责任界定、责任追究等和权限有关的事情上,我们只关注目标:问题被及时 发现、及时解决,以及解决过程中的低成本协作。

  开始应用一款项目管理软件,都存在不习惯、甚至抵触的问题。最难的是改变人的思 维习惯,其次才是行为习惯。前者需要有效的培训和辅导,培训的效果,取决于团队成员多大程度的认同而不是会用,后者可 能需要痛苦的练习。

  项目管理 vs 过程管理

  能够将这两个概念清晰区分的人,一般都有真正的项目管理经验。前面说过,项目管理,本质上是关注如何在有限的资源下,达到设定的目标。项目管理,本身和具体开发的实物无关,比如甘特图几乎可以描述任何项目。这就是为什么有些项目还会有产品经理。过程管理,本质上是实现具体实物所需的步骤或流程,而它和具体实物、以及项目团队关系很大。

  我将两者拿出来比较,主要是因为,我觉得项目的成功与否,与采用的过程关系很大,而这在项目管理软件中很难体现。比如开发企业信息系统,要 建立数据库:

  如果是大项目,可能有专门的DBA负责建库,不需要和谁一个个字段确认。

  如果是中小项目,可能是PM或PL负责建库,也不需要其他人确认。最混乱的情况是,各模块开发人员自己建表。

  如果是偏产品,小团队,比如我建立过一个流程,对我们很实用:

  引用

  1、项目经理先和某开发人员沟通需求及业务字段

  2、开发人员在一个规范的Excel表格中建表

  3、告知经理,review一下字段命名及类型等,微调

  4、开发人员在开发数据库中建表

  5、建完后告知经理,再次review

  这样,把本来建库的繁琐工作授权给开发人员,解放了经理,也提升了他,还保证了质量。过程其实非常敏捷。

  权力并不会带来真正高效的的管理

  可能有人说,我也带过项目呀?如果你带的一批人,一开始都和你关系不错,直到项目结束,你可能并没有接触到真正棘手的管理。当你的项目组,都是一批 有个性、工作性质不同的人,你这时候才会深刻体会到,沟通、协作有多大的挑战,如果再加上一个项目期限,我姑且抛开项目本身的业务复杂性。比如,技术牛 人,往往很有个性,喜欢自己来一套,不遵守团队规范,并且不太喜欢主动反馈,因为自我感觉都OK。如果强推规范和流程,往往会埋没一位人才。

  还有一种情况,就是大公司的“资深”项目经理,这类人往往受公司高层支撑,比较强势。如果遇到项目组某成员不服管,往往是,要么打入冷宫, 要么驱逐出队,而不是站在员工角度,和他沟通。这种行为可以理解,因为找刺头沟通很烦,再说替换他毫不费力。这样的资深的项目经理,往往并没有多少管理经 验(管理=管人+管事),因为权力并不是领导力,权力并不会带来真正高效的的管理:员工主动性、责任心。再说,他并没 有利用好资源。如果该队员是他带入的,这样做,是一种对己对人都不负责的行为。对于项目经理的他,选择即责任。

posted on 2011-12-07 11:31 顺其自然EVO 阅读(126) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2011年12月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜