逃逸速度:初創(chuàng)企業(yè)如何走出失敗的泥沼

0 評(píng)論 12361 瀏覽 1 收藏 12 分鐘

導(dǎo)讀:對(duì)于一個(gè)初創(chuàng)企業(yè)來說,有什么比速度更珍貴的呢?Sam Altman如是說:“快速推進(jìn)。速度是你逃離巨大競(jìng)爭(zhēng)吸力的最主要的方法”。 而Eric Ries所提出的當(dāng)前炙手可熱的“精益創(chuàng)業(yè)”理念大部分說得也就是速度的問題。那么對(duì)于一個(gè)初創(chuàng)企業(yè)來說,速度最大化以避免你的企業(yè)墜毀得灰飛煙滅尸骨無全究竟意味著什么呢?下面我們就好好分析分析!

物理學(xué)上有個(gè)術(shù)語叫“逃逸速度”,指的就是一個(gè)物體如果要逃離萬有引力的約束所要達(dá)到的速度。一個(gè)火箭上升的初始速度如果能達(dá)到11.2km/s以上的話就能夠沖出地球走向宇宙一去不復(fù)還。如果低于這個(gè)速度的話,那對(duì)不起,你將需要消耗更多的燃料慢慢的推動(dòng)著火箭往上升,最終的結(jié)果可能就是上演一出真實(shí)版的“重返地球”最終墜毀化作一團(tuán)火球,只是電影《重返地球》中人家是從外太空來回到地球,而你卻從來沒有離開過地球。

對(duì)于一個(gè)初創(chuàng)企業(yè)來說,有什么比速度更珍貴的呢?Sam Altman(注:YC董事長(zhǎng),”硅谷創(chuàng)業(yè)教父“Paul Graham的接班人)如是說:“快速推進(jìn)。速度是你逃離巨大競(jìng)爭(zhēng)吸力的最主要的方法”。 而Eric Ries所提出的當(dāng)前炙手可熱的“精益創(chuàng)業(yè)”理念大部分說得也就是速度的問題。那么對(duì)于一個(gè)初創(chuàng)企業(yè)來說,速度最大化以避免你的企業(yè)墜毀的灰飛煙滅究竟意味著什么呢?下面我們就好好分析分析!

初創(chuàng)企業(yè)發(fā)展速度模型

初創(chuàng)企業(yè)跟火箭一樣都是按著一個(gè)速度往前推進(jìn)的。在物理學(xué)中速度指的是在某個(gè)時(shí)間內(nèi)推進(jìn)的距離。而對(duì)于初創(chuàng)企業(yè)來說,速度意味著企業(yè)發(fā)展的進(jìn)度(上圖右上的Progress)除以所需的時(shí)間(上圖右下的Time)。假設(shè)一個(gè)初創(chuàng)企業(yè)所需要投入的資源成本就是時(shí)間,進(jìn)度就等同于獲取到的商業(yè)價(jià)值,那么替換到以上的公式就得出了你的ROI(投資回報(bào)率)!

作為一個(gè)初創(chuàng)公司來說,你將會(huì)面臨很多的不確定性。你很難去預(yù)測(cè)你下一次迭代的功能點(diǎn)收效如何。你的預(yù)測(cè)結(jié)果也許會(huì)命中,但大部分情況下往往結(jié)果會(huì)是錯(cuò)的。你所能做的事情就是去快速投放市場(chǎng)驗(yàn)證然后觀察效果??偟膩碚f,初創(chuàng)企業(yè)在每次迭代時(shí)所取得的進(jìn)展平均起來都是很小的,因?yàn)樵?0個(gè)功能點(diǎn)快速驗(yàn)證當(dāng)中,你如果有幾個(gè)效果是很成功的話已經(jīng)是非常阿彌陀佛的了。

為了在我們的初創(chuàng)企業(yè)速度模型中更好的描述這些令人擔(dān)憂的因素,讓我們把迭代進(jìn)度進(jìn)一步細(xì)化成“預(yù)期功效“(下圖右上的Expected Win)和“成功機(jī)率”(下圖右上的Success Chance)。在下圖中你就能看到每次迭代中低迷的”成功機(jī)率“會(huì)大大的拖住每個(gè)初創(chuàng)企業(yè)的發(fā)展速度。這我們總不能坐視不管啊。

