最新公告
  • 欢迎您光临欧资源网,本站秉承服务宗旨 履行“站长”责任,销售只是起点 服务永无止境!立即加入我们
  • 产品经理不是在需求评审会上遇到技术的吐槽怎么办?

    有一个笑话:产品经理要么在吵架,要么在吵架的路上,形象地描绘了我们的产品经理需要花在沟通上的时间。

    需求评审会议是比较重要的沟通场景之一,所以今天分享几个需求评审会议中经常遇到的需要特别注意沟通的问题,希望对大家有所启发。

    作为产品经理,我经常在需求评审会上遇到技术投诉。常见的问题大概如下:

    让我们一一分析。

    01 第一个问题:我觉得这个功能没用,为什么要做?

    技术问题的潜台词是:我们不知道需求的目的和背景,也无法判断这样做是否合理,产品经理赶紧谈了起来。

    大多数时候,技术并不真的认为这个功能没用,它是一种咆哮和询问。

    听到这句话,应该赶紧说明需求的背景和需求的目的,让技术清楚地理解为什么提出这个需求,这个需求解决了什么问题。这样可以在信息层面与技术保持一致,更好地达成共识。

    这种情况是在需求评审会议开始时没有明确说明关键信息。这是一个新人进入这个行业时经常遇到的问题。

    很多时候新人认为每个人的信息都是一样的,所以我不需要解释为什么。但事实并非如此。技术部门需要产品部门传达这些背景信息。产品是关键节点。

    在整个研发过程中,大部分信息都是通过产品传递的。一般其他部门与技术部门之间没有直接联系。这样一来,虽然产品经理和业务部讨论了好几轮,但技术部还是第一次涉足,所以还是要从头开始认真。

    当然,真正感觉技术没用的情况很少。我遇到过这种情况,技术根据自己的经验觉得这个功能没有必要,然后就没有实现。

    这是一个比较麻烦的情况,通常发生在技术比较强的时候。这个时候就把争议搁置一旁,会后请他和领导商议这个问题。双方都说明理由,然后领导给出建议。在这种情况下,如果领导者决定这样做,技术不会说什么。

    引入第三方可以有效避免与技术的直接冲突,但弊端也很明显。一些技术可能会继续使用这种方法。你不可能总是找到第三方来解决类似的问题。小范围内,按技术处理。大方向上,还是要说服技术走自己的路。如果不能说服,将按制度处理。

    02

    第二个问题:你的方案设计不合理,应该这样设计。

    这也是很常见的情况。科技认为产品经理的计划不好,但他的计划是好的。

    这没有潜台词。纯科技觉得产品太差,所以当场表达自己的想法,免得再做坑图,后期补坑。

    这种情况有两种可能。一是产品和技术对整体业务的掌握程度不同,所以每个人都有不同的想法;二是方案偏好不同,效果相近。一个选择A,另一个选择B。

    第一种情况,如果产品经理没有足够的控制力,那就比较麻烦了,因为这说明你对公司的业务不熟悉,会对你的信任产生负面影响。你需要做的是立即在会议上询问相关细节,然后暂停审查会议以调整计划,并准备再次来。应尽可能避免这种情况。

    新人这个时候常犯的错误之一就是明知有问题还是强行推进计划,怕被质疑,其实是不可取的。之后,你还可以向领导征求意见,这就更糟糕了。

    如果技术掌握得不够,那么就需要搞清楚设计的原因,他的方案哪些方面有问题,通常是和其他模块的联动有问题。就这件事而言,如果把事情说清楚,一般不会有问题,大家都知道。该技术提出其他解决方案只是因为信息不够全面。

    第二个是偏好问题。你可以谈谈你设计的原因,也可以谈谈技术方案。两种解决方案之间没有区别。只是你更喜欢这个方案和业务,这是部门已经达成共识的。

    在这种情况下,技术一般不会坚持,因为没有必要。他提出了一个计划,希望能表达自己的想法。你可以同意他的计划。

    03 第三个问题:你在设计时考虑过XXX的情况吗?

    也许是善意的提醒,也许是恶意的刺,没关系,都是善意的提醒。你如何看待这个问题,决定了你如何处理它,善意的回应更好。

    如果你考虑过这种情况,那么你可以说你考虑过,我后面会详细讲。

    节奏掌握在自己手中,不要跳楼说话,开会的节奏要在会议主持人的手中,需求评审会的节奏要在产品经理的手中。如果打断节奏回答问题,那么整个会议的节奏就会混乱,时间会很长。虽然你已经成功的回答了大家的问题,但是你的效率还不够,而且会有点乱,不好。

    如果不考虑,可以说是之前的情况不太清楚计算机操作系统第二版课后答案,后面我们会重点关注。注意不要打乱既定的会议节奏。在需求审查会议上,首先确定可以确认的内容,然后花时间讨论缺少的部分。

    一般来说,不超过15分的讨论可以当场讨论,然后确定方向。如果时间长了,那就开会后再讨论,然后做一个计划,做完再做二次审核。

    二审不是一件可怕的事情,也不是一件丢人的事情,可以理解为二审是一个必要的过程,重点是把事情处理好。

    04 问题4:你的需求不完整,缺少很多东西。

    计算机操作系统第二版课后答案_计算机操作系统教程第三版课后答案_操作系统概念第七版课后答案

    也会遇到这种情况。一般来说,新人新来的时候,会遇到更多的事情。其实以后应该就好了。

    如果出现这种情况,有两种情况:一是产品的计划真的不完整,二是技术认为你的计划不完整。

    不管是哪种情况,如果听到这个,首先要做的就是询问提出问题的技术,具体是缺少什么,然后一一检查。

    有时技术说的是对的,有时技术说的是对的,但不一定。根据具体情况弄清楚这个问题。如果技术是真的,那就写下来,然后改,回去自己强化技能。如果你这么说,那么这个确认动作可以有效的减少那些无效的干扰,同时也可以让以后这种情况发生的频率降低计算机操作系统第二版课后答案,省去很多麻烦。

    一般来说,缺的东西不会很多,一个产品的计划也不会千疮百孔,因为其他人通常会在审核之前阅读和讨论,不会由产品经理一个人完成。拿出来审核。

    但是可能有些地方没写,不多,只有一两个地方,技术刚想到,让技术在会上指出来,然后简单给个方案,就可以了,而且会议结束后,计划上不去。

    因此,这句话往往有些夸张。不用太紧张,确认一下即可。

    05 问题5:这个要求变化太大了,真的需要改吗?

    这句话有潜台词。技术意味着开发的工作量有点大。你考虑清楚了吗?

    技术这么说的时候,多少有些不情愿或者有点担心,因为在这种情况下,通常意味着很多原来的代码是没用的,过去的工作可能会被浪费掉,这是技术不希望看到的,所以技术会证实也是人性。

    还有一种可能是需要改的代码比较乱或者以前用的地方很多,所以技术有点担心改后会出现各种问题。他们会这么说,希望业务部门和产品重新考虑。

    如果是和上一个一样好的处理,产品应该尽可能的把修改的目的和背景说清楚。一般来说,如果真的需要改变,技术不会多说。

    但如果是后一种情况,那么最好先和技术沟通,然后尽可能多的给技术和测试留出时间,确保上线后没有问题。

    这种情况其实在小公司更容易出问题。经常是业务负责人说不,需求必须在几天内实现。可能是业务方答应了大领导或者客户,也可能是门外汉。高手,不管哪一个都比较坑。

    在这种情况下,建议请技术部负责人与业务方沟通,看是否可以调整研发周期或做出折中方案。我绝对建议调整研发周期。因为做出妥协意味着以后需要更多的时间来解决问题。

    06

    问题6:你的要求又变了,那为什么当时又变了?

    这种情况经常发生在产品的初始阶段。因为方向不确定,需要不断的调整和探索,所以可能会有反复的修改。

    问这个问题的技术一般都习惯于成熟产品的研发,但初创的产品必然会经常调整。

    我也遇到过这种情况。技术往往强调在开发之前先想清楚,尽量规划好,这样以后就不用频繁改了。

    这么说的术法还是高级术法,我觉得这么说有点不专业。想要改变的不是产品,而是业务需求。

    如果您遇到这种情况,请告诉我们为什么会出现这种情况。客观地说就够了,不需要额外解释。技术只是换回来有点烦人,但其实你知道还是要这么做的。你需要做的是安抚他们,然后给出步骤。

    07第七题:这个地方可以改成XXX吗?

    在这个需求评审会上,除了研发部门的同事外,通常还有对应业务部门的同事。业务部门有时会在会议上提出一些东西,通常是增加需求或修改计划。

    如果是附加要求,那也不错。您可以评估更改的大小。如果比较小,可以交流,当场添加。如果比较大,建议下个版本和其他内容一起优化。当前版本是第一个不要添加,因为计划已经确定,如果添加需求,会议将无法打开。一般企业会同意的。

    如果是改变计划,那将是一个坑。通常,一个计划是暂时想到的,然后说可以这样改变。这种话其实说明操作经验不是很丰富,所以会出现当场改变计划的情况。

    如果发生这种情况,您可以询问新计划是否比原始计划好得多。如果答案是否定的,建议使用已经排序好的方案,以便尽快上线。如果是新的计划,好在很多情况下,需要重新组织计划,重新开需求审查会议。尽量不要让这种情况发生。这是浪费时间。尽量在会前和业务部门商量。

    以上是我在需求评审会上遇到的常见问题的一些观察和总结,希望对大家有所启发。

    一个产品经理如果没有经历过无数次需求评审会议的洗礼,就无法成长为真正的产品经理。一个真正的战士需要面对技术的愤怒和商业的解体,而且大概率需要反复面对。

    没关系,只要成功挺过,你就是最强王者。

    如果你选择成为产品经理,祝你好运。

    本文最初由@codenamedaochang 发表于人人都是产品经理。未经许可禁止复制

    题图来自Unsplash,基于CC0协议

    站内大部分资源收集于网络,若侵犯了您的合法权益,请联系我们删除!
    欧资源网 » 产品经理不是在需求评审会上遇到技术的吐槽怎么办?

    常见问题FAQ

    免费下载或者VIP会员专享资源能否直接商用?
    本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
    提示下载完但解压或打开不了?
    最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。若排除这种情况,可在对应资源底部留言,或 联络我们.。
    找不到素材资源介绍文章里的示例图片?
    对于PPT,KEY,Mockups,APP,网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。
    欧资源网
    一个高级程序员模板开发平台

    发表评论