阿里、騰訊以及一些創(chuàng)業(yè)公司是如何進行研發(fā)管理和績效考核的?在知乎上，這個問題得到了超過5000位網(wǎng)友的關注，顯然，bat獲得的巨大成功使得巨頭們的管理模式成為了人們好奇的焦點。豌豆莢創(chuàng)始團隊成員丁吉昌這個問題下做了一個豌豆莢研發(fā)管理的詳細分享。

　　首先，畫一下我們通常講研發(fā)管理的范疇：確定如何立項，如何確定產品目標，如何把控項目進度，如何驅動產品一代代完善以及如何調動團隊積極性等。

　　在時間周期上來說，我們歸納為 5 個關鍵步驟：選方向、定目標、控進度、帶團隊和排干擾。相配套的，則是在這五個關鍵步驟的一些流程和工具的使用。

　　一、高效研發(fā)的5個關鍵步驟

　　第一步：立項——定方向信息源:汕頭招聘網(wǎng)_www.rc3721.com<;/span>

　　在豌豆莢的整個研發(fā)過程中，立項稱為productbrief或者project brief。團隊的產品經(jīng)理會撰寫一個1-2頁的文檔，然后和執(zhí)行團隊進行評審，如果評審通過，立項就成功了。文檔一般包含會包含以下內容：

　　1. 愿景：一句話表達清楚要做什么;信息源:汕頭招聘網(wǎng)_www.rc3721.com<;/span>

　　2. 分析市場機會和趨勢，決定當前策略;

　　3. 確定目標用戶的特征和核心需求;

　　4. 現(xiàn)存的解決方案和各自的優(yōu)劣勢;

　　5. 該項目對豌豆莢的利益點;如果不做該項目，哪些競爭對手會做，對競爭對手的利益點;

　　6. 需要哪些技術的支持和驅動，哪些技術是豌豆莢的弱項;

　　7. 人力需求;

　　8. 項目的緊急程度，是否需要快速推進;

　　9. 發(fā)布策略;

　　10.核心衡量指標，用來衡量成功的指標。

　　第二步，okr 體系——定目標

　　對一個項目來說，設定目標是非常重要的，因為這決定了如何去做，以及能做到何種程度。豌豆莢采納的目標管理是從 google 引進的 okr 體系(objectives& key results，目標與關鍵成果)，這跟傳統(tǒng)的 kpi(key performance indicator，關鍵績效考核)稍微有些區(qū)別：

　　1. okr 首先是溝通工具：豌豆莢共有 300 多人，每個人都要寫 okr。為了便于溝通，所有這些okr都會放在一個文檔里。任何員工都可以看到 ceo 的這個季度最重要的目標是什么，hr 團隊這個季度的目標是什么。

　　2. okr是努力的方向和目標：okr代表你到底要去哪里，而不是你要去的地方具體在哪里。

　　3. okr必須可量化。比如健身時設定鍛煉目標，如果只是定義成「我們要努力提高身體素質」，肯定不是一個好的 okr，因為無法衡量，好的okr是「今年的跑步時間較去年增加一倍」。

　　4. 目標必須一致：制定者和執(zhí)行者目標一致、團隊和個人的目標一致。首先，制定公司的okr;其次，每個團隊定自己的 okr;第三，每個工程師或設計師寫各自的okr。這三步各自獨立完成，然后對照協(xié)調這三者的okr。在豌豆莢，okr跟個人績效沒有關系，因為okr 系統(tǒng)的結果和每個人并不直接掛鉤。

　　5. 通過月度會議review ，時時跟進okr： 在月度會議上需要確定如何去達到目標，是一個幫助達到目標的過程。

　　6. 通過季度會議 review ，及時調整okr：互聯(lián)網(wǎng)的變化非?？欤酝愣骨v每季度有一個okr 的 review，調整的原則是目標(objectives)不變，只允許調整關鍵成果(key results)。

　　為了更好的理解如何制定okr體系，我們看個例子：

　　● 目標(objectives)：發(fā)布有影響力的新功能，將 xxx 產品做成用戶可以每日使用的產品。

　　● 關鍵成果(key results)：

　　日活躍用戶量為xx;

　　使用xx方式，提高xxx核心指標;

　　第三步，項目管理——控進度：

　　目標設定以后，非常重要的就是執(zhí)行，一般的項目管理實際上就是控制進度。

