项目管理的一些感悟

     做了几年的项目管理工作,对项目管理的感悟作一总结。

     很多人都是从技术转到项目管理的,我也不例外,刚开始总会习惯的以开的角度去看待问题,特别对于技术依依不舍,忽略了项目管理水平的提升。而且管理工作做得非常累,总有做不完的事。心里也时常在问做项目是否一定要对技术非常了解,了解到什么程度才算够用。慢慢的这些疑问开始找到答案。我的体会是“需要了解优缺点,但不是每个细节”。

     项目管理主要涉及到 需求管理、风险管理、质量管理、进度控制、资源管理、团队建设几个方面,而对于不同的项目每一个阶段的管理方法都可能存在一些差异,软件开发本身就不是那种重复性的工作,项目能否成功项目管理者起到决定性的作用。这话不太夸张。

      首先讲一下项目计划的制定,至关重要的一个环节,不管是用什么模型的开发流程这都是项目中非常关键的一个环节,这是一个项目所有工作开展的前提。项目计划中包括整个项目的任务拆解、资源安排、各个模块之间的依赖交互时间、明确每个人的工作职责、项目沟通机制约定。

      要想做好项目计划,我们首先问一下为什么要做项目计划?

      古人云:“凡事预则立、不预则废”,项目计划和我们开发在设计时做得建模的目的类似,都是为了更早的验证我们的设计是合理的,是可行的,所以我们项目计划第一个目的就是论证我们的在给定的资源内可以完成相应的需求。当然这个计划不是PM一个人YY,然后发给大家,通知大家开工了。这样的计划排了不如没排。WBS的过程一定要让开发一起参与,也可以关键人员参与,通常我会让每个模块的负责人对于自己负责的工作估算出工时,然后收集大家的预估结果,并check其合理性,对于有偏差的部分了解到具体的原因,要了解真正的原因,不一定靠你的技术功底,重要的学会怎么问问题。最后排出合理的项目计划,并且在公布项目计划之前要和每一位开发过一遍。目的在于充分尊重开发的工作,也是一个检验计划合理的重要环节。

      需求管理:

      在项目计划中应该有对于需求变更合理流程,需求变更原则一定是对项目有利,但决不是只要有利就变,也不是什么阶段都可以变更,PM要根据当前项目进展状况、需求本身、可能造成的风险、是否导致项目整体计划调整。

      质量管理:

      对于测试,我们要关注测试计划、测试方法、是否需要性能测试、性能测试的结果不理想,可能需要调整架构,所以条件成熟,尽量提前做性能测试,bug修复机制,最好日结,如果修复不完的需要加以注释,尽早发现项目中可能存在大问题。

      质量管理也包括项目中每个阶段的评审,BRD评审、DEMO评审、UC评审、设计评审、TC评审、发布计划评审等,这些评审都是为了缩小每个阶段给项目带来的影响。例:简单的一句话,被10个人传一遍很可能就变了意思。

      进度控制:

      当发现进度和计划有偏差时,PM需要及时的找到原因,并施加影响。进度check周期不能太长,也不能太短,不同阶段不同项目也会有所有不同,最长不应该超过一周时间。

      团队建设:

      这是最灵活,也是比较容易忽略的问题,当然也是非常重要的环节,很多时候项目团队是临时组建起来的,怎样让这个临时的团队发挥作用,PM需要了解每个人的背景及性能特点,在项目初期让每个了解项目目标,明确每个人的职责。项目目标激励,让大家对项目充满信用,慢慢的大家会发现项目中遇到的问题远远不如预期的少,开始郁闷了,PM要多关心项目成员每个人的遇到的问题,协助帮忙解决。磨合期过后,团队凝聚力最高的时候,效率较高的时候。最后是准备交互阶段,在不同阶段针对不同情况PM应该给予相应的激励,这里不一一列举,有物质激励当然最好了。

      资源管理: 主要是根据项目情况合理分配,所谓“好钢要用在刀刃上”项目成员的个人成长,成就感,职业发展都需要考虑周报。

       风险管理:尽早的预知风险并制定有效的风险规避计划,也是保障项目顺利发布的必要活动。

       以上是PM需要考虑到的一些问题,没有给出解决方案,就算给出也不一定用得上,每个项目都有自己特殊的地方,要结合具体项目具体对待,不要盲目听取专家的话。

     

猜你喜欢

转载自sagehu.iteye.com/blog/871452