Category Archives: IT Talk

優質趨勢部落格

最近似乎很流行抨擊某位趨勢預言家,姑且不論這位到底有沒有料,關鍵的還是到底有沒有人有辦法準確的對台灣電信或網路生態進行分析。

義氣幫的成員大多都和交大校園網路策進會有關係,而這個社團的精神領袖則首推前交大計中網路發展組組長劉大川老師了。劉大川老師從 1996 年就開始固定發表文章,有些是社論有些則未公開發表,當時雖然還沒有 “blog” 的概念,但他確實可以算是持之以衡又言之有物的少數 IT 觀察者 (舊文在此)) 當然,更早之前其實他也固定在 BBS 發表文章,就更不可考了。劉老師在計中開的課程,也一向是想深入瞭解電信網路業發展內幕者不可錯過的課程。劉老師之所以能言之有物,一方面是他貼近產業,瞭解許多不被大眾所瞭解的內幕細節,另一方面也是因為他觀察時事不從表面出發,而是去推測更深層的動機,再加上有數字分析,讀起來就格外有啟發性。

劉老師在 2007 年退休之後改在 blogspot 落腳發表文章,雖然退休之後多了很多食譜文,不過分析事情確實還是有條有理,而且往往能夠直指核心或提供另類思考,如果真的想要訓練自己分析時事能力,我覺得劉老師依然是非常值得學習的對象!

劉老師的部落格: http://ltcctl.blogspot.com/

成本導向的軟體開發

最近遇到兩個軟體開發的決策問題,一個是既有程式的加強,另一個則是全新的專案。有趣的是,同一個邏輯會導出來一個功能上的死結。

大前提是,公司的每一個小組,應該朝向降低軟體開發成本的目標而努力!(Keroro 軍曹如是說)
眾小兵: 喔!!!

Continue reading

為什麼老闆指導的專案容易出錯?

大多數基層的工程師往往對老闆很有意見,如果說專案管理裡面有什麼比 “客戶” 更大的風險,那應該就是老闆了。一個具有絕對決定權的人,對於專案卻不一定有全盤的瞭解,這種角色下的決定當然很容易就出錯。久而久之,老闆似乎就成了專案中最大的不定時炸彈。

但是到底為什麼老闆會做出錯的決定?又是怎麼樣的環境限制了老闆的能力?假如我們相信,大多數的老闆,在當老闆以前還是有幹過一點像樣的事、帶過一些像樣的專案、至少還是有一點能力的,那麼為什麼在老闆的位置上卻反而變成絆腳石呢?先前和一位朋友聊天後,有了以下的心得。

老闆容易天馬行空

我們聊到一位資深、素富聲望的資深 PM,被公司賦予一個任務,“開發下一代的電子商務系統“。下一代,代表沒有參考點,當然也就不是照抄別家網站兜一兜就可以了。這個團隊花了很多時間構思五年到十年後的系統,所用的技術當然也是最新的架構,從這些新東西上試著建築出 “下一代的電子商務系統”。”下一代” 的另一個隱含意義是 – “現在還不能用“,但是人力物力花了下去,公司不可能持續燒錢來支持一個不能用的系統;這裡的問題是,為什麼一個資深的 PM 或是總工程師,會造出一台不會跑的車?

關鍵是在天馬行空。大部份商業環境下,專案往往有許多限制,越到底層限制和責任也就越明確。每一個 PM 或是工程師往越上晉升,除了專案所牽涉的複雜度增加以外,限制也逐步減少。限制減少一方面代表的是空間變大,另一方面也代表風險增加,更糟糕的是,這代表評估專案成功的底線也越來越模糊。

一個”下一代的電子商務系統”,它的評估條件到底是在 “下一代” 還是 “賺錢” ? 它的成功是因為公司的過渡成本低廉還是因為長期支出降低?它能滿足的需求是公司目前的業務還是應付未來的變化?這些根本的問題是專案成功與否的基準線,但是這些基準線卻很可能逐漸的、緩慢的擺到另一頭去,原因是即使有經驗的 PM 或總工程師為自己設下假設性的限制,這些假設都很容易因外界而改變;公司政策的突然轉向、產業的典範轉移,都會讓某些假設顯得荒謬。

