产品需求和项目需求分析，及其二者的区别

晚安吾爱

需求的定义

需求分析：从用户提出的需求出发，挖掘用户内心真正的目标，并转为产品需求的过程
需求是问题：人类之所以有各种各样的需求，是对生活有太多的问题不满意，太多欲望没有得到满足，希望去解决问题，满足欲望，消除现实与理想的差距，就会产生需求。
我们做一个产品、服务、功能等就是为了解决问题，满足需求。而这些表面需求不断的深挖，总是可以回归到马斯洛需求理论和七宗罪。（马斯洛需求理论，它阐述了人类的需求源于五类，即生理需求、安全需求、社交需求、尊重需求和自我实现需求；在圣经中，人类有七宗罪：淫欲、贪食、贪婪、懒惰、暴怒、妒忌、傲慢）
张小龙说，一款好的产品，一定是迎合人性的。表示把握人性是一款产品很重要的一个环节，知道用户内心最需要什么，才能真正做出让用户喜欢的产品，当然有些东西会突破道德底线，甚至可能会触犯法律，总之既要满足人内心的欲望，又要让产品生存下去，所以打擦边球很重要，这也是一个度的控制。  
“需求分析”的过程就是将用户需求 转化为产品需求（通过问“Why”，逐步归纳），再转化为产品功能（通过问“How”，逐步演绎），过程中都要用到各种辅助信息，比如数据、竞品、行业等。
“用户需求”，大多表现为用户的解决方案，首先确认解决方案，“产品功能”一定是从用户需求转化而来，而不是凭空想出来的。所以说，“听不听用户”都是一个意思，更准确的说法是“听用户的，但不要照着做”。同时，也不要误解“创造需求”，你创造的只能是满足用户需求的解决方案——产品功能，而不是用户需求。
把“产品需求”追溯到“马斯洛需求”的过程是可选的，如果感兴趣，每个产品需求总能挖到马斯洛的层面。“产品需求”的点如何选择，我们到底应该挖到那个层面上，作为产品需求，取决于公司和产品的定位。
如何筛选产品需求？
前面说到用户需求只是用户自以为的需求，不够专业，而且有时用户说的并非心中所想，也可能不会表达内心真实需求。
所以，在筛选需求的时候，除了需要挖掘用户动机寻找真实需求的同时，还需要考虑一下几点：

• 该用户是否为目标用户：如果不是产品针对的目标用户，其建议或需求的参考价值可能没那么大。当然也有可取的建议，自当把握了。
  
• 该需求是否符合产品定位：该需求的满足可能会影响产品的核心服务，破坏用户体验。
  
• 该需求是否能实现：评估这个需求需要多少开发资源或运营能力，价值有多大？性价比如何？符合产品的周期或市场战略吗？
  

在考虑需求价值时候，可以从四个维度考虑：

• 广度：该需求的受众面有多大？
  
• 频率：该需求的使用频露是以日/周/月为周期？
  
• 强度：该需求对用户有多强烈需要？
  
• 时机：该需求是否符合产品的规划？当下的环境？
  

当然，所有的分析都只是我们的猜测，只是想往更深层、更靠近本质的地方，通过产品来验证这些推理和猜测，这里会涉及可用性测试，灰度发布等等一些。
被引用最多的一个例子，便是福特汽车创始人 – 亨利福特说的：“如果听用户的，我们根本造不出汽车来，用户就是需要一匹快马。”
<hr/>项目需求分析

