随着工作年限的增长，我们从一开始负责一个功能，再到负责一个模块的数据字典及框架设计。再到负责整个系统的需求评审及架构设计。这一路见证着程序猿的成长。但当我们逐步成为一名架构师，或是一名项目管理人员时，会发现一个项目的成功，会牵扯到各式各样的问题及风险。无论是系统本身要兼容快速发展的业务形态，还是由于人员因素导致的项目延迟，又或是系统代码的臃肿或是难以维护，亦是新人来后的一脸迷茫。那么下面，分享下，项目流程管理之我见。
一、整体项目流程
1、 需求评审与确认
要求：PD会进行需求的整理并放入需求资源池。确定本期研发的功能需求，并开始需求评审，需求评审时，能够使技术人员能够完全理解本次需求的前因后果，作用，目标及整个流程。
产出：该阶段主要为pd产出相关prd及demo，对需求进行宣讲，并记录疑问及难点。
2、模块流程文档
要求：围绕着本次迭代的核心问题，编写整个模块的闭环业务流程。如有复杂逻辑，需要画出用例图、协作图等。
同时，要给出该模块的非功能性需求，例如：调用量、日均增量、访问次数等待。
产出：领域模型、开发模块架构图、技术架构图、人员分工（每个人负责哪个模块）
3、详细设计及评审
（1）概念映射：抽取本次模块迭代的一些属于概念。
（2）框架设计：围绕着本次迭代的核心，进行模块的扩展构思，不仅仅以完成本次功能的模块为主旨，还需要考虑未来的体系中，该模块的可用性、扩展性。
（3）数据库设计：数据库设计时要严格遵守数据库范式、同时围绕系统做到可扩展。
（4）功能细化与调研各个环节中需要调用哪些接口服务。
（5）前后端传输对象的映射及定义，进行前后端最后评审。
产出：技术架构图、数据库关联关系图等，一致评审通过后，形成完整文档。
4、编码
（1）围绕着模块的核心构建核心框架代码（遇到问题可互相讨论）
（2）编码及功能实现。
（3）接口注释、复杂逻辑注释。
5、测试
要求：测试阶段，根据代码逻辑，编写每一个case的相关测试用例及单元测试。变更覆盖率不得低于百分之80。
产出：测试用例文档及单元测试TestCase。
6、发布前准备与发布
要求：查看代码检测工具，质量分不得小于35分、行单测覆盖率不得小于百分之60。从开发->集成->预发->发布阶段，每一阶段都需要进行验证及日志查看。
注：预发前要充分做好回归测试（根据每次迭代的测试用例及单元测试进行测试），防止线上已有功能受到影响。
7、线上问题修复及运维
要求：（1）发布上线后出现问题，需要紧急变更处理，做好线下及预发验证，发布线上。同时在lark上记录该问题的前因后果。
（2）约定时间，每日查看自己负责的模块及整体系统运行情况，发现问题及时抛出。
二、代码质量及review
要求：每次迭代完的下个星期，抽出一下午时间进行代码质量及review（pmd检测大部分代码质量问题），包括：
（1）代码结构是否合理，能否有更好的实现。（结构角度、方法抽象、jvm堆栈内存占用等）
（2）代码中没考虑到的情况
三、项目管理
项目管理要点分为，时间把控、风险把控、补位意识、结果与目标导向四点：
时间把控：
（1）整个项目流程分为需求、设计、开发、测试、实施阶段。根据需求的复杂度、团队整体能力水平、调研负责度进行迭代周期的预测。
（2）一旦时间确定下来，就严格按照每个阶段的产出实行。
风险把控：
（1）意外情况或有进度风险的情况。需要及时暴露出来 风险原因及风险问题。并进行相关协调沟通，补位意识。
补位意识：
（1）项目风险确定，每个成员都有自身的长项，发现影响进度的问题，包含于自己能力的能力范畴内，帮助对方提速，追赶项目进度。
结果与目标导向：
（1）保质保量完成需求及模块的迭代。
（2）优化review及补充，使每个人能够知道对方模块的逻辑及全系统逻辑。
（3）问题总结及技能总结。
（4）从整个系统的层面、业务大图的层面去考虑整个系统或产品的发展及扩展。
当然，现实或许是残酷的，时间或许是紧迫的。很多时候，我们会因为各种各样的原因而搁置其中的部分流程。但规范决定着长远的风险可控，倘若有时间一定要将必要的补上，这是对别人负责，同时也是对自己负责。
本文作者：松柏
本文为云栖社区原创内容，未经允许不得转载。
网友评论