©200一、2014 Don Gray和Dan Starr程序員
在北卡羅來納州的藍嶺山脈附近,離您應該想到的地方不遠,確實有一個名爲Mayberry的小鎮。編程
儘管數年前主要公路繞過了小鎮,但Mayberry是廣受歡迎的1960年代電視連續劇的同名人物,這裏仍然是一個熙熙攘攘的社區。天天早晨,美國北部52號高速公路的商業支線從北部進入梅伯裏市中心。在鎮上進行了一週的諮詢工做,咱們可以觀察到這條路線上最近的道路建設,並觀看了三位當地居民展現本身獨特的管理風格。讓咱們看一下這些人物的交通管理如何與軟件項目管理的通用樣式契合(暗示)。安全
當位於城鎮北部的道路工程關閉了52號公路時,全部從北部進入城鎮的交通都必須繞過52號公路繞行至城鎮西側,而後進入Key Street的市區。不幸的是,這意味着交通將不得不左轉進入Key Street,穿越至關繁忙的東西向交通(見圖1)。工具
圖1性能
鎮議會擔憂,在早上匆匆忙忙等待左轉駛入Key Street的交通會一直沿匝道南行,一直延伸到52號高速公路自己。因爲52號公路的時速限制爲65英里/小時,所以可能會致使嚴重事故。所以,議會決定在交叉路口派駐一名警察和一兩個救援隊志願者,以確保坡道上的交通不會擁堵。編碼
做爲值班人員,值班人員(咱們稱他爲Barney)週一到達現場並迅速肯定了狀況。他認爲須要的是在Key Street和坡道交匯處的交通訊號燈。因爲須要數月的時間來批准一個燈,他決定將其做爲"人工交通燈"來操做,以手動方式引導交通。每一個方向都有轉彎:西行Key Street(包括向左轉入南行坡道),而後是東行Key Street(包括向右轉入南行坡道),而後是下坡道(能夠任意一種方式轉入Key Street)。巴尼的計劃實際上並無那麼好。Key Street上的雙向交通停滯。當Barney讓幾輛車左轉到Key Street時,交通幾乎都堵到了52號高速公路。3d
週二,一名救援隊的志願者(一位當地有幫助的婦女,稱爲Bea姨媽)說她知道如何管理這種狀況。她認爲,只要駕駛員沒必要橫穿彼此的道路,交通就能夠自理。所以,她讓車流在Key Street上雙向行駛,並讓人們在匝道上右轉和右轉。當有人不得不左轉時,她會中止其餘車道並讓它們走。Bee姨媽的方法比Barney的方法效果更好(至少沒有人對她作出粗魯的舉動),但擁堵仍然比咱們預期的要多得多,而且在高峯時間結束時擁堵依舊。blog
星期三,安迪警長出現了,帶來了一把草地椅和一個檸檬水保溫瓶。他把草地椅放在一個陰涼的地方,從那裏能夠看到交叉路口和下坡路的一段不錯的路,而後坐下來喝檸檬水。當車流量開始在匝道上擁堵時,他起身,中止了Key Street的交通,讓匝道空了。而後他回到椅子那裏。除此以外,安迪彷佛幾乎什麼也沒作。儘管他顯然沒有采起任何行動,但交叉路口彷佛仍然有效。人們保持冷靜和放鬆,駕駛員向右轉彎爲他人創造了休息時間,向左轉彎,而且一切工做都像在任何人出現以前同樣,狀況有所好轉,只是稍微好一點。three
戴上顧問的帽子,咱們意識到剛剛目擊了三種獨特的管理風格:Barney的微觀管理(Micro Management),Bee姨媽的母親式管理(Motherly Management)和Andy的專家式管理(Masterly Management)。因爲這些樣式在軟件項目管理中也很常見。讓咱們更詳細地研究每個,並瞭解能夠應用於本身的軟件項目的內容。事件
每個管理者由不一樣的假設,而塑造本身的風格,假設要進行管理的人,以及假設對管理者的角色。這些假設決定了他們如何進行關鍵的管理活動。在溫伯格的《質量軟件管理》一書中。1:系統思考,溫伯格重點介紹了五項關鍵活動:
這些活動共同構成了一個"引導"項目團隊的反饋系統。它們的執行方式(即管理者定義爲問題的方式,管理者如何計劃,進行了哪些觀察,遵循了哪些規則以及如何採起糾正措施)使全部事情有所不一樣 - 肯定團隊的去向,團隊成員對整個軟件項目的感受,以及最終結果將如何使人滿意。
Barney實行了微觀管理,這是基於如下假設:管理者必須確保一切都完成了。大多數微觀管理人員並不是故意出於控制的須要而介入。他們只是在這樣的假設下運做:若是他們不這樣作,那將沒法完成。微觀管理者也傾向於作出相關的假設,即被管理者將按照他們的指示去作。剛恰好,很少很多。
這些假設比人對機器的描述更好。確實,當巴尼(Barney)說咱們須要"人流信號燈"時,他描述的是管理者和被管理者都比人更機械的狀況。也許這就是爲何這麼多優秀的程序員在得到第一次晉升時就成爲微觀管理者的緣由 - 他們只是在"編程"爲他們工做的"生物機器人"!
使用溫伯格的模型,咱們能夠看到巴尼(Barney)的假設如何定義他對關鍵管理活動的見解:
由於管理者必須作出(或至少批准)全部決定,因此一次只發生一件事,而其餘全部事情則排隊等待轉彎。當簡單性,集中信息和監督從美德變爲弊端時,它會產生影響項目計劃和執行的瓶頸。
簡便性因爲整個項目計劃都必須始終在管理者的控制之下,所以計劃必須足夠簡單,以使一我的能夠完整地理解它。這就爲項目的複雜性設定了一個上限-若是要解決的問題超出了這個界限,則管理者必須以某種方式簡化它(例如,一次只容許一個方向的交通)。在微管理項目中,這種活動的序列化也是常見的簡化,而且浪費了精力和時間。當序列化還不夠時,管理者可能會開始將"沒必要要的"活動排除在項目計劃以外。微觀管理因過分簡化而臭名昭著,以致於他們的軟件項目計劃可能遺漏了成功推出產品所必需的東西。
集中信息因爲管理者是惟一能夠作出決定的人,所以得到有關項目執行狀況的大量高質量信息相當重要。不幸的是,惟一容許的觀察是管理者在項目計劃中提出的觀察,可是該管理者太忙於作出每個決定來實際上觀察任何事物的決定。所以,在實踐中,微管理人員經常視而不見,不多或根本沒有實際信息時就作出決定(草率的決定)。
監督須要得到每一個操做的明確批准,這增長了完成任務所需的時間。所以,微觀管理每每效率低下,許多人在等管理者告訴他們下一步該作什麼。瓶頸管理者是一個關鍵的結構性問題。這種作法還會致使人員問題,例如主動抑制。管理者的假設意味着,被管理的人員除了管理者定義的職能以外,沒有其餘貢獻。若是工人想作一些不遵照規則的事情怎麼辦-由於他們看到了更好的方法或計劃的問題?算了吧。微觀管理者將不容許它發生。對於那些受到微觀管理的人來講,這會形成短暫的脾氣和漫長的日子。
大多數人不喜歡這種管理風格。有些人會作出某種僵化的,機械的順從性迴應,盡職地等待管理者的下一組指示。其餘人可能會選擇某種形式的微妙的叛逆,例如"努力統治"-即便管理者的指示顯然是失敗的訣竅,也要遵循管理者的指示。其餘人則將更公開地反叛,利用管理者的不斷分散注意力來逃避一切。micro,這些對微管理的響應每每會創建一個正反饋迴路,從而增強微管理者的假設並致使更多的微管理。微觀管理者每每很忙。(越關注細節越忙)
那麼,微管理曾經合適嗎?固然,要解決的問題足夠小時,一個管理者就能夠真正理解整個項目計劃,而從事工做的人員則願意遵循管理者的每個命令。儘管這種狀況有時會發生,但在軟件世界中並不常見。
進行微觀管理的一個常見緣由是新晉升的,技術上合格的管理者急忙幫助陷入困境的員工或營救軟件項目的特定部分。這就造成了一個相互依賴的動力,其中管理者變成了救命稻草,員工卻變得無奈。這樣能夠確保下次出現問題時,管理者將再次介入,依此類推,直到出現某種狀況破壞了模式。
儘管微管理項目能夠(而且常常)致使成功的產品發佈,但更多的是儘管對其進行管理,而不是由於它。應該有一種更有效,更輕鬆的方式來處理這種狀況。
Bea姨媽選擇了一種更友好、更溫和的風格,咱們稱之爲母親式管理。容許駕駛員本身作點事情,並在她認爲須要幫助時幫助他們。可是她的基本假設仍然與Barney的假設很是接近:被管理的人也許能夠在不被告知的狀況下作一些例行事情,可是全部重要的決定-尤爲是在存在某種形式的競爭時 - 仍然緊緊掌握在她的控制之下。
若是微觀管理者將人們看成機器來管理,那麼大媽管理者會把他們看做是孩子。被管理者可以作一些例行的事情,但仍然須要保護以避免受到任何潛在危險的傷害。像微觀管理者同樣,大媽管理者不必定是惡意的或迫切須要控制的。Bea姨媽根本不須要控制司機。她只是知道,沒有她的幫助,他們將沒法作出重大決定。她簡直沒法想象一我的可能會左轉進入另外一個右轉所形成的差距的狀況,由於她沒法看到誰在控制着這種關係,並且她知道兩個駕駛員固然不能沒有人來協調他們。
Bea姨媽的母親假設肯定了她對關鍵管理活動的見解:
像微觀管理同樣,當母體管理的基本假設正確且問題和解決方案不太複雜時,母親式管理也能夠工做。麻煩的是,大多數軟件開發都不是這種模式,而且大多數開發都是很是規的,須要解決許多衝突。界面、分區、分解、協議 - 這些都是大媽管理者所認爲的"左轉",他必須親自確保每一個人都玩得很好。這就產生了相似於微管理的結構問題。相似於微觀管理但也不一樣。因爲某些工做能夠在母親的管理下獨立進行,所以與微觀管理相比,管理者沒有什麼困難。
可是因爲該過程仍然是高度以管理者爲中心的,所以能夠並行完成的實際工做量一般少於預期。咱們最終獲得了一個很是有效的過程:幾乎平行,相對觀察而且很是接近賦予工人獨立的責任:
並行(幾乎)只有預約義的"常規"事物才能並行發生。只要交通一直向前或向右轉,Bea姨媽的計劃就彷佛奏效了。可是她沒法預測會有多少人想要左轉。當不少人開始向左轉時,她的計劃崩潰了。以一樣的方式,由大媽管理的軟件項目的實際性能在很大程度上取決於真正須要多少開發,而不須要交互或解決衝突。若是"例外"比預期的多,那麼許多根據項目計劃並行工做的開發人員可能坐在他們的手上,等待管理者作出決定。這可使在理論上平行的項目計劃在實踐中變成串行的。
保姆對於被管理的人來講,大媽管理比微觀管理要輕一些,由於"母親"容許她的"孩子"本身作一些事情。只要不背離流程或陷入衝突,各個開發人員就能夠繼續前進。可是,若是首先代表存在非標準行爲,則整個過程將中止,直到管理者決定要作什麼。管理者必須處理全部真正重要的決策,而這扼殺了我的對解決總體問題的貢獻,幾乎與微觀管理同樣無效。這裏存在很大的變化-一位把員工視爲青少年的管理者比那些將員工視爲幼兒的管理者更不公開控制。不過,大多數從事軟件業務的人都有大學學歷,若是咱們要找到一種比微觀和母性更有效的樣式,則必須從更改基本假設開始。巴尼(Barney)將人們看成要編程的機器來管理。Bea認爲他們是須要幫助的孩子。如今,讓咱們看看安迪將他們視爲成年人時會發生什麼。
安迪採起的方法起初看起來根本不像是"管理"。他只是坐在椅子上,一邊喝着檸檬水,一邊看着52號高速公路匝道旁的車流。當匝道開始嚴重堵車時,他就溜進交叉路口,阻止了Key Street上的交通,並清理了匝道;而後他回到位置上。他彷佛比Barney或Bee 阿姨少作"工做",但交通更順暢。咱們將安迪的風格稱爲專家管理 - 因爲咱們的三個交通管制員,只有他纔是真正的管理大師。
安迪的管理風格的關鍵在於他的基本假設:駕駛員是成年人,大多數時候他們均可以照顧本身,而他做爲管理者的角色是支持這些有能力的成年人,以便他們可以作獲得本身安全經過十字路口。這與Barney和Bea姨媽的假設徹底不一樣。安迪(Andy)對本身的能力和駕駛員的技能感到足夠安全,所以他能夠將本身從工做中心轉移出去。
因爲Andy並未將本身置於管理任務的中心,所以他能夠在關鍵管理活動上更加靈活有效:
安迪認爲要解決的問題是高效安全地經過十字路口。他還意識到,大部分時間這個十字路口不須要任何幫助。人們天天都在這裏轉彎而無需任何監督。是什麼使這裏須要一些的管理和干預呢?繞行繞道增長了52號高速公路匝道的交通,有時可能致使坡道上的交通堵車到高速公路上,並形成安全隱患。請注意區別 - 巴尼和巴比阿姨根據他們必須作的事情來定義問題,而安迪則根據結果來定義問題,而與誰真正"完成了工做"無關。經過這樣作,安迪將本身定位爲觀察和"引導"起做用的系統,而不是做爲從事該工做的人。(譯者注:關注技能 vs. 關注結果)
經過了解要解決的實際問題,Andy可以爲其解決方案制定有效的計劃。駕駛員負責本身經過十字路口。安迪和他的"管理團隊"將監視匝道,並確保在(以及是否)擁堵的很遠而構成安全隱患時將其清空。儘管Barney可能會指責Andy沒有太多計劃,但事實是,Andy的簡單計劃實際上容許發生一些很是複雜的事情。由於他沒有試圖控制駕駛員的低級動做,因此安迪的計劃將管理工做委託給了各個駕駛員。這樣一來,他們就能夠並行運行,而他們等着--等待駛向左轉彎的駕駛員利用了駕駛員右轉彎所產生的交通缺口。
如今Andy既有問題陳述又有計劃,安迪能夠肯定他須要進行哪些觀察。爲了防止交通擁堵回到52號公路,他必須注意坡道 - 而不是十字路口。所以,他將本身放到能夠看到坡道的一側。這是安迪風格的另外一個重要差別。站在十字路口的中間,Barney和Bea姨媽正在吸取大量信息 - 大多數信息與解決實際問題無關。他們不在正確的位置進行真正重要的觀察。固然,安迪並無忽略交叉路口發生的事情,但他並無將交叉路口做爲主要關注點。
Andy的管理風格使用了兩個過程模型。首先,若是流量在匝道上擁堵,就要在Key Street上中止車流並讓坡道的車先走。其次,若是有東西擋住了交叉路口,請當即將其移開。在其他時間裏,Andy的過程模型表示"讓駕駛員本身照顧本身"。
這兩種模型都比它們看起來更微妙。第一個模型容許Andy在早晨進行時進行一些微調。坡道距交通距離"太遠"有多遠?起初,他採起了一種保守的方法,在坡道擁堵到高速公路的一半時將坡道清空。後來,在觀察到Key Street的交通能夠多快中止以清空坡道後,他將"太遠"的定義更改成坡道上四分之三的距離。這意味着須要更少的干預,由於一般狀況下,流量會回升到四分之三擁堵點,而後自行回落。
第二個模型包含關於觸發動做的靈活定義。安迪正在尋找可能有多種根本緣由的症狀。若是有東西擋住了交叉路口(例如,駕駛員太膽小以致於不能向左轉),安迪的模型將對其進行處理。
就像咱們討論過的其餘兩種樣式同樣,精通管理在其基本假設有效時起做用。在軟件開發中,若是管理的人員是熟練,稱職,受過教育的成年人,那麼這些假設一般是正確的。所以,熟練的管理能夠解決咱們在微觀和大媽管理中看到的結構和行爲問題:
該計劃固有的受權意味着無需管理者干預便可解決大多數爭論和較小的衝突,所以大多數時候人們無需等待管理者的命令。當問題確實須要管理者的注意時,該問題就沒必要在一系列小衝突以後排隊等待。
對並行活動的支持意味着熟練的管理能夠處理那些過於複雜而沒法由單個管理者理解其全部細節的項目,而且大多數軟件項目都屬於該類別。
由於被管理的人還被委派了自我管理工做,因此他們可以提出微觀管理者或大媽管理者可能會錯過的觀點。
專家管理涉及管理項目而不是我的。在大多數狀況下,從事工做的人員能夠在一些基本準則內自由選擇本身的方法(例如,在正確的道路上行駛或使用公司標準工具集)。這容許創造性的精力投入到尋找"擊敗系統"的方法上,而不是去創造有利潤的產品。
簡而言之,像Andy這樣的專家管理者會觀察並操縱一個系統。若是問題獲得了很好的理解,計劃是適當的,而且工做的人很稱職,那麼控制員一般不須要作不少事情。與微觀管理者和大媽管理者不一樣,熟練的管理者將大部分時間都花在觀察和思考上,而不是在瘋狂的活動中。可是不要上當 - 當安迪坐在椅子上喝檸檬水時,他比巴尼或比阿姨更有效地控制了局勢。
若是專家管理是如此出色,爲何咱們不常常看到它呢?由於在某些方面使人不安,尤爲是對於管理者而言:
外觀可能具備欺騙性。專家管理的項目一般會給人以混亂的印象。當安迪(Andy)管理十字路口時,交通往各個方向轉彎,與巴尼(Barney)負責時整潔有序的行爲相比,這使人不安。可是,在安迪看上去混亂的管理風格下,更多的交統統過了十字路口,而且更加安全。許多軟件項目已經看起來很混亂。專家管理會使他們變得更加如此嗎?咱們對此表示懷疑;咱們懷疑軟件開發中的許多明顯混亂來自對微觀和大媽管理的抵制。
專家管理者須要不一樣的心態。大多數人將管理與權力一詞聯繫起來。然而,從微觀管理轉向專家管理涉及放棄管理職位的許多表面上的權力和權威,並將其交給工做人員。根據做家Barry Oshry(在Weinberg的書《成爲技術領導者》中引述)的說法,高級管理者具備更強的權力,若是咱們將權力定義爲"以加強系統在環境中發展的能力和行動的能力" 。
衡量重要因素在某些組織中(尤爲是那些以微觀管理爲準則的組織),專家管理者可能很難晉升。畢竟,與周圍的微觀管理者和大媽管理者相比,您將不會進行太多可見的管理,而且作出晉升決策的微觀管理者很容易得出結論,儘管您"無所做爲",該項目成功了,但不是由於你的管理。
可是專家管理也有回報。專家管理者一般沒必要像微觀管理者和大媽管理者那樣瘋狂地工做。做爲高級管理者,您不太可能在凌晨三點到辦公室,試圖解決另外一個瑣碎的問題。當項目團隊說"咱們本身作到了"時,您將知道本身確實是一個有效的領導者,就會對此感到滿意。
肯定管理風格的最佳方法是提出問題並觀察正在發生的事情。
向您報告的人是否像風中的樹葉同樣散落?您是否以爲他們在履行法律條文而不是精神?出現問題時,您會跳入並開始編碼嗎?若是是這樣,則多是您進行了微管理。
您是否組織工做流程以減小交互,使團隊中的事情順利進行?您是否介入並嘗試使全部人都適合?在緊縮模式下,您是否還原爲微觀管理?
您是否花費大量時間觀察正在發生的事情,考慮事件將對您的團隊和項目產生的影響,並計劃作什麼?若是是這樣,則您多是專家管理。
若是您想更改本身的管理風格,則須要考慮一些重要問題。首先,您是如何擁有當前的管理風格的?對於咱們大多數人來講,咱們的管理方式會受到管理咱們的人以及咱們所處環境的影響。認識到這些影響以及您當前工做情況的限制,可能會幫助您肯定是否該採用新模型了。一樣重要的是,檢查一下您對風格的感受。若是您對現狀感到滿意,則可能無需進行更改。可是,若是您感到勞累過分,而且彷佛一直在撲救大火,那麼也許應該進行一些更改。
原文:https://www.donaldegray.com/managing-in-mayberry-an-examination-of-three-distinct-leadership-styles/
最後,您想作什麼?咱們看到Barney(微觀管理)、Bea(大媽管理)和Andy(專家管理)對"眼前的問題"的見解影響了他們的獨特迴應,對您來講也是如此。 知道本身想作什麼以後,就能夠建立和實施計劃,以實現目標並保持流量平穩運行。
歡迎留言討論,你是什麼風格的管理者(不必定必須是管理層,任何人均可以反思)? 是否有感覺到天天很累,就像救火同樣? 你身邊的狀況和現狀是什麼? 哪些是重要的,如何站在一個合理的位置上進行觀察? 採起什麼行動(嘗試)?
本文首發於 Bob Jiang的博客 ,轉載請聯繫 Bob Jiang