解决创业型公司项目研发流程的痛点，如何做一个高效的项目团队管理？

现有项目管理流程痛点

• 需求管理:由于迭代更新速度较快，需求没有进行有效的管理，即迭代完成后：迭代需求完成情况确认，是否有遗留或流转至下一个迭代再实现
• 测试管理：
• • 设计测试用例工作的缺失，多少因为需求理解不一致、未考虑完善的测试场景导致漏测
• • 兼容性测试：根据App版本、H5对机型的适配，此测试类型力度不足
• • 用户体验性测试：体现在产品的UI、APP功能用户使用习惯，从用户使用习惯及对UI层设计体验，易用性测试不足：即人人需要产品思维
• • 测试环境不足，由于迭代速度快，开发代码分支管理不足，现象：开发完成后无可用测试环境提测部署，无法及时测试上线，同时会因为开发代码累积、合并问题导致代码丢失，测试时间压缩及回归测试策略不足
• 项目管理：
• • 项目进度信息同步不及时：即需同步各项目组成员负责的task完成情况
• • 项目总结及测试总结，未对各项目组成员及整个项目进行的工作情况进行分析，尚需进一步加强及完善

做一个有效的项目流程管理

• TAPD项目管理系统进行迭代需求、任务分配、开发及测试管理；
• 开发提测要求：以迭代开发分支提测，sql脚本、配置文件统一git仓库管理：
• • 提测邮件包含要素：更新服务(先后顺序-依赖关系)、有无SQL脚本(执行顺序)、配置文件信息变更，前端包含：前端访问路径、有无静态资源包更新；
• • 在git创建脚本仓库，新建迭代开发目录：存放每次迭代开发提测的sql脚本及配置文件，由测试人员拉取至本地，在测试环境执行；
• 每次迭代/需求开发完成并完成测试，测试人员需提交测试报告；
• 大版本迭代测试完成后，按需提供上线文档，指导运维同事部署上线。

测试环境需求：

• 准备1套新测试环境：+原测试环境+对外联调测试环境：共3套；
• 准备1套开发环境，回收开发对测试环境数据库所有权限，只留有查询权限；
• • 对外联调环境只在需要与第三放联调时供开发及测试使用；
• 所有测试环境的数据库、linux服务器权限回归测试人员，由测试人员维护。

目的与好处：

• 开发与测试环境独立分开，保证测试数据的干净，开发解决问题后由测试人员部署，控制测试进度，对提测版本进行有效管理；
• 多套测试环境并行可以一定程度的避免迭代任务堆积导致迭代延期上线、或上线没测的代码；
• • 每次迭代开发完成后，有效管理开发分支并以分支提测；及按需合并分支提测；
• 测试环境由测试人员自己维护：部署服务(jenkins\ranchar)、更新sql等。

后期测试流程改善：

• 需求评审通过后，分析测试需求、整理测试点，合理设计测试用例，发起用例评审会议通知；
• • 如是新项目或大版本迭代需求，开发按需编写开发计划，测试依开发计划编写测试计划及方案，指导测试；
• • 用例评审成员：开发、产品、测试、项目，评审结果并完善测试用例以邮件形式通知涉众；
• • 评审规则：单次需求设计的测试用例小于50条目，免评审，可测试交叉评审；
• • 待项目稳定，需求迭代放缓，有大版本更新，加入交叉测试流程，避免漏测；
• • 后台与前端联调需要对后台接口返回的数据结构进行规范定义，提高开发效率；
• • 接口测试：对需要变更、调整的接口进行接口测试，提前介入并进行有效测试；
• • 新项目或大版本需求，待完成测试后上线，需要测试提供测试报告及项目总结报告；
• 回归测试，累积多迭代需求提测需要对原有功能进行上下兼容性及回归测试策略
• • 召开项目总结会议：开发、测试、产品、项目；
• • 不定期开展测试内部技术及测试心得交流会议。

改善的目的与好处：

• 用例的设计及评审：对产品需求，开发测试产品进一步沟通，统一需求理解一致，可以完善用例，避免未考虑的测试场景：降低漏测率及现网bug率；
• 规范接口数据结构：前后端独立开发，前端可以自定义mock数据，提升开发效率，降低沟通成本；
• 交叉测试：避免测试人员定向思维，测试疏忽导致漏测，有利于培养及提升测试人员对不同项目组人员之间的沟通能力；
• 接口测试：在前期投入，降低进入系统测试后才发现bug的概率，尽早开发尽早测试尽早发现bug，提升测试工作效率；
• 回归测试：对较多迭代需求的提测，对原功能进行选择性全量/增量回归测试，避免上线后发现功能不全等bug；
• 项目总结报告：有利于总结项目迭代过程中的不足，不断提升及完善公司项目开发测试流程。

项目绩效考核

• 主要使用Tapd项目管理系统，统计各项目组成员负责的task的完成情况是否及时；
• 测试过程中测试发现有效缺陷数及开发解决缺陷的效率；
• 各组长对组员日常工作安排及临时接收任务完成情况评估；
• 关注项目整体工作效率的提升，技术创新等方向全面考核。