about 9 years ago

去年我有一個班,比 Ruby on Rails 口碑還要好。這個班就是 敏捷專案管理班

很多人不知道,其實在我心目中,我認為自己的軟體專案管理技能其實還遠比我的 Rails 強悍非常多。很多外界的朋友知道我 Ruby on Rails 網站開發的無敵快,以為是純粹是 Rails 技術精熟的原因。其實,Rails 技術熟練只是佔其中很小一部分而已,真正的關鍵在於我關於規劃管理專案 Scope 與資源的能力非常強大。(這方面評價都可以問我過去的同事)

在執行專案的時候,專案管理才是最重要的,如果專案的資源與時程管控不當,任程式設計師開發速度再怎麼暴力(就算你是 Rails Expert),不可能在時程內完成就是不可能完成。特別是軟體專案通常不是一個人進行,而是十個人,二十個人,五十個人以上進行。

為什麼需要專案管理?公司人員成長所帶來的溝通合作問題

我以前在網路上粗略發表過幾篇我怎樣做專案的文章,後續也有一些讀者來信或者社群朋友求教。而我發現許多公司成長的痛點在於

  1. 團隊成長太快,沒有有效的工具管理需求。真的需求與假的需求混在一起,工作量爆炸。
  2. 即使篩選出真的需求,委派給工程師執行。但是執行到最後,進度與成果都歪到不知道到哪去了。
  3. 想引入專案管理工具,卻導入哪套好像都不對,沒有加速的感覺。很多同事開始覺得專案管理系統「只是派票」,被抱怨為何我不回去用 Email 回就好了。
  4. 已經固定熟練了一套專案管理工具,也開始有加速的感覺。但是每次專案還是 delay,專案上線後的總檢討,永遠是當初被路人塞進了太多假需求。但是專案很趕,老闆很硬,PM 很盧,莫名其妙就做了。花了大把時間,上線後才發現當初花很多時間做的是垃圾功能。
  5. 公司開新專案,PM 越熱心,我越害怕。因為他越想規劃得越仔細,我就覺得專案越可能 Delay(每次三個月工期,PM 總花兩個半月時間規劃,最後只剩10天時間逼我加班寫完)。有沒有辦法叫它們停止瀑布流式的規劃。
  6. 我對敏捷很有興趣,也去上了 Scrum 與 Kanban 的班。這些課裡面有些工具與工作模式很棒。但是有一些完全不合乎常理。硬導入公司,還被同事嘲笑很像扮家家酒。到底這些敏捷框架哪一些是可以用的,哪一些可以不要用?
  7. 我們公司導入了敏捷,剛開始成效還不錯。但後面敏捷好像毀了我們公司,RD 原本很關心公司產品,導入了敏捷之後,變得只願意跟 PM 講話,去溝通需求都是 PM 的事,不甘他的事。專案分工是明確,但好像後來越花越多時間在釐清幾句話的需求。越來越慢以及越來越被動,而且需求還開始一直做錯。

三個想達到的目標

  1. 不想盲目加班
  2. 不想老是 delay
  3. 不想老是做錯功能

2014 年版的軟體專案管理班

2014 年時我開的班,主要集中在以下幾個技巧

  • 控制專案 Scope 的技巧
  • 控制專案時程與風險的方法
  • 如何使用 Redmine,及利用 Redmine 大幅加速專案開發的速度 (切票派票沉票技巧、Milestone)
  • 如何結合 Redmine 與一般敏捷開發技巧如 Kanban、Standup、Git、Continous Delivery 和團隊協作工具,流暢地進行專案。

也就是傳授如何一套如何將專案催到極速的技巧。同學評價非常好。

2015 年版的軟體專案管理班

2015 年我對課程做了大改版。主要是過去的一年,管理台美兩地快速成長中的跨時區軟體專案,讓我在專案管理上又有非常大的突破與領悟。我希望把 2015 得到的經驗也帶入這個班裡面。同時去年上完之後,同學也給我了一些他們想了解的主題。因此在「原有的主題」之外,我還會加入了以下主題:

  • 如何挑選敏捷方案?敏捷方法的核心
  • 如何挑選「適合」公司做事方法與部門的專案管理工具。
  • 如何解決導入「敏捷」後期反帶來的「效率低落」。
  • 如何避免做到假功能,以及如何做到正確的功能。( PM 與 User 提出的方法是錯的。花時間做完上線反而被罵)
  • Growth Hack 如何與專案管理一起並行

這些主題我都設計了一套系統性的做法,解答這些問題。
這也是為什麼這個課程比去年貴一些的原因。

QA 問到飽

並且這個課還有一如往常的 QA 問到飽。我們最後一段都有非常充裕的 QA 時間,你可以提出任何的專案管理問題,我都會想辦法解答。很多同學都在這個階段(藉由別人的問題)得到很寶貴的收穫。

我摘錄一個同學的課後回饋是:「 Xdite 有問必答。這麼多奇怪的問題,竟然沒有看到他在 Q & A 被問倒,我覺得真的很屌」。

歡迎同學今年再來報名挑戰這個傳說。

適合報名對象

我認為這個班適合報名的對象,偏向軟體界。不過如果你不是軟體界,但對專案管理非常有興趣,還是可以來聽看看。我建議來報名的對象是:

  • 老是被專案搞到加班的 RD
  • 老是最後因為公司很操很瞎搞到離職的 RD
  • 想學習如何管理軟體專案的 RD 頭
  • 快速成長中的 Startup RD team
  • 覺得自己勞心勞力卻老是被 RD 幹翻的 PM
  • 好還想更好的專案管理狂熱者

