阿里、騰訊如何進行研發(fā)管理和績效考核

特選阿里、騰訊如何進行研發(fā)管理和績效考核？

阿里、騰訊如何進行研發(fā)管理和績效考核？

阿里、騰訊如何進行研發(fā)管理和績效考核？

如何進行有效的管理又不流于形式

.zm-item-answer"}'>丁吉昌，豌豆莢創(chuàng)始團隊成員

正好最近做了一個豌豆莢研發(fā)管理的分享，稍微整理了一份分享到這里，一起交流學習。

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

在時間周期上來說，我們歸納為5個關鍵步驟：選方向、定目標、控進度、帶團隊和排干擾。

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

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

第一步：立項——定方向

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

1.愿景：一句話表達清楚要做什么；

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

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

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

5.該工程對豌豆莢的利益點；如果不做該工程，哪些競爭對手會做，對競爭對手的利益點；

6.需要哪些技術的支持和驅(qū)動，哪些技術是豌豆莢的弱項；

7.人力需求；

8.工程的緊急程度，是否需要快速推進；

9.發(fā)布策略；

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

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

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

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

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

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

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

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

6.通過季度會議Review，及時調(diào)整OKR：互聯(lián)網(wǎng)的變化非常快，所以豌豆莢每季度有一個OKR的review，調(diào)整的原那么是目標〔Objectives〕不變，只允許調(diào)整關鍵成果〔KeyResults〕。

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

●目標〔Objectives〕：發(fā)布有影響力的新功能，將XXX產(chǎn)品做成用戶可以每日使用的產(chǎn)品。

●關鍵成果〔KeyResults〕：

日活潑用戶量為XX；

使用XX方式，提高XXX核心指標；

第三步，工程管理——控進度：

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

1.任務/進度勤同步。整個公司所有人的calender，包括會議、要做的事情、工程的時間節(jié)點都需要及時同步。在整個戰(zhàn)略布局上，如果某個工程工期非常緊，就必須進行更多的溝通，確保每一個環(huán)節(jié)都沒有問題。2.站立會議(DailySync)：每天進行站立會議，一般控制在十分鐘之內(nèi)，每個人說明自己今天要做的工作，需要什么幫助，有誰可以幫助，可以更有效的調(diào)節(jié)資源和公關。

3.多方位溝通〔GoogleDocs/Gmail/Hangouts〕：對非緊急的事情，兩個團隊或者是兩個人一起討論所有的設計。Hangouts用于做快速響應。

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

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

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

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

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

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

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

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

豌豆莢為了鼓勵大家更好的完成挑戰(zhàn)，也會設計一些特別有特色的獎品，歷史上2023年提供的是蘋果剛出MacbookRetina，2023年是GoogleGlass，2023年那么是程序員最愛的HermanMiller頂級座椅。

在歷史的Hackday中，有不少作品最終都成了重要產(chǎn)品對外發(fā)布，比方MUCE、豌豆洗白白和IAS〔應用內(nèi)搜索〕，都成為了豌豆莢極具特色的產(chǎn)品。

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

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

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

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

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

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

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

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

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

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

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

2023-06-05

現(xiàn)在的it工程管理和績效考核就是扯淡，居然將一個創(chuàng)造性的勞動當做流水線勞動一樣管理。見過哪個真正的藝術家說方案未來一周要完成多少多少任務的嗎？這也就是為什么活力往往只存在于小型團隊甚至個人之中。好的管理應該是首先要保護團隊的創(chuàng)造性的，如果做不到，那么謝謝，還不如不要管理。

廣聯(lián)達〔glodon〕國際事業(yè)部副總經(jīng)理

好久不來知乎了，簡要介紹廣聯(lián)達的研發(fā)管理的做法，希望可以給你一些啟示吧廣聯(lián)達研發(fā)管理使用的是IPD+敏捷的方式進行研發(fā)管理，IPD是一級層面的研發(fā)管理，多產(chǎn)品多工程管理，敏捷是微觀層面的研發(fā)管理。詳細的可以上網(wǎng)查找一下IPD的資料

績效考核，形式比擬多，我?guī)F隊這些年使用的績效共采用過三種模式：主基二元法、PBC、平衡計分卡，這三種模式分別適用于中小團隊〔15人以內(nèi)〕，中型團隊〔30~100左右〕，大團隊〔多部門管理〕的方式。

要做好績效考核，建立一個健康的績效管理文化很關鍵，績效并不是簡單的考核使用，也肩負著人員能力提升和工作改良作用的。

