如何高效地提升團隊效能？在進行團隊管理之前，你可能需要認清效能問題的本質(zhì)是什么，進而再搭建提升團隊效能的策略。那么，提升業(yè)務團隊的效能，可以遵循哪些步驟？本篇文章里，作者結(jié)合實戰(zhàn)經(jīng)驗做了總結(jié)分享，一起來看。

效能問題表面上看是一個團隊產(chǎn)能問題，但根據(jù)近一年的實踐經(jīng)驗，并非這么簡單，以下談談我對技術(shù)團隊效能的理解和管理的一些方法。

一、團隊效能本質(zhì)仍是人心問題

市面上最近都在談研發(fā)效能度量，研發(fā)效能度量/價值度量一直以來都是一個難題，因為對于絕大多數(shù)公司來說，研發(fā)和業(yè)務就是綁定的，公司通常都只談業(yè)務價值而不談技術(shù)價值，研發(fā)團隊是成本中心。

舉個例子，微信研發(fā)團隊在10億日活用戶的用戶量下把支付功能的可用率做到了99.9999999%，業(yè)務覺得這是理所應當?shù)?，要不然研發(fā)就是拖后腿，但實際上對于技術(shù)來說這是件很難的事。整個公司層面看數(shù)據(jù)的時候，只看交易筆數(shù)、交易金額、交易傭金，并不看支持功能的可用率。

真讓研發(fā)來講價值，也挺尬的，上價值上高度是研發(fā)同學非常不擅長的事，所以每次給機會給研發(fā)同學，研發(fā)同學也很難講得清楚自己的價值，技術(shù)只是創(chuàng)造了一些可能性，不好衡量這些可能性的價值，沒有業(yè)務收入、成本這些來的直接。

在這些因素的加持下，技術(shù)團隊就變成了一個玄學部門，有點食之無味棄之可惜的意思，沒有這個團隊或者大規(guī)模削減預算吧，好像又不太行，到時候系統(tǒng)各種出問題用戶不干了，但到底應該投多少資源呢，技術(shù)團隊到底創(chuàng)造了多大的價值呢，怎么衡量技術(shù)團隊的好壞呢，玄之又玄。

所以后來就開始講技術(shù)交付，意思就是技術(shù)側(cè)在多大程度上支撐了業(yè)務的發(fā)展，相關(guān)指標有需求交付比例等。再后來又看團隊效能，意思就是技術(shù)側(cè)到底干了多少活，干得多快多好，慢慢地技術(shù)側(cè)陷入了一種自卷的狀態(tài)。

在預算層面，也只能參考同行保障一定營收百分比的預算投入，對外則宣稱持續(xù)保障對技術(shù)的投入，實則根本不知道應該加大還是縮小，或者說加大技術(shù)投入并不一定能帶來相應的回報。

在以上這些混亂的局面下，讓我來談對于產(chǎn)研團隊效能的理解。

我理解這還是一個人心問題，在技術(shù)價值無法直接貨幣化的情況下如何讓大家認可你的價值、認可技術(shù)團隊花的這些錢。

再具體一點講，是如何打造一支具有戰(zhàn)斗力的團隊、如何提升業(yè)務對于技術(shù)的信心、如何讓團隊感受到自我的價值的問題。這個過程中需要一半Manager的基礎(chǔ)能力，一半Leader的個人魅力。

我把整個過程總結(jié)成下圖這個循環(huán)。

二、共識目標，規(guī)劃資源

在大公司里非常容易出現(xiàn)的一個問題是業(yè)務產(chǎn)品研發(fā)的規(guī)劃脫節(jié)，因為各個角色做規(guī)劃的時候下意識地認為自己做規(guī)劃就好，下游理應配合自己完成工作，最后發(fā)現(xiàn)天天都有預期外的資源協(xié)調(diào)項目延期之類的幺蛾子。