一季只開一班,趕緊報名

這個班是每季才會開一次。下一次這個班開課的日期是 2016 年的 1 月。如果你被這些問題頭大了非常久,歡迎來報名解決困擾。

目前最近的開課日期是 10/9。目前 2015 冬季班正在接受開放報名,請趕快卡位:

http://www.growthschool.com/courses/agile_management

(目前兩人團報有優惠)

 
about 9 years ago

一直以來,對日本商家的「印象」都是服務「設計」得很好,以及招牌「設計」的很棒。但是如何好法,總是沒有個頭緒。

日本服務業的心法

疑惑 1 : 日本的「服務好」只是「一種選擇性的 style」?

講到想深入研究,旁人總會丟一句「不用研究啦,那是日本人的龜毛性格,台灣人做不來」。

自從我體悟到「Growth Hack」的原則就是「把服務做好」後,就對於日本的實體與線上服務就開始產生好奇心。這次來日本旅遊也特別留心注意周遭的服務設計,想試試看到底可以取經多少。

自從我發現「設計 Landing Page」是一種必要的選項,不是「一種選擇性的 Style」後。我也不再相信「日本服務好」只是「一種選擇性的 Style」。所以想藉此機會重新研究日本的服務業。

疑惑 2 : 為何日本的商店招牌,走在路上總可以讓人不小心掉到坑被騙進去?

之前來日本的幾次感想,都是日本的招牌設計太強了。雖然花俏,但是總可以讓人不小心掉進坑裡走進去。走在整條都是餐廳 / 居酒屋的街道,總是可以讓人決策樹崩潰。

這次重遊日本我也想研究到底原因是什麼。

1. Landing Page 之上的 Landing Page

我在上課時,總喜歡將 Landing Page 類比為「店餐廳外觀內裝潢」。

這次來日本才發現,日本為什麼拐客人這麼強,是因為他們在「Landing Page」上還再蓋了一層「Landing Page」

這是我從九州、東京、東北,拍到的店家外招牌:

撞球間

小說店

雞肉燒烤店

居酒屋

可以看到他們都用了 Landing Page 結構做了包裝:

  • 一句話形容自己(對本店的形容)
  • 提供什麼服務 (直接秀食物)
  • How it works(直接拍餐廳內裝潢)
  • CALL TO ACTION (營業時間)(甚至有寫 Happy Hour 時間)
  • 消除疑慮 (招牌都會寫店內最大容納多少人,讓人不會有「店會不會滿了的疑慮」)

2. 高級旅店的 Check-in Onboarding

這次我來日本,有兩天是住了超過五萬日幣的高級溫泉旅館。一間是在箱根的「箱根吟遊」,一間是在函館的「湯之川 渚亭」。這兩家都有類似的 check-in 流程。

因為我是一個禮拜內連續碰到,發現這已經是一種 check-in 的 best practices。而且跟 growth hack 的 onboarding 概念是一樣的。

超高級旅店如何做 onboarding

1. hand-free

這兩間的飯店的 checkin 流程是,首先是到了飯店以後,行李就可以放手了,有人會幫你提。然後來人會先幫你提到 check-in 處。

2. welcome-drink first

check-in 處是小小休息桌,然後第一件事不是叫你拿 id,而是問你要喝什麼歡迎酒 / 飲料。坐下來看風景聊天。會有好幾桌。這樣就算很多人同時 check-in,旅客也不會不爽。

3. personalize check-in

然後快喝完時會有專人帶著筆電來服務你,這時候才會請你給 passport。都辦完了之後,

4. personalize guide

會有另一個專人帶你去房間,一樣這段是 hand-free,還是會有人有幫你提行李。進房間之後,專人會幫開始介紹房間各項設施怎麼用。進房前,則是會介紹路過的公共設施要怎樣用。然後跟你 book 吃飯時間與鋪床時間,才離去。

Summary

我實在很慶幸當初去學了 Growth Hack 這門學問。原本在沒有接觸這門學問以後,我認為許多服務的「好」,只是「一種選項」。後來瞭解了原理之後,現在參觀任何「傳說中」的好服務都會放心思在看主辦方的細節,到底是真心設計還是只是搬弄照抄。又有什麼好技巧可以師法學習。

特別是又來了「好服務」的大國「日本」。走在街上,真是特別多靈感。

 
about 9 years ago

之前有朋友希望我多寫一些 GH 實際案例,不過我手上有些 showcase 有綁 NDA 無法公開展示。想想,不如來寫「解構」系列,透過解構業界知名 GrowthHack 團隊怎麼樣設計系統,讓大家一窺後面的手法。

最近在旅行,住了不少 Airbnb 上的房子。剛好 Airbnb 的 GrowthHack 團隊是出了名的強,最近在被 Airbnb 催寫房客評價單,覺得這套系統真是設計的超漂亮,決定這次來解析他們的設計手法。

郵件不斷地提醒

首先,透過郵件不斷的提醒,在十四天內要寫評價。而且是雙向提醒,也就是如果你不寫評價,若房東有寫你的評價,你也會看不到。

強調是貢獻社區,而不是單向的被要求給 Airbnb 改善建議

提醒消費者,Airbnb 的社區改善(Traveler 與 Host 的 plan ) 是建立在大家的誠實 Review 回饋上改進。讓你覺得不貢獻有罪惡感。

