需求包的颗粒度要合适控制，一要具有关联性确保是流程线上的有关需求点，不至于一个批次的需求南辕北辙；
二是具有相互依存性质的特例需求，可能需求间互相依赖、需求和队友互相依赖，同样的这个问题在需求评估中也要考虑（类似于之前说的杠杆套，为了更重要的功能提前放出来的功能杠杆），每个批次需求包也好迭代周期也好，都有瓶颈所在，识别瓶颈才能迁就瓶颈；
三是粒度的划分要合适，这个问题我比作拿一个巨无霸面包吃和拿一个个一口可以吃完的面包的感觉，合适的粒度可以作为资源灵活调用，符合小步快跑的敏捷理念；#ispiik小站#
每个人都面临过这种情况，A美食想吃、B美食也想吃、C美食也想吃，但是又不可能一次吃完，只能拍出来顺序，在一段时间内陆续吃完。
吃饭我们是怎么做选择的呢？
也许你会考虑，ABC三种的价格，到达ABC三个点的时间花费，以及三者目前的是否有活动又会、目前自己意愿里最想吃的是哪个，然后排除顺序。
在做产品的过程中会出现同样的问题，面临一堆产品需求，但是不可能在一个迭代内全部搞定，那在一个迭代周期内如何选择要做的内容也是个不得不面临的问题。通常上，可能是由boss直接基于经验判断拍脑袋，或者大家讨论都觉得应该做什么，不过总觉得虚了些。之前读到苏杰老师人人系列中设想过用群体打分获得商业价值（但是实操起来比现实），然后性价比=商业价值/实现难度决定需求list的优先级。
如果同类别需求，具有可比性，还可以尝试F/C的方式得到价值高的需求，F代表功能系数（比如有10个需求，每个对应功能值然后求和，F为当个需求功能值占比），C代表成本（简化为瓶颈资源，多数为开发资源，然后同样的求占比）。
———————————-
上面的过程也正应了：不能因为简单就先做，不能因为价值大就先做
得到价值需求或者性价比需求之后，还需要考虑：
杠杆套——连环杠杆的情况，比如#微信# 上线打飞机的那个版本，后来听说是个连环套功能，因为升级版本才能玩打飞机，然后客户端升级版本是微信支付场景的一个前置条件
#会议# 七人左右的小组可以完成讨论并产出想法，当人数再多之后 大概率上要么是一边倒要么是众口无言，这点在工作经历中不乏看到。如果人数众多，比如几十人，分小组（每小组控制在7人左右）进行会议是比较合适的，提出议题，以每小组为单位进行内容产出，这时候你会发现竟然有了竞争意识、团队意识产生。
好处在哪里，小组会议缺乏信息的广度，群体会议缺乏效率，结合起来之后效果会好不少（不排除小组内部仍然存在跟风一件）。比如面对一个问题的解决方案，就可以尝试“卡片分类法”先storming出来各种方案，然后汇集、讨论、分类。
【#需求采集# 大生产运动】18年Q4做过一个项目，因为产品名称中有个“匣”字，所以项目名字叫做“钢铁匣”，当时处于实测的需求大采集阶段。一想促进尽快的通过小范围实测暴露产品问题，二来挖掘需求，所以我组织发起了需求大采集的活动并制定了相应的奖励规则。
方案起草、时间规划、审批、kick off启动大会，一条龙顺利的开启了那次运动，那时候搞的奖项也是五花八门：
成长奖励【挖需求的】——为提供有限需求贡献的（转化为产品需求）奖励20元每个需求
突击奖【促进数据新增】——为在要求时间内在新交易系统产生订单数据的同学给与5元/人次奖励
技能get奖【提升培训效果】——对培训内容进行抢答形式提问，回答正确的同学奖励10元每题
数据协作奖【奖励协作】——为系统切换前提进行基础数据整理的同学给与奖励
种子用户【前期的种子用户奖励】——100元/人奖励、颁发《2018年钢铁匣项目影响力用户》证书
比对测试奖【小范围实测参与奖励】——给与小范围内测的参与人员额外的奖励支持200元/人
这次大生产活动总计花费了6980元，持续大概2个月，对项目推进起到了不可忽视的作用。
整个活动10月份启动，直至那年春节前夕结束，并在春节后申请下来了资金制作了证书，当公布并发放奖励的时候感受到大家对于这种形式的重视，仪式感也算是到位了。
经此之后：
①大家由此养成了需求提供的习惯，基本上摒除了上来就抱怨的搞法，很多人开始给我主动说他的场景、问题、想要的
②由于前期的触点安排分布较广，基本每个部门都培养除了用户代表，会进行典型的体验反馈，沟通起来也更加顺畅
③竟然遇到有的同学会在提需求的时候帮相关部门的用户也考虑一下，这种情况简直是万幸
过程中并没有用什么标准的需求收集工具，计划过用钉钉表单、格式文档，但毕竟是业务型团队还是放弃了，归集由我统一用看板进行管理，但相关人员可以有查看权限（其实几乎是没人会看…）。加杠杆之后的需求采集，你会发现异常发散，不失为一件好事儿