程式設計師公升級專案經理後的 管理之癢

2021-04-13 05:28:16 字數 3737 閱讀 2055

程式設計師公升級專案經理後的"管理之癢"

發布單位:中國專案經理網資訊中心 發布日期:2007-05-18

在國內,不少做過幾年程式設計師,被同事、圈內的朋友公認為技術水平不錯的人,在考慮自身職業發展的時候,可能會想當然的認為:"我可以做專案經理了,感覺做個專案經理也沒啥特別難的"。 

但如果你真的有機會,去嘗試帶乙個團隊,哪怕是只有幾個人的乙個小team的時候,你就會發現,你必須面對一系列的問題和麻煩,而這些事情的處理結果,基本上和個人技術水平無關。 

舉一些例子: 

"自己每天被領導施壓,忙忙碌碌,累得**,可手下的幾個人,卻讓人覺得他們閒的發慌"。 

"給他們布置的任務,好像怎麼也做不完,一拖再拖,個人感覺是很簡單的事情"。 

"好容易分工做完了幾個模組,整合起來卻怎麼都不對,老是出現錯誤,還得我自己親自動手修改處理"。 

"交給了客戶乙個測試的版本做展示,客戶第一句話就是:這個不是我們想要的"。 

"眼瞅產品交付的最後期限逼近,可軟體的問題層出不窮,錯誤百出,這怎麼能讓客戶滿意並且驗收簽字呢?"。 

"天天加班,把人搞得生理時鐘失調,晝夜顛倒,做這個專案的人怨聲載道,整**氣沖沖,威脅辭職、罷工"。  

在具體的軟體專案運轉中,這些令人頭痛的問題接連不斷,常常把人搞得焦頭爛額,心煩意亂,任你技術水平再高,都沒用。俗話說的好:"你渾身是鐵,能碾幾顆釘"。事必躬親,大包大攬的結果只能是把自己累垮,工作還沒做好。在軟體越來越複雜,需求多變的情況下,個人英雄主義、單打獨鬥是行不通的,幹活還得靠大家。 

痛定思痛,你也會很聰明的想到:我必須使用軟體工程方法、開發流程來管理我的團隊。但你真的要在團隊中套用上鼎鼎大名的cmm,更令人沮喪的事情還在後面:cmm中光是那一堆名詞和文件,就夠大家理解好久的了。而且,這些標準、指南更像是評分手冊,可操作性不足。專案組好像整天在忙,老是開會,煩不勝煩,搞出一大摞文件,真正的軟體卻總是出不來。 

還有不少其它的專案管理方法、指南,也是難以在實際環境中操作應用。 

你必須找到適合自己公司團隊的開發流程、框架,不僅要完整,而且必須有良好的可操作性,比較靈活,適應範圍廣泛。所以,向在軟體專案管理上成熟、完善的公司學習,是個很有效的辦法,能讓你迅速掌握在專案管理上的各種方法和技巧,並且上公升到理論水平。 

在軟體行業,微軟公司的軟體產品眾多,產品線齊全。這個軟體巨人在各個市場上取得的成功也是有目共睹,其軟體專案的開發、管理過程也一直是大家很感興趣的焦點。 

筆者有幸參加了一次軟體專案管理的培訓,由微軟中國顧問諮詢部門的講師主講,為期三天,大有斬獲。好多困擾已久的問題和疑惑得到了解答,有種豁然開朗的感覺。 

課程內容是msf-microsoftsolutionsframework,微軟解決方案框架,所謂msf,就是微軟公司定義的用於軟體專案管理的一套完整的流程、方法。講義是從英文教材翻譯過來的,msf的版本是3.0。你可能會覺得奇怪,怎麼這個框架還有版本。嗯,沒錯,微軟公司的講師聲稱,當visualstudio.net2005發布的時候,會整合、攜帶msf4.0一起面市。 

因為msf自身也是根據軟體產業環境,根據新的思想、新的理念、新的實際專案經驗不斷調整,不斷演進的,並不是教條。如3.0版本的過程模型中,就比2.0版本多了乙個稱為部署階段的過程。 

msf是由微軟公司的全球產品組、諮詢服務部門、資訊科技部、微軟的合作夥伴共同協作,分析、總結經過實踐檢驗的正確經驗,對比業界的方法,彙總而成,是關於"人和過程"的指南。它的特點就是實戰性很強,對專案整個過程的指導很完整。而且,它是通用的體系,不管你用什麼技術,做什麼專案,都有可以參照的準則。 

msf主要包含了兩套模型、三個準則。模型正好涵蓋了"人和過程":團隊模型、過程模型。三個準則:專案管理準則、風險管理準則、就緒管理準則。 

在講師講述團隊模型的時候,很有趣,讓我們5個人一組,分組做了乙個讓人印象深刻的實驗。這也是這套課程的獨到之處,講師上課,並非照本宣科的講,而是在學習過程中,穿插了多個實驗和具體的專案例項,讓大家在乙個臨時組織的團隊中,體會理論的含義,加深消化理解。 

這個實驗並不複雜,就是模仿大家日常工作中最常見的、專案小組的結構化組織形式,小組包含乙個"老闆",乙個專案經理,多個團隊成員。由"老大"發號施令,讓專案經理指揮自己團隊的人執行,然後看結果。等15分鐘的時限過去,"老闆"揭示"成果",小組成員要當眾發表感想。難以想象,平時我們認為那麼自然的組織結構,竟然有這麼多缺陷! 