　　任務/進度勤同步。整個公司所有人的 calender，包括會議、要做的事情、項目的時間節(jié)點都需要及時同步。在整個戰(zhàn)略布局上，如果某個項目工期非常緊，就必須進行更多的溝通，確保每一個環(huán)節(jié)都沒有問題。

　　2. 站立會議 (daily sync)：每天進行站立會議，一般控制在十分鐘之內，每個人說明自己今天要做的工作，需要什么幫助，有誰可以幫忙，可以更有效的調節(jié)資源和公關。

　　3. 多方位溝通(google docs / gmail / hangouts)：對非緊急的事情，兩個團隊或者是兩個人一起討論所有的設計。hangouts用于做快速響應。

　　4. 周會(weekly report)：每周總結。豌豆莢的團隊產品經(jīng)理要做周報，匯報這周的工作、發(fā)布、取得效果以及數(shù)據(jù)。

　　5. 數(shù)據(jù)系統(tǒng)：muce 是豌豆莢的數(shù)據(jù)系統(tǒng)，上面有全公司所有的產品數(shù)據(jù)和運營數(shù)據(jù)。muce 的數(shù)據(jù)能夠用來驗證產品的假設、方向等。

　　第四步，人員管理——帶團隊：

　　項目是由一個個具體的人來執(zhí)行的，所以帶團隊非常重要，在人員管理上，豌豆莢有三個基本原則：

　　1、re-organization& 換組：公司鼓勵員工換組，每個人都有機會到喜愛的團隊做更有趣的事情。只要在原團隊的績效合格，每季度都可申請換團隊或換工作內容。員工的績效不與 okr 掛鉤，公司鼓勵員工挑戰(zhàn)難度、超越優(yōu)秀，低 level 的事情做不到優(yōu)秀會被懲罰，做事不及格也會被懲罰。

　　2、one on one：在帶人方面， one on one 非常重要。one on one 指的是每個團隊的 manager 需要定期(最佳間隔是每周一次)與自己團隊中的每個成員進行一對一討論或者對話。在豌豆莢，manager 首先是一個教練，應該幫助自己團隊的成員成長。通過 one on one，manager 需要了解每個團隊成員現(xiàn)階段的狀態(tài)和遭遇的困擾，分享職業(yè)規(guī)劃，幫助他們正確地處理問題，更好地實現(xiàn)個人成長。

　　3、個人 okr 和 performance 體系：每個員工在每個季度初需要確定自己本季度的 okr，在一個季度結束后需要根據(jù)自己這個季度的工作完成情況給 okr 打分。每半年公司會進行一次 performance review，主要是 review 員工過去半年的績效，并根據(jù) performance review 的結果變更 job ladder(業(yè)務職級)和薪酬。值得一提的是，在豌豆莢，所有的個人performance review 的成就內容及級別都是全公司共享公開的，如下圖所示。這個對于很多公司來說是不可想象的，豌豆莢為什么要這么做?因為一方面對于豌豆莢來說可以做到更為公平和透明，另一方面也給每位豌豆提供了更好學習和成長自己的樣本，激勵大家在產品研發(fā)中更高質量的挑戰(zhàn)和要求自己。

　　第五步，興趣管理——排干擾：

　　1、激發(fā)興趣：hackday，是豌豆莢一個特殊的節(jié)日，開始于2010年，類似黑客馬拉松。通常在春節(jié)假期回來的那一周，產品設計師和工程師們 3-5 人組成一隊，在連續(xù)48小時的時間里，充分展現(xiàn)工程團隊的創(chuàng)意和想像力，完成一些比日常開發(fā)更 geek、更有趣的東西。

　　豌豆莢為了鼓勵大家更好的完成挑戰(zhàn)，也會設計一些特別有特色的獎品，歷史上2012 年提供的是蘋果剛出 macbook retina，2013年是 google glass，2014 年則是程序員最愛的 herman miller 頂級座椅。

　　在歷史的 hackday 中，有不少作品最終都成了重要產品對外發(fā)布，比如 muce、豌豆洗白白和 ias(應用內搜索)，都成為了豌豆莢極具特色的產品。

　　2、控制興趣：polishweek，讓公司慢下來，對已有產品的細節(jié)進行精細化的過程。在大量開發(fā)和新產品上線的過程中，我們會擔心因為走得太快而對產品的細節(jié)關注不夠。在連續(xù)3個工作周后，第4周通常是 polishweek。在 polish week 的這一周，豌豆莢內部不會進行新產品或新功能的開發(fā)，而主要是對現(xiàn)有的產品和服務進行打磨，解決一些細節(jié)問題和小 bug，譬如產品內一些字體的統(tǒng)一等等。平均每個 polish week 會解決產品中各種 bug 大約 200 個。

