MSF管理的組隊模型與億泰公司的的項目管理
   
MSF管理的組隊模型與億泰公司的的項目管理

MSF最早由美國微軟公司提出的針對軟件開發與應用服務的項目管理模式。

Microsoft 解決方案框架 (MSF) 組隊模型描述了微軟如何通過構建人員以及人員的行為來實現項目成功。模型專門為小組成員定義了各類角色群、職能領域、職責和指導,幫助他們在整個項目生命周期中實現各自的工作目標。為了在整個 IT 生命周期中將 IT 項目及其操作的成效最大化,Microsoft 解決方案框架和 Microsoft 操作框架 (MOF) 提供了指導文檔和各種成功做法。通過它們,小組可以實現有效的規劃、構建、部署和操作解決方案。MSF 為成功地規劃、設計、開發和部署 IT 解決方案提供了經過檢驗的做法。與規定性的方法相反,MSF 提供了一個可以伸縮的靈活框架,以滿足任何規模的組織或者項目小組的需要。MSF 指導由原理、模型和用來管理人員、項目和技術元素的準則(大多數項目都會碰到)組成。MSF 的指導致力于解決人員、過程、技術和管理等問題。

億泰公司為了能給用戶提供更多更好的通信產品,不但直接派出開發部與技術部骨干人員參與微軟公司舉辦的MSF項目管理學習班,還以此為重心在公司內部開展一系列學習研討,在針對軟件開發與項目管理上充分結合MSF項目管理的理論基礎,結合億泰公司自身企業管理模式,進行了多項管理探討,使理念與工作實踐有機結合,取得了初步成效。以下內容摘錄自微軟公司MSF 組隊模型的相關文章,有關MSF項目管理的詳細文章內容請登錄http://www.microsoft.com/網站。

組隊模型基礎原理

MSF 組隊模型經過數年時間的發展,禰補了傳統項目小組自上而下的層次結構的一些不足。

按照 MSF 組隊模型組織建立的小組是小型、跨學科的小組,在這樣的小組中成員們共同承擔各項職責,權衡彼此間能力差異,以便將主要精力集中到手頭上的工作中。他們擁有共同的項目前景,以部署項目為中心,堅持高標準的質量和溝通,保持樂意學習的心態。本文描述了小組中的各種角色群,以及他們的目標和職能領域。同時提供了指導,以便使用 Microsoft 的方法根據規模和復雜性的高低來建立小組。

下面將概述應用于 Microsoft 組隊模型的 MSF 的各類基礎原則、關鍵概念和成功做法。本章以及整篇文章里的各種主要思想將被重點標出,并將作 MSF 組隊模型的細節進行討論。

MSF 基礎原理

MSF 包括一些基礎原理和框架方法的里程碑。本部分中與成功的小組相關聯的一些原理將被重點標出。

清晰的責任,共同的職責

MSF 將工作進行中需要共同承擔的職責和確保工作如期完成需明確的工作責任結合起來。

MSF 組隊模型基于這樣一個前提,即小組里的每個角色都代表了對項目的一種獨一無二的觀點,但是沒有哪個個人能夠完全代表所有的不同質量目標。為了解決這一問題,MSF 組隊模型把對各種利益相關人的清晰角色職責與實現這個項目成功的整個小組的責任結合起來了。

在小組內部,每個角色通過對小組本身負責(也對他們各自所屬的組織負責)實現該角色的質量目標。在這種意義上,每個角色都對最終解決方案質量的一部分負責。小組成員之間共同承擔職責(根據不同小組角色指派)。角色之間是相互依賴的,有以下兩個原因:首先,就其必要性而言,因為把每個角色的工作分隔開來是不可能的;其次,出于優先的原因,如果每個角色都了解全局情況,那么小組的效率會更高。這種相互的依賴性會鼓勵小組成員對由他們負責的直接區域以外的工作做出評論和貢獻,以確保小組所有的知識、能力和經驗能夠被應用到解決方案里。項目的成功屬于所有的小組成員;他們共同分享一個成功的項目所帶來的榮譽和回報,他們也同時希望,即使是一項不太成功的項目,也能做到全心投入并從中吸取教訓以完善他們的專長。

賦予小組成員權力

在一個高效的小組里,所有的成員都被賦予權力以便根據他們自己的承諾交付任務,并且充分信任小組的其他成員也能實現各自的承諾。類似的,客戶也能夠認為小組將會兌現其承諾,并進行相應的規劃。在最壞的情況下,小組也應該盡快地告知客戶項目出現了哪些延遲和變化。

MSF 小組賦予小組成員權力以幫助他們履行承諾。反過來,MSF 小組又要依賴所有小組成員的整體配合和動力來:

²        準備好向其他成員作出允諾。

²        清楚定義自己擔負的承諾。

²        做出一切合理的努力交付承諾的工作。

²        發現承諾陷入危機時進行真誠的溝通。

由于每個參與者的工作都要依賴于其他小組成員的工作,所以一旦一項活動需要一個以上的小組成員參與,那么他的工作就要受到其他成員工作的影響。然而,小組成員不會花時間監視他們的各項工作是否會對別的小組成員產生影響。有效的小組會逐漸形成一種信任,他們了解同事被授予權力正在履行實現小組目標的承諾。

拿接力隊打個比方。在接力隊中,當第二棒的運動員起跑的時候,他不會減速也不會向后看究竟前一隊員離他有多遠,他只會集中精力全力加速,跑完賽程后回頭接棒,并且他有信心可以從隊友手中順利拿到接力棒。這種信心來源于做法、經驗和信任。

