2015年12月23日 星期三

精實執行-精實創業指南

a357_OK

 第一次接觸到Lean Startup(精實創業)的概念是讀了Eric Ries的書 (精實創業:用小實驗玩出大事業),但是 Eric 書裡的內容比較像是心法概念,真正要去執行時卻有不知如何操作的疑惑,一直到我讀了這本「精實執行」,看到作者提出一個可以參考的執行程序,真是相見恨晚。

 作者指出區分成功與不成功初創事業的關鍵未必是「成功初創事業是由較佳的初始計畫(亦稱作計劃A)展開的」,而是「在耗盡資源之前先找出有效計劃」。

 對照自己在新創團隊一年多的經驗,實在是描述的很貼切。自己在辦公室想出來的計劃一定要走出去跟潛在客戶互動才能學習到用戶真正要什麼。像我們團隊成員都有聽過精實創業思維,但要如何跨出辦公室與潛在客戶訪談、發現問題、評估、再學習卻不知如何有效行動。  

 本書提出了「精實執行」的三個 Meta-Principle.

1. 文件化你的初始計劃
 寫下你的初始遠景,然後至少與一個人分享。在一般的企業情境中,若要kick off 一項新創project,通常會被要求先寫營運計畫書(business plan),但因為大多數的初始計畫最後很可能都是錯的,所以你需要某種不像商業計畫書那樣很制式化的內容。花費數週甚至數月撰寫一份未經假設驗證的60頁商業計畫書,基本上就是一種浪費。

lean canvas
精實畫布(Lean Canvas)

 在本書中,作者提出了格式如上的一頁式精實畫布(Lean Canvas)。第一份精實畫布可以在15分鐘內完成,協助創業者將商業模式解構成9個獨立的元件,然後按照風險最高到最低的順序,以系統化的方法試驗之。

2. 識別出計畫中最具風險的部分
 對於大多數的新創公司來說,比較大的風險是「建造没人要的東西」,在不同的階段則有不同的風險要考量。創業者必須隨著時間的推移有系統地去除新創事業的風險。
作者指出新創事業有三個階段,各階段必須回答不同的關鍵問題。

3-stages (2)

 在產品/市場Fit之前,應該把焦點集中在學習與軸轉(pivot)上,在軸轉實驗中,創業者將反覆地驗證(validate)商業模式假設(business model hypotheses)以找到真正可行的計劃。在產品/市場Fit之後,焦點則轉向到成長與最佳化上,在最佳化實驗中,創業者藉由改善(refine)商業模式假設以加速在前面發現的可行計畫。前者的目標是路線修正或軸轉(Pivot),而後者的目標是提升效率或擴展。

 另外為了最大化學習的成效,創業者必須挑選大膽的產出(bold outcomes),而不是追求逐步的改進(incremental improvements),例如與其修改 call-to-action 的 button color,不如實驗改變整個 landing page。 

3. 有系統地試驗你的計劃
 有了初始計畫並且為可能風險訂好優先順序後,便可以透過執行一連串的實驗(experiment)來有系統地試驗商業計劃。

 「精實執行」所提到的實驗(experiment)即是下圖中所謂的Build-Measure-Learn loop,由 Eric Ries在精實創業中提出。「Build」階段根據一組想法(idea) 與假說(Hypothesis)所製作的 mock-ups, landing page, prototype 等,將這些成果拿給顧客測試收集定性及定量反饋資料以評估顧客的反應;根據這些資料來驗證一開始的假說是否為真來獲取學習心得,進而引發下一輪的行動。
Build-Measure-Learn loop
Build-Measure-Learn loop

一個實驗可以幫助創業者驗證或反駁特定的商業模式假說,然後串連多個實驗以完成特定的目標。例如逹成Product/Market Fit。

iteration meta pattern
上圖是「精實執行」使用的 iteration meta-pattern,前二階段著重在「找出值得解決」的問題。之後再利用先定性再定量的方法評估所建造的東西是否為人們所需要,然後再逐步反覆迭代到 Product/Market Fit。

本書之後的章節,分別為
  • 建立精實畫布(Lean Canvas)
  • 排定執行優先序
  • 準備實驗
  • 準備訪談顧客
  • 問題訪談
  • 解決方案訪談
  • 產品-版本1.0
  • 準備評估
  • MVP訪談
  • 驗證顧客生命週期
  • 評估產品/市場適配
作者舉了許多實際的例子說明 Lean Startup 的執行步驟,若你也想要嘗試精實創業這個方法,強烈建議你一定要買一本來看。

2015年1月2日 星期五

2014年度回顧


2014年我做了一個人生的重要決定,離開任職十多年的法人機構加入一家國內網通業者的內部創業團隊。我很高興也很感恩新老闆能讓我在台中成立一個Agile Team。簡單回顧下半年換新工作後自覺做得不錯的事
  • 6/14 跟朝陽科大唐教授等人辦了第一場 Python Taichung Meetup
  • 9月底台中辦公室啟用,是一個 Agile friendly workspace
  • 12月辦了一場 Kanban 桌遊工作坊, 因而促成 Agile Taichung Meetup 的成立(2015 每月會辦一次)
  • 逐步落實團隊的 Agile practice,讓member (包含 designer & engineer) 可以快速的協同工作
之前在台中遇到資訊領域的朋友都會說台中在地 meetup 很少,其實當我有想辦 meetup 時代表有其它人也是有同樣想法的,所以大家一談就立刻有一群熱血的朋友跳出來,所以2014下半年台中就有了Python Taichung(反而我後來只是參加而已 XD);而2015年還會有Agile Taichung。

另外「連辦公室都是從無到有建立一個RD團隊」的經驗是人生第一次,過程中也學到了不少以前從没有想過的細節,其中感受最深的還是人與人之間的溝通。

第三個感受是團隊的人對了,敏捷實務的推動就自然順利了,在之前單位想做而無法順利推行的實務,在現在的團隊中卻是很快的落實。

對於2015年,自己的新計畫是:
  • 每月舉辦一次 Agile Taichung Meetup,今年下半年希望可以挑戰辦一次 Agile Tour Taichung
  • 團隊的Kanban流程可以落實到量化的管理
  • 第一季以前要讓MVP上線到Google Play,儘快取得end user 的 feedback
  • 努力做好自己的GTD
  • 安排時間做運動
新年快樂,大家加油

讓Agile社團在台中落地

圖片來源: techdistrict.kirkk.com

把12/23發佈的FB的網誌,匯整到這個blog
----------------------
11/28 David 在 FB Scrum Community in Taiwan 提出 "Agile Tour 落地生根" 的想法,文中提到有一位台中的朋友說: "真心希望往後台中的軟體業可以更加成長而成為另一個聚落,讓我可以下定決心回鄉發展”,我心中著實也很期待讓台中軟體圈熱起來.

我是在台北長大,卻剛好在台中落地.之前在台北幾乎每天都可以找meetup去參加.來到台中,遇到同行大家常常感歎在地很少有跟軟體開發相關主題聚會可以參加,但這一年來陸續看到或參與 "享實作樂","台中前端社群", "Python.Taichung", "光明頂創育智庫"...等社群主辦的活動,感受到台中軟體圈似乎漸漸動起來了.

12/6在台中辦完看板桌遊後,David 找了幾位表達有興趣參與Agile Tour Taichung 志工的網友,大家討論要如何開始,我給自己挖了個坑來當主辦人.第一次的聚會先決定在我的辦公室跟台北 Agile meetup 直播連線.

昨天晚上氣溫頗低,本來還在想是否會降低參加者的意願,但是到了7點原本說好的網友都來了,心中真是感動.

昨晚除了學習到台北Hugo分享如何利用看板流程精進自己的看書計畫(感謝 Tony 支援 Adobe Connect 連線直播),大家也很熱血地決定了2015 年度目標:年度活動大略規劃為:
  • CodingDojo x 2
  • Kanban/Scrum Game Workshop x 2
  • Agile Tour Taichung 2015 x 1
活動時間:以每個月第三個禮拜一晚上7:00開始為原則,需長時間活動選擇禮拜六
第一季度活動規劃:
  • 一月: CodingDojo by using Python,
  • 二月: 停辦,
  • 三月: Scrum實踐分享
在討論中我聽到台中的軟體開發團隊其實比想像中的多,期待明年大家都來Agile一下.






2014年11月28日 星期五

台中 Kanban 桌遊工作坊

kanban board game圖片來源: meetup

今年11月8日參加了 Agile Tour Taipei 2014, 當天下午是參加“看板桌遊工作坊”。

雖然我們團隊目前是採用Kanban在進行專案管理,但除了我之外團隊成員對於Kanban的WIP以及度量方法(CFD)還没有很深的體會。當天在2個小時的過程中,透過getKanban ( http://getkanban.com/ ) 這個桌遊很快地讓我體會到
1. Kanban 工作流程運作
2. 如何在開發中進行工作項目限制(WIP)
3. 如何處理不同類型的工作(例如緊急任務)
4. 如何度量: CFD, control chart, cycle time
5. 如何自backlog挑選user story

在當天的 Retrospective session 我自己設定一個action item:要在台中公司辦一場Kanban桌遊工作坊。也非常感謝 David Ko 熱心贊助,願意在12月6日來台中帶這個工作坊,目前這個工作坊已經有盟創雲應用中心及台中另一友人的公司同仁共14人參加。但我覺得David 難得來台中,跟他討論之後應該還可以再開放6個名額,如果你對Kanban有興趣、想要在最短時間內對Kanban有簡單的認識,這套遊戲應該是最有效、最模擬、最互動、最好玩的方式。
有興趣的朋友請到報名網頁(http://mitracloud.kktix.cc/events/kabangame-taichung-2014)報名。

Kanban桌遊工作坊
日期:2014/12/6
報到時間: 13:30~14:00
工作坊時間:14:00~17:00
議程:
Kanban 簡介 (10 min)
getKanban 遊戲說明 (20 min)
play getKanban game ( 策略說明:討論為什麼會贏; 分享心得:討論 swarm, WIP, 以及分析圖表)

PS:這一次的費用由盟創贊助,下一次的話則會酌收費用。

參考資料
1. 看板遊戲操作心得
2. 看板培訓課程筆記 - 看板遊戲玩後的感想


2014年7月18日 星期五

Agile Workspace

agile-office-environment_with-comments
圖片來源:Henrik Kniberg

最近終於把台中辦公室的地點確定下來,並且著手規劃敏捷團隊的工作環境。
Mike Cohn 曾寫過一篇blog “The Ideal Agile Workspace”, 文中提到一些元素。依此列表來自我檢查一下

2014年5月16日 星期五

新的旅程啟航

new trip
圖片來源:pixnet blog

  我在本週離開了工作十幾年的法人機構,進到業界開始投入一項新的計畫。有些朋友問我在法人做的好好的為什麼想出來到業界?也有些朋友關心:這一出去似乎有很多的不確定性!其實一開始在考慮是否離開前公司時,也確實對未來的不確定性猶豫了一陣子,但在綜合考量了自己對工作的期待、業界現況以及家庭因素後,決定把握這次的機會試看看。
  今天想來分享其中的二點思考面向。
  其一是去年看了「人生是永遠的測試版:新創企業家改寫生涯的方程式」,書中提到了ABZ計畫:
  • A:你現在正在做的事。
  • B:你需要改變目標或方法時所採取的應變對策(轉用B計畫的時間點:當某件事行不通了/有更好的機會,就是轉為執行B計畫的時候。而最好的B計畫,就是和你目前做的事情不一樣,但密切相關。)
  • Z:你的救生艇計畫,當轉換到B計畫失敗了你是否有救援方案?

2012年11月21日 星期三

你的品質 vs 我的品質

high-quality
Image by shutterstock
最近得知一位的客戶A對我們Team的產出的品質不太滿意(是由另外一個單位所作的滿意度調查)!但和另一位客戶B相比,我們Team的成員普遍認為交付給客戶A的產品品質遠高於交付給客戶B的產品,而客戶B對我們Team的滿意度卻高於客戶A所給的分數。
(註:這兩個客戶的產品需求是很相似的)
 溫柏格在「溫柏格的軟體管理學:第一級評量」中有一個例子,有一家軟體公司的經理人員認為延誤交期對小型專案無妨。但公司用問卷調查方法去評量顧客滿意度,用1到7的數字代表專案的好壞,並將之轉換為臉型。(最燦爛的笑臉是最高滿意度,而黑色的骷髏頭加兩根骨頭則是最低滿意度),以下是分別是顧客滿意度及開發人員滿意度的結果:
quality-11
圖1:顧客滿意度
quality-21
圖2:開發人員滿意度
讓資訊部門經理大感驚訝的是,顧客對於大型專案没有那麼不滿意,即使這些專案在時程的延說超過原訂時間的25%到125%。(有一個專案得到骷髏頭和兩二根骨頭,是因為能否準時交貨攸關到顧客的生意) 其它專案的顧客在使用新軟體前需要有許多準備工作,因為顧客本身在守住時程上遇到許多問題,其實他們大體上反而很高興軟體有延誤。
 但針對開發人員滿意度的結果顯示:顧客和開發人員對於何謂專案品質所採用的標準是不一樣的。顧客所關心的是對於他們商機會有怎樣的影響,而開發人員最在意的是對於自己工作的成果是否滿意。
 對開發人員來說,專案做得愈久表示要花好久時間test & debug,對此他們會感到壓倦。規模較小的專案雖然也有延誤,但開發人員不會因花幾週的時間test & debug 而厭倦。
 然而小型系統大多需要很快就能派上用場,若有延誤做生意的機會已完全消失,這是顧客最不滿意的情況。
 以上書中的說明正是我們Team的客戶A情形,我們交付的產品是客戶A要立刻拿去做生意的;相對於客戶B,我們交付的產品比較像是公司內的POC還要整合到既有產品中才會開始銷售,所以客戶A對於時程延誤的容忍度很低,也因此給了我們一個大叉叉!
 溫柏格還提到「軟體第零法則」:
如果軟體不需實際派上用場,那麼無論需求是什麼你都能符合
 經過這次的經驗,我未來對於不在乎品質的顧客其實更有信心如何去交付結案了. ^_^
謎之音:真得有不在乎品質的顧客嗎?