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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

專欄作者


熱門新聞

Advertisement