Tom's IT notebook
IT is not Information Technology here, IT means EVERYTHING
2012年12月15日 星期六
2012 Java 認證日與會感
其實除了我有利用 Java 開發過 Android 程式外,對於整個 Java 繁華萬千的世界,我可以說是個局外人。
這次『2012 Java 認證日』從主題很明顯是個推廣 Oracle 版本的 Java 證照行銷活動,本來應該與我毫無關聯,但收到 eDM 的當下,不小心被我瞄到這場免費活動的議程其實有『置入性教學』。真是怪哉,別人都是藉教學之名做『置入性行銷』,Oracle 則是反其道而行。
閱讀內文
失敗專案的得與失
前幾個月和同事在業外接下一個稍具規模的專案。承接這專案其實背負著相當高的風險,其一為此案所需要的各項專業技能我們是
完全付之闕如
,能夠在什麼都不會的情況下接觸到這案件,完全是同事的人脈引薦所致。其二為對眼前這個合作夥伴的不熟悉,以及一些不信任因素。
當初會考慮冒此風險,原因之一是此案的極高的報酬,再來是因為上過
激勵課程
,內心感覺要跳脫筐做冒險:
若要如何,全憑自己
。所以在工作規劃分配後,對於必須惡補的技術項目覺得有賭一賭的信心。
如果是之前的我,只敢做有把握、會做的事,當看到實力和目標有如此懸殊的差距,一定會直接拒絕。
當然,最終沒有成功完成此專案,但其實我一點都沒有難過的感受。因為這個挑戰的本來就是『
失敗是應該,成功才奇怪
』的任務,然而我從這個挑戰的過程看到自己的延展性和真正的弱點。若我承接的是個十拿九穩的案子,面對的可能就是『
成功是應該,失敗卻難過到想不開
』,而且什麼都沒學習與成長的結局。
所以接下案子後,我們當務之急就是如何將技術落差產生的風險降到最低,並且爭取最多的工作時間作為克服技術障礙的緩衝之用。
這次團隊組合的專精是在 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,就是:
我一個人一頭熱,夥伴卻都沒採取有效行動
。
常常因此搞得我心情惡劣導致破局。既然要找到步調一致的夥伴太困難,我又沒有能力去管理夥伴的執行力,而且容易因此而惱怒到不爽幹,所以到底該怎麼解決這樣重複的模式而改寫結局呢?
在我心中,答案似乎慢慢浮現了出來⋯⋯。
較新的文章
較舊的文章
首頁
訂閱:
文章 (Atom)
Database 選擇的 cheatsheet,太棒了!
SQL Deadlock 的處理經驗談
最近公司在為了即將上線的產品進行壓力測試,產品內有個結帳功能是同事 A 先生的得意代表作,結帳功能在 A 先生信誓旦旦拍胸脯保證三百萬筆資料秒殺的信心下,平行作業卻發生了 Deadlock。
網站效能不佳?談『如何判定系統變慢原因』的簡易 SOP
上次『 大禹治水 』提到,對於採用 Windows+ASP.NET+MSSQL 技術的網站服務,找出網站系統變慢、效能不佳的原因其實有一簡易 SOP 可以起手,減少無頭蒼蠅盲目亂撞的時間成本浪費,這篇就簡單介紹一下這簡易的 SOP。 ...
『東西沒壞就不要修』?淺談軟體的技術破產
只要在軟體開發圈子混一段時間,尤其已經有系統 run 在 production 環境上,十之八九會聽到這句廣為流傳的經驗談:「 東西沒壞就不要修。 」 這句話,常常被反對重構( refactoring )者掛在嘴上。