· 本文內容為圖文形式
· 欄目：對話CTO
· 閱讀時間：15分鐘
· 閱讀建議：深度長文，請配合文末福利慢慢食用
· 掌握難度：★★★☆☆

專欄介紹

「對話 CTO」是極客公園的一檔最新專欄，以技術人的視角聊聊研發管理者的發展和成長。

本專欄由ONES 的創始人&CEO 王穎奇作為特邀訪談者。王穎奇曾參與金山軟體 WPS、金山毒霸等大型軟體的核心開發工作；2011 年創立了正點科技，旗下產品正點鬧鐘、正點日曆在全球使用者過億；2014 年，王穎奇在知名美元基金晨興資本任 EIR，並以個人身份參與十餘家公司的管理諮詢工作；2015 年，王穎奇創立 ONES，致力於提供企業級研發管理解決方案。

摘要

美女主播、短視訊、遊戲直播，這些紛繁的視覺資訊似乎已經將我們的日常填滿。然而，在視覺的另一端，荔枝正在挖掘聲音的一萬種可能。荔枝是國內最大的UGC聲音互動平臺，在荔枝你可以感受到或獨特、或美好的聲音帶來的故事，通過聲音的互動來認識一個主播或體驗一種生活。在這個用聲音打造的世界裡，荔枝已經孕育了超過500萬的優質聲音主播和2億多註冊使用者。

2013年，荔枝還是一個普通的播客創業團隊。當時中國的移動網際網路方興未艾，但流量價格還遠未及現在的體貼親民。作為聲音互動平臺的技術負責人，荔枝聯合創始人兼CTO丁寧當時最棘手的問題是如何讓使用者以最少的流量聽到最高品質的聲音。2013年荔枝上線了iOS和Android兩個移動App版本，音訊編碼用mp3還是AAC，長連結的研發投入是否有必要，是當時的丁寧每天都在思考的問題。

2014年，荔枝便獲得了5萬個電臺的開通，超過Podcast時代中文播客的總量。從零到一的過程中，能夠實現業務如此快速發展，不僅是創始團隊對於播客市場趨勢的準確判斷，也是以使用者體驗為準則的技術團隊夜以繼日對技術架構的優化、嘗試和探索。在業務發展的關鍵階段，使用者體驗和研發運營成本的平衡又該如何解決？

2015年的播客平臺爆發之後，移動音訊出現了巨大的競爭和分化。經過陣痛和思考，荔枝仍然留在了UGC的戰場，堅持最初的理想——給年輕人一個用“聲音陪伴的世界”。激烈的市場環境下，丁寧也在經受著磨練和自我升級，完成了從技術專案的管理者到成熟CTO的管理轉型，帶領大家突出重圍，構建荔枝的技術壁壘。

今天，穎奇拜訪了荔枝CTO丁寧，一起來聊聊這個國內最大的UGC聲音互動平臺，是怎樣從創業團隊發展成為擁有200名研發人員的高效率平臺。在這個過程中，荔枝又經歷了什麼樣的技術調整、組織結構演化和人員管理的蛻變，是如何在大浪淘沙的競爭中，堅持了最初的產品理想。

1、移動網際網路早期的技術“拓荒者”，一切從使用者出發的技術探索和優化

穎奇：今天很高興能夠跟荔枝CTO丁寧同學一起聊聊天，能否先介紹一下荔枝的在音訊技術上的發展過程？
丁寧：好的，我先介紹一下整個過程。我們從2013年7月份開始做荔枝App，首先考慮到當時的使用者在移動環境下的流量消耗問題。探討了幾個方向，比如是用AAC還是mp3？當時mp3還是很流行的。但是mp3本質的問題是在相同位元速率的情況下，效果沒有AAC好。

穎奇：當時如何判斷音訊效果好壞呢？
丁寧：第一種方法是通過聽，第二種方法是通過audition去分析音訊的頻譜，能夠看到整個能量點的分佈情況。然後再通過一段標準的音樂，以及兩個相同（音樂的）位元速率的解碼輸出，就會看到兩者之間的差距。我們希望達到的效果就是要省流量，效果好，還要比較通用。當時在那個環境，用mp3在瀏覽器上可以直接播放；但AAC在個別瀏覽器上是無法播放的。我們想做出來的是全平臺都支援的方案，不僅是App，瀏覽器也要去支援。所以我們做了一個折中的方案，使用者有wifi的情況下用mp3的128kpbs。

