消除嘗試交付所有功能的迷思

 專案的時程安排，有時對一些開發團隊來說，並不是一件那麼容易的事情。而我們在專案的時程安排上，時常會遭遇到困難，我覺得起碼是因為兩個因素所造成的。首先，我們擔心時程的延誤是因為開發人員不夠認真所造成的，其次，我們覺得準時交付「所有」功能是絕對不容改變的原則。

就第一點來看，開發人員可不可能沒有百分之百的投入工作呢？當然有可能，他可能是因為正處於低潮、缺乏工作的情緒，也可能身體不適，或單純的只是想偷點懶休息一下。我覺得你要關心的，並不是在一個很的短時間之內的生產力，應該關心的是在足夠長的時間區段中，他是否能夠提供相較穩定且合理的生產力。因為每個人的生產力都不是固定維持不變的，開發者是人，而非機器，狀況難免有時好、有時不好，只要他的生產力平均起來夠好，而且變異的程度不會太大就好。

當然，也一定存在那種長期無法提供足夠生產力、或是根本就是無心在開發工作上的人。對於此類的開發人員，如果是遇到需要協助的困難，應該著手的是協助他解決困難，而不是看著他持續發生延遲。若是的確無法改善，甚至是天性就不願意貢獻在工作上，那麼應該做的決定是請他離開團隊，而不是訂出一些規範來監管他的工作進度。因為你不需要因為特定不值得投資的人員，而讓整個團隊一起付出額外的負擔。

了解無法跟上開發進度的原因
觀察每個開發人員的進度，是為了明白開發人員是否有遭遇到困難，以便提供必要的協助。困難有可能發生在開發人員本身的生理，或是心理之上，也有可能是工作本身的內容。

在前文中我們有提到對工作時程的計算，估算能比較準確的程度大概是數量級的層級上，例如幾分鐘、幾小時、幾天、幾週等等。倘若開發人員的誤差已經出現了在數量級的差距時，例如，估計需要幾小時，卻要幾天才能完成的情況時，那麼就有必要介入了解原因。

通常，如果只是單純開發人員短期間內的「自我調適型的休息（其實就是小小的偷懶一下啦）」，那麼被關心之後，都會自我振作一下，以彌補之前的落後。至於被關心之後，還依然沒有改變跡象的人員，就應該考慮進一步深談，或之後的處置了。

被歸類需要一週的功能，例如估計需要一週，結果花了一週半，所造的具體影響應該是不會太多，但即使估計時間小到一天的功能，卻花了三天才完成，這代表有事情需要檢討：是不是數量級的估算錯了，或是程式設計者沒有火力全開，還是存在其他的困難需要幫助。

若是程式設計者沒有全力以赴，對問題的檢討會促使他受到督促，因而在之後有機會修改。如果時間允許彈性，非得百分百如期，而在相信程式設計者必然全力以赴的情況下，程式設計者多半不會想作假。

更務實、精準地控制開發的時程

假設開發人員都能在有自我紀律的情況下，其實在時程上，接下來要面臨的其實是「預測和實際執行不符」的問題。而這反映的只是「工作的本質就是這樣，需要這麼多時間就是需要這麼多時間，只不過我們預測錯了而己」。

不過有些人看不開這點，因為他們覺得不論如何，你就是得符合時間才行。可是，這些人沒有想通，生一個小孩需要懷孕四十週的時間，即使你再怎麼預測，它的時間本質就是四十週（除非不成熟的早產），是不會因為你如何做預測而有任何的改變，開發工作也是這樣。

有位朋友的開發團隊在開發的時程控制上，基本上是採用「盡最大努力（Best Effort）」的原則。也就是說，他們信任每個開發人員，都會盡他們的最大努力（當然是平均上來說）在開發工作，所以，他們基本上只決定要完成的工作的先後順序，「事情需要多少時間就是需要多少」，在固定的時間點上，能完成多少就是多少。

不過如果完全只有「盡最大努力」的原則，會讓時間因子整個消失，這會產生一個困難，也就是你沒有辦法預估某個時間點上會有什麼功能產出。

軟體開發很多時候都避不開具體的時間點：做客製服務的開發專案，客戶會有系統上線的時間要求；做自有產品，也會有公司希望發行的時間。有些時間點就是牢不可動的，例如，某個參展的時間點就是一個絕對不容改變的時間，而且，也確定你勢必要有產品參展。所以，對時間做出預測在所難免，關鍵是如何避掉因為排程所導致的時間流失，以及當預測的確失準太多時，應該如何處置。

當每個人都是「盡最大努力」來完成一個工作時，一個工作需要多少時間就需要多少時間。但工作的排程顯然會時間運用上的效率，因為專案的工作大多並不是由單一個人員循序的在執行著，而是交由多人同時平行進行。因此，工作的排程絕對會影響到時間運用上的效率，像是均勻地將工作分配給每個人之類的。尤其重要的是，工作之間會有相依性，一個工作的完成與否會影響另一個工作是否可以開始進行。

如何做工作排程是另一個很大的議題，在此並不會討論到，但是，基於工作的相依性，在工作的排程上會出現關鍵路徑（critical path），在這個路徑上的工作是最需要被關心的，因為，關鍵路徑上的工作，若是發生了實際執行時間與預期不同的情況時，就會直接影響到整個專案的完成時間。

也就是說，不是在關鍵路徑上的工作，只要不會因為其發生「延遲」而使得它反而成為關鍵路徑中的工作之一的話，其完成時間常常不會影響到整個專案的完成時間。我們其實不太需要放太多心力在它們，因為它們只要沒有太誇張的「延遲」，根本無關大局。

思考所需開發功能的必要性
軟體開發工作需要多少時間就是需要多少時間，而遇上時間點不可更動的情況時，時間到就必須交付、發行軟體。若是無法完成所有的功能時，大多數情況下，你可以控制的因子就是要交付的功能，你必須要認清這個現實。一旦你可以認清這個現實之後，你自然會開始思考，有那些功能是「必須有（must have）」，以及那些功能是「有了加分（nice to have）」的。

我們的產品是靠「必須有」的功能，博得使用者的歡心，利用「有了加分」的功能來為軟體錦上添花，或使其完備。當時間截止時，軟體有一堆「有了加分」的功能，卻少了一個「必須有」的功能，其實是比所有的「必須有」的功能都齊備，但少了一些「有了加分」的功能來得嚴重許多。

所以在規畫時──無論是一開始的規畫，或是開發過程中的功能調整，都必須清楚意識到某個特定的功能究竟是「必須有」或是「有了加分」。

「有了加分」的功能是我們在時程預期與實際有所落差，而專案時間也受到影響會被拿來調整的部份。簡單的說，開發時間若是不夠，「有了加分」的功能就會被犧牲。我們的底線是所有「必須有」的功能在發行時一定要都齊全，而「有了加分」的功能，則視情況完成。

所以，在你的專案中最需要關心的，就是那一種「必須有」、而且實作起來困難的功能。因為它們在交付發行時是一定要被完成，但是因為它們的本質困難，所以完成時間預測準度會比較低，這使得它們充滿風險。

對專案的管理人員來說，需要站在更高的點上來檢視專案的進行情況，你需要分出什麼是關鍵的（像是必須要有、但實作困難的功能）？什麼是不關鍵的工作？然後，把大多數心力放在那些關鍵的工作，並且在風險發生或時間預估不準時，捨棄不那麼關鍵的工作來成就關鍵的工作。