那麼老闆的問題又和這種總架構師或大 PM 有什麼相似之處呢?多數老闆都長期在沒有限制的狀態下思考,唯一的限制就是現金流。老闆的成功與否也沒有評估的基準線,除了慘賠的案子以外,老闆幾乎都可以用自己想要的方式來評估成功與否。一個不賺錢的案子可以說是賣進去了下一個更好賣、接不到下一個也可以說累積經驗。沒有一以貫之的評估條件,就很難決定朝向哪個方向走才是對的;先有地平線,才能知道往哪飛才是高。老闆常是別人的地平線,但老闆自己的地平線在哪裡呢?

離現實越遠,越不容易掌握成本

另一個常見的問題,則是來自老闆對專案的突發異想。越到高層自然不會也不該事必躬親,所以對於許多決策的形成過程不瞭解,這是其一;但專案會議既然希望高層列席,當然也是希望他們能提供觀點、看專案是否和他們心中的 “基準線” 相符,這是其二。原本這兩件事都是正常的,但是在這種情形下,很容易變成專案一面倒的妥協,只為了希望贏取高層的支持。事實上,符合高層 “基準線” 並不代表要迎合每一個要求,如果你相信老闆是理智的,那麼其實應該要做的是讓高層瞭解變動的成本為何。專案執行者如果沒有把成本的資訊往上回送,老闆當然就很容易做出錯誤的指示。

老闆如何避免帶領專案時犯錯

  • 反求諸己: 假裝自己是低一層的專案管理者,為自己事先套上一些前後一致的(consistent)限制;
  • 建立基準線: 避免射了箭才畫靶的心態

老闆如何避免自己提的意見成為專案的風險

  • 從下到上: 鼓勵團隊解釋決策過程;
  • 吃米要知米價: 確認按照自己意見修改的成本;
  • 不要深不可測: 事先、主動的表明自己評估專案的基準,避免下面為了猜測自己的基準線而一味退讓。

資管人才要怎麼教?

優秀的資管人形形色色,但通常都有的特質是:

  • 邏輯好, 頭腦清楚;
  • 至少有一個專長;
  • 溝通能力強;
  • 興趣廣泛

如果以武將來說,大約是姜維的水準;拿他跟呂布 PK 一定死,找他跟司馬懿下棋當然也被電好玩的,問題就是姜維既不會跟魏延鬧脾氣、遇到雜魚也可拿刀跟他對幹。所以爭論誰程式寫得好是沒意義的,但是,絕對要能寫水準以上的程式。

問題就是,姜維真的是學校教得出來的嗎?這就是資管教育最根本的問題了。水鏡可以開班授課教出八奇,反正孫子兵法照念,前八名的再趁就業博覽會時介紹給大公司就好了;武將反正就是練兵跟打仗,打了幾年下來還沒死的人自然就是個將軍了。但又要唸兵書又要打仗的學校,到底是拉單槓重要還是唸陣法重要?

可是回過頭來說,一個軍隊也不能只有諸葛亮和關羽吧,不然八陣圖要建的時候會這樣:

孔明: “姜維, 這個八陣圖在這, 照圖施工就對了。”
姜維: “丞相, 請問石頭跟工人要怎麼調配?”
孔明: “有沒有這麼菜啊? 問我咧~”

<跑去找魏將軍>

姜維: “魏大將軍, 這個八陣圖麻煩您支援弟兄幫忙蓋一下…”
魏延: “賽你丞相, 關我屁事, 我們要去健身房鍛鍊啦~”

資管教育是可以教你技術和商業遇在一起時可能會產生什麼問題,教得比較好的老師也可以教學生怎麼解決問題,但實際上,大部份學生都太年輕而沒辦法真的吸收進去。考試當然更沒辦法考出什麼東西來,因為商業的東西終舊要在商業的環境中實戰才能驗證,而不是靠考試或報告。這也是大多數資管教育失敗的主因。

有板友說,美國資管系教育正在減少;我的看法是,美國人因為相信媒體宣傳的 “IT 已死”,認為這類技術工作終究會被外包到國外,所以唸這類科系的美國人大減,這是我和 CMU 資管的系主任 (管理學院副院長) 聊天時他說的。也因為這樣,系上會每年檢討開課跟業界的需求是否符合,儘可能以學生能找到好工作的方向推動。反之,台灣大部份的資管系所和業界的合作卻很少,對基礎能力的要求也不夠,畢業生出去時當然就比較吃虧了。

回到資工資管的問題,既然我都唸過,應該有一點點資格說話吧。人的時間是有限的,你花時間鑽研一項知識,就可能會漏掉或輕視另一個知識。你可以設計出世界上最好的新無線網路協定,但是如果你搞不定電信頻譜執照就是白搭;你可以寫出最棒的網站,但你應該不會有時間天天和金主吃飯開法人說明會。你的擋垃圾信演算法很棒,但是得有人去做無聊的市場調查才知道用戶到底在不在乎。

資管不是管理資工的人,而是管理資訊相關的議題,以及被資訊影響的人。總有一些事情是資工沒有教,但在現實社會中也和技術同樣重要的。資工沒有教是因為這些時間得省下來鑽研更深的技術來維持競爭力,並假設有人會去處理這些事。運氣好,處理的人對技術有概念就很好;運氣不好,整個團隊的競爭力瓶頸就會出現了。

即使我現在還是以寫程式為生,但我很高興有人幫我把市調做好、把事情優先順序整理好、把客戶需求搞清楚、把測試者的時程接好,這樣我可以專注在我做得最好的事情上。不管我做的事有多麼不可取代,沒有其他資源,我仍然是英雄無用武之地。我可以自己幹出一個網站,但要認真跟檯面上的大公司拼,個人是沒有用的。

雖然平心而論我覺得台灣的資管系設太多,但如果已經踏上這條路並打算走下去,我建議還是:

  1. 要有一項專長, 不管是寫程式還是財務;
  2. 溝通能力要強;
  3. 學習力要強, 你會一直需要學新東西的.

《原發表於 PTT 八卦板》

相關閱讀: 《資訊和管理的交界 – 資管的心得分享

為什麼老闆不愛我的專案?

前幾天在某板發文結果被酸打高空跟嘴炮,所以還是來自己的 blog 說的好。

很多研發人員和上司最大的衝突往往是專案的優先順序,研發人員認為 A 比較重要,上司或是老闆認為 B 比較重要。因為認知不一樣,所以雙方的磨擦和衝突就越來越多。一個很容易讓研發人員抓狂的老板語錄如下:

老闆:「那個 A 專案隨便做一下,可以交差(驗收)就好了。」

研發這時候往往會覺得老闆是豬頭,如果可以隨便做,客戶為什麼不自己隨便做就好?幹麻花這麼多錢包給我們?如果可以隨便做,那當初估出來的時程難道是估心酸的?

之所以雙方會有這麼不同的看法,主因還是思考邏輯的不同;想要說服老闆愛你的專案、或是事先知道老闆會不會愛你的專案,就要知道老闆是怎麼想的。
Continue reading

技術不是用來解決管理的問題

記得在學校畢業前有一門必修課,叫 Digital Transformation,主要是利用個案來探討資訊科技對於企業甚至政府的影響:在這些個案中,主角都因為科技的變化而遭逢了一些問題,有的是傳統產業想要升級,有的則是國家的港口想要轉型,在這些個案中,對於資管的學生來說,科技,幾乎就是唯一的解答。所以甚至會看到有些不太認真的組,提出: “該公司應採用 Java 相關的 Web 技術來設計系統” 給 1995 的公司。的確,有些公司的問題,確實是只要等待科技稍微進步一點 (例如,BlackBerry 機的出現),就會比較容易解決,但是實際上,管理上的問題並沒有這麼簡單,這也是同樣的技術,用在不同的公司,會有完全不同下場的主因。

前陣子聽到主管討論到把公司的每一個網站元件都切成獨立元件的問題。在工程師的完美世界裡面 (或是有一些 SOA 的宣傳文件裡面),每一個 Service 都應該可以獨立運行,彼此之間只要界定好介面訊息,撰寫和維護各元件的工作應該就可以切開給不同的人 (或組) 負責;”負責” 代表權和責,某人要為它負責,當然需要確保這部份元件運作正常;既然他要負責,而且我們已經有完美的介面,自然其他人也應該尊重這個封裝,不應該去動他的程式碼。

幾乎所有老經驗的程式設計師都會同意,loosely coupled 和封裝可以減少很多問題,只要…我們不考慮效率的問題。
Continue reading

十個人機介面可用性的評鑑原則

設計人機介面有很多種方式, User Study 應該仍然是最重要也最難在小公司實現的一環。對很多公司來說,除非先前曾經有過慘痛的失敗經驗,不然人機介面設計的預算往往低到不行,所以也只能祈禱工程師設計出來的介面不會太難用了。

不過,這樣的流程會讓介面設計的討論流於情緒化,往往公司裡面會有這樣的對話:

PM: 「我覺得這個按鈕放這裡不對。」
工程師: 「為什麼?」
PM: 「我也不知道,但我就是覺得怪怪的。」
工程師: 「好吧,我改。」

如果 “覺得怪怪的” 是客戶說的,也許我還是可以視為 user study 的一環,但是 PM 並不是 user;這樣的討論最後往往沒有什麼好的結果,為了大家說不出來的 “感覺”,爭得臉紅脖子粗。

所以,如果有一些原則可以遵守,找出自己覺得奇怪的原因,就可以讓討論更為理性。
Continue reading

資工畢業生應該要可以答出來的面試問題

前陣子幫某公司面試實習生,覺得頗有感觸。

我覺得,作為一個資工(Computer Science)的畢業生,有一些面試問題,會是像叫籃球球員運球一樣的基本。運球運得好的人,不一定可以變成 Michael Jordon,但是很難想像 Michael Jordon 運球會運不好。同樣的,也有一些問題,如果畢了業還答不好,會掩蓋住你在其他方面的成就。

之所以寫這篇,目的倒不是要寫另一篇草莓文埋怨現在學生,而是希望能夠喚起大家對於 “基本功” 的意識。有別於媒體上所宣傳的,面試 Google 和微軟,大多數的問題其實並不是要你天馬行空解題,而是問基本功。

所以我想稍微寫一下我認為的基本功問題,也算是給還在唸書的人一點參考吧。

如果你說你修過演算法/資料結構…

  • 解釋時間複雜度?空間複雜度?兩者之間的關係?
  • 請解釋以下幾種資料結合及運作方式: hash, heap, stack, tree
  • 請提出一種時間複雜度為 NlogN 的演算法,並用你熟悉的語言寫出來

如果你說你修過作業系統/計算機系統…

  • process & thread 有何不同?
  • 決定 cache 效能的兩個指標?
  • 什麼是同步化?要怎麼寫?
  • 什麼是 deadlock?要怎麼解決?

如果你說你會寫程式…

  • 什麼是 call by value?什麼是 call by reference?兩者的優缺點?
  • 寫一個迴圈來看看?
  • 寫一個遞迴來看看?
  • 什麼是 function 的 signature?回傳值能不能是 signature 的一部份?
  • 什麼是 static function?什麼是 static variable?

如果你說你會資料庫…

  • 什麼是 normalization?為什麼要做 normalization?
  • 解釋 inner join, left (outer) join, right (outer) join
  • table 為什麼要做 index? 舉一個做 index 有用的例子和沒用的例子?

如果你說你會 C/C++…

  • 請搞懂 pointer

如果你說你會 JAVA…

  • 請搞懂 OOP

如果你說你會 PERL…

  • 請搞懂 Regular Expression

如果你說你會 PHP…

  • 給你半小時應該要能生出一個 Hello, Pesty 的網頁 (當然,Pesty 是 form input 的)

如果你說你會 TCP/IP…

  • 把下面幾個服務依使用到的原理照 OSI 層排序: http, telnet, DNS, MAC Address, ping, session, vpn
  • 解釋 class A, B, C, 和 class-less

如果你說你會 UNIX….

    怎麼把 ls 的結果導到 /tmp/test.txt 中?
    為什麼平常操作不該用 root?

再列下去我就要專做一個網站了….以上問題應該都不算過份吧….唉~

P2P 借款: Prosper.com

去年看完《窮人銀行家》之後開始在 kiva 上面小額放款,到目前的成果… 五個貸款者裡面只有一個還款不正常,希望他可以挺得過去。

不過,kiva 畢竟是屬於非營利精神居多,款項收不收得回來其實大家也沒這麼在意。去年畢業專題的指導教授正好是專門研究這類網路服務的,他就介紹我使用 Prosper.com ,一個 P2P 的營利借放款網站。
Continue reading