项目管理中的三大难点,分别是需求管理、风险管理和干系人管理。其中就提到,需求管理,是项目管理过程中的一大难点。作为项目经理,能做好这三个方面的管理,项目管理的水平也就达到了一定的高度。
那为什么需求管理是项目管理中的一大难点呢?我先看看这些场景是不是都很熟悉:
1)产品提的期望是A ,结果做出来演示的是B,实际出现很大的偏差,从期望到真正可落地的需求千差万别;
2)比如老板和产品负责人对需求的理解不一致,经常出现已经定好的目标,产品负责人要变更,但老板觉得没必要,项目经理受夹板气;
3)老板经常性的插入需求,导致变更率居高不下,需求变更流程形同虚设;
4)需求落地执行的过程中,一切都看上去挺顺利的,都在按计划执行,结果到验收阶段,各种问题频出:不是功能的缺失,就是进度的延迟,功能看着像是做完了,但各种小问题一堆;
5)多方不断地插入需求,但时间又不允许增加,还要求按原计划完成,导致团队怨声载道,满意度很低。
以上这些场景,是不是都不陌生。事实上,可能远不止这些问题。
那么就我们项目管理日常的一些场景来分析,需求管理的难点在于:
1)需求管理本身,因为项目的特点是渐进明晰,不确定性是贯穿整个周期,而需求是源头,一旦源头有问题,对整个项目全流程都有很大的影响;
2)需求管理“背后”,需求输出、实现、交付、完成,都是由人来参与的,有人参与的地方,人的复杂性,就使得整个链路都不会太简单。比如对需求方期望的真正理解、对老板变更预期的理解、对团队执行过程中的跟进与监控、还有团队执行的满意度。
但作为一名项目经理,我们日常项目管理中,非常重要的一项工作,就是需求管理。如何做好需求管理,非常考验项目经理能力。
今天,来系统地谈一下,我是怎么做需求管理的。
1、了解背景
一位合格的项目经理,在负责一个项目之初时,需要花大量的时间了解清楚项目的背景。我认为这是非常重要的前提。换句话说,如果项目经理对自己所负责的项目背景都不了解,就别提对业务有所了解和理解了。
何谓项目的背景,简单来说,就是这是一款什么样的项目?是什么类型的项目?市场上是否已经有类似的竞品?和竞品相比,项目的优势和亮点体现在哪里?项目的主要干系人有哪些?项目发起人,项目核心管理层的预期是什么?
除了这些以外,还有必要了解清楚,我们为什么要做这个项目?做这个项目能带来的价值是什么?
再更深入一点的,这个项目主要要针对的是哪些用户?这些目标用户,我们的项目是否可以满足他们的期望和诉求?我们项目将围绕怎样的目标来展开,以便满足这些用户的期望和诉求。
为什么要了解项目的背景,其实目的很简单:当了解项目的背景之后,会有助于真正理解业务。也就是说,项目经理是要真正理解业务的。
2、明确目标
当了解了项目背景之后,接着就要进一步明确项目的目标,从项目阶段来说可分为:短期目标、中期目标和远期目标。从产品本身来说,项目目标分为:最直接的目标、业务目标和战略目标。
不论项目内部自己怎么划分,这个不是重点,重点是项目经理需要明确项目目标。总不能一接到项目,就直接带着团队开干吧。
之所以要特别强调明确目标,是因为在实际落地执行过程中,我们很多项目经理往往会忽略这个目标的确定。
我们项目经理的首要事项就是带领团队去实现项目目标,如果目标都不清晰,怎么做好项目管理,更别提具体到需求管理的细节了。
以最直接的目标为例,其实就是弄清楚时间、成本(人力)、范围和质量这四要素。要做这个项目,预计是在什么时间,投入多少人力资源,做多少需求,达到怎样的质量标准,这是必须项,也是项目确定目标非常具象化的。比如我们常常会去界定,项目在某个时间节点上线。这就是最直接的目标。
而业务目标是更深一层次的目标,也就是投资项目的价值是什么,或者说做这个项目的价值是什么?
项目经理在了解项目背景的时候,通常都需要清楚地知道业务目标。执行过程中是以最直接的目标为依托,但真正是以业务目标为导向。因为要达成业务目标,是需要通过一个个已经规划的版本来达成的。
3、界定范围
在目标明确之后,要落地每一个版本,就必然要界定清楚每个版本的范围。这个范围通常可以按照敏捷的MoSCoW法则来定:must(一定有) 、should(应该有)、could or would not(可有可没有)。
MoSCoW法则只是确定范围的一个方法。在确定范围之前,还有一个步骤,就是对目标进行分解。目标分解之后,再针对每个小目标进行范围的界定,这样执行才可以比较有效地落到。
以一个为期一年的项目为例:
1)项目最直接的目标是,一年后要上线测试;
2)为期一年的项目,说长不长,说短也不短。界定范围时,得先有一个整体的需求框架,这个是整个项目的大范围。梳理需求框架的目的不言而喻,就是我们要做一款产品,会涉及到哪些系统功能。这和scrum里面提的梳理产品待办事项列表是一个意思来的。比如下图表格所呈现的模式,把整个一年要做的需求都界定清楚。
这个梳理出来之后,可以让团队对整体的功能需求有一个全貌。当然最重要的目的之一还是为了对整体版本进行规划来的。
3)有了整体的需求框架之后,就可以开始进行版本的整体规划。在做整体规划的时候,项目经理不能完全的去拍个脑袋做一份规划,应该需要和产品负责人进行深入的沟通和交流,确保彼此的理解一致。比如我们最初始的节奏是以两个月为一个版本周期和节奏进行规划。
4)有了版本规划之后,就可以进一步地进行范围的界定了。以beta1为例,要做11个功能系统。这11个功能系统,也会进一步明确,哪些是必须要保证的,哪些是应该有的,哪些是可有可不有的。
可能会有朋友疑惑,为什么进行了版本的规划,还需要去进行需求优先级的划分。这里面主要的原因在于团队的资源有限,进行需求优先级的划分是更有利于需求的落地执行。同时,项目在研发过程中,是一定要预留buff的,以便可以应对各种突发情况。
4、确认需求
范围确定之后,接下来就是确定需求。确定需求这一步,往往是决定需求管理做好与不好的关键步骤。而确定需求,恰恰也是项目经理最容易忽略的地方。
需求管理,最根本在于对需求源头的管理,只有源头抓好了,后面的每个环节才会更顺。所以,具体到每个需求在正式开始落地之前,一定要经过确认。怎么来确认?
敏捷提倡我们小步快跑,快速迭代,但并不代表着对需求的质量输出没有要求。确认需求,提高需求的输出质量,可以借鉴如下:
1)每个需求的输出,是需要在产品内部(游戏的产品叫做策划)经过层层把关的,具体的流程是这样的:
需求模块撰写人->领域负责人审核->领域群评审->主策划评审->制作人和策划团队一起评审->输出需求提交项目经理安排。
2)需求输出之后,需要进行交互的设计,交互是产品需求和开发的一个桥梁。在需求确认之后,还需要进一步明确交互设计。交互的用途在于,把需求以可视化的方式呈现出来,也有利于开发人员进行详细的评估。
互联网或游戏项目,需求的产出都是来自于内部产品经理,项目经理只需制定好相应的流程和规则,处理起来也都还好。
但对于一些甲方和乙方类的项目,很多时候客户提出的不一定是需求,可能是某一个期望。这种情况下,从期望到真正落地的需求,项目经理是需要花费更多的时间来对齐确认的。
这一类的项目,项目经理更加需要了解项目的背景和目标,有了信息的基础,当客户讲他们的诉求时,往往也能更容易抓住核心观点,逐步进行拆解和分解,最终输出可落地的需求。
所以,需求是一定需要经过确认的,而且对于我们项目来说,只有经过产品团队内部确认过的需求,包括项目总监,leader等一并确认过的需求,才会被提到需求管理工具中来。这也是我们项目制定的最基本的原则之一。
5、需求开发
需求确认之后,进入开发阶段。从需求评审到最后验收,是一个闭环流程。详见下图:
需要特别说明的是,需求在开发阶段,需求评审、需求可行性论证、需求的方案设计、技术方案评估,都需要开发和美术的leader一起参与评审,并对结果负责。在需求评审的时候,产品、开发、美术和测试相关的人员都需要参加。
需求的源头确认了,那么在需求进入开发阶段的源头,也需要多次核对并确认。正所谓磨刀不误砍柴工,千万不要认为这个时间花了,还不如提前接入写几行代码。一旦出现被催进度,尽快启动开发的时候,项目经理一定要顶得住压力,把前面的准备工作做足。
以一个需求为例来说,我们看的是整个需求的完整开发周期,也就是从需求评审->需求开发->需求验收->需求测试->需求完结。
需求开发的源头就是需求方案的设计,详细工作量的评估,需要层层把关,对结果负责。试想,如果为了省这个几天的时间,结果导致需求开发完成之后,出现一堆bug,最后验收效果不好,测试过程坎坷,看着前面省了一点时间,但其实整个需求的开发周期都拉长了。
在软件质量里面有一句话:质量是设计出来的。测试人员是质量最后的“守门员”,不要把所有的质量问题都留在最后测试环节。
所以技术方案,详细工作量评估(WBS)这些准备的越充足,一方面是有利于跟进执行;更重要的是有利于保证验收环节和测试环节的顺利。
为了确保验收的效率和测试的顺利,在整个需求开发流程里面,我们还额外新增了自测用例的评审,开发某个需求自测联调结束之后,开发人员需要跑10%-20%的自测用例,通过率需要达到90%及以上,才能正式转产品验收。
当产品验收的体验问题输出之后,需要快速拉起开发、产品、测试一起对齐,落实体验优化,在体验单解决完90%及以上之后,才会正式转测试。
6、搭建可视化
需求管理的过程需要透明化,可视化。市面上已经有很多好的工具。项目经理需要善于借助工具来搭建搭建可视化,建立需求自动化运转流程。
一个好的工具,可以让我们在对需求管理时事半功倍。我们用的TAPD工具非常的强大。
因为每个公司的项目管理工具可能不一样,所以这里不做细述。但用工具需要是为了更好地去提升效率。
通过工具,让整个项目管理过程更加的可视化,透明化。项目经理要详尽一切办法,让能够可视化的都尽量可视化。这也是项目经理的核心价值之一。
至于工具的使用,需求单状态的流转,从宣讲开始,逐步的培养团队养成这样的习惯,这些并不是难事。
同时,建立相应的规则,加以约束,避免部分成员不遵守。对于还有部分经常性不遵守的成员,则在项目管理过程中重点关注,以引导和教育为主。
7、应对变更
世界著名作家、大思想家斯宾塞.约翰逊曾经说过“世界上唯一不变的,是变化本身”。
作为项目经理,我们在带项目的过程中,需要有一个认知:市场驱动型的项目,变是永恒。面对变化,项目经理需要拥抱变化,宜疏不宜堵。
不否认的是,很多项目经理怕项目过程中出现变更,甚至想方设法制定各种流程,试图来控制变更。
从我自身的角度来说,我认为这都是不成熟项目经理做的事情,或者是初级项目经理会做的事情。
而一位合格的项目经理,成熟的项目经理,是需要懂得怎么去拥抱变化,有效地引导和控制变更,做好预期管理。
怎么来更好地应对变化呢?这里要分几种情况来看:
1)项目的范围蔓延和镀金
这是项目经理需要重点关注的,范围蔓延和镀金也是项目推进过程中变化的一种情况。当出现范围蔓延或镀金的时候,会慢慢蚕食项目的资源,或者原本产品需求没有的,额外新增了一些功能,使得原本的计划不断地偏移,团队各种加班赶进度,抱怨声音不断。
这种情况我认为是需要控制的。项目经理需要高度的敏感,一旦识别项目范围蔓延或出现镀金的情况,要及时地进行管控,确保项目在正常的框架内运行。因为资源是一点点被蚕食,可能会不知不觉中进行,当量积累到一定程度的时候,可能会对原有计划有很大的影响。
2)项目执行过程中出现的需求变更
一个项目计划已经按照既定的要求制定好了,并在有序的进行执行中。在做着做着的过程中,发现一些需求的细节需要补充,或者在自测用例评审的时候,发现需要增补一些功能点。
这种情况在实际执行过程中是非常常见的,项目经理不要急着去阻止这些需求,成熟的做法是和团队一起沟通对齐这些新增需求需要花费的时间,然后评估需求的影响面和必要性(或者敏捷谈到的价值)。有了这些数据之后,再去和管理层沟通,给出相应的方案,最终让管理层和团队一起来决策是否需要走变更流程。
如果走变更流程,就重新刷新计划,更新好之后同步全员,按新的计划执行;如果沟通的结论是可以放到后面再安排,则按原计划进行。这里我个人会倾向于开发过程中出现的这类需求细节的调整,尽可能的一次性到位的安排处理。
3)项目执行过程中,有插入新的需求情况
这在很多项目中是非常常见的,插入的需求可能大多来自于老板,领导。老板们的需求自然是要重视的,但如果放任这种情况持续的发生,需求的管理会逐步失控,而且团队的满意度会直线下降,对项目经理的认可度也会大打折扣。
根据我自己的经验,遇到这种情况,偶尔出现一次,管控好预期,应该问题不大。插入的需求或许是业务侧本身的需要,但需求的增加,表明范围的扩大,铁三角中,人和时间都不变的情况下,这个插入的需求必然是会影响已经制定的计划的。这种情况下怎么应对呢?
如果时间和人都不变的情况下,对于插入的需求,可以重新把之前的需求拿出来一起沟通对齐优先级,重新排优先级就好,千万别给老板拍胸脯保证,可以内部消化掉,因为很有可能赶时间完成的需求和预期有很大的偏差,而且团队成员也加班加点,不买账。
如果是时间可以调整,那新增的需求,在当前的人力资源情况下,整体评估完成时间,更新计划,同步老板和团队,按新的计划进行。
如果范围和时间不变,新增的需求可以协调其他人力支持,项目经理也需要更新项目的情况,同步老板和团队。
如果项目经理可以做决策的情况下,以上都可以,但为凸显项目经理的更加专业和稳重,可以将各种方案呈现出来,最终由老板去做选择题,拍板决定使用哪个方案。
对于偶然的情况,以上的策略都是可行的。但如果作为项目经理,你发现已经出现2-3次这种插入需求的情况,甚至未来还会持续的时候。项目经理需要和管理层“约法三章”了,要从源头梳理并重新建立相应的规则,制定插入需求的处理方式。不要认为老板提的需求,项目经理就无条件地去执行。老板也是怕欠人情的,多次提需求,使得项目推进过程出现变化,甚至延期,那就有必要从管理层入手来解决这个频发插入需求的情况。
4)项目目标出现变化
项目目标出现变化,必然会导致项目的范围出现变化。
项目经理要对目标有清晰的理解和认知,要能够根据日常的沟通,尤其是管理层的沟通中,获取有用的信息,以便判断是否对目标有影响。
当然,通常情况下,如果是因为市场的变化,因为政策的变化,使得项目目标要进行调整,这个时候管理层也会主动发起相关的会议,和项目的核心干系人进行沟通对齐。
但切记,管理层的信息对齐只是一个信息的传达,作为项目经理,需要果敢的应对这种突发的变化,要清楚的知道该如何开展下一步的工作。
事实上,本身也不复杂,当目标出现变化时,就又回到了前面第二、三大要点,重新明确目标,界定范围。
因为目标已经变了,再按原来的计划执行下去,做得越多,可能错的也就越多,所以,需要即刻展开范围的梳理和界定,然后重新制定计划。
学习ACP的朋友,这个时候也需要灵活地进行变通,理论知识是说一个迭代内是不允许变更的,但实际项目执行的过程,当出现目标变化,需要果断的叫停一些已经做的需求,哪怕是这个需求即将做完。
在应对变更时,项目经理需要根据实际情况,发挥自己的专业性,对项目重新梳理,尤其是范围,在重新制定计划之后,还需要特别的和管理层对齐预期。
项目的特点是渐进明晰,实际推进项目的过程中,哪怕是风险管理做得再好,也还是会出现一些突发的情况。因此,变更的情况在这里也不能一一枚举。
一位成熟的项目经理,就是当项目出现突发情况时,能够在团队面前处变不惊,并且有思路、有逻辑的展开和推进各项工作。所以,变化是永恒的。拥抱变化,管理好预期,是应对变更的重要原则。
8、产品能力
最后一个要点,产品能力,是说项目经理需要具备一定的产品能力。以互联网项目或游戏项目为例,在负责这一类项目时,可以不懂技术,但我认为是需要具备一定的产品能力,需要真正的懂业务。
当项目经理具备一定的产品能力,能够更充分地理解需求,把握产品意图。因此,项目经理要能够或者多培养自己从产品层面思考,让项目的推进能够更加贴合产品的最终形态,这样更有利于对项目的把控。
在我的认知里面,项目经理绝不仅仅只是排排计划,管管风险,和管理层沟通沟通。项目管理中,需求管理要真正的做得好,项目经理是需要理解业务的,需要花一定的精力下沉到业务线中,要对产品有自己的理解和认知。
具体的产品能力包括但不限于需求的理解和分析能力、产品意识(产品体验和竞品分析)、运营数据分析能力、用户思维等。
当项目经理具备一定的产品能力,真正的懂业务,对业务有自己的理解,在实际推进项目的过程中,也会更加有底气。
在和团队成员沟通对齐目标时,不用担心自己不懂技术而没有共同沟通的频道,一切以目标为出发,就是最好的手段之一。
作者:zhouxu,腾讯IEG研发项目管理,PMP,PRINCE2,专注于分享日常项目管理过程中的点滴,辅以分享职业成长的思考与感悟。著有《谁说菜鸟不能成为项目经理》一书。
如若转载,请注明出处:https://www.vsaren.net/7960.html