探討Microsoft Solution Framework(MSF)框架下管理的秘密
hello,同學們,同胞們,同志們,同齡們,這樣們,那樣們,們們們,我又回來寫“論文”了,半年時間沒見我發佈任何博文,是不是認為我被潛規則了啊,哈哈。我想死你們了。好了,廢話不多說,進入今天主題:
你的軟件開發團隊有這樣的一些問題嗎: 日程安排一團糟、功能不合適、到處都是系統錯誤,而原因就是左撇子不知道右撇子在做什麼,一想到要出下一個版本,就覺得頭暈想吐,神出鬼末的缺陷,殺之不盡的缺陷,無止境的加班,對計算機完全失去興趣,萌生轉行的念頭。
……
在談軟件開發團隊之前,我們先看看優秀的團隊,都具備怎樣的一些特點?
英明的領袖
優秀的個人
嚴明的紀律
良好的溝通
一致的目標
協調的行動
良好的團隊氛圍
良好的習慣
(更多的優秀特點請參閱PMBOK)
— 您的團隊有這樣的特點嗎?
MSF,全稱是Microsoft Solution Framework,微軟解決方案框架(模型),不是什麼技術框架,而是微軟進行研發活動的方法論。微軟的研發團隊是讓人羨慕、讓人關注的團隊,微軟的研發團隊是如何工作的?本文我們來一起探討一下。
原文鏈接在此:https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb497060(v=technet.10)
下載鏈接在此:https://download.microsoft.com/download/2/3/f/23f13f70-8e46-4f44-97f6-7dfb45010859/MSF_v3_Overview%20Whitepaper.pdf
雖然這個框架(模型)是微軟十幾年前(2004年)的產物了,但很多模式和思維,都被不少團隊管理進行學習和研究,或者,你的一套管理論中就有他,請繼續往下看。
MSF的八大原理
軟件開發團隊管理有自身的特殊性,它更強調:
激發大家的潛能和創意。
讓每一位成員有機會成為“牛人”。
充分發揮“牛人”的作用,並讓牛人和其他團隊成員和諧地工作。
讓每位成員投入到創造性的工作中,享受成功的愉悅。
軟件開發團隊是一個種很特別的團隊,很容易形成群眾領袖,這種領袖並不是公司任命的,而是在實際工作中通過突出的工作表現,在所有成員的心目中自發形成的,這些人就是我們常說的“牛人”,這些牛人是最讓公司又愛又恨的人了,如何讓管理好這些牛人,如何讓牛人們和諧地工作,這是軟件開發團隊管理的一大難點。微軟可以說是牛人如雲了,微軟的團隊管理有什麼秘密呢?
微軟的MSF有以下八大基本原理:
一、開放式溝通(Foster open communications)
The MSF Process Model enables an open and free flow of information among the team members and key stakeholders to prevent misunderstandings and reduce the probability that work will have to be redone. Documenting the progress of the project and making it available to the team members, stakeholders, and customers can best achieve this.
幾乎90%的團隊問題,都可以歸結為溝通問題,“溝通管理”已經成為團隊管理中最泛濫的一個詞語,“開放式溝通”具備以下的特點:
即時、主動:溝通時馬上進行溝通,感覺到有問題時馬上進行溝通,事後諸葛亮是為人所不齒的。
有效:最直接最有效的方式溝通,抓住要害,準確表達,盡量簡短。
形式多樣:儘可能多的最合適的方式溝通,面對面談話、郵件、msn、QQ等,哪種方式最有效最直接,就用哪一種。
參與:人人參與,人人都要主動溝通,同時也要主動去和每一個人溝通。團隊每一位成員都參與到每一個活動中。
包容:聆聽各方面意見,鼓勵不同意見。
直接、坦誠:不需要拐彎抹角,不需要諸多粉飾,用最直接最坦白的話來表達。
對事不對人:戴有色眼鏡看人,所有的溝通都是為了把事情做好。
二、為共同的願景而工作(Work toward a shared vision)
The MSF Process Model provides a phase (the Envisioning Phase) and a separate milestone (Vision/Scope Approved) for creating a shared vision. A vision includes detailed understanding of the goals and objectives that the solution needs to achieve. A shared vision highlights the assumptions that the team members and customers have for the solution.
簡單的說就是大家的目標要一致,並一起為這個共同的目標努力工作。所有偉大的軟件必定有一份宏偉的願景文檔,該文檔描述了軟件將會帶來什麼社會價值、經濟價值,開發本軟件的目的是什麼,本軟件應用的範圍、領域,本軟件能解決什麼業務問題,本軟件有什麼特性等等。如果達不到以下任何條件之一,都不能算“為共同的願景”工作:
這個願景是大家一起來制定並一致通過的;
團隊中的任何一個人在任何時候都能清晰地說出本項目的願景的大致內容。
用願景來指導工作,明確工作的重點,明確工作的方針,用願景來解決工作中的分歧。
很多人都會喊團隊需要有一致的目標這樣的口號,能不能做得到?以上三點就是檢驗的標準。
三、授權團隊成員(Empower team members)
Empowering the team members implies that the members accept responsibility and ownership of work assigned to them. Team empowerment can be achieved by preparing schedules where the team members commit to complete their work on a fixed date. This makes the team members feel accountable and also provides a method for identifying any potential delays early in the project.
“在最優秀的小組裡,不同的個人會在不同場合下體現出其領導能力,他們會在其專長的領域裏擔負起領導職責。沒有哪個人是永遠的領導,因為如果這樣的話,這個人就無法和其他人融為一個整體,而小組的互動會因此而開始分裂。小組的結構應該是一個網絡型的而不是一個層次型的。”
據我們所知,微軟的團隊是沒有固定的領導的,因為任何人都是領導,每位成員都有不可替代的作用,每位成員在自己專長的領域中擔當領導的作用。
四、建立清晰的責任和共同的職責(Establish clear accountability and shared responsibility)
The MSF Team Model is based on the principle that each role is accountable for the quality of the solution. All the team members share the overall responsibility of the project because the project can fail due to a mistake made by a single member.
測試一下大家對這點的理解,如果你的團隊中出現這樣的問題,這樣處理是否合適?
項目進度推遲、項目預算超出計劃,公司領導把項目經理叫去,嚴厲的批評了一頓,而沒有責備過任何其他項目成員。
軟件發佈出去後,發現嚴重的缺陷,公司領導把測試人員叫去嚴厲批評,也沒有責備過任何其他項目成員。
你們的團隊中,有沒有這樣的情況?
只有項目經理為項目的進度、預算勞心勞累,其他人都在“安分”地完成“本職”工作,不會主動過問其他情況。
出現問題時,誰是問題責任人的皮球會被踢來踢去,沒有人願意承擔責任。
為什麼有這樣的問題呢?應該如何處理呢?是責任定得不夠清晰嗎?
團隊的每一位成員,肩負起自己所在領域的責任,團隊的每一位成員共同對最終解決方案負責,同時鼓勵小組成員對非他們直接負責的領域作出評論和貢獻。
軟件開發團隊中,有項目管理、需求分析、設計、編碼、測試等各個領域的人才,每領域的負責人對自己的工作負責。另外一個方面,軟件是團隊共同勞動成果,所有人對最終的解決方案負責,最終解決方案只有有問題,就是整個團隊的責任,最終解決方案取得優異成績,就是整個團隊的功勞。軟件開發團隊,是一個“一榮俱榮、一損俱損 ”的團隊,只有這樣才能把全部人的利益扭在一起。
了解這個原理後,大家對前面提到的問題有答案了沒有?
五、專註業務的價值(Focus on delivering business value)
The solution must deliver value to the organization in the form of business value. This business value is achieved only after the solution is completely deployed into the production environment.
客戶需要的是一把梯子,產品分析並設計的是一張凳子,開發人員做出來的是一張桌子,測試人員卻以為是一張椅子。看上去可笑,但這樣的情況卻經常發生在我們的身邊。
專註交付的業務價值,意思就我們工作中的每一份工作產品,都應該是需求驅動做出來的,這樣才能保證我們最終做出的軟件就是客戶所需要的東西。這個原理有以下幾層意思:
小組成員要對客戶的需求有一致的充分的理解。
要讓客戶積极參与到項目過程中去,隨時了解小組的理解和客戶的需要是否一致。
需求驅動地完成所有工作,保證最後的軟件產品符合客戶的需要。
六、保持靈巧,擁抱變化(Stay agile, expect change)
MSF assumes that the solution will encounter continuous changes before being deployed to the production environment. The team should be aware and prepared to manage such changes.
expect change,確切的翻譯應該是期待變化,但是“期待”的不是主動的,而是被動的,就像我期待物價不要上漲,但結果還是會上漲。正好我前幾個月在何師燒烤駐場的時候,看到過他們的警示語:“擁抱變化”,擁抱 這個詞,是主動的,是積極的,正如回到物價的問題上,明知要100%會上漲,已經無法改變的事實,那麼不幹脆接受他,積極的擁抱他。換一種說法,我們懷着積極的心態去擁抱他的變化,對他的變化提出可行的解決方案,這才是我們作為項目管理者應該要做的。
軟件是智力型創造性活動,保持靈活、適應變化是軟件開發的最高境界了!我感覺這條原理是最難把握的一條了,至今都是非常難於把握。這個原理主要體現在以下方面:
軟件開發過程
微軟採用的不是RUP,也不是XP,而是類似於螺旋形的階段式分版本發佈。微軟會把軟件分成若干的版本發佈,除了平時我們見到的Beta版、Release版、RTM版,其實在Beta版之前還會有若干的內部版本。每個版本都包含相對完整的功能,都能實現部分業務價值。每一個版本就是一個開發周期,每個周期包含願景、計劃、開發、穩定、部署五個階段。這樣的一種開發模型,能很好地適應需求變化,發現設計、編碼缺陷,優化設計,更容易控制軟件質量,便於隨時做出商業決策。
設計方案
執着於優雅設計的人士,可能很喜歡做出完美無缺的設計,關注於業務的人士,可能更關注於盡快要拿出軟件。我們追求的是適度設計,而不是過度設計,如何做出一個簡單的而又適應變化的設計,是對軟件設計高手們的一大考驗。
七、投資 質量(Invest in quality)
In MSF, each team member is responsible for the quality of the solution. To confirm the quality throughout the project’s duration, a test team is formed. This ensures that the solution meets the quality level of the stakeholders.
“質量第一”是很多軟件公司的口號,而且僅僅是口號而已,你們的項目有這樣的一些問題嗎?
代碼沒有經過簡單的冒煙測試,甚至不進行是否通過編譯的測試,就直接提交。
為了趕時間不寫設計或者寫了不能指導編碼的設計文檔。
開發進度推遲,測試時間被壓縮,為了保證軟件發佈的時間,在不充分測試情況下交付軟件,更甚者不測試軟件,直接讓客戶測試。
開發過程中發現的問題,只要能不解決的就不解決,進度優先!
測試中發現的易用性方面的缺陷,因不會嚴重影響使用,一律不解決!
質量投資要求我們有零缺陷的意識,零缺陷意識要貫穿在全部的工作中,包括:
零缺陷文檔:計劃、需求、設計等開發過程中產生的文檔,要用一次寫好的決心來編寫,所有文檔都應該發揮它的價值,而不是為了寫文檔而寫文檔。要讓相關的小組成員對該文檔發表意見,重視他們的意見並修改文檔。
零缺陷代碼:要用一次把代碼寫好,不讓測試發現缺陷的態度來寫好代碼,寫出垃圾代碼是不負責任的行為!
零缺陷發佈:用質量投資的態度對待所有缺陷,包括自己代碼產生的缺陷,對用戶負責,不滿足質量要求的軟件堅決不發佈。
全體小組成員都應該同步達到零缺陷里程碑,本着一步一個腳印、不斷追求高質量的態度來完成全部工作。
八、學習所有的經驗(Learn from all experiences)
MSF states that the experiences derived from one project should be used and shared with teams in other projects. These experiences can also help to identify the best practices that should be followed in your organization.
像Windows這樣的一些偉大的軟件,都是經過很多人通過很長的時間做出來的,工作量之大、難度之大不亞於一些偉大的建築工程。軟件工程與建築工程最大的優勢就是,如果軟件做得不好,可以推倒重來,但建築工程就不能這樣做了。
我拿軟件工程與建築工程比較,目的就是想強調做軟件是很強調學習的,很強調不斷改進的(當然建築工程也重視學習)。我們應該慶幸,我們這些做軟件的要比做建築工程的要幸福的多了,我們不太可能犯一些不可以彌補的錯誤。“那些忘記過去的人肯定會重複過去(的錯誤)。”
我們要讓大家從自己或者別人的失敗和成功中學習,要幫助小組成員再次獲得成功,捕捉和共享技術的或者非技術的最佳實踐,並想辦法讓學習制度化。學習制度化的辦法很多,如項目總結、例會等,但要注意的是學習應該是隨時進行的,抱着學習一切可以學習的態度來工作。
微軟的項目團隊結構
談了微軟MSF的八大基本原理,我們來看看,微軟的團隊是怎樣組成的?
很多軟件公司的開發團隊,大部分是由一名項目經理,若干項目成員組成,項目成員包括需求分析、架構設計、編碼、測試等角色。
而微軟的MSF團隊定義非常特別,他們是沒有項目經理(實際Program Management 就是 Project Management)的,由6類角色組成,分別是產品經理(Product Management)、程序經理(Program Management)、開發(Development)、測試(Test)、發佈管理(Release Management)、用戶體驗(User Experience)。
角色
目標
職能領域
職責
產品管理
滿足客戶
市場開發
業務價值
客戶擁護
產品計劃
為項目小組充當客戶角色
驅動共同的項目和方案設想
管理客戶需求說明
開發和維護業務案例
管理客戶期望
驅動產品特徵、日程表、資源權衡決策
管理市場開發、產品宣傳和公共關係
開發、維護和執行交流計劃
程序經理
交付滿足項目約束的解決方案
項目管理
解決方案體系結構
過程保證
管理服務
驅動開發過程以期按時的交付產品
管理產品規格說明書 - 首席項目構架師
促進小組內部的交流和商議
維護項目日程表和報告項目狀態
驅使關鍵的權衡決策的實現
開發、維護和執行項目總規劃和日程表
驅使和管理風險評估和風險管理
開發
根據規格說明創建解決方案
技術諮詢
實現的構架和設計
應用程序開發
基礎結構開發
指定物理設計的特徵
估算完成每個特徵所需的時間和精力
構建每個特徵並監督其實現
準備部署時使用的產品
為小組提供技術主題的專門知識
測試
在所有產品質量事宜被識別並處理後進行發佈
測試規劃
測試工程
測試報告
確保了解所有問題
決定測試策略和制定計劃
執行測試
用戶體驗
提高用戶效率
技術交流
培訓
可用性
用戶界面設計
國際化
易用性
為項目小組充當用戶的角色
管理用戶需求說明
設計和開發性能支持系統
驅動可用性和用戶性能增效的權衡決策
為用戶提供幫助特點和幫助文檔的規格說明書
開展和提供用戶培訓
發佈管理
進行平滑的部署及日常運行
基礎結構
支持
操作
業務發佈管理
管理產品部署
驅使可用性和可支持性權衡決策
管理各種操作、支持和交付渠道之間的關係
為項目小組提供後勤支持
微軟的MSF團隊模型中的6種角色,不代表團隊最少要6個人組成,一個人可以兼任多種角色,也不代表每一種角色只有一個人,可以多個人公擔一個角色。微軟這種團隊結構與我們常見的團隊結構相比,有這樣的特點:
扁平對等的團隊結構,強調每個人的價值
這種團隊結構,是“賦予小組成員權力”、“清晰的責任和共同的職責”、“推動開放式溝通”這三個原理的表現。這樣的結構,讓每位小組成員都感受得到自己的重要性,項目的成敗與每位成員直接相關。這樣的結構更容易調動每位成員的工作積極性,更容易讓團隊激發工作熱情,產生更多的創造性成果。
微軟很重視的我們常會忽略的用戶體驗和發佈管理
微軟團隊的6種角色所負責的工作,覆蓋了軟件開發中需要考慮的各個方面,用戶體驗、發佈管理是常被我們忽視的地方。微軟軟件的用戶體驗都非常好,規範一致的界面,詳細的幫助系統,良好易用的安裝程序,良好的技術支持等。微軟創造了很多界面規範,操作習慣,這些都是我們需要認真去學習的。
知識(儲備)管理
軟件開發團隊是知識密集型的團隊,學習再學習,是軟件開發團隊的重要特點。沒有學習的團隊,是沒有活力的!
如何保證團隊的每位成員都具備完成本項目的能力呢?就緒管理就是來解決這個問題的。
小組成員的6種角色,需要不同的技能來完成本職工作,任何一種角色技能的欠缺,都會影響最終解決方案。小組應該根據項目的願景,列出各成員所欠缺的技能,這些技能包括技術方面的也包括非技術方面的,安排相應的學習計劃、培訓計劃,保證每位成員的技能都達到要求。
知識管理還包括知識的共享和積累、技能的評估、技能提升機制等。從微軟提供的系列認證,如MCSD、MCP等,大家就可以感受到微軟系統的培訓制度。項目團隊的知識管理,應該在組織層面上進行,跨越項目組進行,每位團隊成員都可以學習其他團隊的經驗,每位團隊成員都可以共享知識給其他的團隊。
風險管理
MSF團隊提倡積極主動的風險管理、持續的風險評估,並在整個項目和運營生命周期內融入風險決策。對風險進行持續的評估、監控和積極的管理,直到風險得到解決。MSF團隊風險管理流程定義了六個邏輯步驟,團隊使用這些步驟來管理當前風險、計劃和執行風險管理策略,以及為企業獲取知識。
識別風險:風險識別的過程要求所有團隊成員參與風險的識別,使團隊意識到潛在的問題。作為風險管理過程的輸入,應儘早進行風險識別,並在整個項目生命周期內頻繁重複。
分析並確定優先級:風險優先級使團隊能夠投入項目資源來管理和決策最重要的風險。
計劃和時間表:風險規劃從風險分析和優先順序中獲得,並將其用於制定戰略、計劃和行動。風險調度確保這些計劃得到批准,然後納入項目管理過程和基礎設施,以確保風險管理作為團隊日常活動的一部分進行。風險調度明確地將風險規劃與項目規劃聯繫起來。
跟蹤和報告:風險跟蹤監控特定風險的狀態及其各自行動計劃的進展情況。
控制:風險控制是執行風險行動計劃及其相關狀態報告的過程。風險控制還包括當風險狀態或風險計劃的變化可能導致項目特徵、資源或進度的變化時,啟動項目變更控制請求。
學習:風險學習將從項目中獲得的經驗教訓形式化,收集相關的項目工件和工具,並以可重用的形式獲取這些知識。
(感覺這裡跟PMBOK差不多)
結語
MSF的團隊管理辦法,似乎就是解決我們開發團隊管理問題的靈丹妙藥。但實際上沒有這麼簡單,這種管理辦辦法要成功,還必須滿足這樣的條件:
必須要有坦誠、積極、向上的企業文化 。沒有這樣的文化,什麼“推動開發式溝通”、“質量投資”等原理是難以做到的。
團隊中每一位成員都是能力相當水平相當的,沒有素質特別差的成員 。這點做不到,是很難應用“為共同的願景工作”、“賦予小組成員權力”等原理的。
實際上這兩點都是很難做到的,微軟是通過招聘優秀的人來滿足這兩個前提條件,另外美國文化下成長的軟件開發人員,都是很有主見,溝通很主動,表達能力強,也注重自我價值的,而我國開發人員,很多是少說話多幹事(大多是擼起袖子加油干),表達能力特別是書面表達能力差的。當然難做到不代表做不到,MSF的團隊管理中有很多值得我們學習、品味、實踐的地方,我們要做的是掌握其精髓,結合我們自己的實際情況,靈活地用起來。