一个我心目中的项目迭代推进

一、介绍

在今天，一位实习生同事问我，为啥我们项目管理得这么乱

其实我也想改变，但我只是一个小兵仔

借由这个时机，我思考了一下，我理想中的一个项目迭代流程是什么样子的

二、如何进行管理

首先，我介绍一下几个角色，大家都很熟悉，我将他们分为几个部门阵营

• 开发部
  • 开发经理（架构师，技术总监，CTO）
  • 开发人员（主要是业务开发）
• 产品部
  • 产品经理（主要负责产品需求，对接客户了解需求）
• 测试组
  • 测试经理（负责人）
  • 高级测试（主要负责压力测试，安全测试）
  • 中低级测试（主要负责业务功能测试）
• 运营
  • 负责产品业务上的运营
• 运维
  • 负责发版升级，日常服务器监控治理等
• 项目经理
  • 统筹项目的版本周期，以及项目的迭代内容

好的上面介绍了几个部门，下面直接开始

1. 周五下午：产品经理将自己收集到的需求，提供给开发经理及测试经理
   1. 项目经理收集产品经理的需求，确定下一次发版的窗口
   2. 开发经理评估后对需求进行拆解，简单的评估开发工作量，涉及自己的技术方案
   3. 测试经理评估后对需求进行拆解，简单的评估测试工作量，编写自己的测试用例
2. 周一上午：开发经理，测试经理基本评估完成
   1. 开发、测试、产品过技术会，会上会提出技术方案。简单的需求就会一笔带过，复杂的则会细讲（尤其是有要调研的技术）
   2. 如果会上技术方案，不满足产品需求。需要重新进行设计或者是微调
3. 周一下午：开完技术会议后，测试编写的测试用例，可能需要做一点变更
   1. 测试会通过开发给出的技术方案，带上自己的测试用例，完成之后拉上开发、产品一起过测试用例
   2. 达成一致后，由项目经理、开发经理、测试经理确定工时，定下需求数量，做出微调，以及提测时间、发布时间
4. 编码阶段、测试阶段：各负责人把握进度
5. 预发布阶段：产品验收
   1. 如果验收不通过，项目经理临时解决方案
   2. 会后进行复盘问责， 避免类似情况发生
6. 发布阶段：运维提前收集升级脚本，进行操作
   1. 发布完成后，测试会上线进行验证

三、最后

• Q：程序员在写代码的时候，产品经理在做什么
  • A：在收集你的饭碗
• Q：人这么多，不会乱吗
  • A：项目是多个的，小组是多个的，分配任务是各个负责人定的
• Q：出现生产重大事故该怎么办
  • 如果是服务器原因导致系统崩溃，首先要恢复正常。后续对运维、运营进行问责
  • 如果是代码原因，导致服务无法正常使用。那么相对应的开发就要做好心理准备了

以上，便是我的想法。

我不是PM，管理不了项目。但每次看到公司焦头烂额的推进迭代，我就心烦

故推出我心目中的迭代版本流程，没有实践，肯定会充满各种问题

如果有大佬看到，能否帮忙指点一二，感激不尽