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

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

一、團隊效能本質仍是人心問題

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

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

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

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

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

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

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

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

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

我把整個過程總結成下圖這個循環。

二、共識目標，規劃資源

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

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

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

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

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

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

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

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

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

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

三、培養習慣，穩定交付

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

具體的做法是一個個的戴明循環，現在互聯網圈里又稱敏捷迭代。

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

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

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

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

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

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

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

四、共同回顧，自驅進步

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

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

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

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

五、總結

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

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