創(chuang)投分享會(hui)注：阿里、騰訊以及一些創業(ye)公司是如何(he)進行研發管(guan)理和績效考核的(de)？在知乎上(shang)，這(zhe)個問(wen)題(ti)得到了(le)超過5000位網友的(de)關注，顯然，BAT獲(huo)得的(de)巨大成功使得巨頭們(men)的(de)管(guan)理模式成為了(le)人們(men)好(hao)奇的(de)焦點。豌豆莢創始團隊(dui)成員丁吉昌這(zhe)個問(wen)題(ti)下做了(le)一個豌豆莢研發管(guan)理的(de)詳(xiang)細分享。本文已(yi)獲(huo)作(zuo)者授權。
首先，畫一下我們通常講研發管理的范疇：確定如何立項，如何確定產品目標，如何把控項目進度，如何驅動產品一代代完善以及如何調動團隊積極性等。
在時間周(zhou)期(qi)上來說，我們(men)歸(gui)納(na)為 5 個關鍵(jian)步驟(zou)：選方向、定目(mu)標、控進度、帶團隊和排干擾(rao)。相配(pei)套的(de)，則(ze)是在這(zhe)五個關鍵(jian)步驟(zou)的(de)一些流程和工具的(de)使用。
一、高效(xiao)研發的5個關鍵步驟
第一步：立項——定(ding)方向
在(zai)豌(wan)豆(dou)莢的整個研發過程中，立項(xiang)稱為ProductBrief或(huo)者Project Brief。團(tuan)隊的產品經理會撰(zhuan)寫一(yi)個1－2頁的文(wen)(wen)檔(dang)，然(ran)后和(he)執行團(tuan)隊進行評(ping)(ping)審，如果(guo)評(ping)(ping)審通(tong)過，立項(xiang)就成功了(le)。文(wen)(wen)檔(dang)一(yi)般包含(han)會包含(han)以下內容(rong)：
1. 愿景：一句話表(biao)達清楚(chu)要做(zuo)什么；
2. 分析市場(chang)機會和趨勢(shi)，決(jue)定當(dang)前策(ce)略(lve)；
3. 確(que)定目標(biao)用(yong)戶的特(te)征(zheng)和(he)核心需求；
4. 現(xian)存的解(jie)決方案(an)和(he)各自的優劣(lie)勢(shi)；
5. 該項目對豌豆莢的利益點；如果不做該項目，哪些競爭對手會(hui)做，對競爭對手的利益點；
6. 需(xu)要哪些技術(shu)的支(zhi)持和驅動，哪些技術(shu)是豌豆莢的弱項；
7. 人力需求；
8. 項目的緊急程度，是否需要快(kuai)速推進(jin)；
9. 發布策略；
10.核心衡量指標，用來(lai)衡量成功的(de)指標。
第二步，OKR 體系——定目(mu)標
對一(yi)個項目來說，設定(ding)目標(biao)是非常重(zhong)要的，因為這決定(ding)了如(ru)何去做，以及能做到何種程度。豌豆(dou)莢采納的目標(biao)管(guan)理是從(cong) Google 引進的 OKR 體(ti)系（Objectives& Key Results，目標(biao)與關(guan)(guan)鍵(jian)(jian)成果），這跟(gen)傳統的 KPI（Key Performance Indicator，關(guan)(guan)鍵(jian)(jian)績效(xiao)考核）稍微有些區別(bie)：
1. OKR 首(shou)先是溝(gou)通工具(ju)：豌(wan)豆莢共有(you) 300 多人，每個(ge)(ge)人都要寫(xie) OKR。為了便(bian)于溝(gou)通，所有(you)這些OKR都會(hui)放(fang)在一個(ge)(ge)文檔(dang)里(li)。任何員工都可以看到(dao) CEO 的(de)這個(ge)(ge)季(ji)度最重要的(de)目(mu)標(biao)是什么(me)，HR 團隊這個(ge)(ge)季(ji)度的(de)目(mu)標(biao)是什么(me)。
2. OKR是努力的(de)方向和(he)目標：OKR代(dai)表你(ni)(ni)到底要(yao)去哪里，而(er)不是你(ni)(ni)要(yao)去的(de)地方具(ju)體在哪里。
3. OKR必須(xu)可量化(hua)。比如(ru)健身(shen)(shen)時設(she)定(ding)(ding)鍛煉目標，如(ru)果只是定(ding)(ding)義(yi)成「我們要努力提高身(shen)(shen)體(ti)素質」，肯定(ding)(ding)不是一(yi)個好(hao)的(de)(de) OKR，因為無法衡量，好(hao)的(de)(de)OKR是「今年的(de)(de)跑(pao)步時間較去年增加(jia)一(yi)倍」。
4. 目標(biao)(biao)必須一(yi)致：制定者(zhe)和執(zhi)行(xing)者(zhe)目標(biao)(biao)一(yi)致、團隊和個人(ren)的(de)(de)目標(biao)(biao)一(yi)致。首先，制定公司的(de)(de)OKR；其(qi)次，每(mei)個團隊定自(zi)己(ji)的(de)(de) OKR；第(di)三，每(mei)個工程(cheng)師或設計師寫各自(zi)的(de)(de)OKR。這三步各自(zi)獨(du)立完(wan)成，然(ran)后對照協調這三者(zhe)的(de)(de)OKR。在豌(wan)豆莢，OKR跟個人(ren)績效(xiao)沒(mei)有(you)關系，因為OKR 系統的(de)(de)結果和每(mei)個人(ren)并不(bu)直接掛鉤。
5. 通過(guo)月(yue)度會議(yi)Review ，時時跟進OKR： 在月(yue)度會議(yi)上需(xu)要確(que)定如何去達(da)到目標(biao)，是(shi)一個(ge)幫助達(da)到目標(biao)的過(guo)程(cheng)。
6. 通過季度(du)會議 Review ，及時調整(zheng)(zheng)OKR：互聯網的變化非常(chang)快(kuai)，所(suo)以(yi)豌豆莢每季度(du)有(you)一個OKR 的 review，調整(zheng)(zheng)的原則是目(mu)標(biao)（Objectives）不變，只允許調整(zheng)(zheng)關(guan)鍵成果(guo)（Key Results）。
為了更好的理解如何制定OKR體系，我們看個例子：
● 目(mu)標(biao)（Objectives）：發布有影響力的新功(gong)能(neng)，將(jiang) XXX 產品做成用戶可以(yi)每日(ri)使用的產品。
● 關鍵(jian)成(cheng)果（Key Results）：
日活躍用戶量為XX；
使用(yong)XX方式，提高XXX核心指標；
第三步，項目管理——控進(jin)度：
目標(biao)設定以后，非常(chang)重要的就是執行，一般的項目管理實際上就是控制進度。
任務/進度勤同步。整個(ge)公(gong)司所有(you)人的(de) calender，包括會議、要做(zuo)的(de)事情、項目的(de)時(shi)間節點都(dou)需要及時(shi)同步(bu)。在(zai)整個(ge)戰略(lve)布局(ju)上，如(ru)果某個(ge)項目工期非常緊，就必須進行更多的(de)溝通，確保每一個(ge)環節都(dou)沒有(you)問題。
2. 站立會議 (Daily Sync)：每天進行(xing)站(zhan)立會議，一般(ban)控(kong)制在十(shi)分鐘之內，每個人說明自(zi)己今(jin)天要(yao)做的工作，需要(yao)什么(me)幫助，有誰可以(yi)幫忙，可以(yi)更有效的調節(jie)資(zi)源和公關(guan)。
3. 多方位溝通（Google Docs / Gmail / Hangouts）：對非(fei)緊急的(de)事情，兩個團(tuan)隊或(huo)者是兩個人一起討論(lun)所有(you)的(de)設計。Hangouts用于做快(kuai)速響應。
4. 周會（Weekly Report）：每周(zhou)總結。豌豆莢的(de)(de)團隊產品經(jing)理要做周(zhou)報，匯(hui)報這周(zhou)的(de)(de)工作、發(fa)布、取得(de)效果以(yi)及數據(ju)。
5. 數據系統：MUCE 是豌豆莢(jia)的(de)(de)數(shu)據系統(tong)，上(shang)面有全公司所有的(de)(de)產品數(shu)據和(he)運營數(shu)據。MUCE 的(de)(de)數(shu)據能夠用來驗證產品的(de)(de)假設、方向(xiang)等。
第四步，人員管理(li)——帶(dai)團隊：
項目是由一個(ge)(ge)個(ge)(ge)具體(ti)的人來(lai)執(zhi)行的，所以(yi)帶團隊非常重(zhong)要，在(zai)人員管(guan)理(li)上，豌豆(dou)莢有三個(ge)(ge)基本原則：
1、Re-Organization& 換組：公(gong)司(si)(si)鼓勵(li)員(yuan)工換組，每個人都有(you)機會到喜愛的(de)團(tuan)隊做(zuo)更有(you)趣的(de)事(shi)(shi)情。只(zhi)要在原團(tuan)隊的(de)績效合格，每季度都可申(shen)請(qing)換團(tuan)隊或換工作(zuo)內容。員(yuan)工的(de)績效不(bu)與 OKR 掛鉤(gou)，公(gong)司(si)(si)鼓勵(li)員(yuan)工挑戰難(nan)度、超越(yue)優(you)秀，低 Level 的(de)事(shi)(shi)情做(zuo)不(bu)到優(you)秀會被懲(cheng)罰(fa)，做(zuo)事(shi)(shi)不(bu)及格也會被懲(cheng)罰(fa)。
2、One on One：在(zai)帶人(ren)方面(mian)， One on One 非常重要(yao)。One on One 指的(de)(de)是(shi)每(mei)(mei)個團隊(dui)的(de)(de) manager 需要(yao)定期(qi)（最佳間隔是(shi)每(mei)(mei)周一次）與(yu)自己團隊(dui)中(zhong)的(de)(de)每(mei)(mei)個成(cheng)員(yuan)進行一對一討論或者對話。在(zai)豌豆莢，manager 首先是(shi)一個教練，應該幫助自己團隊(dui)的(de)(de)成(cheng)員(yuan)成(cheng)長。通過 One on One，manager 需要(yao)了解(jie)每(mei)(mei)個團隊(dui)成(cheng)員(yuan)現階段的(de)(de)狀態和(he)遭遇的(de)(de)困(kun)擾，分享(xiang)職業規劃(hua)，幫助他們正確地處理問(wen)題(ti)，更好地實現個人(ren)成(cheng)長。
3、個人 OKR 和 Performance 體系：每(mei)(mei)個員工(gong)(gong)在每(mei)(mei)個季(ji)度(du)初需要(yao)(yao)確定自(zi)(zi)己本季(ji)度(du)的(de) OKR，在一(yi)個季(ji)度(du)結(jie)束后需要(yao)(yao)根據自(zi)(zi)己這個季(ji)度(du)的(de)工(gong)(gong)作完成情(qing)況給 OKR 打分。每(mei)(mei)半(ban)年(nian)公司會進行一(yi)次 Performance Review，主要(yao)(yao)是(shi) review 員工(gong)(gong)過去半(ban)年(nian)的(de)績效，并根據 Performance Review 的(de)結(jie)果變更(geng) Job Ladder（業務職級）和(he)薪酬。值得(de)一(yi)提的(de)是(shi)，在豌豆(dou)莢，所有的(de)個人Performance Review 的(de)成就內(nei)容及級別都是(shi)全公司共享公開(kai)的(de)。這個對(dui)(dui)于(yu)很多公司來說是(shi)不可想象的(de)，豌豆(dou)莢為(wei)什么(me)要(yao)(yao)這么(me)做(zuo)(zuo)？因為(wei)一(yi)方(fang)面對(dui)(dui)于(yu)豌豆(dou)莢來說可以做(zuo)(zuo)到更(geng)為(wei)公平和(he)透明(ming)，另(ling)一(yi)方(fang)面也給每(mei)(mei)位豌豆(dou)提供了更(geng)好學習和(he)成長(chang)自(zi)(zi)己的(de)樣本，激勵大家在產(chan)品研發中更(geng)高質量的(de)挑戰(zhan)和(he)要(yao)(yao)求自(zi)(zi)己。
第五步，興趣管理(li)——排干擾：
1、激發興趣：HackDay，是豌豆(dou)莢一(yi)個特(te)殊(shu)的節日，開始于2010年，類似黑客馬拉(la)松。通常在春節假期回來的那一(yi)周(zhou)，產(chan)品設計師和(he)工(gong)程師們 3-5 人組成一(yi)隊，在連(lian)續48小時的時間里，充(chong)分展現工(gong)程團隊的創意和(he)想(xiang)像力(li)，完(wan)成一(yi)些比日常開發(fa)更(geng) geek、更(geng)有趣的東西。
豌豆(dou)莢為(wei)了鼓(gu)勵大家更好的完成(cheng)挑戰，也會設計一些(xie)特別有特色的獎品，歷史上2012 年提供的是(shi)蘋果剛出 Macbook Retina，2013年是(shi) Google Glass，2014 年則(ze)是(shi)程序員(yuan)最(zui)愛的 Herman Miller 頂級座椅。
在歷(li)史的 Hackday 中，有不(bu)少作品最終(zhong)都成(cheng)了重要(yao)產(chan)品對外發布，比(bi)如 MUCE、豌豆洗(xi)白白和 IAS（應用(yong)內搜索），都成(cheng)為了豌豆莢極具特色的產(chan)品。
2、控制興趣：PolishWeek，讓公司慢下來，對已有產品的細節進行精細化的過程。在(zai)大量(liang)開發(fa)和(he)新(xin)產(chan)品(pin)上(shang)線的(de)過程中，我們會(hui)擔(dan)心因為走得太快而(er)對產(chan)品(pin)的(de)細(xi)節關注不夠。在(zai)連續3個工作(zuo)周后，第(di)4周通常是 PolishWeek。在(zai) Polish Week 的(de)這一(yi)(yi)(yi)周，豌豆莢(jia)內(nei)部不會(hui)進行新(xin)產(chan)品(pin)或新(xin)功能的(de)開發(fa)，而(er)主要是對現有(you)的(de)產(chan)品(pin)和(he)服務進行打(da)磨，解決(jue)一(yi)(yi)(yi)些細(xi)節問題和(he)小 bug，譬如產(chan)品(pin)內(nei)一(yi)(yi)(yi)些字體的(de)統一(yi)(yi)(yi)等等。平均每個 Polish Week 會(hui)解決(jue)產(chan)品(pin)中各種 Bug 大約 200 個。
二、高效研發的流程和(he)工(gong)具
過(guo)去幾年豌豆莢做(zuo) Windows 版(ban)的時候，嘗試過(guo)一(yi)(yi)個(ge)(ge)(ge)月、兩(liang)(liang)個(ge)(ge)(ge)月、一(yi)(yi)個(ge)(ge)(ge)星(xing)期(qi)、兩(liang)(liang)個(ge)(ge)(ge)星(xing)期(qi)的發(fa)布(bu)節奏，整(zheng)個(ge)(ge)(ge)模(mo)式跟 Chrome 比(bi)較像(xiang)，有功能發(fa)布(bu)就(jiu)希(xi)望盡早的發(fa)。我們在服(fu)務端上每天都有更新(xin)，客戶(hu)端會慢一(yi)(yi)點，現在大概是(shi)兩(liang)(liang)周一(yi)(yi)個(ge)(ge)(ge)版(ban)本，如下圖所示：
在(zai)開(kai)發(fa)節奏(zou)上(shang)，前(qian)兩周(zhou)的(de)(de)(de)(de)時間(jian)用于(yu)開(kai)發(fa)，然后截取分支準備(bei)發(fa)布，接下來(lai)兩周(zhou)進(jin)(jin)行測(ce)試，同時進(jin)(jin)行另一(yi)(yi)個(ge)開(kai)發(fa)，每一(yi)(yi)個(ge)迭代都控制在(zai)兩周(zhou)之(zhi)內。相對(dui)而言(yan)，服務端的(de)(de)(de)(de)發(fa)布比較好(hao)操(cao)作(zuo)，可以(yi)做很多的(de)(de)(de)(de)回(hui)歸(gui)測(ce)試和(he)自(zi)動化測(ce)試，不太(tai)需要(yao)手工(gong)的(de)(de)(de)(de)測(ce)試來(lai)做發(fa)布，但是 Windows 和(he) Android 都會(hui)有一(yi)(yi)些 Beta 的(de)(de)(de)(de)發(fa)布，在(zai)內部很難模(mo)擬用戶的(de)(de)(de)(de)使用場(chang)景和(he)用戶的(de)(de)(de)(de)環境，所以(yi)在(zai) release 之(zhi)后的(de)(de)(de)(de)過程中一(yi)(yi)般會(hui)抽樣 1%、5%、10% 這(zhe)樣一(yi)(yi)個(ge)節奏(zou)來(lai)做驗(yan)證，主要(yao)是看某(mou)些指標是否(fou)達標。
這(zhe)個流(liu)程(cheng)剛開始(shi)(shi)執行的(de)(de)(de)(de)時(shi)候問題(ti)特別(bie)多。比如在這(zhe)周(zhou)開發完成以后，測(ce)試(shi)(shi)發現根本測(ce)試(shi)(shi)不了(le)(le)(le)，有很多很多的(de)(de)(de)(de) Bug，工程(cheng)師只(zhi)好(hao)利用(yong)第二個研(yan)發周(zhou)期去修 Bug，然后又會影響第二周(zhou)期的(de)(de)(de)(de)開發，這(zhe)樣(yang)問題(ti)越來(lai)越多，就(jiu)會導致(zhi)流(liu)程(cheng)很難進(jin)行，然后進(jin)入惡性循環(huan)。為了(le)(le)(le)解決這(zhe)個問題(ti)，首先在操作層面上一(yi)(yi)開始(shi)(shi)先用(yong)一(yi)(yi)個月(yue)的(de)(de)(de)(de)迭代(dai)來(lai)讓大家適應，同(tong)時(shi)要求 Master 分支必須(xu)是可用(yong)的(de)(de)(de)(de)（比如某人(ren)提交了(le)(le)(le)代(dai)碼跑(pao)不起(qi)來(lai)，或者沒有經過測(ce)試(shi)(shi)，給其他同(tong)事帶來(lai)了(le)(le)(le)阻礙(ai)，就(jiu)會被要求請全團(tuan)隊(dui)喝咖(ka)啡(fei)）。其次(ci)加強單(dan)元測(ce)試(shi)(shi)和(he)(he)回歸測(ce)試(shi)(shi)，確保(bao)每個迭代(dai)的(de)(de)(de)(de)研(yan)發質量是可控的(de)(de)(de)(de)，后面的(de)(de)(de)(de)測(ce)試(shi)(shi)主要是回歸和(he)(he)校驗，減(jian)輕相(xiang)互(hu)重疊的(de)(de)(de)(de)壓力問題(ti)。一(yi)(yi)個月(yue)的(de)(de)(de)(de)迭代(dai)跑(pao)順了(le)(le)(le)之后，再跑(pao)到兩周(zhou)、一(yi)(yi)周(zhou)的(de)(de)(de)(de)節奏，整體來(lai)看(kan)，差不多用(yong)了(le)(le)(le)半年(nian)的(de)(de)(de)(de)時(shi)間，豌豆莢就(jiu)完全跑(pao)順了(le)(le)(le)這(zhe)個流(liu)程(cheng)，想(xiang)快可以快，想(xiang)慢也(ye)可以慢。
工欲善其(qi)事必先利其(qi)器，為了(le)提升產品研發效率，豌豆莢(jia)內部(bu)開發了(le)一款項(xiang)目管理(li)工具Wandoulabs。作為內部(bu)的溝通工具，它主要用來做(zuo)跨團隊溝通，全公司所有員工都(dou)會使用。重要的 roadmaps 必須在這(zhe)里(li)登記，登記了(le)以(yi)后，一個項(xiang)目需要多少設計師(shi)、需要多少marketing、每個階(jie)段(duan)是什么(me)樣(yang)以(yi)及工程師(shi)的發布狀(zhuang)態都(dou)可以(yi)在這(zhe)里(li)看得到。
這就是前面提到的Wandoulabs，大(da)概(gai)邏輯如下：不同(tong)的標(biao)記分別代表(biao)研發(fa)狀態(tai)(tai)、發(fa)布狀態(tai)(tai)、負責的團隊(dui)及這個事情(qing)的重要級別。
對于重(zhong)要(yao)的(de)發(fa)布，豌(wan)豆莢(jia)有三個最基本的(de)要(yao)求：
第一要獲(huo)得 Product／Design Review 的批準。一個(ge)功能開發以后，無論(lun)是(shi)界面還是(shi)整(zheng)個(ge) UI，如(ru)果會影響(xiang)到用(yong)戶(hu)的(de)(de)(de)操作，或(huo)者(zhe)影響(xiang)到商戶(hu)的(de)(de)(de)收入，比如(ru)我(wo)們的(de)(de)(de)廣(guang)告系統或(huo)者(zhe)和合(he)作伙伴的(de)(de)(de)一些策略調整(zheng)，這(zhe)就需要做 Design Review。Design Review 在(zai)豌豆(dou)莢里面的(de)(de)(de)時(shi)間大概是(shi)每周(zhou)(zhou)的(de)(de)(de)周(zhou)(zhou)一、周(zhou)(zhou)三和周(zhou)(zhou)六，每次持續 1-2 個(ge)小時(shi)，包括Product（Review）、Design（Review）或(huo)Business（Review）。Product Design指的(de)(de)(de)就是(shi) PD，主要的(de)(de)(de)視覺設計師(shi)或(huo)產(chan)品設計師(shi)必須全員參加。
第(di)二要獲得 EngineeringTech Review 的批準(zhun)。這(zhe)(zhe)更接近于傳統上的技(ji)術設(she)計(ji)，主要是(shi)(shi)看某個功能在工(gong)程(cheng)設(she)計(ji)上是(shi)(shi)怎么(me)做(zuo)的。做(zuo)這(zhe)(zhe)個設(she)計(ji)的團隊和(he)所有工(gong)程(cheng)師必須全員參(can)加，也會有一(yi)個人(ren)來 host，還(huan)需(xu)要幾(ji)個指標(biao)的 review。這(zhe)(zhe)個過程(cheng)是(shi)(shi)幫(bang)助相(xiang)關的工(gong)程(cheng)師把設(she)計(ji)考慮更全面(mian)，包括流量、游戲的帶寬壓力的需(xu)求(qiu)等(deng)等(deng)。
第三要(yao)獲得 MarketingReview 的批準。主要是看產品上需(xu)要如何引入 marketing 團隊的配合，需(xu)不(bu)需(xu)要做(zuo)一些傳播，需(xu)不(bu)需(xu)要注意(yi)公關策略等等。
同時對于更(geng)小的一(yi)些 Beta 測試則不強制要(yao)(yao)求。這些 Review 實際上是幫助(zhu)整個(ge)團(tuan)隊、整個(ge)公(gong)司(si)去理解當前最重要(yao)(yao)是什么，其實也是建立一(yi)個(ge)高標準的過程。
本文(wen)(wen)由作(zuo)者(zhe)丁吉昌授權創投分享(xiang)會發(fa)表。轉載此文(wen)(wen)章須經作(zuo)者(zhe)同意，并請(qing)附(fu)上(shang)出處(創投分享(xiang)會)及本頁鏈接。原(yuan)文(wen)(wen)鏈接：//www.zhihu.com/question/20190597/answer/26416269
