Friday, November 14, 2014

Business Model Canvas的九個欄位

獲利時代(Business Model Generation),大概是第三個人跟我推薦這本書之後,我終於買了它。書中的Business Model Canvas讓我用更完整的方式去看一個專案或產品,以及它與市場的關係,也很想分享這個書中最重要的Business Model Canvas,讓更多人可以一起發想與設計,做出更多人們想要的商品。

前言

以往在討論專案想法或規劃時候,我們會約略感覺到哪部分有不足,而也可能在執行過後才發現有東西忽略了,即表示缺乏一個可以設計周全的方式。而書中介紹的Business Model Canvas是很好的工具,透過思考表上的每一個欄位,我們可以很清楚的讓參與人知道專案目前的定位與運作模型,同時會不斷變形與進化以適應專案發展。最終目的則是找到一個可以讓專案或是公司順利運作的模型。


內容結構

書的第一章節講述了Business Model Canvas表格中的九個欄位與對應的意義,我認為這是最重要的部。而中半段則是針對各種Model進行討論與分析,其中我認為最有趣的是在探討「免費服務/商品」是如何辦到的這部分;另外也介紹一個商業模型設計與討論的發展環境應該是如何。最後部分則是探討如何不斷適應與修正模型。


Business Model Canvas的九個欄位

把這九個欄位:發想、討論、不斷修正,專案就不會再虛無飄渺了。第一次的思考過程是可以同時依照順序的,所以在思考一個元素的時候,不需要馬上就思考其他元素互相影響的關聯關係,可以建立在前一個元素上往下思考。(我照自己的解釋方法翻譯成中文,可能與中文版的不同)

A. 目標客層(Customer Segments):要賣給誰?

首要,必須將客戶對象描述的非常精確,什麼樣的人?年齡層?區域?他可能是「大眾市場」、「部分小眾市場」、「多元化市場(兩種無關的客戶層,如Amazon提供網路書店與雲端伺服器)」或「多邊市場(面對兩個以上互相需要彼此的情況,如點餐系統須要有使用者與商家)」。

B. 價值主張(Value Propositions):要賣什麼?

就是要賣的商品或服務是什麼?有了目標對象之後,我們便要思考我們是要解決他的什麼問題,所以要提供他什麼樣的東西。這個東西的特色可能是:新穎的、比以往效能更佳的、或是更加便利等。

C. 通路(Channels):透過什麼方法賣?

要賣的商品或服務如何傳達到我們的目標對象?直接的銷售,或透過合夥的間接銷售。這兒有個有趣的點,注意到傳達過程不單單包含「購買」這個行為而已,應該依序為「認識品牌與產品」、「評估產品」、「購買」「傳遞價值主張」、「售後服務與關係」。

D. 客戶關係(Customer Relationships):跟客戶的互動關係是什麼?

客戶看到的除了商品之外,還有這家公司與他互動的行為,即是客戶關係的範疇。可能提供個人協助(如電話客服)、自助式(如洗衣店)、自動化服務(如網站購物推薦)、社群(如小米手機的米粉們)或共同創造的關係(如YouTube讓使用者提供內容)。

E. 收入(Revenue Streams):賺多少錢?

恩,就是以上的元素拼湊起來之後,哪部分可以賺錢?而又是賺多少錢?它可以是銷售費(賣多少賺多少)、使用費、會員會費、租金、授權費或廣告費等。就算是提供免費的服務,也一定會有其他Value Propositions可以賺錢,不然必定無法維持。

F. 關鍵資源(Key Resources):我有但別人沒有的東西是什麼?

在執行的過程中,我們的不可取代性是什麼?當遇到對手時,客人一樣會選擇我們的原因是什麼?是因為我們有別人所沒有的金錢資源、人力資源或智慧財產等?

G. 關鍵活動(Key Activities):為了維持以上東西,需要做什麼?

模型快要想好了,但是為了實現模型的內容,我們應該要做什麼事情來維持?例如要生產產品、要廣告產品、要維護平台運作等。這個欄位是要列出我們要做的事情。


H. 關鍵合作夥伴(Key Partnerships):夥伴有誰?

這部分其實是選擇性的,也可能沒有夥伴。但夥伴的存在可以協助我們降低風險、取得特定資源等。

I. 成本(Cost Structures):要花多少錢?

最終,為了維持所有上述的事情,需要支出多少,包含固定成本與變動成本等。當然,成本如果大於先前討論的收入,整體而言就是賠錢(但不代表不能這麼做)。



結論

透過思考以上九個欄位,再與其他人不斷發想與修正的方式,可以讓專案的發展更完善,做錯事情的機會降低,或是看見先前忽略的部分。很多有經驗的人可能早已內化這些內容,但是若能畫出來放在白板上,大家可以更明確的同步腦中想法,或是做下一步的討論。

Monday, August 4, 2014

Carnegie Mellon University 卡內基美隆大學

在幾次和同學聊天的過程中,發現仍有滿多人不認識這所學校,於是透過這篇文章介紹,同時也讓自己更認識CMU。關於CMU的資料不論在學校網站或Wikipedia上都十分充足,而在此我是將台灣學生較關心的一些「事實」列出,並附上值得閱讀的參考資料。


簡介

  • 中文名:卡內基美隆大學
  • 英文名:Carnegie Mellon University
  • 位置:Pittsburgh, Pennsylvania, United States (美國, 賓州, 匹茲堡)

  • 校訓:"My heart is in the work."
  • 成立:1900年

學院

  • 科技工程學院 Carnegie Institute of Technology
  • 藝術學院 College of Fine Arts
  • 人文暨社會科學學院 College of Humanities and Social Science
  • 工業管理研究所 Graduate School of Industrial Administration
  • 公共行政管理學院 H. John Heinz Ⅲ School of Public Policy and Management
  • 自然科學學院 Mellon College of Science
  • 電腦科學學院 School of Computer Science

校友

  • 詹姆斯·高斯林 (James Gosling): Java程式語言發明人
  • 安迪·貝托爾斯海姆 (Andy Bechtolsheim): Sun Microsystems共同創辦人
  • 吳恩達 (Andrew Ng): Coursera創辦人、參與Google Brain與「百度大腦」計劃
  • 交大資工系吳毅成、吳凱強等教授
  • 19位諾貝爾得獎者
  • 12位Turing Award得獎者