老闆感言:我以為大家知道的事情,原來他們根本不了解,不知道,資訊完全不對稱。

專案經理:太累,不懂領導到底要啥。 

團隊成員:閒得無聊,不知道要幹什麼。對工作沒有積極性,不主動。 

這樣的結果就是:領導和專案經理的個人能力,基本決定了專案成功的可能性。 

然後大家開始分析為什麼會這樣,原因在**,於是就引入了msf的團隊模型。 

當然這個實驗模型為了突出問題,做了很多簡化,但在實際環境中,這些缺陷是確確實實存在的。 

msf的團隊模型中,分成了6個角色,這6個角色是:程式管理、開發、測試、發布管理、使用者體驗、產品管理。每個角色之間是平等的關係,沒有上下級的行政差別。 

這幾個角色並非一定要和人一一對應,當你沒有足夠的人手時候,一些角色可以重疊,由乙個人兼任,但開發不推薦和其它角色兼任,這是因為要保持開發的封閉性。 

當你的團隊人數眾多,規模比較大的時候,可以把大 

大團隊劃分成小團隊,再由核心團隊總攬。既可以按照軟體功能、特性來分成功能團隊,也可以根據職能劃分,例如,程式管理角色有多個人擔任。這充分體現了msf非常靈活、務實的一面,適應性很強。可以用於幾個人的小team,也可以適用於規模很大的團隊。 

敏捷軟體開發理論適應性就弱些,大家公認不太適合超過10人的團隊組織,而且,對成員的要求更高。 

在另外乙個模型-過程模型裡面,msf敏捷的一面又顯露了出來。通過把複雜的專案分成多個版本進行迭代開發,來充分的簡化專案難度。每個版本都有自己要完成的功能範圍,可以看成乙個"小專案",專案小了,複雜度、難度自然大大下降,當然成功的概率就高的多。而且,和專案相關的人能很快的評估專案成果,來決定專案的"下一版本"方向。 

在每個專案過程中,都包含乙個很完整的階段,專案構思、專案計畫、專案開發、專案穩定、專案部署。從專案構思到專案部署結束,每個環節都有很多的所謂"里程碑"成果。就是每個階段都有很明確的要求,到底要拿出什麼成果。而這些成果,是需要團隊成員共同努力來取得的,正好和團隊模型相互結合。 

在專案的任何乙個階段,每乙個團隊成員都要有成果,大家是並行工作的。這樣一來,就避免了傳統組織方法的很多弊病,如開發沒結束,測試難以進行。在這樣的模型中,不再是乙個上司發號施令,下面的人去被動執行,已經演變成了大家都能積極主動的參與進來,每個人都有事情可以做。不同的角色在不同的專案階段,分別起到主導作用。 

課程中還有乙個很重要的msf原則貫穿其中,那就是風險。所謂風險,簡單的說就是事件有可能發生,但是不確定何時何地。 

團隊最早開始做的事情之一就是管理風險,我們通過分組,在課堂上模擬了一遍,很有意思。每個人根據實驗要求,挖空心思,冥思苦想,想象在專案過程中到底會發生什麼事情,判斷可能性和後果。連團隊成員懷孕,無法繼續工作這種事情也被找了出來,戲劇性的是,乙個學員就承認,自己的團隊就遇見了這樣的麻煩,而且還不知道到底應該怎麼辦。 

管理風險的目的就是把握主動權,在風險發生的時候能迅速處理,從而保證專案能順利進行下去。這樣一來,客戶會對我們更有信心,更信任我們,專案成功的可能性會進一步提高。 

課程的後面,就是具體的專案執行過程了,如專案計畫的制定、開發、穩定、部署等等。其中不乏精彩的觀點和指導方針,讓你有法可依。 

這就是我在msf培訓結束後的體會和總結。理論和實踐從來都是相互交織的,沒有理論,做事情就沒有章法,沒有後勁。缺乏實踐,理論就變得十分空洞,陷入空談。你必須把理論不斷的應用於專案管理實踐,才能不斷的成長、成熟。

程式設計師與專案經理

有人加我為好友後,經常問到的一句就是 你寫程式這麼長時間了,一定是專案經理了吧?鬱悶呀!為什麼就要是專案經理呢?在我看來程式設計師和專案經理完全是兩個不同的發展方向。程式設計師是和 打交道的,而專案經理卻是和人打交道的,所以他們完全沒有什麼共同點,我覺得他們是兩個行業。您可以從程式要 轉到 專案經理...

程式設計師與專案經理

很多專案經理都是從程式設計師成長過來,也有很多年輕的程式正在把專案經理做為人生發展的目標之一,但我認為專案經理跟程式設計師有很大的不同,實事上,專案經理要承擔的責任和能力是完全不能跟程式設計師相提並論的。面對乙個專案,程式設計師只需要考慮尋找最巧妙的演算法去實現專案需求。而對專案經理來說,他要解決很...

當程式設計師變成軟體專案經理

當你預期的那一天,也許是害怕的那一天,終於來到了 從工程師的隊伍裡你被提拔到了軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路,或許你不太情願,將就嘗試一下。無論在哪種情況下,你都可能缺少工程學科 人員管理以及領導能力的相關教育。這需要更多的領導能力和管理 它們不是一回事 而不能象dilb...