對話 CTO〡用聲音在一起,聽荔枝 CTO 丁寧聊 UGC 聲音互動平臺的技術世界

摘要

「對話 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 名研發人員的高效率平臺。在這個過程中,荔枝又經歷瞭什麼樣的技術調整、組織結構演化和人員管理的蛻變,是如何在大浪淘沙的競爭中,堅持瞭最初的產品理想。


移動互聯網早期的技術「拓荒者」,一切從用戶出發的技術探索和優化

穎奇:今天很高興能夠跟荔枝 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 上去。

穎奇:所以本質上來說,始終還是用戶體驗為第一優先級,而不是運營成本。

丁寧:是的,我們從始至終沒有過多考慮過運營成本,必須是考慮用戶體驗優先。我寧願效果好,貴一點沒問題。因為我們相信用戶體驗永遠是第一,沒有用戶再便宜也沒有用。

穎奇:這是一個非常棒的價值觀。

丁寧:也是我們一直的堅持,能夠保證體驗的基礎上,再去節省成本,做一些自動化的策略。


基礎決定命運,專註擅長領域,掌握核心技術

穎奇:荔枝現在也面臨著一定規模的增長。您覺得下一階段,比如未來一兩年內,最大的技術挑戰可能會在哪些方面?

丁寧:最大的技術挑戰一直是直播業務的並發。我們從 2016 年開始做直播後,明星直播的並發中出現的問題還是蠻多的,所以我們在明星直播上做瞭大量優化。因為我們做的整體策略是平的,沒有做特殊處理,常規情況下平的策略不會有問題,因為不會有大的流量並發。但明星一來,可能帶來的就是一兩百萬的用戶,這需要做一些架構上的調整。我們也考慮過做兩套系統,不過這樣成本還是蠻大的,平常用不到另一套。所以解決直播業務並發上面,我們花瞭大量的精力。

穎奇:應該有第三方公司能夠提供這樣的解決方案。

丁寧:嗯,的確有一些。但我們有一個技術理念就是最核心的技術或能力一定要自己可控。不論是在發展中,還是現在。

穎奇:這可能跟荔枝的發展過程有關系,以前早期創業公司沒有那麼好的開發者服務工具,所以隻能自己做。而現在的創業公司一開始就有很多的選擇,所以他們不願意自己做,發展到中後期的話可能還要補課。

丁寧:是的,自己控制核心的能力和技術,本身的好處很容易理解。例如,出現問題能快速解決,所有需求能夠快速響應,不依賴於外部。更重要的是,可以「鍛煉程序員的靈魂」。當我們面臨非常底層的技術時候,都需要去面對和克服挑戰的對吧?這是一種技術價值觀,如果沒有堅持這種技術價值觀,這樣的技術文化傳承不下去的話,等到我們需要去挑戰一些更大型項目的時候,技術人員的水平就很堪憂瞭。

穎奇:說到這裡,想聊聊荔枝的研發團隊管理。荔枝現在的研發團隊是什麼樣的規模?

丁寧:200 多人吧。

穎奇:管理這麼大規模的團隊,有沒有您已經堅持瞭很多年的管理方法或理念,包括一些策略?

丁寧:對於整個技術團隊,我有一個最基本的要求,就是剛剛所說的核心的東西要掌握自己手裡。你會發現,當團隊有這麼一個信念之後,技術團隊聚攏的就是這批人,這就是我在技術層面的價值觀。我認為這個價值觀可以鍛煉人。

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

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

穎奇:200 多個程序員,他們會有很多想法,怎麼去理性地管理這些人?

丁寧:這也是有一個發展過程的。在 100 個研發人員的時候,我們沒有特別地去做管理。大傢按照組織架構去分工,產品線、研發線、運營線。我就管研發這條線,例如客戶端、服務端、數據等等,是很典型的組織架構。需求來瞭就一層層分下去,然後所有迭代我那時候都管。

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

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

穎奇:基礎研發的產品化,是說他必須得被業務部門認可。

丁寧:對。未來大方向就是可以產品化。我的小目標是基礎研發可以支持業務發展,大目標是以後把做的這些東西全部串聯起來,技術方面全部進行項目制的變革。把所有事情全部包裝並且項目化,項目化之後確定責任人。

穎奇:那是否會面臨一個問題,可能外面有很多方案做得更好,所以業務部門選擇方案時,並不用選公司內部的,這樣在荔枝內部可以嗎?

丁寧:沒錯,這可以。業務線具有最大決策權。因為 Team Leader 是要考慮到非常多事情包括成本,而且身上承擔最終業績的。如果他覺得用外部的方案更好,那你可以去用。而內部的這些技術研發肯定也有一些優勢。比如說內部的成本核算,靈活的需求定制等等。

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


