自組織的鐵三角關係

weixin_33763244發表於2017-03-13
\

要點

\
  • 瞭解自組織是什麼,為何它很重要 \
  • 在團隊中正確實現自組織的三大關鍵要素 \
  • 如何使用這些要素實現所需的結果 \
  • 如何將其運用在敏捷方法中 \
  • 如何自組織用作一種管理工具
\

自組織團隊這種想法已成為管理複雜工作所用到現代化方法的核心。該方法可用於鞏固所有敏捷方法,以及諸如Holacracy等企業治理所採用的新方法。\

然而自組織這個概念經常被誤解為某種“無政府主義”,如果就此聽之任之,甚至不需要任何關注或引導,確實會造成這樣的結果。實際上如果希望在群體內部實現行之有效的自組織,需要有人為群體成立所抱有的目的提供支援,推動群體變成一個團隊,不過這首先要滿足一定的條件。\

自組織鐵三角確立了最重要的三類條件,如果希望成功地將自組織用作一種管理工具,必需妥善處理這些條件。最初我建立這個模型是用作教學工具的,希望能通過形象的方式向學生們強調“鐵三角”所包含要素的重要性。然而後來發現如果要與自組織團隊合作,還可以將該模型用在實踐中,確保可以順利確定所有要素,進而獲得所需結果。\

模型

\

自組織鐵三角包含三個重要條件,能對群體的自組織產生極大影響。很多組組織團隊主要是通過分別管理鐵三角的不同要素間接實現的。\

如果缺少任何一個要素,自組織就無法實現(意味著群體不會開始討論從事工作/行為的方法,工作可能完全無法完成,或只能由群體中的個別人完成),或只能以不希望的方式實現(通常位於自組織公司內的員工會抗拒管理層的命令和控制,集體遊戲中的獎金計劃就是一個典型的例子)。\

鐵三角的三個要素分別是:目標規則,以及張力。下文將詳細介紹。\\

5d05c665ad215698a4ec2c6b4132a312.jpg

\\\\

圖1:自組織鐵三角\

首先最重要的是,必須要有一個群體中每個人都瞭解的明確目標。這個目標決定了群體進行自組織的具體方式:不同目標需要人們應用不同的技能和方法。存在一個共同的目標,這也是群體和團隊的主要差異,如果希望讓群體變為團隊,那麼必需通過一個目標將大家緊密聯絡在一起。\

理想情況下,這個目標應該有吸引力,群體中的所有成員需要願意實現它。目標可以是“含蓄”的,但如果能明確提出,讓所有成員知道並使用者,往往能獲得更好的效果。如果群體位於一個共同的物理空間內,那麼更好的做法是將目標公示在某個位置,確保所有人都能看到並瞭解。\

越簡明扼要的目標往往能獲得越好的效果,這樣的目標更好記,更易於理解,因而也就更吸引人。\

第二個要素是組員必需遵守的一系列規則。這些規則可以通過對群體進行治理實現所定義的目標,可將其理解為整個群體需要遵守的“必須……”和“嚴禁……”。具體規則因不同情況而異,並且與目標一樣,規則可以是“含蓄”的,但最好能進行公示。大部分情況下,這些規則會來自群體運營過程中所處的組織脈絡。例如技術標準或組織所採用的某種方法論中定義的規則施加給群體的結果就是很好的例子。隨後群體可以自行新增為了實現目標所需的額外規則。\

與目標類似,規則也應儘可能少並且保持簡單。太多或太複雜的規則很容易被部分或全部成員忽略。\

最後,第三個要素是張力(我有時甚至會將其稱之為壓力),這是一種短期激勵,可以告訴大家群體成員為何應該儘可能實現自組織的團隊,進而主動促進目標的實現,而不應被動等待。\

通常時間的壓力就足以推動群體發展,截止日期可以創造出足夠的張力。然而有時張力也可以來自挑戰或獎勵。\

簡而言之,為了讓群體實現自組織(並在這個過程中變成一個團隊),需要滿足三個條件:一個清晰的,被所有成員理解並遵守的目標;一系列需要被成員遵守的規則;以及敦促成員積極參與而非被動等待的張力。\

