訪談《敏捷和精益專案集管理》的作者Johanna Rothman

\

重點

\

• 專案集管理關乎的是如何優化產品交付。
• 敏捷和精益專案集管理者呈現僕人式的領導風格。
• 讓人們自願參與到軟體專案集團隊。
• Cynefin模型有助於專案集管理者理解什麼是未知的。
• 擴充套件協作，而不是流程。

\

由Johanna Rothman《敏捷和專案集管理者：擴充套件跨組織的協作》探討了如何擴充套件精益和敏捷流程以完成大型專案集工作。它探討了如何進行跨組織的協作從而建立和引導自適應的、有彈性的專案集。由於團隊向敏捷和精益的轉型，以及使用了自適應的專案集管理，所以組織可以更快速地交付給市場。\

Rothman在這本書中提到了以下敏捷和精益專案集管理的原則：\

1. 1. 採用產品的視角。原則是：“業務人員和開發人員必須在一起工作。”\
   2. 敏捷和精益方法鼓勵以整體法對待產品，在這種情況下你可以更容易做出調整去滿足當前的需要。原則是：“歡迎需求變更。這是競爭優勢”。\
   3. 專案集管理人員是僕人式的領導風格。原則是：“圍繞積極上進的個人構建專案”、“信任他們可以完成工作”和“把權力授予團隊”。

InfoQ專訪了Rothman，請他談了談敏捷和精益是如何共同為所有專案集提供幫助的，以及管理如何支援專案集走向成功。\

InfoQ：為什麼你會寫這本有關於敏捷和精益專案集管理的書？\

\

Rothman：我看到大家都在專案集方面努力奮鬥著。\

有些人沒意識到正在做專案集管理。他們認為自己正在把敏捷從一隻團隊“擴充套件”到多隻團隊。\

有些人使用的是公共框架，可能得不到他們想要的和所需的效果。\

有些人試圖把Scrum作為管理手段來用。當然，你可以這麼做，但在一個專案集上協作的管理者們卻很少作為一個團隊在一起工作。他們是有著共同目標的一個組織，但卻沒有進行共同協作。這意味著Scrum對於他們來說不是最理想的，對於如何協作他們需要其他的思路。他們可以看看核心團隊法是否適合他們。

\

InfoQ：誰是這本書的目標讀者？\

\

Rothman：當然是專案和專案集經理了。專案集經理有很多不同的型別：軟體專案集經理、硬體專案集經理、核心團隊專案集經理。\

此外，還有Scrum Masters、技術帶頭人（比如企業架構師）和其他設法幫助敏捷和精益團隊跨組織協作的人。你不一定要成為專案集經理後才來讀這個書，你也一樣可以從中得到收穫的。

\

InfoQ：傳統專案集經理與敏捷和精益專案集經理有怎樣的差異？\

\

Rothman：更傳統的專案集經理往往會按以下方式工作：\

管理者說，“完成這個專案集。這裡有300個人。要在明年8月完成。”傳統專案集經理早就意識到要麼就是人太多，要麼就是時間不夠，又或者需求將來要變，或者其他一些可怕的事。對於專案集經理來說，最重要的事就是這個專案集，但在大家長長的工作列表中卻並沒把它擺在優先的位置。\

更傳統的專案集經理喜歡告訴大家她需要這在什麼時候完成。那是因為更傳統的專案集經理喜歡按交付物的最終期限來倒推。\

如果你永遠都按階段的流程工作，在第二階段之前就很混亂。需求無窮無盡。架構把該流程框定在一個狹窄的空間，並通過設計或需求階段來做，人們發現他們無法在該架構內正常工作。或者，他們通過編碼階段來實現它，架構師早已不見了蹤影。\

當專案集經理不得不做出壓縮的決定時：我們縮減範圍還是測試？技術人員就得拼命工作了。我們都清楚會發生什麼：我們會做出根本沒什麼價值的產品，它根本就無法工作。\

與之相比，敏捷和精益專案集管理針對專案集採用整體性的方式，並歡迎變更。敏捷和精益專案集經理促進決策的制定和所有層面的交付，而不是專案集經理直接試圖進行控制。\

核心團隊專案集經理幫助大家在業務層的專案集交付。軟體團隊專案集經理幫助軟體組織交付。\

專案集經理不要要求團隊一定要交付的特性。如果他們提要求，那就是確保專案集層的人交付他們的交付物，即特性團隊可以交付特性。\

這意味著專案集產品所有者和產品所有者交付敏捷路線圖，由它匯出劃好等級的待辦列表。\

這就解放了團隊，使之儘可能且經常地自己管理交付價值。\

專案集經理和專案集團隊為該這些團隊移除障礙，為這些團隊掃清交付的道路。\

敏捷和精益專案集經理呈現僕人式的領導風格。架構師、產品經理和產品負責人同樣如是。專案集針對的是對產品交付的優化，而不是任何個人或部門。

\

InfoQ：敏捷和精益如何一起為任何專案集提供幫助？\

\

Rothman：敏捷有助於我們歡迎變更。精益有助於我們理解全域性。當你結合這兩個強大的思想時，會發現專案集經理是關於針對產品交付的優化的。我們在約束條件下可以交付的最好的產品是什麼？\

每個專案集都有約束。而且專案集有著數不清的交流途徑。你什麼何時與何人交流？作為一名專案集經理你與人交流得越多，那麼專案集就會越好。你將清楚風險在哪裡，而不必等他們暴露出來，然後大家就更喜歡與你交流潛在的問題了。\

