網路創業:與其當成在做生意,不如當成在做實驗

開餐廳、開工廠、做進口貿易…在各種創業的形式中,網路創業有一個特性。

這個特性會誤導人們,讓網路創業看起來容易,實際做起來卻無比困難。

這個特性就像是一個會吃掉所有網路創業者的陷阱!

這個特性就是…

你看不到客人的表情!

你看不到客人聽你介紹產品的表情。

你看不到客人使用你產品時候的表情。

你看不到客人消費、結帳時候的表情。

當你閉著眼睛、摀著耳朵去跟客人做生意,做生意會變得極度困難。

這個像是廢話的商業常識,常常被大家忽略,然後因此犯下很多錯誤。

想像你在開餐廳創業

開始營運之後,大部份的客人結帳時表情都非常不悅,桌上的餐點都留下一大半。

部份客人甚至吃了幾口就吐在衛生紙裡面。

幾星期之後,店裡幾乎沒客人了。

作為老闆的你,認為問題出在哪呢?

「我們聘請的設計師不夠強,店內裝潢應該要更好才行!」

「我們宣傳的力道不夠,應該要在附近路口更用力發傳單才行!」

如果你真的這樣認為並且付諸行動,那麼只會讓你的創業更快失敗,然後賠更多錢而已。

當你閉著眼睛、摀著耳朵在做生意,就很容易變成這樣。

你會不願意承認自己的東西不夠好,你會做很多可笑的事情。

很多人網路創業遇到挫折,會覺得問題出在設計上面,覺得問題出在APP不夠流暢,覺得工程師不夠強。

這些都是因為看不到客人表情而有的誤解。

想像你在開工廠創業

你累積一筆資金,看中一個產業,買了塊地、機具、原料開始興建工廠。

你到處拜訪客戶,結果客戶們跟你說:你做出的零件是上個世代的欸,現在都用最新的原料、最新的製程在開發了。如果你沒辦法更上腳步,我們寧可付高價買國外的。

作為老闆的你,該怎麼做呢?

「我們只要賣得再便宜一點,就可以爭取到客戶了! 」

「我們的產線還不夠多,沒達到規模經濟,應該要再加倍購買現有的機具、原料!」

如果你真的這樣認為並且付諸行動,那麼只會讓你的創業更快失敗,然後賠更多錢而已。

當你閉著眼睛、摀著耳朵在做生意,就很容易變成這樣。

偏偏網路創業你看不到客人在電腦前的表情,也聽不到客人在手機前驚嘆或是抱怨的聲音。

你會很難看到現實,不知道該付出心力把東西做更好。

很多人網路創業遇到挫折,會覺得問題出在自己沒有富爸爸,覺得問題出在國家/銀行不給我錢。

這些都是因為看不到客人表情而有的誤解。

想像你在做進口貿易創業

你發現國外正在流行某種生活創意小物…看起來有點怪,但同時也很有趣。

你進口了一批這種小物,試著在台灣開始販售。

結果你發現…只有住在台灣的某些外國人會買,台灣人自己是不會買的。

你在生意成交/被拒絕的時候,順口問了這些人,結果吃驚地發現:只有生於某些國家、某些文化習慣的人才可能會買,除此之外的人根本沒有這種消費習慣。

作為老闆的你,該怎麼做呢?

「我們應該要找藝人代言!讓更多的人知道我們有進口這個產品!最好找歌手辦個演唱會!」

「我們應該要多開產品記者會!教育台灣市場!就好像,說服西方人買電鍋煮飯、說服東方人買刀叉吃飯,做到的話市場很大!」

如果你真的這樣認為並且付諸行動,那麼只會讓你的創業更快失敗,然後賠更多錢而已。

當你閉著眼睛、摀著耳朵在做生意,就很容易變成這樣。

很多人網路創業遇到挫折,就覺得問題出在市場。覺得問題出在台灣市場太小,覺得台灣人觀念還沒更上。

其實,你要做的當然是趕快尋找其他有潛力的生活小物,而不是整天想著教育市場、怪罪市場。

偏偏在網路產業創業,因為看不到客人的表情,廣告錢砸下去,流量飆起來,就算沒有成交量,你可能還是會覺得「很值得」,覺得「我們網站/APP的流量這幾天相當不錯」。