穎奇：當時128kbps的在播客上屬於什麼水平的音質呢？
丁寧：聽音樂的話，256kbps才是最低的標準，128kpbs的話被稱為廣播級別。 因為我們當時沒有去考慮到音樂音質，更多的是考慮人聲。在移動環境下是動態位元速率，動態位元速率差不多是在16kbps的AAC。這樣的話，AAC的輸出效果就非常好。我們對比了一下，16kbps的AAC其實比32kbps的mp3效果還好。

穎奇：還可以省一半流量。
丁寧：對，當時我們宣傳的重點就是省流量。不過從省流量這方面來說，不僅僅是音訊，還要從整個客戶端的架構去思考，客戶端也要省流量。站在現在來說流量已經不是那麼重要了，但2012、2013年的時候，流量對人們來說還是蠻重要的。除了位元速率以外，要解決流量問題，我們就在想架構應該怎麼做，我們同時也考察了很多架構。

我們做過幾種模型，一種是完全的短連結。完全的短連結會有推送的問題，我可以推送給iOS端使用者但無法推送到安卓端使用者。其實，今天我們看到很多理論，比如增長模型等等，很重要的一點是你必須觸達使用者，那成本最低的方式就是推送，但當時國內的安卓系統已經去掉了谷歌底層框架，是無法觸達使用者的，也沒有像今天的各類推送平臺（例如小米推送、華為推送、極光、個推等等）。

穎奇：是的，推送是一個相對複雜的底層技術。
丁寧：是，所以那時候我們就思考怎麼解決這個問題。最開始是完全的http、輪詢，我們做了一版，非常耗電，要想怎麼去定輪詢的週期。後來做了改進， 這種改進的形態有很多人也用過，叫法不一樣但其實原理一樣。就是http上去之後在服務端設定一個超時時間，把這個請求hold住，到了超時時間再把它放下去。受限於運營商、地域性等等，真實環境出了各種各樣的問題。因為我們對自己技術的質量要蠻高的，如果不考慮那麼多，做http那就好，但我們還是希望高要求自己把東西做好，於是決定做長連結。但是一轉長連結之後，對整體架構的調整會非常大。那要保持住這個長連結，底層就要去做IM。

我們認為當時微信在IM上可以做出多種變化，那麼長連結也可以在我們的App上實現各種能力，所以我們就照著IM的要求來做。而且還有一個好處，那就是如果後期去做變現業務，是要全鏈路加密的，如果跟一條tcp連線的話，整個全鏈路加密就可以快速的收到一起，不用去分開了。總之，這個過程有出現各種各樣的問題，從http到長連結過渡中間還存在一個過渡，就是http和長連結並存的解決方案。但是真正做的時候也有各種問題，我們最後就選擇做一條長連結。

穎奇：為了做好長連結，勢必要做很多的技術架構調整。
丁寧：沒錯。那個時候開始建立整個長連結的架構，確定架構之後，就要去服務端和客戶端進行調整，之後就是維護一個長連結的策略，對它做大量的優化。比如必須要省電省流量，保持連結的活躍。其中保活還包括程序保活和連結保活，這是兩個問題。我相信你原來創業的時候都有遇到這些問題。

穎奇：對，都走過彎路，包括後來對齊策略喚醒等等。本質上來講，在移動網際網路早期發展的時候，作為工具環境、包括所謂的開發者環境，開發者工具沒那麼成熟的時候都要拓荒的。你們做了長連結架構對現在有什麼樣的影響呢？
丁寧：那個時候選擇長連結作為最初的技術方案，的確對後面的發展產生很大影響。從今天來看，很少有APP是有一個長連結的。這種做法微信也有。我們當時對微信這類即時通訊也做了很多的調研。到今天來說，荔枝的主要業務仍然還是在長連結上，大的架構沒有換，大部分業務還是在長連結上執行，這個在當時對技術實現的要求很高。

穎奇：是的，後來很多公司把推送做成了獨立的業務來發展。
丁寧：對，再舉個最簡單的例子，一般所有request response在一個通道的時候，需要把它進行序號化。原來用http的時候，開一個就是一個通道，再開一個是另一個通道。然而現在全部壓在一個通道里，要求快速的response，這就需要進行編碼了。早期的安卓機效能不太好，我們測試過當大量tcp併發的時候會在底層卡死。如果把這些東西擠在一個通道里，就要去管理這個通道排程。至於怎麼樣去把上傳去做好，那就需要去切分。這個切分的策略，相當於最底層tcp的排程，我們在上層應用層做了一次排程。還有一套優化策略，response的優先順序一定要比上傳的優先順序要高，並且做好通道里面這些切分的排程，我們當時叫單通道多路複用。

