文章详情

那个客户的需求又双叒叕变更了......

任性小编 1个月以前

1.jpg


变更是项目中最常见的场景,也是最让PM“秃头”的难题之一。


大概一提起变更来,大家脑海中浮现的场景就是:

客户拿着一沓材料对项目经理说,“小王啊(不是我),我们增加两个需求,明天给我做个原型出来。什么?还要钱?这个需求很简单的,就是增加一个审批节点,让程序员改两个小时就行了。就这样吧,明天我要看”。


以上场景不知让多少项目经理头秃。


所以,我们迫切的希望,能更了解变更,更能管控变更,更能降低变更带来的问题和风险,更多享受变更带来的红利。


01
变更-有人欢喜有人愁

变更真的被人那么讨厌吗?

是否有人喜欢变更呢?

简单分析一下,不难得到以下结论:


1.谁喜欢变更

甲方、乙方领导(以及其他享受变更红利的人员)。对于甲方来说,变更可以帮助甲方修正思维偏差,更接近需求;对于乙方领导来说,变更带了直接的收益,和潜藏的机会(新的合同、商机)


2.谁讨厌变更:

乙方团队(其他因变更成本过高造成损耗的团队)。

通常意义下,变更会带来额外的工作量,轻则导致成本增加,进度延迟,重则导致成本过耗,进而直接影响项目交付以及组织发展。


02
变更的定义

想要对变更有更深入的掌握,就要对变更本身有深入的了解,所谓“知己知彼”,才能“百战不殆”。


根据PMBOK的定义,变更是超出项目基准范围外的工作,也就是说,变更的判定的是基于基准的,并非所有额外新增的工作量都应该当做变更来对待。


变更,顾名思义,变,就是不同于基准;更,就是要执行这个变更带来所有的制度上、流程上、文件上、意识上以及人员上的刷新。


变更的本身,是基于基准进行的,是需要进行一系列更新的,是涉及成本的,是会引发交付风险的。


所以,遇到任何变化之前,均需要与项目各项基准进行比较,真正发生改变的才是真正需要考虑的变更,而其他的,类似于由于很多其他原因导致的,不遵守基准、不守规矩的额外工作量并不是真正意义上的变更,是伪变更。


我们真正需要去评估影响、提交需求、走变更手续评审的是真变更,需要抵制的是伪变更。


为了更好地识别变更,我们也应该做到建立一个符合项目交付要求、可验证、可实现、具有指导作用的基准体系。

注:本文重点分析变更,关于基准内容可以后面再研究(可催更)



03
变更的原因和措施

为什么会引发变更呢?

在变更的场景里,甲乙双方都是变更的常客。

除了因为不遵守规则产生的偏离(伪变更)外,真变更的核心原因主要包含以下两个方面:


1.客户方面:思维验证慢,更新成本低


原因:甲方是出钱方,其供需关系位置导致其话语权大,对整个需求方向有指导性作用,且不关注如何实现,主要输出的是想法、思维和逻辑。

在没有落地之前,思维更新的速度、迭代频率是非常高的,且思维创新成本很低。

此外,甲方除了项目诉求外,主要负责人往往还承担其他诉求:令高层领导满意、令用户满意、个人业绩等方面。

因此“一天一个想法”“一会一个想法”“改了9版还是用第1版”的现象发生,也就不奇怪了。


分析:对于甲方的这类行为,项目经理应该进行充分理解并进行引导。

对于客户而言,也许并非其本身意愿,也许在客户角度,“变更”是解决方案,能够帮助其解决眼前的困境,因此一定要协助其充分挖掘变更的根本原因,并找到替代方案。

另一方面,要进行沉浸式管理,打造“同甘共苦”的团队环境,让甲方深刻了解项目变更带来的成本和问题,并指导其为结果负责。

变更并非简单的改变,任何的“牵一发”都有可能“动全身”。


措施:①站在客户视角分析梳理变更,找到替代方案;

②充分引导客户,让其为决策结果负责。


2.团队方面:视角窄化,技术膨胀


原因:乙方团队也是变更中的常客。

对于项目团队核心成员(尤其技术成员,尤其资深技术成员),对变更的不重视程度跃然纸上。

一方面,技术人员过分迷信技术能力,通常以为“顺手调整”就能解决问题,忽略了一个改动带来的影响,忽略了交付目标之间的偏差,并让项目经理“后知后觉”。

另一方面,乙方团队成员的视角相对比较窄化,每人各自负责一块,缺少全局视角的判断力,自然就无法对“变更”有一个全面的评估。


分析:项目经理要背这个督促不严格的锅。

作为PM一定要有基准的概念。在项目立项初期,一方面要规定交付物的标准规范,大家能够达成共识,共同为这个目标去奋斗。

另一方面,也要规定交付过程标准规范,比如项目管理制度、岗位职责说明、沟通规范、驻场交付行为规范、范围管理规范、需求管理规范等制度文件,并严格在项目组内进行推广。

说白了就是给大家立规矩,让大家知道如何规范地开展工作。

比如常见的两个现象,团队成员私自修改架构,属于不符合团队管理规范;私自修改需求,越过项目经理,也属于不遵守沟通规范、需求规范。

对于这些点,在变更前就作为风险灌输给团队,在项目初始就予以明确说明,应该可以规避很多不必要的工作量。


措施:①对目标达成共识,随时纠偏,防止偏离;

②设计可量化基准和制度规范,宣贯给每个团队成员,保证大家遵守。


XXX

项目不是一个技术化过程,而是一个业务过程,这是一个很重要的项目化思维。
项目经理一定是一个业务层面的管理者。
最后记住一句话:在项目中拥抱变更。


阅读 71
0
0
收藏成功