失敗專案的得與失
當初會考慮冒此風險，原因之一是此案的極高的報酬，再來是因為上過激勵課程，內心感覺要跳脫筐做冒險：若要如何，全憑自己。所以在工作規劃分配後，對於必須惡補的技術項目覺得有賭一賭的信心。
如果是之前的我，只敢做有把握、會做的事，當看到實力和目標有如此懸殊的差距，一定會直接拒絕。
當然，最終沒有成功完成此專案，但其實我一點都沒有難過的感受。因為這個挑戰的本來就是『失敗是應該，成功才奇怪』的任務，然而我從這個挑戰的過程看到自己的延展性和真正的弱點。若我承接的是個十拿九穩的案子，面對的可能就是『成功是應該，失敗卻難過到想不開』，而且什麼都沒學習與成長的結局。
所以接下案子後，我們當務之急就是如何將技術落差產生的風險降到最低，並且爭取最多的工作時間作為克服技術障礙的緩衝之用。
這次團隊組合的專精是在 Adobe Flash / .NET ( ASP.NET ) / MS-SQL，但客戶要的是 HTML + AJAX ( No Flash ) / Java ( JSP ) / PostgreSQL 。在最初幾次與客戶的會議討論，總算把其中一項置換為同事所宣稱熟悉的 PHP。客戶的網站除了少部分的特色項目，大多是一般網站都該有的常見功能，而 PHP 是出了名的有很多免費既存套件可以快速架站，因此我研究幾套自由免費的 CMS ( 內容管理系統 ) ，挑選了 Joomla 做為整個專案的開發基底。
由於 Joomla 只支援 MySQL 和客戶需求不同，經過幾次強力說服客戶轉換資料庫平台無效後，我肩付起最難評估風險的任務：移植 Joomla 到 PostgreSQL 平台上。要深入這麼龐大的系統原始碼進行改寫，而且用的是我毫無所知的語言 PHP ，這過程只能用費神費力、艱辛刻苦來形容。利用 Joomla 可以大量節省我們刻後台管理的開發時間，並且解決掉一半前端頁面的工作量，等於把這些省下的時間全部賭在移植工作上，這真是一場生死一翻兩瞪眼的豪賭，若改寫移植失敗，將面臨沒有任何進度兩手空空去見客戶的窘境。
這中間多少次，遇到 trace 細節內的魔鬼讓我挫折沮喪幾乎要舉白旗的當下，最後決定堅持不放棄。結果，竟然能在最短的時間內深入學習多項過去不曾碰觸的技術或應用：PHP / Zend Studio / Joomla / MySQL / PostgreSQL。若不是執意冒險承接這個案子，我敢說這輩子幾乎不會也沒有任何動機去接觸這些新玩具。
然而最後案子的敗跡，竟然不是出在這些技術關卡上，而是團隊的合作出現間隙！
首先是上半局，其中一位經由同事介紹認識的夥伴表現非常沉默被動，幾經詢問後才表達：因技能落差太大，也沒有想接觸新東西的想法，感覺這案子太硬、風險太高而決定離場。後期擇是當初介紹這個案子、宣稱很熟 PHP 並且負責前端使用者頁面與互動的同事，完全沒有進行任何有效的開發動作。我不斷請他給我進度上的承諾、不斷地在我心中設下停損、也不斷地看到進度一再地跳票。
雖然離結案還有一段時間，但我心中已經認定這是艘救不起來的鐵達尼。與其在最後一天才兩手一攤，給上游客戶難堪，又讓自己獨自一人的努力白費，我選擇嚴守停損，斷尾求生提前主動告知退出這個案子，讓客戶還有另尋備案的機會。
雖然拿不到半毛錢，這段時間花的力氣看起來像是平白損失了，但其實我卻有十分充實愉快地感受。因為這個案子進行過程的每一天，都在逼我學習許多全新的東西，也開啓了我對其他類型技術的視野。這個學習的過程，本身就是相當值得的回報，也讓我對跳出自己能力框框去接下任何可能的機會有了全新的想法。
而且回顧失敗的原因，其實也正反映出我一直以來的弱項：如何真正有效地管理協同合作的夥伴？
之前我本來想寫另一篇難產中的文章，反思我過去有三個失敗的創業合作案的體悟，連同這個外包案在內，恰恰好都遇到一模一樣的 Pattern，就是：我一個人一頭熱，夥伴卻都沒採取有效行動。
常常因此搞得我心情惡劣導致破局。既然要找到步調一致的夥伴太困難，我又沒有能力去管理夥伴的執行力，而且容易因此而惱怒到不爽幹，所以到底該怎麼解決這樣重複的模式而改寫結局呢？
在我心中，答案似乎慢慢浮現了出來⋯⋯。
留言
張貼留言