分類彙整:工作

關於做 Side Projects:改善點子的7個小技巧

身為軟體工程師,我通常一有空就會做些 side projects。

該做什麼樣的主題比較好呢?

久了之後慢慢發現幾個改善的點子的小技巧。跟大家分享一下。

1. 不要做大家都說「還不錯」的

不要做那種你跟別人聊過之後,大家都說「聽起來還不錯」的點子。

這種點子就是沒人在乎的點子,沒有解決任何人的問題。

做那種大家聽了都皺眉頭的點子。大家聽了都覺得有點困惑的點子。大家都覺得是在浪費時間的點子。

這種點子通常會有非常少數人聽了眼睛為之一亮。他們不會說「聽起來還不錯」,他們會說「真的嗎?可以現在就給我用嗎?」

他們甚至願意當場就付錢。執行這種點子。

先從解決極少數人真正的問題開始,然後從那裡往下走。

相關文章:http://www.paulgraham.com/startupideas.html

2. 反過來開始做

據說 Amazon 內部開發產品的時候,會先從寫「產品發表會的新聞稿」開始。

在寫宣傳稿的同時,會希望把產品描述的吸引人、貼近用戶,並且先省略技術細節。

同樣的道理,在做 side projects 的時候,有時候會不太確定自己在幹嘛?

這個時候可以反過來開始做,先寫「產品上線發佈文案」。

也就是專案做好之後,你會在 FB 或是 PTT 之類的地方,貼文章跟親朋好友介紹的那種貼文。

介紹文章寫完之後,通常思緒跟目標也會跟著清楚許多。

相關關鍵字:Amazon Working Backwards

3. 克服一個挑戰…很困難,克服兩個挑戰…幾乎不可能

不管執行哪種點子,幾乎都會碰上一些挑戰。

比方說經營某種平台,需要有供需兩方,那一開始到底如何起頭?(雞生蛋、蛋生雞問題)

比方說某種創新服務,需要用戶帶著手機在指定地點做某件事(培養使用者某種全新的習慣)。

克服一個挑戰就更困難了,但花費足夠精力的話,至少還有點可能。

如果是個需要同時克服兩個以上挑戰才能 work 的點子,執行起來真的會非常非常困難。

稍微轉換方向,或是簡化它。先從一次面對一個挑戰開始吧。

4. 先睡一覺,明天再說

你有沒有那種經驗,就是你朋友興高采烈的找你討論某個點子,你也熱血的急著動手做了。

結果過幾天你發現他只是一頭熱,他自己不再有興趣了,而你這段時間都是在浪費時間?

其實一個人做自己的專案也一樣,不管當下有多熱情,最好都… 睡一覺醒來再說。

把這個想法簡單寫進文件裡面。頂多稍微設計一下架構。

隔天起床還是一樣覺得很熱血嗎?那不妨… 再睡個幾天再說。

不要因為這種一頭熱把生活中其他事情排開。

大多時候你會發現,睡醒之後你對昨天的爛點子其實沒什麼興趣了。

做那種不管過了多久,都還是每天起床,會覺得非做不可的事情。

5. 洗澡的時候…縈繞心頭的事情

點子這種東西想破頭通常也沒用。為了做而做也很沒意思。

想想看有沒有在洗澡的時候常常會浮現的念頭。

那種時不時會出現,你總覺得好像可以動手做的事情。

下次這種念頭又偷偷出現的時候,不要再忽略它。

相關文章:http://www.paulgraham.com/top.html

6. 不能只比現有的 solution 好一點點,要好很多

不論想做的新產品/服務是什麼,它都必須要比現有的解決方案… 好非常多才行。

如果只是好一點點的話,用戶是不會買單的,畢竟轉換需要成本,大家會寧可用已經習慣的。

如果你要做的東西只比現存方案好一點點,你心想「試試看,推推看,也許可以吸引到大家改用我的產品」那你就錯了。