我以往經(jīng)常和我的主管們說，能有效和進行績效管理是一個想成為管理者的人必須在剛剛成為管理者的時候就優(yōu)先直面和解決的問題，否那么以后還會在相同的問題上困擾。

什么都略懂，什么都不懂

我們的績效考核方式主要是KPI。

KPI是層層分解的：

公司需求→部門KPI→個人KPI

所有的KPI制定都是員工和上級一同制定而成，在KPI實施的周期里，如果你有更多的想法，都可以表達在KPI中。所以我不明白為什么很多人說績效管理只能針對勞動制造企業(yè)。

KPI的評分分為月度和年度。月度評分和年度評分分別作為月度獎金和年度獎金發(fā)放的依據(jù)。

以下是兩個技術人員的KPI截圖：

〔第一個是第二個的考核上級〕我們看這位員工的KPI，包括了開發(fā)、建設、日常維護及其他KPI工程。這些工程都是直接分解他的領導的。在開發(fā)工程上，有些工程有時間限制，因此KPI的評分標準有時限的評分標準。這是上面員工的助理。助理的活就相對簡單，維護和效勞職能占了多數(shù)。

如果沒有績效評價，不知道各位的公司是如何發(fā)工資？————————

重新回到績效本身?？冃菃T工在崗期間行為、態(tài)度和結(jié)果的一個綜合。其實所有企業(yè)都有績效考核，只不過考核的方式五花八門而已。有的企業(yè)喜歡流程化，有的企業(yè)老板說了算，有的企業(yè)看似沒有，實際真的沒有嘛？沒有的話老板怎么發(fā)工資？大家發(fā)一樣的工資么？工資的不同，實際上就是績效結(jié)果的不同表達。

——————

績效考核僅僅只適用流水線工人嗎？

技術人員其實并不比流水線工人高端，大家都是替人打工的，嗨什么勁呀。說績效考核遏制了員工的創(chuàng)造性是因為績效考核的方法方式用錯了。谷歌公司也有績效考核，可人家的創(chuàng)新精神照樣遙遙領先。

——————

績效考核會造成唯老板是從么？

是的，其實在企業(yè)干活，就從來沒有什么自由獨立的說法。你對你的老板負責，你的老板對你的大老板負責。既然你的老板的考評標準是“心情和人品〞，那又何妨?人家只要能讓他的上級開心就好了啊。怎么樣能讓上級開心？通俗意義上的“資本家〞的開心原那么當然是盈利。所以，你還操啥心？

專注互聯(lián)網(wǎng)行業(yè)，IT效勞管理體系、信息安…

簡單引入PMP管理思維，對于一些需要創(chuàng)新的企業(yè)是個災難。。

碼農(nóng)/嚴重拖延癥患者

騰訊主要看你組長和總監(jiān)看你爽不爽

交互設計師

贊同

國內(nèi)好多公司太注重所謂的這些外來理論，反而無視了真正的核心實質(zhì)。。。

我覺得國內(nèi)公司逼格都高死，拿來一堆堆理論學術用語出來，其實并不能很好的應用他們，

太多形式上的東西我覺得物極必反＝－＝

旁觀、思考、實踐是我的樂趣

做研發(fā)個人感覺一定要有個人空間和討論空間。死板的報告流程制度只會浪費大量的注意力。我見過真正有效率的研發(fā)就是產(chǎn)品的開發(fā)者收入與市場反響匹配，不要過于控制過程，研發(fā)的人可能10個月都在冥思苦想，但1天豁然開朗，兩天就完成了工程。

，讓購物變得簡單快樂

卓有成效的管理是非常不容易的事情。KPI在一些公司把員工累的半死。我個人認為要從企業(yè)文化上下功夫。引進一些PMP管理人員，拿一個部門先試水！照抄別人，要想超過別人是一件不容易的事情。在另外一些方面超過騰訊、阿里還是可能的。

慢慢的

在企鵝和創(chuàng)業(yè)公司待過一段時間但是從未聽過績效這東西。你的升職加薪和狗屁績效一點關系沒得，說得難聽點這些天天為績效奮斗的工程師一輩子都在被績效奮斗。要想錢拿得多升得快首先得讓領導爽，要會吹噓自己的工作，比方說你1天能完成的工作必須要5天完成并且讓領導對你的工作認可。工作是混出來的不是做出來了。

互聯(lián)網(wǎng)產(chǎn)品

作為豌豆莢最早的一批用戶，早就改用360了。

只想說一句，看看現(xiàn)在各種對豌豆莢的評論，踏踏實實把產(chǎn)品功能和用戶體驗弄好不行嗎？功能越來越差，各種bug導致不能用，扯淡的功夫日漸增長，有這時間好好學學360不行