當你開發網站/APP網路創業,你要找機會當面推銷給使用者,你要找機會當場看著他們使用你APP的時候是什麼表情,你要找機會開口跟他們說:請你付錢吧,我們的產品正式版是要收費的。然後你自己聽他們怎麼說。

與其當成在做生意,不如當成在做實驗

上面的例子分別代表產品管理、技術研發、行銷策略。

從做生意的角度來說,在乎這些事情、願意在這些事情上面花錢,怎能算是錯誤呢!?

正因為看不到客人的表情,網路創業會陷入這種兩難,好像在乎不對,不在乎也不對。

所以不如直接把整個心態都換掉:就當成在做實驗吧!

相對於化學實驗,把網路創業想成一種商業實驗。

首先你會有「假設」,接著設計實驗來「驗證」。

你做的每一件事,團隊的每一種專業,都是為了驗證某種假設。

至於投入花費的金錢與時間,都只要足夠驗證某些假設就可以了!

僅僅是這個簡單的轉念,就足以讓你在看不到用戶表情的狀況下,面對成千上萬電腦前、手機前的客戶,做出正確的決策:或許是某些調整,或許是放棄某些方向。

做實驗最怕什麼?最怕一開始就認定自己的想法是對的

最怕覺得自己的假設通通是對的,實驗一定沒問題!

直接花光手上金錢,一口氣買了很大量自以為重要的材料與器材。

其實,做實驗當然要假設自己的想法「可能是錯的」才對。

然後保留重新做實驗的能力、保有彈性去改變實驗內容。

在針對每件事都很有把握之前,決不要輕易地「規模化」。

永遠選擇在「驗證完畢」,很有把握的情況下才去「擴張」。

這個再說下去就長篇大論了,這邊分享一個小重點!

看出商業實驗背後的假設

這種實驗最籠統的假設是「這產品賺得到錢」,實驗結果就是「我變成有錢人、公司 IPO」,團隊所付出的所有努力都是在「驗證」。

這種實驗很快就會失敗了!一定是賺不到錢的。

這時候你需要把籠統的假設拆成比較小的不同假設,然後分別驗證。

就好像一口氣做大實驗不行的話,那就把實驗拆成幾個小的,分別做過實驗再說。

假設台灣的用戶面臨一個問題、假設他們在乎這個問題、假設他們願意使用網站/APP處理這個問題、假設他們很在乎設計美感、假設我們的解決方案是對的、假設我們的產品/價格/地點/促銷都是對的、假設他們是願意為此付錢的、假設他們願意付的金額加起來是能夠養活一間公司的…

這些不同的假設每個都需要驗證,根據驗證的成功或失敗去調整實驗,做出新的假設、進行新的驗證。

前面的假設失敗,後面的假設也通通不用做了,然後這全部假設都驗證成功,你才勉強有機會存活。

一般人做不到,但有經驗的投資人與創業者一眼就能看出任何一個點子背後隱藏的眾多荒唐假設。

在不驗證的情況下就基於這些荒唐的假設去開發一個好像很大、很強的網站/APP,當然會是九死一生。

你幾乎看不到你用戶的表情,網路創業需要對此保持警覺。

如果從做生意的角度難以決策,改成用做實驗的角度去決策吧,執行起來會單純很多。

(完)

遠端(在家)工作的4個技巧:批次溝通、過度溝通、被動溝通、多層溝通

小弟身為軟體工程師,不論是全職上班、或是全職接案跟客戶合作,以遠端方式工作已經6年。

分享幾個改善遠端工作效率的技巧。

批次溝通

在辦公室大家可以隨時找同事討論、發問,也可以臨時團隊開會之類的。

遠端工作很難這樣做。因為人與人溝通的頻率被迫降低了,所以每次溝通的內容量要提昇。

建議養成批次溝通的習慣。也就是一次詢問多個問題、一次安排多個工作事項。

舉例來說,大家早上團隊視訊/語音開會的時候,不要只是每個人安排一天的工作量,最好把一整週的工作事項都先預排好。