不如想清楚一點、多下一點決心:直接做一個需要多花10倍心力,但是屌打現有方案的東西吧!

相關關鍵字:Elon Musk. It can’t be just a little better than the competition. it has to be great.

7. 點子是很脆弱的,一捏就死

仔細想想就會覺得,幾乎什麼點子都不可行。

每個點子都明顯有很困難的地方,根本通通都不可行。

否定總是最簡單的。

這個做不到、那個不可行、然後沒有錢執行這個跟那個。

真的是這樣嗎?

新點子、想法、創意,這種東西永遠都是非常脆弱。用力摸一下就粉碎的東西。

不如養成一個習慣:不論是聽起來再怎麼糟糕的爛點子,都留給它一點點點點的生存空間。

再讓它存活一下下。過陣子再想一下…真的不可行嗎?…確定嗎?

真的有這麼確定?你到底是為何可以這麼確定?

再保持野心一下下,再調查研究一下下,也許你會發現,其實有你可以動手的空間。

相關文章:http://fortune.com/2011/10/24/jonathan-ive-on-steve-jobs-and-the-fragility-of-ideas/

(完)

遠端工作溝通技巧:被動式溝通,多層次溝通

遠端工作三年(在公司 remote 工作兩年,之後接案工作一年),發現這樣工作確實可行,而且能夠鼓勵專心工作,很適合現代各種需要專注的職位。

不過「團隊成員都能專心工作」跟「彼此溝通變得困難」是一體兩面的事情。

要有效率地遠程辦公,至少需要兩項技巧:「被動式溝通」與「多層次溝通」。

溝通習慣的改變:從「主動式」轉換為「被動式」

拍同事的肩膀問問題、叫他過來開會、打電話給他…等等,屬於主動式溝通:以發問的人優先,被問的人配合發問的人的時間。

貼便條紙給同事、張貼事項在公告欄…等等,屬於被動式溝通:以被問的人優先,發問的人配合被問的人的時間。

被動式溝通以被問的人、接收訊息的人為主,有空時才答覆、做出反應。

遠程工作的團隊一定要習慣被動式溝通,否則遠程工作就沒有意義,也沒有效率,會變成很痛苦的事情。

網路時代讓被動式溝通輕鬆許多,只要採取多層次溝通就行了。

多層次溝通

多層次溝通指的是依照主動/被動程度的不同,分成至少3-4層溝通工具。舉例來說:

  • 即時溝通:見面、手機/Skype/Hangouts/Zoom 通話
  • 通訊軟體:Skype、Line、Facebook Messenger
  • 工作聊天室:Slack
  • 任務管理軟體:Bitbucket/Github、Trello

即時溝通是最主動的一種,碰面開會、打電話等等都算。在很多情況下,還是需要用這種方式討論、腦力激盪。最好每天約個固定時間線上通話一下。

通訊軟體則是次之的溝通方式,但因為訊息通知會一直跳出來,還是有點干擾。

工作聊天室是最常發生溝通的地方。這類工具的特色在於,忙著工作的人,可以直接把聊天室關掉,就不會被打擾。有空時再打開來看看有什麼需要回答的、討論的。

任務管理軟體是大家一起紀錄工作待辦事項的地方。需要日後方便翻閱的東西都記在這裡。

其它工具軟體像是 Google Docs、Google Sheets、hackmd 也都非常好用。

採用被動式溝通、多層次溝通需要練習、需要時間習慣。這邊跟大家分享兩項個人心得。

被動式溝通優先,非必要不使用主動式溝通

上面提到的多層次溝通模型,越上面是越主動,越下面是越被動的溝通方式。團隊成員要慢慢習慣,非必要別使用主動式溝通。沒那麼急著得到答覆、急著需要處理的事情,就盡量用被動的手段溝通。

話雖如此,每天慣例性地在固定時段通話一次,可以大幅增加團隊的安全感。

