数据相关项目管理的打法

简介

本材料用于记录对项目团队的预期、碰到的问题和考虑到的建议。主要为落地项目管理中的流程文档。

项目团队预期

输出确定感：包括计划的时间和各环节工作质量；

输出结果：数据分析支撑类项目能输出数据分析后建议的结果（赋能），并增加效果的评估环节（闭环）。

常见问题

需求背景、目标、功能等不够清晰，产品间相同业务的数据逻辑不一致，PRD和设计稿存在不匹配情况；

需求存在并行情况；

需求变更环节不够规范；

分工和排期未严格按流程规范执行；

技术改造等的文档落地不足；

测试范围存在不够明确的情况；

进度和项目问题反馈机制不统一；

线上bug等故障处理记录暂无处理过程；

数据验证环节；

项目主要流程

项目管理过程指南

数据产品建议

需求文档：

文档需描述准确，覆盖产品背景、功能（核心功能、原型图、限制条件、主流程等）；

明确各功能点的优先级；

明确版本迭代的目标和预期的计划；（一方面可以提升产品迭代的目标感，一方面方便开发、测试等同学了解产品的发展情况）

涉及ETL工作的注意备注数据来源、开发对接人和中文取数逻辑；

需求提前发文档再评审：

在建项目讨论组时将产品的PRD、设计稿的文档链接共享在群公告中；

文档提前1天共享，以便项目团队成员提前了解项目情况，提升评审会的效率和质量；

需求变更：

需求变更，即需求评审后有对内容的增删改，因需求调整会影响前后端和测试工作，必须做好记录；

变更内容根据项目团队理解情况，安排会议、电话等方式确认变更内容；

产品需求变更时要求与项目团队确认迭代的版本，并更新在对应版本的PRD中的变更记录一栏；

产品上线规划：

产品同学内部根据产品规划安排迭代的计划和内容，有助于提升资源利用效率；

ETL建议

需求评审：

取数逻辑：根据PRD中的数据来源、开发对接人和基本逻辑，与后端确认对接方式后，确认最终的取数逻辑和推送方式；

ETL排期：

根据取数逻辑、现有工作，按数据分类预估ETL排期；

ETL：

进度反馈：在按数据分类排期的基础上，配合项管反馈进度情况，同时应不受日常迭代工作的影响。

后端建议

需求预审

PRD提前共享后，熟悉需求内容，并检查PRD未完善或不明确的背景、功能等；

根据PRD后端可以提前考虑实现的技术方案；

需求评审

评审时确认背景和功能；

基本确认技术方案，并考虑改动范围；

如涉及底层框架、逻辑、服务接口等修改则落地到文档同步给项目团队；

后端排期：

根据PRD的工作拆分、技术方案和ETL依赖关系，按模块预估后端开发时间；

根据ETL、前后端交互情况增加联调时间；

后端开发：

进度反馈：在按模块排期的基础上，配合项管反馈进度情况；

后端协调：涉及后端间配合的项目整理好流程、环境配置、数据准备等；

前后端协调：与ETL确认好字段和类型，整理好接口文档，并与前端确认；

上线后：

故障分析记录反馈表：记录故障介绍、故障等级、故障分析、修复步骤、后续优化方案等；

产品技术优化：具有代表性的故障和方案，可以将优化方案提到版本迭代中。

前端建议

需求预审

PRD提前共享后，熟悉需求内容，并检查PRD未完善或不明确的背景、功能等；

根据PRD可以提前考虑前端实现效果的难点，供设计师参考；

需求评审

评审时确认背景和功能；

基本确认前端结构和设计建议；

设计评审

评审页面设计和交互逻辑；

确认页面实现时间；

前端排期：

根据PRD的工作拆分、设计稿和后端接口的依赖，按页面预估前端开发时间；

根据前后端交互情况增加联调时间；

前端开发：

进度反馈：在按页面排期的基础上，配合项管反馈进度情况；

前后端协调：与后端确认接口文档；

