如何做需求管理?这8个tips你需要知道(上)

发表于:2022-8-02 09:26

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:今日头条

分享:
  项目管理中的三大难点,分别是需求管理、风险管理和干系人管理。其中就提到,需求管理,是项目管理过程中的一大难点。作为项目经理,能做好这三个方面的管理,项目管理的水平也就达到了一定的高度。
  那为什么需求管理是项目管理中的一大难点呢?我先看看这些场景是不是都很熟悉:
  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等一并确认过的需求,才会被提到需求管理工具中来。这也是我们项目制定的最基本的原则之一。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
价值398元的测试课程免费赠送,填问卷领取吧!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海漕溪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2022
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号