当你坐下来分析一个项目的时候，会发现很多项目在需求分析阶段就出现了问题
俗话说：需求分析好，项目交的早。
理解需求分析是业务导向型
一天你和客户谈项目。
客户：“我们想做一个办公管理系统。”
项目经理：“这个系统想实现什么功能?”
“想用什么样的数据库?有多少人用?想用什么IT架构?”
客户有点懵，我只要用它来解决问题就行了，你问我这么多我怎么知道?
项目经理一般都有很好的技术背景，但项目经理不是总工，不是架构师，不是程序员，而应该是一个“业务层面的管理者”。项目需求的切入点必须在业务层面。
“请问，我们为什么要建立这样一个办公管理系统?前遇到的主要业务问题是什么?您最希望通过这一系统解决哪些业务问题?”
作为项目经理，应该明白客户的业务目标比技术实现重要的多，首先要弄明白的是为什么做，而不是怎么做。
谈项目需求要找对人
你和客户的一位副总谈了很久，确定了项目的详细需求，并形成了文档。但是，当文档上报给客户总经理的时候，被全部推翻了，一切从头再来…
上报给高层领导时，有调整还可以理解，但全部推翻了是怎么回事?
这说明你谈项目需求的时候找错了人。比如客户要做一个研发类项目，你不能去找客户的技术经理谈。
多数情况下，需求并不来自技术部门，而是来自业务部门。作为项目经理，一定要能够把自己提升到业务的高度，有能力和业务层面的人员直接进行沟通对话。
而业务层面的需求往往是模糊的、不确定的，甚至有些人自己也不知道想要的是什么。业务层面的需求还会牵扯到各方的利益，纷繁复杂，需要项目经理一一去梳理、沟通、协调、妥协，最终达成“相对的共识”。
所以项目经理谈需求时，一定要找对人。即使不容易见面，也要通过电话、微信等方式取得联系。
项目需求是需要确认的
经过沟通，你完成了项目的需求文档，把它交给老板。
项目经理：老板，这是项目的需求文档，包括交付时间、验收标准，您看一下，没问题就签个字吧。
这个时候，领导会乖乖签字吗?一般情况下是不会的，因为连他自己也没有想好到底签不签。
“先做一部分看看。”
“你是项目经理你定吧。”
你当然是项目经理，但你不是客户，更不是老板，你决定不了项目需求。其实让老板签字并不是非签不可，而是让他对项目认真思考清楚，很多时候老板是不会替你考虑问题的，最后出了问题还是项目经理背锅。
不管是签字，还是软磨硬泡，亦或是动之以情晓之以理，总之要让重要相关方认真考虑你的项目，让他们对项目目标、需求达成一致。不管他们是否强势，项目经理都不能退缩。
分清浅层项目需求与深层项目需求
你谈下了一个项目，在选择技术方案时，双方出现了分歧。
项目经理：这种方案简单，成本还低，可以满足您的要求。
客户：成本高没关系，关键是要稳定、可靠，我建议选择更复杂点的方案。
项目经理：这种技术也很可靠的，我们做了好几个这种项目了，没出现问题，你放心。
客户：我还是选择复杂方案…
这人咋这么说不通呢?钱多花不完啊，放着简单省钱的不用非得用那费劲的!
而后来你了解到，他们公司以前的系统都是用的这种方案，他只是不想做第一个吃螃蟹的人，他考虑的首先是安全，其次才是项目。
在需求沟通过程中，项目经理需要的是耐心、技巧和深层次的沟通，了解客户内心的真实需求，而不是从技术层面去说服对方。在很多情况下，问题都不是技术层面的。
在沟通项目需求时，要站在业务的角度，要和真正的业务负责人沟通，还要和老板沟通，逼迫他去考虑你的项目，最后，还要像读心一样读取客户的内心真实需求。
<hr/>产品需求和项目需求的区别，更多的是项目与产品的区别

“驱动因素”不同
项目的驱动因素：
做项目侧重于时间驱动，因为时间就是成本，要压缩成本就要压缩时间，在功能上力求操作敏捷、易用、友好，如果在项目时间紧迫的情况下，至少要能保证每个功能都好用、不出现BUG。
做项目是以客户的需求为驱动，按照客户的需求进行定制开发，对于不明确的需求要第一时间与客户进行沟通，不可存在需求不明确的现象。
产品的驱动因素：
做产品侧重于功能驱动，做产品的时间相对来说比较充足，所以要以开发出有竞争力、受广大客户欢迎的产品为原则，功能响应速度要快，操作要简便、界面要美观。
做产品是为了满足某一应用市场而针对性进行一套装软件或一个产品的开发，对于产品的性能以及快速迭代扩展的要求更高，产品的需求也并不像软件项目一样完全明确，存在着后期根据需求、迭代升级的情况。
“质量要求”不同
项目的质量要求：
做项目的第一准则是客户的需求，项目的开发人员需要依据客户的需求进行定制开发，并且项目需要保证功能适用于当前客户的使用习惯，性能稳定。
项目的质量更加侧重于某一客户的具体需求，保证交付的软件项目程序可运行、维护，需求功能可实现。
产品的质量要求：
产品的质量要求更加侧重于某一行业领域的应用场景，某一款产品需要适应或囊括当前行业可能涉及的需求，所能匹配的应用性更为广泛，并且对产品逻辑、代码运维性的要求更高。
做产品的性能必须尽量优化，因为产品为提升竞争力就必须比同类产品更好用，更敏捷，而且产品是一个不断完善升级的过程，对代码的框架以及维护性都具有更高的要求。

超人哥哥

说得好