這篇是「公有地的悲劇 」那篇貼出來後公司內部的一些討論。 因為BLOG的讀者無法看到我覺得滿可惜的，所以把當事人匿名後在此轉錄。 有興趣的讀者也可以一起討論。 :)
-----
四月06日
C說:
其實關於這個Life Cycle Cost，在軟體開發也有相同的概念，只是我們叫做total cost ownership, tco。也就是說，大部分的user，會將注意力放在很顯而易見的「購入價格」，所以傾向於買便宜的東西，所以最後可能買了一個軟體，很便宜，但是發現很難擴充、或是不穩定、經常當機，而這些當機的處理成本、損失...連同購入成本，才是所謂的TCO。
這個問題長期以來也困擾著很多企業主，因為很多「專業」雜誌都會大力推薦使用open source的軟體，或是免費軟體，說用了可以省多少錢，卻沒有說明假設的前提(公司的規模、軟體的成本結構...etc)。open source和免費軟體不是不好，對做技術的人而言，說是寶藏也不為過。但是對於企業來說，一方面open source軟體通常不會有付費軟體這麼就手，多半是堪用，但不見得非常好用，要做到跟商業軟體一樣的效果，通常要花較長的時間($)，或是根本沒辦法，最後被迫轉換平台，轉換的成本可能很高；
二方面如果出了問題，沒有廠商在背後支援，企業就需要僱用技術等級較高的技術人員($$$)，才有辦法自行處理問題；
三方面，open source的東西一般來說終端使用者也不熟悉(ex: MS Office v.s. Open Office)，所以公司還要派人教育訓練($$$)。
結果就是，購入價格為0，但是，從TCO的角度，不見得真的省得到錢。所以軟體市場很妙，包括商業軟體、免費軟體，都聲稱他們有最低的TCO。其實雙方都在說謊，也都沒說謊，因為到底哪些成本要被算入TCO，沒有標準。
==超無聊軟體話題結束，更無聊社會學話題開始==
而在社會學裡面，這種自己享用利益，成本卻不全然由自己負擔的狀況，我們會說是「成本外部化」或是「外部成本」。例如你騎機車、開車，路人吸廢氣就是典型的例子。所以「外部成本的內部化(由每個人完全負擔自己應付的成本)」，就一直是重要的課題。例如騎車、開車的人，如果把自己製造的廢氣自己吸進去，那就是外部成本內部化(只不過會死很多人，成本被轉稼給醫療單位，哈哈
)。當所有的成本，都正確的歸到使用該資源的人，那麼根據人類利己的原則，大家的行為，就會符合整體利益。例如，既然一定要吸自己車子製造的廢氣，為了避免死亡，大家就會選擇開電動車，或是根本不開車。
==更無聊社會學話題結束==
上面的理論聽起來可行，做起來卻很難，因為「外部成本」實在很難估計和量化，過於簡化的規範，經常流於不公平，過於繁雜的規劃，又不易實行，再加上還有很多政治問題，所以從來也沒什麼真的非常成功的外部成本內部化的案例。例如燃燒石化燃料產生廢氣，但是花大錢開電動車也不環保啊，因為電也不是憑空生出來的，也是火力、核能、水力發電才有的，廢棄電池也是問題...。或是說一個中低開發程度的國家，連飯都吃不飽了，短期就要餓死了，你去跟他談環保這種遠期目標，也是不可能有結果的。
==超無奈現實結束分隔線==
回到專案，「正常的專案」是有一定的目標、範疇、時間、預算、人力，很多條件都已經被限制住了，因此他不會像解決社會問題一樣會需要扯那麼遠。不過即使如此，要設計出一套能讓大家盡量朝著同一個方向走的獎懲制度，盡量減少將自身成本外部化給整個專案承擔的狀況，都還是不容易的事情。我想這也是專案經理終其一生都要不斷纏鬥的問題吧，不然專案就讓機器去run就好了...
啊，真是一篇好硬、好無聊、又臭又長、又沒建設性、又增加資料備份成本的回文啊(哈，這篇回文本身就是成本外部化的範例)...這樣會不會幫你趕走更多讀者啊
--------
四月 06
L說:
認同案子必須以整體的角度來看，不過有一些有趣的例子也可以跟大家分享一下。
很多時候專案領導人的確是以整體對專案利益最大化的考量下去設定策略，但是操作手法卻容易被誤會， 例子很多，舉三個來看看:
1. 專案研發有時候需要某一個部分先*"長的漂亮"，然後各部分才有一個更收斂的方向去"對齊"*它。
=> 小時候國語課本裡面有這樣的故事: 有一個很髒的人收到一束很漂亮的花，然後他找了一個很髒的花瓶出來放花，然後發現花瓶很髒配不上花，所以把花瓶清乾淨了，後來發現放花瓶的桌子很髒配不上花瓶，然後把桌子清乾淨了，然後又發現房間很髒不配這張桌子.......最後的結果就是一束漂亮的花，讓整體環境都提升了水平。
2. 專案研發就像寫歌或小說一樣，先快速整體做一遍看整個大架構，然後再整體 tune 一遍，不夠滿意再一遍.....一直cycle下去，每個 cycle 有不同的 level of detail，這是對研發案來說最好的開發方式。
=> 所以寫歌的時候會先大致把曲子擬好，然後快速填個rough的詞聽感覺，然後再整體的去一次一次調整。以歌曲製作來說大家都很容易理解，但是變成大專案時因為成本太大或牽涉的人太多，就很容易有其他聲音，很多case並不是不去做細部規劃或為了節省便宜而跳過，而是必須先走到後面看過了整體才有辦法理解現階段精準的需求。
3. 真正面對到客戶的時候，讓客戶慢慢的等你一輪一輪的加detail好，還是拿出一小部分很高 quality 的東西讓對方滿意比較好呢?
=> 我個人的經驗是前者的話客戶會因為信心不夠而不斷下來變更設計導致專案嚴重干擾，後者的話干擾會少很多，但是這個 high quality 的 demo 實際上到最後通常都和最後產品方向不一樣而必須遺棄。所以到底是哪一個方向好很依賴專案領導人判斷的眼光。
以上三個都是先針對部份最佳化以爭取到專案開發最佳條件況的例子，所以有幾個問題可以想想:
- 局部優化真的沒價值嗎?
- 現階段先大致有個框架就先去做後面部份，真的是便宜了事嗎?
- 為了demo 而 demo 真的損害專案開發嗎?
- 專案是不是一定要等所有的條件都到了才能開工? ( 如果東風不來，赤壁之戰東吳就可以不用打了嗎?)
以上問題給大家參考與討論，不過還是要再呼應第一句，專案開發絕對要以整體的利益角度去看待。
------
四月 06
c說:
我大膽猜測一下，L應該是在創意的不可預測性和管理之間被困擾著吧。一直以來，我都是屬於那種沒創意的軟體開發的領域(哈！)，所以以下的看法也許不適用，但至少是我的理解。
我認為，專案管理的精神在於「管理」，而不是告訴我們什麼是對、什麼又是錯的聖經。所以對或不對，有沒有價值，還是留給各領域的專業去判斷，這不是專案管理能夠給我們答案的。專案管理，只是要告訴我們「當初的計畫是如何，現在的狀況又是如何」，然後協助我們去對未來做調整。
要達到這個境界，要做專案管理，就要有讓事情是「可管理的」，即便是很不容易管理的事情，也得努力想辦法去管。很像繞口令...舉例好了。
--局部優化是否沒價值？
專案管理無法回答這個答案，但是如果專案經理覺得有價值，就給他一個優先權，一些繼續執行的前提，或是停止執行的條件，並納入管理。將來如果有一件「看起來也很重要的事情」或是其他狀況出現的時候，才有辦法權衡、做出抉擇。
--為了demo 而 demo 真的損害專案開發嗎?
一樣，沒有任何專案管理可以回答這個問題(賣房子不蓋樣品屋應該不容易賣)，但是如果你認為為了demo這件事情，專案應付出的成本、時間是多少，就應該給他一個數字，這樣當超過這個數字的時候，專案管理人員和工具就可以適時提出警告，讓大家決定是不是該繼續下去。(如果訴求不是豪宅，那花5億去蓋樣品屋就不切實際。而跟老闆說「我不知道蓋樣品屋要花多少錢，蓋完就知道」對設計師而言也許合理，但對老闆來說，也是一樣不切實際。)
--專案是不是一定要等所有的條件都到了才能開工?
有些是，有些不是。但哪些是、哪些不是，還是得照人的判斷。當經過人判定為「必要」之後，那這個條件若沒達到，就是不能開工。(如果東風不來，仗還是得打，就是會輸而已...輸得起就沒差，輸不起的話...東風沒來就是不能開工)
其實最終還是人的判斷啦，專案管理工具，只是幫助我們能夠將每個思考、判斷的結果，一一的記錄下來，當工作很多很複雜的時候，我們不會因為超過人腦的負荷，而憑感覺做出一些違背當初設定的目標的決策。
例如：已知一個專案中有5次demo。
- 沒有管理：這5次要消耗多少預算、多少時間，因為很難預測，所以完全沒有計畫。等專案結束，木已成舟、生米煮成熟飯，小孩都叫Joe爸爸了，不認也沒辦法...
- 人力管理：每次demo都有排定時程和預算，所以每次demo都可以知道有沒有超支或是過份膨脹預算。但是如果demo是50次而不是5次，人腦可能就記不得了，到專案結束的時候，總結一算，還是可能會出現大驚奇...
- 工具協助管理：同上。但是因為有工具輔助，所以就算有5000次demo，我們都可以隨時知道每次demo的預算、時程，跟當初的預估差多少，整體來看是否還能忍受，如果已經偏離太大，趕進修正(也許後面的demo就不做了，或是減少次數，將預算改配置到行銷部門之類的)，因此從專案的進行到結束，都不致於出現大驚奇。
個人淺見，僅供閒聊
-------
四月 06
L說:
C果然高，我們想講的東西是一樣的：管理是個"心法"而不是個"招式"，最重要的還是領導者的判斷，我完全認同。
我並沒有為了什麼事情而困擾，遊戲和軟體其實都一樣是創意領域，我們面對的問題其實都差不多的，哈哈。對我來說管理的定義就是"讓專案以最佳狀況下走下去"，所以手段本身無對錯，只有以專案整體利益的角度來看，才有它適不適合的問題浮現，提出這些問題也就是要強調這個概念。
與這類似的，也是大家常討論的 SOP 的問題。對我來說 SOP 這個詞的定義就是"讓技術與製程用最佳方式方式傳遞下去"，所以不管是用文件、用種子員工去教還是要拿一個範例讓執行者先去玩個幾天 (腳踏車的 SOP 就給他一台車去摔)，不管什麼手段都好，只要有效率即可。
研發專發是屬於每一階段的結果會變成參數進而影響整體目標的一種過程，例如某一天一個大客戶看上你的產品然後丟一大把錢叫你大改，也許你原有目標只是賺個小錢，但是有這樣賺大錢的機會我想大多數人還是會改變原有目標 (專案管理上這個也叫做 risk = =...)，所以牽涉到的判斷條件非常多元：專業力、判斷力、經驗以及週圍相關人物與環境變數都會對整體決策有影響，牽涉到的管理手段也非常多元，所以這麼複雜的狀況當然需要管理工具的協助才有辦法應付的來。
所以說到預算規劃、專案三角、WBS、Change Control、優先權設定...等這些專案管理手段，我會覺得這已經是基本技能了，應該每一個管理者都必須具備 (要麻煩 Joe 繼續訓練大家了 
~)，每一個案子也都需要導入，這實在沒有什麼需要特別討論的。管理者反而需要聚焦在比較難的部分，舉例來說，怎麼組織資訊來判斷事情的優先權、怎麼樣設定WBS的內容、怎麼讓底下的創意人處在很有靈感的狀態.....等，多來討論這些會比較有意義。
最後分享一下我個人的看法，東風不來，仗還是得打，要不東吳只有死路一條。最佳解找不到就必須找出第二佳的解，金錢、時間、底下的弟兄還有競爭對手是不會等你的。有做，就有成功的機會。
-----
四月 07
c說:
> 最後分享一下我個人的看法，東風不來，仗還是得打，要不東吳只有死路一條。最佳解找不到就必須找出第二佳的解，金錢、時間、底下的弟兄還有競爭對手是不會等你的。有做，就有成功的機會。
話說，如果東風不來，那東吳最好還是把小喬收好帶走最重要，如果她真的長得像林志玲的話...
