需求评审:如何让开发明白产品的需求

需qiú评审会,虽然是产品经理的演讲会、高光时刻,但是更重要的是怎么让“与会人员”明白我的需qiú是什么,达成一致意见或知道会后如何修改。

发现问题,刻意练xí

我发现近几个月的需qiú评审中自己出现的3个比较具体的问题,X一天观察导师是怎么高效做需qiú评审,记录总结了可以“刻意练xí”的要点。

需要提醒自己的是,“刻意练xí”是书《优秀到不能被忽视》中明确刻可以成为更好的自己的一种方fǎ,共有5个步骤。其中我认为首要是先找到自己的“对标对象”,即 找到自己需要提高的不同能力的学xí对象。

因此我找到了需qiú评审可以学xí的对象,下一步则是“摧毁和拉伸”, 就是承认自己的失败;突破自己的舒适范围。“摧毁”自认为优秀的部分,“拉伸”自己离开舒适圈,刻意练xí自己不会的但是适用的东西。

“刻意练xí”的5个步骤(摘录自书《优秀到不能被忽视》)

3个问题分别是:

  1. 在写文档的时候思考的逻辑点,该怎么告诉开发需要这样做?
  2. X过程中,先说什么?后说什么?
  3. 展示需qiú文档时,什么场景下对着X说?什么场景下对着原型说?

zhēn对这3个问题,我进行了下述要点的刻意练xí。

如何告诉开发WHY、WHAT、HOW

1. 评审前

开发同事虽然是帮助产品完成需qiú,但是也需要X为什么做和做什么,来判断该开发工作是否是新增的,开发量是否很大,排期等。这就涉及到产品在开需qiú评审前,需要提前查看本期backlog中和这个需qiú相关的,明确本需qiú是新增的,还是优化的。

如果是新增的需qiú,直接进入评审中的3个开题环节。

如果是优化的需qiú,需要先打开backlog说明“本需qiú是zhēn对上一期需qiú做的二期、三期优化,其中在这个需qiú版本中只做二期优化。二期优化的内容有以下这些,分别是xxxxxx”。因此也涉及到填写backlog的时候,需要清楚详细写明需qiú的名称,让开发一眼明确这个需qiú是做哪块儿内容。

2. 评审中

打开需qiú文档时需要先说明需qiú类型、背景或现状、需qiú的目的。需qiú背景或现状也就是在设计这个需qiú时,自己思考的点。比如最近在设计X活动,需要新增需qiú目的是在微信环境下完成活动闭环。

为什么要在微信环境下闭环,因为(背景):“班X或X的宣发渠道普遍是X微信,家长在看到X海报后,想直接X二维码参加活动”,说清楚什么人在什么时候做什么事情,得到什么结果或遇到什么问题。

因此这个需qiú,主要是解决xxx问题,这就是需qiú目的。说完背景和目的后,再接着说需qiú重点解决的是什么问题、整个liú程是怎么样的,再一个部分一个部分去描述。

如果评审的需qiú是比较大、内容比较多和复杂的新项目时,在开始讲下一个大模块前,需要对上一个模块总结

比如观察导师做商城需qiú评审,是总结刚才模块的整体liú程:“刚才说的基本是从商品列表进来,用户看到详情页,X后兑换商品,看到兑换明细。那么接下来到了xxx部分。”

需qiú描述中,先说什么?后说什么?

需qiú评审会先说需qiú背景和目的、功能设计,进入到需qiú描述。本着高效原则,每个需qiú点只描述重点和难点

在一个需qiú点的描述中:

1. 从上到下,从左到右描述

我认为,zhēn对B端工具,从上到下描述,从左到右描述是比较完整的,既可以当做是使用者查看顺序来描述,也可以当做是自己在思考时逻辑过程再走一遍,查漏补缺。

比如,最近在设计微信模板消息X的X工具,属于B端X工具。在需qiú评审时,可以直接打开liú程的原型图,对着原型页面从上到下,从左到右描述。

上述图中,可先从上到下,第一部分是信息筛选:可支持筛选xxx数据,X查询的结果展示在下方的表格数据;

第二部分是表格数据,展示的数据项按原型图顺序排列。再从左到右:表格数据中,前两项是xxxx,中间这几项是反馈微信X的结果,最后cāo作中可支持以下几种状态的不同cāo作,分别是xxxx。

这样说下来,自己会感觉很清晰,开发也能明白这个页面需要做什么,不同状态下可以做什么cāo作,剩下的内容可请开发自行查阅需qiú文档。

2. 从用户cāo作路径描述

zhēn对C端产品,根据用户cāo作路径来描述,会让整个liú程的听众也能把自己当做这个产品的用户一样去完整体验一遍这个需qiú的闭环。因此根据用户cāo作路径来说会比较完整,需要讲清楚每个部分之间的X,这个X通俗来理解,就是下一个页面是X上一个页面的什么cāo作的来的。例如用户在商品详情页X“去X”,就跳转到了订单确认页。

考虑到C端产品通常会有X系统进行配置,所以在需qiú评审中通常也涉及到前端页面和X页面的描述。所以我认为在评审中将前端页面和X页面对应起来描述会更liú畅,还是例如用户进入商品详情页,可看到页面顶部是5张商品图轮播,商品图是在X的新增列表中可配置,是怎么样的上传规则xxxx。

3. 暂无结论的尽量不占用X时间

虽然需qiú评审是产品经理的“演讲会”,但是也难免会存在开发与产品、开发与开发之间会因技术实现的问题占用较长的时间。除了在前期设计需qiú时需要主动和开发讨论技术实现最优方案,在评审会中也需要把握技术讨论的时间。如果不能一下子讲清楚或者暂无X结论的,先不占用X时间,会后再和开发讨论。

和开发讨论技术方案实现,我认为千万不能被开发用产品“听不懂”的技术带跑。透过现象看本质,深究影响这个技术实现的X问题到底是什么,因为产品不一定懂很多技术知识,但是一定是了解X的。

什么场景下对着文本说?什么场景下对着原型说?

首先需要明确,文本和原型的区别/效果分别是什么?

在我看来,文本是zhēn对逻辑、格式、规则等一些规范性需qiú要qiú的详细阐述。原型是zhēn对cāo作界面、liú程、展示大概的样式的图像化呈现,因此需要根据当下讲的内容来匹配对应的展示内容(文本or原型)。

例如,近期设计的X活动,在需qiú评审时,需要阐述用户可以X完成什么任务获得X卡。

一个任务包括:任务名称、任务时间、任务触发入口、任务展示、任务状态等。可以将上述的先分类,任务名称、时间、入口、展示都是可以X图像化形式呈现,任务状态需要有规则告知什么时候展示什么任务、当用户完成该任务时任务排序是怎么样的等等。因此可以在描述用户可以完成什么任务的时候,对着原型说是合适的;在描述详细的任务排序规则的时候,对着文本说是合适的。

上述3个问题是我从入职以来到现在,在需qiú评审会中最常见的,因此X观察导师的需qiú评审总结了一些提高效率的方fǎ,虽然并不是完全我都能立刻掌握,但仍在“刻意练xí”的过程中。如X需qiú评审中让开发能更快、更清晰、更准确明白产品的需qiú,也是锻炼产品经理“同理心”(换位思考)的技能。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 需求评审:如何让开发明白产品的需求 https://www.xiongfawang.com/2201.html

常见问题

相关文章

需求评审:如何让开发明白产品的需求-海报

分享本文封面