上下游之間應該共識目標，把各自的目標變成共同的目標，這個過程跟做預算有點像，有興趣的同學可以去了解下公司做預算的過程，本文就講講產(chǎn)品和研發(fā)之間怎么去做目標共識。

在《B端產(chǎn)品規(guī)劃一攬子工具》一文中已經(jīng)講了產(chǎn)品怎么去做年度、季度、雙周迭代的規(guī)劃，這里不再贅述。

研發(fā)規(guī)劃其實也是一樣的道理，需要有自己年度、季度的規(guī)劃。在季度初，需要產(chǎn)品研發(fā)一起開一個統(tǒng)戰(zhàn)會，全員參加，會前大家把自己認為應該在這個季度做的事寫在一張清單上，會上大家用標準的STAR來闡述「在什么背景下，要解決什么問題，需要做哪些事，預期能實現(xiàn)哪些提升或改善」。

這個過程通常要持續(xù)一個小時左右，過程中還要確定每個任務的負責人、優(yōu)先級，其他異常問題都可備注出來，例如需要大量研發(fā)資源、需要8月30號上線。

這個環(huán)節(jié)大家就都清楚接下來一個季度要干什么了，然后肯定會有資源不足的問題，那么就需要砍需求。

怎么砍呢，按照優(yōu)先級把列表排序下，由各個任務的負責人與組長一起評估資源夠不夠，把明顯資源不足且優(yōu)先級低的事劃掉，把重要但資源不太充足的需求標出來。這個過程通常持續(xù)二十分鐘左右，其實就是所有人來領(lǐng)活，并且自己主動評估工作飽和度。

然后是所有人一起review這張表，再次共識那些一定要保障的需求和被干掉的需求。對于那些資源不夠的需求，要求需求提出人縮減需求范圍，先實現(xiàn)需求的一部分，并且排出一個大家共同認可的優(yōu)先級，此后有資源沖突，大家可以自行根據(jù)這張表調(diào)整資源分配。這個會給組長很多待辦：

• 敲定會議上的一些爭議點；
• 去找大家都認為應當補充的資源，找不到資源還得再砍任務；
• 一些復雜的任務需要消除風險，做一些預研性的工作；
• 最最重要的是找上下游共識工作項，伺候好上游知曉下游。

其實這張表排完之后資源肯定還是不足的，之后還會砍，但是大家就有一個共識，就是這個活是相互認可的，是業(yè)務你認為有價值的活，是產(chǎn)品研發(fā)測試一起要干的活，咱們是綁定的。

三、培養(yǎng)習慣，穩(wěn)定交付

如果把「統(tǒng)戰(zhàn)會」理解為工廠生產(chǎn)產(chǎn)品的排產(chǎn)過程，那么之后的一個季度時間里就是生產(chǎn)的過程，如果產(chǎn)能不穩(wěn)定，那么就無法按承諾交付，接著就影響銷售運營等上下游，團隊產(chǎn)能也會越來也差，行為自由散漫，進入一個惡性循環(huán)。所以一定要花時間培養(yǎng)產(chǎn)研團隊按承諾交付的習慣。

具體的做法是一個個的戴明循環(huán)，現(xiàn)在互聯(lián)網(wǎng)圈里又稱敏捷迭代。

敏捷迭代強調(diào)的是每個迭代周期（兩周或三周）都能交付一些東西，可以是一個需求的技術(shù)設計方案，也可以是一個功能點的上線。每個迭代內(nèi)的任務在迭代第一天就確定了（需求清單），并需要進一步做任務拆解和排期，形成團隊的迭代任務看板。每個迭代還需要有個迭代日歷，明確各角色關(guān)鍵任務的截止日期。

配合迭代日歷要開的會是迭代回顧會，大家一起看看這個迭代有哪些做的好的地方，哪些地方需要改善。配合任務看板要開的會是每日站會，檢查每日任務的完成情況。在每日站會和回顧會上追問為什么任務延期，為什么沒有報風險，為什么沒有按承諾交付，同時強調(diào)這不是指責大家、不是push大家，而是要大家非常負責任地評估工作量、盡力按承諾完成任務。

