昨天
产品经理的职位的工作方式，在不同企业中有各式各样。有的负责需求整理、有的负责画原型、有的负责项目管理、有的甚至负责设计.....，但需求评审是整合以上所有环节的核心流程：深度理解需求
最近在带一个新的产品团队，我发现了一个有趣的现象。在评审中，产品经理尽可能的把需求文档写得非常细、逻辑文档一大堆、以及设计完成的UI稿。开发尽可能的少出BUG，不拖延上线。
但结果是：产品越来越累、开发越来越累，但项目却好不起来。
如下案例：
在评审中，产品以瀑布流的方式展现需求，从第一个页面到需求的最后一个关联页面如下图：
注意上面的页面1、页面2、页面3....已经在需求评审中是高保真的原型，你发现这样的流程有什么问题吗？
其实上面的问题会有3个
UI资源浪费
需求评审效率低
产品资源浪费
我们在需求评审中，因为是需要产品策划方案。产品经理给出的方案首先是要满足用户的，这里的用户可能是一个真实的用户、也可能是一个企业客户或则内部部门。
但在需求评审中，我们可能与开发、领导一起讨论后会拿出来更简洁的方式满足用户需求。这个时候如果采用上面的方案，UI资源的浪费是不可想象的。
因为UI输出的结果页，是不能确定我们会上线用的？而只是为来应付评审而已！如果解放UI资源后，我们可以让UI做一些更多的业务支持。比如出一些banner、去支持其他产品线所需要的UI资源。
采取瀑布流的方式，其实页面的连接并不高。我们都知道人看图会比看字符更快的理解意图。
但对一个需求来说，往往是若干个页面组合在一起的。因此采取尽可能的将页面铺展开链接起来，可以帮助参与评审会的同学更快的理解需求。
如上图，我们可以看到这样的页面讲解方式后。可以帮助参与评审的同学大体明确4个方向：
需求的解决方向如何
所使用的技术解决方案会是什么
开发难度与时间如何
需要的设计时间多少
在评审会中，确定上面4个问题后。其实整体的方案就基本确定了，剩下的就是产品经理去推动、连接各个部门即可、最终上线
产品经理没办法自己评估项目的时间周期、技术实现难度。
采取上面团队中的评审方式，其实也会造成产品经理梳理出来的文档是无效的，甚至是需要大部分调整的。
我们通过使用原型页面来确定上面的4个问题后。
产品经理再落地产品需求文档，就会避免这样的问题出现。产品经理可以更多的思考需求是否能解决问题，而不是落地在文档上。
把最终的方案呈现给开发同学甚至是设计同学即可。
当然，不管需求评审怎么变，本质是希望让团队开发、设计更清楚的理解需求。所以我们可以也通过线下私聊的方式和技术、设计去完成需求评审的目的。
产品经理的角色不仅是做一个需求解决者，还要去学会更快的让团队获得成就、与团队共同面对困难。拒绝与开发成对立、设计同步
好啦，今天就在这里。我会每周原创两篇工作的案例