每次開會都做線上筆記,所有檔案都對所有人公開

因為大家沒待在一起,開會完忘記會議細節的話,會需要一直詢問同事,很浪費時間也很煩。

所以開會時建議使用 Google 文件、hackmd 或是其他可以共同編輯的軟體,開會的時候一邊做線上筆記。

然後這些文件最好公開給整個團隊的人看到,讓全部資訊同步到全部人腦中。

這些技巧熟練之後,團隊成員不但可以專心工作,溝通能力也會全部上升。

像是跟客戶、合作廠商溝通這種本來就需要遠端溝通的任務,remote 工作者也比一般的工作者更知道怎麼溝通、避免溝通誤會。

(完)

軟體工程接案技巧:「週薪式兼職」報價

最近接網站開發的案子,特別是新創團隊的案子,我發現用週工時的兼職方式報價,比報固定價格的傳統接案方式好很多。

報價方式會像這樣:

  1. 接案者每週工作 N ~ M 個小時
  2. 每週收費為新台幣 X 元
  3. 預估案件大概 Y 週會做完
  4. 每 Z 週結帳一次

N、M、X、Y、Z 的原理如下:

  • 根據案件的困難程度、急迫程度來決定 N、M、X
  • 要讓案主知道估計的總花費,所以要估一個 Y
  • 接著由雙方的互信與方便程度決定 Z

這種報價方式看似含糊曖昧、對雙方來說都有風險。實際上卻正好相反,它比傳統報價方式符合雙方需求得多,也比較符合現實狀況。

舉例來說,我最近一次替新創團隊做網站的接案對話如下。我先說明報價方式:

111

接著補充說明一些:

222

案主很爽快的答應了,後續也進行得非常順利。這種兼職方式解決了傳統報價方式會遇到的3個問題:

  1. 需求與規格不必在事前定得非常清楚
  2. 消除案主的訂金恐懼、消除接案者的尾款恐懼
  3. 以連續多個較小的承諾培養互信,取代一次性的大承諾

需求與規格不必在事前定得非常清楚

軟體工程幾乎不可能準確規劃規格與細節,因此案件總金額、總工時根本估不準。

按照傳統的方式,雙方只能各憑經驗,討論出一個價格。這價格簡直是兩邊各猜一個數字之後妥協的,一點都不準,價格很少是公平的。常常導致接案者覺得自己被凹了,或是是案主覺得自己被當肥羊宰了。

其實,對很多案件來說,特別是新創團隊的案件,這種固定價格式的接案本來就不合理。

現在創業的商業方法論,講求執行、靈敏。趕快先開始,過幾天有新想法、新功能想做,再調整開發的優先順序。需求與規格本來就會跟一開始不同。

接案者要案主一開始就把規格訂得非常清楚,實在是強人所難。

而這種情況下,案主在一開始就想確認一個絕對數字的預算,也是強人所難。

除此之外,光是為了報價,就必須花一堆時間確認規格、需求。這些開會討論的時間成本很高,卻又不可能跟案主說「我給報價是要收費的」。

於是接案者為了保護自己,會演化出一種習慣:防禦式報價。

那就是把情況都往壞的方向預想,一律只給偏高金額的報價。這對整個接案市場都不是什麼健康的事情。

週薪式兼職不會出現防禦式報價。只要大致溝通一下需求,接案方大概了解情況,馬上就可以開始動工。

消除案主的訂金恐懼、消除接案者的尾款恐懼

對案主來說,什麼都沒拿到就要先付訂金,還經常是總額的1/3到1/2,壓力不小。

對工程師來說,一大部份費用卡在尾款,還有可能一拖再拖,結不了案,同樣可怕。

每 Z 週結帳一次,雙方觀察對方的時間多了許多,不用再賭人品。

以連續多個較小承諾培養互信,取代一次性的大承諾

