产品经理如何有效进行需求管理?

需求是整个软件项目当中最重要一项输入。软件开发和传统生产行业最大的区别在于,需求总是模糊的、主观的和随时变化的。相对于电子产品、汽车等制造行业有形的硬件需求,软件开发的需求的描述和验收是个难以解决的问题。

但是需求又是整个项目能否成功的决定性因素,所以我们必须对需求进行管理,从而使需求成为整个软件工程的基线。使得所有产品、设计、研发、测试、运维工作能围绕着统一的需求开展。保证项目能顺利进行,完成目标。

需求管理的难点?

一般情况下,需求难以管理的原因有以下几方面:

1、需求描述的问题

一般来说,最容易造成开发出来的产品与设计功能不符的原因便是需求描述的问题了。其实大部分情况下,写需求文档的人没有错,看文档的人也没有错。共享文档不等于达成共识。只是因为面对同一段描述,人与人之间的理解不相同,而且这种情况是一定会发生的。所以对于需求,一定要基于团队面对面讨论,保证对需求的理解一致。

2、需求变化的问题

需求变化的原因很多,如一开始没有识别全,新增需求;业务变化导致需求变化;需求有误;需求不清晰等。需求变化将导致从设计方案到编码测试的修改,延迟交付,带来诸多麻烦。这就需要团队在迭代进行前,尽量保证需求清晰明确。

3、需求的优先级及排期问题

什么样的功能能对用户产生最大的价值,这是需求管理中最重要的问题。因为在软件开发中,你想要开发的功能,永远比你能投入的资源多。因此,找到这一部分最有价值的功能,优先处理,尽早交付,才是需求管理的核心所在。

如何对需求进行分级管理?

敏捷开发中,用户故事被广泛使用,但是我认为仅仅使用用户故事是不足以很好的管理整个项目的。(关于用户故事的诸多好处,就不在此多说了。)用户故事可以描述出真正有价值的需求,也能提供优先级和故事点规模为排期提供依据。但是繁多的同级用户故事会让人迷失在其中,只见树木不见森林。每次的交付和发布都会变成功能的东拼西凑,甚至有时候还会为了单个功能的价值,偏离整体的产品愿景。

因此,我们推荐按照 Epic Story – Feature – User Story 的层级顺序去管理需求。团队也可有自己的层级关系定义,取决于团队的喜好。

按照Epic Story-Feature-User Story对需求进行层级划分的好处在于:Epic一级可以与产品战略对齐,Feature一级作为版本发布规划的对象,User Story则进入迭代进行研发。

1. Epic Story

Epic Story即史诗故事,简称为史诗。一般史诗被定义为一个非常大的用户故事,是产品中的主干任务或者公司级战略举措,一般情况下会持续数月。我们对史诗的风险、业务价值、工作量进行评估,得到史诗的优先级,再依据优先级对史诗进行排期。

image.png

2. Feature

Feature即特性,特性是能对用户提供价值的完整功能。描述了产品具有的一个完整功能,特性一般也比较大,可能持续数周,横跨几个迭代。一般作为版本发布计划的规划对象。我们依据特性的风险、业务价值、工作量评估特性的优先级,进行版本发布的规划。

image.png

3.User Story

User Story即用户故事,用户故事是能对用户提供价值的功能场景。一般来说,特性可以拆分为多个用户故事,每个用户故事都对用户有价值,但是单个用户故事却有可能不能被用户正常使用或者是整个功能的细分场景。我们会对用户故事的故事点进行估算,放入迭代计划中进行开发。

image.png

在Worktile,我们如何管理需求?

一、需求收集

Worktile的需求来源主要有四种:

  • 用户反馈给业务线同事的需求。
  • 公司内部同事提出的需求。
  • 用户通过产品内帮助中心-用户声音直接反馈的需求。
  • 产品经理规划的需求。

1、前两种来源的需求都汇总在统一的需求收集项目中,要求提出人以用户故事的形式创建,描述出具体的用户场景。

image.png

