一般情況下，開發一個產品，可以分解爲：①需求確認；②原型設計；③UI設計；④程序開發；⑤測試&驗收；⑥上線，這幾個步驟。
我目前討論的項目開發週期，僅僅是站在一枚程序猿的角度，也僅僅只是評估第四步驟（程序開發）。
由於我在公司接手了一個半外包的項目，給xx保險公司做saas系統，這是一個已經運行了兩年的系統，但是他們不時就提需求變更，我目前已經做了四五次需求變更。每次需求變更最讓我頭疼的首先就是開發週期的評估。評估時間短了吧，開發就會非常趕，而且我們就會吃虧；評估時間長了吧，他們公司也有開發人員，會說我們坑人。那如何才能做到一個好的開發週期的評估呢？
謹記：開發週期並不是拍腦袋想出來的，必須是有理有據計算出來的。
我們可以按照如下步驟進行開發週期的評估：
1、當他們提交了需求變更後，首先要做的就是確認需求
把概念不清楚的、邏輯業務不清楚的都要理清，這對我們開發而言非常重要。這個步驟可以和公司的需求人員，以及第三方的業務人員（客戶方）一起討論。理清需求後，還有一點很重要，就是標記哪些需求是難點；
2、把需求整理成接口
我們現在的服務都是提供的RESTful接口，服務與服務之間都是通過接口進行關聯，前後端也是通過接口進行數據交互的。例如我們可以做成如下的表格：
注意：每個接口的開發時間，應該是正常情況下可以做完的時間。個人建議爲大於等於1的整數。千萬不要說，這個小功能很簡單，我10分鐘就搞定了，要知道“世界上沒有什麼需求是簡單的”，雖說你真的可能只要10分鐘，但是也請寫一天。萬一別人問，你就說我要上線、打包、發佈、測試，這都是時間啊。
| 編號 | 接口名稱 | 描述 | 狀態 | 難點 | 開發時間（人天） |
|---|---|---|---|---|---|
| 1 | xxxxx | xxxx | 新開發 | 是 | 5 |
| 2 | xxxxx | xxxx | 修改 | 否 | 3 |
| 3 | xxxxx | xxxx | 新開發 | 否 | 2 |
| 初步合計 | 10 |
3、由初步合計時間，得出最終時間
情況1： 如果你覺得此次開發難度不是特別大，初步合計時間已經足夠了，那請把初步合計時間 乘以1.2得出最終時間，不要問我爲什麼，最少必須乘以1.2，這是機動時間，這是“救命的時間”，萬一你出現一個你意想不到的問題、萬一開發過程中你負責的別的服務出了點小問題耽誤了時間、萬一你開發週期內生病了2天…
千萬不要說沒有這些萬一，如果你開發截至時間到了，你去找理由，你說我生病耽誤了兩天，你覺得合適嗎？別人公司領導已經和下面的人說了，xx日期後就會增加這個功能。然後時間到了，領導去和員工說，“我們外包的開發這幾天肚子疼，耽誤了兩天，上線推遲兩天”，你覺得合適嗎？更何況，這些需求變更都是要簽訂合同的，違約可是要罰錢的。
情況2： 如果你覺得此次開發有些難度，可能會出現未知的問題，那請把初步合計時間 乘以1.5
情況3： 如果我們的客戶是那種類似銀行企業的大客戶，這些大客戶對開發週期要求特別嚴格，一旦違約將面臨巨大的罰款，而且他們不缺錢，那請把初步合計時間 乘以2
4、把最終時間合理分配到各個接口的開發時間中
下面以乘以1.5爲例：
| 編號 | 接口名稱 | 描述 | 狀態 | 難點 | 開發時間（人天） |
|---|---|---|---|---|---|
| 1 | xxxxx | xxxx | 新開發 | 是 | 5 |
| 2 | xxxxx | xxxx | 修改 | 否 | 3 |
| 3 | xxxxx | xxxx | 新開發 | 否 | 2 |
| 初步合計 | 10 | ||||
| 最終時間 | 15 |
但是我們不要把中間步驟告訴客戶，更不要把初步合計告訴客戶，我們給客戶的時間統計如下：
| 編號 | 接口名稱 | 描述 | 狀態 | 難點 | 開發時間（人天） |
|---|---|---|---|---|---|
| 1 | xxxxx | xxxx | 新開發 | 是 | 7 |
| 2 | xxxxx | xxxx | 修改 | 否 | 4 |
| 3 | xxxxx | xxxx | 新開發 | 否 | 4 |
| 合計 | 15 |
在上面的過程中，如果得出的最終時間比較大，很難做到“神不知鬼不覺”，我們還可以多想一想，看看除了上述接口還有什麼是可以考慮，這些東西可能不是接口，只是要做一些小小的改動。都可以寫出來，並且加上開發時間，例如連寫個sql腳本，都可以寫“調整數據庫表結構，2天”。總之，一定要讓人看起來覺得還算是合理。
如果最終的開發週期提交上去，別人說，你這時間太長了吧，這麼簡單的功能也要做4天？你不用說太多話，直接丟一句“你行你上啊”。他肯定不會說他來的，因爲他熟悉項目也是需要時間的。
我們程序員其實是弱勢羣體，一旦在自己寫的開發週期內沒有完成，客戶、產品經理、上司，都只會去責怪我們程序員，纔不會去理解我們的“藉口”，“自己規定的時間，自己都完不成！”。但是我們程序員在開發的時候，不可能只做你那一件事啊，我們可能同時負責好幾個項目，例如我就同時負責7件事，任何一個服務出了問題，我都要去檢查：問題重現、測試是否是bug、檢查日誌、分析問題、甚至是上hotfix版本，這些看似簡單的操作，通常一耽誤就是大半天。
在預估計時間上乘以1.2或者乘以1.5，絕對是有必要的。如果產品經理、或者程序員的上司看到這篇文章，也請理解我們。