在日常生活中，无论是软件还是网站，往往产品来自于需求。但是天空飘过一句话 —— 需求为什么要聊呢？
为什么要聊
- 需求方并不非常明确自己的需要什么样的产品。
- 在实际操作中，不能根据需求想要做什么，就去做什么。因为需求方往往自己得到的解决方案，就把解决方案告知你的。他可能不是专业的，当然你也未必是专业的。需要深挖需求方的需求的动机、背景、为什么会有这样的需求。越完善的产品描述，较多的相关的方的视角，能够更好的描述出一个完备的需求。以上是一个经典的
xy问题，往往是解决这类场景的较好思路。
- 在实际操作中，不能根据需求想要做什么，就去做什么。因为需求方往往自己得到的解决方案，就把解决方案告知你的。他可能不是专业的，当然你也未必是专业的。需要深挖需求方的需求的动机、背景、为什么会有这样的需求。越完善的产品描述，较多的相关的方的视角，能够更好的描述出一个完备的需求。以上是一个经典的
- 需求会遇到产品如何落地问题——可行性。
- 做一个百度 —— 就一个文本框，点搜索跳过去。
- 做一个XX地图 —— 把我们的运单可视化起来。
- 做一个微信吧 —— 。。。。。。。。
- 总结
- 我相信以上都是极端场景，大部分产品大佬都是靠谱。
- 大部分被借鉴的产品都是业界的标杆。背后该产品成功的细节，对方做出的努力，所处在的时代背景，人话就是“天时地利人和”，都下意识被忽略。
- 更多的时候想造一个万能的锤子，解决一切钉子问题。
- 到底这事情可不可行，遇到这类问题，不要忙着拒绝和 say no, 这样会让人感觉推诿, 好好坐下来好好聊聊，怎么操作，能不能操作，可行性问题大部分能解决。
- 需求会变。
- 需求在被细化以后，提出需求的人，自己可能对需求有更深入的了解。这时候需求可能有变化很正常。
- 需求在落地的时候会遇到这种问题（可行性延后暴露）。变化也很正常。
- 所以定期的双方同步，很有必要。
怎么聊
- 画个大象，做个老鼠——信息传递会丢失。
- 往往需求在被描述和传递以后，最好是减少转述的中间人数量，因为每次交流，总会丢失起码20%都 信息系量。所以我们最好做好文字记录。
- 可信性问题。
- 需求交流时，要考虑一下当前的手上的资源能不能启动和跑完这项目或者产品。要尽可能考虑金钱、人力、时间、各方支持，虽然是不可能尽善尽美，但也要做到准备完善。
- 阶段性聊完需求，记得聊一下需求的落地问题，看一下当前需求结合当前个人OR团队的资源在落地环节，尽可能的考虑一下落地会遇到的问题，如何解决这个问题，当前关键点有没有
Plan B。
- 文档
- 需求文档贯穿整个需求交流期间。所有需求的来源和动机；需求交流中的产出；大家的意见；项目落地的可行性问题。
- 在设计的时候需要有设计问题。设计文档即是你的产出，也是你的想法的总结，更是让同伴了解你思路的重要工具。
- 我们为什么需要原型图。
- 有时候文字不能完全表述清楚相关问题，特别是做含有界面或者可视化元素的产品或者项目。
- 原型图能很好的辅助你表达观点，帮助伙伴理解你的需求和设计。
需求变动以后体现到原型图，也能帮助大家记忆和理解相关变动。
所以我们为什么不能多画一下图呢？
So
A: 这需求啊，我们坐下来多聊一下吗~
A: 我们多聊聊，然后多记一下！
A: 这个X需求要这样搞，否则落地会遇到123的问题啊！。。。。。。
A: 我这也出个设计文档，到时候您斧正一下！
A: 还有些边界问题没聊清楚，小张听懂了没有？
A: 这样啊，我们画个（原型）图，大家看看理解是不是一致吧！
A: 要不我们出设计图，拆解一下TODO和OKR吧~
B: 滚~ 今天聊需求，不聊排期！