團隊一開始會因為這種壓力變得不敢承諾，看起來團隊產(chǎn)品是下降了。但是經(jīng)過一兩個迭代，團隊成員發(fā)現(xiàn)自己是能按承諾交付的，并且對自己的能力和工作越來越了解，這個時候就要開始鼓勵大家敢于承諾、努力實現(xiàn)承諾。

在大家都唯唯諾諾不敢承諾的時候，找那種明顯敢于承諾并實現(xiàn)的承諾的人來樹典型，在回顧會上鼓勵或嘉獎；或者適當拔高團隊成員自己立的目標，利用痛點問題的急迫性引導大家主動承接任務。整體研發(fā)產(chǎn)能就能開始逐漸釋放，并且這是穩(wěn)定的產(chǎn)能。

這種狀態(tài)需要保持三四個迭代，鞏固大家的信心。這個時候就很舒服了，你想要的東西在預期時間就一定能交付，剩下就交給時間了。

正常都會想再提一提團隊的產(chǎn)能，但是我個人的經(jīng)驗是不要去挑戰(zhàn)人性，如果把大家壓的很厲害的話雖然看起來產(chǎn)能是高了，但團隊凝聚力戰(zhàn)斗力是往下走的，真有什么事兒沒人愿意出來給你頂起來。所以只能是每個迭代用一兩個確實非常有使命感有價值的事來讓大家挑戰(zhàn)產(chǎn)能，把團隊對于你的信任用在最關(guān)鍵的地方。

一個有穩(wěn)定交付能力的產(chǎn)研團隊自然而然會慢慢贏得上下游合作伙伴的信任。但僅僅是按承諾交付、穩(wěn)定輸出，只是讓大家對于自己工作能力有一個認知，還是沒有自我價值的認同，沒有自我激勵效應。

四、共同回顧，自驅(qū)進步

想要構(gòu)建前文中提到的激勵正循環(huán)，還需要采取一些手段。這里我采取的是上游激勵下游的方式，產(chǎn)研的上游有業(yè)務、運營、用研等部門，拉上每個部門的接口人一起開個產(chǎn)品回顧會，大概就是茶話會的形式，讓各個部門來講講功能上線前后他們工作的變化。

例如讓運營來講講功能上線前后他們工作感受的變化、相關(guān)運營指標的變化，以及未來期望產(chǎn)研做哪些功能；讓業(yè)務講講收入和成本的變化，以及做哪些事能更好地幫助業(yè)務創(chuàng)收降本；讓用研部門講講用戶行為和體驗的變化，做哪些事情能進一步提升用戶體驗。

一開始開這種會的時候研發(fā)可能是無感的，因為他們并不care產(chǎn)品如何業(yè)務如何了，但在「培養(yǎng)習慣，穩(wěn)定交付」這個部分，研發(fā)都越來越負責、越來越投入的時候，他們自然而然會在這個會上感受到「我是被需要的，我的工作是有價值的，我應該做點什么去解決用戶的問題」。

這個會的待辦就是產(chǎn)研團隊每個人去列出自己認為接下來應該做的事，跟第一章節(jié)「共識目標，規(guī)劃資源」形成閉環(huán)。

五、總結(jié)

總的來說，提升效能最終是要提升上游對于你團隊的信心，否則效能再高都會被挑戰(zhàn)。除了上文說到的常規(guī)管理手段外，其實還需要個人魅力和價值創(chuàng)造。

個人魅力體現(xiàn)在團隊凝聚力和上下游對你的信心上，而價值創(chuàng)造則是基石，如果不能扎扎實實創(chuàng)收降本，那么管理做得再好也白搭。但價值創(chuàng)造這塊我自己都沒想明白整個運作體系，等想明白了再跟大家分享。