項目經理在敏捷中的職責

書裡的敏捷不談管理者的角色,而是談教練/促進者。本文首先解說了各行業通常意義上的項目經理角色,然後試圖將其與敏捷中的教練/促進者角色相對應。在這一探討中,本文也試圖拓寬教練/促進者的工作範圍。

在探討敏捷中的項目經理角色前,讓我們首先看看各行業中到底為什麼需要管理者。

  1. 人無完人人類頭腦的工作方式是非常複雜的。世上沒有兩個腦袋想法一模一樣。 就像兩個指紋絕對不可能重合,兩個個體的工作方式也不可能哪怕90%合轍。美妙的自然,創造出如此多而各不相同的個體,實在讓人讚嘆。但是,商業目標對所有利益相關方都保持“唯一而相同”。這裡提到的人,代表所有參與項目的利益相關方,他們來自不同部門,如(a)項目團隊成員、(b)業務用戶、(c)管理層和出資人。每個項目在每個地方都需要管理人員,從而做到:

    1. 讓人們與項目目標保持一致並調優其工作方式。
    2. 發揮人們最佳能力。
    3. 幫助人們保持專注和激勵。

    如果項目中每個人都是完美的,那無論什麼行業的任何項目都不可能失敗,不管是瀑布還是敏捷的軟件開發模式,完美的人總能造就完美的項目。

  2. 控制改變生活中唯一不變的就是改變。什麼事物都會變,不管是有形的(如需求)還是無形的(如人員)。

    1. 需求就像風,總是吹拂(就是改變)。
    2. 人的經驗和閱歷每天都在改變[比如,我明天的經驗比今天將+1天]。這會帶來改變,對我的:

      1. 抱負
      2. 技能
      3. 信念
      4. 態度
      5. 任何其他軟硬技能

    3. 業務和市場瞬息萬變。因此,客戶的期望可能改變。
    4. 技術領域時時發生著改變和創新——軟件項目環境、架構和設計、開發流程都可能改變。
    5. 資源流動在長期項目中不可避免。
    6. 就數學意義而言,計劃是一個時間函數。無論是在項目組、項目還是Sprint層面上,不管你計劃如何周密——它可能明天就無效了。計劃中的所有屬性(任何層面的任何計劃種類)都有時限,有些近在明天。當所有事情不斷地、不可預期地發生改變,昨天的計劃如何能在明天有效呢。在這一語境中,管理者的角色是:

      • 給予人們持續激勵,讓人們全心投入到項目中。
      • 以實際的過渡計劃應對資源流動,將對業務的影響降到最低。
      • 時刻注意計劃,讓計劃與時俱進,採取相應的額外步驟來管理影響和改變。
      • 因為人員和計劃都是動態的,所以要與利益相關方就影響和應對策略保持持續溝通。

  3. 交流導致嫌隙和衝突

    1. 溝通交流是所有快樂之源,也是所有衝突之源。
    2. 它是一種藝術,總是需要勤勉不怠、深思熟慮,提前想到信息會如何被受眾解讀,是否會冒犯某人,是否足以保證信息的傳遞順暢到位。世上少有人具備這一藝術。
    3. 開發人員通常太注重技術,於是(有意或者無意地)忽略了這一精巧藝術。

      項目經理在很大程度上控制著溝通交流職能。他/她應當在團隊成員願意承擔時對其下放部分責任。

  4. 流程並非完美

    1. 沒有完全理想的流程(比如軟件開發方法,不管敏捷或瀑布,都不完美,沒有理想的流程來忠誠地定義客戶-供應商關係,而且就算有,也幾乎不可能按照其實質精神來履行)。
    2. 就算一個流程對某人或在某種情況下運行絕對良好,它對不同環境下的另一個人也許就會可怕地失敗。

      管理者應該讓團隊關注於結果,而非總是擔心流程。 “流程為我所用,我不為流程所用”——意思是,遵循流程並非最終目標,它只是達成某種結果的工具。管理者應該與團隊一起,決定流程的哪部分對該項目最佳,並只適用那個部分。

  5. 流程實施不當

    1. 流程實施總是意味著更多的工作,更多的辛勞,更多的跟踪記錄,而這些是任何通常意義上的開發團隊力圖避免的。流程開銷被很多人當成是罪魁禍首。
    2. 一個特定流程在整個項目期間被100%原汁原味地實施,是很罕見的。

      如果任何對流​​程的違背可能導致混亂並對項目產生負面影響,管理者需要干預並保證對所有優良實踐的高度遵守。

如果以上5個原因都不成立,就沒有什麼行業需要管理者了。但是很不幸,以上5者在每種行業、每家公司、每個項目和每次sprint全都存在。投資人和利益相關​​者必須在任何項目中得到好的投資回報(RoI),所以需要有人來擺平這些事情,並且仍然幫助達成項目的業務目標。所有上述五個屬性實質上都不是技術相關的,可以通過應用管理實踐來很好地應對。而扮演這一角色、將管理實踐帶入項目的人,在企業界就叫做“管理者”。但這不是說,管理者們有萬靈仙丹來讓上述這​​些達到完美,但是他們能幫助人員和流程得到調優,監控並應用橫向思維的管理概念,來產出創造性的解決方案,以使上述五點不會大範圍地影響業務目標。這一角色的一個子集,在敏捷用語中被描述為教練/促進者。