傳統接案方式,雙方可能從頭到尾都彼此怕怕的,因為兩個沒合作過的人,要在一開始就互相綁定一個大承諾,也不知道案件會不會進行順利、對方人品到底怎麼樣。

而週薪式兼職,對案主來說,最糟的情況就是幾週之後工程師擺爛失聯了,損失幾週的錢。就算這樣也比傳統報價方式搞砸時,損失50%總金額的訂金好。

對工程師來說,最糟的情況就是定期結帳時,案主不付錢失聯了,損失幾週的錢。就算這樣也比傳統報價方式搞砸時,損失50%總金額的尾款好。

這種方式不但可以逐步培養互信,也對溝通很有幫助。

因為雙方每 Z 週必須真實面對彼此一次(付錢/要錢的時候,就是真實面對彼此的時候)。有什麼誤會都會被迫儘早說開,不會拖拖拖好幾個月,到要結案才發現雙方距離彼此期待差超多。屆時的誤解跟憤怒都會高到無法溝通了。

結語與經驗分享

本文一開始提到的接案經驗,雖然規模很小(我1人+案主方2人參與),但是執行得非常順利、非常愉快。連一開始的報價我都只看了一份 UI 的 pdf 檔一眼,5分鐘就給出報價。

我們甚至連合約都沒簽,隔天就開工,只花費 4 週就完成了這個案件。每週見面1-3次,搭配頻繁的線上討論,總金額新台幣 48,000 元。一點浪費時間的感覺都沒有,是一次非常理想的商業合作經驗。

下次接案、發案時,碰到傳統接案方式的困境的話,不妨以這種方式接案、發案,根據個別情況調整一下 N、M、X、Y、Z 參數即可。

傳統合作產生的商業糾紛,或許只是 pricing model 的問題而已。

附註:為什麼工時是區間、不是定額?

跟案主見面開會完之後的閒話家常,算不算工時?
工程師通勤去開會的時間,算不算工時?
工程師吃晚餐、出門散步的時候腦中在想演算法,算不算工時?
案主要求的技術工具太有趣,工程師自行額外看了一堆進階文件,算不算工時?

每件小事都要定義清楚算不算工時,有點不切實際,對雙方來說都很煩,而且斤斤計較這些東西有點傷感情。區間讓案主、接案者雙方都更自在。

不如承認這點曖昧性,兩邊都知道會有彈性,彼此守住一些議價的立場就好了。而且是區間的話,你也不用一直拿手錶計時了。每週抓固定幾個時段工作就差不多了。案主也不用每次開會要一直看手錶了。

除此之外,區間工時可以保護接案者的時薪高低的彈性。未來再接案時,你會有立場在 X/N 到 X/M 附近的範圍報價。

(完)

Ethereum 智慧合約佈署初體驗:數據與成本分享

正式佈署一份智慧合約是什麼感覺?

它的佈署速度、佈署成本又是多少呢?

我親自跑了一次流程。分享一下實際的數據與心得。

發行個人專屬加密貨幣:阿川幣

我直接拿官網的範例程式碼來修改參數,發行阿川幣:

https://ethereum.org/token

官網提供兩份範本,一份只有基本功能,一份具備進階功能。

以太錢包預估了基本合約的佈署成本是 0.000715604 ether(約合新台幣 22 元):

erc20

而進階合約的佈署成本是 0.001010363 ether(約合新台幣 31 元):

advanced

我選擇佈署基本合約就好。輸入參數之後,會發現成本微幅提昇到 0.000777146 ether(約合新台幣 24 元):

with-parameters

按下 DEPLOY 按鈕,會確認密碼,並顯示預估成本 0.000777146 ether 是因為預估耗用 777,146 gas,並且多準備 0.0001 ether 作為緩衝:

gas-usage

送出後,以太錢包會顯示 etherscan.io 網站上的交易連結:

https://etherscan.io/tx/0xcedd9b10deb6ca64b44a547244045383d4563f916849c005308453d939f69c51

大約 6 分鐘後,網頁上的交易狀態顯示為 success:

6-min-success

不過以太錢包內還沒有同步顯示完成。再過 4 分鐘,也就是大約 10 分鐘後,以太錢包上才顯示 created:

10-min-success

進入帳號底下查看,會看到 2,100 萬枚阿川幣正確顯示,代表合約佈署完成了。

我本來有 0.01 ether,現在剩 0.009222854 ether,所以的確是被扣款 0.000777146 ether,以太錢包的預估成本是準確的:

final-balance

並且可以查看合約的地址,合約的原始碼也在裡面:

https://etherscan.io/address/0x03f6a68baf85840a513a71f49f5f8fb1edcf27f6

心得感想

這次初體驗,以個人用戶來說,我認為佈署速度不算太慢(約 6 – 10 分鐘),手續費也還行(約合新台幣 24 元),都還 OK。

所以佈署這種範例程式碼等級的合約,不困難,也不昂貴。

可以以此為基礎,再進一步研發更複雜的智慧合約。

至於智慧合約的未來到底有多少潛力?其實沒人有把握。

還是建議有心參與的朋友,保持懷疑精神,建立自己的觀點跟看法,不要輕信任何人的說法。

(完)

以太幣購買與傳送初體驗:數據與心得分享

購買與轉帳加密貨幣,究竟是什麼感覺?

它的交易速度、交易成本又是多少呢?

我親自跑了一次流程。分享一下實際的數據與心得。

在 MaiCoin 註冊帳號

我選擇的加密貨幣是以太幣。

台灣能購買以太幣的管道不多,查詢之後決定使用 MaiCoin 的服務,因為可以在萊爾富繳費。

https://www.maicoin.com/

原本只想買個新台幣 300 元,但發現 MaiCoin 規定單次購買至少要滿 0.05 枚以太幣,當下約合新台幣 1,806 元。

所以我用這數字下單了,確認後取得了萊爾富的繳費代碼。

因為匯率波動太大,MaiCoin 提醒我要在 15 分鐘內繳費,否則可能以新匯率計價。

在萊爾富使用代碼繳費

我到萊爾富時已經超過 15 分鐘了,使用 Life-ET 代碼繳費,萊爾富收取手續費 20 元,總計支出 1,826 元,繳費完成。

在 MaiCoin 確認交易完成

回家打開 MaiCoin 網站,馬上確認了繳費完畢,並顯示我帳號擁有 0.04984127 枚以太幣。因為匯率變動,我受到了小小損失。

111

使用 Ethereum Wallet 建立帳號(address)

MaiCoin 上的以太幣是記在 MaiCoin 底下,為了建立一個正式的以太坊地址,我使用了官方的 Ethereum Wallet 建立帳號,並取得地址。

從 MaiCoin 傳送以太幣到我的 address

MaiCoin 規定傳送的以太幣數量至少為 0.01。

確認之後,明細會顯示處理中。

222

在 etherchain.org 確認交易內容

MaiCoin 約 11 分鐘後通知我,確認交易完成。

我電腦上的 Ethereum Wallet 需要下載完所有區塊鏈資料(目前約為 55.1 GB!),才能顯示我的帳戶餘額。

不想等這麼多資料下載完,所以我去 etherchain.org 上確認區塊鏈內容。

區塊編號  4992415 ,實際交易時間約為 9 分鐘。

https://www.etherchain.org/tx/0x37f3597ee17754494ba88e732f6ff32ed604b18fac9e786071089ea773d39501

交易內容 0.01 ETH ,約合美金 $12.31。

交易手續費 0.00084 ETH,約合美金 $1.03,這費用是由 MaiCoin 支付,沒有扣到我身上。

55 GB 資料下載完後,我也在錢包上看到了餘額 0.01 ETHER 沒有錯。

333