最後,我想提醒各位讀者,提供了鐵三角的三要素後,並不意味著就不再需要後續的過程或內部結構,例如由過程提供的指導,或由Scrum大師等教練提供的協助。無論過程或教練,所做的任何決策都應代表整個團隊的利益,他們需要協助團隊在規則允許的範圍內推動工作進展並最終實現目標。\

鐵三角在實踐中的應用

\

上文曾經提到,最初我所建立的鐵三角是用作教學工具的。在意識到我的很多學生認為僅僅從字面意義上理解了“自組織”之後,只要大聲地宣佈“我們已經敏捷了”,就可以產生非常神奇的效果,很多問題得以順利解決,但我希望通過一種更簡單的方式向大家介紹在我看來,這種方法的真相到底是什麼。我最初的想法是通過更直觀的方式介紹這些我所瞭解的,能夠幫助群體或團隊順利實現自組織而需要考慮的問題,藉此讓學生能從不同的視角來看待。然而很快我發現,這個模型在現實工作的實踐中也大有用處。\

通過組組織的方法指引整個團隊,主要是通過刻意應用鐵三角的不同要素,緩和地推動群體向著所需目標努力實現的。這一過程通常可由群體本身完成,例如通常可以考慮使用某種敏捷過程,或者由群體之外的管理者進行。\

先來詳細談談第一種情況,再討論第二種情況吧。第一種情況主要發生在通過自組織團隊基本原則所構建的過程開展工作的團隊身上,例如最常見的就是Scrum。\

深入研究Scrum之後你會發現,鐵三角的所有三個要素都已融入到Scrum框架中。在衝刺規劃(Sprint Planning)階段中,每個衝刺過程中,團隊會定義需要盡力實現的衝刺目標(Sprint Goal)。Scrum框架本身提供了團隊必須遵守的一系列規則,這些規則涵蓋了自組織的具體方式(“最多9人組成的跨職能專家團隊”等)以及工作方法(“完工”的定義,每日Scrums等)。該框架會提供需要團隊成員遵守的現有規則,例如整個公司都需要遵守的程式碼編寫標準等,並且會在團隊發現(也許是在衝刺回顧過程中)有必要時對其進行擴充套件。所有工作可在短期衝刺過程中完成,轉瞬即逝的衝刺和隨後對成果的審查(衝刺審閱)會提供必要的張力。換句話說,Scrum為刻意塑造的自組織方法提供了所有必要的條件,並確保通過不同衝刺所執行的活動對其進行更新和適應。這種方法的反覆使用有助於將群體變身為高績效團隊。\

對於使用看板方法(Kanban Method)的團隊,處理方法就完全不同了。這種方法也有各種規則(實際上該方法要求“所有規則必須清楚明確”),其中最明顯的當然就是WIP限制。然而這種方法不具備任何可供使用的明確“衝刺目標”(因為根本沒有衝刺),或其他類似的目標。對整個群體而言,唯一始終如一的目標是實現和優化流程所暗含的目標:以儘可能快的速度推動工作項實現進展,並始終堅守對質量的要求。通過追蹤週期時間和產量等指標,這樣的目標通常顯得更直觀,尤其是在針對某種商定或預期的績效進行追蹤時。然而要注意,這是一種過程目標,而非Scrum的“衝刺目標”那樣與產品有關的目標。\

張力也是間接的,首先來自上文提到的,實現理想“流程”的推動力和相關指標,以及每天進行的“Walk the Board”會議,團隊可以在這樣的會議中歸納總結因為任何原因卡住的工作項。\

如果從這個角度對比Kanban和Scrum,可以很清楚地瞭解為何更難以使用Kanban打造更優秀,更緊密的團隊:這個框架對目標和張力的體現並不那麼徹底。這樣做當然也是可行的,因為無論選擇哪種框架,我們都可以提供所需的三要素(舉例來說,如果團隊要構建一個軟體產品,那麼隨後的釋出目標就可以成為群體的激勵焦點),但這些要素對Kanban方法本身並非必須的。\