排名

  • QS World University Rankings (2014):CS世界4名
  • Academic Ranking of World Universities (2013):CS世界6名
  • U.S. News & World Report ranks:CS研究所第1名
  • 華爾街日報(2011):CS第1名
簡而言之就是Computer Science中優秀的學校,以下是之前Facebook創辦人到CMU訪問的一小段影片:


傳統

  • The Fence(籬笆):學生用手油漆上一層層東西在籬笆上
  • Spring Carnival(春季嘉年華):「Buggy Sweepstakes」是嘉年華的特色,學生把人裝進小的輪車中,看誰在最短時間滑下山坡
  • Mobot(機器人比賽)

參考資料


Thursday, July 31, 2014

你為什麼不踩草皮?


我們大學校園的中央有塊草地,位置在最多人的資工系工程三館與圖書館之間,每天經過的同學相當多,是絕大多數學生上課必經的區域。而我們觀察到每位同學都會繞過草地,而放棄比較快的方式:直接穿過。為什麼?

「因為小學老師說不能踩草地」、「大家都繞過去我就跟著繞了」、「草不是不能踩嗎?」是我問了近十個人中得到的答案,這些答案也成功順服著大家不該踩草地;然而當我們回到問題本質時,這是否真能夠清楚解釋並令人信服?

造景與美觀是我詢問多位同學之後得到這塊草地的設計目的,讓我回想起過去與設計師討論的內容,「設計必須要解決最初的問題」;而這些草地在本質上已經逾越造景與美觀的功能,儼然變成一個校園大路障。當本該只是美觀用途的設計影響到既有本質上的功能時,是否其實是一個錯誤?

曾經去過美國與歐洲,那兒草地是讓人放鬆的地方,不只是穿越,大家更喜愛在上面玩耍或曬日光浴。台灣氣候或許不同,所以從小被訓練不該踩草地;於是乎,在我們校園的例子中,同學不但少了一個可以玩耍與發揮的地方,甚至連每天在校園走路時都需要繞路。

這問題很嚴重嗎?我實際在現場測量,繞路一次會多花10秒的時間,校園有萬人以上,假設平均每日有2000人經過、在學學生與教授的時薪平均值為每小時200元、一年中有200天的在校時間,則得每年學校因為繞路而浪費掉的錢是22萬元。是的,22萬元。

不論是重新設計草地位置,或是讓大家就直接踩草地而過都是解決之道,只是這故事或許不只是草地,也投影在很多日常生活中。

我們應該當參與過沒有目標而無效率的會議、不知道為什麼而做的工作、不知道在教什麼卻還要念的書、⋯⋯,當下我們感到難受,或是已經無奈而無感,認為「因為大家都這麼做,所以我也該這麼做」或是「事情就是這樣,做了就會對了」,卻沒發現或是沒有足夠勇氣去思考問題的本質。

也許這個會議不開反而對大家都好、也許這份工作目的根本不明確而該去叫主管修正、也許這老師也不知道自己在幹嘛而應該翹課;太多的既有習慣讓我們忘記去思考問題最初的樣子,而盲目堅持。

我們正在做的事情到底有無解決到問題,意義與目標是否明確,還是只是無感的跟著大家繞過一次又一次的草皮,忘記停下來想想:為什麼草皮在這?它應該在這嗎?該踩嗎?

Sunday, June 29, 2014

PLATE點餐系統 開發手札

PLATE團隊負責人 Heron Yang 筆

PLATE點餐系統於2014年春天在交通大學第二餐廳運行一個月,累計約600位同學下載,數百位同學在系統上點餐,是由自發性、興趣與熱情驅使的在校同學共同開發15個月完成。
官方網站:http://plate.tw/,粉絲專頁:http://fb.com/plate.tw


Part 1 - 開發

2013年春,有位社團學長知道我對於專案開發有興趣,同時過去也有幾個小作品,於是找我參與他們已經有兩個人的小團隊。當時我第一個反應:「應該和先前好幾個團隊一樣,說比做還多,不會成功的」;然而第一次我們在一個借用的社團裡面見面,發現大家都很有熱情,紛紛把自己想做的題目丟出來腦力激盪,這成為了PLATE這趟旅程的起點。
蹲在社團的白板前,三個人輪流寫出自己想做的題目:Tim想做個股票相關的應用,Fucxy想做吃飯相關的應用,而我想做穿戴式裝置相關的應用;最終我們共同發現一個需求:「吃飯時候,總是不知道要吃什麼!」於是開始思考用Machine Learning整理餐點資訊後,提供點餐建議的應用,也開始構想怎樣的服務是每當吃飯時候就會想使用的;所以,我們有了一個大致的專案定位:想做一個餐飲的平台,而凡是吃飯時間,大家就會上來選餐、被推薦餐點。
當時我們在網路上做了些調查,看到Food Panda、EZTable、摩斯漢堡等類似服務,也閱讀了Peter的午餐大王夢文章,甚至實際拜訪了某個小公司的老闆,談論是否合作建制餐廳地圖。那時候我們第一次像是大人一樣的奔波,談論似乎跟商業有關的事業。
記得當時有一天,在我前往上課的路上,看到邵家健老師路過,而我知道老師在以往課堂上一直很支持學生的專案與創業,於是我便向前跟他討論起PLATE的構想,他十分激動,也告訴我們他的研究室有個相關的研究,認為這樣的應用很有需求,於是我們專案成為了老師底下的專題之一,回想起當時若乖乖去上課,而沒有為了自己想做的事情翹課的話,接下來一年半的PLATE應該壽命會更短。當我們確定目標之後,除了要有勇氣去追求,也要有勇氣去放棄。
從三月份我開始參與計劃,四月份準備開始執行開發,找了一位同學當設計(綽號Bass),幾次至半夜三點的會議決定出Logo與配色,也決定第一期開發使用者會有的功能:「查看推薦與點餐、查看列表、餐點與社交、查看點餐記錄、設定」,租了一台Linode機器,申請了PLATE.tw網址。團隊成員每個都以很高度的熱情投入,Tim把Coursera的Machine Learning在一週內啃完,而我則是把Stanford的iOS App Development的課程上了七成,也跟著寫了數個練習程式。
暑假期間,團隊一週有三天齊聚在社團開發PLATE App,每天八小時,相當高的效率也讓我們在暑假結束之前,有了一個Demo版本的iOS App可以展示,甚至還拍攝了一個介紹影片
回想起這段時間,是我們生產力最高的時期,早上構想的程式,下午能在分工下就完成並測試,那時的我認為動手做遠遠勝於嘴上談兵,每當一個想法浮現,花在討論與規劃上的時間並不多,而是埋頭寫程式,讓東西在最短時間內被生產出來。然而,也因為如此,這段時期雖然大家熱情最高,但也是做錯決定最多的一段時間,我們在往後的階段丟棄了幾乎所有這時候做出來的東西。