這樣一來,當你手上的任務卡住,需要詢問別人問題、等待答覆、等待別人工作先做完時,可以先改做其他待辦任務。

這會讓負責安排工作任務的主管,工作難度提高不少。但習慣一下會發現效果很不錯。

發問的時候也是一樣。可以拿筆記本、或是在電腦開個檔案,整個早上陸續遇到、想到的問題,都記錄下來。

下次終於有機會跟同事通話時,一口氣問清楚。

就算只是用聊天室也一樣。

我常常一口氣丟出好幾個不同事項的不同問題。反正同事有空再逐一回答即可。

過度溝通

遠端工作絕對要避免這個狀況:因為溝通誤會,導致做了整天的白工。

絕對不可讓這種情況發生。平常在辦公室,隨時都能知道同事在幹嘛、有疑問也可隨時跟主管確認。在家工作可不行。

所以要養成過度溝通的習慣。我自己習慣是剛剛視訊時已經講過的事情,結束前我會再統整一遍、然後每件事描述確認一次。

結束之後,還會把我剛剛確認的事情打成幾個待辦,貼到聊天室讓對方再看一次。等於每件事我都跟對方確認2-3次。

我甚至會把同樣幾件事情,換個方式、換個角度再重新描述幾次,讓相關人都同意,我才放心沒有做錯方向。

有留紀錄的話,事後出問題也比較容易討論責任歸屬。

總之,在家默默工作幾天,然後才發現通通在做白工,是絕對不可以發生的。

如果你發現在家工作之後,自己會一直跟同事確認事情,或是同事會多次重複確認同樣的事情,好像大家變得有點神經質?

別擔心,這不但是很正常的現象,還是很鼓勵的現象。

被動溝通

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

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

請參考我另一篇文章:

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

多層溝通

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

請參考我另一篇文章:

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

結論

這些工作方式有點違反一般的工作直覺,所以容易被忽略。

但只要習慣一下,一定會發現遠端工作的好處,工作效率甚至比在辦公室更高。

(完)

關於做 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/

(完)

清單力量 Open Source:跟網友一起蒐集清單資料的系統

我最近開發了一套 open source,叫做 ListPower,清單力量。

ListPower 讓你可以針對特定主題,與社群一起蒐集整理資料,感受到清單力量的強大!就像這樣:

我把它 open source 開源釋出到 github:

https://github.com/howtomakeaturn/ListPower

歡迎有興趣的工程師自行把玩看看!

起源

前陣子因為很常去咖啡廳工作,所以做了一個網站,讓網友們可以一起蒐集適合工作的咖啡廳資料。

https://cafenomad.tw/

網站背後的「清單核心系統」有六大功能,讓網友們可以一起蒐集資料:

  • 新增
  • 編修
  • 評分
  • 留言
  • 照片
  • 標籤

我當時發現,這六大功能其實不只可以用來蒐集咖啡廳資料,蒐集其他主題的資料也可以。

首次嘗試 open source

所以我首次嘗試把核心的系統程式碼做成 open source 開源軟體,放在 github 供人下載使用:

https://github.com/howtomakeaturn/nomadic

陸續有幾個團隊想要使用這套系統,所以找我用「安裝+客製化開發」的方式接案來開發。

UrSchool

Screenshot from 2019-03-31 14-31-18

第一個是對教育產業有熱情的 UrSchool 團隊,希望能有一套系統,可以整理教師資訊:

https://urschool.org/

他們整理、建檔了多個學校的教師資訊,然後找了各校的學生幫忙評分、留言、貢獻資訊。

網站也順利上線蒐集了不少資料!

SportsMap 運動地圖

Screenshot from 2019-03-31 14-22-41

第二個是對運動產業有熱情的 SportsMap 團隊,希望能有一套系統,整理球隊、運動場地資訊:

(目前網站資料以羽球為主)

https://isportsmap.com/taipei/all-club

https://isportsmap.com/taipei/all-place

https://isportsmap.com/taipei/map

他們整理、建檔了各縣市的羽球場地資訊,然後找了各社群的球友幫忙評分、留言、貢獻資訊。

這些網站上線之後,獲得相關社群不錯的迴響,也藉由 SEO/SMO 穩定獲得網站流量。

新版 open source

