本文来源: 不知名产品露
181
对需求已知的前提下进行0到1的系统搭建。以M集团的项目进度管理系统为例:
一、核心业务流程 通常我会从用户行为路径出发,对流程中涉及到的角色、场景等进行串联,搭建核心业务流程与分支流程,拿上方所提项目举例,与业务方调研后获得进度管理业务流程如下,为线下手工作业流程: 流程简述: 1)流程图中可发现,一份计划从创建到投入使用的审批效率较低; 2)计划投入使用后,通过打印纸质版,张贴上墙的方式进行日常进度的填报,时间久了不便于查看、且易丢失,可视化效果不佳; 3)每周例会时,才进行工程完成情况/问题的汇报,时效性较差,出现问题不能第一时间采取相应措施,影响工程进度。 与项目生产部门负责人沟通了解到,他们有专门的工具进行计划编制,但工具不能提供后续的管理工作。由于计划较复杂,业务人员也习惯使用该工具编写计划,讨论后确定计划编制依然保留原线下工具编制的方式,计划编制作为一个节点,从该节点以后进行线上化管理。将工作流程(如审批流等)纳入到系统规范化管理的一部分,在系统中支持计划增删改、进度上报、工作审批、工程可视化管控等。 流程中涉及角色: 1)项目生产部人员:参与制定施工项目的施工计划、并负责实施等 2)项目生产部总监:管控工程施工全流程工作;科学组织和管理施工现场的人、材、机等各生产要素;参与施工组织设计等多项工作 3)分公司生产部负责人:对所辖项目的施工情况进行协调管理 4)集团工程部负责人:对所辖分公司与集团项目的工程进展实施监管、制定相应业务管理办法等。 以上岗位职能非标准化,各公司职责范围可能存在差异。 确定后部分业务流程图如下: 二、产品定位 主要为了更清晰的明确产品目标,产品对业务的支持范围或总体的功能目标。为谁提供什么支持。如以上案例主要是为工程企业提供施工全过程的进度监督管理、降低项目延期风险,提高企业竟争力。 将抽象的定位落到具体实施中,我一般会从系统实现形式、系统分类、不同业务人员的功能分类几个维度进行分析。 1)根据客户日常工作场景了解到,管理者通常较多时间在办公室进行工作监管、定期到项目上进行实地检查考核等,一般会有助理类岗位人员同行; 一线业务人员,较多时间在项目施工现场,很多工作基本通过手机进行处理,在类似周会/月会等情况会在办公室进行,项目前期一般也会在办公室进行项目情况梳理; 综合以上实际情况及投入产出比分析,最终确定通过PC端和移动端小程序结合实现。 2)对一线业务人员来说,需要一个方便操作工程计划相关内容的平台,因其需要对计划进行一系列的操作,若出现风险,还需进行纠偏等动作;对管理层来说,需要为其提供一套管理后台的能力,因涉及工作规范的制定、业务内容的审核等;对前面两者来说,均需要提供一个可视化模块,快速了解工程进展,因工程可视化模型的特殊性(文件格式、解析时长等不支持移动端),不便于在移动端查看,所以会在PC端进行实现。 通过以上分析,我们进一步将系统拆分为3大模块,每个模块的定位不同:
三、应用架构设计 一般需要与公司已有的系统架构相融合,不同系统模块之间如何衔接。因涉及技术专业性方面的内容,需要与研发负责人等共同讨论确定,此处不做展开介绍,感兴趣的小伙伴可以自行查阅。 四、功能模块设计 一般会把能想到的功能都列出来,做加法,不局限于某一个环节,将系统未来整体规划思路做罗列,如基于以上3个模块,做拓展及与其他业务系统的结合功能。
五、演进蓝图设计 大的产品架构出来后,可以进行版本拆分了,根据业务需求排好优先级后,确认产品的功能规划与实现节奏,是否和其他业务系统联动,若有,我一般会单独估算这部分的排期,防止因为对方系统排期异常影响本系统。这步蓝图设计我主要用来做减法。 以上案例,一期会将核心业务流程作为首要实现的目标,如进度跟踪;二期聚焦解决特殊业务刚需的诉求,如风险把控;三期主要关注可视化方面的附加能力,如形象进度展示等,我习惯用框架图进行梳理,便于一览整个系统的结构与排期情况: 以上是我对整体产品方案设计的思路与大致案例,希望对你有所帮助,欢迎一起交流学习。 作者:不知名产品露 。未经作者许可,禁止转载。 文章来源:“不知名产品露”,未经允许不得转载。 文章代表作者观点,版权归原作者所有,热传平台仅提供信息存储空间服务。 |
2024-11-05
2024-09-29
2024-09-26
2024-09-26
2024-09-24
2024-09-24
2024-09-24
2024-09-24