上线后：

模块化需求：根据产品需求迭代和日常维护，考虑前端页面的模块化改造，可将改造工作提到版本迭代中。

测试建议

需求预审

PRD提前共享后，熟悉需求内容，并检查PRD未完善或不明确的背景、功能等；

根据PRD可以提前考虑测试重点；

需求&设计评审

评审时确认背景、功能；

基本确认测试的范围和重难点；

测试排期

根据需求、设计、技术方案，按模块确认测试时间；

确认好提测节点、预发节点等；

用例评审

评审成员：产品、开发、测试、项管；

评审测试范围、功能点、测试重难点；

明确回归时的范围

测试工作：

进度反馈：在按模块和用例配合项管反馈进度情况；

问题反馈：统一反馈到jira页面，并及时同步；

上线后：

回归测试：上线后及时回归测试，验证无误后，完成发布单。

项目管理建议

需求评审：

PRD共享（提前+公告）：项目相关的需求内容（包含背景、目标、功能点等），不明确的内容反馈产品补充；

需求范围：推动产品明确版本的需求范围，并做好版本中功能的优先级预估；

需求评审后：推动产品除变更不改动PRD；

项目排期：

排期：

需求评审后：ETL、后端可整理技术方案并输出排期；

设计评审后：前端输出排期，如不需要设计时参与的前端工作可先按模块输出；

前后端评审后：测试根据需求、设计、技术方案等输出排期，如不涉及复杂的重构、技术改造、大版本需求等；

排期计划：在开发、测试完成工期预估后，输出计划，尽量错峰安排项目减少并行，充分发挥团队效率；

进度反馈（站会）：定期站会同步项目团队内进度，并辅助推动问题；

进度反馈（在线表格）：汇总项目进度备查；

消息响应情况：对项目团队的消息的反馈要做到及时，尽量避免长时间未回复消息；

技术评审（进阶）：推动技术评审环节，输出技术方案文档。在需求评审完成后安排，需求稿中待定内容尽量在当天确认，需求稿和设计稿除样式外应保持一致。技术文档基本结构如下：

系统整体架构（沿用架构文档中的应用架构图）及依赖说明

系统业务流程分析

业务流程1

业务流程概述

业务时序图

业务处理说明

业务流程2

业务流程概述

业务时序图

业务处理说明

新增的service及接口

数据库模型分析

产品、开发、测试等质量（进阶）：

需求&设计：需求清晰的共享，设计稿确认完成后进入开发；

开发：前后端开发完成后，要求联调并做好自测；

测试：加强用例环节的评审，按用例测试的问题统一的反馈；

数据验证（进阶）：

需求阶段推动产品明确数据要求的量度-维度（涉及的指标分类和数据）-粒度（数据的颗粒度）；

推动产品和ETL明确数据的取数逻辑、表名和结构；

联调过程中输出结果验证数据；

测试环节加强数据验证环节；

测试工作（进阶）：

测试用例质量管理；

版本完成后反馈测试报告，总结故障点。

常见问题list

延期

分工

数据验证

需求变更（例如：上线前增加口头变更）

产品预期目标

线上bug处理效率

需求信息描述、同步、解释，需求评审提前共享文档

项目建设中新增需求

底层代码改动时技术文档的落地，测试资源的安排

不同数据产品间相同内容的数据，接口输出逻辑不一致情况

需求中对细节点的理解，产品和开发逻辑不一致

需求稿与设计稿不匹配

上线前变更逻辑影响上线周期

需求并行，可以反馈增加资源

预估到的风险未充分暴露

重要迭代版本的技术文档落地

故障处理过程和分析的记录

技术评审缺失

回归测试的范围商量的不清楚

设计评审环节不充分，设计稿缺失较多内容

排期预估时间较紧，缓冲时间不足

测试问题反馈后产品也重复提出

预发时间节点不够明确

产品使用场景和目标不够清晰

产品迭代优先级不够清晰

较大项目定期同步进度的意识不足