文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载本篇基于 Lottery 分布式抽奖系统 Part-1 第02节的《需求怎么来的》文档展开对比传统企业与互联网公司在需求承接模式上的差异拆解业务方提出需求 → 运营量化指标 → 产品输出 PRD → 研发设计与开发 → 测试验收上线的完整协作链路。读完后你会清楚一个互联网需求以抽奖这类营销活动为例从战略背景到 PRD 评审的诞生过程以及研发在整个链路中处于什么位置、要承接哪些角色输入为后续进入系统架构设计与编码阶段做好铺垫。一、先看清起点两种截然不同的需求模式作者在 第02节需求怎么来的 中先以自己在传统企业工作的经历切入说明需求怎么来的这个问题在互联网和传统行业有本质区别。1. 传统企业的模式项目经理 甲方文档驱动在传统行业工作时需求都来自于带来我的项目经理。典型流程是项目经理出去与对接的甲方聊本年度的需求比如需要完成一个烟草精准打码项目聊完以后项目经理回来开始整理几千页的项目文档因为几千万的项目就需要几千页的文档项目确定以后对应的研发开始按照项目文档进行设计和开发开发完成以后到甲方现场开始实施部署一直到验收完成。这种模式下研发是按文档施工的角色文档由项目经理产出验收在甲方现场完成研发与业务方几乎不直接对话。2. 互联网的模式多角色协同驱动而在互联网从事开发工作会有更多的角色。以承接需求的视角来看涉及的角色包括业务方需求的原始提出者产品需求的方案化输出者运营数据与策略的执行者研发系统的实现者测试质量的把关者。这些角色以及各项的负责人、系统架构师、风控等部门都会按照需求的大小不同而会被拉到一起进行项目 PRD 评审并逐步到排期、研发上线。当然每家互联网公司的扁平化管理程度不同具体协作方式会略有差异但角色分工的主干基本一致。二、业务需求不是产品给你的而是战略落地的结果从研发角度你所承接的需求最开始并不是产品经理给你而是业务方根据市场战略提出需求。理解这一点非常关键这些需求的背后是依赖于某些战略落地的背景需求要完成目标结果这个目标可能是拉新、促活、留存等等最终要在预期投入下完成价值产出。对照文档中的思维导图见文首图片业务这一分支下具体包含四个要素背景信息、目标结果、预期投入、价值收益。也就是说业务方提需求时给出的不是一句做个抽奖而是一套完整的商业论证为什么做背景信息、做到什么程度算成功目标结果、打算花多少资源预期投入、投入产出比如何价值收益。在 Lottery 项目中抽奖系统正是营销体系下承接拉新、促活、留存这类目标的典型微服务之一。从 Lottery 抽奖系统项目介绍 可以看到营销是一个非常庞大的系统体系包括营销平台、返利平台、积分账户、抽奖系统、券系统、灌券系统、售卖系统以及各类玩法的组件系统抽奖只是其中的一个重要微服务。理解了抽奖在营销体系中的位置就理解了它的业务需求为什么会长这个样子。三、产品业务定需求产品做方案业务定需求、产品做方案。产品经理的职责是梳理方案执行落地的过程协调各方部门配合完成项目开发。所以在 UI、前后端研发视角下各处都有产品经理的身影。产品的核心产出与动作包括整理输出 PRD 文档把各方可配合的信息协调好后产品经理开始整理输出 PRDProduct Requirements Document产品需求文档组织 PRD 评审整理完成后拉对应项目需要的人员组会一起评审 PRD多轮评审直至通过有些时候第一次 PRD 评审会遇到不少问题如果不通过或者有问题则需要 2、3 次评审交棒给研发评审完成后需求正式交棒给研发。从思维导图的产品分支可以看到产品侧的完整工作还包括实现方案业务流程、功能细化、职责拆分、干系人员、各项文档、数据埋点及其维度与口径和项目排期。其中数据埋点往往容易被研发忽视但它决定了运营后续能否量化活动效果是 PRD 评审时值得重点核对的内容。运营连接业务目标与技术实现的量化层文档的思维导图将运营单独列为一支包含三类工作内容运营分支具体内容量化模型A/B TEST、人群数据指标CMV、获客数、留存率、转化率运营策略内容、活动、用户、产品这一层的意义在于业务方给出的是战略方向如提升留存运营将其转译为一套可度量的指标体系获客数、留存率、转化率等和可执行的活动策略抽奖活动正是活动策略的载体之一再由产品落成 PRD。对研发来说这些指标直接决定了系统需要支持哪些能力——例如按人群标签差异化投放活动、对抽奖次数做频次控制、对活动效果做数据回传等这些诉求最终都会体现在 Lottery 系统的规则引擎、活动配置、人群过滤等模块设计中。四、研发PRD 通过之后做什么PRD 评审通过只是起点。在 第03节系统架构设计 中明确强调当产品的 PRD 评审完成后就能立刻进入编码吗绝对不可能。拿到需求以后需要做的是视需求大小进行不同层级的系统设计这个过程包括拆解出属于此项目的各项人员职责职责总表决定采用什么架构来承接负载、网关、结构、治理、框架、服务、数据等各层选型各功能模块如何细化设计涉及到的库表要如何设计分支计划是什么样、列出工程导图准备一个执行进度的汇总表统计开发到上线阶段的各项进度把控风险直至发出上线报告推进项目上线交付。对照思维导图的研发分支可以进一步把研发体系的工作拆解为前端与后端两条线前端UI、APP、APP 前端页面的开发后端开发体系的主要工作架构设计 → 模块拆分 → 细节设计 → 设计评审 → 确定排期 → 功能开发 → 系统联调 → 提交测试 → 部署上线 → 运维监控。其中设计评审是研发侧的又一次评审关卡与产品的 PRD 评审呼应PRD 评审解决做什么设计评审解决怎么做。Lottery 项目在 第04节进入开发阶段 中展示了设计评审完成后的系统搭建实践按系统复杂度选择架构形态单体、分布式、分库分表、分层大型系统会把职责拆分为基础层、业务层、网关层、任务层、异步层等独立系统开发数据服务上以 MySQL 为主数据量大时采用分库分表并基于 binlog 用 otter 将数据同步到 ES 便于汇总查询。五、测试质量闭环与上线交付思维导图的测试分支包含四类测试测试用例、冒烟测试、流程测试、回归测试。完整链路是研发在系统联调完成后提交测试测试侧按用例执行冒烟基本流程可走通、流程核心业务链路、回归新改动不破坏老功能等测试通过后测试人员发出系统测试通过通知研发侧配合进入上线阶段。上线阶段的协作同样涉及多方如 第05节系统上线维护 所述测试人员发出系统测试通过后研发在测试邮件上发送系统上线通知所有相关人员各做各的工作——配合的研发提前发布接口、前端等待后端接口上线、运营配置好活动等待新系统上线、业务人员做好计划。部署时需注意日志打印信息、RPC 接口挂载情况、外部调用链接情况、指定 IP 调用的返回情况等验证点验证完毕后按 20%、30% 这样的比例灰度放量发布。六、回到 Lottery 项目一条需求链的完整映射把本文的内容串回 Lottery 抽奖系统的 Part-1 章节脉络恰好就是一条真实互联网需求的完整生命周期阶段对应文档关键动作需求来源第02节需求怎么来的业务方按战略提需求运营量化指标产品输出 PRD 并多轮评审架构设计第03节系统架构设计职责总表、架构选型负载/网关/结构/治理/框架/服务/数据开发阶段第04节进入开发阶段系统搭建分层、数据服务MySQL/分库分表/ES 同步上线维护第05节系统上线维护上线通知、环境准备、灰度部署、验证要点对读者来说掌握这条链路的价值在于当你拿到一个类似抽奖的营销需求时能清楚知道上游业务、运营、产品会给你什么输入背景、目标、指标、PRD、排期你作为研发需要向上游确认哪些模糊点埋点口径、人群规则、频次限制以及向下游测试、运维交付什么设计文档、测试就绪版本、上线报告。这正是 Lottery 项目介绍 中提到的互联网大厂的代码开发规范、需求评审、运维监控的实践背景——抽奖系统后续的 DDD 四层架构、规则引擎、滑动库存等设计都是从这条需求链中沉淀下来的工程能力。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐探索未来抽奖体验lottery-3d 3D球体抽奖系统探索未来抽奖体验lottery 3d 3D球体抽奖系统 lottery 3d是一款基于现代Web技术构建的3D球体抽奖系统专为各类活动场景设计。该项目采用纯CodeGuide 研发流程指南互联网项目从需求确认、研发提测到上线复盘的完整链路CodeGuide 研发流程指南互联网项目从需求确认、研发提测到上线复盘的完整链路 本文以 CodeGuide 仓库中 《谁说明天上线这货压根不知道开发流程文档教程后端刚提测就改需求代码成了屎山从需求变更看研发与产品的协作治理刚提测就改需求代码成了屎山从需求变更看研发与产品的协作治理 本文以仓库内文档 《刚提测就改需求我是渣男吗》 https://link.gitcode.c文档教程后端上一篇3个月社区管理实战总结如何打造活跃的Obsidian生态下一篇如何专业优化游戏性能DLSSTweaks高级配置工具完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考