之前公司我除了带架构和业务研发团队,PMO也在我这边管理,对于200多人的研发团队,下面介绍下整个研发管理流程,瀑布式开发模式,虽然比较慢,不过很稳,适合传统企业。

项目研发管理流程_研发流程


1、立项阶段


发起人提出需求(公司领导/客户等)、产品自身需求,产品部收到发起人通知或自身规划需求后,做相应竞品分析、市场分析等评估工作,经过评估后,如需要以项目的形式继续往下实施,则安排填写《项目立项申请表》,并走流程进行确认,项目发起人一般是公司领导或来自客户。


2、需求阶段


MRD

项目立项后,产品部进入需求收集、分析、筛选、整理等工作,产品部输出需求范围或其它产品规划文档,需求范围需同项目干系人进行讨论、确定,并最终由sponsor确认,需求范围需体现是否会涉及到第三方或公司内部其他部门(如财务、运营、客服等)的业务,需求范围得到明确后,将进入后续的产品设计阶段。


PRD

根据需求范围,原型设计编写产品需求文档及其它附属文档等,产品需求文档产生后,召集相关部门对产品需求进行评审,产品需求文档内容需包含(但不限于)如下部分:

★ 功能需求是否覆盖

★ 性能需求是否覆盖

★ 数据需求是否覆盖

★ 监控需求是否覆盖

★ 适配范围需求

★ 新老平台/系统的兼容性要求

★ 周边系统的影响评估

★ 安全需求

★ 系统容量/并发需求


原型设计

根据需求范围,对产品进行设计,并输出产品原型,产品原型设计产生后,须召集相关部门进行评审,可与产品需求文档PRD一起进行评审,评审过程需形成会议纪要,评审通过后,将正式原型归档。


3、规划阶段


在项目正式启动前,项目经理需要做一些项目前期规划工作,规划的内容和范围主要包含:

Ø资源评估及规划

Ø项目风险评估和管理计划

Ø项目估时及时间计划表

Ø项目Check List生成


资源评估及规划

项目经理组织对项目的资源进行评估和规划,项目资源主要包含内容如下:

★ 开发资源/工具规划确认

★ 测试资源/工具规划确认

★ 生产环境资源规划确认


项目风险评估及管理计划

项目经理组织项目组成员对项目的风险进行识别和评估,项目风险主要包含技术风险、资源风险、沟通风险、环境风险等,引导项目组采用头脑风暴等方式,对风险进行识别,并对其严重程度及影响面进行评估,以综合评估风险指数,针对识别出来的风险,需要给出相应的预防措施,以防变成问题,将风险降到最低点,最终生成风险评估及管理计划,由项目经理实时跟进,并定期更新和维护风险管理计划表。


项目估时及时间计划表

项目经理召集相关研发经理、团队成员进行计划估时及制定,研发人员需要配合项目经理进行任务的分解和评估,同时对开发时间进行评估(估算的时间要尽量确保合理),评估的时间粒度原则上能让项目经理可有效的进行任务跟踪,具体的粒度由项目经理根据项目实际情况进行把握(按照国内的项目管理惯例,一般情况下,最小粒度希望能细到1天,最长不能超过3天。)项目计划所包含的维度需包含(但不限于):

★ MRD

★ PRD

★ 研发设计

★ 编码

★ 自测

★ 联调

★ 测试

★ 验收

★ 上线

★ 结项

项目经理根据开发、测试等部门评估的计划,整理出整个项目计划,作为项目正式启动的重要输入之一。


项目正式启动

项目规划阶段工作就绪后,项目经理发起会议并召集项目组所有人员进行正式启动会议,会议主要明确内容如下:

① 项目计划同步和确定

② 资源及人员职责的明确和确定

③ 当前风险评估及管理表的宣讲

④ 对项目目标的同步和明确

会议结束后,项目经理将以上4项明确后的结论做最终整理,并将其相关文档提交到SVN上进行统一管理。