將問卷分段

問卷採分段式填寫,非冗長式的一次填到底,讓住客有興趣繼續填下去。這種透過 Gamification 的手段,通常比較常見在商店購物車結帳中。即使是複雜的填寫,也會讓人有動力填寫下去。

將體驗與 Feedback 切開

設計三欄,讓消費者明白「體驗」與「小差錯」以及「相對建議」應該分開寫。

這一點要是 App Store 或 Google Play,可以改採用這樣方式的設計,可以降低很多莫名其妙的1星,而且開發者能夠得到真實建議。而非憤怒的一星意見「老是 crash」。

細節評價

  • 協助房東在各方面改善的更好
  • 如果不好,以消費者的觀點應該「怎樣補強」
  • 是否推薦朋友來這個房源 ( Y / NO )

是否提名房東參加 Airbnb 大獎

  • 是否提名 Airbnb 參加最佳房東(未必是一件真實的比賽),但能驗證你推薦此房東是否真心。
  • 前面跟房東談了他應該知道的事情,接下來跟 Airbnb 談談這個房子 / 房東的狀況。

插入 NPS 問卷

我上個月在這篇,Referral 重要的指標:NPS 文章中談了 Net Promoter Score。

相較於很多團隊總在突兀的時刻,送出 NPS 調查。Airbnb 很準確地在消費完畢後的問卷插入 NPS 問卷。

提醒 Review 是雙向的

  • Review 是雙向的
  • 如果你不寫 Reivew, 房東寫的 Review 你也看不到

跳回 Dashboard 之後再請使用者做一次 Referral

之前的一篇文章中 Build proper Referral Program,我提到 Referral Everywhere 的重要性。

Airbnb 又做了一次精確的 Referral everywhere, 塞到了精準的 Referral 時機。

跟傳統的旅館 Review system 差異

我在體驗 Airbnb 房間後,過幾天跑去住了「箱根吟遊」,算是非常高級的旅館。這是他們合作的線上訂房網的 Reivew Request。

Summary

Growth 是 Conversion Rate - Churn Rate。

降低 Churn 的手法,在於能真實的聽到顧客心聲,改進。且在聽取使用者心聲時,小心地不觸怒顧客,且得到非敷衍的改進意見。從而改進服務,增加 Conversion Rate。

在這份問卷上,可以看到 Airbnb 在設計問卷時,深深的經典巧思。所以拿來頗析,分享給大家。

 
about 9 years ago

我在兩個月前寫了一篇文章Growth Hack : Build proper Referral Program,簡單講解了設計 Referral Program 的一些簡單要素(小懶人包)。

今天要來探討,什麼樣的狀況才適合啟動 Referral Program。

照慣例先講結論:產品必須要在 PMF 情況下,設計 Referral Program。 Referral Program 不會幫忙達成 PMF。

為什麼有些服務會使用 Referral 取代下廣告?

Referral 是常見的行銷手法。商家會用 Referral 式行銷的原因很直覺:

  1. 行銷成本遠較一般廣告成本低。
  2. 朋友推薦朋友速度快,在信任程度高的情況下,轉換率通常非常高。

不過常見的謬誤是,有些行銷者會得出這樣的結論:「任何商品」 X 「Referral」=「病毒式增長」。

Referral 使用的條件與時機

事實上用 Referral 的條件有幾個,否則實際上 Referral 非常難啟動。甚至還可能不但啟動不了,反倒引火自焚。Referral 的條件與時機如下:

  1. 產品一定要已經 Product Market Fit 。
  2. 產品給的 Referral 的 discount 至少要高過產品本身訂價或服務量的 10% 價格或至少提供 10% 服務量。
  3. 產品要 Net Promoter Score 夠高,才有辦法啟動,甚至「才不會造成反效果」。

1. 產品一定要已經 Product Market Fit

為什麼要 Product Market Fit?Product Market Fit 後,通常代表你提供的服務已有「穩定的服務品質」,穩定的利潤。

1) 要做 Referral 之前,產品品質一定要維持一定,否則口碑行銷容易出事。(消費者總不希望推薦朋友去使用一個服務,然後那個服務砸鍋,從此搞砸信用吧)

2) Referral 也是廣告的一種,你還沒抓熟成本。不知道 Referral 會不會造成澇賽,一 Referral 下去甚至有可能入不敷出,甚至倒閉。

2. Discount 設計一定要過 10%

那些用 Referral 很兇的 Dropbox, Airbnb, Uber, 無疑的是獨角獸。但你也必須注意看他們提供的 Referral 內容是什麼?

Yes.

1) over 10 % 的 discount。
2) 有品質的服務
3) Referral 成本對服務提供者來說減損到純利的狀況是很少的。

為什麼要 over 10% 的 discount?這樣消費者才會真正覺得,推廣是對我有好處也對朋友好處的。

我從Gogoro、Tesla 與直銷的競爭優勢 一文,觀察到某 G 牌機車在做 Referral。事實上我不太知道他們想幹嘛。G 牌機車,一台 12 萬 8 ,送一個月電池服務(大概折台幣 1000 吧)????老實說我不知道這到底會吸引誰去買誒。(這到底哪個天才設計的?)幫你推廣的消費者搞不好甚至覺得都不敢跟朋友推薦吧。講這樣的方案內容可能還被笑死 =_=

老實說, G 牌真要做 Referral 的話送一萬折價卷大概才會有消費者鳥你吧,我說真的。

