需求的变更发生在任意的一个项目过程,它针对的是一个过程的影响,进而给整个项目带来重大甚至致命性的影响,轻则延期发布,重则分崩离析。 作为项目经理,要理解一个概念:项目的铁三角(范围S、进度T、成本C),当然也可以说是项目的四要素:范围、进度、成本和质量。 S、T、C三者之间存在强烈的制衡关系,当你需要扩大/变更范围(也就是需求边界)的时候,一定会给进度和资源的投入带来影响,变更的范围越大变更的频率越高,则对进度和资源的影响越大,也就是你不要奢望“又想马儿跑,又不给马儿吃草”。由于S、T、C之间的制约关系,产品的质量必然随着需求的变更带来影响,而且往往是负向的影响,最坏的局面可能是产品质量急剧下滑直到演变为质量事故,而团队的士气也会随着频繁的变更而低落甚至崩溃。 变更通常意味着当前的项目路径摇摆不定和失去控制,人可以适应变化,但对未知的世界会感到恐惧,简单的说就是“不知道你的需求什么时候是个头”,当团队失去盼头的时候,就会像推翻了潘多拉魔盒一般。 管理需求变更的目的不是为了要避免变更,而是有序控制变更,减少和降低需求变更对项目的影响,包括成本、进度和质量的影响。 一般情况下,需求变动是常事,作为项目经理,首先要做的第一件事就是要明确规则,启动项目之前首先要搞清楚边界,梳理好规范,什么是必须要做的,什么是可以变更的,通过什么机制,流程来实施变更等等。项目经理的一个重要职责就是确保团队始终朝着确定的方向前进。 任何项目都有一个特色,那就是项目开始之前群情激昂,至于过程和结果,有的怨声载道,有的劫后余生,万象丛生都很正常,越大的项目故事往往越多。在事情还没正式开始时,往往什么话都好谈,制定规则也相对容易,所以这个良机千万不可错过,必须在确保所有干系人头脑清醒,态度温和的动工之前,把未来可能预知的风险尽量评估,并形成有力的项目环境,以及良好的决策沟通机制。否则,可能会面临诸多不可调和的矛盾。 作为项目经理,尽可能的丑话讲在前头,为未来的荆棘之路清理掉一些沙子石头。 (1)重视需求变更 作为项目经理,首先要能深刻的理解变更将给团队带来巨大的影响,需要在战略上保持清晰的头脑,只有在有序、可控的情况下,才能确保项目的按质按量的交付,通常都不可能在频繁的接受需要变更的情况保证项目的质量和进度,以及资源投入。 还需要让团队深刻的理解需求变更的代价,任何在项目之初的轻视都会埋下隐患。 (2)统一需求入口 另一点非常重要,就是控制需求入口,搞清楚要做什么,该做什么,以及能做什么。 所以,需要牢牢的控制需求的入口——需求的接收渠道和管理平台,它决定整个项目的边界范围,为此,应该有足够的心里准备,需要面对N多方的压力,甚至,为了项目交付的这一终极目标,需要有不惜得罪人的思想准备。越是大项目,越是牵涉多方的项目,风险和协调都会是指数级的放大。 当一个项目,失去统一的需求入口,当一个项目经理失去对入口的控制,意味着项目的失控。 (3)评审后再动手 “不要着急做”,“不要任何人接到需求就开始动手”。 需要让整个项目团队,理解并遵守一个基本原则,那就是所有未经过评审的需求,只可讨论,不可执行。 这里其实是有一个例外,那就是技术本身驱动的变更,比如有更好的实现方案可以带来性能的提升,这个情况,需要根据整体项目状况,结合技术本身的能力判断。 (4)保持持续跟踪 俗话说“好记性不如烂笔头”。任何需求,都必须记录在案,甭管是否执行,需求的第一个动作就是备忘,第二步才是决定是否执行。 完整的需求变更记录将有助于了解整个项目情况,包括执行的需求,被拒绝的需求,需要一个“需求池”统一管理来自业务端、技术端的需求,并针对项目中出现的资源、时间等因素可以合理的进行调配。 今天被拒绝的需求,不等于将来也会拒绝,今天已经执行的需求,也不代表未来依然可行。 |
|
来自: 阿明哥哥资料区 > 《59.项目.质量.现场管理》