Part 2 - 團隊組成

時間來到九月,在與老師溝通之後,團隊極力想安排與資工系的會議,原因是我們的作品必須在更多人的檢視與支持下才合適拿到餐廳裡使用。然而,這場會議讓團隊整整等了一個多月遲遲沒有開成,我們寄了超過三封的郵件,甚至直接印出報告書投交到辦公室。當時團隊氣氛低迷,Fuxcy在一次意見不合的會議中離開了,而我和Tim則在牆上,開始畫著規劃圖,內容是會議若是開不成的Plan B、開不成也營運不成的Plan C、…,我們一路寫著至年底最壞情況的計劃。
這時Anthony加入團隊,負責Android程式這部分,也就是接寫Fuxcy原先的東西,但是當時我們並沒有持續開發,反而是找了與原本題目相關的其他小程式實作,原因是PLATE這個東西很大部分在運行上需要透過系上或學校的允許,而在會議遲遲沒開成的情況下,大家對於開發PLATE沒有明確的預期效果,怕任何的持續投資會做錯更多的事情。反之,大家對一些有趣的應用感到興趣,例如讓餐點在盤子上旋轉的特效,這也成為之後我們專題報告時的部分內容,確實滿有趣的。
終於,到了十月,系主任的信終於寄到團隊手上: “The team has my support.” 而我們接著與系上計算機中心談論伺服器與網址的問題,於是團隊又開始忙起來、回到正軌,當時的每個會議我都會演練五到十次,並很認真思考聽者想聽到的內容;雖然偶有不足,但回頭看,PLATE從最開始至今的會議並沒有失敗過。
由於PLATE也是資工系的專題之一,我們多了一個與人分享的機會:專題課。我們把影片與構想在台上報告,第一次報告結束之後,Sidney學姊前來聊天,她表示她在另外一門課的專題想做類似的系統,所以認為可以合作。雖然事後我們開過幾次會與她的團隊溝通,但最後並沒有實際的合作方式,反而寒假時,Sidney加入我們幫忙宣傳方面的事情。
而第一次在系館大廳跟Sidney溝通時,同班的Jackson恰好在一旁聽,事後Jackson表示對於我們做的東西很有興趣,也曾經構想過類似的作品,認為這確實是未來的方向,於是乎一陣子之後,Jackson加入PLATE,幫忙行銷公關的部分。一次次的機緣連成機會與可能。
當時Bass因為個人方向不同,所以漸漸離開團隊,往自己有興趣的另外一個方向走,我們開始很積極的在交大尋找可負責設計的人。先在人社一館貼了傳單,也到處詢問;最後,在人社一館的某面牆上看到一個頗不錯的App設計海報,便敲門問附近老師得知這海報的製作人Jessie,於是我們多了一位設計。我仍記得與Jessie見面時,Jackson嘗試說服她加入時候的情緒,很單純相信PLATE是一個能夠讓生活更好的平台,而且我們是那群能夠完成它的人。

Part 3 - 溝通與定位

接著,我們與學校第二餐廳的經理溝通,規劃PLATE系統營運的方式與細節,經理是這次專案中非常支持團隊的人,也表示他個人很想有這樣的系統給同學更方便的用餐環境,一直到更後期遇到困難的期間,經理也都是一樣的態度協助著團隊。反之,團隊也見了總經理,他的態度則是認為這樣的系統對於他的幫助不大,覺得在交大運行單純只是做善事幫助同學,意願並不高。
而與系上、系計算機中心、餐廳經理等的溝通過程中,團隊繼續開發第二期的App,我們把原先五個「查看推薦、查看列表、餐點與社交、查看點餐記錄、設定」功能修正後只剩下一個功能:「點餐」。團隊認為點餐是提供所有吃飯相關服務的基礎:透過點餐,我們能夠知道所有人對於餐點的喜好,未來得以推薦餐點;透過點餐,我們可以與Facebook結合,分享餐點引起話題,同時協助商家廣告自己;透過點餐,我們得以擁有使用者對餐點喜好最正確的資訊,夠過分析之後可以提供給商家,以做顧客市場分析。
同時,我們也曾在暑假把PLATE的構想與學校外圍的商家分享討論,發現大部份的商家對於這樣系統並沒有太大意願使用,首要原因是它預期帶來的負擔大過於獲利,其次則是上頭充滿太多的未知數,甚至一開始系統上並沒有使用者。於是,團隊認為應當從學校開始,透過系上老師的指導,並以學生的身份,對於失敗的容許度較高的方式進行第一次的營運,這也是PLATE最先投入在交大第二餐廳的原因。而既然我們在第二餐廳,透過點餐系統,首要要解決的即是「排隊問題」,我們認為學校內的餐廳每到用餐時間,全部的人都塞進餐廳 “Busy Waiting” 導致人山人海,甚至遲遲吃不到午餐,而我們的解決方式是每個人應該把自己的訂單在事前送出,而只有當餐點完成的時候,被 “interrupt” (即被通知之意)來現場領餐。
在Jackson的安排下我們跑進數個大班教室(如微積分課)內發問卷調查,發現校內約莫85%的人使用Android智慧手機,而非iOS,於是決議把團隊開發的所有成本只專注在Android App,把暑假的iOS程式完全擱置;同時商家介面從原先的網頁版本改成Android App,往後運行在思源基金會贊助我們的平板電腦上。我們稱暑假開發的iOS系統與網頁版商家介面為PLATE Demo版本,而開學後新開發的這個版本為正式版。然而,這個正式版,必須先經歷接下來的Alpha與Beta測試。
終於,我們在年底透過經理招集了第二餐廳的所有老闆,齊聚一堂聽我們報告並展示PLATE,猶記得會議的前一天,商家的Android App第二個頁面的介面仍是空的還沒動工,原先認為這次展示不應該拿出實際作品,因為滿可能中途拋錨。但,老師在前一天和我們說:「就拿出來給大家看啊!壞掉也不會怎樣!」恩,也是。於是展示的前一天,我找了Tim跟Anthony: “Hey, where are you guys? We got to rock this out.” 終於,半夜我們把隔天的東西準備齊了,也做了數次排練。那天的會議,在發下去的意願單中,我們收回了全部老闆的簽名,當天晚上我請了團隊成員一頓很開心的慶功晚餐。