但這又要回到,G 牌是否有 PMF, 1 萬才有動力,但是利潤根本沒有 1 萬啊。

另外一件事值得一提的是 Tesla 雖然推薦一個人是 1000 美金。(動力雖然對車主沒有很高)。但推薦到 5 台以上是贈送「稀缺資源」,這才是強烈動機。(這是另外一種 Referral 密技,我有空再講)(拜託 G 牌不要再送保留號碼,大家都知道你們車子沒賣完...)

3. Net Promoter Score

這是做 Referral 前最重要的指標了 超重要超重要超重要 要講三遍

Net Promoter Score 就是「願意幫你 Promote 的顧客分數」。Referral 能夠 Run 的前提是 NPS 要高,就我的經驗,分數要高到 5 以上。

如果你有興趣瞭解更多 Net Promoter 原理的話,細節可以看這篇:http://blog.clientheartbeat.com/net-promoter-score/

NPS 的運作方式,是送一個 1-10 分的問卷,只問一個問題,「你會不會推廣這個服務給朋友,為什麼?」

如果你的 NPS 不高,千萬別推 Referral ,因為

1) 輕則推不動。(我覺得這服務還可以啦,但是價格太高,不一定每人都需要)
(只要有「可是...」,服務提供者就要盡力去修)

2) 重則反效果。「笑死人,那麼貴那麼爛的服務還要做推廣,這種折扣貼出去超丟臉」。你寄希望幫忙做 Referral 的信給使用者,憤怒的使用者甚至會覺得他們被你騷擾了,開始幫你反行銷。

矽谷現在甚至有專做 NPS 的服務叫 Delighted https://delighted.com/

所以通常做 Referral 之前都會先 run NPS,而不是盲目的做 Referral。以免賠了夫人又折兵。

提供想設計 Referral 的人一個參考。

結論

產品必須要在 PMF 情況下,設計 Referral Program。 Referral Program 不會幫忙達成 PMF,切記。

 
about 9 years ago

兩個禮拜前,我寫了一篇 HomeJoy 陣亡的討論。今天我要寫另外一個面向的探討。就是 HomeJoy 究竟怎麼死的。

在這個切入點之前,我必須要先談 YC 與其他加速器最大的不同:他們的加速器不教別的,教創業者「Growth」。

創業者只需要學會「Growth」

市面上有很多加速器,坦白來說你也不知道他們在加速什麼的,有些你加入了反而「減速」。

好,不多扯這個主題了。每個加速器不太一樣,有的教你怎樣造 Traction,有的教你簡報技巧,有的教你募資技巧,有的帶你大量曝光。

但真真切切的,報名加速器的創業者真的需要什麼,就是學會「怎麼做生意」,然後「成長」。

(所以不是教你做生意的加速器,就省點時間別去了....)

創業「無法」也「不能」 Game the system

PG 本人說過 ": starting a startup is where gaming the system stops working."。他認為創業是唯一個無法靠作弊成功的領域。

何謂 Gaming the system?就是像你上大學,大部份人考試考高分,並不是真的了解這門知識,而是知道「教授會考什麼」。你知道教授想出什麼會出什麼,所以你考高分。

但創業不是這樣,他無法靠「game the system」達到你想要的終點,你如果始終想要 "gaming the system",這個心態會殺死你,只是死的時機點而已。

而 HomeJoy 就是這當中的一個例子。

HomeJoy 倒閉的真正原因:「Growth X Game the system」

雖然創業不能 Game the system,但 YC 還是找到了一顆「北極星」,那就是 Growth。並把這整個概念覆蓋到他們旗下的 startup 下。

公司圍繞著「成長」這個概念,可以讓創業聚焦。因為你要想辦法達到成長,所以你就不會浪費力氣在 big bang 式的媒體曝光,或者是砸大錢在廣告上。創業者會開始注重在產品的 AARRR。

好。那 HomeJoy 出了什麼問題呢?

OK。你要想想 HomeJoy 什麼時候從 YC 畢業的呢?2012 年七月。距離現在多久?三年。

三年拿到 10 億台幣資金,然後擴張到 31 個城市的 B 輪公司。你覺得這門生意是擴展的太成功還是太奇怪?創辦人才 20 幾歲。

這看起來反而像是類固醇打過頭的公司。

實體辦公室的迅速擴張

1) 首先軟體公司暴發式成長的公司不是沒有。但多是「純軟體」居多。就連當年爆發性成長的 Facebook,都沒有「實體 Operation辦公室」的快速擴張。但是 HomeJoy 擴張了 31 個點。

小孩玩大車,人數的迅速擴張

2) B 輪公司大多在 150 - 300 人規模。兩個年輕人要怎樣從只管 5 個人迅速「心智」上成長到可以管 150 人?
管 5 人,10人,20人,50人,100 人,500 人,都是不同等級的難度,需要時間與歷練。

而且還是 Operation-oriented base 的公司。

如果你上 HomeJoy 的 Glassdoor 一定可以看到類似的抱怨(對幼稚管理層的瘋狂抱怨)。而且還會是滿滿一大堆。

瘋狂盲目地燃燒資金,用「成長」去吸引下一輪投資者

3) 2012 開始剛好是 Uber like 的大爆發年,所以該年開始,只要你的題目是 Uber for Anything,都很好拿錢。消費者也很容易買單。

因為消費長也想要買單 Uber for everything。所以相關 O2O 題目瘋狂的爆發。錢變得很好拿。成長曲線也會很漂亮。(因為市場上從未有這一類的商品)

