标准的开发上线流程和重要窗口

一个标准的开发上线流程&重要窗口&支撑工具

Posted by 飞云 on June 27, 2021

工作已经很多年了, 总结了一下标准的产品开发流程, 供大家参考理解. 2021.6.27 by Felix

  • 一切的前提: 要有独立思想, 要充分理解公司战略和目标, 熟悉业务, 贴近业务, 密切合作
  • 前言: 不要相信需求方, 不要相信运营, 不要相信产品, 不要相信技术, 不要相信设计师, 不要相信运维 哈哈哈
  • 背景音: 我是为了写周报, 我不了解公司业务, 我只是为了自己省事, 我这个太复杂, 我什么也没操作, 在我机器上运行的好好的
阶段 步骤 参与 内容 备注  
产品方案 需求收集/讨论 产品+(技术) 重要功能, 流程相关最好参与, 避免提出无法实现的方案 明白要做什么, 为什么这么做, 收益等, 要勇敢质疑 业务参与窗口
产品方案 方案评审 产品+技术 参与评审, 了解, 并参与讨论, 提出自己的意见 方案决定性时刻 公司重要节点!
产品方案 产品需求+方案培训 产品+技术+测试 充分了解需求和方案, 并考虑整个流程 流程(上下游) 是最容易出问题的, 方案不一定考虑到  
排期阶段 评估/优先级 产品 + 技术 + 需求 给出初步的工期估计, 指出风险(如果有) 考虑工期是否依赖其他部门, 及其风险  
开发阶段 技术架构设计 技术 设计: 算法, 数据库, 命名空间, 流程, 外部接口等 编写文档, 设计后必须提交负责人审核 技术人员成长窗口
开发阶段 技术评审/审核 技术+技术委员会 评审, 提问, 修改方案 视项目重要性/复杂度采取不同的流程 团队重要阶段!
开发阶段 技术开发 技术 在独立分支上进行开发    
开发阶段 自测 开发人员 自己测试: 例如功能测试, 兼容性测试, 上下游数据流动, 安全性测试等 提现用心/责任 冒烟测试
开发阶段 提测 技术 + 测试 通过冒烟测试后, 提交给测试人员, 并填写提测单 未经测试不能提交  
开发阶段 测试 测试 + 内测参与 参照需求方案/设计方案, 按照TestCase进行测试 使用bug管理系统 测试人员
上线阶段 上线准备 技术 + 产品 +运营 准备各种发布文档, 相关脚本/SQL/数据, 回滚方案等 重大上线必须有回滚预案, 灰度发布方式等 上线关键点
上线阶段 上线准备 产品 + 运营 准备上线数据和素材, 安排好功能培训, 准备迎接流量和新的用户 和运营打配合  
上线阶段 灰度发布 & 测试 运维 + 测试 + 运营 预发布, 并在真实数据情况下测试 灰度最好  
上线阶段 正式上线 运维 + 测试 + 运营 上线回归测试, 提交Release文档, 通知各部门 及时通知  
运营跟进 观测 技术 + 产品 + 运营 观察线上数据, 日志, 使用方是否正常, 及时发现修复问题   发现问题窗口
持续跟进 Review 项目和数据 技术 + 产品 + 运营 对项目的技术设计, 产品方案, 运营效果, 实际数据等进行回顾 提交Review报告, 改进计划等 总结窗口阶段
回顾 回顾和奖惩 技术 + 产品 + 运营 主要从业务数据, 技术架构上进行回顾, 激发士气 激发团队 团队激励窗口

下面我们看看这些窗口:

窗口 节点 说明  
需求收集/讨论 业务参与窗口 业务是否落地, 是否小步快跑, 是否脚踏实地, 是否可行, 均在此阶段决定. 万万不可好高骛远, 追求高大上而造一个空中楼阁, 或者上线后无法投入生产, 空悲切, 误了技术白头. 所以此时技术同学一定要参与进去, 我们也是公司重要一员  
方案评审 公司重要节点 一个产品方案的评审是公司至关重要的阶段, 需求方/运营方/产品/技术各方博弈, 目标都是为了公司的战略服务, 而不能是为了自己省事, 或者偷懒不参与. 大家参与,激烈讨论, 正向引导, 同时考虑小步快跑才能真正落地, 发挥价值  
技术架构设计 技术人员成长窗口 架构设计决定了技术团队的后续发展, 是否可复用, 是否具有扩展性, 是否清晰容易理解, 是否合理, 是否高效. 架构设计的工作是重中之重, 认真仔细, 成长的机会!  
技术评审/审核 团队重要阶段! 一个人的思路难免偏颇, 三个臭皮匠, 总会有火花. 认真对待挑战, 讲解自己的思路, 让大家的认识一致, 走在同一条大路上最重要. 不能纯为了技术而设计, 不要盲目追求新技术!  
上线准备 上线关键点 灰度发布, 回滚预案是必须的. 监控+报警必不可少! 异常不能视而不见, 处理异常是日常任务  
上线后观测 发现问题窗口 问题总是在你不想发生的时候发生, 监控和报警平台时刻在心! 多节点运行+自动切换必不可少  
Review项目和数据 总结窗口阶段 总结对人和团队而言都是必须的, 项目刚刚结束, 此时是最容易发现问题的时候, 不要让问题留存, 快马加鞭, 修复问题/重构有问题的代码, 否则我们就会留下技术债务, 一瓶瓶陈年败醋!  
回顾和奖惩 团队激励窗口 奖励, 用实际数据来激发团队是最切实的奖励, 用户数/销售业绩/复购率…等等, 都提现了我们工作的重要性, 提现了公司整体的协作成果, 继续向前!  

顺便提一下在不同阶段我们需要哪些工具来支撑我们的工作:

  • 需求: 文档平台, 例如Wiki, Confluence, 语雀等等
  • 排期: 文档平台
  • 测试: Testcase工具, 例如XMind, Excel, 禅道
  • 技术设计: 文档平台, 接口平台(例如yapi)
  • UI设计: 设计平台, 例如蓝湖
  • 项目管理: 太多了, 例如禅道, Jira, Trello
  • Bug管理: bug管理, 例如禅道
  • 上线: 部署工具, 例如Jenkins
  • 异常监控: 日志, 服务器, 流量, DDOS. 相关例如Zabbix
  • 报警: 短信, 钉钉, 企业微信等等

2021.6.27 by Felix 用Markdown写这篇文章用表格好麻烦…

Page PV: