研发管理-流程篇
标签: 项目管理 研发管理
情况介绍
2011年-2014年主要致力于国内某大型企业财务公司资金结算系统,系统主要业务包括对公、对私、代理资金划转交易,交易金额少则几万多则亿元,不容闪失。值得骄傲的是在我担任项目经理期间没有出现一笔问题,回想那段时间我个人压力巨大,每天琢磨系统哪儿容易出现问题,如何防范,出现问题如何补偿。带领团队完成系统监控研发上线,确保问题交易提早发现通知银行协同解决。
2015至-2018年初主要负责某e宝研发工作,主要分为两个阶段,第一阶段,2015年-2016年底主要负责APP研发,带领团队完成某宝APP v1-v3版本研发上线。2017年-2018年主要负责某宝全部系统的研发管理,包括前端APP和后端核心系统,在这期间带领兄弟们夜以继日工作,完成一项一项艰巨任务。每想到此,心中尤为感概,特别感谢曾经一起共事的兄弟们,道一声“感谢 & 珍重”。
2018年,总部新成立****事业部,让我负责研发管理工作,由于涉及到电费相关,系统出现异常容易造成企业用户损失,为降低系统风险,确保流程规范顺畅,制定一份切实可行项目研发管理,争取2019年做到系统零事故。
项目研发管理
项目管理阶段
研发项目主要从产品需求作为入口,线上验证作为结束,主要分为:
需求评审
项目设计
项目研发
项目测试
项目上线
线上验证
六个阶段分别阐述每个阶段的主要工作职责和内容。
需求评审
需求评审主要评审什么?一直以来我们对需求的评审不够严格或者仅仅是过了一遍需求,让大家都知道有这个需求需要研发上线,缺乏对业务、系统整体风险的揭示,业务评审主要考虑从业务、技术两个层面规避风险和处理风险。我要求团队对需求的评审主做到如下四点:
- 分析新上产品(需求)对现有产品是否存在冲击风险
- 分析新上产品(需求)自身的业务风险,如果出现系统风险,业务层面是否有解决办法
- 分析新上产品(需求)业务流程是否逻辑清晰,业务是否考虑后续产品扩容
- 分析新上产品的接入方(银行、内部系统、其他厂商)的产品和我们产品的融合能力和技术实现
项目设计
技术经理或研发组长在需求评审结束后开展项目设计工作,如果做好如下的三条应可以满足我们当前的研发要求,太多的要求担心时间的损耗大还未必能够达到好的效果,本着实用好用的原则做好如下三条。
-
数据库架构设计(表名,字段名命名规范、充分思考业务发展,满足业务扩展、查询多变更少的采用缓存数据库(redis+oracle)结合使用,基础字段必须包含如:操作用户编码、创建时间,可以适当的冗余字段方便管理平台的统计分析和查询工作)
-
应用架构设计(应用架构图,描述系统应用关系,描述不同系统间的职责范围(银行、财务公司、内部系统、其他外部系统)、设计测试环境和正式环境的虚拟机数量、说明相关网路权限的申请和开通)
-
安全架构设计(数据脱敏、数据加密、网络安全(专线、https、证书)、用户权限、Xss、SQL注入等基本安全防范)
重点:设计必须评审,这个是我必须要过的一道程序。
项目研发
项目研发需要经过九大步骤,主要包括:
- 分支创建
- 工作分配
- 环境申请(测试)
- 代码编写
- 代码审查
- 代码合并
- 集成测试
- 环境申请(正式)
- 测试提交
分支创建
研发经理根据项目需求、应用架构设计、《git管理办法》做出项目分支(future_branch)创建工作。
工作分配
研发经理创建好分支后,在分支下将包创建好后,将分支权限分配和具体研发人员。
环境申请(测试)
申请虚拟机、开通对外网络、内部网络、申请redis、memcached的key。
代码编写
代码编写必须做到如下规范日志输出、规范注释编写、规范命名规范(应用、包、类、方法、字段)、规范单元测试、规范异常处理、规范缓存使用、规范SQL、规范使用通用类、规范任务处理调用、关键程序逻辑处理、QAPlug代码检查。
代码审查
- 为什么代码审查在合并之前?
研发经理层面:1)审查代码实现是否符当初的设计。2)投提前了解合并可能存在冲突。
研发工程师层面:1)团队其他成员通过审查,能够理清(加强理解)队友代码实现和自己代码的逻辑关系。2)通过代码审查,了解技术实现尽早实现技术层面提升。- 代码审查的成员
代码审查包括所属项目组所有成员- 代码审查的内容
日志输出、注释使用、命名规范(应用、包、类、方法、字段)、单元测试情况、异常捕获、权限处理、事务处理、缓存使用、数据库使用、SQL编写、代码逻辑、通用类使用情况、任务处理、关键程序处理。
代码合并
代码合并的工作必须由研发经理执行,研发经理解决合并的代码问题。合并完成后使用代码检测工具(Sonar)开展代码检查工作。
集成测试
完成业务基本测试和性能测试。将研发的包放入集成测试环境(暂时正在搭建),主要测试核心逻辑、外部系统调用、内部系统调用、数据量千万级、数据量亿级处理时长,考虑业务量大的情况性能和基本功能测试。
环境申请(正式)
申请正式环境的虚拟机、开通正式的网络、可提前部署相关的硬件或者软件(如:银行前置机)。
测试提交
准备发版文档,将发版文档提交给测试,测试按照发版文档部署配置(jenkins、 git)服务。
后续将测试环境当做生产,确保提交给测试的环境配置无错误。
项目测试
用例编写
测试用例编写开始于需求评审完成后,包括覆盖基础功能、本次上线功能、环境变化调整功能。
用例评审
测试用例评审,包括必须复测的基础功能,包括本次上线功能的完整性,包括因代码、环境调整等因素需要测试和恢复测试用例。测试用例的评审包括开发(最低2人)+测试本项目组全体成员。
分配工作
测试工作的分配,通过项目计划将模块分配给相关的测试测试人员,(考虑交叉测试,希望明年能够实现,交叉测试需要人员较多,成本较高)。
系统测试
系统主要测试三轮:
- 第一轮主要是业务流程跑通测试,目前由于测试环境和研发环境较大差异(配置、数据、外部环境)所以第一次的测试以跑通为主;
- 第二轮测试主要包括业务实现逻辑及细节测试,包括日志输出、相关系统处理时间、业务数据、异常数据测试等。
- 第三轮主要是回归测试,出具测试报告,提出因测试条件缺失的风险,让业务人员签字确认风险。出具代码研发质量报告,根据代码行数和bug的比率、相似功能bug比率提出研发质量报告。
产品上线
发版准备
- 做发版计划,环境准备提前一周,发版计划提前3天。
- 准备发版的工作票,封版前完成。
- 做好发版材料的审查
发版跟踪
- 发版当天安排技术经理值班。
- 跟踪运维系统启动情况、日志输出情况(检查kibana日志查询)、系统的初步验证
线上验证
线上验证
我们的产品主要TO-B,线上的验证难度大,所以19年我们需要实现灰度+白名单客户帮助业务便于线上业务验证。
《以上是我研发管理经验分享,目前整个部门都在推行。感谢您阅读到此,希望您多多指正。》