但是這就又燒出一個隱憂。拿到錢的人真的懂這個 Business Model 的成本結構嗎?

(當然台灣環境比較悲哀啦。所以根本沒有「拿到錢」的煩惱 XDDDDDD所以做 O2O 的通常是 run 幾個月就血流倒地了。)

矽谷都是燒錢式的把 business model 燒出來。不過這在 O2O 這一個領域開始踢到了大鐵板。Operation 真的非常非常非常非常地燒錢。

而且非常非常燒管理人才。我認為矽谷這樣 O2O 繼續玩下去,operation 的人才搞不好現在大概跟 Software Developer 一樣搶手吧。

清玉迅速展店都還是加盟主捧錢給總店,加盟金還是天價的高,都會迅速崩潰了。更何況是自己拿錢到處砸開「加盟店」。我想用這個例子你更能明白 HomeJoy 發生了什麼事。

一旦 retention rate 很低,幾乎就是賣 1 單賠 5 單吧。

不過 HomeJoy 需要錢,也有投資人的壓力。怎麼辦呢?反正他們有 Growth 曲線,就是繼續去募,他們也募到了 B 。
在這過程中,他們有思考自己的 model 問題在哪呢?我想應該也是沒有。

不然擴張 31 個城市還擴到其他國家(美國英國加拿大法國)這件事,看起來很屌,實質上在運營管理上根本像神經病一樣。矽谷很多觀念是很先進很成熟,但這是超越物理極限的事(需要大量管理人力以及運營經驗堆積),是不可能做到的。

HomeJoy 就如同他的僱員和同業批評的一樣:「盲目擴張,盲目追求增長」

一旦募不到下一輪,就趴了。

結論

O2O 雖然挑戰門檻極大。但並非不能做的生意。

Homejoy 的 CASE 正像海水退潮就知道誰沒穿褲子。接下來 O2O 界相信應該會有一系列海水退潮。

我自己覺得可以從 HomeJoy 這個例子裡面吸收的是:

  1. 要創業,慎選資金,沒辦法幫自己成長的資金與加速器少拿。
  2. Focus 在 Growth,可以省走歪路。
  3. 人員擴張,運營擴張,是成長結果不是成長手段。
  4. Never game the system

共勉之。

 
about 9 years ago

我今年下半年重開了去年評價很好的 Rails 商務網站 x 即戰力班。開這個班的目的,是為了讓市場上多一點即戰力能戰鬥的 Rails Developer。

目前口碑蠻不錯的。

課程內容以及設計理念

雖然網頁上我已經有公布上課大綱是什麼。不過有朋友還是希望我解釋一下這是在上什麼。所以我就大致上寫一下:

第一週

第一週我會教新手,「軟體規劃」,以及「規劃完怎麼樣慢慢實作完內容」

這是過去我訓練過幾十個 Rails Developer 發現大家的共同罩門。很多人學完坊間的 Rails 基本教材,會操作基本的 API 了。但是對於「要重新寫一個自己屬於自己的 App」有困難。

其實不要說自學了,就連許多公司裡面新雇用的 Rails Developer,很多人頭三個月都還只能實做「單項」簡單的功能,沒辦法說「規劃一個整塊功能」,在限時內寫完。

這就是我第一週想要傳授的能力。這個能力會在後面的課程中一直反覆的用到。

第一週其餘的內容,都會圍繞著

  • 「軟體規劃」
  • 「如何圍繞著軟體規劃,慢慢把軟體疊出來」
  • 「利用 gem 實作功能」。
  • 「如何問出不會被鄙視的問題」

同時鼓勵大家下課後去參加社群,寫作業,問問題。

第二週

第二週,份量會變得非常的重。

主要是「規劃一個整塊功能」並實作。
從 Helper -> View -> Controller -> Model 逐層的深入設計。同時透過這些一個一個功能,把 Rails 常見的功能觀念一個一個帶進去。

這一週的主題是

  • 實作購物車
  • 結帳
  • 生成訂單
  • 切換訂單狀態

同學會學到

  • Helper 常見設計方法
  • Model 常見設計方法
  • Controller 常見設計方法
  • 怎麼樣拆架構,「跳開還沒有頭緒」的架構

第三週

第三週呢,我們實際介紹如何介接「第三方服務」,以及處理第三方服務需要處理的問題。再來,因為前兩週我們把程式寫得很亂了,怎麼樣整理程式碼。

這一週的實戰主題是「寄信」以及「實際付款」以及「部署」。

  • 寄信是教 Mailgun
  • 付款是教 歐付寶
  • 部署是教 Heroku

部署這些第三方服務還會有一些「開發環境」與「正式環境」的差異。我們教如何處理相關的疑難雜症與 debug。

整理程式碼部分我們會教

  • View
  • Controller
  • Model

的相關 Best Practices 收納術,以及整理心法。

第四週

第四週呢,我們教實際從業 production 環境會遇到的各種挑戰。去年我們教了

  • 簡單的 SEO 與 Facebook Opengraph 資訊
  • Frontend 怎麼樣提升效能,
  • Backend 怎樣提升效能,簡單的資料庫設計以及索引原則,怎麼要找效能瓶頸點。
  • 開發時需要注意的簡單安全性問題
  • 求職履歷要怎麼整理

今年這些全部都會教。

另外我還會多教一些簡單的 MVP 與 Growth Hack 實戰。讓你知道一開始哪些產品功能可以先做,哪些不用做。還有簡單的推廣產品技巧。

