个人技术分享

项目管理流程梳理

11/6/2021 项目管理

# 项目管理流程梳理

# 项目流程图

  • 流程图

# 项目类别及发布规范

1、紧急需求，并且紧急发布（swan上拉紧急发布，流程通过TL审批） 2、日常/紧急需求，通过发布窗口发布（发布窗口一般于每周二/四建立） 3、常规项目，通过发布窗口发布（发布窗口一般于每周二/四建立）

# 需求发起

1、需求提交方：PD 2、文档：prd+交互（或交互上附prd内容，需PD最终校验通过） 3、需求发起至PM，并需要包含以下几项

1 名称
2 背景及目的
3 目标
4 优先级 P0/P1/P2
P0紧急且重要（紧急需求需注明）
P1紧急但不重要/重要但不紧急
P2既不重要也不紧急
5 期望交付时间 理论上为1个月

# 需求确认及产品确认

image.png

  • PD从需求池中认领需求，并规划版本。
  • 在此阶段中（可于prd及交互稿分别完成后，也可两份文档一起完成后），PD或PM发起需求讨论会，与相关人业务TL进行多次需求沟通，直至该版本中需求点沟通无误，多方理解一致，并且将文档修改完成。
  • tapd上建立迭代
  • 语雀建立迭代，上传文档
  • （若此前PM未参与）则于以上步骤完成后，正式向PM发起需求
  • 需求评审会
  • 立项
  • 系分评审会、设计稿评审会
  • 排期
  • 测试用例评审会
  • 冒烟测试review会

# 立项及项目排期

# 立项标准

立项意味着PRD一致通过，需求点最终确认，原则上不再进行影响项目进度及范围的变更

# 包含信息

1）项目背景及目的
2）需求点及文档连接
3）预期风险
4）资源
5）下一步动作（技术文档输出时间、视觉稿输出时间）
6）预计项目排期产出时间点

# 立项邮件由PM发送至项目干系人

# 项目排期

1）产出时间：一般于系分评审后，根据设计、研发、测试估时确定项目排期规划 2）同步方式：①项目组群同步；②输出邮件

# 技术系分评审、WBS、项目计划

# 文档管理

1）技术系分文档：前、后端开发参照语雀中模板进行填写，并在系分会议时，进行沟通； 2）其中标红为必填项，其余字段应充分思考，并将存在的可能性填写下来，如一个项目在经过充分思考后，确实不包含部分相关内容，责任人可填写“无” 3）语雀文档格式说明： ①放置在【进行中项目/迭代】中 ②一个项目中所包含的所有文档，放在该业务线下； ③文档title说明文档内容及负责人

# 技术系分评审

该里程碑需明确以下几点：

  • 1）确定项目owner：项目负责人
  • 2）接口文档
  • 3）WBS，每位开发对应的功能点及估时
  • 4）会后，由PM输出项目排期计划，以项目组群/邮件形式进行同步

# 接口文档：接口，及关联系统的说明

  • 1）列明所有接口，及接口负责人
  • 2）接口关联方，例如开发小明，需要A提供给他接口，同时小明又需要给到B 接口，A→小明→B

# WBS/story分解

1）责任人：项目负责人 2）以最小功能点为单位 3）每个功能点的工时，必要时，请注明接口依赖方及时间截点 4）根据项目大小，选择性采取白板跟踪功能点进度

# 项目计划（排期）

  • 根据设计、研发、测试估时，产出项目排期计划，并于会后以项目组群/邮件形式同步

# UI评审

# 视觉评审

  • 全部视觉稿完成后，进行视觉稿评审，参会人员：全员
  • 该环节原则上不可产生影响项目范围及进度的变更

# 测试用例评审

# 输出规范：

  • 1）时间：开发阶段1/2及以前
  • 2）文档：①全量测试用例；②冒烟测试用例
  • 3）全量测试用例：①用于评审会；②测试同学自用
  • 冒烟测试用例：研发提审前自测，需根据功能模块指给相应的开发

# 测试及发布

# 开发自测及提测

  • 1）开发依冒烟测试用例进行，当发现测试用例文档不完善时，做好沟通并同步项目组成员；
  • 2）自测通过后，进行冒烟测试review评审
  • 3）自测、冒烟测试review通过后，项目owner正式发出提测申请邮件

# 冒烟测试

  • 1）冒烟测试review前完成分配的冒烟测试用例
  • 2）冒烟测试review前准备好冒烟时需要用到的数据账号等信息

