【創業說】5人到50人,創業團隊如何突破發展瓶頸
編者按:【創業說】是36氪為創業者提供的一個欄目,讓創業者可以分享他的創業故事、經驗和觀點。投稿地址:tips#36kr.com。本文來自36氪特約作者、大姨嗎創始人柴可。點這里查看我們之前對大姨嗎的報道。 其實整個創業的過程就像傾倒一瓶金黃色的青島啤酒,從胖胖的酒瓶肚子里,突破那長長瘦瘦的瓶頸,經過漫長的等待,最終噴涌到啤酒杯壁上,濺起厚厚的啤酒沫,直到舉起冰涼的已經結了水霧的啤酒杯一飲而盡的瞬間,才將那漫長的、通過瘦長瓶頸的等待、痛苦和焦慮拋之腦后。我經常這么鼓勵自己,創業就像倒啤酒喝,當鮮美的啤酒在突破了瘦長的瓶頸后,最終那甘美的佳釀就是你的戰利品了。而這個過程中最痛苦,最漫長的,是等待啤酒沖破瓶頸的時候。 最近我也經常調侃說:"隨著大姨嗎用戶量發展成了第一,我們也擁有了國內人數最多的專研女人月經的團隊,50個人每天8小時都在研究月經,那是相當壯觀的景色…"。從創業最早的4個人團隊,慢慢成長為一個50人的團隊,期間遇到的瓶頸和挑戰非常多。比如與用戶共同改進產品、與投資人談判資本回報、與有關部門協調法稅、與員工博弈報酬的多少,當然還有與惡意的抄襲者盜版者爭斗領地。任何新興的創業團隊也和我們一樣,會面臨無數的瓶頸和分歧,而遇到瓶頸時往往先是手足無措,然后….一般會出現下面三種情況: 亂成一團吵架 上級指責下級 同級較真起來的話,結果往往是你走我留,我走你留 其實不管吵架與否,大家都是熱愛這個項目和公司的,問題往往在于遇到瓶頸和分歧的時候,大家很難冷靜下來分析問題的根本在哪里。尤其是隨著創業者年齡越來越小,越來越混搭和跨行業,導致管理方法的缺失。其實很多大公司都有著冗長的管理教條,效率低下,但是問題最終卻可以被正確解決。而許多創業企業雖然腳步輕盈,但是卻因為不懂得如何找到瓶頸的根本,導致發展受限。就像以前帶兵打仗,有的將領可以管好10個人,有的將領就可以管好10萬個人,這里面的管理哲學和方法,其實是需要創業者去不斷學習的,當然之后還要根據自己的情況不斷優化。方法論到最后并不重要,但是不會方法論則萬萬不可,經歷過無數瓶頸的大姨嗎一直使用著一個叫"COPR模式"的簡單模型,輔助我們快速找到公司發展瓶頸的根本,然后解決它。這個方法其實最最重要的就是可以讓人冷靜下來,理智地將吵架和指責的能量轉化為分析能力和生產力,最終解決問題。 先說COPR,是不同類型的瓶頸的縮寫,Capability(能力),Occasion(事件),Process(流程),Regulation(制度): 第一種瓶頸:Capability,能力帶來的瓶頸,這樣瓶頸的成因一般是因為沒有能力去完成某事。比如我就不會編程,如果團隊里也沒有會編程的,我們就自然而然做不了軟件開發。 第二種瓶頸:Occasion,事件帶來的瓶頸,一般是突發事件,意料之外的事情,規劃之外的事情,比如本來做活動談好了的贊助商,忽然跑單了… 第三種瓶頸:Process,流程帶來的瓶頸,這個瓶頸有很多觸發因素,比如公司的開發/生產/服務流程存在缺失或者效率低下的地方,又或許是因為業務拓展新增了需求,導致流程變了。比如以前我們團隊還小的時候每個人都是測試員,上線流程非常簡單,但Bug也相對多一些,但現在加入了專門的測試環節,那么整個大姨嗎開發上線的流程也就應該做出相應的調整。 第四種瓶頸:Regulation,制度帶來的瓶頸,無論是公司制度,還是法律制度,總之是頂層規則性的要求導致的瓶頸,比如以前我們所有的版本發布和更新都會要求必須有CEO簽字,CEO要對產品品質做出把控,但是隨著公司規模擴大,CEO能簽字的時候可能往往會錯過發版的良機(配合市場炒作或者周末的超大流量),那么這個瓶頸就必須改進。 在三年創業的實戰中,我們也總結了解決這些瓶頸的方法框架: 如果發現是Capability能力瓶頸:那么用S解決。Supply補給,Study學習,趣味一點說,S也代表Superman,一個能力無限大的英雄角色,沒錯如果是能力不夠解決不了的問題,最簡單就是找來一個超人!換而言之,如果是能力不足導致的發展瓶頸,要么去找補給(外援團隊、外包服務),要么去自己學習。比如當年我們從web項目轉型移動開發的時候,就要求CTO對移動開發進行了惡補,而同時因為不能耽誤進度,我們還采取了半外包的方法,也就是讓一個外包開發公司的程序員來到我們的辦公場所進行開發,并且讓技術團隊配合他,同時進行學習,很快產品出來了,自己也有了一支移動開發的團隊。 如果是Occasion事件瓶頸:那么用A解決,Action行動,Agility靈活度,趣味地說,A也是24個英文字母中的第一個,代表了速度和優先級。所以遇到突發事件的時候,最主要做的,一定不是哥幾個先坐下來開個小會,而是立刻找到最靈活有效的解決方案,并且立刻行動起來。比如前一段時間大姨嗎因為出現大量盜版、惡意攻擊和嚴重侵權事件,這個時候從法律、市場、公關各方面就必須并行立刻行動起來。事件瓶頸的解決一定要通過可以量化的行動來解決,把執行具體到跑了幾個小時的工作、找幾個關鍵人聊了天等非常細節的層面,在不打亂公司正常運營的節奏和規律的同時,使公司發展盡快回歸正軌。 如果是Process流程瓶頸:用O解決,Optimization優化,Overwrite重寫。同樣,在英文中,O就是一個閉環,流程的通暢也正好代表一個完整的閉環,很好記。流程不光是生產和服務過程中的,也有可能是管理上的,流程瓶頸多是因為增加了新的功能,或者因為某個環節效率低下導致的。這個時候需要大家坐下來,用數據分析流程中出現問題的地方,分析下是否可以通過優化效率、或者調整順序來解決,如果不能,那么就只能打破流程,重新安排流程的組合了。比如以前我們沒有融資也沒有盈利的時候,基本是不考慮為自己的產品打廣告投的,沒錢嘛。但是當公司上了正軌,也就會將一部分利潤作為規律的廣告投放成本,而這個其實直接影響了產品的開發上線流程,新版本的發布可能會需要配合營銷,或者廣告位,于是在產品上線的流程中就會將廣告同樣作為一個參考因素和關鍵點。 如果是Regulation制度瓶頸:用R解決,Restructure重構,Revolution革命,大家可以這樣想象,制度的問題就要靠制度本身解決。所有不合理的制度產生的問題,除非把制度改變了,否則問題都不算得到了根本的解決。所以制度瓶頸要么推翻重來,要么依據現有的結構進行重構。 這個模型中最最重要的是首先學會找到問題瓶頸的根本,到底是能力、事件、流程還是制度瓶頸;其次,學會向下解決問題的方法。所謂向下解決問題就是當遇到瓶頸并且時間很緊的時候,嘗試把COPR反過來,用RPOC的思路解決問題。 遇到Regulation制度瓶頸,實在無法解決了,看看能否用Process流程的方法解決,比如對流程進行調整,規避制度的影響,比如蘋果官方市場是抵制軟件內去推薦其他市場類應用的,那么在上線的時候如果就帶有這個推薦,那肯定無法通過審核,而調整下流程,開放一個后臺更新接口,先將沒有推薦的產品上線,成功后通過后臺更新的方法加上其他合作市場,這樣也就規避了制度。 而當遇到Process流程瓶頸無法解決時,看看能否用Occasion事件的方法解決,流程忽然被打斷或者出現問題,這時候也不應該拖拖拉拉想太久再去做,而是并行地用一些臨時性彌補措施,臨時事件對流程出現問題的環節進行補充。 特別要強調的是,當遇到Occasion事件瓶頸無法解決時,就需要看看Capability能力方法了。有的突發事件很違背常規,可能不在自己的能力可以解決得范圍之內,那么這個時候采用外援,或者突襲學習補充知識的方法是可以及時解決問題的。要理解的是,很多時候Occasion事件瓶頸會讓人非常緊張,因為事件的突發性以及當即性,導致被管理團隊過度重視,甚至臨時性打斷原有公司運作的流程,更有甚者讓所有團隊全部投入到事件的處理中去,結果讓正常的流程被破壞,公司的一片混亂。要提醒創業者的是,中國的互聯網惡意競爭是常態的,很多你的競爭公司其實很善于用事件打亂你的公司運營,為他自己爭取更多時間。其實不用緊張,這正是你的對手產品品質不夠好的表現,中國的許多流氓創業者很擅長的就是"既然我成事不足,那我就敗事有余"這個方法,要理解他是想拖累你的產品,打亂你的流程。所以越是遇到這樣的情況,創業者越要臨危不亂,千萬不能把Occasion事件瓶頸提升到流程層面去解決,正中了對手的下懷。 但是當最后遇到的是Capability能力瓶頸的時候,那么就只能通過能力補充或者外援的方式解決瓶頸了。 很多時候創始人會一味去提升公司的人數,認為是能力不夠,或者人數不夠,其實仔細沉靜下來思考,發現還是有很多閑余戰斗力的,比如好多公司不會迭代開發,非要等到一個產品的成品設計圖完全出來了才開始安排程序員開發,其實前期很多數據庫架構、數據接口、和基礎功能,在設計圖的原型方案出來的時刻就已經可以提前開始了,這樣可以讓設計師并行具體的設計,待底層工作完成了,新的設計圖也就出來了,整個開發周期就可以縮短許多,這種情況其實完全可以通過Process工作流程的優化解決,而不是一味追求通過補充能力Capability去完成。 說了這么多,最后,其實最重要的就是冷靜下來思考瓶頸發生的根本是屬于哪種,而不要在問題的表象上面大做文章,應該去找到瓶頸的根本。本文也只是我們自己在發展中歸納的一些小小的方法論,每次發生問題我們就仔細分析問題的根本,再迅速做出反應。創業團隊要保證的是在不停地解決問題,而不是在等待問題被解決。 圖片來源 除非注明,本站文章均為原創或編譯,轉載請注明: 文章來自 36氪 原文地址:http://iphone.myzaker.com/l.php?l=51ef0d877f52e9c22a00000b 該文章在 2013/7/28 8:35:43 編輯過 |
關鍵字查詢
相關文章
正在查詢... |