标签： 需求

说需求分析像是需求管理的催化剂，从用户需求到产品需求的过滤器。需要经历透过现象看本质的过程，iamsujie提出了典型的Y模型，找到用户的本质诉求然后形成产品功能。

从问题到解决方案，其实是解构和建构的过程，解构用户（打的够散，看到真实世界） 建构产品（极具收敛进行产品提炼）。 ​​​​

【#需求采集#  大生产运动】18年Q4做过一个项目，因为产品名称中有个“匣”字，所以项目名字叫做“钢铁匣”，当时处于实测的需求大采集阶段。一想促进尽快的通过小范围实测暴露产品问题，二来挖掘需求，所以我组织发起了需求大采集的活动并制定了相应的奖励规则。

方案起草、时间规划、审批、kick off启动大会，一条龙顺利的开启了那次运动，那时候搞的奖项也是五花八门：

成长奖励【挖需求的】——为提供有限需求贡献的（转化为产品需求）奖励20元每个需求
突击奖【促进数据新增】——为在要求时间内在新交易系统产生订单数据的同学给与5元/人次奖励
技能get奖【提升培训效果】——对培训内容进行抢答形式提问，回答正确的同学奖励10元每题
数据协作奖【奖励协作】——为系统切换前提进行基础数据整理的同学给与奖励
种子用户【前期的种子用户奖励】——100元/人奖励、颁发《2018年钢铁匣项目影响力用户》证书
比对测试奖【小范围实测参与奖励】——给与小范围内测的参与人员额外的奖励支持200元/人
这次大生产活动总计花费了6980元，持续大概2个月，对项目推进起到了不可忽视的作用。

整个活动10月份启动，直至那年春节前夕结束，并在春节后申请下来了资金制作了证书，当公布并发放奖励的时候感受到大家对于这种形式的重视，仪式感也算是到位了。

经此之后：
①大家由此养成了需求提供的习惯，基本上摒除了上来就抱怨的搞法，很多人开始给我主动说他的场景、问题、想要的
②由于前期的触点安排分布较广，基本每个部门都培养除了用户代表，会进行典型的体验反馈，沟通起来也更加顺畅
③竟然遇到有的同学会在提需求的时候帮相关部门的用户也考虑一下，这种情况简直是万幸

过程中并没有用什么标准的需求收集工具，计划过用钉钉表单、格式文档，但毕竟是业务型团队还是放弃了，归集由我统一用看板进行管理，但相关人员可以有查看权限（其实几乎是没人会看…）。加杠杆之后的需求采集，你会发现异常发散，不失为一件好事儿

记得梁宁老师产品思维30讲里面举了个索尼音响的用户访谈，大致是问用户新的音响他们偏向选择什么颜色，提供黄色和黑色可选，大多数都选择了黄色。然后访谈结束，组织者说门口有黄色和黑色的音响作为回报，每人可以任选1个带走，结果清一色的选择了黑色带走……

用户怎么说≠用户怎么做
这个现象现实中也很多，我们说自己明天要早起、他说明天开始减肥、他说旅行中希望导游可以全程陪同，但事实往往并非如此。不是说用户蓄意，更像是信息不完备情况下或特定非典型场景的引导导致的偏差。

前两年做旅游交易系统产品时候，对于销售、财务反馈的优化问题，我往往更愿意到他的工作场景中去查看相应的问题。经常会留一句：今天再现这个情况时候发个消息，我现场了解下。这种情形基本上用户可以边做边说再加上真实场景，bingo！往往你会挖出这个表面问题背后的隐藏问题#ispiik小站#

去年原团队和某匣科技公司联合开发旅游B端产品，作为甲方难免催的急一些，所有人都感觉乙方不给力，期望的时间内这里上线不了那也上线不了。

岂止是人力巨贵的产品团队，连当时的旅游团队也是如此 门店客户/游客又n多对产品的需求，我们还不是一样遥遥无期

究其根本，不是不为，是那个时刻那个资源那个形势下，我们都要找到对自己组织发展产品发展最有力的事情去做，体现出来就是做那个feature做什么产品。

没有资源完全充足的团队和环境，所以总需要找杠杆最大的，ROI高的动作。

我们可能面临的是：高端vs大众客户、城市vs区县、男性VS女性、老年vs青年、老客户VS新客户……当然，你无需满足也不可能满足所有用户的需求。#ispiik小站#

搞工程造价的同学都知道，建筑中有很多定额（企业定额 行业定额 区域的 国家的 协会的），定额就是不同颗粒度的事情在特定环境条件下完成所需要消耗的资源的一个标定。之后在工程业务中会广泛用到，比如招投标、业务核算、财务核算、目标责任制定等等，比较典型的一种对应关系就是：实际场景中的一项内容和定额之间，不一定是一对一的关系，可能多对一、一对多，完全取决于当个场景下融合而成的信息单元粒度如何。

继续阅读iSpiik快记018：需求vs功能，工程vs定额