「清單核心系統」是在 2016 年為了 Cafe Nomad 所開發,距今已有一些年紀。

不論是 UI 介面跟底層架構都需要更新(Laravel 5.3 升級 5.8,Bootstrap 3.4 升級 4.3)。

資料基礎模型架構也需要改寫,從 JSON-based 架構改寫成 Entity-Attribute-Value (EAV) model 架構。

整套系統重寫很花時間,但目前最核心的功能已經重寫完畢。

新系統用起來、看起來會像這樣:

[適合下班後小酌的酒吧清單]

https://listbox.app/list/qKnP10

[網站與手機APP接案公司清單]

https://listbox.app/list/zj4djZ

程式碼也作為開源軟體 open source 釋出到 github:

https://github.com/howtomakeaturn/ListPower

結語

如果你有想要蒐集的資料,歡迎聯絡我討論看看,也許可以在 https://listbox.app/ 直接建清單出來。

除此之外,我也可以用接案的方式替客戶安裝這套系統。

如果你需要獨立安裝這套系統,或是對這套系統有任何問題,也歡迎找我討論看看:

[email protected]

https://www.facebook.com/chuanhao.you

根據你的需求,應該可以找到快速安裝、架站的方式,或是持續客製化修改、頻繁討論的方式。

可以來研究看看用什麼方式安裝、開發,還有相關的報價、收費怎麼計算會比較適合。

(完)

分離式客製化開發:兼顧模組化與客製化的 Laravel 彈性架構

接案的時候,常常很想把一套系統寫完之後,一口氣賣給多個客戶。

偏偏每個客戶都有各自不同的客製化需求,沒辦法真的都拿同一個專案去佈署。

只好把一個專案複製成好幾份,然後分別客製化給不同客戶。

但這樣又會出現維護問題:各專案的差異越變越大。

之後就算更新了核心功能、修理了核心 bug,也很難一口氣替所有客戶升級。

如果各專案的差異是無法避免的,那有沒有辦法至少,讓核心系統與客製化的程式碼分開來放呢?

最好能讓各專案的檔案結構都像這樣:

System/
Customization/

如此一來,雖然 Customization/ 內的 code 不能重複使用,至少 System/ 內的 code 可以。

可以將 System/ 內的 code 更新進其他專案,也可以拿強化後的核心系統去接未來的新案子。

我把這種檔案結構稱為「分離式客製化架構」,下文用 SCA (Separated Customization Architecture) 代稱。

這篇文章跟大家分享在 Laravel 底下如何使用這種 SCA 架構。

前置需求

使用 SCA 架構非常簡單,只要安裝 laravel-modules 套件就可以了。

laravel-modules 套件非常單純,它只是運用了 Laravel 原生的 Package Development 觀念,幫助你把 app/ 與 resources/ 資料夾底下的程式碼移進另外的 Modules/ 資料夾而已。

Modules/ 內可以有一或多個資料夾,每個資料夾就跟一個獨立 laravel app 一樣,有自己的 controllers, views, entities, routes, migrations… 等等內容。

laravel-modules 套件就只是幫你讀取各個模組的內容而已,沒有其他黑魔法。

如此一來,你的 Laravel 專案的檔案結構會變成這樣:

Modules/
app/
resources/
...

注意到了嗎?它剛好對應到前面說的檔案結構:

System/
Customization/

Modules/ 就是 System/,而 app/ 與 resources/ 就是 Customization/。

那麼實際上該如何開發呢?以下直接舉例說明。

情境:你開發了一套 Awesome 通用系統來接案

首先你根據過去的經驗開發了一套 Awesome 電商官網模組,打算用它來接許多案子,賺大錢。

你的 laravel 檔案結構長這樣:

Modules/Awesome/
app/
resources/

Awesome 模組的 controllers, views, entities, routes, migrations… 等等內容都在 Modules/Awesome/ 裡面,就跟一個獨立 laravel app 一樣。

而 app 與 resources 資料夾內目前只有 laravel 預設檔案,你沒寫半行 code 在裡面。

你拿 Awesome 系統開始接案,接著客戶出現。他們有以下的客製化需求。

情境:客戶想修改 UI

客戶要求對首頁畫面微調。

