DevOps|高效能敏捷交付組織:特性團隊(FeatureTeam)+Scrum

2022-10-19 06:02:00

這是《研發效能組織能力建設》的第三篇。特性團隊和Scrum,這兩個定義我們在之前的文章中都詳細介紹了。這兩個組織模式或者說管理實踐,我都用過所以有些時候特別有感觸。書本上純粹的模式很容易理解,但是具體工作中運用這是非常考驗團隊和人的,尤其是涉及到考核和彙報的關係就會很複雜。本篇文章主要來嘮嘮我實際使用時的感受和理解。

特性團隊定義

特性團隊是一個長期穩定、跨職能跨元件、持續端到端交付使用者價值的團隊。

 

Scrum 定義

Scrum是一個用於開發和維護複雜產品的框架,是一個增量的、迭代的開發過程,目的是讓開發人員像打橄欖球一樣迅猛並充滿激情,通過團隊合作,提高工作效率。通過團隊間的有效互動,為企業創造價值。

 

不確定性的世界

簡單地總結下Scrum的合作模式是:PO負責計劃、定義功能、驗收產出,Scrum Master 負責流程,Team 負責實現。如果真這樣去用,會不會有啥問題?對於日常的工作這樣安排沒有問題,但是對於非「按部就班」的事如何解決呢?放到產品代辦列表中?PO去跟進?還是Scrum Master 去跟進?重視團隊績效而不是個人績效,所有人都同一個係數還是各不相同?同一個係數,摸魚的無所謂,拼命的的肯定受委屈。如果幹多幹少一個樣幹好幹壞一個樣以後有事誰還往前衝?定義是一方面,真的帶團隊做事情每天遇到「雞毛蒜皮」「柴米油鹽醬醋茶」的事情太多太多。我們不是在象牙塔裡,我們要在複雜的世界中前行,所以這些非「按部就班」的事需要有人負責。這也就是特性團隊提倡的要以一種「全職能」的團隊去應對各種不確定。

各司其職+相互配合

為了追求效率最大化,各種分工越來越細,術業有專攻。每個人都在忙範圍劃定、能力所及的事,總感覺這不是一個「Team」,而是「迎面喊聲兄弟借個火」的路人。可以說這是一個鬆散的,靠自願、靠興趣來驅動的組織。

人都是有惰性的,團隊壓力小還能相安無事。真想做出點事情,壓力一大,工作任務多,需要每個人有更多承擔的時候就會出現問題。不是說自組織麼?不是說自領任務麼?本質是Scrum 這種模式在人員素質高、工作壓力不大,人員設定充足,分工合理的企業還能進行得下去,比如外企。因為很多外企在國內的部分都是成本中心,通常也不會有營收目標,你好我好大家好。但是對於很多還處在生死線上的企業是否合適?我自己感覺靠興趣,靠影響力去驅動是不靠譜的。在公司裡就要專業一些,職業一些。

PO,SM和Team 這三個「腦袋」驅動整個團隊向前走,但有點問題就會非常內耗。能同時影響這三頭「豬」的人是誰?如果是一隻「雞」還好,往往還是好幾只「雞」。這些「雞」不在團隊裡,平時也不參加各種會議,只是偶爾聽下彙報,但是卻考核團隊裡的「豬」。這隻「雞」不在團隊裡卻對團隊效能影響很大。

Scrum 帶來了流程,還帶來了「各司其職、人盡其才」, 給我們帶來一個按照規範流程做事情的組織;但三股碎麻無大用,要擰成繩才能提千斤鼎。對於公司也一樣,公司的訴求也不是一個照本宣科的 scrum 團隊,而是一個能拿結果、高效能的「特種部隊」。

特種部隊也得卷

西方發達國家依靠先發優勢,掌握了大量先進的科學技術,即便是歐洲小國,也可以依靠一兩樣先進技術或者不錯的產品賺大錢,過上富裕、安逸的生活。公司裡面的人也不用那麼拼命,按部就班的工作,很多人喝喝咖啡閒聊幾句就是一天,只要公司裡有一部分在努力工作,公司就能活的很好。

而我們不行,我們還處在產業鏈的低端,還在攀登科技高峰的途中,我們要想爬上金字塔的頂端,光靠「按部就班」的工作是活不下去的。所以造成了國內的公司和團隊都很拼,都很「卷」。好像這一點說得有點遠了,但的確在那裡。

「卷」也不是一無所獲。打工賺錢來的,談錢不寒磣。「三個人幹五個人的活拿四個人的錢」。如果沒有更多的收穫,我覺得不應該卷。實際上很多團隊並不是在「卷」,而是「乾耗」。加班很多卻沒有收穫沒有成果,這種「乾耗」是應該抵制的。純乾耗不如早下班。

有價值有產出的團隊

對於公司內的團隊,底線就是要有價值有產出,在可預期的時間內拿到預期的效果;對於個人來說,經過一段時間能有所收穫(知識、技能和收入)。而這所有的一切都需要產出的保障。而要做到這些,首先要選對一個有價值的方向,其次團隊在這個方向上要做出有價值的產出。

這個「有價值的方向」公司會有一定的考慮,在團隊建立之初其實公司是有預期的,雖然可能很籠統、概括。因為能在一個更高的維度看到存在的問題,有解決這些問題的訴求,也有一定的經驗或者掌握了一些資訊,所以才要成立相應的團隊來解決。大方向是有的,但是還是要靠具體團隊來落實。也就是說團隊成立之初是有價值的。但是團隊具體有多大價值,要靠團隊來證明。那麼一個高效能的團隊就是證明其價值的有力保障。

高效能團隊

一個對領域有深刻理解,同時能帶領團隊拿到結果的 FTO 是關鍵。這樣的人只要授權他,同時給予資源就能取得很好的結果。

聚起一隊「跨職能、持續閉環交付使用者價值」的 FT Memeber是根本。各司其職、人盡其才的同時還要有主人翁意識(ownership),能自驅,能補位。至於一些具體的流程、做法,相對反而不那麼重要。團隊正向運轉起來,這些問題自然會迎刃而解。

所以,我心目中的高效能團隊是一個可以持續完成一個個高優先順序任務的「特種部隊」,團隊內部職能、職責清晰,同時儘可能地閉環。這樣可以順暢溝通,高效協同,持續地端到端交付使用者價值。

期待&總結

成立一個高效能敏捷的團隊不難,難的是我們有時候人為破壞它。一個團隊從形成到高效能有一個form-storm-norm-perform 的過程,頻繁的組織變更會讓團隊長期處於動盪,這也就是為什麼特性團隊要強調「長期、穩定」。FTO 對團隊的產出至關重要。兵熊熊一個,將熊熊一窩。我見過很多特別優秀的FTO,也見過瞎整的FTO。向社會「輸送一兩個人才」「讓一兩個隊員畢業」「把一兩股寒氣傳給其他人」,不如向社會輸送一個 FTO。當然對於做出成績的 FTO,我們也要不加吝嗇的給予掌聲和獎勵。希望各位都能找到自己心目中的「高效能團隊」做出一番事情。

 

更多閱讀

感謝點贊、轉載
關注我,瞭解最新研發效能發展動向
歡迎進入「DevOps研發效能群」一起探討