Pinterest 和 FanDuel。
在經過了長達三十多個小時的採訪之後，我們弄清了一件事：選擇正確的團隊發展模式不僅利於企業的發展，同時也能強化企業文化。
團隊發展模式
從我們的採訪中可以總結出兩個較為流行的團隊發展模式：
一種是獨立模式，一種是功能模式。如果你想要組建自己的發展團隊，二者都是不錯的著手點。“當遊戲開始時，要按正確的佈局玩兒”(Zack Onisko，CreativeMarket首席發展官)。每種模式都聚焦於“更為深入地瞭解自己團隊的發展模式”(Mike Duboe，Tilt發展官)，然後全力解鎖盈利問題。
獨立模式
總結
Uber 和Facebook採用的就是獨立模式。我們在採訪中無意發現該模式主要有以下兩個版本：
在這兩個版本中，都有一位發展副總裁在領導著團隊。舉個例子，在Uber ，Ed Baker就是發展副總裁，直接向CEO Travis Kalanick彙報。Ed所領導的團隊由100多人組成，與產品、市場、工程、設計以及資料部門的專家共同致力於供求雙方的發展。
根據採訪物件所提供的資訊，Uber就是利用這種模式提高了團隊生產以及反覆運算的速度，建立了很強的團隊DNA。Uber極其重視速度和反覆運算，他們的發展團隊還為此搭建了一個穩健的回饋機制，轉而再將回饋體現在Uber的產品上。
回饋機制能夠幫助一個老用戶群體發展出一個新使用者群體，這種情況通常由老使用者的搜索、支付以及舉薦機制所引發。例如，新用戶是聽了老用戶的推薦而開始使用Uber，這就是推薦回饋的結果。司機是因為看了“成為Uber司機”的廣告而加入Uber，這就是支付廣告的回饋結果。在兩個案例中，無論是供方司機還是需方乘客，都是老用戶利用回饋機制創造新用戶的過程。
Uber發展團隊的職責就是讓這些回饋機制盡可能的強大，以此來提高公司的乘數效應。例如，在Uber推薦回饋機制的乘數效應中乘數是“10”。這也就是說，Uber通過線性手段(例如付費廣告)獲得的用戶將會再創造十倍的新用戶。如果團隊通過付費廣告獲得了1000名用戶的話，那麼這1000位用戶還會通過推薦回饋機制創造10000名新用戶。
乘數效應越好，那麼Uber就發展的越快。
獨立模式中的衝突與解決方案
Pinterest發展部的產品經理Casey Winters認為獨立模式中的衝突是不可避免的。
當Pinterest採用獨立模式時，發展團隊的資料一直處於上升狀態。事實上，Pinterest的資料增長的如此之快，以至於其他團隊都開始擔心這種過快的增長是否是以犧牲廣大的用戶體驗換來的。
舉個例子，當發展團隊推出一個全新的註冊介面時，使用者的活躍度會得到顯著提升，但是憂慮也會同步而來。其他團隊認為這一過程讓用戶體驗變糟。然而，資料最終會給其他團隊的直覺性言論帶來反擊。
這種既要保證使用者體驗，又需要維持增長指標的強勁有力是在採用獨立模式過程中需要面對的最大挑戰。
關於這種增長是否必須要以犧牲用戶體驗為代價的爭論一直不絕於耳，如果不採取措施，“這將會造成用戶對於平臺的信任缺失。” Winters表示，接著又說道“大家應該明白(也應該相信)發展團隊會盡全力為用戶帶來最好的體驗。”
信任的建立
你要如何在不同的團隊間建立最基本的信任?
Casey針對上述問題給出了一個良好建議：讓發展團隊書面承諾自己不會為了增長指標而做出有損用戶體驗的行為。我們的某個採訪物件建議將該承諾書交由CEO保管，因為CEO是企業文化的開創者，與此同時，也請發展和產品副總裁簽訂此協定，以此來減少獨立模式中的衝突。
在Invoice2Go發展主管Naomi Ionita(前印象筆記發展主管)看來，發展部門的工作將不可避免的與產品部門有所重疊。基於自己在帶領這兩個團隊方面的經驗，她解釋道，如果分工明確或者產品發展部的領導具備良好的溝通能力，那麼這種衝突問題是可以避免的。問題又重新回到“了信任、透明度以及客觀性”上。
功能模式
總結
採訪物件們表示，當發展部門的員工需要向功能部門主管(例如產品、工程等)，其他人就會覺得發展指標將會以正確的方式得以實現。
Pinterest、Twitter、LinkedIn、Dropbox和BitTorrent採用的就是功能模式。
該模式的流行得益於以下三個優點。
1、功能主管(如產品、工程等)決定發展計畫。
2、由功能主管來平衡增長和非增長計畫。
3、產品副總裁通常扮演功能主管的角色，從而來掌管發展。
讓我們來看看第三條是如何在實踐中發揮作用的。
Pramod Sokke是BitTorrent的產品主管，能夠在平臺上與所有客戶進行接觸。他要負責BitTorrent的增長及非增長指數，這就意味著Pramod的產品規劃必須圍繞著增長和非增長績效展開，因為他要為兩組的績效表現負責。BitTorrent發展團隊以外的員工也都非常信任Pramod，因為他以一種平衡的方式來制定計劃，確保所有人都能成功。
功能模式中的衝突及解決方案
儘管如此，用戶體驗與用戶增長間的衝突在功能模式中仍然存在。因為上文中提到的幾個優點，衝突並不像獨立模式那麼明顯。之所以衝突還在，是因為保證用戶增長的措施往往與使用者對產品的預期背道而馳。
這就是為什麼我們的採訪物件會提倡縱向分析的原因。通過對用戶行為所進行的分析，我們能夠得知用戶增長是否會以犧牲用戶參與的積極性為代價。同時也會瞭解哪種發展計畫既可以保證用戶數量增長又能提高用戶的參與度。
我們還瞭解到，當增長指數的全權負責人是資料驅動型，並且認可產品是需要反覆運算及學習機制的，功能模式會最具效果。這樣一來，產品的發展藍圖就不會是單憑直覺就規劃出來了。
例如，Pramod在產品上就採用了一種非常典型的資料驅動反覆運算方法。這使得團隊中唯一的發展項目經理AnnabellSatterfield變得更高效。因為這一方法將資料分析和反覆運算過程結合的非常好。
Annabell解釋說她所採用的增長過程就是資料驅動和反覆運算的，跟直覺沒有任何關係，而是全在於過程本身：觀察資料(分別從質和量兩方面分析)、制定假定方案、推出測試方案和最小化可行產品、觀察測試結果，判斷是將此次實驗性產品推向市場還是帶著教訓從頭再來。
現在讓我們以假設的方式來說明功能模式中另一個潛在的衝突，假設資料驅動和產品反覆運算兩個過程未能很好結合。
比方說Pramod在管理產品時採用非反覆運算的方法，而Annabell 採用的還是反覆運算的發展模式。Pramod很可能要求Annabell在產品發展藍圖方面放出大招，這一過程需要6-12個月的時間。Annabell可能會答應Pramod，但是她也可能在短短數周(或者數天)內就用資料驅動產品反覆運算的方法來證明這都是一些爛招。Annabell表示，無論是從收益還是用戶的角度來看，這樣做將會增加產品的計畫成本。
我們的一些採訪物件將會通過改變產品藍圖的方式來對衝突進行解決。在上述假設的例子中，Pramod可能想要雙管齊下，而不是將所有的產品工作全部壓在一種模式上。一個賽道用於實踐Pramod的非反覆運算方法，而另一個則使用Annabell的反覆運算模式。每個賽道都有其獨立的產品、工程以及設計資源，以確保所有的功能都內在計畫的時間和預算內完成。
企業高層必讀(兩種模式必讀之處)
不管怎樣，為了促進發展，公司高層必須引入資料驅動反覆運算的思維模式。不然，無論你怎樣規劃自己的發展團隊都難逃失敗的命運。
結語
在我們所處的軟體世界中，發展與產品相互纏繞，意味著我們很難瞭解產品的終點和發展的起點在何方。這仍然是一個相對較新的現象，同時也使得選擇最佳的團隊發展模式充滿挑戰。
我們的採訪物件，二十位元發展主管，無一例外的都提到了兩種最為流行的模式：獨立模式以及功能模式。在業務可伸縮之際，當你想要組建自己的發展團隊時，這兩種模式都是很好的著手點。
在運行增長試驗中，獨立模式能夠加快產品生產和反覆運算的速度。不過，這種模式也會導致團隊工作透明度的降低，導致企業內部不信任的滋生，而功能模式因採用更為平衡的發展模式而增加了工作的透明度。不過，無論如何，用戶體驗和用戶增長間的衝突仍然存在。
有趣的是，我們並沒有在兩種模式所造成的結果上發現太大差異，也就是說在實現產品更大的指數增長方面，任何一種模式都沒有好過另外一種。
這是一個非常重要的發現。
所以在為團隊選擇發展模式時，以企業文化、組織結構及戰略適應度為考量可能會得到更好的結果。不要單純為了企業發展而選擇模式，要選擇適合的模式。
兩種模式都具有各自的衝突，選擇那種衝突在你團隊能夠解決範圍之內的模式，然後選擇一位元秉性能與之契合的人作為團隊領導。
發展部門主管與產品團隊的關係將會對你所選擇模式以及整家企業的成功與否起到決定性作用。
留言列表
