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

推荐订阅源

OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
云风的 BLOG
云风的 BLOG
小众软件
小众软件
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 司徒正美
博客园 - 聂微东
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
美团技术团队
宝玉的分享
宝玉的分享
量子位
V
Visual Studio Blog
罗磊的独立博客
Vercel News
Vercel News
B
Blog
J
Java Code Geeks
S
SegmentFault 最新的问题
Recent Announcements
Recent Announcements
有赞技术团队
有赞技术团队
P
Proofpoint News Feed
GbyAI
GbyAI
G
Google Developers Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
B端产品经理:复杂数字化项目如何设计产品架构
边亚南 · 2022-07-13 · via 人人都是产品经理

编辑导语:在数字化转型的大环境下,越来越多的企业都在进行数字化转型。本文作者分享了在进行复杂数字化项目时设计产品架构的具体方法思路,讲述了产品架构过程中的注意点等,一起来学习一下吧,希望对你有帮助。

数字化转型背景下,越来越多的企业开启数字化转型,B端产品会接触到越来越多的从0-1搭建数字化系统的项目,这样的项目需要从0-1搭建产品架构,还需要设计模块流程,并且严重依赖业务流程和客户支持资源。

复杂数字化系统对产品架构和模块化间的逻辑处理方法要求非常高;如果模块间关系处理不清晰,到产品的后续应用环境会出现阻塞的情况,返工成本会很高。如果产品架构设计不合理,那可能会直接导致功能无法顺利实现。

那我们在做这样项目时需要注意哪些事项?有哪些参考准则呢?

一、项目初始:产品架构框架设计:三要素+三条流+精力分配值

1. 业务三元素:整体组织架构,关键角色及关键权限范围,以及关键业务要素

注意这里三元素不是指我们在系统里实现的功能,而是在客户现有的业务流程里的内容。

我们需要通过全局视角俯瞰整个项目结构时必须了解的部分;组织架构的分布情况了解清楚才可以设计权限角色架构,关键角色权限及范围帮助我们了解角色权限的颗粒度,关键业务要素让我们了解人与业务的交互关系;这些信息能让我们搭建起产品架构的第一层结构。

2. 三条流:业务流 数据流 操作流

业务流是基于数字化系统覆盖范围内的所有业务的流转流程,这个大家应该很清楚,但是在实际调研和设计的过程中特别需要注意,我们设计的系统不是将业务流程原原本本的还原出来,而是通过梳理业务流程,发现隐藏的产品架构; 产品经理要通过数字化的设计能力设计完整的产品架构。

举个例子,我们在给不同的客户设计订货业务系统时,其钱款的实际业务流程是类似的:经销商充值打款、财务审核确认、业务下单订货。

我们在设计架构时,是不是将这个业务流程直接设计出来就OK呢?明显不是,产品经理应该能捕捉到,这里有『账户体系』的结构隐藏在业务之后。

所以在设计产品架构时,我们不但要看到业务的明线,还需要捕捉到产品结构的『暗线』,保证方案的完整性。

另外还需要注意,业务流程梳理完成后转化成设计方案时,一定要结合全链条流程进行设计,否则很容易设计错误。

再拿账户体系的设计方案举个例子:业务流程相同,那是不是所有的这样的业务流程都是设计相同的账户体系内?完全不是。

我们为不同的客户设计过不同的架构体系,虽然业务流程都是一样的,但是账户体系的结构完全不同,原因就是因为后续的结算业务流程不同;所以我们做的A客户的账户体系是归属在经销商逻辑内,B客户的账户体系是归属在经销商订单内。

通过上述的流程梳理,产品的第二层架构可以细化;我们结合数据流转逻辑和关键角色的操作流程,就可以继续细化架构;

3. 关于『精力分配值』

项目调研是每个项目都要经历的一个步骤,调研的手段和方法有很多,我们会花费很多时间和精力在调研的过程中,但是我们更需要关注的是调研的目的。

我们需要通过高层访谈,业务访谈和用户访谈,获取项目关键目标, 了解关键角色以及其主要权限,获取现有的企业资源支持项目;以方便我们确认系统设计的『精力分配值』。

这里需要注意,项目的设计,并不是将客户提出的需求事无巨细的设计出来,客户需求的描述是基于他对业务的认知表达的,最后落地如何设计,是需要产品架构师进行设计的,设计的合理可以为客户有效节省成本,也就是需要提前预估好系统设计的“精力分配值”。

什么是“精力分配值”?

举个例子,我们为一个药械企业做财务数字化系统,他们做数字系统的核心诉求是3年后IPO时,系统需提供所有业务数据,且需要符合审计合规性,保证证据链的完整性。

我们通过访谈获取到核心目标,了解关键角色和关键业务,在后续设计时,就明确了哪些模块是必须要详细设计的,哪些模块可以做简化设计;这样在做项目方案时,我们结合客户的预算和目标,就可以游刃有余的提供设计方案。

二、架构细化阶段:望远镜和显微镜

经过了前期的调研,对项目的业务流程已经有了大概的了解,那我们需要对产品设计方案进行细化及逻辑合理性审查。

这个过程中,我们需要不断的从整体到局部的视角切换 审核方案的合理性。

真正到设计过程中,很多模块间的关联性非常强,如果仅关注单独模块的逻辑,则很容易造成功能不完整;所以我们需要有『望远镜』思维,不断的梳理各个模块之间的关联关系,确保任何联系的那条『线』不会缺失,保证功能完整性。

在建立模块和模块的链接后,我们需要调回到『显微镜』状态,详细梳理模块内各个业务关键点如何设计,如何和不同模块间打造通道,保证系统的完整和合理。

之前我们在设计一个客户的订货业务系统时,就使用了这种方法。

因为下单是整个系统的核心模块,中间关联着渠道价格体系,产品授权,账号,库存,审核权限,串货限制,以及信用体系和任务返利体系,在这个模块设计时,我们通过单个模块的业务流+多个模块的限制并行处理,反复的梳理模块和模块之间的逻辑,最终能够将系统完美交付。

三、模块细节设计

前期的架构设计合理,后续的模块的细化任务就简单很多,这个时候注意,方案的设计会较依赖客户的实际业务需求,所以前期的业务调研一定要做到位,如果业务逻辑梳理以及沟通有歧义,会造成方案设计方向的偏差。

还需要注意:有些设计方案设计出来后,可能会更改业务流程因为之前的业务流程,比如因为之前系统间有数据孤岛,新系统因为模块的链接和数据的打通,可能很多业务流程是可以省略的;在遇到这种情况时,大胆设计,小心验证。

尝试突破业务的限制,最大化利用数字化的优势提供价值,才是我们最终的目的。

#专栏作家#

边亚南,微信公众号:边亚南,人人都是产品经理专栏作家。华秉科技产品合伙人,IT东方会副秘书长,北京理工研究生,《数字突围》第二作者。专注实体企业数字化升级方案设计和私域流量运营体系搭建,擅长为企业提供全链路数字化升级解决方案,以及私域流量运营方案。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于 CC0 协议