2017年，抖音還只是個 DAU 不足百萬的初創(chuàng)項目，短短幾年就成為億級 C 端產(chǎn)品。在字節(jié)，這樣的 APP 還有很多。字節(jié)內(nèi)部是如何同時支持這么多產(chǎn)品以高效敏捷的方式發(fā)展壯大的？
即便是抖音，早期也面臨著管理系統(tǒng)多、數(shù)據(jù)不準(zhǔn)確、推行困難的問題。因此，秉承 Context not control 的理念，抖音團(tuán)隊孵化出了可定制、可度量、可迭代的一體化管理工具，讓產(chǎn)研工作像“生產(chǎn)線”一樣自運轉(zhuǎn)起來。
近期，在稀土掘金技術(shù)社區(qū)舉辦的第三屆稀土開發(fā)者大會上，飛書項目的技術(shù)負(fù)責(zé)人熊典，分享了他在抖音和飛書項目期間沉淀的產(chǎn)研管理理念和實踐。
熊典畢業(yè)于北京大學(xué)法學(xué)院，是PKU Helper & 合同家的創(chuàng)始人，進(jìn)入字節(jié)后負(fù)責(zé)抖音產(chǎn)研流程的工具支持與落地，從 0 到 1 孵化了飛書項目及多個流程平臺，目前專注于飛書項目產(chǎn)品的打磨和迭代，致力于打造最優(yōu)的產(chǎn)研流程工具。本文是他在稀土開發(fā)者大會上演講內(nèi)容的整理。
當(dāng)討論產(chǎn)研效能的時候，我們在討論什么
大家好，我是熊典。今天的主題是字節(jié)跳動的產(chǎn)研管理實踐，核心是如何用工具助力產(chǎn)研效能。
字節(jié)跳動做了很多產(chǎn)品，頭條、抖音、飛書、西瓜視頻等等。其中有初創(chuàng)產(chǎn)品，也有千人協(xié)作的大團(tuán)隊；有 Demo 工程，也有千萬行代碼工程；也有從內(nèi)部工具走出去成為擁有億級 DAU 的產(chǎn)品。比如說我所在的飛書項目，就是這樣的情況。
那么字節(jié)內(nèi)部是怎么支持這么多產(chǎn)品，高效地協(xié)作開發(fā)的呢？其實是我們的理念和工具。在字節(jié)，我們有圍繞著以飛書項目為核心的一系列工具來支持我們的產(chǎn)研體系，包括 Bits 研發(fā)平臺、 Libra 的 AB 實驗平臺等等。這些工具背后其實有統(tǒng)一的理念：
高效協(xié)作：字節(jié)之前有一條字節(jié)范叫 Context not control，就是希望所有參與到項目里的人都能夠擁有最多的上下文。
高效產(chǎn)出：當(dāng)所有人在一起協(xié)作的效率很高的時候，最后的問題就會變成每個角色自己如何保持專注做到最好。
伴隨成長：字節(jié)所有的 APP 都是從 0 開始做的，第一天可能只有三個人的小團(tuán)隊在做這個產(chǎn)品，最終卻可能成為一個成千上萬人的部門，整個過程不是一蹴而就的，而是一個連續(xù)的、過渡的狀態(tài)。那么我們就需要流程可定制，可度量，可迭代的工具循序漸進(jìn)地支持一個團(tuán)隊從三人到千人的發(fā)展過程。
那么什么才算是好的產(chǎn)研效能？其實就是兩點：第一，交付速度快，團(tuán)隊敏捷，這就是能；第二，產(chǎn)研節(jié)奏好，資源不空轉(zhuǎn)，這就是效。
除了效能之外，還需要關(guān)注兩個點。一個是穩(wěn)定性，另一個是承諾必達(dá)。總的來看，我們實際的關(guān)注點其實就是交付速度、資源利用率和交付確定性。
我 2017 年剛進(jìn)字節(jié)的時候，抖音還是一個 DAU 不足百萬的初創(chuàng)項目，我們的晨會就是做各種流轉(zhuǎn)登記。當(dāng)時我們也用 Google Sheets管理需求，在 IDE 里去做本地開發(fā)，用 GitLab 做 MR 管理，用 Jenkins 做持續(xù)集成，用 JIRA 去跟進(jìn) Bug 和任務(wù)。但這樣多系統(tǒng)并存存在很大問題：一是數(shù)據(jù)不準(zhǔn)確；二是不夠及時；三是難推行。
我們現(xiàn)在是怎么做的？我們做了兩件事：數(shù)據(jù)中心+操作終端。
數(shù)據(jù)中心：我們現(xiàn)在有一個平臺，就是飛書項目，它有非常強大的可定制能力，任何數(shù)據(jù)都可以被建成字段、建成流程，結(jié)構(gòu)化地存儲在里面。
操作終端：當(dāng)我們搞定協(xié)作問題的時候，剩下的瓶頸在哪？在于每個人自己的效率。所以我們想讓每個人都能專注自己的事，順便完成數(shù)據(jù)收集的工作。
我們想要去收集這些數(shù)據(jù)，對很多一線同學(xué)來說肯定是很困難的，因為大家會覺得這是一個額外的工作，所以我們必須要做很多的額外的事情來幫助大家去減負(fù)。
在流程中自然產(chǎn)生數(shù)據(jù)
大家可能會有疑問，就是你好像說得很簡單啊，那具體怎么做？研發(fā)場景到底有什么東西是可以自動收集？到底能給研發(fā)減多少負(fù)？
字節(jié)在做 Mobile APP 研發(fā)的時候，首先會制定一個版本日歷，每個需求采取跟車機制，版本不等需求。
經(jīng)過這樣的流程之后，除了一些必須人工介入的工作，很多節(jié)點都變成了自動化工作。而這些人工作業(yè)也能順便將信息沉淀到統(tǒng)一的數(shù)據(jù)中心里去，方便進(jìn)一步統(tǒng)計和度量分析。
指標(biāo)收集之后，又該如何做度量分析？
我們認(rèn)為度量有幾大原則：
第一，用度量去尋找問題和檢驗效果，但不要與一線同學(xué)的績效掛鉤。
第二，要在全局范圍內(nèi)做數(shù)據(jù)度量，不要把眼光局限在開發(fā)活動。
第三，需要形成度量檢驗的固定周期，不要做一次性工作。
前面提到交付速度、利用率和穩(wěn)定性，它們對應(yīng)到很多的指標(biāo)，我們應(yīng)該如何去落地這些指標(biāo)？
傳統(tǒng)方法是依靠人工，先從五花八門的系統(tǒng)里導(dǎo)出數(shù)據(jù)，然后做數(shù)據(jù)清洗，再導(dǎo)入到本地 Excel 中，再填寫公式，最后復(fù)制圖表到文檔中勝場度量報告。
抖音早期沒有工具的時候，很多數(shù)據(jù)格式不統(tǒng)一，PMO 同學(xué)需要花兩周去清洗、定位、校準(zhǔn)、粘貼這些數(shù)據(jù)，這件事就像是“人力殺手”。
現(xiàn)在有了工具的加持，我們可以很自然地去做這些事情：
第一步，數(shù)據(jù)沉淀。我們把五花八門系統(tǒng)數(shù)據(jù)用結(jié)構(gòu)化的方式無縫收集到一起。
第二步，指標(biāo)沉淀。在系統(tǒng)里面，借助公式字段可以形成標(biāo)準(zhǔn)化的指標(biāo)和圖表。
第三步，定期推送。我們可以基于自動化能力去做自動化定期推送，或者是做預(yù)警處理。
最后一步，實時關(guān)注。系統(tǒng)里可以動態(tài)關(guān)注這些數(shù)據(jù)，方便實時下鉆和分析。
用度量來做流程迭代
當(dāng)我們拿到度量分析結(jié)果之后，又該如何去優(yōu)化流程？
一般情況下，我們有這樣一個流程：
但在日常工作中，實際流程可能長這樣，有很多奇奇怪怪的節(jié)點冒出來。
因此我們需要調(diào)整流程，但調(diào)整完之后，怎么推進(jìn)落地？
一個辦法就是開會，層層傳遞，那有沒有更好的辦法，讓流程迭代自然推行下去？我們可以用度量來做流程迭代。
舉個例子，我們在雙周會上發(fā)現(xiàn)，近期的需求交付時間變長了，然后下鉆發(fā)現(xiàn)，“多語言文案”這個節(jié)點的時長是上升的。原來是近期國際化動作增加，對多語言的要求變高，導(dǎo)致整個時間周期拉長。定位到了問題，我們就針對性地將“多語言翻譯”節(jié)點提前，在“需求詳評”結(jié)束后就進(jìn)入這一環(huán)節(jié)。
但是這樣又會出現(xiàn)新的問題：有些需求走的是舊流程，有些走的是新流程，怎么辦？
飛書項目里有一個功能叫做模版升級，能夠直接把歷史需求升級到新的狀態(tài)，過程中會自動記錄新舊流程里面所有的 DIFF。用這樣的方式，我們把選擇權(quán)交給了每個需求的負(fù)責(zé)同學(xué)，他可以自己選擇是否升級進(jìn)行中的需求，升級之后可以享受到流程上的便利。
流程 SOP 是可沉淀的企業(yè)資產(chǎn)
我們從三人小組的抖音到現(xiàn)在萬人團(tuán)隊的抖音，這個過程不是一蹴而就的，而是連續(xù)的。在這個過程中，我們必須要借助一些工具才能管理好成千上萬的需求以及它們在成千上萬個版本流程里的行為。
有一句我們認(rèn)為非常有價值的話：“流程 SOP 其實是可沉淀的企業(yè)資產(chǎn)?！?strong>不要把流程當(dāng)成需要口口相傳的事情，而是要把它真正沉淀下來，做好迭代，這對產(chǎn)研效能會有非常大的幫助。
飛書項目內(nèi)置了完整的產(chǎn)研管理能力，從源數(shù)據(jù)驅(qū)動的指標(biāo)收集，到開放能力建設(shè)，再到度量分析的圖表和自動化推送，最后到流程的管理、沉淀和迭代。
想要了解更多產(chǎn)研管理最佳實踐？歡迎點擊下方鏈接，一鍵獲取你的專屬解決方案。