為什麼這樣設計?

這套課程,內容都是一個 Rails Developer 從業 2-3 年(還未必會全)學到的課題。目前是沒有一本書以及線上教材所可以提供的。全是從我 Rails 從業八年來帶過非常多 Rails Developer 的 Training Cycle 所萃取出來的。

所以如果要說這個班跟其他人有什麼不同。

1) 首先,雖然我們上課只有四周,每次只有 3 小時。但是這 3 小時不是講一些 「網路上就找得到的基礎教材」灌大量時數。我們是教書本上沒有的東西,鐵錚錚的實戰累積經驗。

2) 我們上課是高度互動。學生一定要留時間寫作業(下課要至少寫3-6小時的作業,有解答),下課還來 meetup 問助教問題。每一上上課就能帶很多高度半成品的東西回家。

如果你有點子想自己實作,按照類似的架構就可以搭出有模有樣的東西。

而不是只教你單一個功能,你根本不知道為什麼會這樣設計。(如果要學這種東西,Railscast 很多)

3) 我們教的整理術是 rails 圈內已經演化到有最佳解的東西。所以學生不用浪費時間重新再進行這個 cycle 一遍,還不一定有方向。

這個班從設計的宗旨開始就是要教出:錄取後馬上可以打仗的人。不管是你想要換工作,或者是做自己產品,都可以自己有方向快速上手。

我們不會唬爛你說出來可以變即戰力,事實上每週都在教你網路上的 101。

趕緊報名

這個班是每季才會開一次。錯過了就要等上 2-3 個月。每次開放都是幾天之內就爆滿。

目前 2015 冬季班正在接受開放報名,請趕快卡位:

 
about 9 years ago

昨天剛傳出 HomeJoy shutdown 的消息。雖然行內認為這篇資訊已經夠多,但是我認為還是可以寫出更深一點的評論。

(P.S. 筆者曾在矽谷 O2O A 輪公司任職,擔任 Engineering Lead 且設計主導重寫擴展過整套 O2O 複雜的商業系統架構)。

這篇文章太長,所以我先寫結論。

  1. 如果你只能賭一家 O2O 公司,賭 Uber。如果你能賭第二家,賭 Airbnb。
  2. 初次創業者,不要來碰 O2O。必死。這行不是寫個 "Google Map" + "Billing" 就可以開始賺錢的行業。
  3. 在台灣搞 O2O,嗯...。(我不想直接寫會引發地圖砲的字句)
Read on →
 
about 9 years ago

幾年以來,我在執行專案時,一直是使用「使用者故事」的方式,與團隊一起進行敏捷專案開發。

開發專案時,捨棄寫 Spec,而改由撰寫「使用者故事」。可以讓團隊釐清,整個專案有多少角色,在什麼場景,執行什麼功能。我們再針對爬梳出來的 User Story,進行資源以及執行期限的限制篩選。擬定可以執行的方案。

但是,後來這一套方案在特定的狀況下遇到嚴重瓶頸。我們公司的架構當時是分隔台美兩地。Product Owner 在美國協助整理使用者需求,台灣團隊收到後執行。但是,以往管用的招式在此狀況下卻不管用。

原因是以前如果開發團隊都在同一個辦公室,使用者故事上「沒寫到」的細節或原始情境,透過快速的口頭補述交流,就可以補完。專案不至於執行偏差。但是在團隊分隔兩地的情況下,因為時差與團隊成員功力差異,許多「需求」的「原始情境」會消失。

「使用者故事」變成 Product Owner 的一面之詞,他憑著「自己的判斷」以及「喜好」,寫成了「無原始背景」的技術性用戶故事,加上公司又是 Operation-Oriented,有些細節必須要是在現場才會知道。這些「重要的細節」隨著 Remote 與溝通不良被蒸發,於是「使用者故事」又變成只是「簡單版的 Spec」而已。這讓團隊之間,摩擦又開始變得很大。

於是我掙扎著又設計協調出另外一份問題解決結構,搭配 User Story 執行。方式是這樣的:

  1. 我們遇到了什麼問題?
  2. 為什麼這件事會發生?
  3. 我們目前的限制是什麼
  4. PM 建議的解決方案
  5. (召集相關的開發成員)大家建議的解決方案是什麼
  6. (召集相關的開發成員)簡單的 vote

這份敘事的結構,目的有幾個:

  1. 讓「原始目的」與「原始情境」儘可能的被重現
  2. 讓團隊了解這個問題的資源限制,以作出最好的建議(一天之內要解決?一週之內要解決?或放著想根本沒差)
  3. 讓相關的成員有參與感,以及可以激盪出最好最適切的解決方案。(透過 Hackpad 討論,所以來回不會很冗長,通常一個工作天內會結論與表決同時出爐)。而不再是 PM 的一面之詞。

我們成功用這個架構 deliver 了很多大大小小 tricky 的專案。

本來我們也以為這套方案是獨家發明,後來跟一個朋友聊天分享過後。才發現這其實已經是麥肯錫內的架構解決 Best Practices 了。我在麥肯錫新人培訓七堂課 這本書內有找到更多這套方法的敘述與強化。

以下整理出方法重點:

1. 解決真正的問題

比如說老闆抱怨「最近生意不好」,所以我們要搞個「促銷」。此時重要的不是真的去寫「促銷」的 User Story。而是去找出「生意不好」是指「來客量不高」,還是「單個客人貢獻營業額不高」。

