1. 先認清戰(zhàn)場VR產(chǎn)品總監(jiān)和普通產(chǎn)品總監(jiān)的差異點在哪我在VR行業(yè)做了將近八年產(chǎn)品從早期的移動端VR盒子一路做到現(xiàn)在的VR一體機和分體機帶過內(nèi)容團隊、軟件團隊也和硬件團隊死磕過無數(shù)次排期。老實說VR產(chǎn)品總監(jiān)這個崗位最尷尬的地方在于——市面上絕大多數(shù)通用的產(chǎn)品管理方法論拿過來根本沒法直接用。你照著互聯(lián)網(wǎng)產(chǎn)品的范式去管流程、搞溝通不出三個月就會被拖進泥潭。為什么因為VR產(chǎn)品的交付鏈路是硬件、軟件、內(nèi)容三線并行而且每條線的節(jié)奏完全不同。一個普通App產(chǎn)品需求評審?fù)昱牌陂_發(fā)一個季度怎么也能上線一版。VR產(chǎn)品不是這樣你的體驗依賴頭顯設(shè)備的算力、屏幕、光學(xué)方案你的內(nèi)容依賴片源、引擎、素材管線你的軟件還要同時面對SDK兼容性和性能優(yōu)化問題。三條線互相咬合任何一條拖后腿整個產(chǎn)品就卡住。我見過太多從2C互聯(lián)網(wǎng)轉(zhuǎn)過來的產(chǎn)品負責(zé)人一開始都會犯一個共性錯誤用功能迭代的思維來管理VR產(chǎn)品。比如規(guī)劃了一個3D電影播放功能產(chǎn)品經(jīng)理吭哧吭哧寫好PRD把播放器交互畫得漂漂亮亮排期也定了結(jié)果開發(fā)做了一半發(fā)現(xiàn)硬件解碼能力不滿足8K片源的需求或者光學(xué)方案導(dǎo)致的畸變矯正算法還沒調(diào)好。這個時候你去找硬件團隊理論人家一句話就能噎死你——你當初需求評審的時候為什么沒提性能要求所以VR產(chǎn)品總監(jiān)要做的第一件事不是急著定需求、畫原型而是先把這個崗位的特殊性想清楚你的工作對象不是一個獨立的軟件系統(tǒng)而是一臺真實存在的物理設(shè)備加上一套內(nèi)容生態(tài)。你既要懂頭顯的硬件規(guī)格和技術(shù)邊界又要懂用戶的真實體驗場景和痛點然后在中間做大量的對焦、權(quán)衡和翻譯工作。咱們后面聊的所有流程優(yōu)化和溝通優(yōu)化都建立在這個認知之上。1.1 延遲這個詞的兩層含義體驗指標與協(xié)同痛點VR行業(yè)有個專業(yè)指標叫Motion-to-Photon也就是用戶頭部轉(zhuǎn)動的瞬間到畫面真正刷新出來的時間差。行業(yè)共識是控制在20毫秒以內(nèi)才算合格如果超過這個值用戶就會感到頭暈甚至惡心。這個指標本質(zhì)上是一個技術(shù)指標但它直接決定了用戶是否愿意把設(shè)備戴在頭上超過十分鐘。有意思的是延遲在VR產(chǎn)品總監(jiān)的工作里還有另一層含義那就是跨團隊協(xié)作的信息延遲。硬件團隊改了一個屏幕刷新率的方案可能兩周之后軟件團隊才通過一次偶然的溝通知道內(nèi)容團隊拿到的片源編碼格式和播放器團隊預(yù)設(shè)的解碼方案不一致等到聯(lián)調(diào)那天才炸出來。技術(shù)上的延遲你可以靠研發(fā)團隊拼命優(yōu)化協(xié)作上的延遲只能靠流程設(shè)計和主動溝通去消滅。我后來總結(jié)了一句話VR產(chǎn)品總監(jiān)本質(zhì)上是一個降低行業(yè)協(xié)同熵增的角色。硬件、軟件、內(nèi)容三方各說各話各自都有自己的一套術(shù)語、節(jié)奏和優(yōu)先級你要做的就是建立一套機制讓信息能夠低損耗地流動。這也是為什么我一直強調(diào)流程和溝通不是管理上的軟技能而是VR產(chǎn)品能不能做出來的硬底盤。1.2 一塊屏幕、一條發(fā)熱曲線、一幀渲染時間里的博弈再往深了說VR產(chǎn)品和普通消費電子最不一樣的地方在于它的體驗是全身心沉浸的。用戶戴上頭顯的那一刻他看到的不是一個界面而是一個世界。這意味著任何一點瑕疵都會從局部的功能性問題上升為體驗性災(zāi)難。舉一個很實際的例子屏幕的發(fā)熱問題。普通手機發(fā)熱用戶頂多覺得燙手降降溫就好了。VR頭顯發(fā)熱意味著鏡片起霧、臉部出汗、設(shè)備降頻、幀率不穩(wěn)最后用戶頭暈想吐直接摘下設(shè)備給差評。硬件團隊關(guān)心的是散熱結(jié)構(gòu)能不能壓住溫升軟件團隊關(guān)心的是性能調(diào)度能不能撐住幀率而你作為產(chǎn)品總監(jiān)必須把兩邊的目標強行拉到一個共同的用戶體驗基線上去對齊。這種博弈每天都會發(fā)生。性能調(diào)優(yōu)時GPU占用率、CPU頻率、內(nèi)存帶寬、電池功耗這些參數(shù)擺在一起硬件說要保功耗軟件說要保畫質(zhì)你怎么辦你沒有選擇只能建立起一套以用戶體驗指標為核心的評價體系讓大家用同一套數(shù)據(jù)說話。這也為后面談流程優(yōu)化埋了個伏筆——VR產(chǎn)品的流程不能是簡單的需求→開發(fā)→測試→上線線性流程而是要圍繞體驗?zāi)繕俗霾⑿型七M和持續(xù)對焦。2. 流程重構(gòu)把三線并行的混亂變成可推進的節(jié)奏很多VR產(chǎn)品團隊的項目管理方式是這樣的硬件團隊自己跑硬件的開發(fā)流程軟件團隊用敏捷迭代的節(jié)奏做版本內(nèi)容團隊按自己的排期在采買和制作內(nèi)容。三個團隊各有一套甘特圖總監(jiān)桌上擺著三個版本的進度表。每次周會三個團隊分別匯報自己的進度聽起來似乎一切正常。但真正的項目推進時你會發(fā)現(xiàn)一個殘酷的事實純軟件迭代流程、純硬件研發(fā)流程、純內(nèi)容制作流程這三者之間根本不存在天然的耦合點。你軟件做好了硬件還沒定版你沒法做整機聯(lián)調(diào)硬件定版了內(nèi)容又沒跟上發(fā)布時只能讓用戶面對空空如也的內(nèi)容庫內(nèi)容齊了軟件版本還有一個性能問題沒修完上線日期一拖再拖。所以流程優(yōu)化的第一步不是引入什么高深的項目管理方法論而是重新設(shè)計里程碑節(jié)點——不再按職能劃分各自的里程碑而是按整機體驗來定義關(guān)鍵的、跨團隊的匯合點。2.1 需求評審的第一關(guān)不要問做什么而要問以什么體驗標準做我參與過的需求評審會少說也有幾百場。普通互聯(lián)網(wǎng)產(chǎn)品的需求評審核心是討論功能邏輯和交互方案。但VR產(chǎn)品的需求評審如果只討論這些那就是一場注定失敗的會。舉個例子評審一個VR電影院功能。產(chǎn)品經(jīng)理上來講了一堆界面布局、片單管理、支付流程、座椅視角切換講得頭頭是道。聽完之后我第一句話就問你要求的播放幀率是多少支持的最大碼率是什么片源格式兼容范圍定了嗎如果用戶在8K片源下出現(xiàn)掉幀你的降級方案是什么全場安靜。并不是說這些問題產(chǎn)品經(jīng)理完全沒想過而是他默認這些屬于開發(fā)過程中的技術(shù)細節(jié)不用在需求階段討論。在VR產(chǎn)品里這些不是技術(shù)細節(jié)而是產(chǎn)品定義的一部分。你連體驗基線都沒有拉齊后面流程再順都是空談。所以我把VR產(chǎn)品的需求評審流程改成了一套雙輪結(jié)構(gòu)第一輪叫體驗基線評審第二輪才是功能與交互評審。體驗基線評審先過硬件能力和內(nèi)容約束把幀率、延遲、清晰度、音量、溫度、續(xù)航等硬性指標全部定下來形成一份《XR體驗基線表》然后功能評審才開始討論具體的用戶流程和頁面邏輯。這套流程跑了兩年我最大的感受是需求階段多花兩天開發(fā)和聯(lián)調(diào)階段能省兩周。2.2 技術(shù)預(yù)研的時間盒給不確定性一個確定的位置VR行業(yè)的技術(shù)不確定性特別高尤其是硬件相關(guān)的部分。今天你選型了一款屏幕模組明天供應(yīng)商可能告訴你產(chǎn)能不足或良率不達標你用Unity做了一版界面回頭發(fā)現(xiàn)OpenXR的某個API在目標機型上性能大打折扣。這些不確定性如果不在流程里給一個明確的位置它們就會變成流程中隨時爆炸的暗雷。我習(xí)慣在正式排期之前強制安排一段技術(shù)預(yù)研時間盒通常是一到兩周。在這個時間段內(nèi)不做完整的開發(fā)和設(shè)計只做一件事把項目里風(fēng)險最高的三到五個技術(shù)問題快速驗證一遍得出可行、有條件可行、不可行的結(jié)論。一個典型案例我們做VR 6DoF手柄交互功能時最初計劃用頭顯的RGB攝像頭做手柄追蹤。需求評審時大家都覺得沒問題算法團隊拍胸脯說可以。但我堅持加了兩周技術(shù)預(yù)研讓算法團隊用真實的手柄原型在目標機型上跑了一遍追蹤精度測試。結(jié)果發(fā)現(xiàn)快速揮動手柄時追蹤丟失率超過15%完全達不到交互要求。項目組立刻轉(zhuǎn)向了頭顯手柄內(nèi)置IMU融合的方案。如果這個風(fēng)險在正式開發(fā)三個月后才暴露出來整個項目的排期就直接崩了。技術(shù)預(yù)研時間盒不占正式迭代的排期這個位置必須是預(yù)留出來的不能被任何其他事情擠壓。很多產(chǎn)品總監(jiān)覺得這是浪費開發(fā)資源我恰好相反我認為這是整個流程里性價比最高的投資。提示技術(shù)預(yù)研不是無限期的考古。一旦到了時間盒的末端就必須要有一個明確的決策輸出——哪怕是當前方案不可行都比再研究研究有價值得多。2.3 內(nèi)容管線VR交付物從來不止是代碼和硬件VR產(chǎn)品和純軟件產(chǎn)品的另一大區(qū)別在于內(nèi)容管線。一個游戲、一個觀影應(yīng)用、一個虛擬社交空間不管是自研還是靠供應(yīng)商內(nèi)容制作和采買都是產(chǎn)品體驗的核心組成部分。而內(nèi)容團隊的工作方式跟研發(fā)團隊完全不一樣更接近影視行業(yè)或游戲工作室——有創(chuàng)意階段、制作階段、資產(chǎn)量最大的中段沖刺、以及最后的打磨期。這個差異讓內(nèi)容管線很容易成為項目排期的黑洞。研發(fā)團隊按兩周一個迭代穩(wěn)定產(chǎn)出內(nèi)容團隊可能前一個月毫無動靜最后兩周突然交付幾百個GB的素材還帶著一堆需要返工的質(zhì)量問題。如果你拿研發(fā)的節(jié)奏去套內(nèi)容團隊你會發(fā)現(xiàn)怎么催都沒用因為內(nèi)容制作本身就是前期越安靜后期越爆炸的特征。我的做法是專門為內(nèi)容管線建一個獨立的核心節(jié)點內(nèi)容制作的中期評審。在預(yù)定上線時間前的六到八周不要求內(nèi)容全部完成但要求內(nèi)容團隊交付一到兩個樣板片段配合開發(fā)中的播放器或渲染引擎做一次全鏈路聯(lián)調(diào)。這一次聯(lián)調(diào)能提前暴露大量問題——片源編碼不兼容、色域映射不對、音畫不同步、控制交互沒有對齊等——而不是等到內(nèi)容全量交付后才發(fā)現(xiàn)根本用不了。內(nèi)容管線的另一個容易被忽視的環(huán)節(jié)是格式規(guī)范。你在需求階段就要和內(nèi)容團隊一起擬一份《片源與素材格式規(guī)范》逐項定死分辨率、編碼格式、碼率上限、音頻聲道、字幕封裝、封面圖規(guī)格。不要覺得這些是技術(shù)細節(jié)我見過太多項目因為片源格式不統(tǒng)一最后程序員寫的播放邏輯要兼容十幾種亂七八糟的參數(shù)組合本質(zhì)上是在給流程的懶惰買單。3. 溝通升級每個關(guān)鍵協(xié)作場景的對話方式流程是把結(jié)構(gòu)搭好但真正讓流程跑起來的是溝通。VR產(chǎn)品總監(jiān)的溝通場景跟普通產(chǎn)品總監(jiān)比要寬得多。普通產(chǎn)品總監(jiān)的溝通對象無非是用戶、運營、研發(fā)、設(shè)計、老板。VR產(chǎn)品總監(jiān)還需要面對硬件工程師、光學(xué)工程師、內(nèi)容版權(quán)方、硬件供應(yīng)鏈、甚至渠道合作方——而且你跟他們沒有一個共同的母語。硬件工程師張嘴就是PPI、刷新率、視場角、亮度均勻性內(nèi)容的人聊的是版權(quán)年限、原盤質(zhì)量、幀打包、杜比全景聲軟件工程師關(guān)心的是渲染管線、DrawCall、GC開銷、兼容性矩陣用戶那邊的反饋則是看得頭暈、畫面糊、戴著重、找不到想看的東西。而你作為產(chǎn)品總監(jiān)必須能把所有這些語言翻譯成一種統(tǒng)一的語言——用戶體驗價值與商業(yè)目標。3.1 與硬件團隊的有效對話用體驗指標代替感性描述我剛帶VR產(chǎn)品那會兒踩過一個特別典型的坑。用戶反饋說畫面看起來不清晰我直接把這條反饋原封不動轉(zhuǎn)給硬件團隊說用戶覺得清晰度不行你們優(yōu)化一下。硬件工程師看了反饋一臉茫然——清晰度不行是個什么指標是分辨率不夠是透鏡畸變沒校正好還是屏幕的Pentile排列導(dǎo)致的顆粒感后來我學(xué)會了一件事跟硬件團隊溝通永遠不要用感性的體驗描述要先把感性描述轉(zhuǎn)化成可測量的體驗指標再基于指標去討論方案。用戶說畫面不清晰我先自己戴上頭顯實際看一下再讓算法團隊測一下紗窗效應(yīng)的可見度、做一個對比度測試圖卡看灰度表現(xiàn)最后定位到是片源的像素密度和屏幕的物理分辨率不匹配導(dǎo)致的問題。這時候你再去找硬件團隊話術(shù)就不一樣了用戶在觀看4K片源時因為屏幕PPI和片源分辨率不匹配有效分辨率只有XXX建議要么調(diào)整片源規(guī)格要么在渲染層加分辨率提升算法。硬件團隊一聽就懂而且能立刻評估成本和技術(shù)可行性。溝通效率直接翻倍。VR產(chǎn)品總監(jiān)一定要逼自己養(yǎng)成一個習(xí)慣任何一條用戶反饋進入研發(fā)團隊之前先親自做一次體驗轉(zhuǎn)譯。就算你無法精確定位原因也要盡量附上設(shè)備型號、片源信息、操作路徑、現(xiàn)象描述這些可復(fù)現(xiàn)的上下文。否則你只是把用戶的模糊抱怨變成了一道無解的題丟給團隊。3.2 與內(nèi)容生態(tài)伙伴的對話權(quán)責(zé)清單比客套關(guān)系更重要VR產(chǎn)品的內(nèi)容生態(tài)特別依賴外部伙伴尤其是片源版權(quán)方和VR視頻資源提供方。很多產(chǎn)品總監(jiān)談到跟內(nèi)容方的合作習(xí)慣用關(guān)系維護的角度去理解。但我的經(jīng)驗是關(guān)系再好的合作伙伴也不如一份權(quán)責(zé)清單管用。VR內(nèi)容合作跟普通的內(nèi)容授權(quán)還不一樣。普通視頻App拿到一個電影版權(quán)基本就能直接上VR視頻還需要額外的適配和制作比如幀打包格式轉(zhuǎn)換、左右眼同步校正、3D深度調(diào)整、碼率壓制、不同頭顯的兼容性適配。這些活兒到底誰來干版權(quán)方只提供原片適配誰來做做壞了誰負責(zé)驗收標準是什么上線時間誰定這些不提前談清楚后面就是無窮無盡的拉扯。我的做法是在正式合作啟動之前拉著內(nèi)容方和軟件團隊一起開一次技術(shù)對接會在會上輸出一份合作雙方都簽字確認的《內(nèi)容交付與驗收規(guī)格書》。規(guī)格書里面不聊感情只列清單交付格式、交付物清單、交付時間、驗收標準、測試設(shè)備、返工流程、版權(quán)授權(quán)范圍?？雌饋砗芊爆嵉坏┡芷饋硪驗楫敃r沒有說清楚而產(chǎn)生的扯皮事件會大幅減少項目推進速度反而更快。跟內(nèi)容方溝通還有一個重要的翻譯工作內(nèi)容方通常不懂VR設(shè)備的硬件邊界。比如他會問我這個片源能做8K 3D嗎如果你直接說可以那你要么是提前踩雷要么是讓內(nèi)容方花了大價錢制作之后發(fā)現(xiàn)設(shè)備不支持。你需要做的是主動告訴他我們目前設(shè)備最高支持5K 3D8K片源放上去體驗反而會下降因為你得重新壓制還會引入延遲。替他考慮清楚技術(shù)邊界內(nèi)容方反而會更信任你。3.3 向上與向下的預(yù)期管理隱形KPI才是真正決定生死的溝通VR產(chǎn)品總監(jiān)的溝通里最容易翻車的其實是向上溝通。老板可能從互聯(lián)網(wǎng)行業(yè)跨過來或者是從手機廠商轉(zhuǎn)過來他習(xí)慣用傳統(tǒng)的KPI體系去度量產(chǎn)品比如應(yīng)用的日活、片庫的保有量、App Store的評分。這些指標對VR產(chǎn)品來說當然重要但如果你只盯這些指標產(chǎn)品很容易在早期階段就走偏。VR設(shè)備的用戶基數(shù)本來就有限過早追求DAU會引導(dǎo)團隊去做各種拉新的小功能而不是先把核心體驗做成戴上不想摘下來。我個人的溝通策略是在向上匯報里單獨開一項叫體驗儲備的指標包含平均連續(xù)使用時長、重購意愿、體驗類負反饋率這幾個維度。每周同步一次并且在下一次版本規(guī)劃時把這些體驗儲備指標的實際變化和版本目標關(guān)聯(lián)起來。這樣老板慢慢會理解VR產(chǎn)品的增長是體驗驅(qū)動的增長而不是流量驅(qū)動的增長。向下的溝通同樣有學(xué)問。VR團隊成員的背景差異很大硬件工程師、軟件工程師、內(nèi)容策劃、產(chǎn)品經(jīng)理大家的出發(fā)點和價值觀完全不同。產(chǎn)品總監(jiān)如果只會用同一種方式跟所有人溝通那基本是在制造混亂。我跟硬件團隊溝通聊的是約束和權(quán)衡跟內(nèi)容團隊溝通聊的是表達和愿景跟軟件團隊溝通聊的是邏輯和節(jié)奏跟產(chǎn)品經(jīng)理溝通聊的是用戶場景和數(shù)據(jù)。這不是人格分裂而是每個團隊天然有自己的語言體系你能不能用對方的語言跟對方交流決定了他愿不愿意配合你?？偙O(jiān)這個崗位在VR項目里的價值其實一半都體現(xiàn)在能不能用一個統(tǒng)一的產(chǎn)品語言把大家拉在一起干活上。4. 案例復(fù)盤一個VR眼鏡3D電影片源項目的全過程前面講了不少方法可能有點抽象。我拿一個具體的項目案例來復(fù)盤一遍你會更直觀地理解流程和溝通到底是怎么在真實項目里起作用的。前兩年我們做了一款VR眼鏡主打3D影院場景核心賣點是戴著VR眼鏡看3D電影。立項之前用戶調(diào)研和電商評論里反饋最多的就是3D片源太少、清晰度不夠、音畫不同步。也就是說用戶的痛點非常集中——片源生態(tài)和播放體驗。項目目標一句話說清楚建立一條從片源采集、制作、審核到上線的標準化質(zhì)量交付鏈路徹底解決片源少、體驗差、上新慢三個老大難問題。聽上去很簡單但實際操作時你會發(fā)現(xiàn)這三個問題分別牽扯硬件解碼能力、片源版權(quán)商務(wù)、內(nèi)容制作管線、播放器開發(fā)、用戶運營五個團隊而且沒有一個團隊愿意承認是自己這邊的問題。4.1 體驗基線的拉齊過程項目啟動后的第一件事不是找片源而是把所有相關(guān)團隊拉到一起確定《3D電影體驗基線表》。這個表定什么幀率60fps必須達標運動到光子延遲控制在20毫秒以內(nèi)支持上下格式和左右格式兩種主流的3D幀打包方式碼率偏好取決于硬件解碼能力上限音頻格式統(tǒng)一成多聲道。這個拉齊基線的過程其實很痛苦。硬件團隊說5K 3D解碼沒問題但整機功耗壓不住續(xù)航會變短內(nèi)容團隊手上一批4K 3D原盤壓到5K格式成本很高軟件團隊明確表態(tài)播放器里做幀率適配和音畫同步方案需要額外開發(fā)時間。三方角力的結(jié)果最后在體驗基線表里寫死了一個大家都能接受的方案整機解碼能力按5K 3D兜底但內(nèi)容生產(chǎn)先用4K 3D起步播放器端默認啟用硬件插幀優(yōu)化把用戶感知到的卡頓降到最低。這個表一旦簽字確認后面所有環(huán)節(jié)就有了統(tǒng)一標準。內(nèi)容團隊沒有自由選擇片源格式的空間軟件團隊也不用猜測硬件能力產(chǎn)品驗收可以直接對照表格逐項檢查。這就是我說的用一套數(shù)據(jù)說話雖然過程很費口舌但省下了后面幾個月無休止的爭議。4.2 流程上做的三次定向調(diào)整第一次調(diào)整發(fā)生在內(nèi)容采買環(huán)節(jié)。原本內(nèi)容團隊是按片子的熱度去采購版權(quán)買回來之后才發(fā)現(xiàn)有些片源設(shè)備不支持、有些片源壓制成本太高、有些版權(quán)方只給流媒體授權(quán)不給下載授權(quán)。我把流程改成版權(quán)采購必須和內(nèi)容格式適配評審并行采購前就要做一輪可行性篩選看看這批片源能不能順利走完適配流程。這個調(diào)整讓后面的片源死稿率下降了大概三成。第二次調(diào)整是引入了內(nèi)容質(zhì)量三審制。一審是機器質(zhì)檢——用自動化的腳本跑格式、碼率、時長、聲道、黑幀、音畫同步檢查二審是人工體驗——由專職的體驗測試員戴上頭顯按標準場景走查三審是由我這個產(chǎn)品負責(zé)人做抽樣驗收重點看這個片子在使用真實設(shè)備播放時用戶會不會產(chǎn)生明顯的不適感。三審制看著笨重但它把內(nèi)容的交付質(zhì)量從靠自覺變成了靠機制。第三次調(diào)整是上線節(jié)奏。過去我們的片源是攢一批、上一批導(dǎo)致一個月里前兩周片庫不動、后兩周突然上新。我把節(jié)奏改成每周固定上新每次上新不用多五到十部就夠但必須穩(wěn)定。這樣用戶每周都有期待運營有節(jié)奏可依內(nèi)容團隊的壓力也被分攤開不再趕月末的deadline。4.3 溝通上出現(xiàn)的三個關(guān)鍵轉(zhuǎn)折第一個轉(zhuǎn)折是跟硬件團隊的一次對話。當時播放器測試發(fā)現(xiàn)部分片源在播放過程中會偶發(fā)卡頓定位原因后發(fā)現(xiàn)是SoC的散熱策略過于激進導(dǎo)致高頻運行時間受限。我在周會上沒有直接催硬件團隊解決卡頓而是把播放器團隊測出的幀率-溫度曲線數(shù)據(jù)拿出來跟硬件工程師一起看哪些溫度閾值可以放寬哪些場景屬于誤殺。最后雙方達成一個妥協(xié)方案針對視頻播放這個固定場景設(shè)一個獨立的性能模式保證長時間播放時的幀率穩(wěn)定。第二個轉(zhuǎn)折是跟內(nèi)容合作方的一次版權(quán)談判。合作方一直希望我們給他們的自制VR內(nèi)容更高等級的推薦位但在技術(shù)側(cè)那批內(nèi)容普遍只有2K到4K的分辨率在頭顯上放大之后糊得不行。我沒有簡單拒絕而是請內(nèi)容方來我們辦公室現(xiàn)場體驗了一下那個效果讓他們自己看到糊是什么概念。然后我們再一起討論能不能提供原素材重新做一版高規(guī)格壓制或者等下一批內(nèi)容再升級技術(shù)標準。那之后內(nèi)容方的期待值就變得現(xiàn)實了很多。第三個轉(zhuǎn)折是向上匯報。這個項目中期公司管理層看到一個現(xiàn)象就是片庫數(shù)量增長沒達到預(yù)期質(zhì)疑內(nèi)容團隊效率有問題。我當時做的第一件事不是去解釋或去找借口而是把體驗基線表、三審制的通過率數(shù)據(jù)、以及單部片源從拿到原片到完成適配上架的完整周期做成一張圖給管理層看清楚片庫增長慢不是因為內(nèi)容團隊懶而是因為邊買邊適配邊質(zhì)檢這套鏈路本來就比買到即上架要慢但我們換來的是用戶播放滿意度大幅上升。管理層的態(tài)度從那之后就從催數(shù)量變成了過問質(zhì)量。4.4 指標驗證與經(jīng)驗沉淀項目上線三個月后回頭去看數(shù)據(jù)片庫總量比之前翻了一番平均每周穩(wěn)定上新達標率超過90%3D電影播放的會話時長比前期版本提升了接近40%差評中關(guān)于片源少和畫面糊的占比分別下降了十幾個百分點。這些數(shù)字背后沒有一個是單靠哪一方努力實現(xiàn)的全部來自流程機制和溝通方式的改進。我也順勢把整個過程沉淀成了幾份標準文檔一份《XR產(chǎn)品與內(nèi)容協(xié)作流程SOP》一份《內(nèi)容交付驗收規(guī)格書模板》以及一份《跨團隊決策會議管理規(guī)范》。后面接新項目、帶新人的時候這幾份文檔省了我太多精力。這個案例再次驗證了我一直堅信的一句話VR產(chǎn)品的問題絕大多數(shù)時候不是技術(shù)實力不夠而是流程設(shè)計和溝通機制沒有跟上業(yè)務(wù)的復(fù)雜度。5. 踩坑清單五個我反復(fù)踩過的流程與溝通之坑做VR產(chǎn)品總監(jiān)這么久踩過的坑兩只手都數(shù)不過來。有些坑是行業(yè)特性決定的繞不開但多數(shù)坑實際上是可以通過流程和溝通的調(diào)整提前避開的。下面這五個坑我?guī)缀趺繋б粋€新人團隊就會看到他們重新踩一遍。5.1 坑一需求評審只聊交互不聊性能預(yù)算這個在前面已經(jīng)提過。VR產(chǎn)品的每一個功能本質(zhì)上都在跟設(shè)備爭奪有限的資源——算力、帶寬、內(nèi)存、功耗。如果一個新功能上線后GPU占用率提升導(dǎo)致原本穩(wěn)定的幀率出現(xiàn)波動那這個功能不管交互做得再精美都是負資產(chǎn)。我的對策是從需求評審階段就把性能預(yù)算當作第一指標來評審。每一個功能必須帶著預(yù)期性能開銷說明進場不管是開發(fā)自己估的還是靠技術(shù)預(yù)研驗證的。沒有性能預(yù)算說明的需求直接打回重寫。這個規(guī)矩剛開始推行時阻力很大團隊覺得形式主義執(zhí)行一個季度之后就沒人再抱怨了——因為線上事故確實肉眼可見地變少了。5.2 坑二把內(nèi)容采買當買橘子買回來才發(fā)現(xiàn)一堆問題新項目最容易犯的錯就是在內(nèi)容采買時只看片單和價格買回來才發(fā)現(xiàn)格式不支持、清晰度不夠、需二次加工甚至設(shè)備根本不兼容。整天跟內(nèi)容版權(quán)方來回郵件扯皮整個項目就在這里空轉(zhuǎn)。我現(xiàn)在的標準動作是做一個采購前置適配評估環(huán)節(jié)。任何一批片源進入采購候選名單前內(nèi)容商務(wù)必須讓技術(shù)團隊抽一個樣片做適配測試跑一遍完整的質(zhì)量鏈路確認可交付標準之后才能談合同。如果樣片測試不過評估直接不通過。貌似多了一道環(huán)節(jié)實際上一旦放到整個項目生命周期里看成本節(jié)約是巨大的。5.3 坑三向上匯報只講進度不講風(fēng)險與取舍邏輯剛做總監(jiān)那陣子我也喜歡在周報里寫本周進展正常風(fēng)險可控。后來我懂了這句話的潛臺詞是我沒怎么干活。真正有價值的匯報內(nèi)容是那些你做了關(guān)鍵取舍、要了資源、堵住了風(fēng)險的決策說明。比如為了保整機續(xù)航我們下調(diào)了播放器默認亮度犧牲了10%的主觀亮度體驗但換來了30%的續(xù)航延長。這種話寫出來老板才知道你在做產(chǎn)品決策而不是在轉(zhuǎn)達進度。溝通的價值在翻譯信息的含金量不在傳達信息的頻率。你越能把復(fù)雜的技術(shù)權(quán)衡翻譯成老板能看懂的商業(yè)語言你的向上溝通就越有效。5.4 坑四忽視內(nèi)容團隊的工作節(jié)奏拿研發(fā)排期去逼內(nèi)容產(chǎn)出前文已經(jīng)提到內(nèi)容制作前期靜悄悄、后期大爆炸。如果你拿研發(fā)團隊的節(jié)奏去要求內(nèi)容團隊每周都產(chǎn)出可衡量的資產(chǎn)他們往往會為了應(yīng)付過程指標而降低前期創(chuàng)造性的投入最終影響交付質(zhì)量。比較好的做法是給內(nèi)容團隊獨立的過程管理指標——前期看制作規(guī)劃和風(fēng)格定版中期看樣板片段后期看完整交付——而不是每周看進度條一樣的完成百分比。內(nèi)容完成30%和完成80%在視覺效果上可能完全看不出區(qū)別拿百分百去管理它只會逼出虛假進度。5.5 坑五把開會當溝通會議記錄了事決策無人跟進VR產(chǎn)品總監(jiān)往往要主持大量的跨團隊溝通會。很多時候會議開著開著就變成了討論會大家來來回回發(fā)表意見會議紀要寫了一大堆但散會之后沒有一個人知道下一步誰干什么、什么時候干完。我后來強行給自己和團隊立了一個規(guī)矩每一次跨團隊會議必須有決策項輸出清單。清單上只放四列——編號、決策內(nèi)容、責(zé)任Owner、截止時間。沒有決策輸出項的會議不如取消有決策項但沒人認領(lǐng)的會議開完就等于沒開。看似是個簡單的表格實則是幫所有參會人員理清了會不是白開的這個心智也大幅壓縮了爛會議的數(shù)量。注意這一步很考驗產(chǎn)品總監(jiān)的硬氣。你要敢于在會議上直接點名這個事到底誰負責(zé)什么時候給我結(jié)果很多協(xié)作低效都是因為沒人愿意當那個逼著別人認領(lǐng)責(zé)任的人。6. 可直接抄走的工具與模板聊了這么多理念和案例我最后把一些沉淀下來、用過無數(shù)次的工具和模板分享出來。這些不是理論模型是直接可以拿去修改使用的東西你在團隊里落地使用時可以根據(jù)實際情況調(diào)整。6.1 《XR體驗基線表》的核心字段這個表是VR產(chǎn)品需求評審的第一個輸入也是整個項目里最為一錘定音的文件。下面是我常用的字段結(jié)構(gòu)分類關(guān)鍵指標目標值測試方法負責(zé)人狀態(tài)視覺刷新率70/90/120Hz 按場景設(shè)定高速攝影測量軟件/硬件待確認視覺運動到光子延遲≤20ms專用延遲測試儀軟件已達標視覺角分辨率視場角內(nèi)不低于XXXX光學(xué)測試臺硬件待確認交互手柄追蹤精度位置誤差≤Xmm自動腳本測試算法待確認內(nèi)容解碼能力最大支持5K 3D/60fps實機壓力測試軟件已達標音頻音畫同步誤差≤45ms測試片源人工判定軟件已達標功耗連續(xù)播放續(xù)航≥2.5小時整機功耗測試硬件待確認這個表的關(guān)鍵不是字段本身而是每一項都必須有一個活人負責(zé)和所有表格最終須由產(chǎn)品負責(zé)人簽字確認這兩個執(zhí)行前提。缺少任何一個表就只是張廢紙。6.2 跨團隊周會的三張表節(jié)奏我?guī)У腣R項目周會頻率不高但效率很高因為我規(guī)定每次周會只討論三張表進度風(fēng)險表、體驗基線段落對照表、關(guān)鍵決策清單。每張表都有固定的更新主人會前發(fā)出來會上只討論增量變化。進度風(fēng)險表簡單粗暴列里程碑節(jié)點、當前狀態(tài)、阻塞項、需要的幫助。完事。體驗基線段落對照表則是把本周內(nèi)線上或測試中暴露出的體驗問題一條一條對照體驗基線表里的標準去檢查發(fā)現(xiàn)問題帶著證據(jù)來不空談感受。關(guān)鍵決策清單就是前面說的決策項輸出清單記錄著每條決策的狀態(tài)和后續(xù)進展。這三張表跑熟了之后你的周會時間能從兩小時縮到四十分鐘而且每個人都覺得該說的說完了該干的事也清楚了。6.3 內(nèi)容交付驗收規(guī)格書的框架這份規(guī)格書是跟內(nèi)容方和供應(yīng)商打交道最核心的武器我建議你根據(jù)自己項目的實際情況剪裁使用。固定部分我通常包含交付物明細、交付時間節(jié)點、格式與編碼參數(shù)規(guī)范、碼率與分辨率要求、音頻規(guī)格、字幕要求、色彩空間要求、幀打包方式、質(zhì)量抽檢標準、返工條件、驗收流程與簽字人。可變部分則根據(jù)內(nèi)容類型動態(tài)調(diào)整。比如VR直播類會增加推流協(xié)議和延遲要求VR互動類會增加交互事件日志和崩潰率標準普通3D電影類則更側(cè)重片源封裝和音畫同步。這份東西最大的價值不是拿給內(nèi)容方看而是拿出來那一刻你、你的技術(shù)團隊、你的內(nèi)容方就都被拉進同一個規(guī)則體系里了。7. 說一說我這些年的體會做了這么多VR產(chǎn)品項目我最深的一個感受是VR產(chǎn)品總監(jiān)這個職位本質(zhì)上是在做系統(tǒng)集成的工作既集成技術(shù)也集成人心。技術(shù)這邊你得懂硬件邊界、懂渲染性能、懂內(nèi)容格式、懂播放器鏈路因為這決定了你做流程規(guī)劃時判斷力夠不夠人心這邊你得能讓硬件、軟件、內(nèi)容三個不同物種的團隊愿意跟你一起拉齊目標因為這決定了流程能不能真正落地。別指望一個完美的流程從天而降也別指望靠一兩場團建就能讓跨團隊溝通順暢。流程是需要你一次次根據(jù)實際項目去迭代的溝通更是需要你每一天都下場去翻譯和對焦的。如果有人問我一個VR產(chǎn)品總監(jiān)最核心的能力是什么我會說是在充滿不確定性的環(huán)境里持續(xù)把各方拉回到同一個目標軌道上的能力。其他所有東西——文檔模板、會議機制、指標體系——都只是這個能力的延伸。最后說一個小技巧吧。在帶VR產(chǎn)品團隊的時候我習(xí)慣在項目最顯眼的白板上永遠保留一塊區(qū)域上面只寫一句話現(xiàn)在的體驗基線是什么我們?yōu)檎l而做這句話不是為了喊口號而是讓每個走進這個項目的同事不管是新來的實習(xí)生還是合作方的負責(zé)人都能在三十秒內(nèi)搞清楚這個項目到底在干什么。VR行業(yè)太容易讓人陷入技術(shù)細節(jié)和流程泥潭里這句話是幫我跟團隊不斷找回方向感的東西。