学会“引导”,让需求快速落地

144
作者 KEVIN
字数 4197 阅读 114评论 0

周末因PMTalk产品社区2.0正式发布,2天太忙了停更了2天,我深感抱歉,并且由于太多同学订购电子书籍《从零到壹:PM改变世界的点滴》,我会在每天中午12点左右抽空将电子书发送到各位同学的邮件中。若没有收到,可以在我公众号留言邮箱即可。


回过头来,近期在负责公司OSS门店系统模块,对接较多内部业务人员和服务人员。在该场景下,后台产品的工作与前端产品不同点区分就较为明显。加上业务人员只清楚自己业务服务,不清楚如何将整个系统的开发框架以及未来涉及的数据迁移工作复杂程度。整个需求落地,产品人员要成为一个节点与引导点,不仅是将业务需求落地,也要让整个系统能够低耦合、易维护去建设。


业务人员总是说“yes”


当后台产品同学将需求调研后,落地整个需求的过程中少不了与业务人员反复确认。这里的反复确认涉及到几个维度


  • 这样解决你们的需求满足吗


  • 业务走转可以按当前产品设计进行吗


  • 业务期望时间点与优先级

在个人工作中,这样的反复确认可以有效降低产品人员在评审会中“砍需求”的场景,并且可以尽可能的按照小步快跑方式。确认每个版本的最优先需求、对业务的了解也会更加有深度,挖掘需求背后的理由。


就像曾经我分享过关于后端产品同学,你觉得我这需求怎么样?,业务人员对于需求的理解因为职业、环境等种种因素。产品人员通过以上反复确认可以发现部分需求是不需要开发资源或许涉及到一些配置或文案的修改就可以将其需求完成。


在以上的3个维度确认中,业务人员因只会考虑到业务需求是否满足,无法确认产品架构和数据结构等问题。很多产品人转型前并不是开发同学,为此对业务的复杂程度只能尽可能的排除与其他业务在“业务上”耦合的问题。



在这样的情况下,拉上开发同学一同前往沟通是很必要的。曾经在负责账户体系涉及到账户体系的3层架构,accountperson身份信息,没有后台同学产品人基本无法清楚定义其账户体系架构。这一点拉上一个后段人员是非常有必要的。



“引导”业务需求


就像上面说的,除了收集业务需求之外。后台产同学需要站在产品与开发角度有意的让整个系统的建立易扩展、易维护,例如数据迁移这样的问题。是在业务人员需求沟通中最容易触发的一个“坑”




例如上图中,产品1和产品2其实为同一个产品。但因为产品1在后期随着业务发展就服务2更加精细化落地,产生了原属于不再服务的服务1.5.


针对业务人员,往往是在产品1周期提出服务1、服务2、服务3;在发展到产品2后,再提出需要取消服务3,增长服务1.5。


这个业务需求的收集是一个很典型的不易维护列子。在这样的需求背景下,第一是调研清楚该业务是否有扩展情况。第二是考虑如果不做扩展,后期会牵涉到一个老用户,在购买了产品1后,如何让他的数据保存于产品2中。毕竟产品2中是没有服务3的数据。



假设第一种情况下,后台产品同学没有考虑到产品1后期会发展到产品2的情况下。同一个用户必定会产生数据迁移和修改等问题。对于开发同学来说,又是一件不相干的多余事件。


产品人员的意义在这里就非常明确,能够有意的引导该业务需求方去设想未来可能存在的场景,将其落地在系统上,前面所说的易维护和低耦合就会在需求中过滤。



另外我个人第一本书籍《从零到壹:PM改变世界的点滴》电子档正式上线这本我归纳222篇产品原创,涵盖产品经理面试、算法、交互等不同维度的内容,如果你感兴趣可以打赏后留言你的邮箱。我会在每天中午12点左右发送到你邮件中(希望大家勿外传支持,支持版权)。如果你需要预览书籍大纲,可以跳转链接


一本给自己与产品人的书:从零到壹


经验分享
登录 后发表评论