這個時候請利用 laravel 原生的 Overriding Package Views 機制,你直接新增一個檔案:

resources/views/vendor/awesome/homepage.blade.php

就在這個檔案內隨心所欲的重寫或是亂寫吧!它會直接取代原本的這個檔案:

Modules/Awesome/Resources/views/homepage.blade.php

如果不只是畫面微調,這種模板覆蓋不夠用,那就可以視為修改系統的 business logic,請接著往下讀。

情境:客戶想修改系統的 business logic

客戶想修改結帳前的購物車頁面與功能。

此功能原本的 routing 定義在 Modules/Awesome/Http/routes.php 內:

Route::group(['middleware' => 'web', 'namespace' => 'Modules\Awesome\Http\Controllers'], function()
{
    Route::get('/shopping/cart', 'ShoppingController@cart');
    // blah blah...
});

請在原本 laravel 預設的 routes/web.php 內新增:

Route::get('/shopping/cart', 'ShoppingController@cart');

接著建立 app/Http/Controllers/ShoppingController.php 檔案,去繼承原先在 Modules/Awesome/ 內的 controller:

namespace App\Http\Controllers;

use Modules\Awesome\Http\Controllers\ShoppingController as BaseController;
use Illuminate\Http\Request;

class ShoppingController extends BaseController
{
    function cart(Request $request)
    {
        // 隨你修改商業邏輯 ...

        // 繼續用原有模板與覆蓋機制
        // return view('awesome::shopping.cart');

        // 或是在 resources/views/ 內建一個新的也行
        return view('the-new-cart');
    }
}

這樣就會直接取代原本的功能了!

最棒的是,這只是用上了基本的 OOP 類別繼承觀念,以及 laravel 的特性:「重複的話,後定義的 route 會覆蓋先定義的 route」。

有需要的話,domain model 內的類別也可以用同樣手法繼承來擴充。

比如說原本有個 Modules/Awesome/Cart.php 類別:

namespace Modules\Awesome;

use Illuminate\Database\Eloquent\Model;

class Cart extends Model
{
    // blah ...
}

你可以建立 app/Cart.php 這樣的子類別:

namespace App;

use Modules\Awesome\Cart as BaseCart;

class Cart extends BaseCart
{
    // blah ...
}

在新建立的 controller 內就可以使用這些擴充後的新 domain model 類別。

用這種手法可以自由新增程式碼!而且全是在 app/ 或 resources/ 資料夾內新增,完全沒碰到 Modules 內的東西。

情境:客戶想開發新功能

開發全新功能就更簡單了,直接在 routes/web.php 內增加 routing 後,在 app/ 與 resources/ 內增加你需要的檔案就行了。

就跟平常開發 laravel 專案一樣!

有需要的話,就在新的檔案裡面引入或是繼承 Modules/ 內的類別就行了。

情境:需要更新資料庫 schema

laravel-modules 有提供指令幫忙產生 migration 檔案。

所以屬於 Awesome 系統的 migration 檔案會在 Modules/Awesome/Database/Migrations/ 底下。

如果客製化時需要更新 schema ,就用 laravel 原生的 migration 指令在 database/migrations/ 內建立 migration file 即可。

連 migration file 都可以完全分離在 System/ 與 Customization/ 裡面!

結論

SCA 的特色在於它不預設你打算把專案模組化或是客製化到哪種程度。

你可以為了客戶在 Customization/ 內先寫完功能。之後有空再完全重構或是部份重構進 System/。

也可以遇到需求就先強化 System/,寫到不適合的地方再開始從 Customization/ 接手客製化。

你可以視情況來來回回,以一種混合的方式寫 code。

你可以邊寫邊決定,事後隨時反悔也沒問題,所以 SCA 非常適合接案類型的軟體開發。

針對 SCA 還有許多進階議題可以討論,本文只談最基本的觀念與技巧,但應該足以解決大部份的問題。

我自己用這種方式接案開發了幾個月,效果非常不錯,分享給各位參考。

有任何問題歡迎留言讓我知道,或是寄信到 [email protected] 與我討論。

(完)

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

遠端工作三年(在公司 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 附近的範圍報價。

(完)

by 阿川先生