项目管理1

如果有空,想要把以前mFone项目中涉及到的方方面面寻个机会记录下来,这是一笔宝贵的经验.择日不如撞日,逛mypm论坛时突然就有写的冲动,那么今天就开个头吧~

IBM的项目管理方法有13种,它本身是对PMBOK的补充了,下面提到的在mFone项目中很多都是有需求的并且在项目过程中主动或被动的被触发的.站在我的角度在mFone项目中有所涉及并且有一定应用的项目管理方法:

1. 变更管理Change Management

说明:在Dante项目中后期,客户的需求变更非常频繁,我们不得不重视变更管理,并因此产生了很多因事而宜的管理方法,比如产生了确认变更的流程,通过会议来confirm需确认的bug等等,以后再详细的写.

3. 交付管理Delivery Management

说明:做为一个产品化项目一定是有交付物的,Mars项目还停留在随意交付的情况,交付物只有binary package,并且多个研发部门分别向QA交付,导致QA还要承担集成的责任,到了Dante项目出现了多个部门要同时在一个milestone交付多样交付物(如UI文档/镜像等),QA无法也不应再承担集成的责任了,这使得当时的应用部成为所有部门对QA输出的统一路径,交付过程也增加了相对详细的交付说明,配置管理也出现了,另外交付管理由于涉及多个问题,还产生了对多个交付品之间同步问题的解决方案等等.

7. 质量管理Quality Management

说明:在所有的mFone产品中,质量管理是最早被得到重视的,因此我们的项目管理方法中最早成形的就是bug管理系统,在Dante这个项目中质量管理更细化到了每个测试阶段,不同的测试目标等等.

10. 跟踪和控制Track And Control

说明:当同一时刻N多任务在N多个人之间进行,跟踪和控制就被触发了,Leader需要知道每个任务的进展以及是否遇到困难以便及时调整资源分配并且控制预期目标实现的风险,曾经有过很多不同的excel表用于跟踪任务完成的情况,设立专人而且每天晚上还会汇总进度报告,但管理的同时为了得到准确的进度工程师的工作也不得不被打断,也曾经尝试过使用专门的系统由工程师在下班前主动填写进度,但在项目繁忙的情况下专人Push的方法显得更有效.

13. 工作计划管理Work Plan Management

说明:由于Dante项目是产品项目,客户更关心项目时间,因此以往粗略的计划无法适应客户的需求,各部门按照各项目阶段都需要有工作计划,甚至到各人,当然越细化的工作计划就越精确,但mFone的项目几乎就没有足够的时间和人力来应付做计划带来的消耗,因此工作计划虽然从个人到小团队到项目都有做,但很少能持续,有的是用Project,有的是用Excel.

——————————————–

下面还有一些管理方法在项目中有需求触发过,但不够强,即使没有也能过,因此并没有产生真正的方法.

2. 沟通管理Communication Management

说明:从Mars项目到Dante项目,一个显著的变化就是分工更细化了,项目管理部/文档/UI/UX/系统部/应用部/QA等等,一个产品的完成被N多个部门细分了,由此带来了很多沟通问题,比如前期项目管理部对项目计划的制定与RD产生了冲突,前期测试部的测试计划与RD缺乏沟通等等,我想准确的讲沟通管理的问题我们并没有真正的方案尝试着解决,更多的可能还是依靠人与人之间的把握.

4. 事件管理Event Management

说明:这里的事件管理具体指什么,我要再看下PMBOK,不知道会议算不算事件管理,会议是项目中必然的事件,它的影响是可能打断与会者的工作,项目中的各种会议在组织/准备/通知/记录方面我们开始寻求怎样才能达到良好的效果,另一方面对于手机项目的各种测试(如CTA),这种即定下来的肯定会发生的算事件不?对于项目团队共公的或个人的需要处理的事件,也曾出现过使用论坛/网站等工具管理,但由于在事件管理方面需求强度不同,在mFone的团队中个人的会弱一些,而共公的可能需求不突出,往往只是通过邮件进行管理.

5. 人力资源管理Human Resource Management

说明:在项目中始终存在这个问题,尤其是一做就一年的项目,但人力资源管理涉及资源备份等方方面面,在技术团队中相对比较难做,没有真正的方案去尝试解决.

———————————————

呵呵,分的比较乱,还有一些实际上并不是在项目中被触发的,而是在项目总结中被发现的有需求的管理方法.

6. 项目定义Project Defintion

说明:UI/UX的需求比较大,他们开始认为项目定义影响着项目的需求定义,在项目总结阶段大家认为项目定义应该在与客户的前期沟通过程中由项目承接团队产生.(PS:如果这里的项目定义是指需求定义那种…就应该放到上面了,需求定义和变更管理不是一回事,13项里好像没有…去看完了PMBOK再说吧)

9. 风险管理Risk Management(对应PMBOK的风险管理)

说明:开始做项目时是不太care风险管理的,一切先做再说,做了遇到问题再说,项目的前期评估通常只是时间上和技术难度的简单评估,但到了Dante项目中不停出现的广泛意义上的风险时,大家开始想要重视对风险的评估和控制,比如第三方合作的风险,团队中人力的风险等等,再遇到类似的事情时会多考虑一下风险的问题,但整体的项目风险管理方法是在项目总结阶段才出现的,因此也借鉴了成熟的一些方法和经验.

11. 供应商(采购)管理Supplier Management

说明:需求不明显.

12. 技术环境管理Technical Environment Management

说明:需求不明显.

8. 赞助人协议管理Sponsor Agreement Management

说明:需求不明显.

Comments (21)

windows下的Trac安装配置

Comments (18)

小咪的生日

Comments (11)

备忘2

Comments

备忘

Comments

美美的照片片-美美的栖霞山

Comments (63)

咪的照片

Comments (49)

计划-Plan

Comments

2007 Post

Comments

Blog使用习惯

Comments

« Previous entries · Next entries »