如何做好产品需求评估？我总结了5个要点！
扫一扫 
扫一扫 
扫一扫 
扫一扫
产品经理经常会收到各种需求。说是需求，不如说是产品“要求”。因为别人提需求时，通常只是说他们想要什么，不会描述用户场景，甚至可能有些需求不是站在用户角度提出的。 产品经理在接收需求后，需要进行需求评估，通过自己的分析、判断，将“要求”转化为产品需求。 最近跟别人沟通需求，西拉东扯聊了 1 个多小时，讲了挺多内容。其实大部分内容还是对产品的要求，或者后续的工作方向。这些信息对产品经理是有帮助的，起码可以对需求的背景有了大致了解。 不过内容多而且没有条理性，产品经理还需要内化分析，完善具体的功能逻辑、对用户场景细化、拆解，考虑如何与现有的产品功能相融合，形成真正的产品需求。 所以会议结束之后，我整理了功能需求规划列表，并需求做了分析，有些还做出来优化调整，所以增加了用户画像、业务流程图，作为需求变动的辅助信息。 准备好这些材料后，我又发起了需求评审会，主要目的是让需求提出人确认需求是否正确可行，以及优先级、版本计划等。另外有部分需求需要开发人员提供具体的场景说明，所以同步拉入了开发负责人参会。 最终大家讨论，确定好了需求计划。后续就要开始准备具体的产品设计工作。 以上就是我需求评估、确认的全过程，有几点想要跟大家分享一下。 更多需求评估干货： 设计师如何做好需求评估？来看大厂高手的总结！在设计师工作的过程中，所承接的需求大多来源于产品。 阅读文章 >一、大胆假设、小心求证某些情况下，产品经理收到产品“要求”后，不会收到需求背后的业务场景信息。比如“增强产品的 XXXX 能力，支持 XXXX 操作”。 这种需求是基于产品角度提出的功能升级，比较务虚，很难直接执行。 产品经理需要根据自己已有的业务知识和理解“大胆假设”，脑补下用户场景，结合现有产品业务流程中找到用户痛点和升级点，拆解成若干具体场景和需求，变成可执行的产品需求。然后二次确认是否可行，得到明确答复后，再进行产品设计，避免无谓的工作投入。 二、多点质疑，找到需求的本质有时候恰恰相反，产品经理收到的“需求”非常具体，可执行性非常强。不过这些信息只是需求的表象，并不是真正的需求。我们要多问几个“why”，找到需求的本质。 比如大家可能都经历过类似的场景。
通过对话过程，我们可以推测业务 A 接收到的任务可能是“产品要增加‘产品测试’的功能”。但是增加功能的方式有很多。A 经过自己的理解做了微调，并作为需求直接传达了。当我们多问几个“为什么”，可能会找到需求的关键点，并提出更好的方案。 三、需求的价值需求评估并不单单是要搞清楚需求是什么，还要知道需求的价值。 我之前收到过一个需求，在后台产品首页中增加产品的架构图。主要目的是为了向客户演示产品的时候，可以方便讲解。当时费了各种很多周折，终于完成了产品设计。 不过在我看来这是一个非常没有用户价值的需求。后台产品的用户能登录系统，说明已经是产品用户了，他们在意的不是产品架构，而是产品如何使用。 即使用户对产品架构感兴趣，也可以通过其他途径了解。比如帮助中心。架构图更应该展示在产品官网首页中，让对产品有兴趣的用户去了解。 四、保持审慎的态度做产品时间长了，见多了各种“另类”的需求，容易丧失“质疑”的精神，会逐级变得“经验主义”。 比如工作比较忙时，对应一些简单的需求，我们很容易想当然。但是在后续开发过程中，可能会牵扯出一堆的问题。所以对任何需求都要谨慎，不仅要评估需求本身，还需要考虑对相关系统的影响。 五、熟悉业务及用户产品经理想要管控好需求，需要深度了解已有产品的功能、业务。这样才能提出自己的想法和疑问，才能够与需求提出人据理力争。所以产品经理功夫要用在平时，通过各种方法尽可能多地了解和积累产品信息。比如：
在这些资料的基础上，做好分析、形成自己的知识库，这样才能应对各种产品需求。 总结总的来说，我的观点就是产品“要求”很多，但是要求是不是需求，要仔细理解分析、慎重地对待每个需求。 另外工作的氛围很重要，单凭产品经理个人的努力无法做好需求的管控，需要产品团队的整体努力才行。 以上就是今天所有的内容了，下期见～ 欢迎关注作者微信公众号：「子牧UXD」
手机扫一扫，阅读下载更方便˃ʍ˂ |
@版权声明
1、本网站文章、帖子等仅代表作者本人的观点，与本站立场无关。
2、转载或引用本网版权所有之内容须注明“转自(或引自)网”字样，并标明本网网址。
3、本站所有图片和资源来源于用户上传和网络，仅用作展示，如有侵权请联系站长！QQ: 13671295。
最新评论
