一個項目的完整生命週期包括以下幾點，想法提出、競品分析、調研、產品內部溝通確定、依賴解決、需求預審、技術方案初步確定、需求正式評審、技術方案正式評審、開發實現、代碼評審、提給測試人員測試、部署上線、產品走查等。
上述是理想化的流程，實際工作中難免有臨時性、突發性問題要解決，但是需求截止時間明擺在那裏，測試人員的排期時間調整又是最麻煩的，因爲在電商公司中測試人員是最稀缺。矛盾的是，技術人員希望問題解決的時間也應該算一個新需求，進行中的需求應該順延，不然只能天天加班自我消化，叫苦連天。
或許需求工期評估時間多留點貓膩是一種辦法，缺點就是容易造成雙方的不信任，得不償失。那有沒有更好的辦法呢？換個問法就是如何有條不紊地管理好版本迭代？且聽我從"在京東我們是怎麼度過一週的"角度說兩句。
1、需求預審
有些產品喜歡私下和研發溝通需求，甚至是長時間的，這其實對雙方都不利。容易消耗開發時間，而且一個研發對需求的理解多多少少有些片面。所以最好的方式是選擇性地私下溝通，然後在需求預審會上再一起溝通。
需求預審聚焦點在於需求的價值分析、可行性分析、風險分析，我們對需求進行初步評估，然後提出存在疑問的地方，會上無法給出定論的，會下再討論。
當然一個需求能進預審會是有前提條件的，以下情況的需求都不能進入預審範圍。比如沒有經過產品內部部門討論的需求、一句話PRD需求、重複建設的需求、個性化和定製化的需求、相關依賴沒有解決的需求。
時間安排：第一週的週四下午
2、技術方案初步確定
這個階段對需求預審中雙方沒有達成一致意見的點進行更加深入的探討，方便產品補充完善需求文檔。另外我們此時會驗證相關依賴的可用性、正確性，在大腦中構思方案。
時間安排：第一週的週五
3、需求正式評審
需求預審後和技術方案初步確定階段的溝通交流結果，都有可能對需求產生巨大變化，所以需要對變更過的需求進行評估，確定需求的最終形態，避免開發階段需求突然變更，讓我們措手不及。
時間安排：第二週的週一下午
3、技術方案設計和評審
當然，並不是要求每一個需求都要進行技術評審的。當涉及到錢或者邏輯較爲複雜時就必須進行了。技術方案編寫好後組織同事和測試人員、領導一起評審。會後再輸出工期。
我們技術人員編寫技術方案時，容易一下子就陷入到技術細節中，關注某個功能如何實現。實際上我們應該多考慮整個交互流程，多想想不同操作場景，多想想有沒有可替代的或者成本更小的方案，甚至可以反思這個需求的必要性真的存在嘛？！
時間安排：第二週的第二天
3、實現功能
所有需求的實現時間儘量不超過一個版本迭代週期。
4、代碼評審
提測前必須進行內部評審，避免返工。另外需要邀請模塊關係最強的同事，還有測試人員參加。因爲他們不知道你到底修改了什麼，影響了什麼，是否存在牽連影響。此時我們選擇開誠佈公，他們會幫助我們提高代碼質量，幫助我們判斷代碼在哪些場景下會腰折。
我們一般以以線下開會投屏或者共享屏幕的形式進行。這種形式或許不是最好的，但絕不是保守主義體現。因爲上線變更引起事故造成的成本浪費遠比一下午的代碼評審成本要高，包括隱性成本。
時間安排：第三週的第二天
6、日常和測試期間缺陷管理
不管是日常問題反饋還是測試期間的缺陷反饋，當天必須解決或者有條件掛起。如果花費的時間超過半天，那就得當成需求卡片來處理了。
5、部署上線
部署必須灰度分批進行，必須周知干係人。另外，小需求必須合併上線，一週不能上線多次，不然就會浪費很多時間在部署上線和部署驗證階段。
時間安排：原則上，上線時間爲測試通過報告的第二天，如遇到節假日、週末、營銷活動日，順延到下週一。
總結
可以看到，如果我們能夠按照這種雙週發版模式進行小步快跑的話，需求可以快速上線，研發也不至於壓力過大。這一切的前提條件是需求拆分合理、產品要接受非需求時間也有可能算爲需求卡片(比如大需求上線)、研發質量有保障。
推薦閱讀