　　二、高效研發(fā)的流程和工具

　　過去幾年豌豆莢做 windows 版的時候，嘗試過一個月、兩個月、一個星期、兩個星期的發(fā)布節(jié)奏，整個模式跟 chrome 比較像，有功能發(fā)布就希望盡早的發(fā)。我們在服務端上每天都有更新，客戶端會慢一點，現(xiàn)在大概是兩周一個版本，如下圖所示：

　　在開發(fā)節(jié)奏上，前兩周的時間用于開發(fā)，然后截取分支準備發(fā)布，接下來兩周進行測試，同時進行另一個開發(fā)，每一個迭代都控制在兩周之內。相對而言，服務端的發(fā)布比較好操作，可以做很多的回歸測試和自動化測試，不太需要手工的測試來做發(fā)布，但是 windows 和 android 都會有一些 beta 的發(fā)布，在內部很難模擬用戶的使用場景和用戶的環(huán)境，所以在 release 之后的過程中一般會抽樣 1%、5%、10% 這樣一個節(jié)奏來做驗證，主要是看某些指標是否達標。

　　這個流程剛開始執(zhí)行的時候問題特別多。比如在這周開發(fā)完成以后，測試發(fā)現(xiàn)根本測試不了，有很多很多的 bug，工程師只好利用第二個研發(fā)周期去修 bug，然后又會影響第二周期的開發(fā)，這樣問題越來越多，就會導致流程很難進行，然后進入惡性循環(huán)。為了解決這個問題，首先在操作層面上一開始先用一個月的迭代來讓大家適應，同時要求 master 分支必須是可用的(比如某人提交了代碼跑不起來，或者沒有經(jīng)過測試，給其他同事帶來了阻礙，就會被要求請全團隊喝咖啡)。其次加強單元測試和回歸測試，確保每個迭代的研發(fā)質量是可控的，后面的測試主要是回歸和校驗，減輕相互重疊的壓力問題。一個月的迭代跑順了之后，再跑到兩周、一周的節(jié)奏，整體來看，差不多用了半年的時間，豌豆莢就完全跑順了這個流程，想快可以快，想慢也可以慢。

　　工欲善其事必先利其器，為了提升產品研發(fā)效率，豌豆莢內部開發(fā)了一款項目管理工具wandoulabs。作為內部的溝通工具，它主要用來做跨團隊溝通，全公司所有員工都會使用。重要的 roadmaps 必須在這里登記，登記了以后，一個項目需要多少設計師、需要多少marketing、每個階段是什么樣以及工程師的發(fā)布狀態(tài)都可以在這里看得到。

　　這就是前面提到的wandoulabs，大概邏輯如下：不同的標記分別代表研發(fā)狀態(tài)、發(fā)布狀態(tài)、負責的團隊及這個事情的重要級別。

　　對于重要的發(fā)布，豌豆莢有三個最基本的要求：

　　第一要獲得 product/design review 的批準。一個功能開發(fā)以后，無論是界面還是整個 ui，如果會影響到用戶的操作，或者影響到商戶的收入，比如我們的廣告系統(tǒng)或者和合作伙伴的一些策略調整，這就需要做 design review。design review 在豌豆莢里面的時間大概是每周的周一、周三和周六，每次持續(xù) 1-2 個小時，包括product(review)、design(review)或business(review)。product design指的就是 pd，主要的視覺設計師或產品設計師必須全員參加。

　　第二要獲得 engineeringtech review 的批準。這更接近于傳統(tǒng)上的技術設計，主要是看某個功能在工程設計上是怎么做的。做這個設計的團隊和所有工程師必須全員參加，也會有一個人來 host，還需要幾個指標的 review。這個過程是幫助相關的工程師把設計考慮更全面，包括流量、游戲的帶寬壓力的需求等等。

　　第三要獲得 marketingreview 的批準。主要是看產品上需要如何引入 marketing 團隊的配合，需不需要做一些傳播，需不需要注意公關策略等等。

　　同時對于更小的一些 beta 測試則不強制要求。這些 review 實際上是幫助整個團隊、整個公司去理解當前最重要是什么，其實也是建立一個高標準的過程。

　　來源：虎嗅網(wǎng) 作者：丁吉昌