心得感想

這次初體驗,以個人用戶來說,我認為交易速度不算太慢,還 OK,手續費也還行。

但是作為投資則非常困難,除了手續費之外,在 MaiCoin 上的匯率跟國外交易所的匯率也有差別。

整體說起來,想到這段金融過程,幾乎沒有銀行或是政府機構介入,而是由全世界各地的電腦一起完成,確實感覺區塊鏈科技滿酷的。

但許多 ICO 相關詐騙、根本沒用的區塊鏈假應用、三不五時傳出的交易所危機等等,讓人不得不保持戒心。

建議有心參與的朋友,以學術精神,保持懷疑,勇於懷疑,建立自己的觀點跟看法,不要輕信任何人的說法。

(完)

dog

搞懂為何設定 React、JSX、ES2015、Babel、Webpack 的學習筆記

學習 React、JSX、ES2015、Babel、Webpack 等等現代化的前端開發觀念時,會需要安裝很多工具、設定多個檔案、用到許多指令。

大部份教學文章只講「怎麼設定這些」而沒說明「為何要設定這些」。照著做完感覺很不放心。

最近我試著搞懂「為何要設定這些」,跟大家分享一下這個逐步搞懂的過程。

前言

這篇文章假設你想要開始用 React 開發,希望搞懂相關的前端環境與設定。

如果你想知道用 React 到底有什麼好處,可以參閱以下連結:

Introducing JSXThinking in React簡單聊一下 ONE-WAY DATA FLOW、TWO-WAY DATA BINDING 與前端框架

接下來,這篇文章會以試著寫一個陽春的 App 元件作為範例,內含 ChildA 跟 ChildB 兩個元件。

讓我們開始吧!

第一步:直接在 html 檔內開發 React 給瀏覽器執行

我們先用原始的開發方法硬搞看看!

用 script 標籤直接從 CDN 引入 react.js 跟 react-dom.js 檔案。

然後試著寫一個陽春的 App 元件,內含 ChildA 跟 ChildB 兩個元件。

這個 html 檔內容會像這樣:

source code

結果瀏覽器無法執行 React 相關的程式碼!

原因有兩個:

1. 瀏覽器看不懂 ES2015 的語法(class、extends)

2. 瀏覽器看不懂那個像是把 html 寫在 js 裡面的 JSX 語法

該怎麼辦呢?

第二步:用 Babel 讓瀏覽器能看懂 ES2015 與 JSX 語法

我們可以使用 Babel 套件來來編譯 ES2015 與 JSX 的程式碼,讓瀏覽器能夠看懂。

只要在 html 內加上這行:

然後在要編譯的 script 加上 type=’text/babel’ 即可:

就可以順利執行我們的 React 程式了!

source code

您可以用這種方式開發一些小型的 React 程式。

但實務上這些元件會複雜、龐大很多,全部寫在HTML裡面的話,不但很難維護,還有 babel 每次都在瀏覽器內編譯的效能問題。

只有3個元件可能還好,但要是有30個元件呢?

拆開成獨立檔案,並且預先用 babel 編譯過比較好。

第三步:把檔案拆開,並且預先編譯完成

把3個元件各自獨立成檔案,也把啟動這些元件的程式碼獨立成一個檔案:

接著來預先編譯它們。

這次我們不使用上面瀏覽器版本的 babel,我們用命令列介面的 babel-cli 來編譯。

先安裝好 babel-cli:

然後 babel-cli 從版本 6 之後預設不支援 ES2015 與 JSX,需要分別加裝所謂的「preset」才行:

接著就能在命令列使用 babel 並且設定 presets 來編譯了。

我們有4個檔案,所以分別打編譯指令4次:

成功編譯之後,就不需要在瀏覽器內引入 babel 了,直接使用編譯完成的檔案即可:

source code

然而,這樣做卻又產生3個新的問題:

