第二系統效應 在公司內，我曾參與許多「棘手」的專案，有些專案是因為技術難度高，有些則是domain的整合複雜，有些則是跨單位協作的問題，專案之所以棘手，原因很多種，而今天我想跟各位談談另一種「棘手」，那就是「第二系統效應」所衍生的問題。 根據維基的定義： 第二系統效應（英語：second-system effect），又稱第二系統症候群（英語： second-system syndrome），由佛瑞德·布魯克斯在《人月神話》中提出的經驗概括。它認為，在完成一個小型、優雅而成功的系統之後，人們傾向於對下一個計畫有過度的期待，可能因此建造出一個巨大、有各種特色的怪獸系統。第二系統效應可能造成軟體專案計畫過度設計，產生太多變數，過度複雜，無法達成期待，並因而失敗。 當我們累積愈來愈多的專案經驗，我們會愈來愈懂得避開風險、預先考量，我們會說：「之前做的系統中碰到了A、B、C三個問題，這次做的系統應該要把這些問題給考量進去。」，或者說：「根據之前的經驗，這個系統使用一年後會開始碰到什麼樣的問題，所以我們應該預先考量，並保留該功能以因應一年後的狀況。」，更常聽到的說法是：「這些地方應該保留彈性，以做為後續擴充之用，至於要擴充什麼，我也還不能肯定，但留著一定有用。」…… 因為我們吸收了幾個系統或者產品的開發經驗，我們會開始期望做出一個完美的成品，這個成品不應該有之前碰到的那些問題，而且能具備所有完整的功能，殊不知，這通常超出了當前專案的範疇，這是一個鍍金的行為。 那些額外的影響 從上頭的論點中，我們看到的是屬於專案鍍金的問題，但第二系統效應在企業內，造成的問題並不僅僅是鍍金而已，鍍金所造成的問題，往往是範疇的蔓延與無止盡的時程延展，但第二系統效應則可能讓專案連啟動都困難。 我曾參與一個「複雜」且「棘手」的專案，在我第一次參與這個專案的會議時，我也深刻的感受到這個專案的難處，這個專案並非首次啟動，在過去它曾經啟動過幾次，同時也失敗了幾次，這是一個含括10餘個資訊系統的內部系統整合專案，在啟動會議上，我聽到了以下的建議： 「跨了10多個系統，彼此用不同的程式語言與資料庫。」 「系統與系統間的流程，有許多需要進行資料拋轉的地方，但整合兩端的資料長度可能是不同的。」 「系統與系統間的流程接合，還沒有被完整的定義，需要逐一疏理。」 「每個系統有自己的帳號與會員管理機制，帳號、權限等並沒有統一。」 「這些系統的用戶對象都不同，但希望讓所有人能一同協作。」 「根據過去經驗，我建議保留多國語言的特性，而且最好能同時接AD跟Facebook／微博等第三方驗證機制。」 「這些系統有些是web，有些不是，但希望儘量讓使用者面對單一介面就好。」 「最好瀏覽器與跨裝置。」 「…….」 以上這些討論都非常的有建設性，也都是大家的經驗結晶，但我在討論過程中，我已大概知道過去幾次失敗的原因，我舉手並提出了我的疑問：「根據過去的估算，這個專案的總體工作量有多少？」。 前任PM回答我：「約莫60多個人／月，共分4個階段實作，但這僅僅是完成既有功能的重整，並不包含以上特殊功能的強化，若全部包含，估計將會膨脹到150多個人／月，而且這專案中的幾個困難點一直都沒有恰當的解決方法。」 我接著問：「這些困難點分別是什麼？會讓專案無法進行下去嗎？」，前任PM回答：「難點一是A提的，根據A的說法，他是說這個問題如果要解決，要不就一步到位做完，要不然就不要做，而一步到位的做法需要花費他5個人／月的時間；難點二則是B提出，他說web系統跟non-web系統間的整合可能要重寫全部的程式，一來效能會比較好，二來也避免維護兩份code，但要改寫整個系統他需要先從系統的功能回推完整的規格，才能動手，初步估計就需要10個人／月。」 經過一番討論，我大概了解了過去幾次專案總是在前期討論時便以失敗作收的原因，我最後歸因為「自己嚇自己」，系統本身的複雜度雖然高，但真正阻礙專案推動的反而是我們自己，我們為專案加了許多額外的期望，讓專案的複雜度與工作量以倍數的增長，針對這點，我們可以看出一些端倪，專案原始的需求只是一小塊，但因為加了額外需求、開發者的經驗並保留較多的擴充彈性後，專案最終的需求比原始需求多了數倍，而所需投入的資源自然也同步增長了。 當一個專案從60個人／月，膨脹到150個人／月，同時又浮現了許多的困難點，負責該專案的PM在對sponsor提報專案預算時通常會被要求要作完善的plan，而這個plan通常一做就是三個月半年，等到真正要啟動時，專案的工作量可能又膨脹到180個人／月，因為過程中又加入了許多老闆的經驗與期待，而這部分又要進行re-plan的動作，這個專案就在這樣的無窮迴圈中不斷遞迴，最終這個專案便僅停留在plan，而沒有進入do的階段。 找出關鍵問題，定義目標，收斂需求 其實上頭的專案，跟平常我們接觸的專案並沒有太大的差異，第二系統效應發生的原因是對系統有過度的期望，而杜絕第二系統效應的方法便是PMP知識領域中的「範疇管理」（Scope Management），範疇管理中清楚的告訴我們只做專案計畫內的工作，在專案之外的事情不該做，而在定範疇前，我們一般要先釐清我們的關鍵問題，先把我們優先要解決的問題找出來，並以解決此關鍵問題為主要目標，其他的問題應該先列為次要目標，並將資源投入在達成主要目標上頭，而這個主要與次要目標，便是我們階段性專案的範疇了。 在上述專案中，我們重新定義我們的關鍵問題，將資訊不一致、操作體驗不佳視為關鍵問題，並將資訊不錯漏以及提高用戶體驗當成專案的主要目標，所有的專案工作則依此目標展開，其他的建議則當成後續改進的參考，但不急著納入專案任務中，如此一來專案的範疇便可被清楚的定義，專案工作也能順利展開了。 後記 這個專案在重新定義問題與目標後，被切分成兩個階段，專案不再過度龐大與複雜，總體工作量僅有先前規劃的一半不到，而成員也在這樣的規劃下找到了方向，並重拾信心。 這篇藉第二系統效應來談範疇的管理，相信很多公司內都有這樣的狀況在發生，碰到此類專案時，只要先將專案的關鍵問題定義清楚，並把範疇確認下來，專案就成功了一半了，剩下的就是我們如何管理專案了。