PM如何有效防止需求蔓延?

服务 admin 1年前 (2020-08-27) 631次浏览 0个评论
【网友提问】创业公司本就产品迭代比较快,用户需求变更也比较快,产品售后支持还没培训完又出新版本,人员又不足,往往只能研发顶上,但这时便会占用正常开发的安排,如何解决这个问题?

需求变更,可以说是在任何产品开发过程中的“万恶之源”,为了应对频繁的变整个团队不得不加班加点的赶工疲于应付,直接后果不是项目延期,就是质量低下,如何通过各项行之有效的措施,把需求变更基本置于自己的控制之下,使其发生机率和损失降至最低,是每一个产品经理都必须思考的重要课题。

01

需求管理常规三部曲

不管是从多年的产品实践,还是从项目管理的理论出发,所有的项目过程中的需求管理从来都只有三板斧,只是有的时候这套机制发挥了重大作用,有的时候反而导致团队分崩离析,项目彻底走向失败。

1、理性认识变更,积极面对需求

我们需要明确一点,所有的产品开发过程中都不可能真正杜绝需求变更,这是应对需求变更的最基本原则,产品经理和整个团队都必须有相应的预期和准备来应对未来的各种可能性。

因为需求变更出除了产品经理定义和梳理需求不到位之外,还包括市场方向的变化,法律法规的调整,组织架构的变更等等不可控因素,也包括技术储备不够,架构设计缺陷等一系列的因素,在现实工作中还包括“无法反抗的老板需求”。

而往往造成团队矛盾的根本原因,就是在认知上没有理性对待需求,把正常的需求变更搞成了产品与研发,研发与测试的对立情绪,甚至不少情况演变为彼此对工作能力问题的质疑。

项目的成功是团队的成功,依赖整个团队的各个环节的齐心协力,产品经理或者团队领导有义务和责任建立这种团队文化。

第二步:项目前期明确需求和规则

让需求提出方、产品设计者、产品实施的开发者都要清晰、理解需求目标,并对需求进行确认,这是把控需求变更的关键。很多情况下的需求变更,其实严格来说不能真正定义为变更,充其量只是为补坑,弥补因为沟通不够,信息不畅,理解不一致导致的需求偏差

这是很多产品经理在面对甲方需求的时候基本策略,他们希望能够通过合同、签字的需求规格书来确保甲方能够在限定的范围内推进项目,而不是横生枝节,临时提出各种新的需求。

需求偏差的原因还包括对需求的挖掘不够,也包括因为项目管理工具的不适应而导致需求被遗漏等多方面的因素,所以建立通畅的、坦诚的项目沟通环境和条件同样至关重要,确保项目信息的公开、透明和到位。

在项目前期,还需要一项重要的工作就是建立有效的需求管理流程。不知道如何发起变更,不知道谁能确认需求是项目过程中的大忌。另外一种极端情况就是谁都可以变更,所有的需求都被接受,从而导致一盘散沙。

第三步:项目过程中遵循变更纪律

与不知道如何跑变更流程相对应的是不遵循确定的游戏规则。包括出现变更时随意被执行,被执行后的变更没有上下游同步,日积月累就导致各端自行其是,谁也不知道对方在做什么,更严重的是实际做出来的产品和原本的设计南辕北辙,完全无法满足实际业务需求。

不习惯更新文档,不及时同步信息是很多工程师和PM的陋习,他们可能因为时间进展,或者其他原因要么闭门造车,要么独自行动,甚至擅作主张主动“镀金”,都是导致项目失控的源头。

但是,很多产品经理发现,这三步曲经常不能有效的管理好需求,该变更的时候还得变更。需求变更的致命性问题,其实不是不知道如何管理变更,而是多数措施在长期的项目过失效,执行不不到位或者无法执行,才导致彻底失控。

02

从项目故事说 “管理事故”

上文我们谈了需求管理的三部曲,我们来看看实际工作是如何从有序演绎到完全失控。本故事非原创,只是为了分析失控的原因,寻找可能的策略。

时间:项目启动期 地点:经理办公室

老王[部门经理]:小项啊,销售部的这个CRM系统可是今年的重点项目,领导们都很重视,一定要确保按时交付啊!

小项[项目经理]:老大请放心,保证完成任务!

老王:好!不过有些情况还是要注意,这之前的几个拖期比较严重的项目,咱们内部也总结过,差不多都是因为需求变动造成的,这次你可要把好需求管理这道关,别犯过去的老毛病啊!

小项:是,老大。以前那几个项目,都到了开发阶段还在不停增加新功能,才导致工期一拖再拖,这回我们从需求阶段就把好关,老大你也跟销售部的老大打个招呼,需求一旦确定后就不要轻易变更,这样工期也好控制。

老王:行啊,没问题,我就等你的好消息了。

【点评】项目前期阶段已经意识到项目的重要性和过往的经验(在PMP的理论体系中,这属于组织的过程资产,能够有效的提高项目管理的水平),试图通过规范化的流程来确保项目的有序和成功。

