跳到主要內容

敏捷的世界需要一聲驚嘆 - AHA Manifesto(上)


前言

上週二參加了一場預先不太清楚主題是什麼的分享會,是由一位敏捷社群的大大邀請的,這次的活動有幾點引起我的興趣:
  1. 名額極為限量,主辦單位想排除掉一些已經聽過類似主題的人,把機會讓給沒聽過的,感覺機會非常難得。
  2. 活動禁止拍照、錄影、錄音(後面結語時例外)。
  3. 活動介紹頁不斷的提到 AHA 這個沒聽過的詞彙,網路上也查不到。
  4. 在介紹的末尾寫到:「本次分享不太適合大公司的螺絲釘員工、只願意沉溺於技術細節的工程師、只浮於抽象層面不願意解決實際問題的老司機、自己不改變只想改變別人的Change Agent。」
上述的種種吊足了我的胃口,而且門票只要 300 塊,買不了吃虧、買不了上當,便心一橫決定去聽看看。

由於時值下班尖峰時間,當天我大概晚了十分鐘入場,一坐下就感受到這場講座與眾不同之處,講者 Daniel 是一個能量四射的天才,而且場子並不大(大概 30 多個人),所以他和台下的互動非常頻繁,大概是講五句話就會問台下一個問題的狀態,一般來說台下聽眾都會和講者有一段距離,所以這種問答往往只有小貓兩三隻,更慘一點就自問自答,但 Daniel 透過他對講題的熱情,還有逗趣的反應(BTW 台下似乎有很多人認識他), 在過程中你會不自覺感染他對於自己在做的項目 - G2Rail.com(一個提供多國鐵路票券的訂票網)的熱情,很自然的試著回答他的問題,隨著他熱情的分享很自然的將他三年來如何迭代演進這個網站的歷程很生動的走過一遍,最後半小時再聽他總結從這些裡面獲得的 AHAs,高潮迭起,整個過程 3.5 小時(從 6:30 一路講到 10:00 )幾乎沒有人起來上廁所,講師也沒有要中場休息的意思,是我人生中罕有的聽講經驗。

講座內容

他講了什麼?我覺得用簡單的話來形容是「一個有快速程式實作能力的商業駭客,如何駭入鐵路票券販售的商業空隙」,如果按照一般的分工,應該會有 PM、UI 設計、前後端工程師,甚至是做系統架構的人,還有客服人員、使用者資料分析師負責接收反饋意見,但在 G2Rail.com 這些事情全給 Daniel 包辦了,兼之他又是創辦人之一,有足夠的決策權,每天都可能有新資訊進來、新的領悟、新的想法產生、新的功能上線,所以他在過去這三年的迭代有多快,學到的東西會是一般正規團隊的幾倍速可想而知,而所謂 AHA 一詞其實就是我們在頓悟時發出的「啊哈」聲,所以 AHA 也可以解釋為「悟出的事情」,整個分享其實沒有程式技術背景也可以聽,但若有技術背景會更有感悟。

其實整場講座的訊息量很大,幾乎沒有時間停下來解釋太過細節的東西(要聽細節之後有一千美金的課程可參加),所以我只是聽個大概念,且礙於當中有一些實作上的細節涉及商業機密,我這邊僅分享那些印象最深、他的網站現在就能體驗到的功能,以及背後商業上的心法有哪些:

1. 以用戶的角度去整合資訊,蘊藏了許多機會:對於生長在台灣的我們來說,由於幅員大小的關係(吧?),鐵路系統大概就只有分成台鐵、高鐵和捷運,搭台鐵短程可以用悠遊卡,長程就直接去買票,高鐵大多用販賣機購票,以上兩者都可以利用網站訂票,便利商店取票,至於捷運一律都可以用悠遊卡,就這麼簡單的規則,以至於我們很少意識到鐵路系統可以有多複雜,但像英國有 28 個鐵路公司、光倫敦就有十一條線路,兩百多個站; 日本鐵路則分成國鐵(又分六個子公司)、私鐵(數十個公司)、第三部門鐵道(也是數十個),光國鐵車站就將近一萬個,大阪有一個地方叫「難波(なんば, Namba)」,同時有五個鐵路公司在那邊設了四個站... 以上資訊對不熟悉的外地人是一堆一時很難消化的資訊,其實旅客要的很單純,不外乎就是我從 A 點到 B 點有哪些車可以坐?坐哪一種車比較經濟?轉車次數比較少?是否買特定的優待券比較省?優待券是否會限制我能搭乘的車種?

如果一個網站只是單純的做「賣票」這件事,上述問題旅客都要自己去查,那麼他離開這個網站的機率就很大,除非是國家特許,票券只能在這裡買,再不然就是這邊買特別便宜(通常小的創業者不可能有以上兩種條件),所以 G2Rail.com 這三年來便做了很多優化,例如:只要輸入你的起點和終點,系統會自動帶入最合適的車站和轉乘資訊,省去很多功課的麻煩,此外你還可以選擇「出發最早」、「轉乘最少」、「價格最低」這三種排序方式,以及進一步觀看車輛簡介、車廂內有提供的設施與照片、沿途會經過的車站資訊,你所需要做的只有挑選最適合自己的票券後付錢購買。

小結:人都是喜歡便捷的,因此每一個要到別的地方找資訊都是一個 Broken,藉由預先整理資訊而把客人留住,都有可能蘊藏了機會。



2. 用系統思維來做事 & 挖掘使用者數據以獲得 Domain Knowledge:為了進一步替訂票網站帶來流量,Daniel 參考了一些寫得不錯的介紹文,做出了類似「英國火車終極指南」這樣的鐵道攻略樣板(包含:哪些車型、哪些座位種類、如何上車、如何選座、如何轉車... 等),再雇一些文科生來將每個國家的每個鐵路公司的介紹一篇篇寫出來,如果只是上述這樣,雖然路術正確,但速度很有限,所以他借助了 Google 翻譯 API 來把文章翻譯成 12 國語言,並將上述翻譯動作整合進 Jenkins 的網站部署過程中,我的理解沒錯的話,他正在將所有的資訊結構化,形成一個語意網,也就是說將世界主要國家的所有鐵路相關的資訊塞進結構化的網絡中,例如:國家、城市、鐵路公司、車站、透過鐵路接壤的城市、月台、照片、站名縮寫、車站的廁所符號... 等鉅細彌遺的資訊,一旦這個網絡漸漸形成,上述產生文章的工作就不難想像可透過程式來完成,而且因為作為模板的第一篇文章還內含有益於 SEO 的 DOM 結構,所以後續按那個模板生成的文章也就自然會在 SEO 上佔有優勢,再想像每一篇文章內都嵌有 G2Rails 的訂票界面,旅客不僅可以在該文章得到充足的資訊,還能夠直接在那邊下訂,誘因可說是非常的強,輔以多國語言和 SEO 的優勢(很多國家對於另一個國家鐵路的資訊很少,先搶佔關鍵字的排名前面位置,就算是機器自動產生的文章,也足以對該國的旅客提供有幫助的資訊),等於有自動化的機器人 24 小時替 G2Rails 招徠客源,只要一開始模板生好了之後,管理者只要定期檢視導流成效,不定期翻新一下個別車站資訊以及調整一下文章模板就能等著生意上門,還有什麼比這個更貼切的被動收入呢?

全世界鐵路資料 x 多國語言 x 列車即時運行資訊 這三個維度展開的龐大資料庫正是 Daniel 現在費心開展的弘大計畫,如果發展起來的話對所有鐵道乘客將是一大福音,也是 G2Rails 一項非常棒的競爭優勢。

當然上述方式還不能高枕無憂,Daniel 還有提到另一點,就是他勤於觀察客人在網站上的行為(事實上從他的言談之中就會體認到他對各國鐵道的如數家珍,已經到了鐵道專家的程度,做一門生意就要對該行檔了解到這麼透徹才行),好比他透過觀察站內使用者的搜尋行為,得知真正要買車票的旅客會去關注自己要去的城市要在特定車站的哪個月台搭車,所以如果針對車站月台去買關鍵字,買來的流量就會有很高的成交率(因為他們離發生實際購票行為已經很接近),唯有對用戶夠瞭解,你才知道要去買什麼關鍵字,站內的介面要做怎麼樣的優化,所以要顧好一盤生意要用系統化思維來提升效率(會讓你和競爭對手的差距大大拉開),也要注重使用者行為分析,結果可能會帶來很多你意想不到的幫助。

好了,先寫到這裡,下一篇再來分享 Daniel 給我們的 AHA 結語吧!

下篇:敏捷的世界需要一聲驚嘆 - AHA Manifesto(上)

參考資料:

  1. 日本鐵路(一):鐵路公司及種類



留言

這個網誌中的熱門文章

敏捷的世界需要一聲驚嘆 - AHA Manifesto(下)

究竟新創公司應該維持怎麼樣的節奏最有利於創新?最後的結語更加精彩,是 Daniel 這三年創業在不斷嘗試中歸結出的心法,我想對於每一個產品人、商業策略制定者,乃至於工程師都很有幫助: AHA Inhibitors(抑制創新的因素) Prediction & Perfection:過早試圖預測與最佳化、加入很多 KPI 和 Metrics(衡量指標)、加入很多組織架構,這些都會讓事情變得不好玩,Daniel 的玩法是有了想法要搞獨奏,不依賴他人能力、自身快速迭代,他稱之為「Playful Solo」,就像一個人在獨奏某樣樂器似的那樣忘我,當然啦,我覺得這點會隨著組織狀況和個人能力不同而不同,一個多元能力的人要搞獨奏容易,但一群人要同時進入這種狀態,能一同往好的方向創新,那又是另一個層次的問題,但不論組織大小如何,就個人經驗來說的確過度預測和最佳化多半只是為了讓自己安心而已,並不能為事情帶來實質幫助(還記得 之前這篇 寫的暑假計畫表嗎?)。 Knowledge Shield:這邊指的是組織中有太多的專家,他們對於某項東西已經太熟了,以至於對任何創新的點子都多少帶有成見,讓一些想法在萌芽階段就被各種抨擊打掉了,所以他認為組織中應該要有專家 / 創新者的平衡,不具備專業但具備研究辦法的人是很需要的。 Concrete Reasoning:要有推論,但不要鑽牛角尖,決定論也會扼殺創意。 Velocity vs Speed:追求速率的同時要看看是否在正確的方向上,否則速度再快,方向錯了也無濟於事,去思考看看你的工具箱中是否有不同維度的工具,而不是用人工去拼,如:把 Jenkins 自動部署轉個彎,便能自動化生成多國語言文章。 AHA Manifesto(創新宣言,仿敏捷宣言格式 XD): Trivial & Detail over Big & Abstract:瑣碎的具體細節 勝於 大且抽象的概念,捲起袖子去做很多具體而微小的事,不要整天吹高大上的概念。 Continuous over Do It Once:連續性的執行 勝於 一次做完(他會一件事先做一點,想一陣子再做一點,很像敏捷的小量快速迭代),做很多重複且具聽的事。 Shortage over Abundance:匱乏 勝於 豐裕(窮會逼你想到變通方法,有錢人...

敏捷治百病?我只知道敏捷治好我的拖延症

前言 上週受朋友之邀到某知名企業做敏捷文化的分享,雖然只是企業內部的內訓課程,人數並不算多,但能藉由這個機會整理一下近三年來接觸的敏捷相關知識,又能了解大企業內部導敏捷遇到的困難點,我其實滿期待的,為了準備這次分享,六月以來讀了大量的參考資料以及參與了幾次敏捷社群的聚會,慢慢在腦中建構了和那些不同於我平常工作所熟悉的例行性會議(如:Daily Scrum、Sprint Review、Sprint Planning、Retrospective...等)的幾個核心信念,分別是:價值導向、自組織團隊、快速迭代與調整、實際互動,其中我特別留下深刻印象的是「快速迭代與調整」這點,而之所以會產生深刻的印象,是因為七月底的去聽的一場演講 -- David Tung 董大偉  主講的 Agile work x Agile life ,裡面提及的一個新穎的觀念叫做「人生敏捷法」,和我這幾年來對抗拖延所悟出的心法有 87 分像。 那些年的暑假計畫 其實長期以來自己都不是那種可以按步就班完成事情的人,小時候每到暑假,大概從國小高年級開始一直到高三吧,大多頭一個禮拜家父就便會找我去訓話,大意就是說如果沒有好好規劃這段時間,日子很快就會過去,然後接著就要面對現實的高中、大學聯考,沒有充分準備的話很難考到理想的學校,沒考到理想的學校就會失去競爭力,時間很快就過去,最終會成為漫無目的的大人... 等等,話都說到這份上了,我終究只能配合來列出一張暑期計劃表,上面就是按日期排列的格子,然後下面列出當日要做的事,一直列到八月底暑假結束,大概就像下圖: 出處: https://christine327324.nidbox.com/diary/read/9785159 但就實際結果來看,這樣的計畫沒有任何一次真的發揮它的功效,總是第一天完成度最高,接著開始逐日遞減,直到最後和我的實際生活完全脫鉤 XD,當然最終暑假作業還是必須得交出來,但往往都是最後半個月才在趕,暑假作業目的就是設計來讓我們溫習或是預習用的,最後半個月的囫圇吞棗效果其實並不太好,如此一來變成前面的時間沒好好玩到(因為心裡會一直惦記著計畫沒做)後面應付式的學習成效很差的困境。 上述的情況一直延續到於出社會的這幾年,當然非得做的事情會趕在 deadline 之前做好,但對於那些長期來說真正重要...