Part 4 - 測試

接在商家會議之後,團隊開始進行寒假期間的Alpha測試和下學期開學時的Beta測試。
寒假期間,我們撰寫簡訊認證功能、商家營業時間機制、手機GCM通知、設定HTTPS、設計PLATE.tw官方網站等等,然後在最後團隊大家齊聚一起在多隻Android手機上反覆操作以發現問題,同時也邀請幾位朋友到場試用,聽取並記錄所有的建議與批評,這段期間是我們的Alpha測試期。
下學期開學的前兩週則是Beta測試,第一週邀請朋友加入測試,約莫30位同學,實際體驗透過PLATE系統在手機上點餐後到現場領餐的流程,那時候我們擔心會出現亂子,於是是一家家開放測試,同時團隊與商家建立合作方式,協助他們使用系統,共同商討人力安排與動線安排等事宜。
Beta測試這段時間是我個人在PLATE開發過程中最辛苦的一段時間,必須同時解決程式問題並上去修改程式碼、討論現場動線問題、與商家溝通並安排每日的測試內容,也同時與我們的第一批使用者溝通、蒐集他們的批評後修正。這段時間原先對團隊很有貢獻的Tim出國交換,而留下一份寫好的合約書,只要測試完成之後,隨時可以跟商家簽合約後開始正式營運;然而,這也成為那時的壓力來源,Beta測試的工作與所需能力已經在我能負荷的邊緣,而是否應該直接接著簽合約?
猶記得當時反覆被詢問:「如果出現任何問題與糾紛,誰負責?」理論上,團隊站在一個想改變現狀、解決問題的角色上,所以挑戰這樣的專案,對我們來說,成敗相對其次,而比較在意的是我們今天認為可行的PLATE,我們是否有使儘全力去嘗試。而誰負責?我想了很久之後,我想是我該負責的,而這樣的責任其實並不大,只是太害怕改變與嘗試的人放大了這個問題,想讓人畏懼之後繼續保持原樣而已。
兩週的Beta測試是頗成功的,我們在期間修復數個小問題,而並沒有大問題讓我們停駐,於是我們想把PLATE拉到另一個階段,然而在此時才發現忘記需與學校相關單位溝通,所以開始安排與總務處的會議。那是一場頗大型的會議,團隊約五人到場,加上老師與總務處逾十位的相關人員,我很真實的展示PLATE的構想與Beta測試的情況,總務長也很清楚地表示這場會議並不討論細節,而只是決議學校是否支持點餐系統的運行;在會議接近尾聲的時候,我聽了很多預期中的問題與討論,做了簡單回復之後,我說:「我知道PLATE要運行會遇到很多困難,也會被質疑很多問題,但我們也同時很清楚,這樣的系統今天我們不做,不久之後會有人做,而我不想看到這樣」大家沈默一陣子之後,總務長說:「好,那準備差不多要推出時跟我們說」。

Part 5 - 再溝通

總務長點頭之後,團隊本以為事情會變得順利,然而實際上卻變得棘手了。學校的執行單位事務組與我們開始會面與討論,團隊不斷被問:「如果太多人用爆掉怎麼辦?」、「現場有糾紛怎麼辦?」、「開放中午時段會不會很亂?」,感謝Jackson有耐心的一一回復這些問題,而我當時則覺得這樣的做事方法與團隊的本意衝突,我們是一個在嘗試改變,且願意接受失敗的一群人;相對的,學校人員則希望讓不確定性與風險降到最低,尤其害怕會有人客訴。
而這樣的溝通衝突,導致團隊人員都很疲倦於回答太多預設情況的問題,無奈於太過保守的做法,且溝通時間不斷拉長,本認為三月可以接在Beta測試過後把系統推出,卻至四月多遲遲沒有定論,過程中團隊也需要跟學生議會組織溝通,回復議會的提問。而,學校希望系統限制人數、限制商家數目、關閉尖峰時間等,都成為我們更之後運行時的潛藏缺陷。最終決議,我們需要關掉中午尖峰時間後開放系統。
這段時間有一個更棘手的問題即是二餐現場網路的問題,提供給商家的平板電腦並不適合直接使用交大的校內無線網路,原因是該網路並不夠穩定,於是從寒假開始,我們不斷在安排與討論,甚至請人評估現場佈線的方式。Alpha測試過程中,現場網路是使用3G網路,透過一個小台路由器分享給多台平板電腦,而3G網路則是團隊成員輪流去中華電信申請七天免費試用而來的。至於佈設實體線的費用實在太貴,餐廳無法在第一次測試階段支出這樣的費用,於是在校內加設無線路由器應當是最佳的方式。然而,我透過郵件與事務組嘗試溝通此事宜時,Jackson從事務組回來後說:「他說你信用詞錯了,不是我們計劃學校計算機中心架設,而說是我們要『拜託』他們幫忙」。
最後,網路問題學校方面表示有能力但並無意願與足夠理由幫忙,於是我們和餐廳協力處理:路由器費用由餐廳承包商支出,而網路月租費則是參與商家分擔。第一次聽到這個訊息時,我其實是相當難過的,這些商家是第一期願意和我們共同承擔風險改變現狀的人,而開發過程中我們也都堅持團隊自行負擔第一期的營運成本,包含開發、現場人力、維護等,而配合上思源基金會贊助的機器與學校的幫助應該可以讓商家無壓力的參與第一期的開發,而卻事與願違。
這段時間,我很高興團隊成員的耐心,有時候當我發現溝通時間已經超過預期時,Tim或Jackson都持續在安排下一步,Anthony與Jessie也在需要的時候替系統問題進行修正。PLATE團隊像是在燃燒的搖滾魂,遇上保守的學校單位,我們最終在火焰殘存之際,爭取到校內的公開營運的許可。

