「公有地悲劇」文章的一些討論

這篇是「公有地的悲劇 那篇貼出來後公司內部的一些討論。 因為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,沒有標準。

==超無聊軟體話題結束,更無聊社會學話題開始==

而在社會學裡面,這種自己享用利益,成本卻不全然由自己負擔的狀況,我們會說是「成本外部化」或是「外部成本」。例如你騎機車、開車,路人吸廢氣就是典型的例子。所以「外部成本的內部化(由每個人完全負擔自己應付的成本)」,就一直是重要的課題。例如騎車、開車的人,如果把自己製造的廢氣自己吸進去,那就是外部成本內部化(只不過會死很多人,成本被轉稼給醫療單位,哈哈4a474b3145ab2 )。當所有的成本,都正確的歸到使用該資源的人,那麼根據人類利己的原則,大家的行為,就會符合整體利益。例如,既然一定要吸自己車子製造的廢氣,為了避免死亡,大家就會選擇開電動車,或是根本不開車。

==更無聊社會學話題結束==

上面的理論聽起來可行,做起來卻很難,因為「外部成本」實在很難估計和量化,過於簡化的規範,經常流於不公平,過於繁雜的規劃,又不易實行,再加上還有很多政治問題,所以從來也沒什麼真的非常成功的外部成本內部化的案例。例如燃燒石化燃料產生廢氣,但是花大錢開電動車也不環保啊,因為電也不是憑空生出來的,也是火力、核能、水力發電才有的,廢棄電池也是問題...。或是說一個中低開發程度的國家,連飯都吃不飽了,短期就要餓死了,你去跟他談環保這種遠期目標,也是不可能有結果的。

==超無奈現實結束分隔線==

回到專案,「正常的專案」是有一定的目標、範疇、時間、預算、人力,很多條件都已經被限制住了,因此他不會像解決社會問題一樣會需要扯那麼遠。不過即使如此,要設計出一套能讓大家盡量朝著同一個方向走的獎懲制度,盡量減少將自身成本外部化給整個專案承擔的狀況,都還是不容易的事情。我想這也是專案經理終其一生都要不斷纏鬥的問題吧,不然專案就讓機器去run就好了...

啊,真是一篇好硬、好無聊、又臭又長、又沒建設性、又增加資料備份成本的回文啊(哈,這篇回文本身就是成本外部化的範例)...這樣會不會幫你趕走更多讀者啊4a474b3145ab2

 

--------

四月 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 繼續訓練大家了 4a474b3145ab2 ~),每一個案子也都需要導入,這實在沒有什麼需要特別討論的。管理者反而需要聚焦在比較難的部分,舉例來說,怎麼組織資訊來判斷事情的優先權、怎麼樣設定WBS的內容、怎麼讓底下的創意人處在很有靈感的狀態.....等,多來討論這些會比較有意義。

最後分享一下我個人的看法,東風不來,仗還是得打,要不東吳只有死路一條。最佳解找不到就必須找出第二佳的解,金錢、時間、底下的弟兄還有競爭對手是不會等你的。有做,就有成功的機會。

 

-----

四月 07

c:

> 最後分享一下我個人的看法,東風不來,仗還是得打,要不東吳只有死路一條。最佳解找不到就必須找出第二佳的解,金錢、時間、底下的弟兄還有競爭對手是不會等你的。有做,就有成功的機會。

話說,如果東風不來,那東吳最好還是把小喬收好帶走最重要,如果她真的長得像林志玲的話...4a474b3145ab2

若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

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

Joe G+ ICON Joe LInkin ICON