所有需求反馈都以用户故事的类型创建,由产品经理进行评估。确定采纳的需求建议再进一步分析,依照故事的规模和影响范围决定其属于史诗、特性还是用户故事,在对应项目的需求规划中响应。

2、用户在帮助中心可以提交自己的需求建议,也可以对已有的需求建议或者我们的规划进行点赞,提升其在队列中的排序。

image.png
image.png

这一部分需求,产品经理会通过后台查看,分析评估之后,考虑在对应项目的需求规划中响应。

二、需求实现

1、产品经理会在对应的项目中按照史诗-特性-用户故事的层级,对整个产品的功能框架进行整体的需求规划。

image.png

2、对已规划的需求进行优先级的排序,来确定正在进行中的史诗里,哪些特性需要在接下来的版本进行发布。将其规划入对应版本。

image.png
image.png

3、将进入发布版本的特性拆分为用户故事,对用户故事进行估算以后,按照迭代容量安排开发计划。

image.png

4、进入迭代的用户故事会按迭代周期进行交付,更新特性的进度。特性验收完成后更新所属史诗的进度。由下而上的推进整个产品的开发进度。

image.png
image.png

通过对不同层级需求在不同维度上进行管理,使得整个需求管理流程更清晰流畅,极大程度的提升了需求管理的效率,聚焦了产品目标。

文章标题:产品经理如何有效进行需求管理?,发布者:刘佳,转载请注明出处:https://worktile.com/kb/p/6474

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
刘佳的头像刘佳
上一篇 2022年3月19日 上午12:59
下一篇 2022年3月20日 上午12:52

相关推荐

  • 研发管理工具选型要考虑哪些内容

    研发管理工具选型需要考虑六个因素,分别是:1、功能性;2、非功能性;3、易用性;4、产品价格;5、服务;6、厂商。其中功能性在研发管理工具选型过程中是最基本的影响因素,直接影响到是否可以满足团队的业务需求。 不能根据单一因素就决定某个工具是否合适,必须结合各种因素来做综合考量,不仅需要考虑产品对需求…

    2023年2月2日
    64800
  • 什么是ProductBacklog(产品待办列表)

    产品待办列表(Product Backlog)指的是敏捷开发框架Scrum模式核心工件之一。产品待办列表是永远不会完成的,它是产品所有已知需求的优先级排序表,为了确保产品是有用的、有竞争力的,列表会不断地变化和调整。 产品待办列表(Product Backlog)指的是敏捷开发框架Scrum模式核心…

    2023年2月2日
    53100
  • PingCode怎样管理看板(Kanban)项目

    在PingCode实现高效的看板项目管理,除了预制的流动模型(需求池、设计、研发、测试、发布)能够用来管理比较普遍的产品交付过程;同时,PingCode-Kanban项目提供了自定义功能,支持自定义栏、泳道等,创建团队自己的价值流动模型。 首次年度《看板状态报告》显示:大部分团队采用看板的首要原因是…

    2023年2月2日
    98800
  • 有哪些产品经理常用的工具

    产品经理常用工具有非常多,其中就包含:1、用户需求调研工具;2、产品/需求管理工具;3、产品原型与设计工具;4、思维导图工具;5、产品文档写作与在线协作工具;6、团队协作与项目管理工具;7、测试/缺陷管理工具;8、图片素材与处理网站;9、数据/统计;10、代码托管平台等。 软件或工具只是为了表达我们…

    2023年2月1日
    96900
  • 有哪些常用的bug管理工具

    国内外最常用的bug管理工具有:1、Excel;2、PingCode;3、Worktile;4、Bugzilla;5、禅道;6、Jira;7、ClickUp;8、Zoho bug Tracker;9、Asana;10、nTask;11、Mantis。用Excel来管理的优点是上手容易,本地操作,速度…

    2023年2月1日
    87500

发表回复

登录后才能评论
注册PingCode 在线客服
站长微信
站长微信
电话联系

400-800-1024

工作日9:30-21:00在线

分享本页
返回顶部