2. 定義問題、假設與分析、解決策略

執行這個步驟的重點在於「分離現象和原因」。利用邏輯樹找出問題結構後

  • 生意不好
    • 來客量不高
      • 每個客戶平均成交率低
      • 沒有花新力在開發新客戶
    • 單個客人貢獻營業額不高
      • 單品平均銷售額沒有增加
      • 顧客平均購買量沒有增加

然後再找出什麼是最重要的議題。(因為沒有美國時間一個一個去做)

3. 根據團隊目前限制針對最重要問題設計出有意義的解決方案

因為產品開發不可能無限制發散討論。一定要有得收斂,且要在「一定時間內」完成,否則超過時間限制,原始的討論也會變得一點意義都沒有,而淪為純清談。

解決問題時必須注意到的重點

  1. 不要受眼前的狀況和條件所限
  2. 經常意識到邏輯思考
  3. 不斷問為什麼?
  4. 為什麼?做什麼?怎麼做?

「為什麼?做什麼?怎麼做?」

在商場上,這三個問題就是把「哪些產品與服務,透過什麼方法,提供給哪種類型的顧客?」只要這三個問題沒弄清楚,就會搞錯方向,浪費資源。

這也是當初我們單純只讓 PO 使用「User Story」單純敘事的缺陷。

PO 少告訴了大家「為什麼?」,而 PO 單方面的決定「做什麼?」「怎麼做?」。

這個方法是一個把產品所有權回歸到整個團隊的好方法。

推薦給大家使用。

 
about 9 years ago

在這個話題上,很多團隊對於「Growth Hack」戰術以及 「Project Management」是否能同時並存且執行是存疑的。因為在傳統的分工架構與流程下,Project Management 強調的是職能分權以及排定優先順序。而 Growth Hack 「印象中」執行的場景是有不分組且跨領域的的 Growth Hacker 獨立的進行產品改造工程。

這兩件看似衝突的事如何一起執行?

產品是誰的?

在繼續講述這個公認為最難的主題之前,我想來先聊一個其他主題。我覺得很多 project management skill 與 framework 在很多團隊裡面沒有效果,其實是一個最重要的前提假設錯了。

這個最重要的前提假設是「產品是誰的?」通常,官方政治正確答案是「產品是大家的」。

但是在許多組織運作現有運作情況下,卻是「產品是 PM 的」。

以至於很多敏捷方法、架構、以及操作方法,在這樣的操作現況下,變得超級畸形以及沒有效率。

Read on →
 
about 9 years ago

2012 年我曾經寫過這幾篇文章:

每個人的困境(藉口)都一樣:「我不開心,但是我不想不孝順」

這幾篇文章常常讓我的臉書被密爆。起手式是這樣的:

Anonymous: Hey, Xdite 你好. 是這樣的, 我最近看到你的文章, 感觸良多. 我最近 "進了大公司", "醫學院念完", "考上公務員", "替代役當了一年", "剛考上公務員". 家人都為我很開心, 可是我很不開心. 他們都覺得我找到了很好的工作, 但我覺得上班很無聊, 看到你的文章, 我覺得你說的很棒很貼切. 「可以跟你交流一下嗎?」

Xdite: 你是想離職嗎?

Anonymous: .......有這個打算. 不知道你當初是怎麼跟父母講呢? 當初會做這個工作是因為 "家人逼我", "家人期待", "社會觀感", "岳父喜歡", 薪水也不錯也很穩定. 我不討厭, 但以後想到將來的 "值班", "開不完的會", "老屁股", "專業上沒什麼熱情", 就讓我很苦惱.

Xdite: 不喜歡的工作就不要做啊.

Anonymous: 很困難啦. 你不知道啦. 我每次透露出這個想法, 我爸媽就會覺得 "我是白癡", "你會餓死", "以後賺不到錢", "不穩定", "不會把女兒嫁給我". 我曾經想過 "先撐過三年", "先撐過專科訓練", "先拿到執照", "先升上主管", "先把手上這份工作上手" 在 "有空的時間", "下班的時間", "上班無聊的時間", 研究我喜歡的題目, 之後再換工作, 你覺得呢?

Xdite: 為什麼你有這樣的想法? 這樣不是很浪費時間嗎?

Anonymous: 沒辦法. 我不這樣做. 離開現在的位子, 父母, 女友, 岳父母 就會跟我鬧革命.

Xdite: 為什麼?

Anonymous: 因為他們會覺得 "我會餓死", "以後賺不到錢".

Xdite: 你會嗎?

Anonymous: 我也不知道. 現在的工作我也不討厭. 所以我很猶豫

Xdite: 不討厭 = 不喜歡

Anonymous: ......XD 對...

Xdite: 你喜歡的話怎會說不討厭呢?

Anonymous: 那你覺得應該怎麼做比較好呢?

Xdite: 辭職,去做你想要做的事。

==== 通常到這裏我會視對方鬼牆程度決定要不要再回應,或直接就放著把視窗丟著不理 ===

這一篇文章不是昨天某一個陌生人或熟人跟我的對話。我的 FB 訊息夾 / Email 大概有兩三百個類似的鬼打牆對話 XDDDD

已經 loop 到我可以直接用背的了。(Siri 到底可不可以內建本功能?)

如何快速打破父母這道迴圈?

其實我不是很想寫這個驚世文(每次寫完這種文章,兩年內我都會因為該文被公幹,兩年後才還我清白 XD),實在是我覺得這個解答邏輯已經可以 Programmable 了,而我沒有一直將來想要進行這種機械式對話。

