项目流程规范

1 项目基本流程

项目流程如图所示。主要阶段有：需求调研 -> 需求评审 -> 技术评审 -> 用例评审 -> 研发提测 -> 功能测试 -> 集成测试 -> 上线交付。

1.3 技术设计&评审

开发人员一定要重视技术设计！

开发人员一定要重视技术设计！

开发人员一定要重视技术设计！

• 主要目的：设计详细技术方案并进行宣讲，保证项目内部成员对系统实现有充分了解
• 过程内容：

• • 技术设计：研发人员在需求评审结束后，针对需求点设计总体技术方案。完成后由研发负责人（或后端主程）发起技术评审
  • 技术评审主要评审什么？

• • • 系统关系图、模块关系图、流程图的设计，画图工具根据自己爱好即可。
    • 接口设计，需要考虑接口的兼容性、扩展性、参数命名等。
    • 数据库设计，关系型数据库，以最少设计为原则，记录数据表变更文档。
    • 存储介质，除关系型数据库外使用到的存储介质，定义其使用范围、存储时长、存储协议等
    • 详细设计，类/方法级别，需要考虑公共类、公共方法、方法定义等，同时定义上下游交互方式
    • 改动影响面，对已有的哪些模块产生影响，测试是否需要回归
    • 排期和分工
    • 风险点，是否有技术上不明朗或者实现上有风险的部分？是否有不确定的第三方依赖？

• • 完成评审后如无重要卡点（如需求不明确）则进入开发阶段，并当场确认测试用例评审时间。

• 注意点：

• • 评审过程中提到的问题（需求不明确，实现不明确）当场整理到 TODOLIST，会后发出并及时确认，更新到 PRD/技术文档
  • 实现方案需分模块给出所需开发时间（人天）、负责人员、风险点和测试注意点
  • 重要的前端相关功能或调整，前端研发也需要准备材料并宣讲。

• 阶段产出：技术方案终稿

2 需求变更流程

需求变更流程如图所示。主要阶段有：发起变更并评估 -> （调整工期）-> 研测继续开发

在版本进入开发和测试阶段时，通常可能因为不同的原因引入一些对原需求的变更。如：

1. 研发人员在开发过程中发现的用户场景，PRD 中未覆盖；
2. 测试人员在测试过程中发现的用户场景，或用户体验交互需改进的部分，PRD 中未覆盖；
3. 产品人员因各种原因需要增加的需求内容

不管是以上的哪一种原因，均按需求变更流程处理：

1. 对应的同学都应立刻在研测群中提出变更，统一到产品；
2. 产品尽快判断是否需求点是否必须进入该版本；过程中和研发和测试负责人商量沟通
3. 研发和测试负责人：对需求本身变更进行快速评估，改动是否对现有工期产生影响，若有影响则给出新的工期，经产品确认后调整交付时间
4. 产品将变更内容同步到 PRD

3 注意事项

1. 各项目现有情况下不设 PM（项目经理），需要产品负责人严格控制项目进度，事实上承担 PM 的角色；
2. 项目过程中，研发和测试同学 遇到 delay 风险应第一时间通报；一线同学（研发/测试）及时反馈给负责人，负责人判断后再同步到产品总负责人；产品总负责人同步到上级（曹帅）
3. 不同职能的同学沟通时，注意基于事实充分沟通，尽最大可能避免理解偏差/歧义；不用顾忌“面子”“情绪”，开放沟通，有问题就讲。