项目管理经验总结

• 如果有紧急需求，或高优先级需求优先其它开发资源，如果现有的人力资源都被占用，可以挂起旧需求、插入新需求。

• 确保需求无缺失、无漏洞、无歧义、大小合适。
• 确保开发/测试对需求理解到位。

• 需求评审。评审时主要注意需求是否有需求缺失、逻辑漏洞、考虑遗漏、需求不明确、需求是否过大的问题。如果需求过大可以可以进行需求拆解，分期处理需求，尽量敏捷开发。需求越大，进度管理越难、不可控因素越多，可能出现的变化越多、风险越大。逻辑漏洞、考虑遗漏以及是否明确的问题主要由开发测试同学把控，这个比较考验开发和测试同学的素质。项目管理者主要把控总体的需求质量和需求大小。

• 产品将需求文档在评审前1天发出，研发侧有时间去看
• 再小的需求都必须有文字记录，比如用1句话在tapd进行描述

• code review。code review要在开发完成前进行。新入职同学必须进行code review。code review时，组长要做好决策和把关，对没有把握的逻辑不要急着上线。
• 开发规范。规范文档沉淀和宣导；sonar插件/alibaba规范插件，sonar系统扫描卡点。
• 单元测试。cicd平台可设置一定比例的单测卡点。

• 进度掌控：
  • 定期透明进度（频率合适），必须汇总到项目管理者，可使用早会、进步同步文档、项目群每日个人总结（各发一句话）等形式。
  • 协同较多、跨域项目建议使用会议形式，有利于问题解决。
  • 协同较少、小型项目建议使用定期文档同步或群内透明的方式，减少低效会议。
• 风险解决
  • 风险识别与记录
  • 风险跟进。
  • 风险解决：加班、砍需求（保主线，砍支线）
• 问题解决：
  • 问题记录与解决
  • 遗留项记录为文档或者需求的方式

按量完成：