# 测试过程

  • 1）bug记录至tapd，开发在bug修复完成后，更新bug状态，并据实填写相应字段
  • 2）测试验证完成，关闭bug
  • 3）bug定级

# 1级bug - 致命错误（或阻断流程类）：

  • 1、常规操作过程中系统崩溃、死机、死循环
  • 2、涉及金钱，如支付类软件，金钱计算错误
  • 3、主要功能缺失导致测试严重阻塞（大于1h）
  • 4、流程错误，包括提测后编译失败，sql或配置缺失
  • 5、业务实现设计错误
  • 6、业务方需求理解错误（这种问题提给产品）

# 2级bug - 严重错误（或阻碍流程类）：

  • 1、次要功能或分支链路缺失
  • 2、主链路错误导致测试较短时间阻塞(小于1h)
  • 2、次要功能错误但波及面广，影响到其他重要功能正常实现
  • 3、非常规操作导致的程序崩溃、死机、死循环
  • 4、外观难以接受的严重缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）
  • 5、密码明文显示
  • 6、冒烟用例执行失败
  • 7、逻辑错误

# 3级bug - 一般错误：

  • 不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷
    • 1、次要功能错误但不影响链路
    • 2、查询错误、数据错误显示
    • 3、简单的输入限制未放在前端进行控制
    • 4、删除操作未给出提示
    • 5、不符合产品文档的实现
    • 6、一级页面文案错误

# 4级bug - 优化建议不影响发布：

  • 1、界面显示上不美观，不符合用户习惯的实现方式，但原型未给出
  • 2、辅助说明描述不清楚，但产品文档未给出规范文案
  • 3、提示窗口文字未采用行业术语
  • 4、非一级页面存在文字错误
  • 5、对需求与体验方面的改进意见

# 验收

PD、UI、需求方、PM

# 发布

  • 1）提前24小时通知PM
  • 2）参照系分评审时的各环境（测试环境、预发环境）时间规划，尽早完成每个阶段的工作
  • 3）发布时间：每周二/周四，晚22点
  • 4）紧急发布
  • 规定发布时间以外的所有发布，需执行紧急发布流程；
    • 现阶段，通过邮件进行申请（说明发布原因、发布系统）
    • 发送邮件给业务开发负责人，抄送PM，审批通过后，由PM建立紧急发布窗口

# 线上验证

  • 项目人员一起验证

# 测试报告

1）项目结束后，由测试工程师输出测试报告； 2）测试报告包含的基本内容 3）的bug等级，输出bug列表② 相关bug等级说明 ③ 其他异常情况说明等

# 复盘

  • 1）复盘类型流程复盘故障复盘
  • 2）人员：项目组成员Team Leader
  • 3）确定可行的action，根据实际情况确定action在项目组实施，或在研发中心实施

# 流程注意事项

# 基本信息

# 项目群基本信息

  • 1）群名为本次需求的项目名称
  • 2）群内成员：PD、PM、UI交互、项目组前、后端成员、测试以及TL
  • 3）群公告内容：此次需求的prd链接、项目进度、视觉稿链接以及测试用例链接

# 需求变更规范

# 需求变更发起者

  • 1）需求方、PD、UI交互：根据对需求对实际诉求而产生的变更
  • 2）开发：根据技术方案的实现可能性而产生的变更
  • 3）测试；根据用户体验而产生的变更

# 需求变更类型

  • 1）需求修改/删减
  • 2）需求新增
  • 3）因技术方案的实现性评估而造成需求变更

# 需求变更流程

  • 1）需求评审/视觉稿评审后项目全员以prd/视觉稿为准
  • 2）若有变更需求（需求方、PD、UI、开发、测试），都提至PD,由PD发起变更需求，评估确定可行性以及在不影响项目范围前提下，及时更新prd以及修订记录并群同步
  • 3）项目全员均以prd/视觉稿为准，不接受口头变更
  • 4）涉及到设计方案变更，则开发需在系分文档的变更记录表中同步更新

# 提测邮件规范

  • 1）提测模版可参照PM提供的提测excel模版
  • 2）提测邮件中需要包含提测地址以及提测相关的app/小程序

# 测试期部署事项

  • 转测后部署时间，在完成测试环境搭建前：
    • 1）转测后，部署时间为：中午和傍晚的吃饭时间
    • 2）阻碍测试流程的bug，群内告知测试并允许后再进行部署