这是项目成功的起点,在实际工作中一定要把握这个机会,通过高效的启动后,宣讲会来让整个团队树立流程规范意识,明确责任。

时间:系统开发期 地点:项目组办公室

小李[业务经理]:项经理,我们部门考核销售员拜访活动的规则做了调整,不但要考察拜访的过程和效果,还要跟具体的项目和客户挂钩,进行综合考察,所以之前咱们讨论过的功能需求也有些变化,你看大概需要多久能改完?
小项:李经理,需求都已经定了,代码也开始写了,当初原型演示的时候你们也是同意了的,怎么说变就变?这个属于需求变更,按规定要项目管理委员会评审通过我们才能改,可能得延后交付日期,说不好要多久。
小李:延后交付?那怎么行!上线日期都已经定了,怎么能说延就延?虽说需求我们确认过,可实际的业务发生变化,系统的功能要是不改就根本用不了,这个责任你能负吗?
小项:我也没办法,反正需求变更的流程是这样规定的,要么不变,要变就得按流程走。
小李:哼,行,我找我们老大去,就不信变不了!

【点评】受考核机制的变更,原有设计已经无法覆盖现在的业务,业务方开始发起需求变更。PM试图利用规则来应对需求,并提出风险预警,但业务方认为原有设计已经无法满足实际业务的开展,无法按照原计划进行,并试图绕过PM通过高层来改变决策和原有项目计划。

这里暴露了一个PM常犯的错误,就是有风险意识,没有风险对策。

地点:经理办公室
 
老王:小项,昨天小李他们老大过来找我,说那个拜访考核的变更很重要,直接影响上线后的使用,要不然你就先给他们改了再说,不然系统做出来也没法用,你说是不是?
小项:老大,不是我不给他们改,确实是那个新考核规则太复杂,肯定会影响到项目进度的,再说,不是说要严格控制需求变更吗,如果这次不按规矩走,那以后……
老王:哎,我也知道,这不也是没办法么,他们老大直接来找我,说要是不给改整个系统就没必要做下去了,这样的话咱们到老板那里也不好交待呀!
小项:那变更流程还要不要走?
老王:这个,你先把该改的改了,至于变更流程的文档什么的,事后补一补,做个记录就行了。
小项:哦,那好吧。

【点评】需求方通过“组织权威”或者“业绩压力”,迫使原有的产品方案发生重大变更。作为PM,无法承受来自多方的压力,从而导致原有的规则被破坏,在多数组织,一线的PM们事实上并没有任何决策权力,尽管他们应该临时做出应变。到这个状态,项目已经进入失控阶段,一旦该变更涉及的内容较为广泛,就可能导致整个系统发生根本性逆转,团队不得不付出成倍的努力来修复。

不得不承认,在某些情况下产品发生颠覆性的变更是无法避免的,当发生这种变更的时候,应该调整的整个产品的定义和设计,以及相关的配套策略。一定要避免直接破坏规则来实现重大变更,也事实证明也无法通过“补一补”的简单策略来完成既定目标。

地点:项目组办公室

小郑[QA]:项经理,系统功能里的很多功能点跟《需求库》里对不上啊,下礼拜的阶段评审可怎么做呀?
小项:呃,小郑啊,这不是进度太赶还没来得及改么,要不这个周末我突击一下,把文档给你补齐咯?
小郑:(叹气)项经理,文档可不是写给我的,还有,变更需求库之前是要作变更评审的,你连变更请求都没写,怎么能直接改呢?
小项:唉,这不是没办法么,工期落后快2周了,我差点就焦头烂额了,哪还有工夫作那个什么什么评审的?
小郑:可是,你不是说需求管理和变更的流程要严格执行吗?
小项:咳,此一时彼一时嘛,要是有时间我能不写吗?
小郑:那好吧,记得要在评审前补全……
小项:知道啦。

【点评】任何变更,都不是简单某一个环节做一些调整就可以实现,而是牵涉到上下游的一系列动作。令人遗憾的是,不管是一线的PM,还是业务负责人,他们过于习惯于单点问题,而忽略全盘考虑。他们把精力过多的放在某一个显性的问题上纠结,而从不考虑那些隐形的成本,直到问题集中爆发的时候总是显得措手不及。

时间一天天过去,其间,销售部经历了一次组织架构调整,负责系统需求的小李被调去新的岗位,改由另一个业务经理接任。但是,这位新的业务经理和小李在许多问题上的看法都不太一样,尽管软件已经进入开发阶段,销售部提出的变更却越来越多。

【点评】套用PMP的体系,这属于项目干系人识别不够。2B的产品或者企业内部系统,一定要有足够资深的业务决策人,而不仅仅是负责对接产品需求的代理人。

由于进度已经落后,小项已经没精力去做变更申请的评估,为了让系统尽快上线,他只好来一个改一个,修改完成后再抽点时间填个《变更实施记录表》了事。至于《需求说明书》也根本来不及更新,离系统实际的功能相差越来越远……