翻譯:「你會餓死」= 「我不希望以後養你」

要打破這個迴圈,首先需要的是「獨立思考」。

說真的,我期待讀到這篇的讀者,既然你已經有逃離了念頭了,不妨再多花一些腦力。

這些看似打不破的迴圈不是打不破,而是你的大腦無法破題,無法破題的原因可能是因為害怕而抗拒進行解題,或者是一直以來都懶得思考(如果是懶得思考,這樣這篇文章可以直接 end,不適合你)。

父母的話「你會餓死」其實相等於 「我不希望以後養你」。

所以第一件事情要思考的是:「你以後做喜歡的事,就算餓到,你會跟父母伸手要錢」嗎?

翻譯:「你以後賺不到錢」= 「我怕你是廢人,達不到應有的成就」

父母的標準很簡單,只是表達形式糟。在台灣父母眼中「錢」= 「成就」。你可以很賭爛這個思維:「錢」= 「成就」,但這就是現實。

我相信有這些困擾的朋友們,都很會「考試」,所以一不小心被考試的高分沖到了一個自己好像不喜歡的地方。但「你會餓死」,「你以後賺不到錢」,好像沒有標準答案,而且是一種情感式的勒索。所以不知道怎樣答題。

其實標準答案,經過翻譯完就是:父母希望你的月薪至少 "XXX 萬",結束。

我家境沒有很好,所以當初我爸的標準大約是月薪 5 萬。認真幹程式設計師一兩年就有這個數目了,所以我很有把握的硬幹下去。超過 5 萬我就自由了。(如果按照他當初設定的路線,我大概要幹 robot 至少十年才有這個月薪)

所以你也可以設定一下,你想要的那個職業,要投入多少努力和多久才有這個同等收入。

  1. 三年內達得到。恭喜你,現在可以立刻就烙跑!(而且我保證,因為你非常有興趣做你想要做的這行,其實只要花一半的時間就辦得到了)
  2. 5-7 年才達得到。可以研究如何賺其他業外收入或加值收入(賺錢),湊在一起達得到。不要藉口說不可能,你不是很喜歡怎麼不可能?

可是做自己想做的事,好像違背父母的話,好像不孝順?我不想不孝順。

Hey, 仔細看看你父母在表達什麼?

「我希望你經濟獨立,並且變成社會上有成就的人」。

只是他們考試及格的標準,在現在已經 expire 了。就像你聽到「我國首都是南京一樣」會覺得非常荒謬一樣。

所以成為「經濟獨立,並且變成社會上有成就的人」,是很孝順的行為,沒有不孝順。

如何快速打破自己這道迴圈?

「可是,我當醫生、在竹科上班、在政府上班,也蠻有面子的,我不討厭,只是也沒有很喜歡,特別是 XXXXXX 情況很爛」。

Hey, 想想看, 為什麼你有面子? 為什麼人家給你面子? 是因為你是名醫? 你是工程師? 你是高官?

人家是給你的機構面子,不是給你面子

No. 人家是因為你後面的機構 = 有錢 / 有權。但是你本人 有錢 / 有權 嗎?你又真的覺得你的職位「有錢 / 有權」嗎?

你只是想要自己「有錢」「有權」,還可以「做自己開心的領域」

為什麼「你自己」不「做自己很開心的事又做得好」然後因為「專業權威」變得「有錢 / 有權」?

而要躲在一個「不開心的地方」「每天假裝開心上班」再「假裝自己有錢有權?」

鬼島標準:「年薪」= 「人生分數」,想逃跑至少要及格

寫完這篇,也許你會覺得我這個人完全變了個樣。以往在部落格老是大談「有熱情」多重要,賺多少不是很重要,對社會有多少貢獻才重要。結果這篇「錢錢錢」。

Hey, 面對現實吧,爸媽的緊箍咒,其實說穿了就是一張考卷,而 95% 的爸媽,及格標準跟錢有關。你對自己的緊箍咒,100% 跟錢有關。

更實際一點,「你現在的月薪五萬,而你想做的工作起薪三萬五,你想做的工作兩年後才會升到五萬。就算到兩年後才會一口氣升好了,兩年也才差 36 萬。36 萬可以賣掉你的快樂?36 萬等於一天 500 元。」

每天多 500 元跟每天上班都很快樂你要選哪個?何況兩年後都是領一樣的錢。更何況你每天上班都很快樂,兩年後你的月薪可能不是五萬,是七萬。

so, 為什麼你不現在就開始研究怎樣讓自己的興趣開始可以賺錢?

反正,最差的狀況,不管你會不會「變得更快樂」,最差的狀況也只是你會變得「更有錢」,而不是「更窮」。我想你的父母也很難因為「你更有錢」去討厭你。

只是記得告訴我,未來當你因為「玩自己的興趣」賺了更多一點錢的時候,你對「有熱情」跟「賺錢」跟「對社會有貢獻」是否會衝突的看法是什麼?:p

快去研究怎麼賺大錢吧!

====

延伸閱讀

==== 後續追加

網友路直讀後發問:「有個loop困境是就算自己跟另一半都已經超越及格了,但父母還是不滿意,請問如何處理?有些人跟無底洞一樣,永遠不會滿足。」

我的回答「我認識一種人更奧,就是我自己,我還是很不滿意我自己。我比我父母還要奧一百倍,所以我忙著處理我這種奧客,沒空管那些次奧的。」