1. 有N個檔案,就要打編譯指令N次,太累了

2. 透過 script 標籤引入N個檔案,會增加伺服器負擔、也會增加用戶端等待時間

3. babel 相關的程式碼都移出瀏覽器了,react.js 跟 react-dom.js 卻還是在瀏覽器內引入

第一個問題還算簡單,可以改成輸入指定資料夾的指令,就可一次編譯:

但是第二三個問題就棘手得多。

有鑑於此,需要找方法一次解決這三個問題:設法一口氣全部編譯、封裝成單一檔案、並且函式庫統一用NPM在伺服器端安裝與管理吧!

第四步:使用 webpack 來解決這些整合問題

webpack 會利用 babel-loader 套件來呼叫核心的 babel-core,所以先分別安裝它們:

我們不會透過命令列去使用 babel 了,既然用不到就先把它移除吧:

我們也不會用 script 標籤引入 react.js 跟 react-dom.js 檔案了。一口氣全部編譯時會用到,所以用NPM安裝它吧:

前面說過 babel 版本 6 以後預設不支援 ES2015 與 JSX,現在不透過命令列設定 presets 的話,就需要建立 .babelrc 檔案去開啟支援:

然後為了讓 webpack 在一口氣全部編譯成一個檔案時,能看懂檔案跟套件之間的相依性,因此需要按照 ES2015 的 import/export 語法寫清楚。

例如原本的 App.jsx 就要改寫成這樣:

src 資料夾內的檔案都要進行改寫。

最後建立 webpack.config.js 來設定檔案路徑,並指定使用 babel-loader 來幫忙編譯:

就可以透過命令列執行 webpack了:

這段指令有點長,可以把它放進 package.json 的 scripts 欄位:

之後就可以用下列指令來進行編譯工作了:

會得到我們要的結果:一個檔案搞定一切!

source code

大功告成!終於搞定我們想要的所有效果!

結語

本篇文章提到的內容,根據不同的套件版本,實務上有多種方式去安裝、設定達到同樣效果。

但是核心觀念是共通的!

可以此為基礎,探索更多的現代前端開發方法,學習更多工具的功能與設定!

(完)

(Photo via 8 Kome, CC licensed.)

photo

Cafe Nomad 蒐集 1,700 間咖啡廳的理由

我是一個很常去咖啡廳用筆電的軟體工程師。

每次在巷子內找到新的獨立小店時,我心中都會浮現3個念頭:

1. 又是一間精緻用心的獨立咖啡廳。這種店台北應該有幾百家,如果每間都去過,一定很有成就感

2. 這間店的位置真是太低調了,就算開幕滿一年,恐怕連附近住戶都不知道它的存在

3. 根據以上兩點,好像可以推論:巷子內的這些咖啡廳,普遍被埋沒了

2016年11月,趁著離職之後時間多,我決定驗證一下這些直覺。

我把過去幾年去過的20多間咖啡廳資料整理出來,根據自己最在乎的7個指標做了評分,接著上網再找出台北60間咖啡廳的店名,作成 Google 試算表,等待網友幫忙評分。

把這個試算表貼到批踢踢的軟體工程師看板之後:

[討論] 台北適合工作的咖啡廳

反應很不錯,隔天下午時,大部份咖啡廳都得到網友評分了,資料也被新增到100多間。

然後,我寫了程式把試算表的內容轉成網頁版的表格,接著訂購了一個網址:cafenomad.tw

稍微做了SEO與SMO之後,我把這張表格分享到我的一個粉絲專頁:

https://www.facebook.com/permalink.php?story_fbid=982000048579054&id=650279948417734

這則貼文隔天被分享了1,200次,再被轉分享之後,最後共計被分享了30,000次,當天有90,000人來看 Cafe Nomad:

1

這些流量也帶來更多人幫忙整理咖啡廳資料,最後台北收錄了200多間,其他地區也共計有200多間。