敏捷創造了一個新詞彙,叫“自組織團隊”。我個人是自組織團隊的忠實粉絲。它在很多時候運行良好,尤其是在那些人們於公共生活中展​​現高度責任和義務標準的文化中,這是因為人們把這些高標準同樣帶進了辦公室,完美地匹配了“自組織”團隊。讓每個僱員都工作於自組織的模式中,是所有公司的夢想。但是就像所有人類各不相同一樣,不是每個人都適合“自組織”的團隊。比如,不是每個醫生都能成為外科醫生、牙醫或者整形醫生,但是每個醫生仍然都對社會有用。相似地,不可能期待每個人都能以“自組織的風格”工作。然而,同樣是這些(不適合自組織定義的)個人,假如以不同方式處理,仍然可以成為很棒的貢獻者。這裡就是項目經理角色變得特別有幫助的地方,他可以通過多多少少(依賴於個體情況)的監管,讓團隊成員做出最佳的工作。敏捷使用“教練/促進者”一詞來代表這種角色。另一方面,這一角色在人們稍稍偏離自組織狀態時也工作良好。在如下3種情況中,教練/促進者或許必須延展其工作範圍。

  1. 人們過度偏離自組織狀態(比如非常無組織、非常不專注、情緒化等等)。
  2. 人們的軟技巧與業務需求不相匹配(比如,不能做到積極主動,害怕講話,溝通不良,時間管理差等等)。這些軟技巧的缺乏,不可能讓真實的潛力轉化為績效。
  3. 人們得了企業病(比如誹謗中傷,嫉賢妒能,自吹自擂,知識壟斷,阿諛奉承等等)。技術上講,假如有強力的管理者(而非教練)以持續的監督來控制他們,在影響到團隊互動之前就扼殺這些苗頭,仍然可能使這些人有所產出。

我在此的意思是,我們應當對所有專業人員具備高度的包容。但是處理和發揮一個個體的長處,方法因人而異,沒有適用於每個人的通行法則。組織在這一點上應當反省。所有國家都有很好的技術人員,他們可以是好的貢獻者,但也許不能自組織。這就是教練/促進者會轉為更像一​​個項目經理的地方。這些人也許會犯錯,也許需要引導和監管,也許缺乏軟技巧,如此等等。在教練/促進者的有限範圍內,讓這些類型的人員與敏捷相適應來完成工作,會成為一個噩夢。我對各種各樣的人充滿尊重,也堅信這些人可以成為好的貢獻者,但是你需要延展教練的職責範圍,給與其某種權力來強硬地表明“什麼該做,什麼不該做” 。這裡項目經理的角色就變得有幫助。下表展示了一些覺得需要項目經理的其他領域。

情境編號 事實 敏捷如何有用 敏捷幫不上忙的地方

(而管理者可以!)

備註
1 人無完人 舉行每日進度會議,讓他們保持專注,讓產品負責人保持需求與業務相一致。 1.專注點是否在正確方向上?

2.產品負責人是否每個衝刺都改變目標?

3.責任是否真正分擔?如果每人都覺得別人更有經驗、懂得更多,所以更要負責,該怎麼辦?

4.人們是否以敏捷之名掩蓋自己能力的不足?

5.團隊是否做到真正自組織?

6.人們是尋找外部原因作為藉口,還是真正有所改善?

7.團隊中是否有某人正搶占所有功勞,而損害了團隊動力?

8.是否有人壟斷了知識,不與團隊分享?

具備橫向思維的管理者可以想出創新的辦法來管理不完美之處。

教練可以用合適方式提出如何做事,但如果人們不遵循又如何?比如,要是團隊在演示後不聽取產品負責人的反饋呢?這是可接受的,還是必須強制聽取?

2 控制改變 敏捷在每個衝刺開始時歡迎新的需求,而Scrum Master在衝刺中防止範圍蠕變。 1.Scrum Master是否正確履行職責?

2.測試人員是否按時做了工作?

3.人們的軟技巧和承諾是否正在改變?

4.客戶是否突然開始不信任敏捷?

5.客戶是否突然開始期待不切實際的事情?

敏捷以需求優先級來照管改變,但只是一部分。

產品負責人可以發揮影響力,在衝刺進行中增加故事,可團隊不知道如何應對?

任何方法都無法應對無形的改變。

3 溝通不適當 敏捷用站會提供了每日溝通的機會,也用回顧會議創造了大家暢所欲言的平台。 1.團隊是否真正提出障礙?

2.團隊是否積極主動地溝通所有事項?

3.受眾是否完全理解了溝通內容?

4.我們的溝通中是否有語言或文化的隔閡?

5.分佈式的溝通是否成了瓶頸?用戶體驗是否良好?

6.是否所有email都得到回复,並達到預期、質量良好?

公司溝通是與懂得寫程序非常不同的課題,也是很困難的課題。

