当前位置:   article > 正文

需求管理 | 如何有效的进行需求规划、实现、协调管理_需求管理 需求实现

需求管理 需求实现

对于PM来说,要管理好需求,离不开四个层面的列表管理。

这里写图片描述
1、Feature List:需求特性列表,日常的需求管理,管理好了,治大国如烹小鲜,管理不好,每时每刻被动煎熬。

2、Feedback List:反馈列表,各个渠道反馈的问题记录,可能有用户的骂声,Thats Great!,用户的痛点出现了!维护好反馈列表,有可能会转化为需求。

3、Bug List:缺陷列表,自己经常把玩产品过程中遇到的Bug记录或者交互异常问题,严重则进行立即修复Hot Fix发版,不严重下个版本顺带解决,当然也可以使用TAPD、禅道进行管理。

4、Version List:版本列表,每次发版内容记录,版本新特性记录。Review每次发版,进行功能效果评估。

这里写图片描述

本次主要简述用户需求管理中的Feature List,需求功能管理:

现实中关于需求管理会出现很多问题,诸如:

  • 需求跟着跟着跟丢了,没有记录导致的
  • 需求开发周期长,需求忘记了,没有记录导致。
  • 需求来源渠道不明,没有记录导致。
  • 需求太多、太复杂了,无从下手,没有树立需求池的概念。

明白了没有记录就没有发生,就很难再出现扯皮的现象了,显然需求的记录和管理是很重要的,这是产品的基础能力。

需求的来源也是很广泛的,诸如:

  • 来自用户研究、调研、访谈的
  • 来自数据分析的,数据驱动产品迭代
  • 来自Boss的
  • 来自市场部、商务部的
  • 来自运营团队的
  • 来自各个渠道的用户反馈的
  • 来自脑暴峰会的
  • PM自己想做的等等….

可见需求来源太多了,先不说如何辨别需求的真伪,单纯的管理需求似乎就成了问题。

那么,如何真正意义上的进行需求管理呢?

需求管理应该分为三个层次,需求侧、技术侧、运营侧,需求的管理包括:需求策划管理、需求实现管理、需求效果评估管理。停留在需求侧是大部门产品经理的现状,兼顾技术侧的,有点偏重项目管理的角色,协调运营侧的,是产品负责人的角色,可以调动周围几乎所有资源,达成某种使命,这样的产品经理就慢慢的靠近CEO了,渐渐有了使命感,领袖的诞生就藏在表格里,潜移默化着每一位产品经理,看你能管到哪里…

这里提供一份相对完整的需求管理基础架构(排除第三方管理工具,仅供参考)
这里写图片描述

首先

需求侧管理:

这里写图片描述

1、需求编号:需求的编号,方便在需求池里管理检索查询需求。

2、需求涉及端口:移动端、PC端、Web端、微信小程序、支付宝生活号等。当业务复杂时,或者产品经理负责的端口较多时,这种需求管理是很高效的。

3、需求主要模块:基于端口下的模块,比如移动端下的、首页、我的、消息、发现、等。

4、需求子功能:基于主要模块下的子功能,比如消息模块,涉及系统消息、内部IM消息、评价消息等。

5、需求详情:需求真实意图描述,如果是比较简单、不复杂的小需求,直接描述要解决什么问题。如果不是小需求,则不仅需要描述要解决什么问题,还要把为什么要解决问题的原因一并记录下来。(解决问题的原因,多数情况下需要产品汪刨根问底的去问,去了解实际上用户的需求到底是什么和想解决怎样的用户需求)

6、需求来源:刚才我们已经说明了需求的几点来源,不再赘述。

7、需求类型:需求的类型每个公司都不一样,一般来说需求类型主要是记录此类需求属于哪一个类别的,主要需求类型有:新增功能、功能改进、体验提升、BUG修复等。

8、需求优先级:需求的优先级有很多种,P1、P2、P3、P4等;高、中、低等,自己能看懂就行。

9、需求版本号:需求规划的版本号,产品的最高发版权限。

技术侧协调:

PM这个词产品经理和项目经理共用,当公司没有项目经理,或者需要产品进行时间进度管理时,显然产品的责任就上了一层,产品负责人,需求的策划管理层次完成后,开始执行你的实现落地管理。

这里写图片描述
10、预期时间:预估上线的时间,这个时间对高层的领导来说很重要的,有的领导有明确的deadline,那就必须记录清楚,并执行到位。

11、PRD:产品经理开始协调交互设计师,讨论需求,进行PRD落地。

12、UI:确定PRD后,将文档同步给UI,将设计师进行输出UI设计稿。

13、SRV:后台组拿到PRD,进行数据库创建、预研实现方案等。

14、iOS: iOS和安卓都属于前端FE,管理之所以分开,是因为每个公司技术储备资源都不一样,两个前端研发进度也会有差异性,所以分开管理。

15、Andriod:同上

16、QA:进行测试验收,质控管理。

17、发布状态:预估什么时候能达到发布状态,这个预估也非常重要,一个人预估能力是否准确,也间接说明了他对产品、交互、设计、前端、后端、测试等整个团队职能的深度理解。

18、上线时间:上线前还要进行ShowCase,进行一轮生产环境测试,将相关人员拉到大会议室,进行全员找茬,很管用。上线后记录上线时间,进行时间存根留底。

运营侧协调:

这里写图片描述
运营侧的需求协调主要涉及数据、内容、和渠道发布的管理。

19、产品运营:上线前后的数据分析,及汇报,产品经理需要知道一手的数据信息,要保证数据信息渠道畅通,并协调运营分析结果,挖掘潜在的用户行为,驱动产品方向,懂技术的产品可以了解可视化数据以外的细节数据,动用结构化查询语言SQL操控数据库里的每一个死角,(产品懂技术,无疑于流氓会武术)。

20、内容运营:上线前后的内容供给,产品涉及的图片、文案、信息、案例等都需要在需求开发阶段协调内容运营资源进行整理输出,作为需求目标达成有力支撑。

21、渠道运营:渠道运营除了ASO、新增、活跃、下载,传包外,还有收集渠道侧的用户反馈,及提供渠道侧的具有参考意义的数据信息,产品上线前后需要和其了解需求方向上的信息,以便输出新的决策。

需求的管理贯穿整个团队,所以产品的需求管理不只是需求的记录,而是需求的策划、实现、效果评估都需要。每个产品经理的需求管理方式可能都不尽相同,适合自己的方法论才是最好的,但是需求管理的好坏、管理能力的强弱是一眼能看出来的,至于我们想治大国如烹小鲜,还是每时每刻被动煎熬,就要看我们的需求管理能力了,优秀在路上,慢慢培养吧…

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Li_阴宅/article/detail/971363
推荐阅读
相关标签
  

闽ICP备14008679号