專案delay常見的11個原因

我們家PM常常說：
「怎麼會有這種客戶阿～！（抱頭）」、「我的案子好像都做不完」、「我是不是不適合當PM」.....之類的話。一般都是因為規格變更、進度delay、維運案出包，以下討論進度delay最常見的原因：

因為這本書只有英文版跟簡體版，那我覺得簡體版翻得不是很夠味道，所以以下是以我自己的話來翻譯。

摘自Making it Big in Software: Get the Job. Work the Org. Become Great 

 Ch.13 避免開發時程延後 AVOIDING SOFTWARE DEVELOPMENT OVERRUNS

在繼續讀下去之前，先瞭解一個有趣的數據：

大部分的案子實際完成時間都會超過預計的84％，而且大約只有1/3的案子是如期完成的 


瞎米，這不就符合80/20法則嗎！我們常常遇到案子做不完火燒屁股的情形，但是有沒有想過是什麼原因造成delay的呢？下面列出了常見的原因和解決辦法：

1.不知道要做到什麼程度  

   就算一開始規劃了某項功能，在實做的時候也常發生一些細節規劃得不夠縝密的情形，這樣就會變成某項功能越寫越深。不管是PM還是工程師都很容易說服自己：「我不想推出一個垃圾產品。」由於功能變強了，所以在寫規格書、設計、實作和測試上的工作量也就會增加，在進度上面也就不得不delay。所以囉， 要成為一個值得信賴的合作夥伴，光是要理解案子的功能需求是不夠的，團隊成員還需要知道「足夠」的邊界在哪，或者是「以現在來說做到什麼程度就夠了」。

2. 千里馬很重要  

    優秀的程式設計師跟肉腳的程式設計師，之間的開發速度最多可差到5～28倍。例如在相關領域寫了十年code的人，他在設計和實作上面的速度就遠遠高於那些新進入或還在學習的人，5個優秀的工程師可以勝過50個水平一般的工程師。增加人力增加或加班會反映在成本上，但是增加多少預算沒辦法保證會增加幾趴進度，專案進度跟投入成本之間的關係並不是線性的。

3.對已經delay的專案增加人手，只是提油救火

      簡單翻譯：因為要多花時間教新人，會額外浪費原本人員的時間

      我自己的想法：要看案例，如果是彼此都是寫一樣的語言，又都遵從相同的coding style，彼此compomtent 都可以切開來寫的話，其實加人進來是絕對有用的。

4.開發團隊對目標不明確

    簡單翻譯：回到第一點，不知道要做到什麼程度，自以為完成需要的功能，但實際上市場要的更多，或者你做的東西已經是對手產品的基本款，簡單說就是：「做了、但沒做好。」

5.把每個feature 所需時間加總起來變成全部工時

    忘記算各個component合併時測試、修改的時間

6. 時間估錯 （應從比例來算全部完成時間）

    這是最常犯的錯誤，你知我知獨眼龍也知：工程師很不會估時程，他們對於要花多久時間的判斷力是很弱的，這邊有一個好方法來預估整個軟體開發時程，就是把實際寫code的時間 X 6，，依經驗法則來看，事情是這樣的：1/3 時間用於寫規格書(io document)和設計資料架構(data model) ，這邊都是紙筆作業 ，1/6 用在實作，1/4 用在功能測試還有和其他元件的整合測試，1/4 用在系統測試。這招在過去30年已經被證實是適用的，雖然大部分的人（老闆、有頭銜MBA的主管、甚至連工程師自己）都不願意相信測試會花到整體時間的一半，但事實證明真的會花到這麼多。

7.ok 啦這個很簡單

   時程亂估，在還沒有開始做之前就埋下了必定做不完的伏筆。

8.怪我囉！ 的心態產生

   在大型專案裡才有這種問題，書上的例子是200個人參與同一個計畫，進度已經delay了，但有蠻多人都認為自己不是造成進度delay的原凶，都在等別人生出一些東西自己才開始寫。

9.不遵從軟體工程的設計規範來走

    不規劃不測試不code review、恣意奔放的寫，有洞補洞，沒有data model，用一堆if else來判斷。 我沒看過這種公司，事實上也不應該會有這種做事態度的人出現。太誇張，用寫作業的心態來開發一個案子，這寫出來的東西簡直是垃圾。

10.忘了考慮員工作其他事情的時間

     像是準備資料、開會、maintain 之前案子、休假之類的，大多數公司，工程師大概有25％的時間在做這些事情。

11.時勢所趨

      市場不需要這個產品，必須砍掉重練重新規劃。會走到這一步都是因為計畫拖太久，或者做好以後一直在找適合推出的時機點，但是一直找不到，所以只好整個案子放棄。

     建議是把一個產品的開發時程設定1～6個月，用敏捷式開發，火速做出一個產品、市場喜歡的話再把需要的功能補上。

我想自己加上第12點

12.規格變更但是時程沒有變
     當初我還年幼無知的時候，朦朦懂懂只看了一本人月神話，跟PM合作的前幾個案子，有時候會發生規格變更但是客戶認為這個很簡單咻一下就可以改好了，殊不知那需要改到data model，然後data model又會影響到View的樣貌，View上面又有很多互相影響的東西....。牽一髮而動全身，最慘的是單看某幾個頁面會覺得這樣修正是對的，但是格局放到整個案子來看發現是彼此衝突的，那就必須傷筋動骨，一兩天是絕對沒辦法完成的。也發生過開發時間太長，第三方的API規格都換掉了，像之前就發生過新浪微博認證從OAuth1.0變成OAuth2.0要重寫的慘案。

＝＝＝＝＝＝＝

小小的讀書心得：
這本書每一章後面都還有一篇資訊業界前輩的專訪，是那些聽到名字會發白光到眼睛看不見的那些人，像是最近Yahoo的CEO、Linux的發明人、微軟的研發大頭、自由軟體開發者先驅，問他們「你是怎麼開始寫程式的」、「在這一行裡有什麼事讓你覺得很煩的」、「你如何平衡工作與生活」、「你覺得未來10～15年會有什麼變化」，他們的回答都蠻實用的，適合在煩心的時候拿出來看一看，看過大師怎麼解決問題之後就會覺得自己的問題簡直就是個屁。