当我们接到一个新需求点时,应遵循的需求分析步骤有哪些?

19 评论 45385 浏览 470 收藏 7 分钟

不要接到一个任务,内心就有一种莫名的冲动,想要马上完成。我们应该静下来慢慢规划,想清楚,才是最重要的。需求亦是如此。enjoy~

当我们接到一个新需求点时,应遵循的需求分析步骤有哪些?

首先,要根据需求设计功能,就要做到理解需求的来龙去脉。为此,需要搞清楚以下问题:

1. 为什么会产生这个需求?

当需求方向你阐述完某个需求后,向她询问:提这个需求的目的是什么?即为什么会产生这个需求?这个问题帮你完全理解需求,帮你辨别需求的真伪。

2. 什么场景下会使用这个需求?

即搞清楚什么人在什么情况下会用到此功能。只有明白了这个,才知道如何更好地设计功能来满足需要。

3. 是否有可能衍生出新的场景?

为了避免设计的功能因扩展性不足,后期推翻重来,在一开始,就应该做尽可能全面的考虑。通过需求方的场景,扩展思考,是否存在衍生的场景。思考的过程,也是帮助你抓住和理解需求本质的过程。

4. 技术层面如何看待这个需求?

接到需求,并充分理解了需求后,跟架构师或技术负责人花几分钟时间讨论一下,听听他从技术上对需求的考虑。通过此过程,你们基本会对需求点及实现方式达成共识,在后期正式开发时,阻碍会小得多。

5. 是否可纳入backlog?

确认需求为真实需求后,将其纳入到backlog中,并大致描述需求逻辑,方便项目组成员对待开发工作心里有数。(应注意backlog是已明确并经过去伪存真的需求,是指导项目组掌控项目的工具,而不是产品经理的备忘录。同时粒度不宜过细,否则非常不利于维护和沟通使用)

 

backlog表头及说明

6. 开启版本迭代,细化需求

当要开启一个版本的规划时,我们从backlog中挑出高优先级的若干个需求,并细化需求、制定迭代计划。

细化某个需求点时,需要做的事情如下:

A. 版本功能列表说明

在版本功能列表中交代清楚需求在此次版本中的优先级(高:必须做;中:进度紧张时,可不做)、类型(新增:此前没有,需重新开发的功能;修改:功能已有,需做调整的功能;删除:不再需要,删除的功能)、描述(交代逻辑)、详情(链接到对应的页面):

附在PRD文档中的当前版本功能列表说明

B. 业务流程说明

若需求点story较大,有涉及业务的流转,则需首先梳理业务流程。流程的梳理不仅帮助项目组成员理解需求,也是帮助自己梳理思路。

C. 设计页面和交互

流程清楚以后,就可以着手设计原型了。此时,如下几点要素是必不可少的考虑因素:

(1)页面的名称是什么?

设计一个页面相当于创造了一个从来没有的新东西,为了与其他东西进行区分,总要给他一个标识。故,每做一个页面,应先给它命名,且这个名称是独一无二的。既然是名字,那么名词或动名词是最合适的,但贵在语义表达准确,即让阅读者看到页面名称,就能八九不离十的了解到这个页面是用来做什么的?

(2)页面由哪些功能组成?

系统功能由一个个页面承载。每个页面分担完成功能中的若干个功能点,因此一个网页就是由一个个的功能点组成的。当设计一个页面的时候,就要构思好,这个页面应包含的功能点应该有哪些?如“写文章”这个页面,大致应有:文字编辑、图片插入、文章发布、文章归类等几个功能点。

(3)完成功能需要哪些操作?

完成每个功能点,用户需要在系统上进行若干步操作。因此在设计一个功能的时候,应交代清楚用户使用这个功能,需进行哪几步操作?如完成“文字编辑”这个功能点,需要先点击操作“写文章”,再完成“书写”,完成“插入图片”,最后“保存”。

(4)执行某个操作的条件是什么?

系统上的每个操作,需要满足某些条件才可触发。否则,系统功能无法形成体系,处于紊乱的状态。如“当文章内容发生变化时”,才可做“保存”的操作。

一个需求从提出到设计实现,应该遵循特定的生命周期,否则极易出现遗漏、混乱的情况,极其不利于项目的质量和整体把控。

特别应注意的一点是,不要听到一个需求,内心就有一种莫名的冲动,想要马上实现此需求。静下来慢慢规划,想清楚,才是最重要的。

 

