在國內，不少做過幾年程式設計師，被同事、圈內的朋友公認為技術水平不錯的人，在考慮自身職業發展的時候，可能會想當然的認為：「我可以做專案經理了，感覺做個專案經理也沒啥特別難的」。
但如果你真的有機會，去嘗試帶乙個團隊，哪怕是只有幾個人的乙個小te am的時候，你就會發現，你必須面對一系列的問題和麻煩，而這些事情的處理結果，基本上和個人技術水平無關。
舉一些例子：
「自己每天被領導施壓，忙忙碌碌，累得**，可手下的幾個人，卻讓人覺得他們閒的發慌」。
「給他們布置的任務，好像怎麼也做不完，一拖再拖，個人感覺是很簡單的事情」。
「好容易分工做完了幾個模組，整合起來卻怎麼都不對，老是出現錯誤，還得我自己親自動手修改處理」。
「交給了客戶乙個測試的版本做展示，客戶第一句話就是：這個不是我們想要的」。
「眼瞅產品交付的最後期限逼近，可軟體的問題層出不窮，錯誤百出，這怎麼能讓客戶滿意並且驗收簽字呢？」。
「天天加班，把人搞得生理時鐘失調，晝夜顛倒，做這個專案的人怨聲載道，整**氣沖沖，威脅辭職、罷工」。
……在具體的軟體專案運轉中，這些令人頭痛的問題接連不斷，常常把人搞得焦頭爛額，心煩意亂，任你技術水平再高，都沒用。俗話說的好：「你渾身是鐵，能碾幾顆釘」。事必躬親，大包大攬的結果只能是把自己累垮，工作還沒做好。在軟體越來越複雜，需求多變的情況下，個人英雄主義、單打獨鬥是行不通的，幹活還得靠大家。
痛定思痛，你也會很聰明的想到：我必須使用軟體工程方法、開發流程來管理我的團隊。但你真的要在團隊中套用上鼎鼎大名的cmm，更令人沮喪的事情還在後面：cmm中光是那一堆名詞和文件，就夠大家理解好久的了。而且，這些標準、指南更像是評分手冊，可操作性不足。專案組好像整天在忙，老是開會，煩不勝煩，搞出一大摞文件，真正的軟體卻總是出不來。
還有不少其它的專案管理方法、指南，也是難以在實際環境中操作應用。
你必須找到適合自己公司團隊的開發流程、框架，不僅要完整，而且必須有良好的可操作性，比較靈活，適應範圍廣泛。所以，向在軟體專案管理上成熟、完善的公司學習，是個很有效的辦法，能讓你迅速掌握在專案管理上的各種方法和技巧，並且上公升到理論水平。
在軟體行業，微軟公司的軟體產品眾多，產品線齊全。這個軟體巨人在各個市場上取得的成功也是有目共睹，其軟體專案的開發、管理過程也一直是大家很感興趣的焦點。
筆者有幸參加了一次軟體專案管理的培訓，由微軟中國顧問諮詢部門的講師主講，為期三天，大有斬獲。好多困擾已久的問題和疑惑得到了解答，有種豁然開朗的感覺。
課程內容是msf－microsoft solutions framework，微軟解決方案框架，所謂msf，就是微軟公司定義的用於軟體專案管理的一套完整的流程、方法。講義是從英文教材翻譯過來的，msf的版本是3.0。你可能會覺得奇怪，怎麼這個框架還有版本。嗯，沒錯，微軟公司的講師聲稱，當visual studio .net 2005發布的時候，會整合、攜帶msf 4.0一起面市。
因為msf自身也是根據軟體產業環境，根據新的思想、新的理念、新的實際專案經驗不斷調整，不斷演進的，並不是教條。如3.0版本的過程模型中，就比2.0版本多了乙個稱為部署階段的過程。
msf是由微軟公司的全球產品組、諮詢服務部門、資訊科技部、微軟的合作夥伴共同協作，分析、總結經過實踐檢驗的正確經驗，對比業界的方法，彙總而成，是關於「人和過程」的指南。它的特點就是實戰性很強，對專案整個過程的指導很完整。而且，它是通用的體系，不管你用什麼技術，做什麼專案，都有可以參照的準則。
msf主要包含了兩套模型、三個準則。模型正好涵蓋了「人和過程」：團隊模型、過程模型。三個準則：專案管理準則、風險管理準則、就緒管理準則。
在講師講述團隊模型的時候，很有趣，讓我們5個人一組，分組做了乙個讓人印象深刻的實驗。這也是這套課程的獨到之處，講師上課，並非照本宣科的講，而是在學習過程中，穿插了多個實驗和具體的專案例項，讓大家在乙個臨時組織的團隊中，體會理論的含義，加深消化理解。
這個實驗並不複雜，就是模仿大家日常工作中最常見的、專案小組的結構化組織形式，小組包含乙個「老闆」，乙個專案經理，多個團隊成員。由「老大」發號施令，讓專案經理指揮自己團隊的人執行，然後看結果。等15分鐘的時限過去，「老闆」揭示「成果」，小組成員要當眾發表感想。難以想象，平時我們認為那麼自然的組織結構，竟然有這麼多缺陷！
專案經理：太累，不懂領導到底要啥。
團隊成員：閒得無聊，不知道要幹什麼。對工作沒有積極性，不主動。
這樣的結果就是：領導和專案經理的個人能力，基本決定了專案成功的可能性。
然後大家開始分析為什麼會這樣，原因在**，於是就引入了msf的團隊模型。
當然這個實驗模型為了突出問題，做了很多簡化，但在實際環境中，這些缺陷是確確實實存在的。
msf的團隊模型中，分成了6個角色，這6個角色是：程式管理、開發、測試、發布管理、使用者體驗、產品管理。每個角色之間是平等的關係，沒有上下級的行政差別。
這幾個角色並非一定要和人一一對應，當你沒有足夠的人手時候，一些角色可以重疊，由乙個人兼任，但開發不推薦和其它角色兼任，這是因為要保持開發的封閉性。
當你的團隊人數眾多，規模比較大的時候，可以把大團隊劃分成小團隊，再由核心團隊總攬。既可以按照軟體功能、特性來分成功能團隊，也可以根據職能劃分，例如，程式管理角色有多個人擔任。這充分體現了msf非常靈活、務實的一面，適應性很強。可以用於幾個人的小team，也可以適用於規模很大的團隊。
敏捷軟體開發理論適應性就弱些，大家公認不太適合超過10人的團隊組織，而且，對成員的要求更高。
在另外乙個模型－過程模型裡面，msf敏捷的一面又顯露了出來。通過把複雜的專案分成多個版本進行迭代開發，來充分的簡化專案難度。每個版本都有自己要完成的功能範圍，可以看成乙個「小專案」，專案小了，複雜度、難度自然大大下降，當然成功的概率就高的多。而且，和專案相關的人能很快的評估專案成果，來決定專案的「下一版本」方向。
在每個專案過程中，都包含乙個很完整的階段，專案構思、專案計畫、專案開發、專案穩定、專案部署。從專案構思到專案部署結束，每個環節都有很多的所謂「里程碑」成果。就是每個階段都有很明確的要求，到底要拿出什麼成果。而這些成果，是需要團隊成員共同努力來取得的，正好和團隊模型相互結合。
在專案的任何乙個階段，每乙個團隊成員都要有成果，大家是並行工作的。這樣一來，就避免了傳統組織方法的很多弊病，如開發沒結束，測試難以進行。在這樣的模型中，不再是乙個上司發號施令，下面的人去被動執行，已經演變成了大家都能積極主動的參與進來，每個人都有事情可以做。不同的角色在不同的專案階段，分別起到主導作用。
課程中還有乙個很重要的msf原則貫穿其中，那就是風險。所謂風險，簡單的說就是事件有可能發生，但是不確定何時何地。
團隊最早開始做的事情之一就是管理風險，我們通過分組，在課堂上模擬了一遍，很有意思。每個人根據實驗要求，挖空心思，冥思苦想，想象在專案過程中到底會發生什麼事情，判斷可能性和後果。連團隊成員懷孕，無法繼續工作這種事情也被找了出來，戲劇性的是，乙個學員就承認，自己的團隊就遇見了這樣的麻煩，而且還不知道到底應該怎麼辦。
管理風險的目的就是把握主動權，在風險發生的時候能迅速處理，從而保證專案能順利進行下去。這樣一來，客戶會對我們更有信心，更信任我們，專案成功的可能性會進一步提高。
課程的後面，就是具體的專案執行過程了，如專案計畫的制定、開發、穩定、部署等等。其中不乏精彩的觀點和指導方針，讓你有法可依。
這就是我在msf培訓結束後的體會和總結。
理論和實踐從來都是相互交織的，沒有理論，做事情就沒有章法，沒有後勁。缺乏實踐，理論就變得十分空洞，陷入空談。你必須把理論不斷的應用於專案管理實踐，才能不斷的成長、成熟。
所以在這裡向大家推薦「微軟解決方案框架」這套理論和課程。
大家可以去
和微軟合作的培訓組織
想成為專案管理者的各位好漢，準備好了嗎？
軟體專案的需求變更管理
一 做好需求工程 需求分析是軟體工程專案最重要 最基礎的起始階段，為後續的規劃設計階段提供參照依據。在軟體研發專案過程中一定要樹立需求工程的意識，將需求視為一項系統工程。為了能夠全面做好需求管理，應根據專案實際情況嚴格劃分專案階段，清晰界定 定義專案階段的基線，在每個專案階段制訂 執行階段性需求管理...
專案的知識管理
隨著軟體專案的功能越來越複雜，技術越來越先進，分工越來越細緻，資訊越來越龐雜，互動越來越頻繁，對專案的有效控制越來越缺乏，對專案的規模 進度 資源估算越來越困難，專案的可交付產品越來越豐富，因此，知識管理對軟體專案管理的重要性日益顯現，也引起了越來越多人的重視。遊戲設計 專案的知識管理 專案的知識管...
專案的過程管理
加強專案的過程管理，可以及時發現專案中出現的弊端，防微杜漸，是保證專案實施的必要手段。一 專案組的成立與分工 現在的軟體開發，除非小系統，一般都是多人同時參與開發，因此，合理的分工將提高工作的效率，甚至影響專案的成敗！分工時，應結合專案組成員的個人優勢，根據專案所涉及的不同方面進行分工，使不同的 某...