惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - Franky
有赞技术团队
有赞技术团队
宝玉的分享
宝玉的分享
雷峰网
雷峰网
Hugging Face - Blog
Hugging Face - Blog
V
V2EX
大猫的无限游戏
大猫的无限游戏
博客园 - 司徒正美
D
Docker
T
The Blog of Author Tim Ferriss
罗磊的独立博客
博客园 - 叶小钗
酷 壳 – CoolShell
酷 壳 – CoolShell
Blog — PlanetScale
Blog — PlanetScale
月光博客
月光博客
J
Java Code Geeks
Jina AI
Jina AI
博客园 - 【当耐特】
C
Check Point Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
腾讯CDC
Last Week in AI
Last Week in AI
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
Visual Studio Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
如何开展产品整体方案设计?–实实在在落地
不知名产品露 · 2024-11-06 · via 人人都是产品经理

需求调研分析结束后,紧接着我们需要进行方案设计阶段,一般我会拆分为2大步进行,首先是整体方案设计,其次是详细方案设计,本文着重对前者整体方案设计进行探讨。

对需求已知的前提下进行0到1的系统搭建。

以M集团的项目进度管理系统为例:

  • 工程进度管理期望可做到线上化,打破信息差、提高时效性
  • 工程进展期望以类似虚实结合的图形方式展现,降低理解成本、快速一览项目进度
  • 缺少线上快速运转的工作流程管理机制,出现问题很难追溯

一、核心业务流程

通常我会从用户行为路径出发,对流程中涉及到的角色、场景等进行串联,搭建核心业务流程与分支流程,拿上方所提项目举例,与业务方调研后获得进度管理业务流程如下,为线下手工作业流程:

流程简述:

1)流程图中可发现,一份计划从创建到投入使用的审批效率较低;

2)计划投入使用后,通过打印纸质版,张贴上墙的方式进行日常进度的填报,时间久了不便于查看、且易丢失,可视化效果不佳;

3)每周例会时,才进行工程完成情况/问题的汇报,时效性较差,出现问题不能第一时间采取相应措施,影响工程进度。

与项目生产部门负责人沟通了解到,他们有专门的工具进行计划编制,但工具不能提供后续的管理工作。由于计划较复杂,业务人员也习惯使用该工具编写计划,讨论后确定计划编制依然保留原线下工具编制的方式,计划编制作为一个节点,从该节点以后进行线上化管理。将工作流程(如审批流等)纳入到系统规范化管理的一部分,在系统中支持计划增删改、进度上报、工作审批、工程可视化管控等。

流程中涉及角色:

1)项目生产部人员:参与制定施工项目的施工计划、并负责实施等

2)项目生产部总监:管控工程施工全流程工作;科学组织和管理施工现场的人、材、机等各生产要素;参与施工组织设计等多项工作

3)分公司生产部负责人:对所辖项目的施工情况进行协调管理

4)集团工程部负责人:对所辖分公司与集团项目的工程进展实施监管、制定相应业务管理办法等。

以上岗位职能非标准化,各公司职责范围可能存在差异。

确定后部分业务流程图如下:

二、产品定位

主要为了更清晰的明确产品目标,产品对业务的支持范围或总体的功能目标。为谁提供什么支持。如以上案例主要是为工程企业提供施工全过程的进度监督管理、降低项目延期风险,提高企业竟争力。

将抽象的定位落到具体实施中,我一般会从系统实现形式、系统分类、不同业务人员的功能分类几个维度进行分析。

1)根据客户日常工作场景了解到,管理者通常较多时间在办公室进行工作监管、定期到项目上进行实地检查考核等,一般会有助理类岗位人员同行;

一线业务人员,较多时间在项目施工现场,很多工作基本通过手机进行处理,在类似周会/月会等情况会在办公室进行,项目前期一般也会在办公室进行项目情况梳理;

综合以上实际情况及投入产出比分析,最终确定通过PC端和移动端小程序结合实现。

2)对一线业务人员来说,需要一个方便操作工程计划相关内容的平台,因其需要对计划进行一系列的操作,若出现风险,还需进行纠偏等动作;对管理层来说,需要为其提供一套管理后台的能力,因涉及工作规范的制定、业务内容的审核等;对前面两者来说,均需要提供一个可视化模块,快速了解工程进展,因工程可视化模型的特殊性(文件格式、解析时长等不支持移动端),不便于在移动端查看,所以会在PC端进行实现。

通过以上分析,我们进一步将系统拆分为3大模块,每个模块的定位不同:

  • 进度管控模块(PC端+移动端):为一线业务人员提供计划导入、进度填报、风险纠偏、模型上传等功能。
  • 进度设置模块(PC端):为管理层提供审核流程配置、风险规范配置等功能。
  • 形象展示模块(PC端):为一线业务人员与管理层提供工程可视化的展现功能。

在设计业务系统过程中,我碰到过很多因业务部门职责边界模糊、权限界定不清晰,导致很多功能被要求揉到一起实现,但这样对系统的长期发展并不友好,可能后续还会因为高度耦合,仅仅一个很小的功能,实现成本却极高,所以每次调研后我都会二次复盘,把业务边界确认搞清楚后再继续后面的设计,业务边界可能包括客户企业内部的部门职责范围及未来拓展方向、部门的实际工作流程、绩效考核指标等。

三、应用架构设计

一般需要与公司已有的系统架构相融合,不同系统模块之间如何衔接。因涉及技术专业性方面的内容,需要与研发负责人等共同讨论确定,此处不做展开介绍,感兴趣的小伙伴可以自行查阅。

四、功能模块设计

一般会把能想到的功能都列出来,做加法,不局限于某一个环节,将系统未来整体规划思路做罗列,如基于以上3个模块,做拓展及与其他业务系统的结合功能。

  • 进度管控模块:先有计划才能对后续工作进行管控,此处主要包括计划管理、过程管理两部分。从计划角度考虑,需具备以下功能:计划模板、增删改计划(含总年月周多分类计划)、增删改形象(模型/施工图纸)等;针对过程管理考虑,需包含以下功能:开停复工管理、进度跟踪、进度检查、风险管控、首页等
  • 进度设置模块:可分为工作规范配置、施工过程配置,针对工作规范配置包括:审核流程、风险规则;针对施工过程配置包括:形象阶段配置、各计划间计算模式、纠偏原因配置等
  • 形象展示模块:不同客户对形象展示方式可能存在不同,公司合作企业中较多出现的是BIM模型与施工图纸两种方式,故形象展示模块主要从可视化方式上支持多种形态

以上功能模块拆解我是从大模块角度出发,直接划分功能点的形式展开;此外,我也经常会从角色角度出发,不同角色一般会用哪些功能,完成哪些工作,将功能罗列好后,再进行分类整合。

五、演进蓝图设计

大的产品架构出来后,可以进行版本拆分了,根据业务需求排好优先级后,确认产品的功能规划与实现节奏,是否和其他业务系统联动,若有,我一般会单独估算这部分的排期,防止因为对方系统排期异常影响本系统。这步蓝图设计我主要用来做减法。

以上案例,一期会将核心业务流程作为首要实现的目标,如进度跟踪;二期聚焦解决特殊业务刚需的诉求,如风险把控;三期主要关注可视化方面的附加能力,如形象进度展示等,我习惯用框架图进行梳理,便于一览整个系统的结构与排期情况:

以上是我对整体产品方案设计的思路与大致案例,希望对你有所帮助,欢迎一起交流学习。

本文由 @不知名产品露 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务