什麽是合理的開發排期？我個人以為合理的開發排期是一個項目不延期，少加班的時間管理。

在目前接觸的各種項目開發中，開始時覺得時間很充足，但是後面做著做著，就變成苦逼開發加班加點趕工期，甚至項目延期。不僅僅是畢業兩三年的同學，甚至有工作近十年的老司機，也會經常遇到這種情況。出現這種情況大家很自然的想到是因為項目過程中各種不確定的事情發生，導致原本預感足夠的時間變得緊張起來。所以在項目進行的前期，作為開發需要給自己定一個合理的開發排期。

那麽如何來做一個合理的開發排期？

一、梳理時間分布

作為主要工作，理想的情況下一天的時間都應該花費在需求研發上，但是各種事情的插入，甚至開發自己的心情變化都會影響需求研發的進度。根據我們團隊的工作事項，總結下來研發同學日常的時間主要花費以下幾個方面：

1. 需求研發
2. 技術支持（工單、線上問題）
3. 團隊事務（指導新人、分享、招聘）
4. 會議溝通（評審、例會、技術咨詢）
5. 技術學習

可以說大多數情況下，一個項目的工期進度，受到研發同學在這些維度上的時間分配影響。假設需求研發按照八小時來分配，那麽隨著其他維度的時間消耗，基本上在工作上的時間要花費是十一個小時左右，而對於在技術和管理中並行的同學，恐怕研發外的事務花費時間更多。同時需要在各個維度上進行思維的切換，這部分切換的時間按照0.5小時來算，那麽在工作上的時間基本要達到十二個小時。算上通勤、吃飯、午休，基本要消耗十六個小時。一鼓作氣，再而衰，三而竭。久而久之對項目造成嚴重的風險，對團隊管理亦帶來沈重負擔。

要做合理的開發排期，第一步是要摸清楚自己每天的時間分布，然後按照自己的有效研發時間來對項目需求估算工期。打個比方如果開發同學真正的有效率的開發時間是6個小時左右。那麽在新的項目中，就以六個小時的開發時間來估算工作量的消耗時間，從而估算出項目的開發周期。

根據多年來經驗，對於上述維度的時間分配建議比例是，6:1:1:1:1，這樣一天的時間是十個小時，對於互聯網工作的同學，這個時間還尚可接受。另外除了需求研發外，其他的事項並不是每天都有或者每天都同時發生，那麽省下來的時間，可以放到需求研發或者學習中去。在遇到時間緊張的項目時，可以根據情況砍掉一些項目（比如技術學習），可以請求其他同事在這段時間內，對一些事務進行支持（比如技術支持、團隊事務）

所以做合理排期至關重要一步： 以實際（每天）需求研發時間來估算開發周期

二、預留buffer

工作中經常遇到一些很自信的同學，做排期時不留buffer。可預知的事情是在有事情插入或者遇到技術難題時，這位同學會往往加班加點趕工期的情況下度過，甚至導致項目對外承諾的時間點不成如期完成。所以不管是什麽項目，不管是什麽段位的技術大牛，一旦在實際項目中工作，預留buffer都是非常重要要的事情。對於buffer的作用無外乎降低項目風險，buffer的預留和使用可以參考以下兩點：

1. 總體buffer原則是一周預留一天
2. 項目版本叠代建議也預留部分buffer
3. UI走查建議使用buffer時間

三、管理依賴

需求某個事情完成才能進行的工作就是我們的依賴項。一個項目難免在項目成員或者對外部團隊產生依賴，依賴完成的時間和質量都會產生項目風險。對於依賴的管理也會影響我們的開發排期甚至是整體的項目進度。根據經驗依賴管理主要有以下兩方面

1. 依賴項完成時間點
2. 規劃聯調時間，一個依賴建議1-2天

對於第二條要特別重視，很多情況下在項目排期時容易忽略聯調時間，想當然以為依賴項在這個時間點給出的是一個穩定的輸出。導致後期發現問題反復溝通修復，延誤項目進度。

四、測試與復查

項目進行到尾期需要進行測試工作，在這個過程中還有兩部分工作：產品復查部分細節邏輯合理性，UI走查設計同學確認交付產品滿足視覺要求，但是這兩部分都可以放到測試階段來做。

測試階段工作，對於開發來說主要是部署環境和修復bug。同時這部分時間還受產品邏輯的復雜度影響，在這階段如果沒有足夠的時間來進行測試覆蓋和bug修復，對產品項目來說同樣是不能交付的產品，項目風險極大。測試與復查時間的分配可以參考以下幾點：

1. 周版本大概1-2天
2. 兩周版本大概2-3天
3. 月版本建議4-5天
4. 產品復查使用測試時間
5. UI復查使用測試或者buffer時間

另外為什麽測試時間這麽重要，因為有些依賴項即使跟他聯調成功後，輸出的依然不是穩定產品，因為他們根本沒有QA介入，只是簡單的自測！

同時遇到項目周期超過三個周的項目，最後是拆分叠代版本，每個叠代都有一個輸出成果，同時對每個叠代的輸出成果單獨測試。對每個叠代的測試bug，只修復嚴重問題，其他問題可以在項目後續開發中修正或者在整體的bug修復時間進行修復。

五、上線

最後進行到項目交付前的臨門一腳，涉及到項目上線，最重要的是梳理上線流程，包括依賴方的上線，梳理各個服務提供方的上線順序，發送郵件通知大家。另外一個重要的事情是各個環節都要有相應的回滾策略，甚至是依賴鏈的回滾。對於大的變動，測試基本結束後，在團隊內部發起捉蟲體驗，每發現一個bug可以給與一定的獎勵。項目上線和線上回歸時間盡量在一天內完成。關於上線的註意事項羅列如下：

1. 梳理上線流程，建議在上線前兩天討論
2. 各環節確認回滾流程
3. 大版本建議團隊內部發起捉蟲
4. 無依賴上線+回歸建議1天
5. 同一個項目最好在1天內完成，否則拆分成多個獨立模塊單獨上線

六、最後

項目上線完記得請客吃飯！！！

不加班的項目從排期開始