Part 6 - 營運

本來的有四至五家餐廳可以參與第一期的營運,然後後來因為網路架設因素,只剩下三家持續合作,分別是米克Q手調飲料、八方雲集與麵朝。而營運時間必須依照與學校的協議,把中午尖峰,也是效果最好的時段關閉。團隊開始致力於粉絲專頁的宣傳與現場動線的告示牌等事務,然後讓系統在2014年5月1日正式上路,開放讓全校同學下載使用,我自己則是常常閒空時待在餐廳角落觀察使用情況,順道聽路人對於系統的看法與八卦。有了Beta測試時的經驗,我覺得並沒有太需要擔心的部分,而聽取到的建議與批評不論好壞跟激烈與否,我都會記錄下來然後冷靜思考,很多部分其實窒礙難行,但我也去思考問題的根本。
商家網路在營運初期頗正常,然而來到第三週漸漸出現問題,因天氣變熱,小台的3G網路無線分享器頻頻過熱關機,團隊成員每日三不五時就需要到現場維護並解決各類問題,漸漸大家疲倦了,而網路的根本問題並不能得到解決。同時,系統設計上的預定功能仍欠缺設定領餐時間的機制、商家數目不夠多、需求量高的尖峰時間卻被關閉系統等原因,讓我們決定提早結束營運。無期限凍結PLATE專案。
PLATE點餐系統成軍15個月,在交大第二餐廳運行,累積有600位使用者下載,數百位同學點餐成功。PLATE的網站與可查看菜單的App仍會持續在市面上讓大家看見,以待未來有日可以繼續經營。

Part 7 - 謝謝,我學會了

PLATE結束了,但我卻是很高興而滿載而歸的。這些數千字的文字仍是無法傳達整段歷程的點點滴滴,一路上給予我們挑戰的人很多,幫助我們的人更多,從思源基金會執行長周吉人不求回報的贊助我們五台平板電腦,到老師不斷激勵並給予我們希望,再到團隊成員以熱忱工作一整年,支撐著整個專案運行。更值得我特別的感謝的是Scott學長,一路上也跟著我們一同商討並解決問題,幫助PLATE的Server Code的架構與後來的各種測試,以及Android App和伺服器通訊的網路行為等,還有在團隊決策上的建議;曾經好幾次我們堅定自己的想法而沒採用Scott的建議,卻在最後踩到地雷爆炸時才發現Scott講的是對的。
這次旅程我也接觸了很多人,團隊與作品或許不能一直順遂,但是人脈卻是可以永遠經營。到了近期,總是會持續遇到一樣抱有創業、創新想法的人,我都會盡力很開放的與他們聊天、交換意見,分享總是讓我更富有。
當然,PLATE最終沒有繼續,但對我來說,「如果要集滿十次失敗,才能換一次成功」那我已經收集了第一次了!這裡,我想條列出幾點所學:

一、別想自己負責全部

記得第一年春天,蹲在借用的社團裡面討論專案時,我覺得自己很能寫,可以在短時間內把想要的東西寫出來;也覺得自己會設計,想參與所有的設計;更覺得自己會規劃,所以希望計劃能照著想像中的樣子運行。然而,這也成為後期最大的問題。
直到專案漸漸走到公開釋出的階段,我發現我無法同時再掌控所有的事情,無法同時修改程式碼又安排行銷事宜,而且角色是尷尬的:站在決策者的角度,希望程式可以有更完整的功能並且沒有錯誤;站在工程師的角度,希望程式有最少的開發成本就能動。
於是,我認為在專案中,每個人應該非常清楚自己的角色與定位,也了解自己與團隊的合作關係。在往後的專案中,我會在開發者與規劃者之間擇一,然後把分內的工作認真且抱有熱情的完成。

二、少,然後精

“Be a thinker, I said to myself.” 想法來自極簡主義,一家公司、一個App應該都只有一個簡單卻確切的目標,而當我們覺得目標不只一個,同時還想要很多東西、很多功能的時候,表示我們想得不夠清楚,也不夠了解自己的定位。
PLATE一開始想要有推薦系統、人工智慧的餐點分析、點餐與社交等功能,但實際上我們發現真正想要的是點餐。而PLATE的關係架構中,除了團隊內部成員,還有老師、校方、系上、餐廳、餐廳承包商等,關係複雜於是難度高、溝通成本高,在沒有足夠能力簡化這樣的狀況時,我們漸漸失去專案的掌控權。
我認為在往後不論新專案或是任何的規劃,都必須思考到非常深,方知道問題的核心,然後夠過最簡單的方式專注於核心問題,並解決之。

三、再想多一點

當事情變得複雜時,我們往往難以全面分析,並找出所有事情的邏輯,於是容易一看到可行的做法就埋頭苦幹。然而等到抬頭發現這其實根本沒有在解決問題時,我們必須把做錯的事情都丟棄,從頭再來。
PLATE初期的程式不到半年就全部丟棄改版了,原因是我以為自己能把iOS App寫好,但忽略其實用iOS的人相對少數;當過多的會議時,我們常常會忘記自己的速求,更忘記我們必須隨時在會議中思考別人的立場並爭取最好的共識。
所以,一樣的, “Be a thinker, I said to myself.”。

四、拿掉個人情感

這是很殘酷的,但必須這麼做,否則會結局會更慘。當我們在做決策時,往往會帶入心理因素,像是:「已經做很久了,應該繼續撐一下就好」、「我相信這問題不是大問題」等;然而事實告訴我們,我們必須徹底的無視這些心理因素,然後把所有影響決策的因素理性的攤開,再做出決策。
PLATE開發過程中有很多預設的心理情感導致錯誤,例如:我們認為團隊已經做的非常辛苦了,所以必須在最短時間,縱使答應學校各種系統限制也要把半殘的點餐系統開放;最後,事實其實跟我們的直覺是幾乎一樣的,關閉尖峰時間、少量商家,所以想用的人很少。而心理因素讓我們甚至忽略本來的直覺。

