拒绝不靠谱的需求：怎样确定需求才是正确的？

我是一个从传统行业5年需求分析师转型做产品经理的同行，很多人都说需求分析师就是产品经理，产品经理就是需求分析师。对于这个理解我个人觉得是狭义的，在某些方面或者某些公司，需求分析师和产品经理的工作是有重合的，但这并不代表两者就是一致；

产品经理负责调查并根据用户的需求，确定开发何种产品，选择何种技术、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。

需求分析师则负责解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以说，在软件工程当中的“需求分析”就是确定要计算机“做什么”，要达到什么样的效果。可以说需求分析是做系统之前必做的。

那么说来说去都包含了需求，我们如何确定需求的正确性，来拒绝不合理的需求呢？
有人说产品经理就是在不断的重复一个挖坑、填坑的动作，当你在不断挖坑填坑的过程中有所感悟了，说明你就进步了。

首先说说我们的项目需求流程：

老板提出重点设想-----大家一起划定功能界限----产品进行构思画出原型----与老板进行需求原型沟通确认，进行相关调整----召集项目经理及相关技术人员进行需求功能评审------调整原型及需求规则-----项目经理确认完成进入开发阶段。

这里想强调一点，需求的完成不是产品经理和老板确认好就行的，在开发前需求一点需要项目经理介入和最终确认，因为实现完成者需要技术执行。不管你需求把握分析的多么准确，原型画的多么漂亮，技术实现不了，一切都是空想，只有跨部门间沟通确认才能完成。

需求的来源：

老板提出的战略方向的需求：老板会站在战略层的事务，在确定了产品的方向之后，他会对产品的样子有个大致的想象，有些功能是必须要有的，这时候，他会和大家讨论哪些需求建议加上去。

产品经理根据产品方向规划需求：产品经理需要进行基本的竞品分析对比、收集各方面的数据，然后分析得出需求有哪些。

产品运营根据推广运营活动及用户访谈提出需求：产品设计出来是给用户用的，而最接近用户的是产品运营人员。那么，不管是一个产品最初的诞生以及迭代，产品运营人员都应该做用户访谈，去获取用户的痛点，用户用得不爽的地方有哪些，然后列一份需求清单给产品经理进行反馈。
其他参与者和关注者反馈需求：这里包括UI、UE、dve，因为对于这些人来说他们也希望自己做的事情、负责的事情能有成就感，往往他们提出一个问题，我们应该去思考，而不是一下子否则，最终大家沟通讨论从而确认需求，这样不仅让他们做的事情有成就感，同时也会让他们更关注和主动。

需求的确定：

我们目前的需求确定方式都是采用TDD记录需求源。为了保证需求的不遗漏，也为了验证需求的有效性及改动频率，我们目前正在做一个需求管理的小系统，流程如下图：



一切需求源完成后，我会召集相关人员进行需求确定，这里的人员包括项目经理，需求提出人、产品经理、老板等干系人员。

会议上产品经理作为主持人，在介绍完产品背景以及产品战略上的信息后，就正式进行需求的评审。

先列出需求，然后先让提出此需求的人说下提出此需求的原因，然后进行投票：
认同：指的的关于产品需求，这个需求你也想到这个需求，和提出者想的一样

赞同：之前你没想到有这个需求，但是经过他人提出后，你很赞同，在使用这个产品你会需要这个功能。

不赞同：之前你没想到这个需求，虽然经过他人提出，但是你不赞同，在使用这个产品你不需要这个功能。

在思考的过程中，强调给出意见之前，站在你是一个产品小白用户的角度上，你会不会有使用这个功能的需求。
如何投票确定需求，打个比方：
会议共有9个人，有个需求进行投票表决，每个人只能投一票。

认同人数加上赞同人数加起来大于三分之二，那么这个需求就确定必须加。

认同人数加上赞同人数加起来大一三分之一，那么这个需求待确定，参会人员重新进行讨论，站在小白的角度上说出各自的意见，重新进行投票，此刻投票只有赞同以及不赞同两种，赞同人数超过三分之二，确定此需求，反之，则放弃。

认同人数加上赞同人数小于三分之一，那么这个需求直接放弃，大家和需求提出者说下不赞同的看法以及意见。

需求的总结和归纳：

会议结束的过程中，需要专门有人在旁做会议记录，把会议过程以及最后的决策记录下来，会议后转发给参会人员，很多时候，记忆总是不如文档来得实在。（我们都会上传到svn存档）
汇总的需求在整理完成后需要发给相关参会人员包括老板，让老板知道需求确认的最终结果。
有些时候老板可能由于事情耽误无法参与需求确认会议，这时候作为产品经理的你需要把老板提出的需求进行详细的反馈并发给老板。
大家可能经常会遇到在进行一些需求确认的时候，一些开发人员总认为这个需求太荒谬，这个需求太不合理，有些可能对老板提的一些需求直接觉得不靠谱，这时候作为产品经理的你，不仅需要把老板的需求背景、需求描述、需求来源给参会人员进行讲解，让大家都理解的情况下进行投票。如果最终老板的需求被pass掉了，你需要记录并把大家的意见反馈给老板，让老板知道具体原因，从而再次确认。

项目经理在需求确认过程中有一票否决权，不管这个需求来源于哪个部门角色，甚至来源于老板自己，因为项目经理会站在技术的角度对这个需求进行评估考虑，如果不能实现，大家讨论再多都是扯淡，但是需要进行记录原因，为何不能实现？有何风险？是否会影响进度？

以上是我们目前需求来源搜集、需求确认、需求会议总结
af3e
的方式和方法，但是在实际过程中我们也遇到了许多问题，表现如下：

1、开发人员质疑这个需求不合理：这个时候作为产品经理的你就需要从自身思考，是否这个需求没有讲述清楚？从而误导了开发人员？
（这里切记不要说这是xxx的需求，我也认为不合理，但是没有办法，这样只会让开发人员鄙视你，造成你后续的被动，工作越来越难开展）
2、开发人员在实现需求的过程中可能会比较复杂，不愿意实现：这个时候作为产品经理的你需要了解这个需求为啥实现中比较复杂，是否和你理解的正确？
（这里就需求你和技术多多沟通，有些必须实现的需求绝对不能让步，这种问题当你让出第一步的时候就会出现第二步，不仅到时候会让老板对你有看法，同时也会很被动）
3、开发人员简单实现一些和规则不符：遇到这种事情你不能直接上去就是指责xxx，而是要了解下这个需求这种实现是否可以，能否满足功能要求。开发人员基于啥这样实现。
（产品经理和开发人员是承上启下的关系，也是完成一个需求功能不可缺少的一部分，正确的沟通和理解会让你在以后的工作中得心应手）

总之我个人认为需求的确认需要大家一起来确认，不是老板的责任，不是某一个部门的责任，不是某一个角色的责任；要适当的学会拒绝，学会沟通，才能让需求更正确的执行。
在工作中我也会跟开发、UI等相关人员进行激烈的沟通和争吵，但是都是基于工作需求；任何一个需求的确认如果只是平平淡淡，没有一点问题和摩擦肯定会出现问题，只有大家一起沟通确认才能让需求正确的执行。

学会拒绝不合理需求，学会正确沟通需求，这是作为一个产品经理最基本的责任；
谢谢大家！欢迎有想法的人一起沟通，一起交流，觉得不错的给个认可，点个赞哦~~~~~~~~~~

本文由PMCAFF产品经理社区作者@Andy-pm  原创，未经允许，禁止转载。