声音管理平台项目回顾

声音管理平台项目2019年3月12日建立qq群，将已明确的项目组成员拉入项目组。

最初人员配置：后台3人，前端2人（其中1个后续投入），测试1人

由于以往其他项目都是提前通知成员先看需求，将项目启动会议忽略了，直接以产品需求讲解为信号当做项目正式启动的标识，以那天为项目正式启动日。

事后发现有部分人员实际因为各种各样的原因并没有在通知看需求的时间里去真正的看需求，理解需求，导致需求评审时有人还没看需求，或者对需求的理解度不够，将需求讲解（需求评审）会议当成需求讨论答疑大会，有的情况下甚至开了2天。开会效率低。

所以吸取教训在需求评审前还是加一个项目启动的会议，通知大家项目已经开始启动。启动会议上明确以下几点：

1. 产品介绍项目背景，迭代目标，期望上线时间，本期重点需求
2. 确认需求、设计图是否完整（一般在会前确定，会议上只是强调重复，需求不完整不启动）
3. 根据需求量给出看需求（需求预审）时间，一般是2-3天，然后进行（需求讲解）需求评审
4. 介绍项目组同事，确认人员投入时间，若人员不能立刻投入，需明确何时投入日期，及不能立即投入的原因
5. 要求需求评审前各端负责人给出预估计划，一个初步评估本期项目大致开发，测试时间，方便评估各团队工作量是否平衡
6. 宣读一些已经明确的项目流程规范，进一步加强大家的意识

回到声音管理项目就存在项目经理与技术人员理解不一致的地方，项目经理以为3月12日可以启动并进行需求讲解，但技术那边理解的是开始投入看需求。经过双方沟通确认，订在3月13日早上开项目启动会议，3月18日需求讲解会议，提供了3天看需求的时间。

项目启动会已知的问题，当前只能投入一个测试人力，由于项目较大会导致测试周期拉的很长，需要协调测试人力。

3月18日-3月19日 2天需求评审，，4月15日产品进一步补充和完善需求

第一次初步计划3月25日-4月4日研发需求分析&方案设计&接口文档整理，4月8日提供详细计划

 

出现重大人员变更：

3月29日原定测试人员退出，由另外2个新人接手，4月1日开始投入

4月1日原定后台技术人员3人，abc，b需请长假，会影响后续项目进度，协商后将其退出项目组，3月27日由另一个d成员替代，由于人员变动安排需重新评估计划，后台负责人a表示4月2日提供新的初步计划，原定的接口评审时间也相应推迟

4月8日人员变动，后台负责人由a变为c，a设计阶段完成后退出项目组，4月9日新增成员e，即后台组由原abc更改为cde，

由于期间的需求补充&新加入成员要重新开始看需求，需求分析设计，最初订的4月8日出计划，推迟到了4月25日

4月28日增加一名前端开发

到此确定人员配置：后台3人，前端2人，测试2人

较大需求变更记录

3月21日-3月24日产品将需求评审中与逻辑有关的修改点在tapd上进行了部分补充

3月25日-4月15日产品跟随技术方案修改，进一步完善和补充需求

4月26日由于技术实现方案对部分需求进行变更

4月30日产品由于需求遗漏，对需求进行了补充

5月10日测试用例评审后针对有疑问的地方进行了补充和修改

7月1日由于实际使用部门体验系统过程中提出严重问题，产品提出需求变更

7月4日发现严重已知问题，提出需求变更

4月25日提供项目详细计划：

需求阶段3月13日-4月23日

第一轮迭代开发：4月24日-5月17日  测试5月20日-5月30日

第二轮迭代开发：5月20日-5月31日   测试6月3日-6月11日

第三轮测试：6月12日-6月17日

第四轮测试：6月18日-6月25日

到5月20日如期完成第一轮迭代开发，按计划提测，但e成员负责的任务可能会延期4天

6月3日未能如期完成第二轮迭代开发，只有部分任务提测，6月6日提测剩余功能，实际这部分功能有很多问题导致测试严重阻塞

6月17日第一次调整计划：由于研发延期4天提测，测试顺延4天，第四轮测试6月24日-7月1日

6月24日第二次调整计划：由于环境准备需要1天，还有遗留问题未解决需1天，第四轮测试6月27日-7月3日，整体顺延6天

7月8日第三次调整计划：由于7月4日重大需求变更，7月 4日-7月10日新增需求设计&开发，7月11日-7月17日测试，7月18日上线

至此项目告一段落，但上线后问题不断，实际用户使用过程中，研发&测试&产品一边解答问题，一边持续不断补坑中

 

吸取的教训：

需求阶段由于人员变更，时间较长耗时29个工作日

需求变更不可避免，开发后期直到临近上线还有需求变更

部分需求变更未及时看变更内容，出现一些细节问题到测试阶段才发现

后台接口请求不规范，接口文档未及时更新

业务能力不熟

开发过程中出现未在需求之内的问题未及时反馈给产品

低估了需求的复杂性开发时间评估偏乐观

项目经理起到的作用有限，更多的是产品经理与技术的沟通

项目上线后有不少产品功能的问题与最初设计不符，修复阶段耗时较长

 

取的的经验：

项目人员确定后尽量不要做大的改动，且需要提前确定好

对于独立的需求变更统一规划迭代处理，已确定的点按原计划执行

加强对业务能力

对于不确定的点一定要尽早尽快与相关方确定，不确定的地方一定要公开透明