一、介绍
在今天，一位实习生同事问我，为啥我们项目管理得这么乱
其实我也想改变，但我只是一个小兵仔
借由这个时机，我思考了一下，我理想中的一个项目迭代流程是什么样子的
二、如何进行管理
首先，我介绍一下几个角色，大家都很熟悉，我将他们分为几个部门阵营
- 开发部
- 开发经理（架构师，技术总监，CTO）
- 开发人员（主要是业务开发）
- 产品部
- 产品经理（主要负责产品需求，对接客户了解需求）
- 测试组
- 测试经理（负责人）
- 高级测试（主要负责压力测试，安全测试）
- 中低级测试（主要负责业务功能测试）
- 运营
- 负责产品业务上的运营
- 运维
- 负责发版升级，日常服务器监控治理等
- 项目经理
- 统筹项目的版本周期，以及项目的迭代内容
好的上面介绍了几个部门，下面直接开始
- 周五下午：产品经理将自己收集到的需求，提供给开发经理及测试经理
- 项目经理收集产品经理的需求，确定下一次发版的窗口
- 开发经理评估后对需求进行拆解，简单的评估开发工作量，涉及自己的技术方案
- 测试经理评估后对需求进行拆解，简单的评估测试工作量，编写自己的测试用例
- 周一上午：开发经理，测试经理基本评估完成
- 开发、测试、产品过技术会，会上会提出技术方案。简单的需求就会一笔带过，复杂的则会细讲（尤其是有要调研的技术）
- 如果会上技术方案，不满足产品需求。需要重新进行设计或者是微调
- 周一下午：开完技术会议后，测试编写的测试用例，可能需要做一点变更
- 测试会通过开发给出的技术方案，带上自己的测试用例，完成之后拉上开发、产品一起过测试用例
- 达成一致后，由项目经理、开发经理、测试经理确定工时，定下需求数量，做出微调，以及提测时间、发布时间
- 编码阶段、测试阶段：各负责人把握进度
- 预发布阶段：产品验收
- 如果验收不通过，项目经理临时解决方案
- 会后进行复盘问责， 避免类似情况发生
- 发布阶段：运维提前收集升级脚本，进行操作
- 发布完成后，测试会上线进行验证
三、最后
- Q：程序员在写代码的时候，产品经理在做什么
- A：在收集你的饭碗
- Q：人这么多，不会乱吗
- A：项目是多个的，小组是多个的，分配任务是各个负责人定的
- Q：出现生产重大事故该怎么办
- 如果是服务器原因导致系统崩溃，首先要恢复正常。后续对运维、运营进行问责
- 如果是代码原因，导致服务无法正常使用。那么相对应的开发就要做好心理准备了
以上，便是我的想法。
我不是PM，管理不了项目。但每次看到公司焦头烂额的推进迭代，我就心烦
故推出我心目中的迭代版本流程，没有实践，肯定会充满各种问题
如果有大佬看到，能否帮忙指点一二，感激不尽