11 則讀友回應

  1. Working Bee 2009-06-30 17:08:24 第 11 則

    我那時候的老闆也剛好叫Alex
    但是他和Eric的老闆個性不太一樣
    我的老闆他可以將市場上的知名產品都研究之後
    要求研究團隊做出一套全方位的CRM
    CRM在之前很熱門
    我在美國的工作也是做醫藥大廠的CRM系統
    REP可以使用Palm Top 或筆電去拜訪醫生
    做銷售記錄及簽名等
    我看到我老闆所規劃的CRM除了原本的基礎系統外更涵蓋
    Webmail Master, data Mining, Sale force management
    前兩項我居然在客戶那裡可以驗收
    我覺得很心虛
    我和客戶成了好朋友
    但是我離職後完全不敢再提系統
    其實還有其他的問題是
    擴張太快,在新加坡,香港和大陸都設點
    我老闆本身是Salesman出身
    可能是業務的想法吧~
    總之他讓我對軟體業很心寒---
    只是當我看到PMP感覺好像又看到綠洲囉~

    • Joe Chang 2009-06-30 19:02:38

  2. 小戴 2009-06-30 15:51:37 第 10 則

    關於Working Bee所提到的問題,其實牽涉層面很廣欸。
    產品和知名品牌一比較就沒有賣點,這有可能是一開始做產品定位、規劃產品功能時的問題;也可能是受限本身技術能力;也可能受限著作權保護法,能夠開發的功能有限。很多原因都可能導致產品沒有賣點...。
    prototype和DM做的很好,但客戶一測試堪用的不到一半,有可能是技術問題,畢竟prototype只是prototype,並不是個開發完成的東西,只是用靜態或動態頁面展是給客戶看,很可能介面上客戶很滿意、但實際開發後並沒辦法執行出那些功能;也有可能是簽約和驗收單位不同,當初和簽約單位談的需求與驗收單位要求的不同,因為認知的落差驗收單位很自然會覺得堪用的不到一半;我遇過最特別的狀況是客戶因為某種原因不想繼續這個專案、但也不想違約,所以不停找問題、想把責任歸責於我們、試圖迫使我方主動提出解約...。
    因為我不是很了解 貴公司的狀況,只能說有很多不同的原因都會使產品最後不被客戶接受。我會建議您可以從各種不同的角度去看這個問題,自行做個案分析,一定可以有很多收穫的!

    • Joe Chang 2009-06-30 18:58:58

      同意 這件事情可能有很多原因
      隨便舉例如
      產品定位 (不一定功能多才好)
      價格策略
      技術能力都有可能造成這樣的結果....

  3. 小戴 2009-06-30 15:46:56 第 9 則

    以我個人來說,因為我以前是帶軟體專案的,我會認為適度的demo對開發是有必要性的。軟體有個很大的特色,文字描述和各人想像往往會有落差、而且文字描述往往也不能把所有的需求涵蓋完全。
    舉例來說,簽約要交付一個「簡單好用的寄信功能」,開發者想像的可能是點選後連結使用者既有的寄件軟體(例如Outlook)、用該軟體寫信功能完成信件後寄出;客戶想像的可能是有個小介面、在介面上填寫響郵寄的內容、寫完後直接按寄送;這時候透過demo的輔助溝通,可以讓雙方溝通出認知差距。更不要說什麼叫做「簡單好用」,更是只有透過demo討論才會有共識。
    因此我認為做demo對verify project scope是有很大幫助的。唔...這樣就可以看出來我算是「雛形法」擁護者了吧(笑)

    • Joe Chang 2009-06-30 18:52:58

  4. 小戴 2009-06-30 15:46:14 第 8 則

    關於Demo做過頭是否是鍍金這件事...我想提個和格主不太相同,但我想格主也會同意的看法。
    我認為,Demo可以視為專案中的一個子專案。既然是個子專案,就有其應有的scope,而Demo的內容只要符合scope,就不算是鍍金。換言之,如果這個demo的scope就是要讓他做過頭,執行者做出符合scope的結果,應該是沒什麼鍍金可言的吧。
    至於為什麼demo的scope就是要做過頭,原因不一而足,但也不是不能想像。例如格主小說裡的Eric,不也是用些「技巧性」的方式去demo、並沒有完全展示出實際的狀況,目的是為了不讓人發現專案有問題而喊停;或者建案要蓋樣品屋,業主要求設計師「多美化一下,讓客人有更多的想像空間進而願意掏錢」,設計師比照業主要求做出樣品屋。我想這些都不能說demo本身有鍍金對吧,反而是道德問題。Eric是該聽老趙的建議先過前這關、保住大家的工作,還是站在公司利益考量老實誠懇的做答?設計師應該聽業主的做出不完全符合事實的樣品屋還是照實際狀況建樣品屋?咳,格主,這就等您下一篇解答囉。

    • Joe Chang 2009-06-30 18:37:52

  5. 小戴 2009-06-30 14:36:37 第 7 則

    關於C所提的內部成本外部化,我想補充一點點,很多學者試圖再處理這部分的問題,也提出了些因應的方式,最普遍是採用抽稅或罰款。就以C所提的汽機車廢氣為例,如果超過標準值,可以依空氣汙染防制法開罰,例行也有燃料稅徵收。借由這類的方式把這些轉嫁到外部的成本再還給使用者支付。當然,這樣的方式是否讓使用者付出了合理的代價另一回事了。

    ------------傳說中的分隔線------------
    關於L的說法,這會讓我想到軟體工學中各種不同的開發方式,瀑布法、雛形法...每種開發方式都有支持者和反對者,很容易在軟體開發工程相關的書中看到對於每種開發方式優缺點的評論,真的要在這邊做詳細討論可以討論很久很久...

    ------------傳說中的分隔線------------
    我覺得最後L和C兩位下的結論很好,管理是種心法,有很多技巧可以使用,但什麼時候要用什麼技巧,就要看管理者的判斷,這也是管理者的價值所在。

    • Joe Chang 2009-06-30 18:34:09