豌豆莢研發管理經驗分享-軟件項目管理及績效考覈方法

豌豆莢研發管理經驗分享

                                                           -軟件項目管理及績效考覈方法

正好最近作了一個豌豆莢研發管理的分享，稍微整理了一份分享到這裏，一塊兒交流學習。

首先，畫一下咱們一般講研發管理的範疇：肯定如何立項，如何肯定產品目標，如何把控項目進度，如何驅動產品一代代完善以及如何調動團隊積極性等。

在時間週期上來講，咱們概括爲 5 個關鍵步驟：選方向、定目標、控進度、帶團隊和排干擾。

相配套的，則是在這五個關鍵步驟的一些流程和工具的使用。

1、高效研發的5個關鍵步驟

第一步：立項——定方向

在豌豆莢的整個研發過程當中，立項稱爲ProductBrief或者Project Brief。團隊的產品經理會撰寫一個1－2頁的文檔，而後和執行團隊進行評審，若是評審經過，立項就成功了。文檔通常包含會包含如下內容：

1. 願景：一句話表達清楚要作什麼；

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

3. 肯定目標用戶的特徵和核心需求；

4. 現存的解決方案和各自的優劣勢；

5. 該項目對豌豆莢的利益點；若是不作該項目，哪些競爭對手會作，對競爭對手的利益點；

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

7. 人力需求；

8. 項目的緊急程度，是否須要快速推動；

9. 發佈策略；

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

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

對一個項目來講，設定目標是很是重要的，由於這決定了如何去作，以及能作到何種程度。豌豆莢採納的目標管理是從 Google 引進的 OKR 體系（Objectives& Key Results，目標與關鍵成果），這跟傳統的 KPI（Key Performance Indicator，關鍵績效考覈）稍微有些區別：

1. OKR 首先是溝通工具：豌豆莢共有 300 多人，每一個人都要寫 OKR。爲了便於溝通，全部這些OKR都會放在一個文檔裏。任何員工均可以看到 CEO 的這個季度最重要的目標是什麼，HR 團隊這個季度的目標是什麼。

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

3. OKR必須可量化。好比健身時設定鍛鍊目標，若是隻是定義成「咱們要努力提升身體素質」，確定不是一個好的 OKR，由於沒法衡量，好的OKR是「今年的跑步時間較去年增長一倍」。

4. 目標必須一致：制定者和執行者目標一致、團隊和我的的目標一致。首先，制定公司的OKR；其次，每一個團隊定本身的 OKR；第三，每一個工程師或設計師寫各自的OKR。這三步各自獨立完成，而後對照協調這三者的OKR。在豌豆莢，OKR跟我的績效沒有關係，由於OKR 系統的結果和每一個人並不直接掛鉤。

5. 經過月度會議Review ，時時跟進OKR： 在月度會議上須要肯定如何去達到目標，是一個幫助達到目標的過程。

6. 經過季度會議 Review ，及時調整OKR：互聯網的變化很是快，因此豌豆莢每季度有一個OKR 的 review，調整的原則是目標（Objectives）不變，只容許調整關鍵成果（Key Results）。

爲了更好的理解如何制定OKR體系，咱們看個例子：

● 目標（Objectives）：發佈有影響力的新功能，將 XXX 產品作成用戶能夠每日使用的產品。

● 關鍵成果（Key Results）：

• 日活躍用戶量爲XX；
  
• 使用XX方式，提升XXX核心指標；

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

目標設定之後，很是重要的就是執行，通常的項目管理實際上就是控制進度。

1. 任務/進度勤同步。整個公司全部人的 calender，包括會議、要作的事情、項目的時間節點都須要及時同步。在整個戰略佈局上，若是某個項目工期很是緊，就必須進行更多的溝通，確保每個環節都沒有問題。

2. 站立會議 (Daily Sync)：天天進行站立會議，通常控制在十分鐘以內，每一個人說明本身今天要作的工做，須要什麼幫助，有誰能夠幫忙，能夠更有效的調節資源和公關。

3. 多方位溝通（Google Docs / Gmail / Hangouts）：對非緊急的事情，兩個團隊或者是兩我的一塊兒討論全部的設計。Hangouts用於作快速響應。

4. 週會（Weekly Report）：每週總結。豌豆莢的團隊產品經理要作週報，彙報這周的工做、發佈、取得效果以及數據。

5. 數據系統：MUCE 是豌豆莢的數據系統，上面有全公司全部的產品數據和運營數據。MUCE 的數據可以用來驗證產品的假設、方向等。

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

項目是由一個個具體的人來執行的，因此帶團隊很是重要，在人員管理上，豌豆莢有三個基本原則：

一、Re-Organization& 換組：公司鼓勵員工換組，每一個人都有機會到喜好的團隊作更有趣的事情。只要在原團隊的績效合格，每季度均可申請換團隊或換工做內容。員工的績效不與 OKR 掛鉤，公司鼓勵員工挑戰難度、超越優秀，低 Level 的事情作不到優秀會被懲罰，作事不及格也會被懲罰。

二、One on One：在帶人方面， One on One 很是重要。One on One 指的是每一個團隊的 manager 須要按期（最佳間隔是每週一次）與本身團隊中的每一個成員進行一對一討論或者對話。在豌豆莢，manager 首先是一個教練，應該幫助本身團隊的成員成長。經過 One on One，manager 須要瞭解每一個團隊成員現階段的狀態和遭遇的困擾，分享職業規劃，幫助他們正確地處理問題，更好地實現我的成長。