網友們的熱情參與,幾乎證明了巷子內的這些咖啡廳果然被埋沒了。

換句話說,台灣獨立咖啡廳產業的整體產值被低估了。

那麼,該如何提昇台灣獨立咖啡廳產業的整體產值呢?

我想到三個辦法:

1. 針對原本就會去獨立咖啡廳的族群:鼓勵他們更頻繁地消費
2. 針對只去連鎖咖啡廳的族群:邀請他們試試看獨立咖啡廳
3. 針對近年來與日俱增的國際觀光客:鼓勵他們去咖啡廳喝一杯

針對原本就會去獨立咖啡廳的族群

這是其中最簡單的方向。只要把這份清單給他們看就行了。

然後不斷開發更好用的找店功能,然後定期告訴他們有新功能就可以了。

這個族群也容易觸及:只要去批踢踢、Facebook社團貼文就可以了,大概像這樣:

[閒聊] 我做了一個蒐集956間咖啡廳資料的網站

[閒聊] 我做了一張台中咖啡廳地圖

[閒聊] 一口氣逛高雄全部咖啡廳的FB粉專的方法

[閒聊] 台南咖啡廳地圖:150間店 + 1,000張照片

https://www.facebook.com/groups/1507207486163325/permalink/1793163560901048/

這些貼文的反應都很不錯,也讓更多人知道巷弄小店要去哪裡找。

針對只去連鎖咖啡廳的族群

這是一個十分困難的方向,但還是有出力空間。

時不時會有咖啡產業的新聞出現,這種時候直接去人多的地方,然後跟大家談談自己對獨立咖啡廳的觀察跟心得就可以了。例如八卦版就很適合去po文:

Re: [問卦] 為什麼台北都很少小資本額的咖啡館?

把握住這種機會的話,可以吸引到至少50,000人開始想試試巷弄小店。

2

近年來與日俱增的國際觀光客

這是最困難的方向,光是要觸及這些旅客就很難,但還是有出力空間。

我把網站介面翻譯成了英文版:

https://cafenomad.tw/en

然後貼到幾個在台灣的英文社群網站:

https://www.reddit.com/r/taiwan/comments/5uw792/cafe_nomad_700_best_cafes_to_work_in_taiwan/

https://www.facebook.com/groups/357339197762790/permalink/723135624516477/

接著找 Cafe Nomad 社群的人幫忙翻譯成日文韓文版

https://cafenomad.tw/ja/

https://cafenomad.tw/ko/

然後再貼到相關的台日交流社團、台韓交流社團:

https://www.facebook.com/groups/japantaiwan/permalink/1392935974078433/

https://www.facebook.com/groups/partyintaiwan2/permalink/1453874974920063/

反應普遍很正面,雖然比較間接,但還是有點效果。

結語

網站上線5個月之後,我開始會在FB收到店家這樣的訊息:

3

Cafe Nomad 現在已經蒐集超過1,700間店、超過3,500筆評分、500則留言。每天都有超過1,000人主動上站尋找他下一間要去的巷弄小店。

最近替 Cafe Nomad 新增了店家贊助的功能,也找到了幾間贊助店家,所以我也得到了一些報酬。

在過去三年,我去這種巷弄小店消費了幾百次。整體說起來,在台灣,你很難找到一間會讓你失望的獨立咖啡廳。

花了很多時間做這網站,其實我也不太確定自己在幹嘛,但因為是滿有趣的事情,所以就算完全行不通,好像也沒關係。

我唯一確定的是,台灣這些巷弄小店,確實普遍被埋沒了。


附註:

店家贊助」功能是我替 Cafe Nomad 最新加上去的廣告功能。

它會將咖啡廳的名稱與照片獨立顯示出來,並且在清單與地圖內特別呈現。

歡迎有興趣的店家點這裡看看這個贊助功能的細節

(Photo via unsplash.com, licensed under Creative Commons Zero)