創(chuàng)業(yè)公司如何高效的進行產(chǎn)品研發(fā)管理
天下武功無堅不破,唯快不破。在瞬息萬變的移動互聯(lián)網(wǎng)領(lǐng)域,創(chuàng)業(yè)公司要想在巨頭的夾縫中求生存,僅靠一款出色的產(chǎn)品是不夠的,高效敏捷的研發(fā)能力才是公司生存與發(fā)展的關(guān)鍵。高效的研發(fā)模式包括如何確定開發(fā)項目,如何把控項目進度,如何驅(qū)動產(chǎn)品一代代完善以及如何調(diào)動員工的積極性等。通過對豌豆莢的訪談,讓我們來看看這家被稱為中國最具硅谷范的移動互聯(lián)網(wǎng)公司在做產(chǎn)品研發(fā)的過程中是如何進行高效管理的。
一、高效研發(fā)的5個關(guān)鍵步驟
第一步:立項——定方向
在豌豆莢的整個研發(fā)過程中,立項稱為Product Brief或者Project Brief。團隊的產(chǎn)品經(jīng)理會撰寫一個1-2頁的文檔,然后和執(zhí)行團隊進行評審,如果評審通過,立項就成功了。文檔一般包含會包含以下內(nèi)容:
1.????愿景:一句話表達清楚要做什么;
2.????分析市場機會和趨勢,決定當前策略;
3.????確定目標用戶的特征和核心需求;
4.????現(xiàn)存的解決方案和各自的優(yōu)劣勢;
5.????該項目對豌豆莢的利益點;如果不做該項目,哪些競爭對手會做,對競爭對手的利益點;
6.????需要哪些技術(shù)的支持和驅(qū)動,哪些技術(shù)是豌豆莢的弱項;
7.????人力需求;
8.????項目的緊急程度,是否需要快速推進;
9.????發(fā)布策略;
10.?核心衡量指標,用來衡量成功的指標。
第二步,OKR?體系——定目標
對一個項目來說,設(shè)定目標是非常重要的,因為這決定了如何去做,以及能做到何種程度。豌豆莢采納的目標管理是從?Google?引進的?OKR?體系(Objectives & Key Results,目標與關(guān)鍵成果),這跟傳統(tǒng)的?KPI(Key Performance Indicator,關(guān)鍵績效考核)稍微有些區(qū)別:
1.????OKR?首先是溝通工具:豌豆莢共有?300?多人,每個人都要寫?OKR。為了便于溝通,所有這些OKR都會放在一個文檔里。任何員工都可以看到?CEO?的這個季度最重要的目標是什么,HR?團隊這個季度的目標是什么。
2.????OKR是努力的方向和目標:OKR代表你到底要去哪里,而不是你要去的地方具體在哪里。
3.????OKR必須可量化。比如健身時設(shè)定鍛煉目標,如果只是定義成「我們要努力提高身體素質(zhì)」,肯定不是一個好的?OKR,因為無法衡量,好的OKR是「今年的跑步時間較去年增加一倍」。
4.????目標必須一致:制定者和執(zhí)行者目標一致、團隊和個人的目標一致。首先,制定公司的OKR;其次,每個團隊定自己的?OKR;第三,每個工程師或設(shè)計師寫各自的OKR。這三步各自獨立完成,然后對照協(xié)調(diào)這三者的OKR。在豌豆莢,OKR跟個人績效沒有關(guān)系,因為OKR?系統(tǒng)的結(jié)果和每個人并不直接掛鉤。
5.????通過月度會議Review?,時時跟進OKR: 在月度會議上需要確定如何去達到目標,是一個幫助達到目標的過程。
6.????通過季度會議?Review?,及時調(diào)整OKR:互聯(lián)網(wǎng)的變化非???,所以豌豆莢每季度有一個OKR?的?review,調(diào)整的原則是目標(Objectives)不變,只允許調(diào)整關(guān)鍵成果(Key Results)。
為了更好的理解如何制定OKR體系,豌豆莢提供了以下實例:
●??????目標(Objectives):發(fā)布有影響力的新功能,將?XXX?產(chǎn)品做成用戶可以每日使用的產(chǎn)品。
●??????關(guān)鍵成果(Key Results):
○??????日活躍用戶量為XX;
○??????使用XX方式,提高XXX核心指標;
第三步,項目管理——控進度:
目標設(shè)定以后,非常重要的就是執(zhí)行,一般的項目管理實際上就是控制進度。
1.????任務(wù)/進度勤同步。整個公司所有人的?calender,包括會議、要做的事情、項目的時間節(jié)點都需要及時同步。在整個戰(zhàn)略布局上,如果某個項目工期非常緊,就必須進行更多的溝通,確保每一個環(huán)節(jié)都沒有問題。
2.????站立會議?(Daily Sync):每天進行站立會議,一般控制在十分鐘之內(nèi),每個人說明自己今天要做的工作,需要什么幫助,有誰可以幫忙,可以更有效的調(diào)節(jié)資源和攻關(guān)。 3.????多方位溝通(Google Docs / Gmail / Hangouts):對非緊急的事情,兩個團隊或者是兩個人一起討論所有的設(shè)計。Hangouts用于做快速響應(yīng)。? ? 4.????周會(Weekly Report):每周總結(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)品的假設(shè)、方向等。 第四步,人員管理——帶團隊: 項目是由一個個具體的人來執(zhí)行的,所以帶團隊非常重要,在人員管理上,豌豆莢有三個基本原則: 1、Re-Organization &?換組:公司鼓勵員工換組,每個人都有機會到喜愛的團隊做更有趣的事情。只要在原團隊的績效合格,每季度都可申請換團隊或換工作內(nèi)容。員工的績效不與?OKR掛鉤,公司鼓勵員工挑戰(zhàn)難度、超越優(yōu)秀,低?Level?的事情做不到優(yōu)秀會被懲罰,做事不及格也會被懲罰。 2、One on One:在帶人方面,?One on One?非常重要。One on One?指的是每個團隊的manager?需要定期(最佳間隔是每周一次)與自己團隊中的每個成員進行一對一討論或者對話。在豌豆莢,manager?首先是一個教練,應(yīng)該幫助自己團隊的成員成長。通過?One on One,manager?需要了解每個團隊成員現(xiàn)階段的狀態(tài)和遭遇的困擾,分享職業(yè)規(guī)劃,幫助他們正確地處理問題,更好地實現(xiàn)個人成長。 3、個人?OKR?和?Performance?體系:每個員工在每個季度初需要確定自己本季度的?OKR,在一個季度結(jié)束后需要根據(jù)自己這個季度的工作完成情況給?OKR?打分。每半年公司會進行一次Performance Review,主要是?review?員工過去半年的績效,并根據(jù)?Performance Review?的結(jié)果變更?Job Ladder(業(yè)務(wù)職級)和薪酬。值得一提的是,在豌豆莢,所有的個人Performance Review?的成就內(nèi)容及級別都是全公司共享公開的,如下圖所示。這個對于很多公司來說是不可想象的,豌豆莢為什么要這么做?因為一方面對于豌豆莢來說可以做到更為公平和透明,另一方面也給每位豌豆提供了更好學習和成長自己的樣本,激勵大家在產(chǎn)品研發(fā)中更高質(zhì)量的挑戰(zhàn)和要求自己。 第五步,興趣管理——排干擾: 1、激發(fā)興趣:Hack Day,是豌豆莢一個特殊的節(jié)日,開始于2010年,類似黑客馬拉松。通常在春節(jié)假期回來的那一周,產(chǎn)品設(shè)計師和工程師們?3-5?人組成一隊,在連續(xù)48小時的時間里,充分展現(xiàn)工程團隊的創(chuàng)意和想像力,完成一些比日常開發(fā)更?geek、更有趣的東西。 豌豆莢為了鼓勵大家更好的完成挑戰(zhàn),也會設(shè)計一些特別有特色的獎品,歷史上?2012?年提供的是蘋果剛出?Macbook Retina,2013?年是?Google Glass,2014?年則是程序員最愛的Herman Miller?頂級座椅。 在歷史的?Hackday?中,有不少作品最終都成了重要產(chǎn)品對外發(fā)布,比如?MUCE、豌豆洗白白和?IAS(應(yīng)用內(nèi)搜索),都成為了豌豆莢極具特色的產(chǎn)品。 2、控制興趣:Polish Week,讓公司慢下來,對已有產(chǎn)品的細節(jié)進行精細化的過程。在大量開發(fā)和新產(chǎn)品上線的過程中,我們會擔心因為走得太快而對產(chǎn)品的細節(jié)關(guān)注不夠。在連續(xù)3個工作周后,第4周通常是?Polish Week。在?Polish Week?的這一周,豌豆莢內(nèi)部不會進行新產(chǎn)品或新功能的開發(fā),而主要是對現(xiàn)有的產(chǎn)品和服務(wù)進行打磨,解決一些細節(jié)問題和小?bug,譬如產(chǎn)品內(nèi)一些字體的統(tǒng)一等等。平均每個?Polish Week?會解決產(chǎn)品中各種?Bug?大約?200?個。 二、高效研發(fā)的流程和工具 過去幾年豌豆莢做?Windows?版的時候,嘗試過一個月、兩個月、一個星期、兩個星期的發(fā)布節(jié)奏,整個模式跟?Chrome?比較像,有功能發(fā)布就希望盡早的發(fā)。我們在服務(wù)端上每天都有更新,客戶端會慢一點,現(xiàn)在大概是兩周一個版本,如下圖所示: 在開發(fā)節(jié)奏上,前兩周的時間用于開發(fā),然后截取分支準備發(fā)布,接下來兩周進行測試,同時進行另一個開發(fā),每一個迭代都控制在兩周之內(nèi)。相對而言,服務(wù)端的發(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)。為了解決這個問題,首先在操作層面上一開始先用一個月的迭代來讓大家適應(yīng),同時要求?Master?分支必須是可用的(比如某人提交了代碼跑不起來,或者沒有經(jīng)過測試,給其他同事帶來了阻礙,就會被要求請全團隊喝咖啡)。其次加強單元測試和回歸測試,確保每個迭代的研發(fā)質(zhì)量是可控的,后面的測試主要是回歸和校驗,減輕相互重疊的壓力問題。一個月的迭代跑順了之后,再跑到兩周、一周的節(jié)奏,整體來看,差不多用了半年的時間,豌豆莢就完全跑順了這個流程,想快可以快,想慢也可以慢。
轉(zhuǎn)載自:互聯(lián)網(wǎng)分析沙龍
贊,現(xiàn)在OKR、敏捷開發(fā)等管理理念在研發(fā)團隊中普及率越來越高啦,可以用Worktile這類研發(fā)管理工具去落地