这样的案例在生活中听到、看到的实属不少。所有的BP大概就是拿着自己的目的作为撬动资本的手段吧，呵呵。高考时目的吗，显然不是，它只是进行人才分流筛选的手段，但是高考前学生的目的就是它，但是对于家长和学校又在用这个目的当作手段去激励和引导学生。做产品也不是目的，是实现商业价值的手段而已，商业价值又是为了完成使命愿景。
切忌把本该是手段的东西当作目的：有个人吃饭用勺子，勺子本来是工具而已，他非要找到一个完美的勺子去吃饭，结果饿死了（杜撰情节，现实中可能是你公司里面的KPI、某项极其形式的制度；最近纯银v分享个例子，他在taptap群给成员说不用回复收到，结果下面一排整齐的收到…… 先僵化后固化再优化，任正非的这个理念也要看应用背景）
目的，作为结果的同时，也是达成结果过程的一个条件。同一件事情手段还是目的是相对存在的，有了这个思维，做人做事中就会尽量避免短视行为，保持对远方的关注。#ispiik小站#
拟定各种流程、制作各种模板、设置各种规则，这是一个人或者组织处事风格的抽象，或者说是价值观的部分具体体现…
每一个职场人或许都想留下点什么，我们拼命的向前跑，但是最终的终点始终是一个人无法到达的，我们需要一群人、更多的人加入一场逐梦的旅行。
自己也曾在团队中做过这样的事情，为了在线旅游小组和产品部门的交互更加清晰，自定改良版的确认件模板；为了策划小组的组建初期工作开展，拟定作业流程和工作管理表（事后看其实就是需求list）；团队ERP产品的落地拟定了各种操作规范，还去往当时集团其他的子公司推广……
各种流程也好、模板也好，都是一种工具和手段，究竟目的？
①确定性——让多边协作的人保持在同一个语言和模式预期上，提高沟通协作效率
②指引性——在既定的框架内填充内容、事件、行为，更容易进入轨道
③标定性——就像大海上点亮的灯塔，你会看到需要到达的地方，不至于遗漏和忽略#ispiik小站#
【里程碑与确定性】职场中经常会遇到这种情形，面临某个艰难的任务，boss说：达到****数据/完成***工作，我们发xxx奖金+聚餐happy
这就是一种典型里程碑设置，当然更多时间你可能没这么好命。里程碑是在达到目标前的中间存在的，可以看作是对达标路上抽象的表达：
①人的内心渴望确定性，不管是参与者还是项目管理者，所以我们希望有明确的抽象出来的标点标定在预期（时间 资源）下达到的位置；这样才能更加专注和聚焦
②不断的对标，进行纠偏
③资源的阶段分配
#晨会# 是很有意思的一件事情，一般会在打某个战役或进行某种项目时候发起的一种临时会议形式，可以将战斗意识注入到以天为单位的时间里面，每天的对标，重新建锚，可以让参与人员身心投入到进度、目标的关注上。
晨会X：去哪儿酒店BU当年做市场覆盖，考核代理、直销、夜销酒店签约数量。每天晨会会有几分钟的破冰互动（可能是个拉手转圈圈）、个人分享、数据概览、每个BD报今天自己的签约目标，然后撒网放BD，每天晚上收网拿回来签约协议然后电脑上线酒店产品。
产品实现过程中，一般也都会有晨会形式，保持小组成员信息的触达确保大家都是同步的，对X问题可以即时的投入关注和调整，算作是项目管理中动态管理的范畴。
所以说，瀑布模型和敏捷模型谁对谁错？简直是泥中有我我中有你啊#ispiik小站#
产品实现过程中，工作量评估出现不止一次：
①需求要想活，你得描绘它的性价比，在需求list入包的时候要初步评估一边工作量
②立项之后，需求确认冻结，这个节点有一个纳入工期的工作量评估，这个是需要尽可能贴近事实的
这个地方通用的三点估算法：（最乐观+最悲观+最可能）/3作为项目时间计划里的工作量。
为什么要估算？我们结构化拆解一下，工作时间包含：
准备和收尾时间
不可避免的中断时间
低负荷工作时间
正常负荷工作时间
其他交纵事项占用时间（比如某个攻城狮的紧急bug修复）
工期的得出怎么来？
①项目是有一个个功能list的点来的，称之为工序，工序之间存在逻辑关系，比如不张嘴怎么吃饭
②各个point的工期是条件
③其他的技术间歇、组织间歇等
④一个工期计划中，必然有一条隐形的关键路径，大佬尽量安排到关键路径，因为这个路径的延缓和提前是直接与工期相关的
#ispiik小站#
如同之前分享的：做产品充满了解构与建构的过程，解构用户的真实世界然后建构起来虚拟世界；项目管理重执行，更像是数学中一道有了完备相关条件（时间资源范围）的解答题。
换个比喻可以把做产品看作是把握方向盘手握挡杆脚踩油门刹车，你得看产品的发展、走向，驾校时候教练经常说：眼不要老看着引擎盖，看远些！项目则是在方向盘指明了方向之后，沿着道路前进。
杠杆也不同，方向盘在科三路考时候走直线那可是动都不敢动，生怕稍微动一下走到另外个车道了；项目就如车轮，你们给了方向油门，车轮就如是前进。
项目像正确的做事，产品像做正确的事，一个是事一个是风格，一个是画一个是画风
需求包的颗粒度要合适控制，一要具有关联性确保是流程线上的有关需求点，不至于一个批次的需求南辕北辙；
二是具有相互依存性质的特例需求，可能需求间互相依赖、需求和队友互相依赖，同样的这个问题在需求评估中也要考虑（类似于之前说的杠杆套，为了更重要的功能提前放出来的功能杠杆），每个批次需求包也好迭代周期也好，都有瓶颈所在，识别瓶颈才能迁就瓶颈；
三是粒度的划分要合适，这个问题我比作拿一个巨无霸面包吃和拿一个个一口可以吃完的面包的感觉，合适的粒度可以作为资源灵活调用，符合小步快跑的敏捷理念；#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月份启动，直至那年春节前夕结束，并在春节后申请下来了资金制作了证书，当公布并发放奖励的时候感受到大家对于这种形式的重视，仪式感也算是到位了。
经此之后：
①大家由此养成了需求提供的习惯，基本上摒除了上来就抱怨的搞法，很多人开始给我主动说他的场景、问题、想要的
②由于前期的触点安排分布较广，基本每个部门都培养除了用户代表，会进行典型的体验反馈，沟通起来也更加顺畅
③竟然遇到有的同学会在提需求的时候帮相关部门的用户也考虑一下，这种情况简直是万幸
过程中并没有用什么标准的需求收集工具，计划过用钉钉表单、格式文档，但毕竟是业务型团队还是放弃了，归集由我统一用看板进行管理，但相关人员可以有查看权限（其实几乎是没人会看…）。加杠杆之后的需求采集，你会发现异常发散，不失为一件好事儿