什么是組織增長官?
前段時間增長黑客很火,眼前耳邊總是時不時的冒出來,當我看到它時,我腦海里一閃而過的是另一概念:組織增長官。下面我想聊聊這個話題,純屬個人見解~
一個組織通過產品傳達他們對客戶/用戶的主張,這個“產品”是組織和客戶/用戶之間的媒介和載體。團隊在設計用戶/客戶在產品上的體驗旅程,我們把它稱之為業務流,這是直接面向我們的用戶/客戶的部分。
而產品的背后是團隊,這個背后的團隊組織如何運作,各部門間有序協同的部分,我們把它稱之為工作流。而我想聊的組織增長官是針對工作流而言,如何讓團隊緊盯目標的前提下相互協作順起來,工作更高效。
簡單的說也就是:方向指對,快速推進。第一層是先理順,第二層是讓其更高效。
現實工作中你會發現哪里像我們上面說的這幾個字這么簡單輕松,因為這個事一般針對已經具備一定規模和復雜度的團隊組織,接下來會嘗試通過舉栗子來更接地氣的讓大家了解組織增長官的范疇和可能的維度。
Case1:我們有一個新的想法想去嘗試和驗證,我們下一步該怎么做?
比如:我們想在某一塊做些創新和嘗試,現在就我一個有想法的光桿司令怎么辦?當然先確認方向是否對,或者符合我們的大目標。被認可和確定可以往下推進后,我們來分析你需要的最小作戰隊和MVP,然后各個角色間怎么配合,制定計劃以及如何行動和驗證成果等。
這里其實說到兩個方面:
(1)設計模式,就是這件事情怎么跑
我簡單的分為以下三步:
- 組建所需作戰隊:之所以加上‘所需’兩個字,原因是有很多新的嘗試和創新未必像我們想的需要重投入,實際分析后可能會發現,或許這個idea只需要投入2-3個人成立前向攻堅隊(不需要把東西先做出來,先去問客戶、包裝方案、做探索和反饋),或者是需要做個簡單原型的5-6人執行團隊。
- MVP(Minimum Viable Product最簡化可實行產品):這個產品經理都熟知的快速驗證方式,我們需要分析和確認要驗證這個創新和嘗試,需要做的最小最簡化內容是什么,以便于我們快速實現和驗證它。
- 運行機制。
(2)制定運行機制
為什么又單獨把它拿出來了,因為對于組織增長官來說,這是重點,如果說方向、目標是what,那么如何運轉和推進就是how的部分,是組織增長官的重點。各個角色間如何協作,設計流程(一環到一環,準入、準出標準等)。
這個Case中當我們確定了一個目標,接下來組織增長官要推動事情的發展,就是把他分解成如何去做:設計模式就是這個創新和嘗試想法目標怎么跑,誰以及最小可執行產品范圍是什么,然后制定運行機制各個角色間如何配合以及如何驗證和反饋。
Case2:總覺得慢,但說不出哪里出了問題
工作中這種現象經常出現,大家都很忙,而且都忙成狗了,可是為什么總覺得還是慢呢(結果、成果)?
其實這里有個很要命的東西就是透明和呈現,我們要在錯綜復雜的現實中去理,讓情況呈現透明出來,而且讓大家一起看見。
我以研發過程為例(其實這個現象發生在各個階段,我是項目經理就以最熟悉的研發過程為例),開發和測試每天處理手頭的工作已經工作12小時了,可是結果還覺得慢、不盡人意。你具體去深入了解,可能會發現一個開發一天手頭有3、4個并行的項目在處理,不停的切換還不停的被打擾,為什么會這樣?!
還有可能一些任務的等待時間已經遠遠超過做他的時間,等待其實就是浪費。這讓我想起經典的Pizza游戲,在交付時如果有過程材料都算浪費需要扣分,現實生活中也是如此,市場瞬息萬變,沒有形成客戶真正可用的產品,中間的過程物就是浪費。
換一個角度,如果迭代的周期夠短你會發現有些需求永遠排不上,而在現實工作中每個版本都存在著偽高優先級需求,甚至可能是半成品的狀態存在著。
因為本文不是一個案例分析文章,是想通過舉栗現象和問題,讓大家了解組織增長官的范疇,所以這里不具體展開出現這些情況的原因和如何解題。
這個Case里想表達的是團隊里會出現各種各樣的現象和情況,這也是組織增長官的范疇,當遇到這些情況時組織增長官要做的提煉下是兩點:
- 透明和呈現。把情況呈現出來,讓團隊看見問題,往往現實是大家都忙于腳下,忘記抬頭。
- 發現問題,確定問題,自然而然接下來解決問題。
另外,組織中每一個階段環節都會有問題,需要立體的看問題,橫軸是職能線,縱軸是項目線。我們需要去看當下最重要緊急的問題在那里,然后解決它。當然組織是系統的,當出現一些問題時我們需要用系統性思維的方式去分析和思考問題。
這里讓我想起曾上過呂毅老師的系統思考課的確收益匪淺,其實是讓大家用系統思考的方式尋找里面的因素、變量,正循環負循環,然后分析和確定你要解決的問題和切入點。
以上是筆者理解的組織增長官,在這個過程中他會通過設計模式(這件事情怎么跑)、制定運轉機制(人/團隊協作流程),發現和定位問題(團隊前進的絆腳石),然后去解決問題,對于組織增長官有一個前提和一個核心。
- 一個前提:針對工作流。
- 一個核心:緊盯目標,快速推進。
說到這,我們再回到一個本來應該在開頭就問的問題:為什么會有組織增長官這個概念?
按理來說各部門各角色各司其職應該能夠順利完成工作,而現實很骨感。各角色在自己的邊界范圍內忙碌沖刺著,很少或偶爾抬起頭看看對面。亦或者我們發現了問題,但還是存在屁股決定腦袋的立場問題,有個從第三視角看問題的人強有力的協助推進和解決它是企業需要的,亦或是他們是真正關心和負責快速高效達成組織目標的人。
除了為什么會有組織增長官這個問題外,可能還有疑問,如何確認或者量化它的效果?
在開頭我們也提到它的第一層是先理順然后是讓其更高效,對于第一層先理順團隊一般不會有太大疑問,因為這類情況一般是目前有問題而且是有人有痛點的,幫忙推進理順之后可能就已達到他們的初衷和效果了。
往往是第二層使其高效,這類情況可能不是別人的痛點,而是站在組織增長官或者負責人的角度發現并想改進的部分,或者說在一般角色中這類情況或許不會成為他們的痛點,很有可能是你發現而且想辦法去改進然而團隊并不買賬,那么要有對比證明和量化這個前和后的效果就變成是很有需要的了。
所以組織增長官還需要建模,通過建模、收集和分析數據、以及通過做改進來驗證效果。
比如:Case2中筆者舉栗研發階段出現的情況,或許就可以通過需求、質量和進度來構成這個所謂的模型進行量化對比,如果引入一些改進之后發現在固定時間、質量不變的情況下,能產出的需求量變多了等等。而不同階段不同層次范圍的模型會不同,需要結合具體情況展開分析,但組織增長官是需要聚焦目標且能量化的思路去開展工作。
這次筆者想先拋出這個概念,希望在此處有共鳴的朋友一起探討交流。
作者:劉煦萍Abble,網易資深項目經理,專注于流程優化、版本交付和團隊成長。微信公眾號:NetEasePM
本文由 @網易杭研項目管理 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
- 目前還沒評論,等你發揮!