项目背景
客户已有运行多年的官网老站（PC端），想在今年对老站进行一次UI全面更新、功能全部平移的升级，对接新的运营后端，然后建立官网小程序端且与官网PC端进行联动，使得品牌自有渠道能够更加全面化。
挑战
- 时间紧。五月份进行Inception Workshop，确定项目交付范围与架构方案。官网六月初开始开发，小程序八月份开始开发，整个项目九月中旬必须上线。
- 系统集成和数据迁移。系统需要对接客户的CRM，对接3个服务商，需要对老官网历史数据（订单、会员等）进行迁移。
- 多团队沟通。小程序设计稿由第三方提供，因此多出了沟通、确认的时间，以及把控第三方交付的时间，以避免交付进度的影响。
迭代计划
Inception Workshop一结束，差不多就开始整理整个项目涉及的故事和技术卡，按照两周一迭代进行迭代计划安排并与客户确认，每个迭代第一周周三安排跟客户showcase上一周的预定的交付结果，得到反馈并安排进行改进。官网项目比较顺利，改造自定义了一下SSR框架就能开始进行开发，并且因为历史原因，还能享受到上一个项目遗留的一些福利，当然也少不了一些坑。
小程序的时间比较紧，相当于整个复制了一遍官网的功能，主要是前端任务，后端可以复用官网后端，因此一开始就给团队同学同步到整个项目的情况，让大家有一个大概的心理准备。然后就是与官网类似的处理，整个交付内容进行迭代排期并与客户确认，前期尽量能多做一些，避免后期怎么努力都无法完成的囧镜。
项目进行时
整个项目的过程中，PM会根据迭代完成情况灵活的找外援加入项目进行支援，以免交付延期。每日的站会（Standup Meeting）更新，让团队能对当前进度有一个大概的了解以及同步一些突发信息。定期的回顾会议（Retrospective Meeting）能暴露团队内部问题，将风险扼杀于苗头，鼓励能为团队带来正向帮助的行为，及时停止不好的做法。
迭代会议（IPM）能让团队对下一个迭代具体要做的事情有一个详细的了解，进行大致的估点，以便check开发进度情况。技术人员定期的CodeReview成为一个大家交流的时段，发现风险，指出问题，互相提高，还可以帮助新人快速的融入团队。
根据团队内部人员情况，可以定期进行一对一沟通，了解个人诉求或是给与近况反馈都是一个不错的渠道。TL应考虑团队内部人员提升自己的诉求，在一些安排上给与倾斜和鼓励，发现问题也需要提前制止。
不足之处
- 后期对卡墙（Jira）的管理松懈。导致有些问题反复修改，且丢失context
- 项目对运营后台有一些的定制化配置，没有提前准备运营需要了解的后台操作资料和培训，导致后期花费大量精力帮助运营进行后台配置与更新
- 人员（QA）变动频繁。公司处于高速发展阶段，项目经历了4个QA，因此有些context可能丢失，测试不到位，导致项目上线出了一些低级问题。比如上线后发现部分浏览器有支付兼容问题
- 甲乙方定位太角色化，不能站在专业角度评估客户需求（项目做完感觉都一样，客户是爸爸）
- 与第三方合作交付产物管控不到位，导致第三方设计稿的延迟影响到我们的交付计划
- 与客户沟通的需求，后面有一些没有进行邮件确认，导致交付验收阶段因一些需求上的问题产生不愉快（这个完全没必要的）
- 对第三方系统的了解不充分和集成系统的需求整理不清晰导致后续一系列的开发、测试都不到位，以致上线出了不可控的问题
项目总结
- 提前评估项目的风险点，且在项目进行过程中持续维护，后期安排足够的时间进行调研与分析
- 与第三方合作一定要有自己的规划，并且将定好的规划提前与第三方确认时间，然后派人提前专门细致的了解第三方需求详细点，确定好具体的业务场景，再来规划己方与第三方的具体集成的点。此外，在进行的过程中，还应注意定时检查合作进度，管控风险
- 与客户沟通的所有需求都要进行邮件的二次确认，一个是能够对所有需求来源有所记录，另一个是能避免后面的不必要的消耗
- 开发管理不能松懈，尽量做到所有的改动都能有卡，能够进行追溯
- 对后期交付时所需要的资料提前准备，对需要进行培训的人员提前约好时间进行沟通培训
在前端这块的管理上，做的还不够。前期经常codereview，然后效果都还不错，让我有了一些错觉就是当前团队趋于稳定，中后期即便是加班比较多，大家气氛这块我觉得都还好。不过在项目后期的时候，有些疏于管理，然后大家有些人也被分配到了其他项目，和同事们的交流不够，没有及时的顾及到一些个人情绪，这块是可以加强的。
作为一个Lead，不论同事是否还在一个项目都应该及时的去了解近况，给与自己力所能及的帮助，这样才能产生向心力，以帮助一些比较迷茫的同学找到方向，看见灯塔。
整个项目时间不长，得失还是挺多的，不论是管理还是技术上，都会有一些心得。然后项目的ROI还不错，得到公司领导的肯定，最后客户那边的反馈也还不错，算是对大家努力的一种认可。