上行就上傳和和信令，如何讓使用者感知不是那麼強，影響整個網路，這中間也有很多策略的調整。這事情前前後後折騰很久。我們對技術要求很高就體現在這一點上。

穎奇：但到了今天這個環境下，流量便宜，效能好了，手機電池容量也大了，那麼與您當初做的這些努力，到今天來看還有什麼變化，或者說有什麼更深層次的影響?
丁寧：當初打下的基礎，使得現在整體架構沒有大調整。現在大家已經對流量不是很關心了，這時候我們推進的就是音訊的質量問題。因為其實通道優化已經到一個點上了，那我們更多的是把音訊質量往上提。使用者上傳的音訊越來越大，我們就把位元速率逐漸放開。現在已經支援到300多的位元速率了，這時候上傳下載的壓力會變得更大，所以我們主要的調整都是在後端的編碼與解碼。

穎奇：所以是否可以理解為，早期可能更多重視使用者體驗，而今天其實更多考慮省流量，節省公司的運營成本？
丁寧：會有一些，但其實最大的成本還是音訊裡面的CDN，這個流量成本其實沒法省。你採用什麼樣的編碼基本上就確定完了，所以我們其實更多考慮到使用者層面，他們的流量怎麼辦。

穎奇：CDN有多大的成本優化空間呢？是否會根據客戶不同的位置和不同時間段去做一些CDN的負載，包括遷移、邊緣的一些優化等等嗎？
丁寧：這個其實有一個排程，最早的時候就有考慮到，但是一直沒時間去做。在發展的過程中，我們始終沒有特別重點的去考慮CDN的成本問題，考慮更多的是使用者體驗。假設從1000萬費用中節省到800萬，一定是省錢了。但如果效果不好，使用者體驗也會變糟糕。所以我們更多的技術考慮是從使用者體驗這個角度。怎麼才能讓使用者體驗變得更好呢。

我們做了CDN的排程體系，也就是融合CDN，使用者根據他的情況來選CDN，使用者的行為日誌會不斷上傳，他請求這些節目的整體情況會不斷上傳到我們的後臺。系統根據當時真實情況去調整CDN策略。客戶端會收集使用者收聽情況，會把基本資料收集起來，傳回伺服器去計算所有收集到的使用者資訊，然後有演算法、權重。 權重裡面就包括剛才我說的各種各樣的維度，例如地理資訊、對接的CDN、價格、斷線率、響應時長等等。這些資訊輸進去，每天會計算一次並排出一張表，把這些資訊全部下發到各類地區的使用者，然後決定電信、聯通、移動這些運營商的使用者到底應該切到哪個CDN上去。

穎奇：所以本質上來說，始終還是使用者體驗為第一優先順序，而不是運營成本。
丁寧：是的，我們從始至終沒有過多考慮過運營成本，必須是考慮使用者體驗優先。我寧願效果好，貴一點沒問題。因為我們相信使用者體驗永遠是第一，沒有使用者再便宜也沒有用。

穎奇：這是一個非常棒的價值觀。
丁寧：也是我們一直的堅持，能夠保證體驗的基礎上，再去節省成本，做一些自動化的策略。

2、基礎決定命運，專注擅長領域，掌握核心技術

穎奇：荔枝現在也面臨著一定規模的增長。您覺得下一階段，比如未來一兩年內，最大的技術挑戰可能會在哪些方面？
丁寧：最大的技術挑戰一直是直播業務的併發。我們從2016年開始做直播後，明星直播的併發中出現的問題還是蠻多的，所以我們在明星直播上做了大量優化。因為我們做的整體策略是平的，沒有做特殊處理，常規情況下平的策略不會有問題，因為不會有大的流量併發。但明星一來，可能帶來的就是一兩百萬的使用者，這需要做一些架構上的調整。我們也考慮過做兩套系統，不過這樣成本還是蠻大的，平常用不到另一套。所以解決直播業務併發上面，我們花了大量的精力。

