我怀疑这个“高级产品经理”可能是假的!(4.2K字)
共 8298字,需浏览 17分钟
·
2024-04-11 20:37
击蓝字
关注我们
01
战略层对应产品目标、用户需求。是对目标,需求的商业化方案的归纳。
范围层对应产品的信息和功能点,涉及到产品的侧重点和取舍。
结构层对应产品的实际落地,产品在这个层面开始具体化。
框架层对应产品具体内容的呈现,产品进一步具体化,落实到界面。
表现层对应产品的视觉传达,是产品的美化。
业务层(抽象业务诉求)
功能层(界定功能定义)
数据层(设计数据结构)
实现层(探讨实现机制)
重视第一层,是需求分析师;
重视第二层,是上文体验五要素的践行者;
做到后两层,你就是别人眼中“懂技术”的产品经理。
做到上述四层,你就是让团队舒服,让运营省心的产品经理。
02
“兵者,国之大事,死生之地,存亡之道,不可不察也。”
同理,调研需求,是获得立题的基础。分析需求,是脱胎出产品雏形的依据。
因为我们看到的用户行为是杂乱的,用户的需求也是无序的。这时候进行归类和穷举,再提炼并抽象出用户的需求模型。
面向故事:是面向用户场景,按照用户与业务场景,定义需求。
面向对象:是面向用例图,按照用户与产品系统交互的场景,定义需求。
面向结构:指的是面向功能结构。以“输入-计算-输出”的模型,分析功能分支,并组建功能树。
领域模型,是对领域内的概念类或现实世界中对象的可视化表示。是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。
03
过于舒服的操作,用户感受不到背后的复杂逻辑。轻轻点击一个按钮,服务器要承载多大的压力。后端产品数据量可能瞬间暴增到极点。
功能替代,就是换一种方式,比如页面勾选操作,一次只能选择100条,那么我们可以改为批量导入后异步执行;
交互补偿,就是通过交互,制造障碍或者制造便利,“强制”教化用户。
组合功能:就是通过多个功能配合完成。以上述例子来说,可以通过单门店全量操作+复制门店上下架关系实现。
即:全量商品上下架时,系统要求必须是单门店。等做好一个门店的时候,其余门店可以复制这个门店的商品的上下架状态。
这个方案从后台处理量来说,和直接支持全门店全商品差不多,但是操作的“复杂”,会减少用户频次,起到一定避灾作用。
降维处理,就是考虑线下其他方式解决用户目的。比如《后端产品经理宝典》一书中一个案例:做一个防止客对订单做手脚谋取私利的功能,不如不做功能,而是改用加强团队培训和监管的方式。
04
05
再看一个例子:
想象一个对码功能:检测平台销售的商品编码,在ERP能查到,查到即为对码成功。以确保能正常发货。
触发条件:创建平台后台的商品的时候、手动点击对码的时候、从平台下载商品的时候,挺多的。
那么就可以把这个对码服务做成通用的插件,供多处调用。
这些可以被共同调用的,可视为中间件,将其用模型化的通用的轮子。当技术架构是这种架构的时候,就可算微服务架构。
在微服务架构中,每个服务都是自我包含的,并且实现了单一的业务功能。
到这里需要明确,我们不是指导开发写代码建数据表,甚至也不是干涉。而是基于业务提出的业务视角的技术设计建议。最终以开发的为准。
我们也只需知道技术的原理即可。
END
写在最后:欢迎支持我的新书
《TOB产品之美》,把我十年的经验写在了书中。推荐学习。