一:业务产品的需求来源与分析:
业务产品的需求主要来自于(运营(业务)、用户,领导和数据)。具体体现为
1,运营提出日常遇到的一些问题,提出系统优化需求。
2,用户使用过程提出的反馈或者疑问
3,领导因为根据战略的调整提出的项目需求。
4,数据驱动,根据上线或者历史数据分析出的问题。
二:业务产品的的知识结构:
懂公司业务就是懂公司的商业模式和流程规范,商业模式即公司在这个行业里面正常运转的窍门,流程规范即运行商业模式过程中各个环节的细则。
1,懂商业模式:即要了解公司是如何将产品(实物,虚拟产品)以合理的方式,通过有效的渠道卖给目标客户群体以此赚取利润的。具体可以参考以下几个方面(图一),具体案例
2,懂流程规范:即要了解公司各个部门之间、公司与商家之间等各个角色是如何运转的,具体的业务目标和业务流程是什么。具体体现如下:
2.1行业规则:公司所在行业的规则,比如金融、房地产、零售;
2.2公司制度:在公司发展不同阶段、规模,都会选择更加有效的公司制度来适应公司发展;
2.3专业准则:比如会计准则、采购准则、营销宣传等都会有相应的规章制度
3.注意事项:一定要深入考虑业务的边界性,考虑业务的异常流程以及系统异常流程,确保业务形成闭环。
三:业务产品核心能力之-两会:
业务产品经理的灵魂就是做好两个评审会,业务评审和需求评审,一个是知道要做什么,另一个是传达给其它部门需要做什么,产品经理一定要做好这个沟通的桥梁,不然到时候会出现一堆的问题。
1,业务评审会:主要是业务部门或者需求提供部门和产品经理之间的对话,需要产品经理把业务聊透,如果业务部门不能很清晰地表达需求,您可以引导他去深入思考。千万不要模棱两可。可以参考以下几个问题
1.1需要做什么业务?(最好一句话描述清楚,如我要做商品审核上架业务);
1.2这个业务的用户群是哪些人(公司内部员工(权限问题)、销售人员、B端管理员,C端用户)
1.3这个业务解决了目标客户什么场景下的什么问题?(考虑是否是伪需求)
1.4做这个业务的目的是什么?(考虑需求紧急程度)
1.5注意事项:全程记录业务部门回答的这些问题,最后再跟他进行确认(记住这很重要,如果出现问题到时候可以找到问题的根源,避免下次犯同样的问题)。
2,需求评审会:主要是技术、测试、设计部门和产品之间的对话。基于业务流程图+产品原型+需求文档进行需求评审。如果时间配合得当,尽量把三个部门拉到一起开会,这样节约时间,效率更高,并且能够尽量保持大家对该业务的思想统一。注意事项如下
2.1评审过程中,你要主导这个会议的主线和节奏,但是也要保持和各个同事之间的互动交流,不能是你一人独秀的舞台。当你在对接需求的时候,你要时不时地问问设计师的态度,看看有没有更好地设计方式,问问技术小哥哥们的意见,看看这个技术难易程度;问问测试部门同事看看有什么疑问。总之不能一个人说,要让其它部门的同事积极参与进来,一起去当着自己的孩子一样做好一个功能或者一个产品。
2.2把所有潜在的问题讨论清楚,各个部门有什么问题要及时反馈,如遇到现场解决不了的问题,也要在会议之后及时反馈,避免遗漏,也是你负责任的一种体现。
2.3现场协调资源,尽量各部门定一个排期;尤其在大公司,不止你一个产品经理,各个部门有很有的需求要做,要在现场拍板排期,当然没必要细分到小时那么准确。当时各部门有什么问题可以现场提出;这样才不会打乱你做其它需求规划的节奏。
2.4设计师设计出产品之后自己对照一下没有什么问题最好是在同步给业务部门确认一下,是不是他们想要的东西,这样尽量能保证不返工;提高效率。
本文来自投稿,不代表重蔚自留地立场,如若转载,请注明出处https://www.cwhello.com/209500.html
如有侵犯您的合法权益请发邮件951076433@qq.com联系删除