好消息是在上面的迭代效率模型的底部你還有個(gè)叫做時(shí)間(Time)的東西讓你扳回一城。你將需要竭盡所能的在每次迭代中用盡量短的時(shí)間將功能推出市場(chǎng)進(jìn)行快速驗(yàn)證。同時(shí),迭代時(shí)間又可以細(xì)分成以下兩個(gè)主要部分:

  • 開發(fā)時(shí)間:所有直接對(duì)產(chǎn)出做出貢獻(xiàn)的活動(dòng)—?編碼,設(shè)計(jì),測(cè)試,以及部署速度
  • 間接消耗時(shí)間:研究,討論,頭腦風(fēng)暴,計(jì)劃,等等

最終得出的細(xì)分的迭代效率模型圖如下:

從中可以看到,如果能把開發(fā)時(shí)間(上圖右下的Development Time)和所有間接消耗時(shí)間(上圖右下的Overheads Time)拉下來的話,你就能大幅度的提升你的初創(chuàng)企業(yè)的迭代速度。如果僅僅測(cè)試一個(gè)小改動(dòng)你就需要花費(fèi)幾個(gè)小時(shí)的測(cè)試時(shí)間的話,那么,兄弟,這意味著你的產(chǎn)品開發(fā)正面臨著一些嚴(yán)重的問題,是時(shí)候開始做點(diǎn)事情了。同理,在你費(fèi)盡口舌耗費(fèi)幾個(gè)小時(shí)來說服你的小伙伴們來認(rèn)同你的觀點(diǎn)期間,你其實(shí)已經(jīng)可以將它實(shí)現(xiàn)出來并開始進(jìn)行測(cè)試了。少說,多做!

那么我們可以做些什么事情來加快我們每次迭代的進(jìn)度呢?答案是肯定的,建議如下:

  • 從潛在價(jià)值高的功能入手 — 首要的就是要關(guān)注在那些你在短期內(nèi)可以實(shí)現(xiàn)的給你的產(chǎn)品帶來重大改觀的那些功能點(diǎn)上面。
  • 好好對(duì)你的上一次迭代進(jìn)行研究分析,以便更精準(zhǔn)高效的對(duì)這次迭代的預(yù)期效果做出評(píng)估以提高成功率。
  • 對(duì)大功能點(diǎn)要抱著如履薄冰的態(tài)度 — 雖然大的功能點(diǎn)往往會(huì)帶來可觀的贏面(這樣說吧,我現(xiàn)在做個(gè)產(chǎn)品,有個(gè)功能點(diǎn)叫做QQ。這功能點(diǎn)贏面夠可觀吧?但你不把它細(xì)化的話,你根本就會(huì)找不著北該如何入手去做,只能東搞西搞的把投資人的金錢燒得無影無蹤而已),但它們同時(shí)也會(huì)充滿風(fēng)險(xiǎn)和消耗時(shí)間(基本上,大功能點(diǎn)會(huì)拖你后腿讓你行動(dòng)緩慢)

好的,理論分析完了,完整的初創(chuàng)企業(yè)速度模型和迭代效率模型我們都有了,那么是時(shí)間來找個(gè)麻雀來解剖下了。

案例分析

不久之前我正好給一個(gè)面臨著開發(fā)時(shí)間嚴(yán)重挑戰(zhàn)的初創(chuàng)企業(yè)進(jìn)行指導(dǎo)。他們的組成成員其實(shí)都是一級(jí)棒的,非常有天分。其實(shí)他們都非常想做出點(diǎn)改變,但是事實(shí)上又對(duì)他們的產(chǎn)品開發(fā)進(jìn)程裹足不前這種狀態(tài)束手無策。開發(fā)和部署一個(gè)小功能往往都會(huì)耗掉大家超過一個(gè)星期的時(shí)間。很多不錯(cuò)的功能點(diǎn)一直都只能在他們的Product Backlog(Scrum術(shù)語:產(chǎn)品清單)或者Sprint Backlog(Scrum術(shù)語: 沖刺清單)中長(zhǎng)眠不醒無人觸碰。大伙慢慢變得意志消沉備受打擊但又無可奈何。

為了解決這個(gè)問題他們也嘗試過想出一個(gè)這樣的解決方案來:根據(jù)商業(yè)價(jià)值和實(shí)現(xiàn)技術(shù)復(fù)雜度來對(duì)每個(gè)功能點(diǎn)進(jìn)行評(píng)估(其實(shí)和我們上面的迭代效率模型已經(jīng)很接近了,只是他們沒有把風(fēng)險(xiǎn)/成功機(jī)率給考慮進(jìn)去)。他們希望對(duì)每個(gè)功能點(diǎn)都做詳盡的分析以便更精確的把握這些功能點(diǎn)的潛在回報(bào)率,然后再從中挑選一些出來進(jìn)行迭代實(shí)現(xiàn)(可以想象這樣的流程在一個(gè)迭代中將消耗大量的間接時(shí)間)。

