背景 需求评审 建议形式:会议形式 目标:定需求大方向 参加人员:技术经理、需求方 主要角色:主持人一名、会议记录者一名(建议主持人和会议记录者为不同的人)、能提出需求中的问题和疏漏的高阶人员若干 评审结论通知到:领导、参加人员 方案评审 建议形式:会议形式 参加人员:各方开发人员、技术经理、QA、需求方、潜在用户(比如一个通用组件可能其他团队也有需求)、相关合作方 主要角色:主持人一名、会议记录者一名(建议主持人和会议记录者为不同的人)、能提出方案中的问题和疏漏的高阶人员若干 评审结论及最终方案文档发送给:领导、参加人员 方案汇报 建议形式:会议形式 目标:达成共识、争取支持和资源 参加人员:领导、技术经理 如果方案有改动则需要重新发送给:领导和方案评审阶段的所有参加人员 动员会 如果是一个并非外部需求驱动的项目,比如在业务部门的长期实践中孵化出来的一个公司级的基础组件。做成一款自己的产品。这时候,最重要的事是要做的人都要有信心和信念把东西做好。自己没有注入灵魂的产品是不可能成功的。 这时候,作为项目经理+产品经理,需要把自己对项目的理解、思考、未来规划和所有实施人员对齐。 开发 建议形式:拉微信群、企业内部交流群沟通 目标:问题及时反馈沟通、进度同步 参加人员:各方开发人员、技术经理 联调 建议形式:拉微信群、企业内部交流群沟通。必要时可在工位或封闭会议室 目标:问题及时反馈沟通 参加人员:各方开发人员、技术经理 代码提测前评审 建议形式:会议形式 目标:对平时已经由个人review过的代码再次梳理,通过review代码发现潜在问题 参加人员:各方开发人员、技术经理、QA 验收 建议形式:会议形式 目标:确认完成的产品和需求的一致性,对之前没有完善的细节需求做补充 参加人员:各方开发人员、技术经理、QA、需求方 验收分为全新功能验收和旧功能改造升级。全新功能验收,主要依赖大家对产品的理解、领悟和感知。旧功能改造升级最好有新老结果对比。举例如下: QA测试 建议形式:拉微信群、企业内部交流群沟通。必要时可在工位或封闭会议室 目标:找出并修复问题 参加人员:开发和QA 投产 建议形式:正规发布流程 参加人员:技术经理、开发人员 注意:需要通知到之前参与过的各方 总结 |
|