專案厚黑學(六)：專案價值的評估

| | | | | | 留下回應

    

花錢開發一套系統，其實一開始都會有一個想法。不過以我自己的經驗，大多數的系統，其實完成的東西，都跟原來的想像，有著不小的差距。一方面當然是因為系統有可能在開發的過程裡面，受到各種因素的影響，偏離了原本預期的方向。另外一方面，就是在我們規劃一套系統的初期，其實為它增添太多夢幻的色彩。

很多人會把他對於現實世界的所有期望，孤注一擲地壓在一套系統上。如果這套系統可以上線，我們多年的問題，就可以一次獲得全部的解決。當你期待越高，失望的機會就越大。

當你花了很多時間跟精力，做出一套新系統來，好不容易它會動，會照著原先規劃來運作時，這樣就大功告成了嗎？其實還沒有。等到你終於要把系統導入到實際使用的部門上時，常常就會有人懷疑：『為什麼要用這套新系統？』『舊系統還是比較好用。』『看不出有什麼實際的效應。』『當初到底是誰說要做這套系統的呀？』『公司賺來的錢，都被浪費在這種沒有意義的東西身上。』

當你花了很多心血，催生了一套系統，等它上線之後，卻面對各種質疑時，內心可能會浮現的是：『你們真的了解這套系統的博大精深，可大可久之處嗎？真是一群見識淺薄目光短淺的無知群眾。看來天才總是孤獨的。梵谷也是等到死後才聲名大噪。』

『耶，這是什麼話，我還年輕，我不想死呀。』

那什麼時候才可以看出資訊系統的價值，來證明你的努力是有代價的呢？我個人對於有沒有辦法真正的驗證一套資訊系統的價值，採取比較保留的態度。

很多人會從財務數字上面去觀察。不過賺錢多寡，跟資訊系統之間可能有正相關，可是不見得可以完全歸功於系統的幫忙。

你可能沒有辦法真正算出，透過這套系統，它幫我多賺了多少錢，因為同時間的變因還蠻多的。況且，有些系統的價植是無法量化的。你怎麼判斷因為有了email這種東西，到底對企業創造出多少價值呢？你怎麼判斷，因為害怕員工在上班聊天，所以公司裡面全面禁用MSN。這可以創造或是因此減少多少價值呢？

很多時候，我們做一套系統，就是因為事先評估覺得應該會帶來效益。所以就去做了。至於KPI，那些只是為了讓人可以在沒有什麼更準確，更優良的方法可以看出資訊系統價值的狀況下，一個不得不然的替代品。

那等你把一套系統生出來了，那要做些什麼，才能讓人覺得這是划算的呢？

我覺得這跟下個主題有關：專案的價值，需要不斷賦予新的意義與調整。

考前重點提示：不管你做了些什麼，記得要重新定位什麼是成功。

專案的價值，需要不斷賦予新的意義與調整

不久前，我做過一套系統，原本他們的目標，是希望把很多東西都變成可以透過很彈性的xml設定以及共用的模組，來縮短開發的時間。很多原本要寫程式才能解決的問題，改成xml設一設就解決了。

可是，沒有想到的是，設定xml所花的開發時間，比起寫程式來說，絲毫沒有比較快。開發人員反倒需要跟格式繁瑣的xml檔奮戰。設定這些東西變得比寫程式還麻煩。又因為系統要花很多時間去解讀複雜的設定與處理，這些事情反倒拖慢所有的performance。後來就會被人質疑：『那我花錢做這套系統到底是為了什麼？』

關於這個問題，我也沒有答案。因為這個系統當初會有這樣的問題，我其實已經告訴原來專案經理，他也知道這一定會有問題。當初雙方想的是，可能有哪一天，可以再多挖一點經費來繼續開發xml設定的部份。

然而這個案子做到一半，這個專案經理就離開這家公司了。留下一個很有彈性，performance很差，也很難使用的系統。讓我與繼任的人選，兩個人大眼瞪小眼地對望。

不管預期的效益是什麼，事實上，有非常非常多的系統，完成的時候，根本就沒有達到預期的效益。我不知道有多少人做過這樣的系統。一套原本想要可以大幅縮短response time的系統上線後，反倒大幅增加response time；一套想要降低庫存的系統上線後，反倒堆了更多的庫存。

當你期望它可以解決一個問題的時候，它有可能反倒讓你的問題更惡化。甚至帶來更多無解的問題。遇到這種狀況，又該怎麼辦？這我們下周再繼續吧。

作者為資深工程師及軟體開發專案經理，經常撰寫軟體專案的文章，作品散見於資訊論壇網站，著有《在公牛身上擠奶》一書。