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

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

報價方式會像這樣:

  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 附近的範圍報價。

(完)

虛擬貓咪原始碼&智慧合約入門筆記

最近想多了解智慧合約的實際應用狀況,希望能跟區塊鏈上的智慧合約做簡單互動。

於是找了目前最成功的應用之一「虛擬貓咪」來研究。

分享一下目前的研究心得。

在開始之前,可以先閱讀以下兩個連結,對於閱讀本文會非常有幫助:

https://medium.com/loom-network/how-to-code-your-own-cryptokitties-style-game-on-ethereum-7c8ac86a4eb3

https://medium.com/loom-network/your-crypto-kitty-isnt-forever-why-dapps-aren-t-as-decentralized-as-you-think-871d6acfea

智慧合約不是完全公開透明的

以虛擬貓咪為例,智慧合約本身看似可以在此取得:

https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#code

但貓咪基因科學的合約是額外佈署的,不但可以由作者動態修改,而且還只有 opcode 可讀。

同樣的道理,您也可以利用這種「設定外部合約」並且不公佈那份外部合約的 Solidity 原始碼,來達成這種保密效果,還讓合約保持可以更新、升級的空間。

智慧合約不是完全去中心化的

除此之外,虛擬貓咪智慧合約定義了 CEO、CFO、COO 三個管理員角色。這三個角色各自有額外權力,甚至可以凍結整個合約的運行。

不僅如此,區塊鏈上的資料看似永恆,但其實除了原始團隊,沒人可以解讀基因編碼。因此一大部份 value 還是來自傳統 web server。所以虛擬貓咪根本沒辦法脫離作者團隊獨立存活。

如何用 web3.js 讀取 address balance?以我與虛擬貓咪為例

要讀取每個地址的以太幣餘額,最簡單的方式就是直接透過 etherscan.io

比如說,我的個人餘額可以在此查看:https://etherscan.io/address/0xcb0418eae76e14c214d79b8305ca34669075cba6

而虛擬貓咪這份合約地址的餘額,可以在此查看:https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d

以工程師的立場,會希望用程式去跟區塊鏈互動。以在網頁內使用 web3.js 為例,安裝了 MetaMask 來連線到區塊鏈之後,可以用以下程式碼讀取地址餘額:

如何用 web3.js 讀取智慧合約的 public variable?以虛擬貓咪為例

試著讀取智慧合約中三個公開變數的值。最簡單的方式一樣是透過 etherscan.io

可以在這裡看到三個管理員(CEO、COO、CFO)的地址: https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#readContract

用 web3.js 來讀取的話,可以先去 etherscan.io 取得合約的 ABI:

https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#code

接著像這樣從區塊鏈上讀出值:

如何用 web3.js 呼叫智慧合約的 public function?以虛擬貓咪為例

呼叫公開函式的話,最簡單的方法是透過 etherscan.io。

以虛擬貓咪的 getKitty 函式為例,如果要找出 ID 為 1 的那隻創世貓咪的資料,只要在欄位內輸入送出即可:

https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#readContract

用 web3.js 來讀取的話,則可以像這樣來呼叫函式(以分別抓出1、2、3 三隻貓咪為例):

心得感想

像這樣的智慧合約,究竟有多少應用場景?

一個 dapp 該去中心化到什麼程度?智慧合約的未來到底有多少潛力?實在沒人有把握。

還是老話一句,建議有心參與的朋友,保持懷疑精神,花時間了解更多,建立自己的觀點跟看法,不要輕信任何人的說法。

(完)

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)

我現在就想用你的產品,就算破破的也請馬上給我用

「當你有一個創業點子的時候,問問自己:有誰現在就想要這個產品?有誰超級渴望這產品,即便是小團隊做出來的破爛版本、即便這團隊根本沒人聽過,他們也照樣想馬上使用?如果你無法回答這個問題,那這個創業點子恐怕不太妙。」── Paul Graham

每次聽到有人正打算要創業、分享點子,我腦中都會浮現上面那個 Paul Graham 提到的問題。

不妨用更尖銳的方式描述這個問題:「這東西有人要用嗎?誰?你認識或見過任何一位這樣的人嗎?你說得出那人的名字嗎?現在打電話給他介紹這產品,他會說:『我現在就想用你的產品,就算破破的也請馬上給我用』?」

這個問題乍看之下沒什麼,實際投身新創產業之後發現,它會在很早期就給你迎頭痛擊。

如果無法回答這問題,那把產品推出之後,要是沒什麼人用,就會心想:是我功能不夠豐富、是我介面不夠漂亮,那再改一下。

改完一下再一下,還是沒人用的話就再改一下。

再不然就是會心想:都是我廣告下得不夠多。

於是付點錢給Facebook、付點錢給Google,還是沒人用的話就再燒多點廣告錢。

如果你自己都不知道這產品是誰會馬上想用,那就幾乎一定會陷入上述的挫折感循環,永無止盡投入的陷阱。

毫無正向回饋的不斷付出,會讓人感到焦慮、靈感枯竭,覺得自己像是跑步機上面的老鼠,沒有目的地疲憊奔跑著,卻也真的只是在跑而已。

在搞定了上述第一個問題之後,還可以參考 Paul 提供的另一個建議:

「相較於讓一堆人普通滿意,還不如讓少數人非常滿意比較好。」── Paul Buchheit & Paul Graham

然後你就會針對很明確的一小群人,非常專注地打造產品給他們。

這些建議之所以那麼多人沒注意到,是因為它們非常違反直覺。

它們乍看之下似乎是在劃地自限、從一開始就把東西做很小、從一開始就把市場弄很小。

實際上並非如此,它們只是一種讓自己能在一開始就保持專注的方法。可以接著把產品越做越大。

「擴展市場大小比提升用戶滿意度簡單。更重要的恐怕是,你比較難欺騙自己。如果你自認產品品質已經85分了,你怎知道它不是70分?說不定只有10分?但是你很容易就知道產品有多少用戶。」── Paul Graham

產品即使一開始只讓一小群人愛不釋手,但使命仍然可以定的很巨大。努力往那裡走就是了。

就算是一邊做一邊確立使命感,都好過於一開始就好高騖遠。

而且這種作法會大幅提昇產品上線速度、新功能上線速度。

愛情裡有一個關於緣份的描述:「世界上有一個人,每天每天都在想,要是有一天,能有像你這樣的人出現,那該有多好。」

不妨直接拿來當作創業的比喻:「世界上有一些人,每天每天都在想,要是有一天,能有像你做的這樣的產品出現,那該有多好。」

她當然知道你不完美,她當然知道你一定有缺點,但是她見到你的瞬間就已經決定包容你的一切。

有些人正在等你介紹你的產品,然後他們會對你說:我現在就想用你的產品,就算破破的也請馬上給我用。

by 阿川先生