网站怎么收录,网站海外推广多少钱,合肥今天发现了一例病例吗,网站索引量突然下降产品专业化就是上山寻路#xff0c;梳理一套作为产品经理的工作方法。本文作者从设计方法、三基座、专业强化、优秀产品拆解、零代码这五个方面#xff0c;对产品经理的产品专业化进行了总结归纳#xff0c;一起来看一下吧。 产品专业化就是上山寻路#xff0c;梳理一套作为… 产品专业化就是上山寻路梳理一套作为产品经理的工作方法。本文作者从设计方法、三基座、专业强化、优秀产品拆解、零代码这五个方面对产品经理的产品专业化进行了总结归纳一起来看一下吧。 产品专业化就是上山寻路梳理一套作为产品经理的工作方法。
以图为例做一个归纳。 **第一梳理自己的设计方法。**就是拿到一个需求点之后如何进行需求分析如何还原业务情况最终进行产品设计形成可供业务方确认的方案可供下游工作环节了解如何做的方法
**第二基于设计方法梳理软件系统三基座权限管理、组织架构、用户管理。**既验证设计方法也完成单个模块单个模块的梳理为后续更多系统模块搭建提供基础
第三强化专业技能抓好产品规划实现需求到版本的管理并借用竞品扬长避短
**第四基于设计方法、产品规划、竞品分析分析挖掘面世产品。**借用现有的各个系统ERP、WMS、TMS、OMS等站在当前面世优秀产品的肩膀上锻造自身关于产品的框架形成对于行业的整体认知也逐渐细微到各个系统部分明确主体逻辑与细微变化积累自身的实战经验
**第五构建零代码产品。**应对大批量小规模企业主路径相似、细节不同的业务现状提升数字化能力提升产品能力制造造工具的工具。
上山寻路路走通路走宽路好走。
一、设计方法 开发和产品之间的战斗似乎是天然的如何活着走出需求评审就靠设计方法。
若是自己的设计是闭环的逻辑是严密的、清晰的不管你开发如何翻江倒海我都岿然不动。
需求的本质是“做事情”就是通过串联的功能把这件事情办妥。例如请假这件事就是申请人发起申请由相关领导进行审批审批通过则休假审批不通过则不能休假。这里申请人、相关领导就是角色发起申请、领导审批就是功能。
应用场景梳理清楚什么人在什么情况下做什么事情。若是可以的话最好操作一下当前员工的工序体验到为啥这么做更关键是找到要什么结果 需求是否合理的终极校验 。
用例图梳理清楚场景还有其他角色没当前角色需要功能是否足够、完备
业务流程图梳理清楚参与的角色如何把这件事情办完特别需要注意异常流程示例如果直系领导不空缺直接由直系领导审核那就一定要考虑没有直系领导如何处理补全异常流程确保流程闭环每一个顺序流程都对应一个异常流程。异常流程可以合并但梳理时需要明确梳理出来
操作/状态图梳理清楚当前这个单据有哪些状态各个状态下有哪些操作特别注意为打造好用户体验状态要前置也就是这个状态下不能进行的操作要隐藏入口或禁用千万不要等到操作之后保存才提醒
交互设计通过以上分析将整体恢复成为交互原型至少做到 页面元素齐备跳转关系明确可以多积累页面元素形成规范这样原型趋近于高仿真对于信息传递有莫大好处也不至于消耗太多时间精力
数据追踪完成产品设计之后需要挑选非关键字段挨个页面检查以防止思考漏洞例如审核意见去看看在哪些页面需要展示哪些页面有却隐藏是否会有多条从而实现自身复盘。
实际上交互原型、PRD文档其中任一都可以表达清楚需求并准确将信息传递下去但为何需要都去执行就是换不同的角度去重复做这件事情让最后的结果更为精确。一个需求经历 业务评审、产品设计、UI设计、开发实现、测试验证 的过程是一个相对耗时耗资源的事情在需求这个源头上处理好将能极大地提升整体效率。
二、软件系统三基座 在所有需要账号密码的系统都需要权限管理和用户管理而用户需要明确组织关系从而权限管理、组织管理、用户管理成为软件系统的三基座。
三、专业能力形成 为了让我们的“产品”有效的成长起来我们需要施加“养分”不断修剪“枝条”确保“盆栽”如我们的“预期”长成。
在互联网产品中用户反馈、市场调研、竞品分析、产品设计、产品规划 为我们提供多维度的需求来源形成较为完善的“需求池”提供丰富的养分。通过需求筛选依据各个迭代版本修剪“产品功能”达成产品“版本树”的成长。
产品规划就是依据业务情况划分出产品模块明确各模块之间的数据通信形成产品蓝图为后续产品成长是否符合“预期”提供标准。
知己知彼百战不殆。在产品设计上也需要深入分析竞品扬长补短。
四、优秀产品拆解 很庆幸的是互联网行业并非是拓荒的年代已有很多优秀的、边界清晰的产品并为此提供了理论支持、实践参考。
一直以来知道有很多的系统但系统之间关系是如何的一直不太清晰。
实际上系统是为业务服务的是为降本增效而生成的。业务本身为系统的划分提供了基础业务链条主要包含产品、采购、制造、质量、物流、销售、服务那么也就需要对应的系统来为之服务物流业务需要TMS、WMS系统来支撑质量管理需要QM系统来支撑。
那为何市面上同一类型系统却有不同产品呢是因为不同公司业务范畴不同业务重心不同会在系统大框架上依据自己的需要来进行调整但其核心相同。例如CRM系统客户关系管理系统核心包含客户管理客户关系管理这个不变具体模块可能是线索、商机管理是信息丰富完善并转成收益的过程管理也可以是协议或合同管理主要是明确和客户之间的合作关系管理。
基于此在进行各个系统的拆解时就更为明确是依据业务的整体划分来的而在具体的产品上需要针对其服务对象分析其业务模式从而深入分析以了解其服务对象、实施业务的不同。
系统的设计实现了系统自身的闭环如上述CRM系统完成客户管理支持客户协议管理那必然隐藏包含协议过期管理、协议再签订、续期等管理。
系统还需要更其他相关系统的支撑、数据通信也就需要提供开放接口能力。但当前这一块的建设还存在较大较多问题这也是数据烟囱产生的原因。自身在设计系统时需要考虑和外部对接的可能性毕竟未来系统融合是大趋势。
五、零代码 系统核心不变细节功能因为业务不一而略有差异这为低代码实现提供了业务基础。
在互联网初期针对一个客户来完成一套系统。在多做过几套系统之后会发现系统实现有一些相似之处秉着降本增效的原则则考虑复用。权限管理、组织架构、用户管理 定为软件系统三基座也来源于此大多数用户管理的系统都需要用到。
之后了解的 业务中台、数据中台乃至于 技术中台都是由此而生成的。
所有系统仅从页面的角度出发也符合低代码生成情况。一个个应用系统是由一个个页面组成的一个个页面是由各类型交互组件组成的一个个交互组件是由页面元素组成的。
拆解好所有组件任一的系统都是可以通过组件搭建出来。这也是为何原型一定要明确 页面元素 及 页面跳转关系。 从组件出发逐步实现低代码构想则是组件支持构建复合组件复合组件支持构建模板模板支持构建库文件 库文件支持构建行业案例。
组件是最小组成单元是标题、输入框、Toast提示、图片、附件
复合组件是基础组件的组合验证组件搭建是否合理提高使用组件的效率
模板是页面框架、是交互框架可以验证复合组件是否合理大幅提升组件使用效率但因其复杂性较高适用场景就逐渐细分、固定
库文件是组件复用的更高效的场景更多适用在不同的项目、不同的人员上可以提升协作效率
行业案例不只是组件的高效使用更是解决方案的体现组件将从这里直接实现价值变现行业案例的丰富度将直接决定案例到项目的修改度、落地速度。
当前或许什么都没有莫怕先造一个、先造一点再不断迭代、完善就好。