Holacracy是自組織一種更為複雜的應用。在Holacracy框架中,人們被組織成不同的角色圈(Circles of Roles)(並且身擔多個角色的同一人可能屬於不同的圈子)。每個圈子必須有一個意圖,並將其作為自己自組織的主要目標。短期目標可當作專案。工作成果會至少每週一次在戰術會議(Tactical Meeting)上審查,藉此提供必要的透明度和壓力(Holacracy對“張力”這個詞定義了不同的含義)。每個角色和圈子的行為是由一系列規則決定的,通常每個角色有與眾不同的規則,但可由任何人來完成,同時可由圈子所明確設定的策略加以引導。實際上還有一種特殊的角色:Secretary(祕書),這個角色負責追蹤所有規則的執行情況。每個規則可在每月進行一次的特別治理會議(Governance Meeting)上進行更改,藉此實現更高程度的自組織。圈子不僅負責管理實現目的所需的戰術,而且可以根據需要更改自己的結構和規則。\

此外鐵三角模型也可用於為希望與團隊合作並且實現自組織(而非傳統的“指出並告知”命令和控制式管理)的管理者提供指導。\

這種場景有一個很好的例子:在一個大型的群體中,使用自組織方式組建小型團隊。通常來說,這樣的大型群體無法定義自己的目標,也無法自行提供必要的規則,必須由外部實體提供這樣的東西。\

實際上這種情況也是鐵三角模型的第一個實踐運用。大約6年前,我當時在與一家希望轉型為敏捷方法的公司合作,他們希望在團隊層面的過程中實現Scrum。開發經歷面臨的挑戰在於:如何將包含28名開發者的群體劃分為4個Scrum團隊。我們並沒有試圖通過某種方式分析每個人並將其分配到某個團隊中,我建議使用自組織的方法。我們坐在一起通過簡短的討論確定了所有三要素,並寫了下來:\

  • 目標:拆分為4個Scrum團隊,共同參與X系統的工作。 \
  • 規則:a) 每個團隊成員人數不超過9人;b) 團隊不應主要側重於測試或其他技術領域,所有團隊都必須能提供Backlog中定義的功能;c) “老虎隊(Tiger team)”的成員不能拆分到同一個團隊中,所組建的每個團隊必須至少包含老虎隊的一個成員。 \
  • 張力:30分鐘內完成拆分。

就當時情況看,目標已經非常明確了,畢竟所有開發者都已經圍繞X系統(該組織其他部門使用的一種內部系統)工作了很久。所有人都參加過Scrum培訓,因此他們都知道(至少在理論上)Scrum團隊到底是什麼。培訓過後,7名志願者組成了一個團隊,通過一個附屬專案的兩次衝刺工作實踐了所學到的Scrum知識。這個團隊開始被人稱作“老虎隊”,開發經理擔心如果這個團隊繼續保持現狀,他們有關Scrum的知識將無法傳播到其他團隊。\

我們把所有開發者叫到一間會議室裡,向他們介紹我們的目標、規則,以及時間要求,隨後問他們是否有什麼問題。他們只提出了一個問題:如何解決/分配不在辦公室裡的人(原來那天正好有兩人沒在辦公室)。我們很快改變了自己的問題(問他們“你覺得這個問題該如何解決”),最後他們決定給那倆人打電話,問問他們意見,但如果這個做法未能成功,將由大家代為分配,但那兩人回來後可以自行決定是否要換個團隊。\

隨後我們設定了一個30分鐘的計數器,並與開發經理一起離開了會議室。對他來說,這個等待的過程異常艱難,他很擔心這個小實驗會失敗,到時候他只能繼續在人員資料Excel表格裡嘗試解決這個難題。當然,他的擔心都沒發生,等我們回到會議室後,大家已經商討出了一個所有人都覺得滿意的名單。\

這樣的體驗並非獨一無二的,大部分敏捷實踐者都會建議通過這種方式建立團隊(可參閱有關團隊建立的這篇文章)。但對很多管理者來說,這已然是一種全新的體驗,藉此他們生動地瞭解到自組織方法的效果,以及鐵三角在這一過程中的作用。他們瞭解到通過選取規則和目標,並應用相應的時間限制,如何能幫助整個群體規避風險(例如所有“猛虎”都在同一個團隊裡)並獲得所需結果。\