三、我的 OKR 和 Performance 體系：每一個員工在每一個季度初須要肯定本身本季度的 OKR，在一個季度結束後須要根據本身這個季度的工做完成狀況給 OKR 打分。每半年公司會進行一次 Performance Review，主要是 review 員工過去半年的績效，並根據 Performance Review 的結果變動 Job Ladder（業務職級）和薪酬。值得一提的是，在豌豆莢，全部的我的Performance Review 的成就內容及級別都是全公司共享公開的，以下圖所示。這個對於不少公司來講是不可想象的，豌豆莢爲何要這麼作？由於一方面對於豌豆莢來講能夠作到更爲公平和透明，另外一方面也給每位豌豆提供了更好學習和成長本身的樣本，激勵你們在產品研發中更高質量的挑戰和要求本身。

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

一、激發興趣：HackDay，是豌豆莢一個特殊的節日，開始於2010年，相似黑客馬拉松。一般在春節假期回來的那一週，產品設計師和工程師們 3-5 人組成一隊，在連續48小時的時間裏，充分展示工程團隊的創意和想像力，完成一些比平常開發更 geek、更有趣的東西。

豌豆莢爲了鼓勵你們更好的完成挑戰，也會設計一些特別有特點的獎品，歷史上2012 年提供的是蘋果剛出 Macbook Retina，2013年是 Google Glass，2014 年則是程序員最愛的 Herman Miller 頂級座椅。

在歷史的 Hackday 中，有很多做品最終都成了重要產品對外發布，好比 MUCE、豌豆洗白白和 IAS（應用內搜索），都成爲了豌豆莢極具特點的產品。

二、控制興趣：PolishWeek，讓公司慢下來，對已有產品的細節進行精細化的過程。在大量開發和新產品上線的過程當中，咱們會擔憂由於走得太快而對產品的細節關注不夠。在連續3個工做周後，第4週一般是 PolishWeek。在 Polish Week 的這一週，豌豆莢內部不會進行新產品或新功能的開發，而主要是對現有的產品和服務進行打磨，解決一些細節問題和小 bug，譬如產品內一些字體的統一等等。平均每一個 Polish Week 會解決產品中各類 Bug 大約 200 個。

2、高效研發的流程和工具

過去幾年豌豆莢作 Windows 版的時候，嘗試過一個月、兩個月、一個星期、兩個星期的發佈節奏，整個模式跟 Chrome 比較像，有功能發佈就但願儘早的發。咱們在服務端上天天都有更新，客戶端會慢一點，如今大概是兩週一個版本，以下圖所示：

在開發節奏上，前兩週的時間用於開發，而後截取分支準備發佈，接下來兩週進行測試，同時進行另外一個開發，每個迭代都控制在兩週以內。相對而言，服務端的發佈比較好操做，能夠作不少的迴歸測試和自動化測試，不太須要手工的測試來作發佈，可是 Windows 和 Android 都會有一些 Beta 的發佈，在內部很難模擬用戶的使用場景和用戶的環境，因此在 release 以後的過程當中通常會抽樣 1%、5%、10% 這樣一個節奏來作驗證，主要是看某些指標是否達標。

這個流程剛開始執行的時候問題特別多。好比在這周開發完成之後，測試發現根本測試不了，有不少不少的 Bug，工程師只好利用第二個研發週期去修 Bug，而後又會影響第二週期的開發，這樣問題愈來愈多，就會致使流程很難進行，而後進入惡性循環。爲了解決這個問題，首先在操做層面上一開始先用一個月的迭代來讓你們適應，同時要求 Master 分支必須是可用的（好比某人提交了代碼跑不起來，或者沒有通過測試，給其餘同事帶來了阻礙，就會被要求請全團隊喝咖啡）。其次增強單元測試和迴歸測試，確保每一個迭代的研發質量是可控的，後面的測試主要是迴歸和校驗，減輕相互重疊的壓力問題。一個月的迭代跑順了以後，再跑到兩週、一週的節奏，總體來看，差很少用了半年的時間，豌豆莢就徹底跑順了這個流程，想快能夠快，想慢也能夠慢。

工欲善其事必先利其器，爲了提高產品研發效率，豌豆莢內部開發了一款項目管理工具Wandoulabs。做爲內部的溝通工具，它主要用來作跨團隊溝通，全公司全部員工都會使用。重要的 roadmaps 必須在這裏登記，登記了之後，一個項目須要多少設計師、須要多少marketing、每一個階段是什麼樣以及工程師的發佈狀態均可以在這裏看獲得。

這就是前面提到的Wandoulabs，大概邏輯以下：不一樣的標記分別表明研發狀態、發佈狀態、負責的團隊及這個事情的重要級別。

對於重要的發佈，豌豆莢有三個最基本的要求：

第一要得到 Product／Design Review 的批准。一個功能開發之後，不管是界面仍是整個 UI，若是會影響到用戶的操做，或者影響到商戶的收入，好比咱們的廣告系統或者和合做夥伴的一些策略調整，這就須要作 Design Review。Design Review 在豌豆莢裏面的時間大概是每週的周1、週三和週六，每次持續 1-2 個小時，包括Product（Review）、Design（Review）或Business（Review）。Product Design指的就是 PD，主要的視覺設計師或產品設計師必須全員參加。

第二要得到 EngineeringTech Review 的批准。這更接近於傳統上的技術設計，主要是看某個功能在工程設計上是怎麼作的。作這個設計的團隊和全部工程師必須全員參加，也會有一我的來 host，還須要幾個指標的 review。這個過程是幫助相關的工程師把設計考慮更全面，包括流量、遊戲的帶寬壓力的需求等等。

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

同時對於更小的一些 Beta 測試則不強制要求。這些 Review 其實是幫助整個團隊、整個公司去理解當前最重要是什麼，其實也是創建一個高標準的過程。

文章來源：http://www.zhihu.com/question/20190597/answer/26416269?utm_campaign=rss&utm_medium=rss&utm_source=rss&utm_content=title