「責任權利」一致的管理方法,真正激活研發團隊潛力

穎奇:  現在的組織結構下,如何確保大傢目標一致,完成業績呢?

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

穎奇:  這是 OKR 的拆分方法瞭。

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

穎奇:所以制定 KPI 的人,就是整個研發中心的班委。類似阿裡體系的班委。

丁寧:是的。一個研發中心會有一個班委,這個班委就決策哪些項目是需要被列入 KPI 的,需要去跟進的,以及考察它的指標是什麼、它到底產生什麼效果、它的結果會對什麼東西產生作用?從這個角度去設計 KPI 就避免瞭 KPI 都是一些技術指標這種情況。因為數字本身沒有意義。做的再好看、響應再快,沒人用就沒有意義。

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

穎奇:其實我們在做 ONES 的時候也有這樣一個理念,就是任何事情有且隻有一個人負責,每個任務包括每個版本每個迭代都是這樣。

丁寧:是的,但也有一個問題就是技術同學比較單純。我們強調的企業文化是目標一致嘛,大傢就想,那個目標一致不就是讓我配合其他團隊麼。而其實目標一致的前提是要「責任、權利」清晰,再去做到目標一致。如果不清晰,又要求大傢一致,就會出現扯皮的現象。所以這個要先思想進行轉變,思想要想轉變,首先要清晰責任人是誰。

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


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

穎奇:我剛才聽您講的是技術上的一些理念和技術團隊的發展過程,那您個人是怎樣的職業經歷呢?才能使得技術團隊形成瞭現在的規模和戰鬥力。

丁寧:我早期是做項目管理的,我是從 2007 年開始做項目管理,一直做到 2016 年。當時的項目管理牽扯不到這麼多像 OKR、KPI 這樣的管理目標等上層管理方法。

穎奇:當時的項目管理更多可能是瀑佈流的或 PMP。

丁寧:對,我那時候用 Scrum,到今天還是。但是項目管理本身管的是時間、風險、項目人員的安排,做完以後出不出業績是完全不確定的。當我從項目管理這個圈子裡面跳出來的時候,站在更高的層面從公司業績實現這個角度去看時,看到的就不僅僅是項目管理這麼一個點瞭。我們不能是原來那種隻是盯著這個項目「做完就好」這樣簡單的邏輯,業務思維要更好,更多考慮到整體業績。

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

穎奇:是怎樣的契機,使您從項目管理的程序員轉換成一個對業績或者對業務有理解的 CTO?

丁寧:應該說是 2016 年吧。2016 年的時候,公司在做調整。從原來錄播的大業務線調整出一個直播的新業務線。當時直播的時候業務線發展速度非常快,讓我們看到,第一,有一個業務要快速去調整的時候,需要去做很多的適配。我們之前做瞭很多的東西都不一定合適。在這個新的業務線上去實施的時候是沒有辦法快速去適應的。那時候,我需要想辦法去面對快速的變化,這個其實是作為創始人應該去關註的。那我發現不僅是 Marco(荔枝 CEO 賴奕龍)需要關註的,我覺得我也需要跳出來,面對變化和發展,來適應支撐新的業務,需要有更多思考。

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

穎奇:這是一種管理意識,我們不是僅僅把東西做出來,我們做的也不是產品本身。

丁寧:是的,跳出來後發現其實項目管理隻是要做事情中間的一小部分。當時我做瞭很多的思考,怎麼樣讓技術團隊、讓中層管理也要有這種轉變。大傢一起來關註的是最終的那個結果,而不是做完這件事情就結束瞭。

穎奇:其實這個轉變挺難的。可能需要一個契機,例如公司轉型或發展速度非常快。要有這樣的一個空缺和要求去壓著大傢去成長,包括壓著 CTO 去成長。

丁寧:沒錯。其實很多人不是說有一個叫 CTO 的四年之癢。如果公司業績一直往上走,那其實 CTO 做到第四年的時候會發現基本上各種框架、服務都已經做的很完善瞭。如果沒有很大的挑戰,之前的坑都踩完瞭,過不去的坎其實也肯定早就不做瞭。CTO 做到第四年、第五年到底應該做些什麼?

穎奇:CTO 需要被業務推著再次成長。

丁寧:對,所以說有四年之癢的這麼一個說法。其實我也深刻地感受到,到瞭那個時間點,需要去關註更大的東西瞭,能力應該要有更大地發揮,而不是僅僅在技術本身瞭。剛跳出來時候其實蠻難受的。管業務線的時候覺得抓不住。以前面對技術同學都好管,大傢一起做完一個東西就好。現在要去看業務,讓數據更好的增長,也要去分析業務和用戶需求。