然而這個鐵三角模型也可以用在其他情況中。我本人經常在圍繞某個特定主題組建焦點研討會時使用這個模型。目前我就在針對管理者群體組建這樣的研討會,研討的主題是為何要在自己的部門實現敏捷方法,如何知道這個做法是否成功,以及如何進行度量。這個活動的預期成果是一系列客觀(或至少是主體間的)指標,可以幫助大家瞭解自己的部門到底是變得更好還是更糟。\

  • 目標:用於代表部門內部不同領域改程式度的2-3個指標。 \
  • 規則:a) 指標必須涵蓋能激勵團隊使用敏捷方法的領域;b) 必須是可度量的客觀標準,如果主要是為了收集意見(例如調查等),則必須使用適當的方法論。 \
  • 張力:時間限制為1小時30分鐘,如果群體沒能選擇出指標,則由管理委員會指定。

不同情境下的鐵三角

\

有一個需要注意的重要事項:自組織通常只能發生在某種組織情境中。自組織方法最基本的鐵三角主要關注於短期要素,需要通過這些要素讓群體以某種方式實現組織。然而也要注意,鐵三角的三大基本要素也需要其他要素的作用或支援(或者也可能不需要)。\

aa2e36708dfac1403ce8fa81c6c65b10.jpg

\

群體力圖實現的簡潔的短期目標應當根植於更長期的願景,當然,群體成員也必須知道並瞭解這樣的願景。雖然時間壓力可以立即提供必要的張力,但長期範圍內的激勵同樣重要。最後,為群體建立(或由群體建立)的規則應當與組織文化保持同步,並得到組織文化的支援。\

願景、文化,以及整體激勵方式是一個長期問題,在檢視建立自組織、自管理的團隊(以及使用敏捷方法)時,每個組織都必須加以考慮。我們經常會看到一些公司嘗試實時敏捷方法,但因為方法與現有文化和願景不符而最終失敗的情況。\

最近我回訪過的一家公司,他們有一個不怎麼有激情的團隊,但依然希望通過回顧自己過去(以及第一次)衝刺發現自己所面臨的最大挑戰,希望藉此能自行找出解決問題的方法。當我問他們具體的行動將由誰來落實時,當時的場面一度非常尷尬,他們說當然是由經理來負責了。也許他們的整個職業生涯都處在一種嚴明的等級劃分中,圍繞命令和控制的文化使得他們根本沒有意識到自己可以主動採取必要措施解決遇到的問題。實際上,一位團隊成員開始爭論說,作為員工,他們的所有工作應該由管理者來安排,在他看來這是良好管理機制的一種象徵。很明顯,他們目前的組織文化並不能有效支援敏捷方法,此時要讓團隊以高效的方式實現自組織,無疑是痴人說夢。\

結論

\

自組織是一種現代化的管理工具,取代了建立團隊時所用的命令和控制方法,可以引導團隊實現所需結果(例如有價值的產品)。為了善用這種方法,管理者和團隊必須瞭解對這一過程提供指導所需的三大基本要素:目標、規則、張力,並刻意選擇能夠幫助自己獲得預期結果的要素。為確保該方法與現有文化、願景,以及激勵方式相匹配,還需要進行周全的考慮。\

關於本文作者

\

aadc48da386594394f74864800e4ed74.jpgAndy Brandt在IT行業有25年的工作經驗,完成了很多壯舉:他是一名程式設計師,一名Unix系統管理員,是培訓講師,是Linux佈道師,是分析師,是專案經理(兼PMP),是直線經理(Line manager),同時也是Scrum大師以及軟體開發初創公司的創始人。他早在2005年就開始從事敏捷團隊的相關工作,從2006年開始實踐Scrum。2010年,他加入了Ken Schwaber的Scrum.org,是任期最長的Professional Scrum Trainers(專業Scrum講師)之一。他還出版過有關敏捷的兩本書(“Environment for Agile Teams”以及“Agile w Praktyce”),並撰寫了很多部落格文章。目前Andy負責管理Code Sprinters,這是他在2007年創辦的軟體公司,經過多年發展已成為波蘭最大的敏捷培訓和顧問服務供應商。\

\\

作者Andy Brandt閱讀英文原文The Triangle of Self Organization

相關文章