穎奇：應該有第三方公司能夠提供這樣的解決方案。
丁寧：嗯，的確有一些。但我們有一個技術理念就是最核心的技術或能力一定要自己可控。不論是在發展中，還是現在。

穎奇：這可能跟荔枝的發展過程有關係，以前早期創業公司沒有那麼好的開發者服務工具，所以只能自己做。而現在的創業公司一開始就有很多的選擇，所以他們不願意自己做，發展到中後期的話可能還要補課。
丁寧：是的，自己控制核心的能力和技術，本身的好處很容易理解。例如，出現問題能快速解決，所有需求能夠快速響應，不依賴於外部。更重要的是，可以“鍛鍊程式設計師的靈魂”。當我們面臨非常底層的技術時候，都需要去面對和克服挑戰的對吧？這是一種技術價值觀，如果沒有堅持這種技術價值觀，這樣的技術文化傳承不下去的話，等到我們需要去挑戰一些更大型專案的時候，技術人員的水平就很堪憂了。

穎奇：說到這裡，想聊聊荔枝的研發團隊管理。荔枝現在的研發團隊是什麼樣的規模？
丁寧：200多人吧。

穎奇：管理這麼大規模的團隊，有沒有您已經堅持了很多年的管理方法或理念，包括一些策略？
丁寧：對於整個技術團隊，我有一個最基本的要求，就是剛剛所說的核心的東西要掌握自己手裡。你會發現，當團隊有這麼一個信念之後，技術團隊聚攏的就是這批人，這就是我在技術層面的價值觀。我認為這個價值觀可以鍛鍊人。

我們潛心從底層一點點去敲程式碼、分析，去思考可能出現的各種問題過程中，可以鍛鍊技術團隊的思維能力，讓大家更縝密的去考慮技術問題，所以當時我們招聘技術人員的時候一直都是秉承這個理念，而我們的招聘也是非常嚴格的。無論是正式員工還是實習生，我們的面試要求都一視同仁，在技術水平上我們的要求一直很高。

隨著時間推移，我的招聘思維也會有一些變化。最早我的要求是技術能力第一、理念第二、人品可能是第三。後來慢慢我調整了，我開始認同技術理念第一、人品第二、技術能力第三的順序，這也是一個認識上的變化。

穎奇：200多個程式設計師，他們會有很多想法，怎麼去理性地管理這些人？
丁寧：這也是有一個發展過程的。在100個研發人員的時候，我們沒有特別地去做管理。大家按照組織架構去分工，產品線、研發線、運營線。我就管研發這條線，例如客戶端、服務端、資料等等，是很典型的組織架構。需求來了就一層層分下去，然後所有迭代我那時候都管。

隨著公司發展，業務線更多的時候，我們就開始了結構調整。首先，是調整一些工程師去到業務線上，分業務研發和基礎研發。基礎研發還是分客戶端、伺服器以及資料分析，慢慢開始做基礎的核心業務。這種組織結構會有一個問題，就是他們去做很多東西的時候會和業務的系統有一些重複工作，在中後期時不時會發生重複的情況。

當業務線變得龐大，企業相對穩定了的時候又要進行調整。業務線發展速度非常快，基礎研發提供一些東西不滿足他們的需求，認為這個東西做的還沒我們做得好，於是業務線自己就做了相同的東西。基礎研發就很頭疼，覺得既然不認同我們做的東西，那我們存在的價值是什麼？所以我們回過頭來就要去調整整個基礎研發，重新定位基礎研發和業務研發，大家的目標是什麼？然後我們就逐漸地拆分和確認目標，比如分成增長技術化的，就是以資料來驅動整條業務線的前進，然後還有一些技術留在那個研發體系裡，目標是去做更好地底層支援，進行產品化。

穎奇：基礎研發的產品化，是說他必須得被業務部門認可。
丁寧：對。未來大方向就是可以產品化。我的小目標是基礎研發可以支援業務發展，大目標是以後把做的這些東西全部串聯起來，技術方面全部進行專案制的變革。把所有事情全部包裝並且專案化，專案化之後確定責任人。

穎奇：那是否會面臨一個問題，可能外面有很多方案做得更好，所以業務部門選擇方案時，並不用選公司內部的，這樣在荔枝內部可以嗎？
丁寧：沒錯，這可以。業務線具有最大決策權。因為Team Leader是要考慮到非常多事情包括成本，而且身上承擔最終業績的。如果他覺得用外部的方案更好，那你可以去用。而內部的這些技術研發肯定也有一些優勢。比如說內部的成本核算，靈活的需求定製等等。

