大約一年前我介紹了 Prosper 這個 p2p 的個人貸/放款網站，並親自投入這個網站開始下標放款，後來並寫下了三個月的回顧，當時候我的預估利率 (在考慮倒帳的風險後) 大約是 10%。接下來我持續放款，直到 Prosper 因為需要跟金管單位進行註冊而暫停新借款為止，共放出 69 筆、約美元 $4,000 的款項。現在一年後，結果是如何呢？ Continue reading →

[原討論串於 Ptt 的 Soft_Job 板]

討論這種問題，應該還是要先釐清什麼是 “軟體公司”?

是傳統的以軟體為商品的公司、如微軟、Adobe，還是可以包括以軟體為基礎但賣的是服務的公司，如 Google、Yahoo，亦或是以軟體/IT為其核心競爭力的公司，例如 Amazon?

如果只把範圍限制在軟體製造業，那麼台灣的確是不太可能像發展出像印度的代工業，最大的敵人不在別人比較便宜或別人人多，而在於台灣最好的資工人才都被電子業吸走了，因為往那邊薪資比較好；同樣的事也發生在印度，電子電機畢業的全跑去寫程式，他們要發展電子業就非常辛苦。

另一個觀點是，落後國家培養產業實力需要外力扶植，透過長期的代工單台灣的電子業才能夠累積非常多硬體製造的 know-how，外國廠商並不是一開始來台灣就下單，而是一步步從 QA/QC 教過來的，隨著台灣學到越多，他們也才能更加放手給台灣做。同樣的事在軟體業並沒有發生，所以落差也會比較大。

但是從更高的角度來說，明明 “software as a service” 都已經喊得震天響，還在討論台灣有沒有能力開一家賣軟體的公司，倒不如往賣服務的方向去想。

例如說，在美國有專門申請學校成績單的網站，他們跟各校簽約，公司負責處理申請的金流、資訊流和認證問題，學校只需要寄出成績單就好了。相較於台灣許多學校都要親辦，不然就是自建時產生一堆問題，這種 “服務”是可以賣的。同樣的例子在企業的薪資系統也有，與其讓自己會計每個月在那邊印薪資條發給同仁，美國公司多把這種業務外包出去，而外包的公司會負責印支票和確保薪水可以透過網路設定自動轉存進多個帳戶。

而對以資訊系統為競爭優勢的公司來說，其內部所需要的技術人才也不會輸給傳統軟體公司。VistaPrint 這家以印名片起家的公司，之所以可以贏過台灣巷口的印刷輸出店，其中一個主因就是他們花了非常多的精力在改善資訊流程，以致於他們能夠讓訂單從網路下單之後到包裝寄出，完全不需要人力介入個別訂單，同時還利用自家的演算法讓印刷的排程可以比別人省紙、省工 (正好是個 NP-complete 的問題)。

不是每家公司都得當 Google，處理商業問題需要的創意也不見得會少。

如果從這種角度來看，Open source只不過是食材，要怎麼炒自己家的這盤菜才是重點。並不是你拿到博客來網站的程式碼，就能夠變成台灣第一大網路書店，也不是你拿到美國這些企業服務的程式，就會有上萬家台灣的客戶。

回到主題，台灣人有著很矛盾的態度；我們對於3C商品接受度很高，但對於以資訊系統作為核心競爭力卻缺乏想像力，某種程度是因為台灣的人工還是很便宜，所以允許組織內大量浪費的人力而不用資訊方式去解決。如果用腦解決問題的人才老闆會嫌貴，這個產業就很難成型。

以電子業來對比，就像如果找了不好的工程師設計出來的東西會讓你 rework 損失幾百萬，倒還不如花高一點的薪資吸引好一點人才。

以長期趨勢來看，台灣受到中國競爭的關係，勢必是得在無形的地方下更多工夫，所以軟體/資訊系統的投資應該也會越來越高，雖然這不代表賣設備的 SA 或現在賣 ERP 的能夠大賺，但我想至少會產生越來越多以軟體為核心競爭力的公司；如果你認為 Amazon 算是軟體公司的話，那這樣應該就符合了。

最近某網創課程被鞭得很兇，許多大大似乎都出來告訴諸位無技術的有志青年，”代誌，並沒有你想的這麼簡單低~”

誠然，技術是需要累積的，不然也就不能稱作技術了。不過，我覺得技術很難並不是原本不是技術背景的人不該學習技術的原因，而是，創業除去技術之外還有太多也同樣重要的事情要做了。

即使你一行程式都不會寫，並不代表你沒有辦法 “設計” 網站，WORD 打開、白紙攤開，一頁一頁的把自己心中的畫面以及每一個畫面中按紐的作用是什麼給標清楚，這個動作雖然叫開規格，但是實際上卻是在設計網站沒錯。大多數技術人員之所以沒辦法和非技術背景的人合作愉快，就在於非技術人員如果只提供想法，叫技術人員提供細節，最後自己再批評別人想出來的細節要求修改，這種合作關係是很難長久的。

相對的，如果非技術人員都已經把細節列出來、把畫面用剪貼或是草圖的方式表示出來，技術人員針對技術上可行性進行增刪，不只是施工更快，同時雙方合作的關係也較圓融。

所以，如果你不是技術背景出身，其實你應該學習的是如何不厭其煩的把自己的想法給畫出來，把自己的設計寫得越清楚越好，而不是只會出嘴巴而已。如果連你都覺得寫成 WORD 很煩了，那別人什麼參考訊息都沒有寫程式不是更煩？

就我個人的經驗，如果 PM 已經把規格寫到每個畫面每個連結都已經有說明了，開發起來真的是快速很多，而且幾乎在討論規格的時候就已經可以把主要問題說明給 PM 瞭解，在那個時候解決。PM 不一定需要程式開發的背景，但做的事不就跟創業時期的非技術人才相似？

創業還有許多需要處理的事，分工應該才是邁向成功的路子；有心瞭解更多程式的運作是一件好事，能夠把自己的邏輯透過程式的訓練培養出來也是好事，但在自己拿起工具開始寫程式前，不妨想想還有什麼投影片、說明書、規格書沒寫，如果等到這些事都做完了，而還找不到好的人來幫你開發，說真的，外包到印度去吧。

相關閱讀:

網路趨勢/創業大師不會告訴你的事（一）

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

義氣幫的成員大多都和交大校園網路策進會有關係，而這個社團的精神領袖則首推前交大計中網路發展組組長劉大川老師了。劉大川老師從 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 →