五、成本,越低越好

如PLATE這類的創新應用,成本永遠是越低越好,過程中有很多的選擇讓我們想嘗試較高成本、較長期的做法,然而長期的做法其實並不適合。原因是創新專案開發(或者你想說創業也可以,但我並不喜歡這個名詞),我們一直在跟時間賽跑,如果這一期的期限到了、錢用光了、人累了(人力成本花光了)沒有達到預期的效果(獲利),而就無法跑到下一個階段,專案會被停止而失敗。相對的,我們必須把成本不斷壓低,讓作品可以在時間內進入下個階段,然後在下個階段才有另個階段的投資,提高作品的完整性與性能。
PLATE開發過程中,我們曾把Demo版本完全放棄,而開始撰寫新的Android App,也放棄當時Web App這個選項。而今回頭看,我認為Web App是比較好的選擇,雖然犧牲掉更好的使用者經驗,但對於最初期的開發,重點是在東西是否能夠快速修改,並且有足夠的力氣去應付後來的麻煩事。Scott當時給我們的建議是:「沒大問題就別改」,可惜當時沒有聽進去。

Part 8 - 後記

「PLATE要結束了,但是我們要深深一鞠躬再下台」我和Tim這麼說,那時大家都已經很疲倦在處理現場的問題,卻得不到對應的成效。我們做出了最後一次的規劃,把參與人員一一列出,擬定怎麼告知他們專案結束的消息,再寫信給每個參與和幫助我們的人。然後我和Tim分工把這段歷程寫成一份完整的數十頁報告,印出來之後,一一拜訪參與計劃的人,把我們的營運成果很誠實的告知並感謝他們讓我們PLATE可以走到今天。
我現在仍相信PLATE這樣的系統是被需要的,而且有非常的市場與發揮空間。點餐系統意味著希望使用者改變現有的吃飯習慣,先訂餐再到餐廳領餐,也改變商家習慣的營運流程,所以需要特別大的成本來驅使大家嘗試;而我認為我們之所以沒法現在成功的首要原因除了經驗不足,就是無法支持這麼大的成本。

最後那天,Tim請團隊吃了一個豐盛的晚餐,感謝所有人參與這段旅程;飯後,Tim和我待在我們平常開會的白板前:「來,下一個題目是什麼?」

Tuesday, June 17, 2014

惡作劇精神

在MIT、Harvard、Stanford等名校,惡作劇是很常被聽見的,但這並不是惹人麻煩的事情,反而是值得鼓勵、充滿創意與反抗平凡的行為。

人很容易依循習慣而為,在安逸中漸漸忘記初衷,然後漸漸對夢想不再要求,而找了一個說服自己卻說服不了其他人的理由開始隨便。而這群搗蛋的人在提醒著我們應該要讓生活充滿創意,在有限的資源與環境中不斷創造,再把一次次的驚奇寫進人生經驗中,讓生命每一秒都在躍進。

在MIT這樣的行為被稱為Hack,而與我們常聽見的電腦Hack是有一樣精神的,都在有限的資源與環境中,不斷挑戰並創新。較為有名的例子有:1982年,Havard與Yale美式足球比賽中,MIT學生在廣大的球場中地上冒出一顆大氣球寫著MIT;2012年,這群Hackers把MIT Green Buidling變成巨大俄羅斯方塊遊戲機,還可以實際操作玩樂。

Michael Snively在他的部落格中分享了這樣Hack應該遵循的道德標準,我將它翻譯如下:

  • 要輕巧的,不要留下證據
  • 把東西歸成原樣、或是更好
  • 不要造成不可修復的損壞
  • 不要偷任何東西,而如果必須借東西,一定要歸還
  • 暴力法是最後無能的手段
  • 不酗酒再惡作劇
  • 不遺漏任何東西
  • 不獨自行動
  • 以上沒論述者,以常識判斷
能觀察到我們身邊有很多環境缺少這樣的精神,大家太過於沉浸於平凡安穩的生活;而如此一來,我們失去很多生活本來有的樂趣,也不懂得跳脫現有框框思考,最終會淪為沒有創造力的機器。於是,我們都需要有惡作劇精神,不是調皮,而是創造。

參考資料

Wednesday, March 5, 2014

QR Code實務應用探討 - 其實並不方便

QR Code是二維條碼的一種,讓使用者透過手機鏡頭掃描QR Code圖案,即可解碼出對應資訊,其中「QR」為Quick Response的縮寫,表示操作過程中,使用者不用按任何按鍵,程式會自動判讀,於偵測成功時跳出對應的資訊。常見的資訊內容有網址、通訊人資料與身認認証等。本文,我想針對放置於「宣傳品」上面的QR Code做探討。

雖然這項科技看似便捷,但我認為QR Code其實是難用的。很大一部份的人對QR Code的印象是「麻煩的」、「不直接的」等,推斷可知這些想法來自於過往的使用經驗,若進一步探討,可以專注於「為何QR Code是不直接的」這問題上。


QR Code使用情境

當我在路上看到一張海報,在截角處有個QR Code提供我掃描,而我對海報其他部分的內容感興趣,於是想透過QR Code得知更多資訊,所以拿出手機後,我需要:
  1. 解除手機密碼鎖定
  2. 找尋手機安裝QR Code掃描App並開啟(若無,需安裝)
  3. 等候開啟App的載入時間
  4. 掃描並解碼(光線不佳情況下需要較長時間才可以成功)
  5. 點掃描結果

問題一:操作流程麻煩

從以上五點可以看出,「掃描並解碼」這個與QR Code技術本身有關的部分只有占一點,然而其他流程操作卻占了四點,而這也是我認為QR Code在實際運行上其實並不方便的主要原因。
如果要嘗試解決這個問題,以上幾點步驟做修正,例如讓QR Code像是相機App一樣寫在系統內建,可以在未解鎖情況下快速開啟。