基礎研發的第一目標是業務支援，第二是把自己做成成熟的專案。專案最大的目標就是能做成通用的，能夠具備完整的對外標準化服務的能力，所以現在全部都往這種平臺化系統化去引進。以前都是不成體系的。

3、“責任權利”一致的管理方法，真正啟用研發團隊潛力

穎奇: 現在的組織結構下，如何確保大家目標一致，完成業績呢？
丁寧：技術在每年年初的時候會進行討論。這一年我們要去做什麼，每半年調整一次目標。我們先定幾個大的方向，然後從這裡面摘出來一些重點專案。其實每一個團隊要跟的專案不止一個。但重要的核心考核往往是核心的負責人身兼1-2個專案。所以我們把這些一年的專案，根據職能摘出來。比如說是客戶端做主導的，那就是放到客戶端的這個Team Leader裡，跟服務端相關的，就放在服務端的Team Leader裡。所以最後你會發現每個人身上都跟了大量專案。

穎奇: 這是OKR的拆分方法了。
丁寧：技術團隊根據KPI來拆分OKR。比如有兩個重要的專案和兩個內部專案的情況下，判斷哪些是重要的、哪些是在這個季度我們一定要做完的，哪些是在要在下個季度要去完成的，哪些是這個季度要做一些預研的，全部拆出來，是一種OKR和KPI結合的管理方法。KPI只是數字，那怎麼實現這個數字，這就要把路徑寫出來。技術同學在討論KPI的時候會有些偏離業務，所以我們會開會多次討論KPI，會明確下來這個KPI最終是為什麼東西來服務的。

穎奇：所以制定KPI的人，就是整個研發中心的班委。類似阿里體系的班委。
丁寧：是的。一個研發中心會有一個班委，這個班委就決策哪些專案是需要被列入KPI的，需要去跟進的，以及考察它的指標是什麼、它到底產生什麼效果、它的結果會對什麼東西產生作用？從這個角度去設計KPI就避免了KPI都是一些技術指標這種情況。因為數字本身沒有意義。做的再好看、響應再快，沒人用就沒有意義。

這個過程需要大量的溝通，班委內部要達成一致。開始的時候大家都是不一致的，比如說客戶端的要做一個專案，需要服務端的支援，那是不是把部分KPI讓服務端去扛，客戶端扛一部分。後來考慮覺得不行。我要求“責任”、“權利”必須要一致，不能兩個團隊都去扛。如果專案最後做失敗了，到底是服務端的責任還是客戶端的責任。

穎奇：其實我們在做ONES的時候也有這樣一個理念，就是任何事情有且只有一個人負責，每個任務包括每個版本每個迭代都是這樣。
丁寧：是的，但也有一個問題就是技術同學比較單純。我們強調的企業文化是目標一致嘛，大家就想，那個目標一致不就是讓我配合其他團隊麼。而其實目標一致的前提是要“責任、權利”清晰，再去做到目標一致。如果不清晰，又要求大家一致，就會出現扯皮的現象。所以這個要先思想進行轉變，思想要想轉變，首先要清晰責任人是誰。

穎奇：所以這是說，我們建立企業文化的同時，也需要給研發同學進行企業文化的翻譯，激發團隊的戰鬥力。

4、CTO的四年之癢，以產品思維和更高的視角做研發管理

穎奇：我剛才聽您講的是技術上的一些理念和技術團隊的發展過程，那您個人是怎樣的職業經歷呢？才能使得技術團隊形成了現在的規模和戰鬥力。
丁寧：我早期是做專案管理的，我是從2007年開始做專案管理，一直做到2016年。當時的專案管理牽扯不到這麼多像OKR、KPI這樣的管理目標等上層管理方法。

穎奇：當時的專案管理更多可能是瀑布流的或PMP。
丁寧：對，我那時候用Scrum，到今天還是。但是專案管理本身管的是時間、風險、專案人員的安排，做完以後出不出業績是完全不確定的。當我從專案管理這個圈子裡面跳出來的時候，站在更高的層面從公司業績實現這個角度去看時，看到的就不僅僅是專案管理這麼一個點了。我們不能是原來那種只是盯著這個專案“做完就好”這樣簡單的邏輯，業務思維要更好，更多考慮到整體業績。

