需求是一切商业行为的来源，是企业存在的立足之本，无论是谁不关注用户需求就不可能成功。需求也是一个老话题了，产品经理的核心使命就是满足自己用户的需求。
01 由业务主导的需求
toB或者后端产品经理通常是业务运营为主导，产品经理负责是配合将业务的需求转化为可执行的方案并推进开发同学进行落地。这里的需求通常可以简单分为“业务知识+问题列表”，业务知识包括为了满足业务运行及发展的一系列业务实体、业务事件和业务规则，比如某电商仓库管理系统需接入智能设备这样的需求，而问题列表则是用户在工作中需要解决的困难和障碍，比如用户经常抱怨软件“不好用”时需要批量操作功能的需求。前者是支撑业务运营生产的根本，通常优先级较高，可以列为项目重点跟进，后者则需日常关注跟进，多与用户保持沟通，利用手里的资源弹性解决。
02 需求错误的代价
需求错误的代价
这张图的意思是说，如果在需求阶段只需花费1个单位时间就能改正的错误，拖到设计阶段来改正就需要5倍的时间，到了编码阶段将是10倍，测试阶段可能达到20~50倍，而到了运行与维护阶段或许会达到200倍之多。其实道理很简单，毕竟需求阶段只是在“纸上谈兵”，随着开发阶段的不断深入，产生的人工制品的数量也就越来越多，要改的东西、推翻的东西就会更多，代价自然也就更大。
03 存在矛盾的需求应该拒绝
由于用户处于组织的不同层面，因此难免出现盲人摸象的现象，从而导致需求的片面性，甚至在不同用户之间会持有不同的观点。正是因为如此，我们还需要对用户需求进行分析、整理，从而整理出更加精确的需求说明。比如，对于一个有100个用户在使用的产品，如果该需求只影响其中1个用户（别跟我说这个用户是老板），并且该需求与其他用户的利益相左，那么该需求就可以考虑拒绝了。
04 开发说，这个真实现不了
产品经理在和开发同学沟通的时候经常会得到这样的答复，但我们要明白不能实现的是“需求”还是“方案”？这点老李同志在他的文章里已经说的很清楚了（感兴趣的移步：https://mp.weixin.qq.com/s/mQMMr5jGbDsr-NpmtDw8EA），我这里“借花献佛”转述下我的理解。需求可以比作一个目标，一旦确认好就不会随意改变。而方案是实现需求的方式、路径，实现需求的方案通常不止一个。比如吃饭，吃饭的方式有很多，我们可以根据自己的情况选择叫外卖、吃食堂或者干脆出去吃，可以根据口袋里的银子决定吃点简单的快餐、还是吃点好的。
因此对需求和方案的评估应该从不同的纬度出发，理论上来说，需求评估是产品经理的工作，而方案评估则是产品经理和开发同学一起配合进行的。需求的评估应该从其合理性、频次和价值这几个方面考虑，而方案才是从可行性的角度来评估，包括难易程度、成本（投入资源和时间）等。
评估需求时可以暂时不考虑实现方案，只看需求是否合理、发生的频度、以及产生了什么价值。一旦确定需求本身是合理、有价值的，才会考虑实现方案。否则，面对一个“假需求”，再完美的方案也无法发挥其价值。而在寻找方案时则要时刻切记，方案是服务需求的，完美的方案不一定是最优的方案，还要考虑方案的难易度及投入的资源和时间成本之间的平衡。比如拿京东618举例，如果一个需求是为了满足618促销活动的，而你为了追求完美的方案，导致开发评估的排期已经在618之后，那么这个方案已经偏离需求的初衷了。
05 好的产品经理满足需求，伟大的产品经理创造需求！
伟大的产品经理是不会满足于只等需求的，而是要去创造需求、发现需求和满足需求。根据需求创造产品，完善产品和服务，做一个需求创造者。真正的需求与传统的营销手段并无关联。创造需求是创造对人的了解，对用户情感诉求的了解。创造需求的过程就是需求管理的过程，也是信息搜集，综合，存储，加工，挖掘和价值创造的过程。真正的需求，潜藏在人性因素和其他一系列因素的互相关联之中。
末了给大家推荐一本书《需求-缔造伟大商业传奇的根本力量》。
end.
网友评论