管理學研究解釋了溝通的藝術性。

任何流程都不能處理軟技巧。

4 流程不完美 敏捷在軟件開發中有效。 每個方法論都有其局限,最終是人來使項目成功。 差的敏捷不如沒有敏捷。
5 流程實施不恰當 敏捷是一個實施依賴於人的流程。 1.人們是否遵循流程?

2.流程可否改善?

3.流程的哪些子集適合我的項目?

4.例外在哪裡,何時偏離流程沒有關係?

一個簡單例子——在敏捷中,團隊是否進行大量的結對編程?

最佳實踐何時真的成為我項目的最佳實踐?

如果情況出錯,項目經理可以拓展其角色至教練/促進者之外。他/她可以控制那些本質上不適合敏捷或是意圖上不願意敏捷的團隊成員。我想要指出3個業內普遍流行的神話,他們在敏捷的語境中更加顯著。

1號神話:管理者們有萬靈仙丹。

事實:處理人的頭腦非常複雜,極其有挑戰性。這裡沒有科學,只有純粹的藝術。不管你做什麼,總有不可管理的人,不可控制的改變。以我的愚見,一個好的管理者能夠:

  1. 完全解決50%的問題,
  2. 部分解決15%的問題,
  3. 通過溝通讓問題顯而易見,讓15%的問題看上去沒有影響或者超出範圍,
  4. 20%的問題總歸存在(有些特定情況下的人和有些改變就是無法管理)。我們必須接受這一點。

請注意,如上這些數字只是我的經驗表達,不是基於任何科學的研究調查。

管理者也是人,像其他人一樣並不完美。 “全方位思考(holistic approach)”的管理是另一個概念。它是一項完全不同的職業,其設計就是為了管理不完美的人和流程。具備相當經驗和學識的人可以帶來很多價值。

2號神話:管理者們總是限制自由。

事實:對某些霸道的管理者可能是如此。但是實際上,好的管理者創造一個環境,​​提高表現,讓人們發揮出最佳水準。有經驗和見識的管理者可能暫時性地限制團隊的自由,但其目標最終只是幫助人。有時候人們不能提前看到這一點,因為(a)缺乏經驗(b)工作環境過於寬鬆(c)總是伴隨著短視的傲慢心態(d)其他任何未言明的原因。

也有可能是,不勝任的人員懼怕被曝光,於是感覺管理者限制自由。渴望做出成績的人應當提高自己的標準,利用管理者的經驗來彌補不足,並與他/她緊密工作,以獲得更多責任,讓管理者可以放心休息。

3號神話:管理者不應該有權威。

事實:有些國家和文化從來就灌輸公共生活中的責任義務觀念,這些情況下是不需要權威的,教練/促進者在這類環境中將如魚得水。但是權威的概念在有些仍在演化而未達到成熟階段的社會更有意義。為了控制上述5個原因(本文開頭所提),任何管理者在那些環境中都需要權威。沒有權威的管理者就像沒有油的汽車。研究顯示,人的思想在心理上(尤其是成年期)就像硬鐵條一樣難於彎曲。要把鋼鐵塑造成漂亮的器具,權威是必需的。當全世界都變得非常勤勉、負責、成熟,以自組織的方式達到高效的時候——全球的管理學院都要關門大吉了。

結論

敏捷是一種很好的軟件開發方法,它幫助克服了傳統瀑布流程的一些不足。但是敏捷不是使項目成功的王牌。項目中進行工作表現的還是同一批人,而一有人的存在,就總有挑戰。這個世界(以及人)充滿了問題和缺憾。科學家們通過創新科技來幫助社會,類似地,管理這個職業幫助人們在受到製約的情況下仍能獲得商業和職業上的成功。沒有什麼方法論可以排除管理者,除非是由完美的人來執行。流程是一套指導方針,有流程的地方就有偏差,有人的地方——就有問題。為了管理人和問題、控制偏差和改變——每個項目都需要專業管理的幫助。與此同時,管理者們也是人,他們也同屬於這個由缺憾構成的世界,某些管理決策也可能失敗。利益相關方必須接受這一點。在一定的環境中,管理者可能需要權威來應用一定的措施,來保證項目的最佳利益。這些措施可能在團隊成員中遇到阻力,因此為了應用它們——有時候教練/促進者工作良好,而在有些情況下,具備權威的管理者才可以。

關於作者

Vinay Aggarwal是印度Xebia IT Architects的交付經理。他在IT業界有11年的經驗。他擁有工程學學士學位,是PMI認證的項目管理專家(PMP)和經認證的Scrum Master(CSM)。曾在IBM和埃森哲等公司任職。他在瀑布和敏捷(Scrum)方法論上都有很多經驗。他信奉橫向思維,並將管理學概念應用於解決各種交付上的挑戰。

查看英文原文:The Role of Project Managers in Agile

本文來自:http://www.infoq.com/cn/articles/project-manager-role

特別注意:本站所有轉載文章言論不代表本站觀點,本站所提供的攝影照片,插畫,設計作品,如需使用,請與原作者聯繫,文章轉自alibuybuy

Comments are closed.