很久沒寫技術性的文章了，所以來這麼一篇，談個重要的概念！
-------
有人曾經跟我說SF很好用，可以用來承接一個固定的里程碑。 比方說「開店」、「驗收」、「上市」，並以此來反推前續活動的開始時間。 比方說如下圖：
換言之，他先用Constrain訂出一個上市日，並用SF的關係連結前續的軟體測試，並讓系統幫你排程出軟體測試的開始時間。
這聽起來還滿美妙的不是嗎？
但為何我會建議你不要用呢？
事實上應該也不只我。 你若去上PMP之類的課程時，老師也都會「照本宣科」的跟你講這關係式該少用。 但恐怕理由上每個就都講得含含糊糊，甚至很多老師根本沒有排程的經驗或能力，答不出原因來。 那我這篇就要告訴你，為何這關係式雖然在邏輯上成立、但實務上不好用的原因。
不好用的理由，主要涉及到CPM的排程概念。 首先，SF最大的問題在於它不容易閱讀。 這在網圖複雜時，其實你是在找自己麻煩。
再來，里程碑的前續工作通常不會只有一項。 比方說，「軟體測試」前面通常還有其他工作。 但它們跟「軟體測試」可能都是FS(或是其他關係)，這時候排程出來會變類似這樣：
換言之，在這樣的設定下，你中間可能會出現有一大段空檔。 當然，可以用此當成專案緩衝的觀察。
這樣做並不是不行，就視覺上來看好像也還好。
可是，真實世界的案子往往比上面的例子更複雜，會有好幾個模組共同開發，最後才會接到測試這工作。
如上圖，你有三個模組，中間都有對應的開發工作，完成後接到最後那個被SF牽制住的測試工作。
這時候你就會發現，專案進行中要監控緩衝就麻煩了。 當然，也還是有辦法，就是進行中監控Free Float，但視覺上會較難看出來緩衝在多路徑的狀況。 這是因為軟體無法在這種排程結構中正確計算出要徑。 因為中間的每條路徑都有正浮時(就算你用最長路徑也是一樣)，所以除了最後兩個工作以外 其他都會變成不是要徑。 這不就更增加自己開始後追蹤的困難度？
再來，會想用SF的概念的人，通常的意思，其實是想要說「軟體測試」是個有點Buffer味道可長可短的工作。 所以其實這工作很可能不是一個固定時間，而是如果有多那中間空檔其實都是可以用來做測試；但如果時間不夠，測試時間可能也可以盡可能壓縮。
但別忘了，測試就算可以縮短，終究還是需要時間的。 如果前續的工作真的把這段空檔都填滿了，SF+里程碑的設定就會跑出另一個嚴重的副作用。 如下圖所示：
在這樣的設計下，請注意喔「如果專案排程因為意外超過原定時間，那你的里程碑工作將會被卡住！」
要強調的是，並非因為我用了Mandatory Finish等強制的限制式。 因為就算你用的是Finish on、或Finish no early than這類軟性限制(事實上我上面是這樣設定的)也是會有相同結果！
原因為何？ 這是因為這個里程碑其實在排程中是沒有前置任務的，所以排程Delay時，別人是無法推動到它。 (這段很關鍵喔，請仔細想想我解釋的這一個概念) 所以，當你專案進度有落差時，這規劃又更加深自己控制的困難度。
好，那可能有人會問，如果我個人要在專案中規畫類似的概念時，又會怎麼做呢？
我自己大概會用兩種做法，大家可以參考看看。
A. 假設這工作有最小工期
那我會完全不用SF，而是把所有工作的順序全設成FS。
專案進行中，我會用Total Float來監控緩衝。 里程碑我也不會設定限制式，這樣我可以視覺化的看到目前預估里程碑的達成日，以及原始計畫(Baseline)中里程碑的達成日。
如下圖(黑色菱形是目前預估的完成日；黃色菱形是原始計畫的達成日)：
在這設定下，要徑會正常計算，里程碑也會附掛在整段流程的尾端。 如果有工作Delay，里程碑會往後推；如果要徑提早，則里程碑會往前移。 紅色是要徑工作。
B. 假設這工作沒有最小工期
甚麼叫做工作沒有最小工期？ 表示這是一個可長可短的工作，時間多就做久一點；時間少就機動調整。 比方說開幕日之前的整理與打掃，這可能就有點類似這樣的味道。
如果是這種類型的工作，我會設成一個「吊床作業」(Hammock Activity)。 (不知道吊床作業的可以去Wiki查)。 吊床作業可以反映專案的Delay，並機動調整本身的工期長短。 這就可以方便的反映出這種類型的規劃。
(上圖，原始計畫下軟體測試的工期)
(上圖，其中一條要徑Delay下，軟體測試這工作的工期就自動縮短了。)
所以因為有這些副作用，所以我個人不使用SF，也幾乎不建議任何人用SF。
而且，一個好的Schedule並非是用了很多特別的功能、限制式、或是邏輯關係才叫厲害。 真正Schedule厲害的人，其實反而是能化繁為簡，只把關鍵心力放在重要的事情上。
所以不需要為了顯示自己很懂邏輯關係，硬要設定一些麻煩的東西。 那不會讓自己變得厲害，而只會讓自己之後很麻煩的！
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