本文由 @小麻雀 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 太棒了!有举例的教程让新人特别容易理解!

    来自广东 回复
    1. 谢谢肯定~

      来自广东 回复
  2. 请问,story point具体是什么?能举个例子嘛

    来自俄罗斯 回复
    1. 可以按大的流程节点为粒度来抽取
      比如商家入驻是一个story,下面又可以拆成很多细小的需求点

      来自广东 回复
  3. “第三点,是否可能衍生出新的场景”存在疑问,这个要考虑一个需求的所有可能性,但可能性并不代表要设计的功能都要满足,如何区分哪些可能性是需要cover的,哪些是可以去除的?如果是通过市场调研来判断,还是有点难度的,希望能回复。

    来自北京 回复
    1. 这个的意思是设计功能的时候 要考虑的长远一点或者说功能设计的要灵活一点 这样后期有变化的时候 可扩展性比较高 不然设计的太死 后面要有一点点改动 整个功能要大改甚至要推翻重来 就不好了~
      举个最简单的例子,比如OA中的审核流,设计的时候就要考虑到,这个审核流是有可能变化的(现在是三级,有没有可能变成四个、五个),那这里是不是设计成配置的 而不是代码写死
      类似这样的,这只是个最简单的例子,意思差不多是这样, 😆

      来自广东 回复
  4. 写的太棒了,让我这个刚接手项目的小白有点自己的思路了,期待你的后续文章,也希望能和你沟通交流~~

    来自广东 回复
    1. 谢谢!
      我也是在摸爬滚打 😥
      有问题一起探讨哦

      来自福建 回复
    2. 我觉得我们可以和楼下的小白组个群 哈哈哈

      来自广东 回复
    3. 你可以加下这个群。群主不是我哦,我也是学员 582507167

      来自福建 回复
  5. 666,小麻雀加个微信?

    来自广东 回复
    1. 😬好 你的微信给我 我加你吧😬

      回复
  6. 需求调研阶段确实挺难的,寻找沟通的目标,引导需求方传达有效信息,还要时刻分辨信息的真伪,确实很重要的产品阶段

    回复
    1. “引导”这个词是精髓;好的引导能帮自己从对方口中获得最有效的信息。
      是的,一个项目,需求调研不清楚,范围蔓延、方向偏离几乎是百分百会发生的事。
      我一直觉得,需求跟实现是2-8法则,但很多时候好像被颠倒过来了。
      这时候产品就要帮项目组把好这道门了,不要让不清楚的问题进入影响实现。
      😉

      来自福建 回复
  7. 当需求不是非常明确的时候该怎么处理?

    回复
    1. 首先,应明确,产品经理是不明确需求、伪需求等影响项目的不确定因素的最后一道防线。因此,当产品经理都觉得需求不明确不靠谱的时候,更不要说让项目组实现这些了。为了不影响团队的工作和进度,当有不明确的需求时,我认为应该:
      1.最直接的方式,谁提出的需求,找谁搞清楚需求
      2.如果提出者也说不清楚自己想要的是啥,在你听完他不清晰的描述后,利用你的专业技能,帮他梳理,并跟他确认,你的想法是否正确,是否就是他想要的
      3.我的经验是,向对方提问题是搞清楚一件事情最好的方式,或许可以尝试这么问需求提出者:什么人在什么情况下会做什么事?你现在实际操作中觉得哪里是最困难不方便的?你觉得最好的操作方式应该是什么样的?类似这类问题,既是帮你搞清楚问题,也是帮对方梳理思路。
      一定要把不明确的东西挡在团队外面,否则,项目做着做着,就没人知道做得到底是啥了?
      希望对你有帮助~

      来自福建 回复
  8. 能不能再详细些?

    回复
    1. 你觉得哪里有问题吗?可以一起探讨下~
      1.其实一个需求你能添加到backlog中,并且对应的列都能写明白,说明这个需求你已经清楚了;
      2.剩下的就是在迭代的时候,把这个需求用原型也好、文字也好 表达出来;
      3.当然这只是我在操作中,找到的适合自己的最佳实践 ,但不一定适合大家;
      4.我想,每个人都应在工作中去寻找适合自己和团队的最佳实践,并把它们总结出来,按着这个去做,会发现项目都在把控之中。

      来自福建 回复
  9. 回复