穎奇:所以一個什麼樣的技術人員才可能在未來變成 CTO 呢?

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


深耕音頻 UGC,用聲音和用戶在一起

穎奇:您怎麼看待現在的直播行業,包括直播視頻,或者有哪些商業領域是您現在比較關註的?

丁寧:我們現在做的主要是直播和錄播兩個業務。直播其實現在大傢可以看到是從 2015 年左右開始到 2016 年一步步發展起來的。我個人判斷,直播仍然是個流量型業務。從整個直播生態來說,它的留存一直都在很難持續的往上做,需要不斷的去拿流量來支撐起來商業變現。所以我們要做的工作就是精細化的深度運營來提高轉化率。

穎奇:基本上不同產品的單個用戶的獲取成本基本差不多?

丁寧:對。所以需要精細化的深度運營提高競爭力。精細化運營的話,品類要足夠豐富,要建立一些制度、規則,以及和別人不一樣的特點。當然,別人去抄你這是很難避免的。但是要保持有一些跟別人不一樣的東西。

穎奇:就好像我們現在創業一樣,行業本身沒有什麼秘密。我們能做的事情大傢都能做,但是大傢在同樣的情況下,選擇打牌的方法跟出牌的順序是不一樣的。這個明牌是說所有人都可以看得到我的出牌,這樣的話這個公司在市場上取得成就才不是靠運氣,而是真正實打實的定位和戰略。通過組織和精細化運營,切實的把戰略真正執行出來。不知道荔枝是否也是這樣,有你們獨特的定位,而且明確告訴大傢的。

丁寧:荔枝從一開始到現在一直定位的都是 UGC,純 UGC。我們的理念就是把草根培養出來。有些人對自己的聲音比較自信或者有異於常人的能力,我們就要把他們挖掘出來,推向更多的用戶。偶爾明星過來代言,也是為瞭能夠去提升整個品牌的知名度。而荔枝產品本身不管是錄播還是在直播,是完全純 UGC 的。

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

穎奇:所以這特別像淘寶的發展狀態,像淘寶大學。中小主播自己學會運營、找流量、自己去做廣告。成長到一定規模後,像淘寶大學來教這些賣傢們去來運營。

丁寧:對,教給大傢基礎技能,怎麼包裝自己宣傳自己。完成瞭整個的包裝鏈學習鏈,到大主播後就是有整個主播運營團隊去跟進瞭。我們會義不容辭去幫助主播,也會去投一些工作室。我們並不是狹隘的隻在做荔枝本身,我們其實是做整個中國的播客市場,這個市場我們覺得現在還很早期。

穎奇:除瞭聲音領域的錄播、直播,您還關註哪些好玩的商業?

丁寧:我現在特別看好的是新能源汽車。因為我覺得新能源智能汽車會是一個超級終端。它不僅是像手機載體,它是比手機還大的一個超級終端。當然可能使用頻度沒有手機這麼高。汽車具有承載作用,還有移動和匯聚的作用,各種信息都匯聚在一起,像車聯網、物聯網、互聯網等等。而新能源的發展將會對這個行業產生很大的激發。我們現在也在和一些新能源汽車進行合作。

穎奇:這會回到一個非常經典的場景上去,就是開車聽電臺。新能源汽車取代舊能源車,然後荔枝來取代掉老的電臺。

丁寧:是的。語音一說,需要什麼電臺節目,還能有些互動。現在大屏又是趨勢,不久的將來,整個前擋風玻璃是有可能是完全的 AR 顯示。AI 在音頻領域可以審核內容也可以做千人千面的智能推薦。每天輸入一些性格、音色、知識面等等這些參數數據,那它可能就會去學習相關的這個領域,同時去做相關領域的節目。然後我們輸進去的一個基礎音色,可能就是你的音色,再有一些微調的變化,這樣一個很有特色的主播就出來瞭。這完全是有可能的。

穎奇:是否可以推薦些您最近在看的覺得不錯的書給大傢?

丁寧:《How Google Works》(《重新定義公司》)挺好的,這是一本管理書籍。除此以外最近德魯克的書我也看的特別多。從技術視角跳出來之後,我發現純管理重塑瞭我。它一直在向我提問,我到底在做的是什麼?我的客戶到底是誰?他們的需求到底是什麼?就這三個問題一直在問自己,讓我對我們現在做這個事情有更深刻的瞭解。

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


作者:王穎奇

作者聯系方式:[email protected]


未經允許不得轉載: 左方新聞網 - 每日提供最新鮮的新聞資訊 » 對話 CTO〡用聲音在一起,聽荔枝 CTO 丁寧聊 UGC 聲音互動平臺的技術世界

贊 ()

評論

留言与評論(共有 0 条評論)
   
驗證碼: