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