我們從敏捷和精益獲得透明度和信任，我們可以信任大家去做正確的事。他們每次都將做出正確的選擇嗎？不是的，但這是可以接受的。因為我們是敏捷和精益的，所以只要每個人總保有透明度並隨時交付些什麼我們就能夠從風險中恢復過來。\

使用敏捷和精益，我們會得到交付的環境。特性團隊、專案集團隊，每人每天都在交付著什麼。在每天交付的時候，你不需做太多的計劃、風險管理和調整計劃。所有計劃的制定都很有幫助且很簡捷，於是你就可以保持做下去了。因為事情總會發生變化的，所以如果你可以及時地制定計劃和調整計劃，你就不需要制定太大的計劃或太大幅度的調整計劃。你不會有太大的驚喜，但會有點驚訝的。

\

InfoQ：你在書中提到了Cynefin框架。在專案集管理中如何來使用它呢？\

\

Rothman：我發現Cynefin很有幫助，因為它能指導我解決問題。在Cynefin的框架中我處於什麼位置？如何建立小型的“失敗安全”的實驗？我需要在此就此問題請教內部專家嗎？我需要找能給予我們指導的外部專家嗎？我需要執行所有專案集進行實驗嗎？或者先在那裡執行一些東西看看會發生些什麼？\

專案集，本身不在明確的象限內。在專案集末期它可能會到一個地方，但我們剛開始的時候，可能會處於Complicated（繁雜的） 或者 Complex（複雜的）象限。我們可能會在Chaos（混亂的）象限，但可能性不大。我發現搞明白我們是否已知未知或未知未知會很有幫助。\

如果我理解了越來越多的風險，可能會詢問些不同的資訊或詢問團隊能交付什麼。\

Cynefin幫我們理解什麼是未知的，而且作為一名專案集管理者，我需要做什麼去揭露這些未知並使更多的未知變成已知？這有助於我去推動團隊的交付。

\

InfoQ：如果要建立好的敏捷專案集管理團隊，哪些方面是最重要的？\

\

Rothman：因為專案集團隊是問題解決團隊，我需要知道每個人都能在此幫助解決問題和消除障礙。我需要他們各自領域的代表人物並有時間參與。\

以下是我為軟體專案集團隊做的事：\

1. 請每支團隊決定他們是否需要某人蔘與到軟體專案集團隊裡。如果多支特性團隊協同工作，可能恰恰需要一個人在專案集層的參與。\
2. 詢問每個說將參與的人是否有時間和貫穿該組織的能力，並能參與到專案集團隊中。如果是，那就太好了。如果否，我會和他們一起確定誰將有時間。

對於核心團隊來說，也是類似的。對於核心團隊，我想要確保參與的人都能夠陳述出這份職責，而不僅僅是他或她。

\

InfoQ：管理人員如何幫助專案集走向成功？\

\

Rothman：管理人員能夠提供以下種類的支援：\

1. 確保專案集產品負責人清楚管理人員在路線圖中想要或需要什麼。這個路線圖是每個人能否交付的關鍵。有一種情況極為常見，那就是管理人員下令一個特性集必須在一個時間點內以特定成本完成。這種方式會極大地約束專案集產品負責人和專案集經理。反之，是請管理人員幫助一起定義成功是什麼樣的。\
2. 我看到有些沒有受過敏捷訓練的組織試圖在一個專案集中變得敏捷。大家不知道做什麼。他們不懂在一個團隊中的協作，永遠不會跨組織思考。大家需要培訓。他們可能需要輔導。如果你想要成功，就規劃如何去達成。\
3. 不要為專案集配備多餘的人員。在我們準備好之前我已經成了過多人員的接收者。使用敏捷和精益，你甚至可能不需要所有這些人。\
4. 通過特性團隊進行組織。不要使用元件團隊或服務團隊。這些型別的團隊會產生難以理解的依賴關係，並在你不能再冒險時突然冒出風險。

\

InfoQ：你願意給讀者們說點什麼嗎？\

\

Rothman：我主要想傳達這樣一個資訊：擴充套件協作，而不是流程。\

流程很有用。一旦你理解了敏捷和精益的原則，差不多就能做任何事了。而且，成功的專案集需要跨組織的協作。專案集團隊和小型世界網路都有助於大家的協作。針對交付物使用滾動計劃，經常交付（至少每月一次）將有助於大家看到進展、仍需要做什麼以及哪裡存在風險。\

你要更經常地去關注進展，更經常地收集該專案集各個層面的反饋意見。如果領導有著僕人式的領導風格，就能完成偉大的成就。

\

關於本書作者

\

Johanna Rothman ，知名的“實用主義管理者”，會針對你棘手的難題提出中肯的建議。她幫助領導者和團隊理解問題和解決風險以及管理他們的產品開發。Johanna是十多本書的作者，其中包括：《敏捷和精益專案集管理：擴充套件跨組織的協作》、《專案投資組合祕決：把精力集中於你需要開始和結束的工作的十二個思想》、《潛水探寶：在專案投資組合中尋找價值》（與Jutta Eckstein合著）、《預見不可預知：評估專案計劃或成本的實用方法》。她的更多著作請點選此處查閱。\

檢視英文原文：Johanna Rothman on Agile and Lean Program Management