不加班的項目從排期開始

什麼是合理的開發排期？我我的覺得合理的開發排期是一個項目不延期，少加班的時間管理。

在目前接觸的各類項目開發中，開始時以爲時間很充足，可是後面作着作着，就變成苦逼開發加班加點趕工期，甚至項目延期。不只僅是畢業兩三年的同窗，甚至有工做近十年的老司機，也會常常遇到這種狀況。出現這種狀況你們很天然的想到是由於項目過程當中各類不肯定的事情發生，致使本來預感足夠的時間變得緊張起來。因此在項目進行的前期，做爲開發須要給本身定一個合理的開發排期。

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

1、梳理時間分佈

做爲主要工做，理想的狀況下一天的時間都應該花費在需求研發上，可是各類事情的插入，甚至開發本身的心情變化都會影響需求研發的進度。根據咱們團隊的工做事項，總結下來研發同窗平常的時間主要花費如下幾個方面：

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

能夠說大多數狀況下，一個項目的工期進度，受到研發同窗在這些維度上的時間分配影響。假設需求研發按照八小時來分配，那麼隨着其餘維度的時間消耗，基本上在工做上的時間要花費是十一個小時左右，而對於在技術和管理中並行的同窗，恐怕研發外的事務花費時間更多。同時須要在各個維度上進行思惟的切換，這部分切換的時間按照0.5小時來算，那麼在工做上的時間基本要達到十二個小時。算上通勤、吃飯、午休，基本要消耗十六個小時。一氣呵成，再而衰，三而竭。長此以往對項目形成嚴重的風險，對團隊管理亦帶來沉重負擔。

要作合理的開發排期，第一步是要摸清楚本身天天的時間分佈，而後按照本身的有效研發時間來對項目需求估算工期。打個比方若是開發同窗真正的有效率的開發時間是6個小時左右。那麼在新的項目中，就以六個小時的開發時間來估算工做量的消耗時間，從而估算出項目的開發週期。

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

因此作合理排期相當重要一步： 以實際（天天）需求研發時間來估算開發週期

2、預留buffer

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

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

3、管理依賴

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

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

對於第二條要特別重視，不少狀況下在項目排期時容易忽略聯調時間，想固然覺得依賴項在這個時間點給出的是一個穩定的輸出。致使後期發現問題反覆溝通修復，延誤項目進度。

4、測試與複查

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

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

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

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

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

5、上線

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

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

6、最後

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