经理老王也没闲着,他要顶住销售经理和老板的双重压力,拼命争取给项目宽限些时日。可是不管怎么努力,系统上线的日子依然遥遥无期。老王回过头责备小项,怪他没控制住需求,重蹈了过去的覆辙。小项也一肚子委屈,认为责任应归咎于需求管理流程的虚有其表,根本“管”不住蔓延的需求。

两人各执一词,面对不断拖后的工期,一筹莫展。

【点评】频繁的需求变更,仓促的项目决策,是导致项目崩溃的根本性原因。千里之堤毁于蚁穴,所有需求管理的策略都必须在项目前期被明确,项目中期被贯彻执行,否则很难在接近项目尾声的过程中去争取“宽限”,因为此时的宽限只能证明项目的失败,背锅成为PM的必然。项目管理不是请客吃饭,所有在过程中的好好先生,往往都成为失败的注脚。

对一线的PM来说,很难独挑大梁,有一个搭配饰演黑白脸的角色也许是缓解和平衡矛盾的上策。

03

“解密” 需求管理的命门

你是否正在经历 老王和小项 的困境?

也许细节不尽相同,但我相信这种眼睁睁看着项目失控的无力感,你一定深有体会。

这就是产品开发的焦油坑,特别是创业型的B端产品。作为奋战在一线的PM,你早就意识到需求蔓延的危害,并且采取了一定的预防措施,你寄希望于规范的流程能协助你管理好需求,把控好变更的节奏,但最后仍然是一团乱麻。

就像上文的例子一样,所有的项目需求管理,都会走上一条奇怪的道路,那就是从最开始的严防,逐渐松懈,最后纵容,变成了谁都可以临时发起变更修改既定的需求。

这是项目管理的一大通病。由于抵挡不住业务部门的压力,看上去只是接受了需求的变更,其本质是导致项目流程和项目纪律被破坏了,前期所有为项目需求管理设定的门槛和边界开始模糊崩塌。可当时的情况还没有变得太糟,至少通过一些加班赶工看上去还能够想办法兜住,于是开始隐忍、麻木,最后变成了习惯了。

一场需求灾难由此爆发,需求管理变成随性而为,项目文档变成机械填鸭,一套完整的项目规范和流程,彻底沦为为“形式化的文档”。需求管理的常规三部曲,之所以“常规”,就是因为管理制度执行不下去,根本“管”不住蔓延的需求。

又该如何解决这个问题?为什么好好的流程摆在那儿却没人遵守?为什么看似严密的“需求管理”制度却根本“管”不住需求?

1、PM没有足够的授权

需求变更流程之所以会成为一张废纸,第一个原因就是一线的PM没有相应的权力,他们既无法确定项目的排期,更无法砍掉变更的需求。对他们来说,需求的重要性事实上并不由他们确定,更多的情况下一线的PM只是为了落实领导的意。

他们由于无法控制项目边界,无法调度相关资料予以干预,往往只能沦为背锅侠,严格上来说,他们并不能称之为真正的产品经理。

2、缺乏应有的资源配备

项目管理的铁三角理论,就是要求多大的项目范围就要有对应的项目资源。但显然多数情况下是很难实现的,而当需求发生变更后,项目的范围随之变化,原来估算的任务和进度事实上已经超脱了原来的预想。

遗憾的是,几乎每一次变更的背后逻辑仍然是想要在原来的计划框架达成预期目标。结果是,项目团队不得不加班赶工,相关的项目文档自然被拉下,所谓的质量自然也被牺牲。

3、一切以业务为先导

以订单和销售为主导的企业文化,自然所有的工作都是为了尽快完成交付,需求变更的目的是为了尽可能多的满足客户对交付的要求。他们狭隘的理解“客户是上帝”,但凡客户有一个要求,他们不是夸下海口胡乱承诺,就是随意镀金罔顾既有规则和条件,结果就是“需求蔓延”变得愈发频繁,项目一再出现延期。

4、缺乏清晰的定位

这种情况更多的出现新产品或者创业团队,由于对市场趋势和业务的理解不足,常常由于缺乏足够的前瞻性设计和产品规划,不得不寄希望快速迭代来响应需求,弥补前期设计的缺陷。他们重视功能、轻视成本,结果就是经常性的在核心需求和细节配置上纠缠不清,在非关键性问题上摇摆不定,错失市场机会。

后记

产品的需求,从来都是一个不断演进的过程,没有一个有效的途径来实现杜绝需求变更。要做的是,如果通过合理的引导,规范的梳理把需求限定的可控的范围之内,然后通过快速迭代的方法来满足业务需求。

项目过程的管理,最重要的是如何控制好整个产品的推进节奏,厘清需求的重要程度和相关资源的投放力度,充分授权一线团队对关键路径关键角色的决策权,及时响应市场的变化和业务的调整,才能确保整个过程的质量,以及最终交付成果的质量。

极客公园 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:PM如何有效防止需求蔓延?
喜欢 (0)
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址