問題二:手機需有網路連線

上述情景中,我們的手機不見得處於可以連線的情況,而在實務面,很多使用者行動上網的單月流量限制各不同,有人並無行動上網功能,也有人習慣沒事就關掉行動上網功能,而若是為了QR Code掃描又開啟網路連線,耗時。

問題三:QR Code對人沒有意義

QR Code是電腦根據資訊內容翻譯過來的,但圖形內容對人來說並沒有意義,一般人也沒有辦法直接透過QR Code圖形翻譯出對應內容,於是乎,這件事情讓QR Code整合進版面設計時,讓畫面變醜,且對人並無認知上的輔助意義。

以下是同一份資訊(網址HELLO.tw)直接呈現與使用QR Code呈現的示意圖。
  

實際情況

由於實際上使用QR Code進行掃描的成本比我們本來以為的還要高(不如預期的心理狀態),所以使用者對這件事情產生負面的使用經驗,開始認為這是一件麻煩的事情。於是趨動使用者去使用的動力弱,造成其實QR Code並不多人用的現象。
現實生活中嘗試解決問題的例子許多,主要都是夠過「提升掃描QR Code」的意願(見參考資料第2, 3點),目前尚未看到是實際解決「操作流程麻煩」這根本問題的人。

參考資料

Monday, February 24, 2014

創新軟體產業,不能再錯過了

台灣已經錯過很多黃金機會了,怎麼還是沒發現已經錯過多時?

發生了什麼事?

我打開我的手機,看看我用的聊天APP。
LINE是日本開發、韓國投資的;WhatsApp是美國的,且近期被Facebook以190億美金收購;WeChat則是大陸的,最近進軍台灣來勢洶洶;那台灣的APP呢?

再看看我們最常用的網頁吧!
Facebook無疑是Mark Zuckerberg在大學時期開始架設的網頁、Google是約十歲的公司;而大陸則有人人網、百度等使用者龐大的網站;那台灣除了剛凋零的無名小站,還有呢?

那麼再來看看許多正在進行且稍有成功的新式科技:
Evernote, Pocket, Flipboard, Foodpanda, Dropbox, ...其中哪一家又跟台灣有關呢?

為什麼會這樣?

我們真的很不重視這塊!好幾次我拿著類似的想法與別人討論時,很多人總是會說,一定要有硬體才會成功,而也只有會做硬體才有深的技術底子,也是之後在個人或公司經營上唯一的路。

而我不認同。台灣現今很多做硬體的代工商,漸漸越來越辛苦,也有很多開發中國家想要競爭,而我們在這個大餅上不再俱有絕對優勢;一定要有「硬體」才是經營之道的想法早已不合時宜,如果不能改變這想法,不但不能改變現在情勢,甚至我們早已失去下一場競爭的參賽資格。

它並不簡單

重視任何新式軟體的開發,沒有接觸硬體,不代表沒有深度。而這類偏應用的程式開發,雖然風險高,但是不代表沒有長遠性,只是完全在於怎麼經營能力而已。

一路上,我接觸過各種想挑戰新想法並實現的人,但是他們總是遇到力不從心的困境,整個環境告訴他應該學更多底層的東西、選擇現今代工商上班、接受別人安排的經營方式,而想實踐一個新的想法的作為被視為是膚淺不切實際的。而我一樣不以為然。

做一個LINE、寫一個Facebook是簡單的嗎?這類的軟體開發,雖然用較高階的語言寫,但不代表程式能力要求低,在整體資料庫的設計、大型程式架構、伺服器系統資源管理等都完全不比跟「硬體」有關的來得容易,同時更關係到人、經濟、產業、文化、市場、行銷、設計、品牌等太多事情,是一件非常有挑戰性的路,絕非大部份人認為的「容易」。

小結

我覺得想經營新式科技或想法的人應該有更多人的幫助與指引,而大環境存有的偏見是有害的,台灣在代工地位上已經不如以往,下個世代的科技也已經錯過半截了,不能再繼續阻止自己成長了。

Thursday, January 30, 2014

不應該完美 - MVP (Minimum Viable Product)

「我們是不是應該把它弄到完美再推出?」

新創團隊對於產品規劃上,往往會有人提出這樣的建言,而下一句話也通常會講述哪個功能是必要、哪個事情一定要處理等理由,再提出時程延期的建議。而我一年之前也對於這類的問題感到不解,是否應讓東西更完美所以延期嗎?

回答這個問題,我思考每人都引以為鏡的公司Apple和Facebook在這問題上的解決方法。而這兩家公司恰巧用相反的方式:Apple喜歡有年度發表會,邀請記者集聚一堂,揭露沒有人能猜測的新產品,而產品的樣子在那一刻定案,是否被市場接受也在數週內可以看見成績;Facebook曾喜愛嘗試新功能(針對IPO之前的經營方式做探討),也在不斷試水溫中修正,例如Facebook Home,執行長Mark在公開演講中認為是嘗試階段,往後大家會接受,而針對網頁有時會當掉的情形,他則以「東西都會壞呀!壞了修他就好!」的態度回復。

對於Apple和Facebook的例子,可以解釋成實體產品公司與純軟體公司的經營差別,也可以解釋成形態上的不同。Apple從個人電腦最初一直營運至今,規模甚大,可以支出的成本大,於是能夠承擔若單一產品失敗的風險;Facebook則是2004年成立的Startup,且以一個大家不認識的商品進軍市場,接受度十分不確定,公司處於較不穩定且目標不明確的情況下,不易承受失敗的風險,所以試水溫成為重要的方式。

分析完Apple與Facebook的例子,我認為新創團隊應當採用Facebook類的做法,因為在沒有錢與產品接受度不確定情況下,團隊不能夠接受累積很久的成果於一次發表的時候宣告失敗的可能;相對的,透過先釋出部分重要功能的產品,再慢慢修正、增加功能的方式顯得正確,數個小失敗是可以被允許的,同時間團隊更了解市場的喜好而做修正,或是放棄一些其實市場根本沒興趣的功能。

MVP (Minimum Viable Product)與Lean Startup都是這類做法的名詞,其中MVP表示創新團隊最一開始應該推出含有核心功能的產品即可,其他部分則應該以最快的速度與最高彈性的方式完成,搶先進入市場,且更快了解到市場喜好後再修正產品。