當思考業績本身的時候，就會不斷的去轉變。從原來盯的效率，討論能不能我做出來，能不能按要求按時間做好，到現在要考慮的是業績本身，不僅要做完專案，更要看這個東西上線了以後有沒有很好的效果。讓它能夠更好的發展和迭代，這個思維一定要先轉變。

穎奇：是怎樣的契機，使您從專案管理的程式設計師轉換成一個對業績或者對業務有理解的CTO？
丁寧：應該說是2016年吧。2016年的時候，公司在做調整。從原來錄播的大業務線調整出一個直播的新業務線。當時直播的時候業務線發展速度非常快，讓我們看到，第一，有一個業務要快速去調整的時候，需要去做很多的適配。我們之前做了很多的東西都不一定合適。在這個新的業務線上去實施的時候是沒有辦法快速去適應的。那時候，我需要想辦法去面對快速的變化，這個其實是作為創始人應該去關注的。那我發現不僅是Marco（荔枝CEO賴奕龍）需要關注的，我覺得我也需要跳出來，面對變化和發展，來適應支撐新的業務，需要有更多思考。

當時我想，如果我僅僅是技術員去做技術管理、專案管理，能支撐起這樣的業務嗎？從現在來看，這些快速的發展、這種演變，以當時的我根本就支撐不起。所以我要求自己往高了拔，剛好那時候也參加了很多外部的管理培訓，把目標管理、專案管理、業績管理慢慢全部融合在一起。讓我真正意識到要去站得更高，最終要考慮的是業績。

穎奇：這是一種管理意識，我們不是僅僅把東西做出來，我們做的也不是產品本身。
丁寧：是的，跳出來後發現其實專案管理只是要做事情中間的一小部分。當時我做了很多的思考，怎麼樣讓技術團隊、讓中層管理也要有這種轉變。大家一起來關注的是最終的那個結果，而不是做完這件事情就結束了。

穎奇：其實這個轉變挺難的。可能需要一個契機，例如公司轉型或發展速度非常快。要有這樣的一個空缺和要求去壓著大家去成長，包括壓著CTO去成長。
丁寧：沒錯。其實很多人不是說有一個叫CTO的四年之癢。如果公司業績一直往上走，那其實CTO做到第四年的時候會發現基本上各種框架、服務都已經做的很完善了。如果沒有很大的挑戰，之前的坑都踩完了，過不去的坎其實也肯定早就不做了。CTO做到第四年、第五年到底應該做些什麼？

穎奇：CTO需要被業務推著再次成長。
丁寧：對，所以說有四年之癢的這麼一個說法。其實我也深刻地感受到，到了那個時間點，需要去關注更大的東西了，能力應該要有更大地發揮，而不是僅僅在技術本身了。剛跳出來時候其實蠻難受的。管業務線的時候覺得抓不住。以前面對技術同學都好管，大家一起做完一個東西就好。現在要去看業務，讓資料更好的增長，也要去分析業務和使用者需求。

穎奇：所以一個什麼樣的技術人員才可能在未來變成CTO呢？
丁寧：我認為是有產品思維的，既做技術又需要有產品思維。CTO需要有對業務發展的趨勢判斷，也需要有自己的看法和理解。在帶業務的過程中，肯定有很多挑戰，因為畢竟管理產品和運營肯定不是管理技術那種手段。運營和產品又是直接跟使用者打交道的人。那怎麼樣用產品運營的話術去溝通？然後怎麼樣去理解他們的需求？現在要去挖掘使用者深層次的需求點，要和產品和運營一起去觀察使用者核心的需求在哪裡，而不僅僅是站在技術角度去思考。

5、深耕音訊UGC，用聲音和使用者在一起

穎奇：您怎麼看待現在的直播行業，包括直播視訊，或者有哪些商業領域是您現在比較關注的？
丁寧：我們現在做的主要是直播和錄播兩個業務。直播其實現在大家可以看到是從2015年左右開始到2016年一步步發展起來的。我個人判斷，直播仍然是個流量型業務。從整個直播生態來說，它的留存一直都在很難持續的往上做，需要不斷的去拿流量來支撐起來商業變現。所以我們要做的工作就是精細化的深度運營來提高轉化率。

穎奇：基本上不同產品的單個使用者的獲取成本基本差不多？
丁寧：對。所以需要精細化的深度運營提高競爭力。精細化運營的話，品類要足夠豐富，要建立一些制度、規則，以及和別人不一樣的特點。當然，別人去抄你這是很難避免的。但是要保持有一些跟別人不一樣的東西。