在一個復雜的項目中,小組成員需要逐漸形成一種同級信任,這種信任會在實現每項承諾(無論大。⿻r建立。下面給出了形成這種信任的一些簡單指導思想:

²        賦予小組成員權力,讓其承擔指派的承諾。這種授權包括向小組成員提供進行工作所需的各種資源;負責制定決策以有效影響隊員的工作;理解隊員的權力界限,并不斷增加各種可用途徑來處理越權問題。

²        準備好向其他成員允諾。這些準備包含了心態(進行面談并樂意采取行動)、就緒,并理解承諾的內在含義以及它對當前工作量和資源的影響。這樣做的結果就是,不到小組成員清楚承諾的內在含義,就不要作出承諾。相反,小組成員要提出一個更小的、他們能夠理解的承諾,例如對這些承諾的內在含義進行研究,然后再迅速堅定地作出承諾。對較小承諾的成功交付將建立小組的信任。

²        清晰定義自己擔負的承諾。這樣可以避免一些可能會導致小組成員間信任危機的誤會。

²        做出一切合理的努力來交付承諾的工作。如果一個小組有來自不同組織的成員,那么合理的期望也將因人而異。例如,某些小組成員可能認為在周末工作是合理的;而其他人則可能將他們視為例外或者可能在周末幾乎不會去上班。

²        發現承諾陷入危機時進行真誠的溝通。有時將無法避免事情的變化,原因可能是某些任務的優先級調整、一個意外事件或僅僅是因為一項工作延期完成。及早的進行溝通將使與之相依賴的其他小組成員可以有機會制定相應的計劃。也許他們還可以提出解決這些問題的途徑。

在大多數組織中,這些行為與企業文化是融合在一起的,隊員們已經將它們視為一種文化,因此很少討論它們。但是,MSF 小組有時需要與不同的組織一起工作,在這些組織中的相關的價值觀念并沒有被完全地了解和注重。這些組織常常呈現出一種高度推諉的文化,這種文化約束著應該開放的信息流。在這些情況下,小組領導應當根據這一點來清楚地陳述他們的期望并幫助新的小組成員適應這種工作方式。

聚焦業務價值

MSF 組隊模型提倡將小組決策建立在小組對客戶業務全面的認識以及項目交付過程中客戶能動的參與之上。產品管理角色在小組中擔當客戶的擁護者,這個角色常常由客戶組織中的成員來擔任。產品管理有其業務案例,這些案例保證了從初期戰略工作開始的連續性。產品管理職責的一部分是確保關鍵的項目決策建立在一個健全的業務認識基礎上。

發布管理角色會確保順利的部署和各項操作。通過這些工作,該角色在解決方案開發、部署以及不斷進行的各項操作之間起橋梁作用,它確保項目交付組時刻了解其決策在產品操作過程中對價值交付的影響。

共同的項目設想

MSF 全力提倡采用一個共同的設想,以便把注意力放在小組的工作方法上,包括在一個操作環境里交付 IT 解決方案或是提供 IT 服務

對項目和過程的目標有一個清晰的了解是很重要的。因為小組成員和客戶都在猜測這項解決方案能為組織做些什么。一個共同的設想將使這些猜測明確化,并確保所有參與者都在為完成相同的目標而努力著。共同的設想是 MSF 組隊模型的基礎之一。

當所有的參與者都了解了這一設想并朝著這一設想工作的時候,小組便能夠根據成員使自己的決策與這一設想體現的更為廣闊的小組意圖相吻合,從而獲得他們的權力。

沒有共同的設想,小組成員可能出現與目標相抵觸的觀點,作為一個團體的交付將變得更加困難。并且即便小組完成交付,小組成員也很難確定自己的成功,因為這種成功依賴于他們評價成功的設想。

保持靈活,預測變化

MSF 認為事情在不斷發生變化,將一項 IT 解決方案交付項目與這些變化相孤立是不可能的。MSF 組隊模型確保所有核心的準則在一個項目的始終可用性,這些核心準則將有助于由各種變化引出的各項決策。當新的變化產生,MSF 組隊模型將強化解決這些問題的靈活性。所有小組角色對決策制定的貢獻確保了對問題的深入研究,確保了以批判的觀點對問題進行探討。

推動開放式溝通

從歷史上看,許多組織和項目的操作單純以需要認識為基礎,它將頻繁地導致誤解同時影響了小組交付一項成功的解決方案的能力。

MSF 提出一個開放式的真誠的溝通方式,這種溝通存在于小組內部以及小組與關鍵利益相關人之間。開放的信息流不僅減少出現誤解與成效耗損的頻度,而且確保了所有小組成員可以降低項目周邊環境中存在的不確定性。

同級小組的方法涉及了在關鍵決策中的所有角色。它是共同的小組設想被視為解決方案交付過程的基本開端的原因之一。它也是 MSF 風險管理的基礎,MSF 風險管理全力提倡所有小組成員運用風險意識辨識問題和分析問題,提倡促發一個無推諉的文化環境來實現風險管理。開放的、真誠的討論做好工作的標準以及應該如何改進工作提供了 MSF 尋求營造的學習環境的基礎。

有一些重要的因素可能抑制小組交流的開放性,例如個人和業務信息的機密性。然而,小組成員在決定保留這些信息時應該認真詢問自己,以保證保密的原因確實是不可置疑的。如果小組成員已經通過開放的交流建立了信任關系,并且在大多數場合上都開誠布公,那么他們便能夠向同事解釋之所以這樣做是因為存在高于一切的理由,并且讓同事相信這些理由是以實現項目的最大利益為基礎的。

關鍵概念

MSF 組隊模型的成功實現存在幾個特征。在本部分,這些特征已經被列出并作為關鍵概念進行闡述。

同級小組

“同級小組”這一概念寄予了每個角色同等的價值。它實現了角色間的自由交流,強化了小組的責任觀念,補充強調了六個質量目標都是同等重要且必須實現的。為成功實現平等的小組,每個角色都必須對產品質量負責,必須以客戶的角度思考,必須清楚正試圖解決的業務問題。

雖然每個角色對小組的價值都是相同的,小組的平等存在于角色 之間 ,并且不應該與受多數意見驅動的決策相混淆。每個角色需要某種內部組織層次實現分配工作和管理資源的目的。當小組成員集中精力實現他們各自的目標時,每一個角色的小組領導人都有責任管理、指導和協調小組。

以客戶為中心

滿足客戶對任何優秀的小組來說都被看作是第一位的。在整個開發過程中,以客戶為中心包含了小組對了解和解決客戶業務問題的承諾。衡量以客戶為中心的理念體系獲得成功的方法之一是能否使設計中每一個特性都符合客戶和用戶需求。同樣,實現客戶滿意度的一個關鍵方式是使用戶積極地參與設計并在整個開發過程中提供反饋意見。這樣,小組和客戶都能的使期望和需求更加吻合。

產品理念體系

產品理念不是關于將業務軟件推向市場(像 Microsoft一樣)或是只為內部客戶開發應用程序。產品理念是將您的勞動成果看作產品的理念

實現產品理念的第一步是認識您正進行的工作,它本身是一個項目也是一個大型項目的一部分。事實上,MSF 提倡項目標識的創造,這樣小組成員將更少的將自己視為個體,而更多的視為一個項目小組的成員。Microsoft 使用的一個方式是為項目代碼取名字。這將有助于清楚的標識項目,清楚的標識小組,強化責任意識并且形成提升小組士氣的機制。將小組項目代碼名印制于 T 恤衫、咖啡杯和其他與團體有關的小禮物上也是創造和強化小組標識和靈魂的一種方式。如果小組是由一個組織中的來自多個不同群體的要素組成的“虛擬小組”,這將尤其有用。

一旦您清楚正為一個項目工作,那么無論最后它可否交付,您都應該把它看作是一個產品。那些應用于創造產品的原則和方式(就像 MSF 所提倡的那些)可以被用來幫助確保您的項目成功的交付。

擁有產品理念同時意味著將更多的精力投向執行過程和項目結束時要交付的成品上,而不是投向如何取得這一效果的過程。但這并不意味著過程是無利的或是不重要的,這樣做意味著過程應該為最后的目標服務而不單單只為了利用過程。采用產品理念,小組中的每一個人都會感到背負著產品交付的責任。

前任微軟程序經理 Chris Peters 描述了應用于軟件開發中的產品理念,下面是他在 1991 年所作的講演的摘錄:

“每個人……確切的說都在做相同的工作。他們有相同的工作描述。那就是售賣產品。您的工作不是寫代碼,不是進行測試,也不是書寫規格書。您的工作就是售賣產品。這正是產品開發小組做的工作

”您作為開發者或是測試員的角色是次要的。我并不是說這就不重要了 - 很顯然是重要的 - 但是對您真正的工作來說它是處于次位的,而您真正的工作是售賣產品!

“當您在清晨醒來并投身工作,您說,“工作中心是什么 - 我們正試圖售賣產品還是編寫代碼?”答案是,我們正試圖售賣產品。您并不是試圖去編寫代碼,您應該不僅僅只是編寫代碼。

零缺陷

在一個成功的小組中,所有成員都感到要對產品的質量負責。產品質量責任不能由一個小組成員委托給另一個小組成員或部門。同樣,每個小組成員都要作為客戶的擁護者,在整個開發周期中考慮最終產品的可用性。

零缺陷理念是對質量的承諾。這意味著小組的目標是盡可能最高效地執行工作,這樣即使不得不在明天就交付產品,他們也可以交付出一些東西。這個想法是讓每一天都有一個接近可交付的產品。這并不意味著交付不存在任何缺陷的代碼;這意味這產品滿足或超出了項目出資人的質量要求并在預想階段被小組接受。

用自動機車裝配線作類比最有力的描述了這一概念。傳統上,工作人員將汽車由單獨的部分組裝起來并且為他們自身的質量負責。當汽車下線,一名檢查員進行檢查并判斷該汽車的質量是否達到售賣的標準。然而在這個過程的后期,大量的時間將花費在查找所有的問題上,因為在此時進行糾錯是極富價值的。同樣,既然質量是不可預計的,在后期決定產品是否可售賣所需花費的時間也是不可預計的。

在當前的汽車制造業中,質量已經成為了“第一工作”。這意味著當工作正在進行時(例如正在裝配一扇車門或是安裝一部收音機),檢查員同時審查該項工作以確保它符合為標準的汽車所定義的質量標準。只要在整個裝配過程中保持該級別的質量,那么在后期為確保這輛汽車的質量可接受只需要花費更少的時間和資源。這使生產過程更可預測因為檢測員只需要檢查各個部分的整合處而不是所有個別的工作。

樂意學習

樂意學習包括了對通過收集和共享知識保持自身發展的承諾。它使小組成員可以從犯錯中吸取教訓,也使成員們通過實現他人的成功做法而獲得連續的成功。進行里程碑的溫習回顧和無指責的事后剖析檢討是 MSF 過程模型的組成部分,它們幫助小組進行交流溝通。小組在進度表中安排時間進行學習、回顧和事后檢討,這樣做創建了一個持續進步和贏取不斷成功的環境。此外,微軟成功地建立一種樂意學習的文化,它將學習和知識共享作為個人回顧目標的一部分。

有動力的小組有效率

缺少動力的小組效率低下來自于兩個原因:從個人上說,小組成員表現不佳導致輸出質量和數量的低下;小組成員在狹隘的目標指導下工作,沒有意識到他們的工作將對同事產生的影響。 IT 項目是以高度的知識輸出和相互作用為基礎的。因此這兩個因素對 IT 項目帶來嚴重的負面影響。

MSF 提倡付出努力激發小組的士氣和動力。而在微軟從事工作的人們都將其視為公司定義的特性之一。用來激發小組動力方法有:

²        明確小組設想。

²        構建小組標識,使用項目代碼名字和小組特別物品 — 如吉祥物、T 恤衫、酒杯等等。

²        花時間通過社交和小組活動慢慢了解您的同事。

²        制定計劃確定進行小組建設會議的地點,在那里小組成員能夠體驗各種不同方式的合作和互動,這一地點通常選擇在工作環境之外。

²        確保尊重個人目標,例如提供機會進行個人能力或技術能力發展,協調小組成員工作和生活的權衡。

²        讓小組成員最大的感到授予了權力并積極聽取他們的想法。

²        慶祝成功。

成功的做法

以下成功的做法對 MSF 小組的每個成員有共同的作用,這些做法確保隊員們持續的專注于成功。

小型的多學科小組

小型的多學科小組具有與生俱來的優勢,他們相對與大型的小組具有更迅速的響應能力。因此,對于大型的項目小組來說,在小組中創建小組的效果將更好- 由多個更小的工作組并行工作。一些小組成員具有在特別領域內的專業知識或對特別領域有清晰的了解,他們應在需要的時候在控制下被授權行動。

在小組內部甚至在一個角色群內存在多重學科,這種多重學科要求了一套明確的技能。擁有不同的職業背景、受訓情況和專業領域并組成小組或角色的人都能參與負責整個的產品質量,這取決于他們向各自的角色以及最終向整個解決方案引入的同一的全景設想。

一起工作

組隊模型的目標之一是使溝通不再高不可攀,這樣小組便能減少進行有效交流的障礙。除了小組結構,小組的地理分布和場所位置在小組內部和外部交流的有效性程度上起著主要的作用。

在他們對 Microsoft 的研究中, Microsoft Secrets, Michael A. Cusumano and Richard W. Selby 如此陳述:

“……單一地點的開發提供了項目參與人員在地理上的一個不變動的地域,他們可以集合在一起并且相互交流探索各種想法。頻繁而易于實現的溝通將使較大的問題不至于變得更糟。

將小組集合在一起工作也有助于加強小組標識和小組聯合的意識。

選擇共同的工作場所被以往的經驗證明是促進開放的交流的最有效率的方式,工作場所可以選擇在大樓的同一區、共用的辦公間或是特別為小組成員集合選定的空地旁的環境。開放的交流是 MSF 小組規則中一個獲得成功的基本要素。

雖然共同的工作場所仍是首要選擇,但是業務性質和可供利用的促進交流的技術使得“虛擬”小組得以成功。

在虛擬小組中,小組成員主要依靠電子手段相互交流和協作。交流跨越了組織邊界、空間和時間。與同事通過 Internet 進行實時的合作深遠地改變了人們工作和共享信息的方式。Internet 正成為小組成員間交流的新標準,同時,協作軟件為將來提高工作效率鋪平了道路。

虛擬小組的觀念是關鍵,因為沒有了將各種規則集合成一個協調單元的組織邊界,小組的虛擬性要求小組具有更強的交流能力,信賴協議與關系,使行動項目不至于迷失方向的清晰的行動計劃和支持項目與任務跟蹤的自動化工具。

虛擬小組中的潛在要素是每個角色通過依賴和信任其他角色而履行職責的能力。這種能力的培養來自于文化的交融、良好的管理以及當需要時在相同的地點一起工作的方式。

行業研究發現虛擬小組成員往往不注重交流的技巧和小組和諧。分析師認為這種疏忽是許多虛擬小組失敗的關鍵因素。如果要建立一個虛擬小組,請任用具有以下特征的隊員:

²        能夠獨立工作。

²        顯示出領導技能。

²        擁有開發解決方案需要的特別技能。

²        能夠與組織分享知識。

²        能夠有助于發揚有效的工作方式。

全員參與設計

每個角色都應參與撰寫產品規格說明書的工作,因為每個角色都對設計以及設計與個人目標、團體目標之間關系存在著特別的觀點。因而孕育出一種氛圍,使來自不同觀點中的最優秀的想法能夠顯露出來。

組隊模型概述

為了使一個項目取得成功,必須實現六個關鍵的質量目標,這種理念是 MSF 的基礎。這些質量目標驅動小組并定義了組隊模型。雖然整個小組都對項目成功與否負責,組隊模型還是將六個質量目標和分離的角色群聯系起來以確保義務分明和中心明確。

組隊模型的六個角色群 - 產品管理、程序管理、開發、測試、用戶體驗以及發布管理 - 定義了確定職能領域以及和他們相關聯的職責的通用方式。角色群常常僅僅被看作多個角色。無論那一種解釋,這個概念是相同的:解決方案框架和組隊模型是可伸縮的,以滿足構建一個特別的解決方案的需要。一個角色或是一個角色群,可能包含一個人員或許多人員,這依賴于一個項目的大小和復雜程度,依賴于為完成功能區內的職責而需要具備的各項技能。

MSF 組隊模型強調將各個角色群與各項業務需求相校準的重要性。角色分組和職能領域與各項職責相聯系,職能領域和各項職責分別要求有不同的規則和重心。角色分組為一個協調良好并且各項技能和觀點代表了所有基本項目目標的小組帶來了動力。擁有一個清晰定義的目標將促進對各項職責的理解并且鼓勵項目小組控制項目,這將最終帶來一個更優質的產品。既然每個角色對項目的成功都有決定性作用,那么代表了這些目標的角色在決策時是平等的,具有均等的發言權。

請注意,這些角色群并不表示任何形式的組織機構示意圖或是工作職位調整,因為這些角色群將隨著組織和小組的變化而產生很大的改變。更常見的是,角色將分布在 IT 組織內部的不同組群之間,有時還可能分布于業務用戶社區或者外部的咨詢師和合作伙伴中。關鍵在于清晰的確定履行某一特定角色群的小組個體以及與之相關的有助于目標實現的各種功能、職責和分布。

角色群

目標

職能領域

職責

產品管理

滿足客戶

市場開發

業務價值

客戶擁護

產品計劃

作為客戶的擁護者

驅動共同的項目和方案設想

管理客戶需求說明

開發和維護業務案例

管理客戶期望

驅動產品特征、日程表、資源權衡決策

管理市場開發、產品宣傳和公共關系

開發、維護和執行交流計劃

程序經理

交付滿足項目約束的解決方案

項目管理

解決方案體系結構

過程保證

管理服務

驅動開發過程以期按時的交付產品

管理產品規格說明書 - 首席項目構架師

促進小組內部的交流和商議

維護項目日程表和報告項目狀態

驅使關鍵的權衡決策的實現

開發、維護和執行項目總規劃和日程表

驅使和管理風險評估和風險管理

開發

根據規格說明創建解決方案

技術咨詢

實現的構架和設計

應用程序開發

基礎結構開發

指定物理設計的特征

估算完成每個特征所需的時間和精力

構建每個特征并監督其實現

準備部署時使用的產品

為小組提供技術主題的專門知識

測試

在所有產品質量事宜被識別并處理后進行發布

測試規劃

測試工程

測試報告

確保了解所有問題

決定測試策略和制定計劃

執行測試

用戶體驗

提高用戶效率

技術交流

培訓

可用性

用戶界面設計

國際化

易用性

為項目小組充當用戶擁護的角色

管理用戶需求說明

設計和開發性能支持系統

驅動可用性和用戶性能增效的權衡決策

為用戶提供幫助特點和幫助文檔的規格說明書

開展和提供用戶培訓

發布經理

進行平滑的部署及日常運行

基礎結構

支持

操作

業務發布管理

作為各種操作、支持與交付渠道的擁護者

管理所得

管理產品部署

驅使可用性和可支持性權衡決策

管理各種操作、支持和交付渠道之間的關系

為項目小組提供后勤支持

滿足客戶

項目必須滿足客戶和用戶的需求,并且以滿足客戶與用戶需求作為成功的標準。項目可能只實現了預算和時間的目標但卻沒有滿足客戶的需要,那么這種項目仍是不成功的。

發布滿足項目約束的解決方案

所有小組的一個關鍵目標是發布滿足項目約束的解決方案。任何項目的基本約束包括預算和日程進度的約束。大多數項目使用“按時、按預算”作為評價成功的標準。

根據規格說明創建解決方案

產品規格說明詳細的描述了小組提供給客戶的可交付產品。精確的按照規格說明交付產品對小組來說是很重要的,因為規格說明書代表著小組與客戶之間的一項協議。

在所有產品質量事宜被識別并處理后進行發布

所有的軟件在交付時都存在缺點。一個關鍵目標是確保那些缺點在發布產品之前被確定和處理。處理涉及了從修復存在疑問的缺陷到為這些周邊工作的解決方案提供文檔的所有工作。相比交付一個存在未辨識缺陷而在稍后也許將驚呆小組和客戶的產品,交付一個已知錯誤而這個錯誤已被處理并提供了周邊工作解決方案的產品更為可取。

提高用戶效率

為實現項目成功,用戶工作和操作的方式必須實現改善。交付一項擁有豐富特性與內容但卻無法被目標用戶所操作的產品將被認為是失敗。

進行平滑的部署及日常運行

有時進行平滑部署的需要會被忽視。部署的理解也被或對或錯地帶入了產品本身。例如,一個錯誤的安裝程序可能導致用戶認為安裝好的程序也同樣存在錯誤,既便這可能并不是真實的情況。因此,小組不應只做簡單的部署;小組必須爭取實現一個平滑的部署并為產品的支持和管理做好準備。這些內容可以包括在部署前確保培訓、基礎結構和支持的準備就緒。

組隊模型角色群

Figure 1: Team Model Role Clusters

1:組隊模型角色群

產品管理角色群

產品管理角色群的關鍵目標是滿足客戶。小組必須讓項目滿足客戶的各種需求,以實現成功。然而,首先要做的是清楚的確定和了解客戶!在某些案例中,客戶要求的解決方案和特性集將與項目支持和投資商的要求不同。因此小組必須進行清晰區別和需求分析,提出使雙方都獲益的因素。只有這樣,定制和滿足期望的職責才能夠被指派到恰當的職能領域內。有可能項目只實現了預算和時間的目標而沒有滿足客戶的需要,那么這個項目仍是不成功的。

MSF 組隊模型為每個角色群規定了不同的職能領域以便更為精細的定義一套職責,角色通過各項職責的履行形成一套常用技能集。

為了實現滿足客戶的目標,產品管理角色群要求有多個職能領域:產品規劃、業務價值、客戶擁護和市場開發。

職能領域

市場開發

²        驅動銷售和影響目標客戶的公共關系訊息

²        高度區別化,使解決方案在競爭獲得優勢

²        通過零售商配銷使目標客戶能夠容易獲得產品

²        提供支持,使客戶在購買和使用解決方案時有肯定的體驗

²        為項目定義和維護業務解釋

²        定義和評價業務價值實現業務價值

客戶擁護

²        驅動共同的項目和解決方案設想

²        管理客戶期望和溝通

產品規劃

²        收集、分析客戶和業務需求并按優先級排序

²        執行市場研究、市場調查和競爭情報與分析

²        確定業務效績評價與成功標準確定

²        多版本發布計劃

市場開發

市場開發是籌劃宣傳、銷售和配銷一個產品、解決方案或服務的過程或技術。市場開發包括幾個方面:啟動市場、維持市場與公共關系。在一個解決方案生命周期的進程中,市場開發的中心將發生轉移。了解您的解決方案在生命周期中的市場定位對執行適當的行動是至關重要的。

業務價值

在業務價值職能領域內,產品管理為客戶、業務決策制定者 (BDM) 提供他們所要求的簡明的預測方法 以判斷花費在一項 IT 解決方案上的投資對業務活動所帶來的財務上和操作上的回報。

為有效的提供一個可用的解決方案,產品管理必須了解客戶的業務活動、各種成功因素和關鍵工作指標?梢詫@得這些知識的過程定義為業務價值評定或關鍵性成功因素辨識。很明顯,了解使客戶獲得成功的方式有助于確定和提出恰當的解決方案。隨著規律性的漸增,進行 IT 投資需要進行深入細致的調查,許多 IT 相關的解決方案都需要在項目停止前進行財務評議。通過進行客觀的支出回報分析,滿足客戶的可能性將增加。財務結果的計算完善了進行 IT 投資的業務解決方案的開發。

客戶擁護

這一職能領域包括了高級別交流和客戶期望管理的職責。高級別交流包括了公共關系、高級管理/客戶簡報、市場推廣、演示和產品啟動。一旦項目設想被確定,期望管理將成為產品管理的關鍵角色。期望管理被認為是首要的角色,因為它可能決定成敗。

有效進行期望管理的重要性可以用例子來描述,假如小組預期交付給用戶 10 個產品特性(數據是隨便給出的)。如果小組實際只交付了 2 個產品特性而不是客戶所期望的所有 10 個,那么這個項目無論對客戶還是對小組來說都是失敗的。

然而,如果產品管理在特性開發和產品研發期間與客戶維持好持續的雙向交流,客戶期望將得以實現而保證最后的成功。產品管理可以包括讓客戶參與權衡決策制定過程以及告知客戶不斷變化的風險和其他難題。與之前的情形不同,客戶能夠評估開發狀態并且同意小組在指定時間能交付所有的 10 個產品特性是不現實的,而只交付了 2 個卻是可以接受的。在這種情形下,交付 2 個產品特性現在符合了客戶的期望并且雙方都會認為這個項目是成功的。

產品規劃

產品規劃確定了為解決方案的多個版本所設定的要求和特性。產品規劃的目標是使程序經理或開發人員盡可能以最少的時間更容易地理解一個解決方案的要求。首先,它要求完全理解解決方案的當前要求- 業務需求是什么,客戶如何使用該解決方案,支持的要點有什么以及有哪些可用的供選擇的方案。其次,檢查那些為使用該解決方案的客戶實現增值的特性,例如實現新業務內容的入口、與其他系統的集成、更優良的工作效率、從其他解決方案上升級、減少支持費用等等。以這些知識為基礎,產品規劃員能夠推薦出指派給每個解決方案版本的特別的特性并且為這些特性按優先級進行排序。

產品規劃的核心是研究和分析。了解客戶和業務的需求以及競爭狀況,并給予研究和分析恰當的關注。這將防止在解決方案中加入不必要的特性。

程序管理角色群

程序管理角色的中心是實現在各類項目約束內交付解決方案的目標?梢詫⑵淇醋龃_保項目出資人滿意項目成果的過程。為實現這一目標,程序管理控制和驅動工作日程表、特征定制和項目預算。程序管理確保了在適合的時間交付出適合的解決方案,確保了在整個項目進程中理解和管理項目出資人的期望。以下是被選定的職能領域的描述:

程序管理

²        跟蹤和管理預算。

²        管理總的項目工作日程表。

²        驅動風險管理進程。

²        促進小組內部交流和商議。

²        跟蹤項目進度和管理項目狀態報告管理資源配置。

解決方案體系結構驅動全面的解決方案設計。

²        管理功能規范說明。

²        管理方案功能范圍和各類關鍵權衡決策。

過程保證

²        驅動進程質量保證。

²        定義和推薦改進。

行政服務實現

²        項目管理進程,支持小組領導使用它們提供一套行政服務。

²        支持有效的小組工作。

項目管理

作為項目日程的控制者,項目管理收集所有小組日程,確認這些日程,并將他們整合到總日程表中?側粘瘫肀桓櫽涗洸蟾娼o小組和項目出資者。

作為項目預算的控制者,項目管理通過從小組中所有角色收集資源需求促進項目預算的建立。項目管理必須理解和贊同所有的資源決策(硬件、軟件以及人員)并且跟蹤實際開支。小組和項目出資人都應收到該狀態報告

此外,項目管理還協調各種資源,促進小組交流,幫助驅動關鍵性決策

解決方案體系結構

解決方案體系結構是程序管理角色群的職能領域,它對解決方案的邏輯設計和功能規范負責。解決方案體系結構專注于確保一個解決方案能夠被指定的用戶使用,以達到指定的有效性、效率、滿意度目標。

解決方案架構師的責任包括:

²        促進解決方案的總體設計。

²        管理功能規范。

²        管理解決方案范圍和關鍵性取舍決策。

擁有著邏輯設計的解決方案體系結構提供了解決方案的業務部分(像概念設計中產品管理的描述)和解決方案的技術部分(像物理設計中開發的描述)之間的至關重要的連接。解決方案體系結構扮演了功能規范管理人的角色。它促使小組與它們的其它角色的需求一起就解決方案的內容和設計達成一致,并證明已經被項目風險投資者同意的方法是正確的。它還對支持需求的功能的可追蹤性負責(并最終完善業務價值),因此所有支持規定需求的功能都是可見的,且改變任一功能小組都可以評定其對解決方案價值的影響。

解決方案體系結構行為包括:

²        創建解決方案概念,并以客戶的企業體系結構進行編排;設計版本發布策略;審查需求獲取規劃。

²        從結構/標準工作組和互操作相關處獲取需求;促進邏輯設計程序;提供一個可追蹤映象來跟蹤支持需求和利益的功能;創建功能規范;定義臨時發布。

²        管理功能規范的變更;維護可追蹤映象;為其它小組角色和外部風險承擔者闡明規范;就互操作問題同其它項目小組保持聯絡。

²        參與篩選過程;管理項目風險投資者期望的解決方案內容。

²        為企業體系結構小組提供更新;為未來的版本發布更新需求

解決方案體系結構實施者的技術必須是可靠的,它們需要擁有廣博的知識和經驗,還要有能力使技術問題同潛在的業務需求發生關聯。雖然對于被用于解決方案的具體技術解決方案,架構師可能依賴開發小組向他們提供專業知識,不過他們肯定能迅速抓住那些解決方案細節的本質,了解它們的內在聯系以及它們對部署解決方案的環境的影響。解決方案架構師肯定還能夠同客戶的架構師討論那些影響,使得他們可以迅速的解決被提議的解決方案同企業體系結構之間的任何沖突。

過程保證

程序管理的過程保證職能領域確保項目小組采納的過程致力于適應項目整體目標、強調排除有缺陷的消息來源。過程保證對兩個主要的區域負責:

²        定義被小組使用的關鍵項目過程,為小組的執行提供建議與指導。

²        承擔過程、建議改進、和一致性監控的審查,以驗證它們的關聯性和有效性。

 

過程保證致力于下列行為:

²        定義符合項目設計的項目協議和過程。

²        為項目過程的有效執行提供建議和指導;驗證過程的一致性;承擔里程碑的審查;建議過程改進。

由于得益于一個獨立于項目小組的地位,過程保證能夠有一個客觀的看法。因為這個原因,它經常從項目小組的外部進行管理,即使項目的大小使它不能成為一個專職的角色。

行政服務

本職能領域屬于程序管理角色群,對執行項目管理過程和為項目小組提供行政支持負責。

項目行政職能領域確保項目小組執行過程符合項目管理定義的項目設計規范。它對確保項目小組能在最小的官僚作風下有效的運轉負責。

項目行政責任包括:

²        利用它們執行項目管理過程和支持小組領導。這包括統一小組輸入以維護總體規劃與進度,幫助領導程序報告。

²        提供一套諸如安排日程會議、常規獲取、以及合同管理這樣的行政服務來有效支持小組工作

項目管理致力于:

²        支持諸如有效的從第三方召集小組成員;管理合同安排;組織小組設施(空間、電話、安全訪問等等)這樣的項目啟動過程。

²        建立統一的規劃框架;幫助小組領導規劃和日程安排;統一小組輸入以維護總體規劃與進度;建立財政與進度報告過程。

²        幫助小組領導進度報告;構建整體進度和財政報告。

²        確保在項目完成時關閉所有的行政系統。

²        執行一般的行政支持行為。比如:安排日程會議;執行風險與問題管理過程;維護主要風險表、操作表等各種表單;生成財政和進度報告;管理小組工作場所以提高士氣。

項目管理角色需要一個強有力的行政能力的組合,關注項目規劃和日程安排技術中的可靠經驗的細節,還有對供應方組織中的運作規則和指導方針的良好的了解。一個大型的項目為在項目指導旁邊工作提供一個極好的機會,確立了指導未來的項目需要的經驗。

開發角色群

“規范構建”目標是關注 MSF 項目期間的開發角色群。為了成功達到它的質量目標,開發角色構建了一個解決方案,它符合客戶期望和在功能規范中表述出來的規范。開發角色群依附于解決方案體系結構,并與來自全面解決方案規范的功能規范一起設計它。

除了是解決方案的構建者之外,開發還為小組提供了如同技術顧問一樣的服務。作為一個技術顧問,它為設計和技術選擇決策提供輸入,也為確認決策產生和減輕開發風險構建功能模型。

作為構建者,開發提供低級別解決方案和功能設計,評估這個設計交付所需要的工作,然后構建解決方案。開發之所以評估它自己的工作和計劃,是因為它每天都和所有進展的可能性因素在一起工作。MSF 把這個概念看成是從底層向上的評估,而且它還是 MSF 方法的一個基本部分。它的目標是取得一個更高質量的計劃,增加那些提供評估的角色和他們執行工作時的責任。

技術咨詢職能領域

²        為小組提供像技術咨詢一樣的服務。

²        評估和確認技術。

²        積極參與到功能規范的創建和評審中。

²        為組織定義開發標準作出貢獻。

執行體系結構和設計職能領域

²        通過向體系結構的具體的解決方案細節提供應用程序、數據、技術,為解決方案的執行體系結構映射企業體系結構(EA)決方案。

²        擁有和執行邏輯的與物理的解決方案設計。

應用程序開發職能領域

²        編碼符合設計規范的功能。

²        在開發期間管理代碼審查,以共享知識與經驗。

²        完成由測試角色支持的測試規劃定義的單元測試。

基礎結構開發職能領域

²        開發符合設計規范的功能。

²        在開發期間管理代碼審查,以共享知識與經驗。

²        完成由測試角色支持的測試規劃定義的單元測試。

²        開發自動化部署腳本。

²        開發部署文檔。

技術咨詢職能領域

技術咨詢職能領域提供一個如同技術資源的服務,貫穿在項目生命周期中。作為一個技術咨詢者,開發必須在高級設計、評估和驗證技術中提供輸入,并在開發過程的早期引導研究以減輕開發風險。

在預想階段,這個職能領域致力于從執行的前景來分析用戶/客戶需求。為了通過項目的初始參數確定實施的可行性,職能領域評估項目技術的本質,促使對設想/范圍文檔的定義。它為執行方法的正反兩面的可能性和有效的技術初始技術的選擇提供指導。在這個過程中,職能領域可能會管理研究,與組織內部或別處的相應的人進行協商,并同技術供應商保持對話。對于附加的驗證,職能領域可能開發一個被當成驗證概念進行服務的有限功能模型。這在項目關聯中是獨特的,它要求新技術的使用或者應用在項目小組缺乏經驗的領域內。

執行體系結構和設計職能領域

執行體系結構和設計職能領域描述在一個 MSF 項目中,與解決方案的執行體系結構定義和解決方案設計的開發相關的一組責任。

從設計的立場看,程序管理對解決方案的整個體系機構負責,它被部署在企業體系結構中。對企業體系結構向解決方案的執行體系結構的映射,開發通過提供具體的解決方案細節向其負責,具體包括解決方案的應用程序、數據、以及技術。

MSF 提出了一個三級設計過程:概念設計、邏輯設計、和物理設計。程序管理和產品管理共同擁有概念設計。概念設計包括了用戶情境、高級可用性分析、概念數據建模、以及初始技術選擇。開發擁有解決方案設計中的邏輯和物理方面。邏輯和物理設計要求對解決方案中相關技術和技術選擇帶來的影響的了解。

應用程序開發職能領域

應用程序開發職能領域描述了與一個 MSF 項目中的軟件開發相關的一組責任。開發角色在整個職能領域中的主要責任是為被要求的解決方案構建功能,其中涉及到的內容包括:規范和設計、管理單元測試、處理在測試過程中查出的質量問題、為生產最終產品完成解決方案組件整合。

開發角色在解決方案過程中始終堅持促進標準的定義。開發管理代碼審查,以評估單元級別的應用程序功能的質量等級。審查允許項目小組成員共享開發知識與經驗、支持 MSF 的目標“自發學習”。測試角色主動的同開發角色一起工作,為解決方案特征計劃和管理獨立的質量評估,就如同一個完整的解決方案一般。

基礎結構開發職能領域

基礎結構開發職能領域描述了在 MSF 項目期間與系統開發相關的一組責任。系統基礎結構包括一個分布式計算環境的網絡接觸結構、客戶端和服務器系統、以及所有支持組件。軟件基礎結構包括客戶端和服務器操作系統、還有提供必須的平臺軟件服務的軟件產品,比如:目錄、通信、數據庫、企業應用程序集成、系統管理。網絡管理等。

在基礎結構開發期間,開發角色“開發”設計中規定的基礎結構。這包括為解決方案配置基礎技術解決方案,比如:網絡支持、設計中定義的客戶端和服務器系統;A結構的各個方面可以被其所支持的應用程序的需求所影響,反之亦然。比如:一個關鍵項目高性能解決方案可能需要分組供應和后端服務器均衡負載。解決方案的操作系統和平臺產品需要適當的開發。各式各樣的軟件平臺產品必須被安裝、配置、和優化以適應解決方案的需求。在適當的測試與穩定處理之后,基礎結構解決方案在發布管理的掌握下在大規模配置,其中發布管理管理著解決方案基礎結構需求的獲取。

測試角色群

測試角色群的目標是只有當所有的產品質量問題被識別出來并被處理后,才可以批準發布。所有被交付的產品都是有缺點的。關鍵的目的是在發布產品之前,確保那些缺陷被識別出來并被處理。在維修被質詢的缺陷的過程中,編制解決解決方案文檔的處理幾乎涉及到了一切。交付一個缺陷已知且被處理的有解決解決方案的產品,比起交付一個有著未被識別的缺陷的產品要好得多,因為稍后小組和用戶就會為之大吃一驚。

要想成功,測試小組角色群必須致力于幾個主要的責任。那些責任被分組在三個主要職能領域中。

測試計劃

²        開發測試方法和規劃。

²        參與設置質量規則。

²        開發測試規范。

測試工程

²        開發和維護自動測試案例、工具、和腳本。

²        管理測試以準確確定產品開發的狀態。

²        管理構建過程。

測試報告

²        為小組提供產品質量相關的數據。

²        在產品發布之前跟蹤所有的錯誤和交流問題來確保他們的解決方案。

測試規劃

測試規劃職能領域是測試角色群的一部分,它致力于使小組知道如何確保所有的產品質量問題被識別且處理。

測試角色開發測試方法和規劃,并為小組測試解決方案之策略描繪輪廓。這些規劃包括具體類型的測試、具體測試區域、測試成功標準、和資源(硬件和人員都是)中需要測試的信息。

測試規劃職能領域的一個重要部分就是通過為項目小組的質量控制方法和規則提供輸入,參與設置質量規則,以確保解決方案的成功。

測試規劃職能領域的最后一個行為是開發測試規范。這是對需要工具和代碼符合的測試規劃的定義的詳細描述。

測試工程

作為測試角色群的一部分,測試工程職能領域致力于完成測試規劃中定義的行為,這是確保所有產品質量問題被識別出來且被處理所必須的。本域所定義的責任是:開發和維護測試案例的具體職責;開發工具、腳本、以及文檔來執行測試功能;進行日常構建的管理,以確保測試規程能以單個參考標準執行和報告;還有管理測試以準確確定產品開發的狀態——同當前的構建一起,通過運行測試案例、工具、和腳本來識別問題。

跟蹤和報告

作為測試角色群的一部分,跟蹤和報告職能領域致力于清晰的向項目小組表達解決方案中普遍錯誤的和普遍正確的是什么,從而使開發狀態能被精確的描繪出來。

問題跟蹤的執行是為了確保所有被識別出來的問題在發行之前已經被解決。問題狀態文檔包括了分配、優先級、決定、和解決,它們全部都頻繁的向小組提供與當前產品質量狀態和詳細趨勢分析有關的數據。

用戶經驗角色群

用戶經驗角色群的目標是提高用戶效率。用戶經驗由六個職能領域組成:易用性、國際化、技術交流、培訓、可用性、和圖形設計。為了使解決方案被成功執行,用戶經驗角色群在每個職能領域中都有一些必須被管理的責任。下面是職能領域和相關責任的列表。

易用性

在設計中促進易用性概念與需求。

國際化

改善解決方案在國際市場中的質量和可用性。

技術交流

²        為支持系統設計和開發文檔(helpdesk 手冊,KB 文章等等)。

²        幫助/輔助文檔。

培訓

開發和實行學習策略(構建/購買/交付)。

可用性

²        收集、分析、區分用戶需求。

²        為解決方案設計提供反饋與輸入。

²        開發使用情境和使用案例。

²        為項目小組擔當用戶辯護者。

圖形設計

²        促進用戶接口設計。

易用性

易用性職能領域致力于通過促進設計中的易用性概念和需求,確保解決方案對那些有缺陷的人來說是易用的。易用性的重要是有很多原因的。最主要的一個方面,易用性很重要是因為不論人們的能力如何,產品和解決方案應該對所有人來說都是易用和可用的。一個產品或者解決方案沒有在易用性上得分將缺乏完全的采用率。另外,遵從易用性可以符合政府法規的要求。

易用性觀念和需求必須在整個解決方案開發周期中被提出,且必須包括:

²        每個功能規范內的易用性部分的結合。

²        將易用性信息集成進解決方案幫助部分。

²        確保易用性文檔的完善。

²        確保易用性文檔以易用的格式呈現。

國際化

國際化職能領域中的責任是提高解決方案在國際市場中的質量與可用性。國際化職能領域由全球化和本地化過程兩部分構成。

全球化

全球化是一個定義和開發解決方案的過程,它考慮解決方案本地華化的需要,其內容要么沒有改變,要么沒有本地用戶不需要的工作區。換句話說,一個徹底全球化的發行解決方案即是為了打算進行最小難度的本地化。

本地化

解決方案本地化包括改變解決方案用戶界面、幫助文件、印刷品和聯機文檔、行銷內容、還有Web站點。有些時候,這些內容可能需要為某個特定的語言版本改變為圖形元素,甚至進行內容的更改。

技術交流

技術交流職能領域致力于解決方案文檔支持系統的開發。

技術交流職能領域的一個主要責任是創建諸如幫助工具這樣的工具組件。這種幫助工具能夠為用戶的基本的問題、關鍵字描述、錯誤解釋、和經常被問到的問題提供答復。像幫助工具這樣的工具可以使用戶和組織雙方得利。用戶得利是因為他們的問題和詢問通過及時有效的方式得到了回答。組織則得益于降低了支持成本。

技術交流職能領域得一個補充責任就是為解決方案設計和開發文檔。這可能包括安裝、升級、操作、和疑難解答指南的開發。

培訓

培訓職能領域致力于通過提供有效使用解決方案需要的技能知識,來提升用戶執行能力。這個技能知識轉移是通過執行一個學習策略來實現的。學習策略的開發是用戶經驗小組角色群的責任。

學習策略的開發可能在組織內部進行,或者外包給一個專門進行培訓和開發的組織。不管實際上是誰開發這個學習策略,這個方法通常都由以下部分組成:

²        對用戶和企業的目的與目標進行分析。

²        設定期望的技能級別集合。

²        開發和執行一個培訓規劃。

²        在執行時,測度培訓規劃的可行性,對培訓規劃進行適當的修改,以保證執行的成功。

學習策略可能由以下的一個或幾個交付機制組成:教師指導培訓、技術交付培訓、自主學習或使用工作幫助。很多組織選擇了混合方法來適應這種單獨的自主學習風格。

可用性

可用性職能領域致力于保證解決方案可以被特定的用戶使用,并高效且令人滿意的完成規定的目標。

可用性職能領域定義的一個主要的責任是可用性研究,它包括收集、分析、區分用戶需求。通過在早期以及貫穿解決方案工作中的了解客戶工作上花費時間,項目將更有可能性有效的適應客戶需要。

可用性職能領域中定義的另一個主要責任是開發使用情境和使用案例。這里的主要打算就是設想和考慮整個解決方案多大程度上可能被使用。這個工作幫助開發小組從一個整體和直觀角度了解了用戶如何處理解決方案,這通?梢詫е略O計被改進,從而使有效性增加。

可用性職能領域中定義的最后一個主要責任是為解決方案提供反饋和輸入。通過在整個開發周期中花費時間把用戶反饋提供給開發人員,解決方案將因此獲取一個更高的用戶滿意率。

圖形設計

本圖形設計職能領域致力于確保解決方案中的圖形原理的設計是恰當的。圖形設計職能領域的主要職責是推動用戶界面的設計。這包括設計用戶打算與之結合的對象(還有應用于那些對象的操作),還包括接口的主要畫面。

發布管理角色群

發布管理角色群的目標是使部署流暢和持續操作。發布管理是直接參與 MSF 小組操作的角色。它包含了下列職能領域的責任:

²        扮演項目部署和操作工作組的主要支持者。

²        為發布行為和驅動最優化自動管理工具選擇。

²        為產品發布設置運作標準。

²        參與設計,致力于易管理性、可支持性、以及可部署性。

²        推進操作訓練。

²        為首次部署提供促進和建立支持。

²        規劃和管理生產解決方案部署。

²        確保穩定性測量以達到驗收標準。

基礎結構

²        企業基礎結構規劃

²        通過地理布局協調物理環境使用與規劃(數據中心、實驗室、外部辦事處)

²        為小組的統一的基礎結構管理和標準提供規則和規程。

²        MSF 小組提供基礎結構服務(構建服務器、標準映像、軟件安裝)。

²        為小組管理軟硬件采購。

²        構建準確反映生產環境的測試與分級環境。

支持

²        IT 用戶提供第一位的聯絡與客戶服務。

²        通過同客戶管理 SLA 支持業務,保證承諾被實現。

²        提供事件與問題決議;對用戶需求和日志事件作出快速反應。

²        向開發和設計小組提供反饋。

²        開發故障轉移和恢復規程。

操作

²        帳戶和系統設置控制;管理用戶帳戶和權限。

²        通信、數據庫、遠程通信操作;網絡操作。

²        系統管理、批處理。

²        防火墻管理;安全管理。

²        應用服務。

²        主機集成服務。

²        目錄服務操作。

業務發布管理

²        產品注冊碼;注冊驗證程序。

²        許可管理。

²        封裝。

²        管理銷售渠道。

²        出版物與電子出版物。

基礎結構

基礎結構職能領域描述了一組責任,涉及到在 MSF 項目中必須令人滿意的操作基礎結構。它是 MSF 發布管理角色群的一部分。至于那些應用了 MOF 的項目,它們符合 MOF 基礎結構角色群的責任。

支持

本職能領域致力于確保解決方案的構建和部署是 可支持的。至于那些應用了 MOF 的項目,它們符合 MOF 支持角色群的責任。

操作

本職能領域描述了一組在 MSF 項目中必須令人滿意的操作責任。本職能領域致力于保證解決方案的構建和部署在同其它服務進行操作時的可操作性和兼容性。至于那些應用了MOF的項目,它們符合 MOF 支持角色群的責任。

業務發布管理

本職能領域描述了涉及到業務軟件產品發布的一組責任。業務發布管理致力于在渠道中獲取產品。

按比例縮放組隊模型

Microsoft 從前的軟件開發人員 Steve McConnell 的書 快速開發中,他寫道:

“大型項目要求組織實行公式化且簡單有效的交流!械倪M行簡單有效交流的方法都依賴于建立各種層次,也就是建立小型的擁有與小組同樣功能的工作組,然后從這些工作組中選定一些代表來相互組合,并與管理相結合!

MSF 提倡把大型小組(那些多于十個員工的小組)分解成小型的、功能齊全的小組。這些小型小組并行工作,并經常進行同步工作。

另外,功能小組可能被用于一個要求多種資源來適應需求的特別角色,并因此被組合在這個角色中。

功能小組

在組隊模型中,每個角色群都由組合在一個層次結構中的一個或多個資源組成(盡管它們是盡可能的扁平)。測試人員向一個測試經理或領導匯報就是一個例子。

覆蓋在這個結構之上的是功能小組。這都是些小型的下級小組,它們把來自每個角色的一個或更多的成員組合進了一個模塊組織中。然后這些小組被賦予了一個具體的功能,并對它所有的方面負責,包括設計與計劃。例如,一個特征小組可能被指定去設計和開發印刷服務。

Steve McConnell 寫進 快速開發:

“功能小組在授權、責任性、以及平衡上具有優越性。小組可以被靈敏的授權,因為它代表性的包含了……每個相關的人員。小組在它的決策中包含了所有的觀點,因而很難出現一個超越它的決策的基礎!

“因為同樣的原因,使這種小組變得有責任。他們所有人員需要的,制定好的決策的權限。如果他們沒有制定出好的決策,除了自己他們誰也無法責備。這種小組是平衡的。您不能期望開發、市場、或者質量保證在一份產品說明書中各有一個獨立的最終說辭,不過您可以從每個種類包含的一組代表性的說法中取得一個平衡!

Figure 2: Feature Teams

2:功能小組

備注: 本圖例并不是描繪組織功能小組的需求。舉個例子,并不是所有的功能小組都需要用戶經驗角色;這些小組都是為了迎合它們的解決方案關注的目標而按需組織的。

功能小組

功能小組是在一個角色內部存在的小組。它們的存在是因為一個小組或項目的人員過多,以至需要將一個角色內部的員工根據職能來進行基于小組的分組。Microsoft 公司就是一個例子,它的一個產品開發小組通常擁有一個產品規劃人員與一個產品生產人員。兩個工作都是產品開發的一個方面:一個致力于取得客戶真正需要的功能,另一個則集中注意力把產品的優點向潛在的用戶傳達。

這對開發同樣是正確的,開發者可以通過他們工作的服務階層來分組:用戶、業務、或者數據。通常開發者還可基于他們是解決方案構建者還是組件構建者來分組。組件構建者通常是低級語言 C 的開發者,他們構建的可復用組件可以由企業調節。解決方案構建者來通過把這些組件封裝在一起來構建企業應用軟件。解決方案構建者通常使用像 Microsoft® Visual Basic® 這樣的高級語言來工作。

功能小組常常被包含在工作組內部的一個層次結構種。比如在程序經理向一組程序經理進行匯報的同時,他們還通過領導程序經理向上進行匯報。像這樣的結構同樣可以在功能領域出現,且要優于角色群集層次。要牢記的重要事情就是:這個層次不可以阻礙項目級別的組隊模型。角色的目標和它們的整個項目小組的責任性都被保留下來。

共享角色

即使組隊模型由六個角色組成,一個小組還是不需要達到六個成員的最小值。它也不需要每個角色一個成員。關鍵的地方是每個小組中的六個目標必須被表現出來。有代表性的是,每個角色有一個成員可以幫助確保有人照顧到每個角色的利益,不過不是所有的項目都可以從這樣的填滿每個角色的情形中受益。通常,小組成員必須共享角色。

在小型小組中,角色必須被小組成員共享。兩條原則指導角色共享。第一條原則是開發小組成員不能共享一個角色。開發人員是項目構建者,他們不能從他們的主要任務中分心。為開發小組添加附加的角色時,由于產生了這些附加的責任,只不過增加了偏離計劃的可能性。

第二條指導原則是盡量不要使有內部利益沖突的角色被組合。例如,產品管理和程序管理因為有利益沖突而不能被組合。產品管理希望滿足客戶,相反的,程序管理希望按時按預算交付。如果這些角色被組合,同時客戶又要求變革,那么出現的風險不是變革沒有達到預期以維持客戶滿意,就是在沒有理解給項目帶來的影響的情況下被接受。擁有不同小組成員,表現了這些角色幫助確保了每個觀點都受到了平等對待。如果嘗試組合測試與開發,這一條同樣是適用的。

下列表格說明了組合角色的風險(由"Not Recommended"或"Unlikely symbols"標識)和促進作用(由"Possible"記號標識),不過對任何小組的做法,成功的角色共享還涉及到現實成員自身和他們帶來的經驗和技能。

4:適合小型項目的角色組合

橫排和縱排交叉處是 N 的,表示這些角色不被推薦來進行組合。因為有利益方面的沖突,除非有絕對的必要,或者關聯的風險可以被關聯風險的緩解與應變計劃處理。很顯然,這些角色的目標在多個層次上都有沖突,這將使組隊模型不穩定,并增加了組合時出現問題的可能性。角色組合并不罕見——如果小組選擇小巧的組合,并積極的管理相關風險,問題發生的幾率將會降至最低。

逐步升級與責任性

MSF 組隊模型不是一張組織結構圖

當應用 MSF 組隊模型的時候,一個問題經常被問起:“誰是主管?”。一張組織結構圖描述了誰是主管以及誰向誰負責。與之不同的是,MSF 組隊模型描述了主要角色以及項目小組的責任,但是沒有從全體職員管理的角度來定義管理結構。在很多案例中,項目小組的成員來自于幾個不同的組織,在行政上對不同的管理者負責。

這里有幾個確定的情況可能會出現,盡管如此,小組仍然不能對其中的觀點達成一致。在付出了應有的努力達成一致后,就到了程序管理角色逐步提高,并為項目的向前推進進行重要領導的時候了。程序管理角色的首要目標是在項目限制下完成交付,時間就是其中的一個限制。因而,這個角色和小組要完成這個目標,程序管理角色會有很多次臨時成為的最高決策下達者,以便使項目回到軌道上來。在這些圖例中,領導地位特有的至始至終都被共享,這些角色理解這種變動的必要性,它為組隊構建了一種更為健壯的可接受的層次并通過權威決策大宗買進,以達到實現項目目標的目的。這個問題一旦被解決,小組就可以達成一致,并立即共享領導地位責任,F在已經證明了同等級組隊的靈活性與可適應性足夠處理這些挑戰,并為項目組隊留下了一種無分層方法。

外部協調——誰應當負責?

為了保證組隊的成功,還必須和其他外部工作組相互影響、交流、以及協調。這些工作組的范圍涉及顧客、用戶、還有其他開發小組。在多數案例中,那些與小組在某點上聯系的顧客都會要求解決方案存在明確的責任性。雖然同等級的小組在解決方案的成功交付中要求共享責任,不過對于交流規劃中的責任性和報告結構文檔的清晰的區分是很重要的,因為這樣顧客和開發小組都能懂得小組中誰對促進這個信息負責。

下列圖表說明中列舉的具有代表性的責任,不是協調業務中心就是協調技術中心。程序管理、產品管理、用戶經驗、以及發布管理是主要的促進者。這些角色都是內在和外在的中心,盡管開發和測試都是以內在的中心并與外部交流相隔絕。

不過這并不意味著開發者和測試者將會與外部世界相隔絕。對于 MSF 小組期望達成的建立以客戶為中心理念的來說,與顧客組織和真正的用戶的接觸是無價之寶,特別是在早期的項目成形階段。不管如何這種交流都不能淪為形式,因為在項目后期,這將使致力于解決方案交付的開發小組和測試小組遭遇麻煩。

4:責任性

本圖表描繪了一個高水平的前景。富有特色的是,小組必須同更多的像質量保證、財政、法律這樣的外部工作組協調。與外部工作組的接口的清楚與明了是很重要的,開發與測試繼續保持隔絕,這樣可以保證它們不受干擾的進行有效的工作。

另外,有一個重要的地方需要強調,當進行外部協調的各種角色能夠提供輸入與建議的時候,不要讓單個的成員或是作為整體的小組擁有修改項目交替使用的,像功能、計劃以及資源這樣的優先級和細節的權限。這些改變都是項目客戶與監護人的特權,并由項目小組執行。這也為由均等伙伴和對等者組成的小組通過組織權限、層次、和結構,如何服從與結盟提供了一個例子。

小結

MSF 組隊模型并不能保證項目一定成功。除了小組結構之外,有著更多因素決定著一個項目的成功與失敗。不過小組結構仍然是很重要的。

在 快速開發中,Steve McConnell 舉例說明了這一點:

“即使您擁有了有技術、有動力、辛勤工作的員工,錯誤的小組結構也能夠消弱他們的努力,而不是飛速的前往成功。一個不良的小組結構會增加開發時間、降低質量、使士氣低靡、增大周轉期間,最終導致項目取消!

MSF 組隊模型正好是來處理這個問題的。恰當的組隊結構是成功的基石,貫徹這個模型并且運用它的優先原則能夠幫助小組,使之更加有效,因而取得成功。

 

部份內容摘錄于http://www.microsoft.com/網站

 

 
 
 
MSF管理的組隊模型與億泰公司的的項目管理
中文字幕国产在线播放