4、设计阶段


技术调研

针对产品规划过程中所提出的技术风险、难题进行前期技术调研,技术调研要有一定的深度,评测结果要真实可信,其他来源的数据仅能作为参考,要以自己的测试结果为主,调研工作结束后,需编写《技术调研报告》,报告中要给出调研技术的分析和建议结论,调研过程中涉及到相关的代码和demo,需要在《技术调研报告》中体现,并说明具体放置的路径,研报告输出后,安排项目组相关人员对调研结果进行评审。


技术方案设计

开发人员根据产品需求文档进行系统模块的划分和分解,分模块进行系统分析,各个模块的系统分析完成后,需要编写《详细设计文档》、《数据库设计文档》等,各子系统间的交互需要编写《系统内部接口文档》,如本系统与其他系统有交互,需要编写《系统接口文档》,针对《详细设计文档》、《系统接口文档》及《数据库设计文档》需召集项目经理、产品经理、开发人员、测试人员等进行评审,详细设计文档包含(但不限于)以下内容:

★ 系统架构

★ 系统各模块分解及功能说明

★ 各系统之间的关系及如何调用

★ 其他部门的合作对接方案

★ 数据平滑迁移方案设计

★ 安全方案等

详细设计文档需以部门或系统为单位,整合成一份文档输出,避免一个项目N份设计文档。


测试用例设计及评审

测试人员根据产品需求文档、详细设计文档进行测试用例的编写和分解, 测试用例编写完成后,需要组织相关人员进行评审,并输出评审报告,测试用例的设计在实际项目操作过程中,可能也会在产品设计阶段确认之后就开始。


UI设计及评审

UI设计师根据产品原型、产品需求文档对UI进行设计,UI设计稿,需同业务方、产品、开发等相关干系人进行评审,原则上产品经理对设计稿上功能、流程是否满足进行负责,设计师对设计稿上的外观、审美进行负责,评审通过后,进行定稿并正式提交。


5、研发阶段


编码 

代码格式须遵照《Java代码编写规范》等规范书写,代码需确保编译通过,并每天入库一次,代码入库前必须完成Code Review,在代码编写阶段,需要严格按照项目计划执行,并确保代码质量。


单元测试

在代码实现过程中,需保证在一个迭代周期内完成单元测试(迭代周期视项目具体情况而定),在一个迭代周期结束前,入库的代码需包含相应的单元测试代码,单元测试代码入库前原则上也必须进行Code Reviewer,单元测试的最终结果是保证迭代周期内的代码测试通过,以确保入库代码的质量。


联调

在编码及单元测试完成后,项目进入联调阶段工作,联调工作主要包含:

★ 子系统间接口、功能联调

★ 本系统与其它系统间的接口、功能联调

联调需确保各子系统间或相互调用的系统之间接口调通,正常流程的功能实现正常,为后续测试奠定良好的基础。


提测

联调通过后,开发人员将代码提交到指定的服务器地址,开发人员需填写《xxx项目提测申请单》, 邮件提交给测试相关人员,版本提交申请单需包含以下内容:

★ 项目名及版本号

★ 联调结果

★ 代码的具体地址(包含SVN地址及SVN版本号)

★ 新增/修改的功能/bugs 清单及功能自测结果


6、测试阶段


冒烟测试

测试部接收到版本后,安排进行冒烟测试,冒烟测试在测试环境上进行,冒烟测试过程中,如果发现重大问题,致使测试无法进行下去的,需要及时将问题highlight给项目经理及开发部,开发部需第一时间安排优先处理问题,直到冒烟测试通过。


系统测试

