清明节前一晚，在深圳回广州的路上，滴滴，高铁站，高铁，一路连着手机热点，远程测着bug，回到家，再接着奋战3个多小时，总算在清明凌晨，完成测试环境和生产环境验收，让月度版本发布告一段落。而这发布，已经比原定的发布时间晚了5个工作日，7天。不客气地说一句，这么长时间的延期，上帝都造完人了。
虽说版本顺利发布，团队的所有成员都有功劳；大家凌晨兢兢业业改bug，也能感受到大家的苦劳。可这几天，反思整个版本为什么会延期这么久，我总觉得，有些苦劳其实是可以避免的，过度的辛苦和疲惫一定会降低人的效率和做事情的效果，想要让以后的版本中，减少不必要的苦劳，很有必要对整个版本的经验进行总结。
本次版本整体来说，存在以下三大核心问题：
1.前期确定需求的过程耗时太长，很多可以早早开始的研发工作，产品没有牵头有效地抓起来，导致后续留给研发和测试的时间过短，工作质量无法有效保障。版本发布的预留时间是一个月，我们和需求方、各外部团队确认业务需求耗费了一周，编写产品需求文档、评审需求文档、反复修改需求文档又消耗了一周，留给研发的时间只有一周，测试一周，实在是太紧凑太赶，极大地影响了交付的质量和准时性；
2.测试资源严重不足，前后台两个系统，多条核心主流程，多个外部对接系统，测试任务全由一位测试同事担纲，我都觉得有点心有余而力不足；且版本发布日之后，虽然还有遗留bug，但测试同事很快就被派往支持另一项目，导致后续无法有效支持遗留bug的测试及验收；
3.项目出现重大风险时，问题反馈的机制没有有效地建立起来，没有直接向研发和测试的核心负责人及时反馈问题，提出加班支援的请求。只是简单地发邮件告知团队成员当前遗留的一些问题，希望大家尽快修复，由产品经理去推动，实在力度不足。导致项目上线前的周末完全没有利用，全体人员睡大觉，对bug们爱理不理。
以上的三个问题，在后续的工作中，其实是可以在一定程度上有效规避的：
1.无需研发和测试参与评审的需求确认，应尽量在上一个版本发布前，与所有相关利益方确认好；一旦研发和测试资源释放出来，就立即推进与研发和测试团队评审需求，这样可以有效地避免研发资源闲置，让各个版本之间的人力资源更加紧密地衔接起来；
2.根据功能点的多寡，评估测试人力的需求，不能纯粹地赶鸭子上架。如果当前的测试资源无法满足，要尽早提出，提前争取。且争取时的出发点一定要合理，切中测试负责人的利益点，例如，“如果本次版本还像上一版本一样，过了发布日期，主流程和核心功能点还遗留十几个bug，对公司领导和外部客户都很难交代”。通过对不良影响的预警，引导测试负责人重视项目，力求能够获得更多测试资源。如若实在无法获取更多测试资源，产品经理一定要尽早介入，加班加点，没有条件创造条件，协助测试同事进行测试。尤其要重视当前版本的主流程和主功能点，尽早发现尽快跟进修复，尽量避免遗留bug，给用户的体验造成严重的不良影响；
3.当项目出现因研发和测试不力导致的重大风险，可能导致该版本无法准时、按需地交付时，要及时向研发负责人和测试负责人通报问题。有效地利用研发和测试负责人的职权，调动相关人员加班赶进度。相比产品经理自己吭哧吭哧地卖萌、卖人情、撒泼，费了老劲别人也不一定配合，领导们哼哼一声，相关人员肯定都会全力以赴。
不过，除了看到问题，在这一次的版本发布中，我也深深地感受到了一群人并肩作战的团队感。
夜深人静的时候，大家坚守岗位，一遍遍地测试，一遍遍地修改，只为了顺利交付，让客户满意。
当我完成了生产环境验收，跑通所有流程，完成数据落库，宣告“没问题了！”时，真有一种打了一场胜仗的感觉，有《流浪地球》里，尾声部分，完成任务后激动人心的感觉。
看着大家齐心协力创造的作品，累，也骄傲。
虽有不足，但相信，力行改善，追求完美的一颗心，会指引我们做得越来越好。
网友评论