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

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

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

一、梳理時間分佈

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

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天內完成，否則拆分成多個獨立模組單獨上線

六、最後

專案上線完記得請客吃飯！！！