测试负责人对任务进行分解到每位测试人员,并确保每条用例到具体负责人,测试人员收到测试版本及测试任务后,进行测试工作,测试人员的工作需按照项目计划进行,如出现与项目计划不符的,需及时提出,并与测试负责人及项目经理进行沟通,测试过程中发现的bug提交及具体操作,请按照JIRA系统操作流程执行,测试过程中,如果碰到严重问题而造成正常测试无法进行的,需第一时间highlight出来给开发和项目经理,开发接到问题后需第一时间安排分析解决。测试负责人需要每天反馈测试进展情况,并输出项目测试日报。


测试报告评审

项目经理收到测试部发出的系统测试总结报告后,结合实际情况,发起测试报告评审的会议,会议评审内容主要包含测试报告的内容及JIRA中的bug list。

测试报告评审的原则:

★ 针对N/A的部分需要说明具体原因,并确认当前是否确实无法测试;

★ Fail项是否都已提交到JIRA系统中进行管理。

Bug List评审原则:

★ 需要对每个bug的最新状态作确认;

★ 逐一讨论bug,对每个bug需要分析其严重程度、解决的优先级;

★ 每个bug需要明确具体的负责人和解决时间点;

★ 对一些bug暂时不需要解决的(如需求不明确或严重程度低的),可做“挂起”处理。但事后需要特别对“挂起”问题,重新进行分析、讨论,作为后期完善、优化的一部分内容;

★ 针对“争议”类的bug需要项目组做特别讨论,并给出处理的结论。

根据评审完的报告和bug list,需要进一步明确下阶段版本更新、系统测试的时间点以及测试范围,根据评审的结果,项目组确定版本是否可达到上线标准。


开发debug

开发人员需要主动查看分配给自己的Bug,并及时更新Bug状态,开发在解决完bug后,要及时更新bug状态,并对已解决bug注释原因及解决方案,针对Bug修改的代码提交时,原则上不允许以下情况:

★ 一次提交代码中包含多个Bug修改;

★ 一次提交代码中即包含Bug修改,又包含其他功能的开发代码。


7、验收阶段


产品验收

当测试通过后,在提交上线申请前,产品经理需对产品进行验收工作,验收工作结束后,需输出验收报告,并在验收报告中给出是否通过等结论,将产品验收报告同步给项目组相关干系人。


8、上线阶段


上线准备会

项目经理召集开发、产品、测试、运维等相关部门进行上线前准备会议,会议内容主要包含(但不限于)以下内容:

★上线前的上线方案是否准备完备

★上线的具体时间确定

★上线的相关事项准备

★上线check list核对

★上线人员确定

★风险评估等


上线部署申请

指定的研发负责人在工单系统上发布上线申请;审批通过后方可进行项目上线工作。


部署上线

上线申请单审批通过后,进行上线工作,上线结束后,运维人员需要验证系统是否能正常运行,确保上线成功,上线结束后,上线人员需要将上线结果通知相关人员。


线上验证

测试部门需要提前准备验证测试的测试方案和测试用例,测试部门收到上线成功通知后,启动线上验证,线上验证过程中如果发现问题,需要及时将问题通知给项目经理、开发人员及运维人员等,项目经理得到通知后需第一时间召集项目组相关人员进行讨论,以确定后面工作的安排,线上验证通过后,测试部门需输出线上验证是否通过的邮件,周知项目组相关人员。


9、收尾阶段


结项

当上线成功及系统稳定后,项目经理须安排项目组所有成员进行项目总结会,项目总结会,每个项目组成员都须参与并积极发言,会议主要内容包含三大部分:

★ 从项目中得到哪些收获

★ 项目运行过程中碰到问题及改进意见

★ 对后期项目期望是什么

项目经理需要对会议内容进行总结,作为项目的组织过程资产,以作为后续项目的借鉴和经验教训,针对暴露问题的措施或解决方案,将其落实并完善项目管理体系,并更新项目管理流程及相应的模板,以PDCA闭合管理,需检查项目在运行过程中所有过程文档及产出物是否已正式入库。


需要资料的同学关注我公号,联系作者。

项目研发管理流程_项目管理_02