【产品聊聊】聊聊需求评审的那些事

“先定一个小目标，做一个小程序吧……”

  最近最火的莫过于微信放的大招——小程序。也找一些朋友问了下，关于小程序的看法。其实根据流出来的demo（也没有去深究其真实有效性）。

作为一个小小的产品狗，只能说说自己的想法吧。

1.其实基于微信H5的开发，微信在很久之前就做了尝试：

   a.还记得微信里的“群发助手”一类的小插件吗？微信刚出来不久，就已经尝试用插件形式，丰富微信内部的各种服务。但是，你现在还用那些小插件么？小插件并没有流行起来，也没有成为微信的标配。    b.出现了功能相对聚焦的订阅号和服务号。它们的本质，是微信给与媒体和商家固定的模板，解决微信用户最基本的需求：阅读和生活服务。目前看起来，这两个产品很成功，但是可定制的程度不高，二次开发相对也比较困难。以这两个形式要满足千万商家和亿万用户的需求，依然显得不够。但是作为投石问路，它们要比小插件前进了很大的一步。    c.打开你的微信，点击开“发现”，里面有个“购物”。它其实就是京东在微信里的软APP，从浏览商品到下单，用户可以在这里能做的事情和京东APP里能做的事情几乎一样。退出来，在点击“我”，里面有个“钱包”，里面接入了滴滴、车票、酒店、58到家、美丽说、微票等等商家，同样的，在微信里也能获得在各自APP里的完整体验。

2.根据流出来的编码页面，我其实更觉得是微信在丰富代码库。类似于墨刀在丰富原型库一样。作为线上编码的保存地址。

3.所有的问题我们都应该抱着去学习的心态。其实即点即用技术，在我上一家服务的公司就早已经实现。不需要下载app，能和app一样完美运行。只不过方式不一样而已。也了解其中的道道。因为现在他们也在用，也不便赘述。

今天聊点啥呢？

聊点我在某家公司需求评审吧。

一、需求“头脑风暴”

每次产品内部组织需求头脑风暴的同时，就会有各种奇思妙想的需求出来。我们每次都不会打断产品同事的异想。会议纪要每次都会有序的整理出来。记住有几个前提： 1.必须是经过数据分散发送出来的需求。是需要根据用户的角度来出发，比如增加用户打开产品黏度，增加开门大吉（抢红包）功能，电商接入小游戏，大家来找茬等等，都是可行的。 2.头脑风暴必须建立在接下来版本的需求来做。脱离版本的头脑风暴其实更加不便于收集；

3.提前规划其内容，有好的idea提前收藏成型，后续风暴有助于发散。

二、需求确认

组织各部门的同事确认需求及其接下来版本定制规则。每个版本确认什么内容，每个内容有什么有什么功能点，应该做一个有序的计划沟通。各部门提的需求应该有计划的实行和采纳，毕竟产品经理是要背锅的。

1. 首先明确需求从哪儿来的。需求的追根朔源是产品必须要去体验和感受的；

2. 为什么要有这个需求。这个需求对于产品有哪些优势？接入产品是否会成为累赘？想清楚这些也是非常必要的。

3. 这个需求对接的产品功能形态是什么？

三、产品设计

对于产品设计，就不多赘述了。重要的是要有版本迭代纪录。每一次的纪录都应该完整的纪录。

![](https://v1cdn.imspm.com/e/f6830fe7e5d94b75b44ce9ee6f738d35.webp)

四、需求评审

需求评审分为两个阶段：产品内部需求评审和开发时间轴需求评审

1. 产品需求评审

   产品内部需求评审主要是针对其功能，逻辑进行分析，是否该逻辑合理，功能是本次版本该确定的。这次评审肯定会有各种异议。所以需要有一个完整的产品迭代内容须知

2. 开发时间轴需求评审

   确定每一个功能大致时长，我们原来是以3个小时为一个周期进行拆分功能点。这样完整的陈述之后，大致预估上线周期。

   

接下来产品跟进就不再赘述了。

总结这么多，最后一句：产品有序的方式工作，才能高效的完成事情。

文/john

关键字：产品经理, 需求

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！