團隊效能管理,沒那麼簡單
如何高效地提升團隊效能?在進行團隊管理之前,你可能需要認清效能問題的本質是什麼,進而再搭建提升團隊效能的策略。那麼,提升業務團隊的效能,可以遵循哪些步驟?本篇文章裡,作者結合實戰經驗做了總結分享,一起來看。
效能問題表面上看是一個團隊產能問題,但根據近一年的實踐經驗,並非這麼簡單,以下談談我對技術團隊效能的理解和管理的一些方法。
一、團隊效能本質仍是人心問題
市面上最近都在談研發效能度量,研發效能度量/價值度量一直以來都是一個難題,因為對於絕大多數公司來說,研發和業務就是繫結的,公司通常都只談業務價值而不談技術價值,研發團隊是成本中心。
舉個例子,微信研發團隊在10億日活使用者的使用者量下把支付功能的可用率做到了99.9999999%,業務覺得這是理所應當的,要不然研發就是拖後腿,但實際上對於技術來說這是件很難的事。整個公司層面看資料的時候,只看交易筆數、交易金額、交易佣金,並不看支援功能的可用率。
真讓研發來講價值,也挺尬的,上價值上高度是研發同學非常不擅長的事,所以每次給機會給研發同學,研發同學也很難講得清楚自己的價值,技術只是創造了一些可能性,不好衡量這些可能性的價值,沒有業務收入、成本這些來的直接。
在這些因素的加持下,技術團隊就變成了一個玄學部門,有點食之無味棄之可惜的意思,沒有這個團隊或者大規模削減預算吧,好像又不太行,到時候系統各種出問題使用者不幹了,但到底應該投多少資源呢,技術團隊到底創造了多大的價值呢,怎麼衡量技術團隊的好壞呢,玄之又玄。
所以後來就開始講技術交付,意思就是技術側在多大程度上支撐了業務的發展,相關指標有需求交付比例等。再後來又看團隊效能,意思就是技術側到底幹了多少活,幹得多快多好,慢慢地技術側陷入了一種自卷的狀態。
在預算層面,也只能參考同行保障一定營收百分比的預算投入,對外則宣稱持續保障對技術的投入,實則根本不知道應該加大還是縮小,或者說加大技術投入並不一定能帶來相應的回報。
在以上這些混亂的局面下,讓我來談對於產研團隊效能的理解。
我理解這還是一個人心問題,在技術價值無法直接貨幣化的情況下如何讓大家認可你的價值、認可技術團隊花的這些錢。
再具體一點講,是如何打造一支具有戰鬥力的團隊、如何提升業務對於技術的信心、如何讓團隊感受到自我的價值的問題。這個過程中需要一半Manager的基礎能力,一半Leader的個人魅力。
我把整個過程總結成下圖這個迴圈。
二、共識目標,規劃資源
在大公司裡非常容易出現的一個問題是業務產品研發的規劃脫節,因為各個角色做規劃的時候下意識地認為自己做規劃就好,下游理應配合自己完成工作,最後發現天天都有預期外的資源協調專案延期之類的么蛾子。
上下游之間應該共識目標,把各自的目標變成共同的目標,這個過程跟做預算有點像,有興趣的同學可以去了解下公司做預算的過程,本文就講講產品和研發之間怎麼去做目標共識。
在《B端產品規劃一攬子工具》一文中已經講了產品怎麼去做年度、季度、雙週迭代的規劃,這裡不再贅述。
研發規劃其實也是一樣的道理,需要有自己年度、季度的規劃。在季度初,需要產品研發一起開一個統戰會,全員參加,會前大家把自己認為應該在這個季度做的事寫在一張清單上,會上大家用標準的STAR來闡述「在什麼背景下,要解決什麼問題,需要做哪些事,預期能實現哪些提升或改善」。
這個過程通常要持續一個小時左右,過程中還要確定每個任務的負責人、優先順序,其他異常問題都可備註出來,例如需要大量研發資源、需要8月30號上線。
這個環節大家就都清楚接下來一個季度要幹什麼了,然後肯定會有資源不足的問題,那麼就需要砍需求。
怎麼砍呢,按照優先順序把列表排序下,由各個任務的負責人與組長一起評估資源夠不夠,把明顯資源不足且優先順序低的事劃掉,把重要但資源不太充足的需求標出來。這個過程通常持續二十分鐘左右,其實就是所有人來領活,並且自己主動評估工作飽和度。
然後是所有人一起review這張表,再次共識那些一定要保障的需求和被幹掉的需求。對於那些資源不夠的需求,要求需求提出人縮減需求範圍,先實現需求的一部分,並且排出一個大家共同認可的優先順序,此後有資源衝突,大家可以自行根據這張表調整資源分配。這個會給組長很多待辦:
- 敲定會議上的一些爭議點;
- 去找大家都認為應當補充的資源,找不到資源還得再砍任務;
- 一些複雜的任務需要消除風險,做一些預研性的工作;
- 最最重要的是找上下游共識工作項,伺候好上游知曉下游。
其實這張表排完之後資源肯定還是不足的,之後還會砍,但是大家就有一個共識,就是這個活是相互認可的,是業務你認為有價值的活,是產品研發測試一起要乾的活,咱們是繫結的。
三、培養習慣,穩定交付
如果把「統戰會」理解為工廠生產產品的排產過程,那麼之後的一個季度時間裡就是生產的過程,如果產能不穩定,那麼就無法按承諾交付,接著就影響銷售運營等上下游,團隊產能也會越來也差,行為自由散漫,進入一個惡性迴圈。所以一定要花時間培養產研團隊按承諾交付的習慣。
具體的做法是一個個的戴明迴圈,現在網際網路圈裡又稱敏捷迭代。
敏捷迭代強調的是每個迭代週期(兩週或三週)都能交付一些東西,可以是一個需求的技術設計方案,也可以是一個功能點的上線。每個迭代內的任務在迭代第一天就確定了(需求清單),並需要進一步做任務拆解和排期,形成團隊的迭代任務看板。每個迭代還需要有個迭代日曆,明確各角色關鍵任務的截止日期。
配合迭代日曆要開的會是迭代回顧會,大家一起看看這個迭代有哪些做的好的地方,哪些地方需要改善。配合任務看板要開的會是每日站會,檢查每日任務的完成情況。在每日站會和回顧會上追問為什麼任務延期,為什麼沒有報風險,為什麼沒有按承諾交付,同時強調這不是指責大家、不是push大家,而是要大家非常負責任地評估工作量、盡力按承諾完成任務。
團隊一開始會因為這種壓力變得不敢承諾,看起來團隊產品是下降了。但是經過一兩個迭代,團隊成員發現自己是能按承諾交付的,並且對自己的能力和工作越來越瞭解,這個時候就要開始鼓勵大家敢於承諾、努力實現承諾。
在大家都唯唯諾諾不敢承諾的時候,找那種明顯敢於承諾並實現的承諾的人來樹典型,在回顧會上鼓勵或嘉獎;或者適當拔高團隊成員自己立的目標,利用痛點問題的急迫性引導大家主動承接任務。整體研發產能就能開始逐漸釋放,並且這是穩定的產能。
這種狀態需要保持三四個迭代,鞏固大家的信心。這個時候就很舒服了,你想要的東西在預期時間就一定能交付,剩下就交給時間了。
正常都會想再提一提團隊的產能,但是我個人的經驗是不要去挑戰人性,如果把大家壓的很厲害的話雖然看起來產能是高了,但團隊凝聚力戰鬥力是往下走的,真有什麼事兒沒人願意出來給你頂起來。所以只能是每個迭代用一兩個確實非常有使命感有價值的事來讓大家挑戰產能,把團隊對於你的信任用在最關鍵的地方。
一個有穩定交付能力的產研團隊自然而然會慢慢贏得上下游合作伙伴的信任。但僅僅是按承諾交付、穩定輸出,只是讓大家對於自己工作能力有一個認知,還是沒有自我價值的認同,沒有自我激勵效應。
四、共同回顧,自驅進步
想要構建前文中提到的激勵正迴圈,還需要採取一些手段。這裡我採取的是上游激勵下游的方式,產研的上游有業務、運營、用研等部門,拉上每個部門的介面人一起開個產品回顧會,大概就是茶話會的形式,讓各個部門來講講功能上線前後他們工作的變化。
例如讓運營來講講功能上線前後他們工作感受的變化、相關運營指標的變化,以及未來期望產研做哪些功能;讓業務講講收入和成本的變化,以及做哪些事能更好地幫助業務創收降本;讓用研部門講講使用者行為和體驗的變化,做哪些事情能進一步提升使用者體驗。
一開始開這種會的時候研發可能是無感的,因為他們並不care產品如何業務如何了,但在「培養習慣,穩定交付」這個部分,研發都越來越負責、越來越投入的時候,他們自然而然會在這個會上感受到「我是被需要的,我的工作是有價值的,我應該做點什麼去解決使用者的問題」。
這個會的待辦就是產研團隊每個人去列出自己認為接下來應該做的事,跟第一章節「共識目標,規劃資源」形成閉環。
五、總結
總的來說,提升效能最終是要提升上游對於你團隊的信心,否則效能再高都會被挑戰。除了上文說到的常規管理手段外,其實還需要個人魅力和價值創造。
個人魅力體現在團隊凝聚力和上下游對你的信心上,而價值創造則是基石,如果不能紮紮實實創收降本,那麼管理做得再好也白搭。但價值創造這塊我自己都沒想明白整個運作體系,等想明白了再跟大家分享。
本文由 @彬哲 原創釋出於人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基於CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。
給作者打賞,鼓勵TA抓緊創作!
- 為什麼你的東西越貴越好賣?
- 初創公司如何建立持續增長私域?流量圍繞公司,使用者經營圍繞公司
- 如何用產品思維去優雅地“拒絕”?
- 產品運營那50件事兒(5):如何做好客戶資產的反饋機制?
- 如何以用例驅動設計,寫出更高質量的PRD?
- 來談談,如何用程式設計師思維服務設計
- 下載量Top 1的內容社交軟體 —— TikTok產品分析&競品分析
- SaaS產品增效 | 小程式類產品設計方法探索
- 倉儲物流機器人:快倉、海柔創新“極速前進”
- 提升使用者分享率的N個套路(上),讓你睡覺的時候使用者依然增長
- 初創公司使用者定位的“域態經營”,解決從0~1轉入經營的問題
- 電商平臺首頁搜尋功能互動設計研究
- PM基本功 | 如何製作一個屬於自己的Axure元件庫
- 智慧汽車的產品體驗和創新
- “直播電商”帶貨場景分析
- 購票加速包能加速?買個心安罷了
- 如何為未來的車設計HMI?
- 內容創業公司到底管人還是管內容?“沙盤概念”經營你的公司
- 內容創業做培訓,必然失敗:在使用者需要當中活下去
- 設計問題中的不確定性