推行敏捷项目管理会失败
2022-3-26 07:47:15 浏览61次
     敏捷项目管理,特别是SCRUM如火如土,很多企业都在推广,近日,在服务一家国内知名企业展开企业培训时,听到企业的一位资深项目经理在推广敏捷时遇到的一些问题,该企业的主要业务为国内银行及大型国企业提供软件定制开发等业务,项目周期通常半年左右,大的项目也可能跨越2年左右,之前的业务流程一直是前端签订项目,后端项目经理交付,采用传统的瀑布模型,随着敏捷项目管理的大行其道,公司高层开始重视敏捷项目管理,想着力推行敏捷项目管理,于是组织企业人员参加了敏捷认证等,然后在企业里开始推行敏捷项目管理,但是推行以后,却发现遇到了这样或那样的问题。
 一、产品经理一职形同虚设
   在敏捷SCRUM模型中,我们知道有三个角色,分别是产品经理,项目经理,开发团队,在面向银行交付型的项目当中,产品经理有谁来担任,理想当中是客户方和最懂需求的人来担任,可事实上呢,这个职责是有风险的,即对最终的项目产出物产品负责,所以,客户方的相关方没有人愿意承担这样一个角色,体系内都不愿意承担风险,这个是可以理解的,最终,项目团队还是按照相应的角色要求指定了一位团队内部的产品经理,负责产品需求,只不过这个角色要对接客户,不断的询问客户需求到底是什么,然后根据自己的经验把开发需求固化下来,但是随着时间的进展,客户渐渐的产生了厌恶之情,不愿意过多的回答产品经理的需求访谈,久而久之,产品经理也不太愿意主动询问需求了。
二、团队的项目推行能力降低
   我们知道,敏捷团队强调自组织,敏捷项目经理的角色是服务型领导,而不是命令式的,在迭代周期内,团队有权选择自己认为重要的任务,很多的时间项目遇到任务的问题,项目经理本来想强势推进下,但想想,在敏捷SCRUM中,SM是一个服务者的角色,应该相信团队成员,于是做好服务工作,但是项目的问题却越来越多。
三、敏捷的流程中的部分方法显得多余
    我们知道在敏捷SCRUM方法中,有很多具有仪式感的会议,比如每日站立会,反思会,也有很多工具,比如燃尽图,用户故事等,但是在实现的项目当中,很多会议或工具变得略显多余,以每日站立会而言,第天花十来分钟时间问三个问题,昨天做了什么,遇到了什么问题,今天计划做什么,敏捷实施之初,团队还充满好齐心,还能够坚持下去,时间久了,大家开始麻木了,变成了例行公事,甚至于燃尽图也没有更新,只到被擦除了。
四、项目如期完成的概率以及干系人的满意度并没有提高
    实施敏捷是为了更好的实施项目,并获得项目的商业成果,但是很多企业实施敏捷项目管理以为,却发现项目并没有实施成功多少,于是开始有人怀疑敏捷的价值了。
    我们思考一下,敏捷这些年如火如土,一定有它的原因和价值,项策项目管理培训服务过很多国内外知名企业,根据项策顾问的观察,其实不是敏捷方法有问题,而是我们在实施敏捷前做的准备工作不足。
一、敏捷对组织和团队要求更高
  有效实施敏捷的前提是组织的文化和团队的能级,敏捷强调自组织,授权,服务型领导,但是如果组织的文化与敏捷宣言里所倡导的不一致,你会发现敏捷一定会出现这样或那样的问题,还有,组织的团队能级是否能够支持敏捷所要求的那样,具有高度的自律,也是需要思考的。
二、客户的配合性
   敏捷的实施其实不是只关注的组织本身,还要关注客户组织的敏捷性,以本案例为例 ,客户是否对敏捷了解,是否对敏捷项目管理价值有充分的认知,愿意去配合敏捷当中的方法论,并且相认团队可以交付所期望的产品,在敏捷方法论中,难以想象,脱离了客户对敏捷的支持,敏捷项目上能够成功。
三、组织的业务特性
    在企业组织当中,每个企业的业务体系都不一样,不能为了敏捷而敏捷,对于确定性项目,即范围和需求非常明确,不确定性较低,其实不一定非要实施敏捷,瀑布型的管理方式也许是一种更好的选择。
四、全员是否对敏捷有相同的认知
  在企业当中,如果企业的全员对敏捷都没有共同的认知和了解,我相信推广敏捷一定会铩羽而归,所以在推行敏捷前,企业要组织全员培训,并考核,使全员都具备相同的敏捷思维,敏捷项目管理才会事半功倍。
 
  总之,企业推行敏捷之前,要进行文化,团队,成熟度,业务,客户等几个维度进行评估,评估成功后才可渐进推广敏捷,企业不能为了敏捷而敏捷,其实敏不敏捷根本不重要,重要的是那种方法可以驱动组织业务目标实现,这样的方法,就是好方法。