上周被开会告知有个关于售后安装维修的需求想要接入物流APP，于是业务方第二天找到我，沟通此事，用了不到一个小时的时间，展示讲解三页PPT，大概意思是要做一个给安维工程师用的APP，主要功能是指派给他们维修单，并且让他们通过APP及时反馈维修结果。接下来告诉我，这个需求比较着急，想知道下周能不能出一个大概的原型轮廓？

       对于一个陌生的业务，如果能用一个小时的时间沟通完需求，且不经任何调研，就把原型画出来，我想说即便做完，凑合交差，也一定不能解决真实存在的问题。但这就是现在普遍存在的现象，舍本求末，着急出结果，却不关注过程和本质。这样做出来的产品可以活，但一定活不久，于是有了敏捷开发，有了迭代。如果迭代是在大方向一致的基础上去更新，对开发、对用户都是容易接受的，这个产品会不断带给用户惊喜，是良性迭代；反之，如果方向不明确的时候，就一味追求创新，追求结果，那后面产品会变型，最后可能驴唇不对马嘴，四不像，往往迭代到最后已经和最初版本大相径庭了，即便最后可能是成功的，但付出的代价也是惨痛的。

       有些工作追求结果见效快，比如销售，最关心的销售额、毛利额KPI数字搞好了，80%就是成功的了。但尤其是需求类的东西，如果不搞清楚就下手，是很难做好的，最怕的就是不熟悉用户的前提下就妄下结论，意淫用户的需求。

       据业务方介绍，现有流程是网点把维修单分派给工程师，一般通过电话的方式分派，但因工程师时间不固定，最终上门服务的工程师经常和系统上分派的人不一致，导致系统里的维修单与最终的维修工程师不一致。他们希望能通过APP分派给指定的工程师，如工程师有事可以在APP上转给其他工程师，但如此流程，在时间上还是需要电话事先沟通好，而且万一客户的时间又变了呢？工程师岂不是也要连锁反应跟着一连串的变化？

      上周六根据业务方提供的三页PPT流程，用了半天时间研究他们现有的后台系统，发现在PPT的流程之下，还隐藏着许多环节，尤其是用户预约安装维修的时间，从后台数据来看，每个维修单都要经过至少两轮的改约，一般要经过半个月的时间，才能和用户在时间上达成一致，安装维修完毕。究竟是什么因素影响了时间的变更呢？——预感这个是优化流程的关键。

      在整个流程里，后面一连串的工作都取决于客户的时间，所以我们要从客户时间的角度考虑，为何不把客户想要预约的时间发出来，让工程师们主动去抢单呢？

      如果工程师反馈很重要，那为何现在不用微信群，或者邮件的方式搜集信息呢？究竟工程师反馈的信息会影响哪个环节呢？业务方一时也说不上来，还有待找真正的需求人——更了解业务的同事，或者网点和工程师去了解真相！

      总结下就是，业务方想要工程师通过手机接收维修单，反馈维修信息，这时我们不要直接跟着业务方的思路就展开手脚画流程图、画原型，而是要充分了解背后的问题，挖掘引发此需求的真相！这才是真正要解决的问题。

      需求像洋葱，等你一层层的去剥开~

以下转载：http://heidixie.lofter.com/post/b8226_6acf545

如果需求和解决方案你都分不清，就别做产品经理了

老生长谈的一句话，可是为何我们现实生活中总还是会犯这个基础的错误？

某天路过自己团队产品经理和需求方沟通的一个小桌子，侧耳倾听了几句，发现双方陷入争执，于是忍不住参与进去，发现原来双方正在纠结于是把一个任务管理功能中的优先级作为筛选条件还是排序条件……于是忍不住问产品经理了，需求方的需求是什么？是筛选？还是排序？还是什么？需求方的需求是让他能够从非常多的任务中把自己最需要关注的任务给找出来，或者再深一层，需求方的需求是能够让他一目了然知道现在最需要做的是什么。

而给出优先级字段也好，还是把优先级字段作为筛选条件、排序条件也好，都是解决方案层的东西。

不要过来给我投诉说：需求方的需求不合理，不靠谱，出现这种情况，大部分是因为我们还是停留在解决方案层面。

很多时候，需求方会直接提一个解决方案，认为就是他的需求。这种情况下，产品经理也无需苛责需求方。比如，你去蛋糕房里买蛋糕，也是倾向于说：喂，给我拿那个草莓蛋糕（这是解决方案）。而不会说：你好，我女儿要过5岁生日，我女儿很喜欢吃草莓，我让让她的生日很开心，你觉得有什么可以帮我的吗？这就有点太傻帽了。虽然一个去买蛋糕的顾客内在的需求可能是“让女儿的生日很甜蜜很开心”，或者是“让我的喜欢浪漫气息的老婆结婚5周年快乐”，但是能够简单表达出来的或许就是他认为最合理的解决方案。

需求沟通也是一样的。

一个需求方来说：我要想数据直接导出，不要每次下载都走审批。他不会表达成：我每周都要写周报，而我的周报需要好几张报表的数据整合，所以我需要导出数据在电脑上用Excel加工，但是因为每次下载都需要审批，不但麻烦我，也麻烦我的审批人，有什么办法能够降低我做周报的成本吗？

如果需求方描述成“有什么办法能够降低我的做周报的成本吗？而且据我所知，和我一样需要导出多张报表数据做本地加工做周报的小伙伴都是这样的痛苦，希望你们能够想想办法”，你可能会发现解决方案未必只有“导出”一种，比如长远来讲，你可以提供在线编辑器，小伙伴把需要做周报的数据都存在一个自己的数据环境里，在其中做加工，编辑，然后分享周报地址出去即可，或者去了解需求方周报汇报的对象看数据的需求，把其需求也做成在线可直接查询的报表……或者……

需求方可以随意表达需求，即使说的是解决方案，也不是他不专业，而是解决方案就在他的口头边。而作为产品经理，最关键的就是：

多问几个为什么，把解决方案背后的真正的“需求”给挖掘出来

场景验证，看看这个需求方的需求是否具备一定的通用性，个性化的需求和通用的需求有不同的解决方案

畅想解决方案，从中选择最合适的

解决方案与需求方进行沟通、与开发进行沟通，敲定

记住：没有什么需求是不合理的，只是解决方案够不够合适。