為何該少用SF (Start to Finish)

很久沒寫技術性的文章了,所以來這麼一篇,談個重要的概念!

-------
有人曾經跟我說SF很好用,可以用來承接一個固定的里程碑。 比方說「開店」、「驗收」、「上市」,並以此來反推前續活動的開始時間。 比方說如下圖:

SF的範例

換言之,他先用Constrain訂出一個上市日,並用SF的關係連結前續的軟體測試,並讓系統幫你排程出軟體測試的開始時間。


這聽起來還滿美妙的不是嗎?

但為何我會建議你不要用呢?

 

事實上應該也不只我。 你若去上PMP之類的課程時,老師也都會「照本宣科」的跟你講這關係式該少用。 但恐怕理由上每個就都講得含含糊糊,甚至很多老師根本沒有排程的經驗或能力,答不出原因來。 那我這篇就要告訴你,為何這關係式雖然在邏輯上成立、但實務上不好用的原因。

 

 

不好用的理由,主要涉及到CPM的排程概念。 首先,SF最大的問題在於它不容易閱讀。 這在網圖複雜時,其實你是在找自己麻煩。

再來,里程碑的前續工作通常不會只有一項。 比方說,「軟體測試」前面通常還有其他工作。 但它們跟「軟體測試」可能都是FS(或是其他關係),這時候排程出來會變類似這樣:

與其他FS的關係中間會有空檔

換言之,在這樣的設定下,你中間可能會出現有一大段空檔。 當然,可以用此當成專案緩衝的觀察。

這樣做並不是不行,就視覺上來看好像也還好。

可是,真實世界的案子往往比上面的例子更複雜,會有好幾個模組共同開發,最後才會接到測試這工作。

結構複雜時更難看懂

如上圖,你有三個模組,中間都有對應的開發工作,完成後接到最後那個被SF牽制住的測試工作。

這時候你就會發現,專案進行中要監控緩衝就麻煩了。 當然,也還是有辦法,就是進行中監控Free Float,但視覺上會較難看出來緩衝在多路徑的狀況。 這是因為軟體無法在這種排程結構中正確計算出要徑。 因為中間的每條路徑都有正浮時(就算你用最長路徑也是一樣),所以除了最後兩個工作以外 其他都會變成不是要徑。 這不就更增加自己開始後追蹤的困難度?

再來,會想用SF的概念的人,通常的意思,其實是想要說「軟體測試」是個有點Buffer味道可長可短的工作。 所以其實這工作很可能不是一個固定時間,而是如果有多那中間空檔其實都是可以用來做測試;但如果時間不夠,測試時間可能也可以盡可能壓縮。

但別忘了,測試就算可以縮短,終究還是需要時間的。 如果前續的工作真的把這段空檔都填滿了,SF+里程碑的設定就會跑出另一個嚴重的副作用。 如下圖所示:

里程碑其實不會被前置工作推延

在這樣的設計下,請注意喔「如果專案排程因為意外超過原定時間,那你的里程碑工作將會被卡住!」

要強調的是,並非因為我用了Mandatory Finish等強制的限制式。 因為就算你用的是Finish on、或Finish no early than這類軟性限制(事實上我上面是這樣設定的)也是會有相同結果!

原因為何? 這是因為這個里程碑其實在排程中是沒有前置任務的,所以排程Delay時,別人是無法推動到它 (這段很關鍵喔,請仔細想想我解釋的這一個概念) 所以,當你專案進度有落差時,這規劃又更加深自己控制的困難度。

 

好,那可能有人會問,如果我個人要在專案中規畫類似的概念時,又會怎麼做呢?

我自己大概會用兩種做法,大家可以參考看看。

A. 假設這工作有最小工期

那我會完全不用SF,而是把所有工作的順序全設成FS。

專案進行中,我會用Total Float來監控緩衝。 里程碑我也不會設定限制式,這樣我可以視覺化的看到目前預估里程碑的達成日,以及原始計畫(Baseline)中里程碑的達成日。

如下圖(黑色菱形是目前預估的完成日;黃色菱形是原始計畫的達成日):

全用FS的狀況

在這設定下,要徑會正常計算,里程碑也會附掛在整段流程的尾端。 如果有工作Delay,里程碑會往後推;如果要徑提早,則里程碑會往前移。 紅色是要徑工作。


B. 假設這工作沒有最小工期

甚麼叫做工作沒有最小工期? 表示這是一個可長可短的工作,時間多就做久一點;時間少就機動調整。 比方說開幕日之前的整理與打掃,這可能就有點類似這樣的味道。

如果是這種類型的工作,我會設成一個「吊床作業」(Hammock Activity)。 (不知道吊床作業的可以去Wiki查)。 吊床作業可以反映專案的Delay,並機動調整本身的工期長短。 這就可以方便的反映出這種類型的規劃。

用Hammock的狀況
(上圖,原始計畫下軟體測試的工期)

0107
(上圖,其中一條要徑Delay下,軟體測試這工作的工期就自動縮短了。)


所以因為有這些副作用,所以我個人不使用SF,也幾乎不建議任何人用SF。

而且,一個好的Schedule並非是用了很多特別的功能、限制式、或是邏輯關係才叫厲害。 真正Schedule厲害的人,其實反而是能化繁為簡,只把關鍵心力放在重要的事情上。

所以不需要為了顯示自己很懂邏輯關係,硬要設定一些麻煩的東西。 那不會讓自己變得厲害,而只會讓自己之後很麻煩的!

覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

Joe G+ ICON Joe LInkin ICON

1 則讀友回應

  1. wenson 2011-08-29 15:54:36 第 1 則

    說真的,這個問題也曾困擾我很久....

    提另一個實務上的情形:捷運潛盾隧道
    常見的情形是,因為潛盾機這種資源很貴
    所以必須完成一段隧道後再移到另一段隧道施作
    相對的,另一段隧道的投入口的完成時間
    如能配合前一段隧道完成的時間完成
    那就是just make了

    請問J大,在這種情形下,您會建議用SF? FF? 還是FS?

    • Joe Chang 2011-08-29 17:02:37

      我個人會傾向用FF呢
      前段隧道的完成連結到下一段投入口 (FF)
      然後投入口跟前段隧道連結到下段隧道的開挖(FS)

      這恐怕是最能滿足所有後續變動的設定方法