穎奇：就好像我們現在創業一樣，行業本身沒有什麼祕密。我們能做的事情大家都能做，但是大家在同樣的情況下，選擇打牌的方法跟出牌的順序是不一樣的。這個明牌是說所有人都可以看得到我的出牌，這樣的話這個公司在市場上取得成就才不是靠運氣，而是真正實打實的定位和戰略。通過組織和精細化運營，切實的把戰略真正執行出來。不知道荔枝是否也是這樣，有你們獨特的定位，而且明確告訴大家的。
丁寧：荔枝從一開始到現在一直定位的都是UGC，純UGC。我們的理念就是把草根培養出來。有些人對自己的聲音比較自信或者有異於常人的能力，我們就要把他們挖掘出來，推向更多的使用者。偶爾明星過來代言，也是為了能夠去提升整個品牌的知名度。而荔枝產品本身不管是錄播還是在直播，是完全純UGC的。

為了培養起UGC的模式，我們不僅有錄播的播客學院，也有直播的播客學院。面向小主播會去教這種播客怎麼樣去做，直播怎麼樣去開，要怎麼樣去發聲、說話，怎樣去跟使用者互動。到了中間段的這些主播，我們會去教大家怎麼樣去找流量實現自我增長、拉新以及保證留存和促活，怎麼樣去做變現，促進使用者幫你做分享。而面向大主播，則更多的是變現和名氣。要去思考商業模式是什麼。直播其實非常簡單。大主播有固定的金主，他要做的是怎麼樣去獲得更多流量，找到更多的金主，所以可能會有不同的業務形態和變現方式。

穎奇：所以這特別像淘寶的發展狀態，像淘寶大學。中小主播自己學會運營、找流量、自己去做廣告。成長到一定規模後，像淘寶大學來教這些賣家們去來運營。
丁寧：對，教給大家基礎技能，怎麼包裝自己宣傳自己。完成了整個的包裝鏈學習鏈，到大主播後就是有整個主播運營團隊去跟進了。我們會義不容辭去幫助主播，也會去投一些工作室。我們並不是狹隘的只在做荔枝本身，我們其實是做整個中國的播客市場，這個市場我們覺得現在還很早期。

穎奇：除了聲音領域的錄播、直播，您還關注哪些好玩的商業？
丁寧：我現在特別看好的是新能源汽車。因為我覺得新能源智慧汽車會是一個超級終端。它不僅是像手機載體，它是比手機還大的一個超級終端。當然可能使用頻度沒有手機這麼高。汽車具有承載作用，還有移動和匯聚的作用，各種資訊都匯聚在一起，像車聯網、物聯網、網際網路等等。而新能源的發展將會對這個行業產生很大的激發。我們現在也在和一些新能源汽車進行合作。

穎奇：這會回到一個非常經典的場景上去，就是開車聽電臺。新能源汽車取代舊能源車，然後荔枝來取代掉老的電臺。
丁寧：是的。語音一說，需要什麼電臺節目，還能有些互動。現在大屏又是趨勢，不久的將來，整個前擋風玻璃是有可能是完全的AR顯示。AI在音訊領域可以稽核內容也可以做千人千面的智慧推薦。每天輸入一些性格、音色、知識面等等這些引數資料，那它可能就會去學習相關的這個領域，同時去做相關領域的節目。然後我們輸進去的一個基礎音色，可能就是你的音色，再有一些微調的變化，這樣一個很有特色的主播就出來了。 這完全是有可能的。

穎奇：是否可以推薦些您最近在看的覺得不錯的書給大家？
丁寧：《How Google Works》（《重新定義公司》）挺好的，這是一本管理書籍。除此以外最近德魯克的書我也看的特別多。從技術視角跳出來之後，我發現純管理重塑了我。它一直在向我提問，我到底在做的是什麼？我的客戶到底是誰？他們的需求到底是什麼？就這三個問題一直在問自己，讓我對我們現在做這個事情有更深刻的瞭解。

穎奇：最後三個問題特別值得我學習和思考，我也再複述一遍。1.我在做的是什麼？2.我的客戶是誰？3.客戶的需求是什麼？非常感謝您的分享。

本文作者：王穎奇
聯絡方式：[email protected]