為什么他們得做法不奏效呢?

  1. 后來的方案沒有把大功能點(diǎn)的潛在風(fēng)險(xiǎn)考慮進(jìn)去。這就導(dǎo)致了他們高估了(擁有最高風(fēng)險(xiǎn)的)大功能點(diǎn)所帶來的價(jià)值,而反過來又低估了小功能點(diǎn)優(yōu)化所帶來的價(jià)值。
  2. 最開始方案的過長(zhǎng)的開發(fā)和部署時(shí)間的消耗導(dǎo)致了大量的優(yōu)秀功能點(diǎn)沒有辦法在迭代中完成,時(shí)間不夠。
  3. 后來的方案中對(duì)每個(gè)功能點(diǎn)進(jìn)行額外分析所帶來的間接時(shí)間消耗就讓上面模型方程式中的分子變得越加龐大,分子變大了,結(jié)果當(dāng)然是等式左邊的迭代效率下降了。

所以,該方案一開始就走錯(cuò)了方向,因?yàn)闆]有把問題定位到過慢的開發(fā)時(shí)間上面來。通過限制從Product Backlog中取出的功能點(diǎn)數(shù)量,并要求對(duì)每個(gè)功能點(diǎn)投入額外的調(diào)研時(shí)間來確定哪些功能點(diǎn)需要放進(jìn)當(dāng)前的Sprint Backlog上面,這只會(huì)大大的拖住你的初創(chuàng)企業(yè)往前邁進(jìn)的后腿。其實(shí)他們更應(yīng)該關(guān)注的是去降低開發(fā)部署時(shí)間以及其他間接消耗時(shí)間(包括那些額外的調(diào)研),以確保盡量多的功能點(diǎn)能得到盡快實(shí)現(xiàn)并投入市場(chǎng)進(jìn)行驗(yàn)證。

結(jié)論

以下各點(diǎn)就是從初創(chuàng)企業(yè)速度模型提煉出來精髓:

  1. 在產(chǎn)品開發(fā)期間把目標(biāo)瞄準(zhǔn)那些具備可操作性的優(yōu)秀功能點(diǎn)上—把功能點(diǎn)的實(shí)現(xiàn)并推向市場(chǎng)的時(shí)間最小化。把你的開發(fā)周期壓縮到以小時(shí)為單位,而不是以多少周來衡量。交付MVPs(最小可行產(chǎn)品)而非大而全的產(chǎn)品。
  2. 別妄想你能準(zhǔn)確預(yù)測(cè)用戶對(duì)功能點(diǎn)的接受效果。離開你舒服的椅子,走出你的辦公大樓去尋找真正的用戶進(jìn)行驗(yàn)證。別害怕失敗。只要你能從中學(xué)習(xí),別在同一個(gè)位置上栽兩次跟斗就行了。
  3. 別把好的功能點(diǎn)都放在你的Product Backlog中睡懶覺,確保你有足夠的“帶寬”來處理那些最“有前途”的功能點(diǎn)。
  4. 別讓上面說的那些“間接消耗時(shí)間”拖了你的后腿。避免那些過長(zhǎng)的無謂討論或所謂的長(zhǎng)期計(jì)劃??焖俚答伈攀峭醯?。
  5. 盡量把大功能點(diǎn)細(xì)化成小的步驟來付諸實(shí)現(xiàn)和驗(yàn)證。耗時(shí)的大功能點(diǎn)只會(huì)讓你舉步維艱。

英文文章參考:https://medium.com/@skalskiw/the-physics-of-startups-startup-speed-model-b014fab7deec

#專欄作家#

朱佰添,網(wǎng)名:天地會(huì)珠海分舵,微信公眾號(hào):techgogogo。人人都是產(chǎn)品經(jīng)理專欄作家兼高級(jí)翻譯官。9年軟件行業(yè)從業(yè)經(jīng)驗(yàn),涉獵海外最新創(chuàng)業(yè)、融資、產(chǎn)品類的資訊和方法論,喜愛結(jié)交各行各業(yè)的朋友,歡迎聯(lián)系。

本文系作者授權(quán)發(fā)布,未經(jīng)許可,不得轉(zhuǎn)載。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 目前還沒評(píng)論,等你發(fā)揮!