需求评审

程序员与产品经理:需求评审桌上的智慧交锋

在科技公司的会议室里,程序员与产品经理的“战争”似乎从未停歇。而这场没有硝烟的战争,最激烈的阵地往往就是需求评审会。在这里,程序员和产品经理围绕着一个又一个需求,展开激烈的争论,用他们的智慧和专业技能

需求评审时总是被挑战,肿么破?

前几天有小伙伴给我留言,说自己每次需求评审的时候被各种拍砖,不知道肿么破。先看下这位小伙伴遇到的问题:下面是我的回复:确实,需求被挑战几乎是每个产品经理都会遇到的问题。要想在评审的时候被拍得越来越少,首先得总结下常见的被挑战的问题点有哪些。经常被挑战的问题1、技术层面,实现逻辑的可行性问题需求评审中,常常会被技术同学挑战的问题,多是发现产品经理提出的某个“想当然”的功能需求

需求的折磨:需求评审的前、中、后,产品都要做些什么

半年经验的产品助理为什么会犯这个错误呢?这是我最近一直在反思的问题。最后,我发现这和我之前的工作方式有关。每一个需求的从无到有,从有到确认;每一次的需求评审,从失败到成功。对产品经理来说都是一次折磨。每一个版本迭代,我们都需要反复地被折磨,换了新工作后到现在已经4个月了,工作方法的转换,2个版本,4次需求评审的折磨。我也慢慢发现错误,改变工作方法。第一个问题,出在需求评审,

多、快、好、省、趣、美、嗨、秀,八字判断需求真伪

成也需求,败也需求。产品经理跟需求有着一种说不清楚的孽缘和宿怨,真可谓成也需求,败也需求。身处互联网江湖十余年,已经司空见惯。产品经理被骂被黑已经成为一种莫名其妙的风尚,最常见的情况就是错误的产品战略是老板亲自决策的,荒谬的产品设计也是上位者意淫出来的,操蛋的产品需求是XXX部门提升KPI撕逼出来的,而这一切的一切,最终的结果就是产品经理躺着中枪被骂被撕。产品经理吃这种哑巴

关于需求评审的一些实践方法和思考

开需求评审是产品经理的工作内容之一,那么如何做好这项工作呢?梳理自己在工作中的实践和感悟,希望能找到更适合的最佳实践方法。需求评审的作用向他人传达自己设计理念如何在会议上讲解清楚自己的设计思路并得到大家认可,是需求评审前应准备和考虑的问题。发现自己设计的不足,查漏补缺一个人的思维毕竟是有限的,通过评审,让不同角色的人员站在不同的角度审视方案,是很好地补充自己思维不足和发现方

需求评审:产品经理的高光时刻

需求评审能极大锻炼产品经理的表达能力、逻辑能力、说服能力、执行力;在面对各位小伙伴的轮番diss,产品经理在那一刻得到了十足的存在感,并在一一回应各方问题后享受着那高光时刻。什么是需求评审?需求评审其实是PM非常讨厌的工作,因为每次做都需要耗费身心精力直到被掏空,但它又是非常重要不得不做。需求评审简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议;俗称挑刺大

需求评审前、中、后三阶段,都该做好哪些准备?

作为产品经理,需要注意哪些事情,才能让一个需求评审能够高效的完成呢?需求评审目的是让项目的参与者(这里主要指研发测试)能够快速理解产品的意图,认可采用的方案。那作为产品经理,需要注意哪些事情,才能让一个需求评审能够高效的完成呢?可以先回忆一下我们评审过程中遇到的一些问题:“这个做了有什么用?”“有没有认真想过?”“唉,你这个做了,之前的XX是不是就没用了”“这个做不了”“有

产品经理在需求评审会上必定被问过的7个问题!

在需求评审过程中,产品经理往往需要跟多方进行解释和沟通,其中,与技术小伙伴的沟通过程中,有可能会就功能、方案设计等方面提出相应问题。本篇文章里,作者就总结了产品经理在需求评审过程中可能会遇到的七个问题和对应解决方法,一起来看一下。有一句玩笑话:产品经理不是在吵架就是在去吵架的路上,生动地刻画了我们产品经理在沟通上需要花的时间。而需求评审会是所有的沟通场景里面比较重

干货!最全需求评审指南,让你不再被怼

令很多产品新人非常头疼的会议就是需求评审,害怕在会上“怼”不过研发,也害怕被“怼”的“体无完肤”。本篇文章里,作者围绕需求评审会议的五个方面为我们全方位解读要如何才能不被“怼”,一起来看看吧。对于产品新人而言,日常最头疼的会议就是需求评审。在做产品的这几年,笔者开过上百场需求评审会,曾经被研发在会上怼哭过一次,也遇到过研发和产品大吵半小时、最终有一方摔门而出的情况