根據以上說明,我認為創新團隊不該花時間讓東西「完美」,而是應該注重在消耗完「團隊成本」之前推出產品,盡訴確認產品是否被接受、找尋商業模型。

「不,應該是檢視我們的產品是否達到MVP的功能!」

Monday, January 20, 2014

[Plate團隊參與筆記] 沒有無用的人,只有無能的領導

Plate團隊發展至今,有新成員加入,也有成員離開,每位參與人對團隊的期許與想法都不同,但大家都清楚知道團隊與自己的關係。對我們來說, 最重要的不是找齊全世界最強的人,而是讓所有參與人獲得最合適的位置,愛上自己的工作,然後組織出最堅強的團隊。過程中,每個人都是獲利的、開心的、熱血的。

團隊運行過程中,我們會針對缺乏的部分對外找人幫忙,同時也檢視內部成員是否都有不錯的參與情況,而對我來說:「如果一個人,沒能幫助大家,提升整體效力,不是因為這人能力不佳,而是他做錯了工作!」我們要做的不是責備也不是抱怨,是需要重新檢討工作分配,讓每個人做自己喜歡的事情,然後自己的貢獻幫助了整個團隊或產品,獲得參與感與成就感。

試想自己有一份工作要完成,它是一件雖能力可及,但卻厭煩而無心再認真做的工作;相對於一份新鮮的工作,上頭有很多新奇的事情讓我想嘗試。雖然不論是前者或是後者,透過一開始的合作共識,應該都能在時限內完成交差,然而可以明顯知道後者可以帶出較好的成效,做出來的東西較有生命力。這並非一面倒的法則,卻解釋不能單從一個人的履歷、就讀的系所或經歷給予工作,應該實際溝通,聽他想做的事情,然後找出對應的工作分配。

實例中,看過一些成績好的資工系學生其實更適合負責非寫程式的工作,而同樣是程式開發者,也有人對於產品外貌感興趣,有人則只對技術有興趣;若是我們逼著只對技術有興趣的人緊跟所有產品開發,必然成為當事人與團隊的負擔。這則是一個分工失敗的例子。

從心理學的書當中,我們可以清楚知道一個人談論到自己喜歡的東西時候,眼睛會睜大、瞳孔放大,同時也會有許多特定肢體語言出現,從這本能現象中就可以判對一個人是否喜歡自己眼前的工作,再配合上個人的性格之後,組成這人在執行工作時做法與態度,而合作後若是沒有好的結果,則便是最初的分工問題。是故,我相信沒有無用的人,只有無能的領導。

Monday, January 13, 2014

目標是做決策的根本

決策,也就是「做決定」,是我們每天頻繁遇到的問題,而生活就是一連串的決策,最終走到一個目的地。小的決策可能是「先吃午餐還是先念完書」、「要不要帶雨傘」等,而大的決策則可能是「研究應該做什麼方向」、「畢業後要唸書還是找工作」等,其中大的決策可能花很長一段時間在思考,同時也會詢問很多人的建議。

最近好幾位朋友跟我聊天,都陸續提出類似的大決策問題,「我畢業後要幹嘛?」、「我應該要修什麼課,方向是什麼?」、「我該出國嗎?」等,我自己也在思考很多個類似的問題,不同問題之間甚至有很多的交互關係,最困難的點在於每個問題我們都不曾遇過,所以無法根據經驗回答,於是猶豫。

恰巧,不久前在朋友推薦下看了一本頗有意思的書:「目標」,雖說書中主要探討管理學,但應用不只在管理,甚至人生規劃等都是有幫助的,而書本中一開始的部分,探討「問題本質」的方法是我目前看到最正確解決決策的方法。

「目標」是做決策的根本。

當我們面臨很多決定而猶豫時,應該思考的是對於這件事情之於自己的目標是什麼,然後在這目標底下,我應該怎麼做眼前的決策,或是更長遠的安排,所有的問題都有了方向而簡單。

仍然以最近許多朋友和我自己都在面臨的決策為例:「畢業後之後要做什麼?」,如此問題的根本變成是「我人生規劃中的最終目標是什麼?」。每個人都有所不同,在朋友間,有人想要專研某項技術,有人想要過安穩生活,而有人想跳舞、想寫小說,社會也因每個人都有自己堅持的目標而美麗。於是乎,確定自己目標之後,畢業後要做什麼顯得容易回答:「找一個最可能到達那目標的路」。

也是在朋友之間,我看到用這方式而做很棒的人生規劃的例子:喜歡技術,所以嘗試許多開發團隊,並不斷經營自己的作品,累積的成果變成履歷;喜歡表演,所以高中多念一年準備出國,接觸並參與世界上他喜歡的那些表演人;喜歡旅行與異國風情,所以嘗試交換學生。

無形中,當我們堅持自己的目標時,做決策時的選擇變多了,更多人認為這個人就是喜歡做某項事情,所以這件事情給他做,不但他有過去經驗,也因為興趣所以可以做好。如此一來,更多的路會開啟讓我們走到本來的目標。

用於團隊管理更是如此,在短期、中期、長期需要一個十分明確的目標,讓團隊規劃上依循目標而走,也讓所有參與人都明確知道當下應該努力的事情是什麼,不會有發散的想法或做不必要的事情。

然而,也有許多與這方法較相違的例子,多來自不容易改變的「習慣」,例如唸書。從小學一路到大學,成績一直是逃不掉的話題,也很多人認為「要努力」就完全等於「要努力唸書」。但,這或許應跟自己在追尋目標中,唸書是不是其中必要條件之一有關,若是一個愛音樂的人,卻讓自己受限於念書,那是否與目標根本背道而馳?在機會成本的概念下,甚至是不斷在浪費掉自己追求目標的成本?

最後,如果自己已經清楚知道目標是什麼後,面對決策的判斷依據變為「哪個較可能帶我實現目標」,可以依據過往經驗判斷,更可以問其他已有經驗的人。再來,如果仍不能做決定時,表示選項彼此間是差不多的,其實選一個直覺對的就好,然後開始規劃下一步。

參考資料: