導讀:說起敏捷開發,並不是因為敏捷而敏捷。這幾年的敏捷開發已經被很多敏捷諮詢服務商神話了,這個東西並不是神器,實施了就可以解決所有軟件公司的問題,而是要結合自己公司的特點和問題摸索出適合自己的一套模式。
大家都知道,創業公司剛開始需要研發出一款產品並且能夠使公司賺錢的產品,不過大部分創業公司沒有那麼容易一下就能做出來,很多公司還沒有成功的產品資金鏈就斷掉了,公司也死掉了。我們公司是這樣一個狀況,有一條產品線可以維持公司開支並僅僅剛夠盈餘,要擴大高速發展還不夠,一直維持就沒有創業的意義。另一條線是做技術創新為未來能夠開發一款人氣爆棚的產品摸索著,但是又不能餓著肚子去開發。我們是如何結合自身的特點實施敏捷開發的呢?一個難題,很大的難題!
我們技術團隊人員是這樣的配置:1名技術總監、2名資深開發工程師、1名高級開發工程師、2名潛力開發工程師、1名前端開發、1名測試。技術總監需要處理很多團隊管理、客戶管理的工作,能夠參與項目的時間最多每天二分之一。2名資深開發需要負責給其他工程師做導師,參與新項目開發時間大概有80%。高級工程師要預留項目學習時間,參與項目的時間大概有90%。潛力開發工程師需要有一些時間學習技術和項目,但是基本可以做到70%的時間投入項目。前端開發和測試哪裡有需要就在哪裡革命,屬於機動部隊。
現在總共有六個老項目在維護,兩個新項目需要開發。六個項目的維護總共需要每週4人天時間(人天指需要花1個人4天的時間完成一個事情)。其中一個新項目「項目1」大概估計120人天的開發時間,需要1個月之內開發完成。「項目2」大概估計要40人天的開發時間,需要2周開發完成。而現在的人力按照能夠投入的時間算一下,總共資源為 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6個老項目每週需要4人天,一個月4周,需要 4 * 4 = 16人天。項目能夠投入的資源有 132 – 16 = 116人天,而總共需要120 + 40 = 160天,足足少了44人天,這看起來是一個不可完成的任務。
不過到最後,我們還是使用敏捷開發完成了這兩個項目,也沒有影響老項目的維護。我們是怎麼操作的?最開始我們兩個開發,這個時候只要兩個人就能夠很好的合作把產品開發出來,不需要什麼模式。隨著人員的擴充,團隊間如何協作按時按質按量完成任務就需要好好思考下了。
嘗試一,傳統軟件開發模式。整個過程為 需求分析、系統設計、任務分解計劃安排、開發設計、編碼、測試、交付、驗收、維護。這個模式也是大家最常使用的模式,不過套用在我們公司時我們是這麼操作的。
傳統開發過程
由於公司創業,老闆有一個想法,但並不能很好的描述需求,所以需求分析的任務落在技術總監身上。系統設計和任務分解剛開始是技術總監完成,後面資深開發工程師可以承擔一部分。開發設計可以讓各個開發工程師完成,資深工程師進行把關,再到測試人員測試,最後再交付用戶驗收、技術維護。看起來很好的模式,開發了幾個產品最終有的延時有的產品離用戶的期望差距甚遠,參與項目團隊的人信心受挫。
為什麼會失敗呢?後來思考了這些問題:
1、技術總監不是產品經理,不能夠承擔產品設計的責任。老闆是信任技術總監能做好產品,就交給他做。但這裡搞混了一個概念,產品經理和項目經理,技術總監應該起到項目經理和架構師的作用。項目經理管控項目進度和計劃、架構師把握整體技術問題。而技術總監接到這個任務又不能不做好,責任所在。說到底,就是機制沒有把產品設計和項目經理區分開,不等於技術實現者就是產品設計者。更多的應該讓老闆或者其他業務人員承擔產品設計的工作。
2、需求不穩定,變化後改動代價大。由於創業,需求為了適應市場會經常調整,但是一但調整,很多開發計劃就會受到相應的調整。如果部分功能已經正在開發,調整需求後很多工作要重新開始,嚴重影響了技術同事積極性。業務不調整需求是不可能的,他們是為了滿足用戶的要求,用戶滿意了才能給企業帶來價值。不過如果調整,代價太大,很多代碼要重寫,大家就會責怪技術總監或者項目負責人沒有把握好需求。
3、團隊經常加班,但戰鬥力不強。 核心團隊疲於應對需求、技術開發、老系統維護,沒時間指導新同事技術學習,而新同事技能暫時還沒有發揮出來幹活效率低,任務經常延期,沒有成就感。核心團隊事情很多,沒有時間整理項目文檔,新員工沒有文檔上手慢。大家每天很多事情,需要加班才能完成,比較疲憊。每個人除了工作還有很多事情需要做,比如回家看看電視、陪陪家人、看看書學習一下等。如果讓一個員工一天二十四小時都是工作,他能同意,他家人也不一定同意。讓大家愉悅的開發,比疲憊的上班效率要高很多。
4、交付軟件質量差,離用戶期望差距大。創業時大家的想法都是好的,大干一番,做一個所有人都愛使用的產品。現實是殘酷的,大家辛辛苦苦做出來的東西,老闆不滿意、用戶不埋單,付出的努力沒有人認可。交付的軟件沒時間自測試,或者自測試不充分,交給測試又是一大堆問題。有些公司還沒有測試,直接出去給用戶,相當危險。這樣交出去的公司不僅僅影響了用戶的使用,還影響了整個公司的口碑。
不是說傳統軟件開發模式不好,只是不太適合我們這種創業公司。開始嘗試其他模式,如果沒有一個很好的體制就不能把大家的最大生產力發揮出來。
嘗試二,敏捷開發模式。敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。敏捷方法強調以人為本,專注於交付對客戶有價值的軟件。在高度協作的開環境中,使用迭代式的方式進行增量開發,經常使用反饋進行思考、反省和總結,不停的進行自我調整和完善。
敏捷開發的主旨:
一:個體及交互比流程與工具更具價值
二:可用的軟件比冗長的文檔更有價值
三:與客戶的協作比合同談判更有價值
四:對變化的響應比遵循計劃更有價值
而我們之前的問題,交付軟件客戶不滿意、延期、需求更改代價大貌似都可以解決。這麼好的模式趕緊要試試,先看一張敏捷開發的流程圖。
創業公司敏捷開發敏捷流程化
敏捷開發簡單流程:
1、產品負責人將整個產品設計成產品backlog。產品backlog就是一個個需求列表。(backlog可以理解為需求或者要做的事情)
2、召開產品backlog計劃會議,預估每個backlog的時間,確定哪些backlog是需要在第一個sprint中完成的,即sprint的backlog。(sprint可以理解為一個團隊一起開發的一個任務集合)
3、把sprint的backlog寫在紙條上貼在任務牆,讓大家認領分配。(任務牆就是把 未完成、正在做、已完成 的工作狀態貼到一個牆上,這樣大家都可以看得到任務的狀態 )
4、舉行每日站立會議,讓大家在每日會議上總結昨天做的事情、遇到什麼困難,今天開展什麼任務。(每日站立會議,是在每天早上定時和大家在任務牆前站立討論,時間控制在15分鐘內)
5、繪製燃盡圖,保證任務的概況能夠清晰看到。(燃盡圖把當前的任務總數和日期一起繪製,每天記錄一下,可以看到每天還剩多少個任務,直到任務數為0 ,這個sprint就完成了)
6、sprint評審會議是在sprint完成時舉行,要向客戶演示自己完成的軟件產品 。
7、最後是sprint總結會議,以輪流發言方式進行,每個人都要發言,總結上一次sprint中遇到的問題、改進和大家分享討論。
我們怎麼結合敏捷開發解決現有項目的問題,要記得任何措施都是為了保證按時按質按量把軟件交付給用戶,不要為了敏捷而教條實施敏捷,公司不能產生商業價值,任何先進的理念或者技術都是無意義的。我們做了這些措施:
1、推廣敏捷開發理念。不管是大公司還是小公司強制推行一項制度效果一般都不怎麼好。要能推行下去的任何東西一定要大家接受的,才能被認可。
首先培養測試小妹學習敏捷開發,後續讓她承擔部分產品責任人和敏捷指導者的角色,原因有:
a、測試要驗收功能,必須理解業務需求。
b、測試也是QA質量體系的一塊,學習好了對於軟件質量有個更深的認識。
c、團隊大部分是男生,女生推廣更有親和力一些。
召集所有技術團隊開會準備推廣。開始和測試小妹好好討論下,怎麼給大家說更有效,更容易接受。她要講解一定要自己非常清楚敏捷開發,並且準備充分知識點。開會時先指出我們現在問題,讓大家看看有什麼想法解決問題嗎?現在我們做的產品,客戶不認可、老闆不滿意、自己很累沒有成就感,有什麼辦法解決。在大家討論後,拋出敏捷開發的優勢,一般情況下大家都會認可的。大家可能會問到如何執行、落地,可以嘗試找一個項目試點,如果實施成功就可以讓大家全面推廣,不成功也隻影響了部分項目。
2、搭建敏捷開發環境。大家要實施敏捷開發,需要比較好的基礎條件保證敏捷開發順利進行。主要幾個關鍵的軟件:nexus 搭建倉庫依賴中心、maven 管理工程的依賴、jenkins 持續集成和自動編譯發佈、svn 集中代碼管理、jira 記錄需求和狀態。具體參考《敏捷開發環境搭建》。
3、敏捷項目實施。整個公司建立以業務目標為導向的氛圍。就以「項目1」來說,目的是完成這個項目,需要進行這幾步:
先根據各自的能力和意向聚集一批完成這個目標的勇士,不管技術和非技術。如果聚集的人不夠,技術總監可以根據總體項目的投入機動調整資源以支持,不過條件允許的話還是根據大家意願來聚集。最終「項目1」召集了一個技術總監、一個資深開發、兩個潛力開發、一個前端、一個測試,除去大家做其他事情的時間,總共可以算作4個人。
充分調動客戶(老闆和業務同事)參與進項目,他們的參與直接決定了項目成功與否。結合之前的經驗,如果他們參與不夠,最終做出來的東西就不是他們要的,或者離他們要的差距很大。他們剛開始加入的時候,很迷茫有時會表現的比較抗拒,這個時候一定要耐心堅持讓大家把第一個sprint開發成功,使大家嘗到甜頭。讓他們全程參與項目也是表示了我們擁抱變化,如果有需求變化,就添加任務到任務牆,大家可以對所有任務的時間有個全面瞭解,如果超過sprint結束時間就需要業務決策哪些功能不在這個sprint週期加入。
技術總監安排和客戶溝通,客戶這裡指老闆和業務。測試小妹負責和客戶溝通記錄,技術總監輔助。多次溝通後,嘗試讓測試把需求原型用最簡單的工具繪製出來,技術總監審核通過後和客戶溝通確認,反覆迭代,直到整個需求大家沒有異議。很多公司這種需求是有一個專門產品負責人來執行,但按照我們目前的人力是沒辦法做到的。這裡沒有讓技術總監做主要是為了避免之前出現的問題,過度技術設計產品。
產品設計出來後,召集項目成員分解任務,確定每個任務的時間,可以使用敏捷撲克牌來估計。任務分解儘量控制在1-2天的粒度,這樣大家1-2天就可以做出一個能測試的原型,儘早可以集成測試發現問題。一個sprint的任務集合儘量控制在1-2周,不能太長,也不能太短。太長會出現疲勞,太短的sprint會讓大家覺得工作太多,做完一個又一個。「項目1」估算結果為120人天,總共投入4個人,需要30天4周時間,我們切成了4個sprint,差不多1個月時間完成,滿足業務的時間要求。
分階段實施sprint,繪製任務牆,劃分未開始、已計劃、進行中、完成、燃盡圖。把要做的sprint任務上牆,貼到未開始的地方。
創業公司敏捷開發任務牆
每日站立會議大家認領任務。包括業務任務、開發設計、開發編碼、前端設計開發、測試等都是一個個任務,統一管理起來。強調的是一個團體,如果有同事請假,其他同事可以頂上完成任務。站立會議總結昨天的任務是否有問題,對於當前的任務有什麼建議,儘量控制在15分鐘內,有效會議。這裡不會像以前業務或者項目經理追著大家屁股要結果,而是團隊驅動,每天大家做的事情都反映在牆上,誰出現了什麼狀況,大家都會幫他想辦法,保證整個項目能夠成功。每一個任務完成,由項目執行者把任務從進行中貼到完成區域。再從未分配區域認領新任務貼到進行中的區域。
軟件開發過程。認領任務後,怎麼保證大家開發有質量的代碼?團隊有資深點的工程師,不需要太多指導,直接可以參與項目的開發。而學習型工程師,需要指導幫助才能一步步做用例、系統分析。技術總監不建議認領太多開發任務,他負責開發團隊的概要設計審核,沒有審核通過的設計不能開發,並指導大家分析和設計系統。大家都知道,系統思路有了,剩下就是技術實現的過程,只要技能掌握熟練實現基本難度不大。大家可能會問,敏捷開發不是強調軟件開發的產品是軟件,而不是文檔嗎?我們這裡也不是像傳統開發軟件一樣為了文檔而文檔,只是讓大家把自己的設計思路寫下來,只有經過自己仔細設計後才能把思路清晰的寫下來。大家寫的時候也不需要長篇大論,這樣的文檔是不歡迎的,受歡迎的文檔只需寫出用例分析,表設計,複雜的邏輯需要畫出流程序列圖。
結對編程。之前這個編程模式被無數人調侃過,其實也不可能讓每一個項目全程都是兩個人結對編程。這個不現實也浪費資源。我們的結對是在大家開發一個難點模塊時,會給結對的人增加一項任務去配合其他開發一起完成這個任務。其實我們在開發時,很多時候都會結對,比如指導新同事、討論設計模塊,而之前這些都沒有算在我們的開發工作量裡。
創業公司敏捷開發結對編程
項目演示和總結會議。在項目結束後,讓所有參與項目的成員都參加,一起演示給客戶展示,並解答客戶的問題,充分讓大家感受到收穫的果實。總結會議主要對於這個sprint中大家遇到的問題和經驗分享,並為下一個sprint做準備。
經過敏捷實施後,我們的生產力提高了很多,員工的積極性提高了,業務的參與使整體需求把控也很好,大家溝通多了,30天的任務提前了5天完成。我們多出來的時間,讓大家每週有一天或者半天研究自己感興趣的領域,但是這些研究最終必須體現出成果。比如後台開發想研究一個新技術,最後做完需要寫個ppt給大家分享下。既能讓大家做自己想做的事情,也給大家創造了一個互相學習的氛圍。
ps:所有的模式都不應該是教條的模式,先進的模式並不是好的模式,適合自己的才是最好的。套用一句俗話:不管黑貓白貓抓得住耗子的才是好貓。
| ||||||
紅透半邊天的日劇《半澤直樹》,原作者池井戶潤不但曾任職於銀行七年,現在也還擔任一家中小企業的獨立董事。 用流暢的文筆,結合自己的企業觀察和工作經驗,不但一步一步地達成自己的作家夢,更帶給大家對抗逆境的勇氣。 撰文‧孫蓉萍 「你昨天有沒有看啊?」日本一家大型銀行的員工餐廳,最近每到星期一中午, 大家談論的話題都是「半澤直樹」。這個在泡沫時期進入商業銀行的主角,面對來自內外的種種壓力,總毫無妥協空間地予以反撲,態度強勢卻又心思縝密,搭配那句經典台詞:﹁整我的人,我將十倍奉還!﹂劇情發展總能大快人心。 看到堺雅人飾演的半澤直樹忍辱負重,不惜下跪磕頭換取反擊時間;看到上戶彩扮演的半澤妻子,在銀行員太太的小圈圈中被「高層太太」酸言酸語,再想到自己在職場上也常遭到不平等的待遇,自然會產生共鳴。 台灣十月上映,已引發討論而且不只在日本,這股風潮還吹向台灣,畢竟職場怪象沒有國境之分,因此即使該劇預計十月七日才由緯來日本台引進台灣,卻已在網路上引發許多人瘋狂追逐劇情發展,成為全民共同話題之一。 這齣日劇的原著小說是《我們是泡沫入行組》和《我們是花樣泡沫組》,作者是在日本頗具知名度的作家池井戶潤。出版社文藝春秋宣傳部主管谷村友也指出,這兩本小說的文庫本在七月《半澤直樹》播出前,銷售量加起來是五十萬冊,播出後一個月就增加到接近一二七萬冊,八月底一七○萬冊。 進入八月底,《半澤直樹》劇情進入第二部分,原著小說的銷量隨著收視率繼續攀升,至九月第一周,累積銷量達到二○九萬冊。 「在出版社的定位,這當然是一部企業小說,企業小說的女性讀者一向不多,但這一次,小說銷量暴增,顯然是因為女性讀者的熱烈投入。」谷村友也認為,小說銷量呈倍數成長,多少是受到日劇、尤其是堺雅人之賜。他解讀,現在許多女生也會買書來看,或許,這一次的成功會為池井戶潤,甚至是企業小說,打開全新的讀者群。 池井戶潤的作品以寫實的場景出發,但在人物性格的刻畫上,又因為極度寫實而令人讀來有一種超脫現實的暢快淋漓;這種精準拿捏現實與超現實的功力,在於池井戶潤本來就是一位「既能服從於現實,卻又絕不忘記自己夢想」的人。 銀行工作經驗,化為小說素材池井戶潤從小就愛看書,早在還是小學生的時候,他就把「作家」當成自己的夢想,「一開始,我想寫出『能讓日本人振奮的小說』!但後來又迷上了推理小說。」日本推理小說鼻祖江戶川亂步的書,他幾乎全都讀過,一度以拿到「江戶川亂步賞」為目標,成為一位推理作家。 不過夢想並非一蹴可幾,池井戶潤會判斷情勢,考慮清楚,有戰略性地朝夢想邁進。 進入慶應大學,池井戶潤念的是文學部,但理性的他很快就開始擔心畢業後不好找工作,早早做好打算,念文學是「為夢想」,但還是要為「生計」做些盤算。因此讀完文學部之後,他又讀了兩年法學部。 離開學校,池井戶潤也還不急著圓作家的夢,他很清楚,一個大學畢業生很難馬上就當上小說家,於是選擇進入三菱銀行(現為東京三菱UFJ銀行)工作。在這裡,他開始累積日後寫出《半澤直樹》故事的種種養分。 當時的日本,就業情勢固然不像現在這般險峻,但要進入大銀行,其實也得要擊敗許許多多的對手,場景或許就像《半澤直樹》的第一幕,數百之眾的應試生在銀行大會堂參加面試一般。只是好不容易捧了金飯碗,池井戶潤卻立刻知道自己恐怕不會久待,「因為大家都要一樣,連細節都要照規定辦理,簡直像一所成年人讀的幼兒園。」所幸,他負責的是對中小企業融資,要和各家企業和經營者溝通,也要思考怎麼做才能順利放款,這些需要「花更多腦袋研究調查」的工作,都能讓他暫時忘卻大組織僵硬死板的制度;而解讀企業財務報表,抽絲剝繭,更可以滿足他「推理」的樂趣,於是這份工作做了七年才辭職。 日本媒體解讀,池井戶潤筆下的故事之所以能夠獲得廣大群眾的共鳴,最主要原因是他本身就有銀行工作的經驗,而且是負責對企業放款,在處理對企業放款的交涉過程中,對於銀行端和企業端的運作,甚至於人性,都有極度透徹的觀察與洞悉。 職場真實寫照,引發讀者共鳴事實上,直到現在,他還是東京都大田區中小企業日邦工業公司的獨立董事,對於金融相關的實務仍不陌生也未脫節。 在銀行工作時,池井戶潤看過很多公司成功和失敗的例子,深知控制成本的重要。因此在離開銀行決定獨立創業時,他不敢花錢租辦公室或雇用員工,而是把自家的一個房間當作辦公室,成立一家為客戶建立資料庫的公司。但因為是一人公司,一開始,「我甚至一天要工作二十四小時。」不過,腦筋靈活的他很快就找到了比較不費力、又能結合興趣和專長的賺錢法,就是寫金融實務書。 找出自己的競爭力,是事業成功的關鍵。「我的優勢是放款知識比別人豐富,而且我又很會寫文章,結合這兩點,我就寫了簡單說明借錢法的書。」池井戶潤「靠書出名」,一開始並非是寫小說,而是撰寫「教中小企業如何與銀行打交道」這種「非文學類」的書籍;大約兩年之內,他寫了五本有關「借錢法」的書,銷量不俗。此外,他也常常以專家達人之姿,應邀到各處演講、提供諮詢服務,事業步上軌道。 一路以理性腦袋應付生活,但是小時候當推理小說作家的夢想,卻從未消失。辭去銀行工作一年後,池井戶潤以銀行為故事的舞台,創作了長篇小說,可惜未能獲得江戶川亂步賞評審的青睞,隔年(一九九八年)再以當年擔任銀行員時和往來企業相處的經驗,完成《無底深淵》一書,終於讓他如願以償。 池井戶潤因為這本得獎的「銀行推理小說」,建立了「企業小說家」的地位,但是銀行或企業故事對一些人來說,有閱讀門檻,如何將企業發生的事融入小說當中,正好考驗他的功力。 池井戶潤在寫小說時,重視三件事:第一是新意,第二是原創,第三是豐富。他認為要當一個作家,不是悶著頭拚命創作就好,而是要大量閱讀,看別人的作品,才知道自己寫的內容有沒有新意。他會選擇以銀行為故事背景的推理小說,原因也在於此,畢竟對於銀行或金融產業的事,他無疑已經「大量閱讀」了。 夢想現實之間,獲得完美平衡至於原創,像他描述銀行相關的推理小說,別人難以模仿,而且為了有真實感,他很認真地擔任獨立董事,不是只掛名而已,藉此更了解社會脈動。故事的豐富性,則來自日常的思考和觀察,秉持著小說必須「有趣」的原則,希望讀者「有興奮的讀書體驗」。《日本經濟新聞》報導,池井戶潤希望讀者看完他的小說,「就像看完電影《法櫃奇兵》一樣,高昂的情緒久久揮之不去。」這三件事的精采濃縮,正是《半澤直樹》大成功的關鍵;就像《日經娛樂》雜誌的分析指出,池井戶潤這部作品有三大魅力:第一是故事給人暢快感,一個小銀行員和巨大的權力及組織正面對決,任何人看了都覺得很痛快;第二是沒有花瓶的角色,真男人的奮鬥故事,反而更能打動女性讀者;第三是避免只有內行人才懂的艱澀用語,像劇中的一顆小螺絲,身邊有的小東西更有人情味。 三大元素薈萃,創造了精采的《半澤直樹》;而池井戶潤的成功,其實也是現實與夢想的完美結合:他為了夢想而必須走在現實的軌道上,而現實,不也十倍奉還給他完成夢想的最強養分嗎? 池井戶潤 1963年 生於日本岐阜縣1988年 慶應大學畢業,進入前三菱銀行1995年 辭職,擔任金融顧問並且寫書1998年 以《無底深淵》獲得江戶川亂步賞2010年 以《鐵之骨》獲得吉川英治文學新人賞2011年 以《下町火箭》獲得直木賞 |
筆者寫給i黑馬的這篇文章不會用諸如「阿里發力移動音樂」、「阿里加速移動端佈局」等內容作為主題——換個角度,天天動聽背後的一家VC,以及阿里之外的另一家公司的行動,比前面那些「高大上」的標題更有故事性。
「一家VC」叫聯創策源,「另一家公司」則是俞永福的UC,兩者圍繞天天動聽這家新興公司的故事,總計有3個關鍵節點。
第一個節點是2008年,那時中國智能手機的主力機型還是塞班,黃曉傑(天天動聽CEO)與另外兩個合夥人一起開發了一款移動音樂播放器,在市場上獲得了不錯的口碑。但這完全是一個草台班子,UC找到這個團隊時,他們甚至連公司都沒有註冊,所有人都是兼職身份。當時,俞永福承諾投資天天動聽並注入UC瀏覽器的流量進行推廣,條件是黃曉傑等人必須正式註冊成立公司,以全職身份去運營這個產品。
實際上,黃曉傑的團隊同時也曾嘗試接觸過聯創策源等VC獲取投資,據筆者曾在其中就職的線人透露,當時策源內部的幾個合夥人看到這個案子時,都表示「看不出前景在哪裡」,隨即放棄了投資機會。
第二個節點出現的契機是國內安卓智能手機市場開始爆發。策源等風投機構開始大幅度轉向這個市場。天天動聽的天使投資者UC本身是國內最早向安卓平台轉型的移動互聯網企業之一,連帶效應下,天天動聽也很自然地立即著手研發該平台產品。很顯然,這一著賭對了,再加上UC瀏覽器不遺餘力地導入大流量,天天動聽順利躋身國內頂尖手機音樂播放器之列。
浮出水面之後,黃曉傑的團隊終於開始受到風投界的熱烈關注,不斷有機構洽談期望進入。當時最積極的兩家,一是聯創策源,二是最近兩年由於跟投雷軍系出名的晨興創投。尤其是策源,態度與上個節點時完全不同,甚至同時向黃曉傑和俞永福(策源也是UC的投資人)兩邊「施壓」,要求進入天天動聽的該輪融資。
但是最後,天天動聽還是選擇了晨興作為自己新的投資方。策源一方再次錯失投資的機會,內部對於這次的結果非常不滿,但也無濟於事了。
第三個節點就是阿里的進入了。2013年初,阿里巴巴明確了收購天天動聽的意向,UC一方經過權衡,決定退出,逐步將手中股份轉讓給阿里。根據線人的匯報,「公司估值增加50餘倍是沒什麼問題的」。再加上2億的用戶量,天天動聽完成這些只用了5年時間。
這讓我想起了前幾天流傳甚廣的一篇文章,裡面提到:互聯網江湖裡,很多時候VC是缺失的。
「現在創業者最想拿的是來自企業的投資(CVC)。」一位風投人士也向筆者感嘆,以高估值退出為導向的投資,和以業務協作為導向的投資,從性質上就是根本不同的。「企業的戰略資源除了能帶來錢,更重要的是能給資源,比如UC這種有流量入口的公司,之前投的ES文件管理、安全管家,再加上這次的天天動聽,業務都是迅速成長。風投有多大幾率能做到?」(一名i黑馬作者的投稿)
我的第一個眾籌項目就出了岔子。一開始,我們為這款使用超級電容供電的藍牙音箱產品擬定了共8000美元的納稅成本和間接成本,但在距籌款結束還有兩天,目標進度達到了97%的情況下,我卻把成本是多少這件事完全忘了。這件事給我的教訓就是下次啟動眾籌前,我一定會把額外成本做成超大海報掛在我視線所及的地方。
下面來說說這個失誤。
我們90%的規劃都是非常現實的。一個簡單保守的模式能保證一旦事情順利進行,我們不但能收回成本,還能獲取一些利潤。於是我開始想像如果規模達到現在的兩倍甚至十倍是什麼一種情況。而我們的失敗之處就在於忽視了眼前明確的目標而好高騖遠,這是這次眾籌中最大的失誤。我們的目標只有一個,除了達成這個目標,其他都是鏡花水月。
如果你搞清楚了成功是什麼,那麼可以說你的眾籌項目就成功了一半。因此,問題的關鍵在於在明確了目的之後如何進行計劃。
首先,你需要檢視市場情況。4 First Names有一套非常不錯的開源數據可視化工具,能夠讓你直觀地觀察潛在市場的全貌。Kickstarter的數據在這套工具下以漂亮的3D圖表呈現,他們統計了所有的Kickstarter的項目,圖表中的每個點都代表一個項目,圖中明亮的對角線則意味著項目往往都會達成籌款目標。
可視化效果很酷,而更炫的就是它抓取了網站上每個項目的數據。在著手準備之前,我們使用過濾將上述項目縮減成「籌集超過2000美元」的「產品設計」類,得到了2085個結果。我們相當確信的是,我們能在第一天得到來自朋友和家人的2000美元贊助,如果連這一點都無法達成,後面的路也不會好走。
在這份類似產品的名單中,我們使用了簡單的統計學技術來計算我們的資金目標。我們發現,籌款目標在2.5萬到3.5萬美元之間的項目最後有45%都達到了目標,而3.6萬到5萬的目標區間裡只有35%的項目成功。更具體的是,有關音頻的項目中,超過3萬美元的項目最後達成籌款目標的只佔了21%。
考慮到這款產品的定位和媒體爆光度,我們確定了3萬美元的目標,我們認為自己的產品對消費者還是有吸引力的。
目標確定了,接下來就是制定價格。我們使用Facebook與SurveyMonkey進行了一個簡單調查,這一項的花費是20美元。但是下一次我可能會直接使用SurveyMonkey的付費調查而不是Facebook廣告,因為前者能得到更準確的樣本。
我們的調查採用了Van Westendorp價格敏感性分析法:為潛在的客戶展示產品,並讓他們按以下順序給出四個心理價格:
1. 太貴了
2. 太便宜了
3. 有點貴
4. 比較合理
將調查結果繪製成圖表,你得到了一組四條曲線,它告訴我們有多少人不願意購買這款產品,又有多少人對它感興趣。
結果和我們最初猜測的300美元非常相近。那的確是一個合適的定價,因為一旦繼續增加50美元,潛在客戶數量就會減少30%。
調查結果讓我們明確了產品需求曲線的斜率,但沒有參考點。所以我們將12個相關的音頻類眾籌項目放在一起做出了這張圖表,以便瞭解價格區間和相應的支持者的關係。加上此前預計的銷售量,剩下的就是在連續的價格和目標範圍內確定最終的定價了,這最後的定價決定基於我對這款產品長遠的打算。
現在,我們有了統計學上合理的籌資目標以及零售價,以及最可能的銷售量。這款產品的間接成本和單位成本,包括物流費用和8%的分成(3%的刷卡費和5%的網站提成)。於是我們基於這些計算又建立了一個簡單的模型,並依此調整了定價和目標。
在這裡我犯了一個大錯。
我當時的想法是讓定價隨著籌款的進行逐漸提高,而且我現在還認為這是個好主意,雖然這次搞砸了。定價不但要讓消費者相信他們購買的產品值那個價錢,也要表現出一種過了這村沒這店的緊張感。
一開始,我們設置了25個「早起的鳥兒」名額(最優惠的價格/最早發貨),這些名額在第6天全部被認購,這和我想像中的情況差不多,可以說是相當不錯。但當價格隨著第二階段的到來增加了50美元時,無人問津的情況發生了。
問題的原因出在我的胡蘿蔔加大棒定價模式。最初50美元的折扣(胡蘿蔔)對消費者來說確實是個不小的吸引力,但它反過來也對後來的購買者產生了強烈的反作用。如果需求足夠高,第二階段(100個)的銷售順利,也許就不會有這樣的問題。但事實恰恰相反,第二階段的銷售數字並沒有增長,反而暗示人們沒必要立即下單,畢竟還剩97個。
在籌款即將面臨失敗的時候,我們在第16天突然得到了一大筆現金投資。於是我們又增加了「早起的鳥兒」的名額。請務必注意,如果你打算做分級定價,一定要確保每個階段之間的差額足夠小!我認為設立一個名義上的「零售價」會促進於中間階段的銷售,但這個度一定要把握好。
從現在來看,其實最難的是網站流量的計劃。我最初以為,只要達到10000點擊率就能達到目標,而結果卻需要接近20000才行。目前的轉換率在0.5%左右,大多數的轉換來自於Facebook和直接訪問的流量,來自我們自己的Facebook專頁的幾乎沒有。
獲得媒體曝光也是一個嚴峻的挑戰。為此我們製造了一些試用機寄給各大媒體(我們也不可能直接要求他們進行報導)。這樣的項目成為「新聞」的時間點只有上線第一天,達成目標的那天以及結束前幾天,上述的時間段一定要把握住。在其他時間,我認為你必須找到產生流量的替代方案。
媒體對我們產品的報導還算不少,大約有30篇文章,但平均下來每篇只能帶來很小的訪問量和銷售量。我很驚訝地發現一些報導的轉化率非常低:比如Digital Trends上的這篇文章得到了650個贊,但同時我們的CrowdSupply頁面只有350個贊。
更幸運的是,我們再一次獲得了一大筆投資,如果沒有它,這個項目早在幾個星期前就無法進行下去了。如果能夠再來一次的話,我肯定不會開放國際購買了(美國以外的支持者實際上非常少),不但能省下一筆錢,還能在定價上有更大的調整空間。
除此之外,這個項目還讓我成為了一名臨時的全職互聯網營銷,實際上我只是想把產品造出來,但是我不知道除了眾籌還有什麼別的方式能籌集到資金。所以無論如何,這也是一個勝利(假設你讀這篇文章的時候已經達成了目標)。
| ||||||
認識Samuel時,他告訴我他看好生技業,未來要投資六百億元,當時我聽完哈哈大笑。但幾年下來,我已經不懷疑他說的話了。 我與Samuel(潤泰集團總裁尹衍樑英文名字)認識,是透過中研院院長翁啟惠介紹的,我們一見如故。後來,因為我在美國生技界有幾次成功經驗,他有什麼案子都會請我看,我也幫忙出些意見,結果,最早期他投資生技業,每投必敗,我幫他出意見後,每戰必勝,真的差很多。認識Samuel時,他告訴我他看好生技業,未來總共要投資六百億元,當時我聽完後哈哈大笑,但這幾年下來,看他每次出手金額愈來愈大,我已經不懷疑他說的話了。 去年,美國Optimer製藥公司與台灣浩鼎發生了爭議,我被Optimer董事會以莫須有的罪名,除去兩家公司董事長的職務,雖然我在美國待了四十年,已看太多這種商場上為了利益翻臉不認人的事,但仍不齒這種行為,這是惡意誣告。Samuel也很氣憤地想幫我,請來大律師曾達夢接董事長,並聯合國內股東與Optimer攤牌,最後以每股一美元,買下Optimer手中的台灣浩鼎四三%股權。 Samuel對員工非常慷慨,我後來知道,當時潤泰集團買了四三%的浩鼎股權,大約六萬多張股票,但他拿出一萬張給主管認購,把利潤分享給員工,目前浩鼎股價漲到二五○元,潛在獲利超過二十幾億元,這是不算小的利益吔! Samuel很講義氣,對創業者的支持也不遺餘力。他曾在美國投資一家生技公司,挺了七、八年,其他股東都退了,只剩他一個人,其間也曾請我去看,我提供了很多建議,但該講的都講了,創業團隊不聽,我也沒辦法,當時匯率還是三十三比一,最後Samuel賠了七、八億元。但更可愛的是,現在這位創業者還在潤泰工作,你看Samuel是多有肚量的老闆啊! 我和Samuel在生技業有許多共同想法,我們都覺得社會責任很重要,像他已把自己的財富裸捐了,還出錢成立唐獎,要做到像諾貝爾獎這種世界級規格。 同時,我們也都認為,醫學進步的目的是要造福人群,因此浩鼎的乳癌新藥若研發成功,不僅有錢人可以得救,也要讓弱勢族群能夠享受到新藥研發的成果。此外,我們也都覺得,如果是一個好藥,風險高低沒關係,我們願意去挑戰。像Optimer的抗生素藥,就撥出一七%免費送給弱勢族群,讓沒錢的病人也能接受治療。這種作法在美國並非特例,但在台灣目前還未發生過,因為股東可能會覺得犧牲了他們的權益。Samuel說,屆時他會用基金會付錢的方式送給窮人,不影響股東權益,但就是要讓窮人都能獲得醫治。 我常與Samuel一起去花蓮、宜蘭騎腳踏車,或到東南亞去潛水,我們不僅在商業上是好朋友,私底下也有很多事可以聊。Samuel的責任感與企圖心很強,在綠能產業及醫療的社會責任上,他還有更大的夢想等著實現,這些夢想若公布,一定會讓世界都很驚訝,大家可以等著看! (口述.台灣浩鼎生技董事長張念慈 整理.林宏文) |