清明節前一晚，在深圳回廣州的路上，滴滴，高鐵站，高鐵，一路連着手機熱點，遠程測着bug，回到家，再接着奮戰3個多小時，總算在清明凌晨，完成測試環境和生產環境驗收，讓月度版本發佈告一段落。而這發佈，已經比原定的發佈時間晚了5個工作日，7天。不客氣地說一句，這麼長時間的延期，上帝都造完人了。
雖說版本順利發佈，團隊的所有成員都有功勞；大家凌晨兢兢業業改bug，也能感受到大家的苦勞。可這幾天，反思整個版本爲什麼會延期這麼久，我總覺得，有些苦勞其實是可以避免的，過度的辛苦和疲憊一定會降低人的效率和做事情的效果，想要讓以後的版本中，減少不必要的苦勞，很有必要對整個版本的經驗進行總結。
本次版本整體來說，存在以下三大核心問題：
1.前期確定需求的過程耗時太長，很多可以早早開始的研發工作，產品沒有牽頭有效地抓起來，導致後續留給研發和測試的時間過短，工作質量無法有效保障。版本發佈的預留時間是一個月，我們和需求方、各外部團隊確認業務需求耗費了一週，編寫產品需求文檔、評審需求文檔、反覆修改需求文檔又消耗了一週，留給研發的時間只有一週，測試一週，實在是太緊湊太趕，極大地影響了交付的質量和準時性；
2.測試資源嚴重不足，前後臺兩個系統，多條核心主流程，多個外部對接系統，測試任務全由一位測試同事擔綱，我都覺得有點心有餘而力不足；且版本發佈日之後，雖然還有遺留bug，但測試同事很快就被派往支持另一項目，導致後續無法有效支持遺留bug的測試及驗收；
3.項目出現重大風險時，問題反饋的機制沒有有效地建立起來，沒有直接向研發和測試的核心負責人及時反饋問題，提出加班支援的請求。只是簡單地發郵件告知團隊成員當前遺留的一些問題，希望大家儘快修復，由產品經理去推動，實在力度不足。導致項目上線前的週末完全沒有利用，全體人員睡大覺，對bug們愛理不理。
以上的三個問題，在後續的工作中，其實是可以在一定程度上有效規避的：
1.無需研發和測試參與評審的需求確認，應儘量在上一個版本發佈前，與所有相關利益方確認好；一旦研發和測試資源釋放出來，就立即推進與研發和測試團隊評審需求，這樣可以有效地避免研發資源閒置，讓各個版本之間的人力資源更加緊密地銜接起來；
2.根據功能點的多寡，評估測試人力的需求，不能純粹地趕鴨子上架。如果當前的測試資源無法滿足，要儘早提出，提前爭取。且爭取時的出發點一定要合理，切中測試負責人的利益點，例如，“如果本次版本還像上一版本一樣，過了發佈日期，主流程和核心功能點還遺留十幾個bug，對公司領導和外部客戶都很難交代”。通過對不良影響的預警，引導測試負責人重視項目，力求能夠獲得更多測試資源。如若實在無法獲取更多測試資源，產品經理一定要儘早介入，加班加點，沒有條件創造條件，協助測試同事進行測試。尤其要重視當前版本的主流程和主功能點，儘早發現儘快跟進修復，儘量避免遺留bug，給用戶的體驗造成嚴重的不良影響；
3.當項目出現因研發和測試不力導致的重大風險，可能導致該版本無法準時、按需地交付時，要及時向研發負責人和測試負責人通報問題。有效地利用研發和測試負責人的職權，調動相關人員加班趕進度。相比產品經理自己吭哧吭哧地賣萌、賣人情、撒潑，費了老勁別人也不一定配合，領導們哼哼一聲，相關人員肯定都會全力以赴。
不過，除了看到問題，在這一次的版本發佈中，我也深深地感受到了一羣人並肩作戰的團隊感。
夜深人靜的時候，大家堅守崗位，一遍遍地測試，一遍遍地修改，只爲了順利交付，讓客戶滿意。
當我完成了生產環境驗收，跑通所有流程，完成數據落庫，宣告“沒問題了！”時，真有一種打了一場勝仗的感覺，有《流浪地球》裏，尾聲部分，完成任務後激動人心的感覺。
看着大家齊心協力創造的作品，累，也驕傲。
雖有不足，但相信，力行改善，追求完美的一顆心，會指引我們做得越來越好。