我的項目管理之路

1、 我的項目管理之路 歷程我的職業(yè)生涯可以說基本上是一帆風順的、也許這個和我的外語能力有關。2000年的2月份進了當時在大連還是比較有名氣的一家軟件公司做對日項目，用pb來開發(fā)一些c/s系統(tǒng)。因為可以寫程序日文也不錯、很快就受到重用、本以為愉快的生活可以就這樣一天天的過去、卻3個月后公司就宣告日本業(yè)務繼續(xù)不下去而解散。經(jīng)過和公司的洽談、同意轉(zhuǎn)到總公司做國內(nèi)的銀行軟件、使用unix c。沒有了外語的支持就是一個普通的不能再普通的程序員了、沒有了往日的優(yōu)越、好在同事之間相處的到還融洽。只是作為一個新人、總是被安排做一些比較瑣碎的工作而已。就這樣過了2年上面因為是我的第一份工作 所以稍微寫的多了點、之

2、后就展轉(zhuǎn)到日資企業(yè)里做一些java和.net 的項目、逐漸覺察到自己的日文還是比較有基礎的、就這樣做一些詳細設計、現(xiàn)在想起來雖然沒什么技術含量 也積累了自己對很多業(yè)務系統(tǒng)的了解。之間過的很快、轉(zhuǎn)眼已經(jīng)2004年下半年、在一家大概300多人規(guī)模的外包公司做項目經(jīng)理、做的很偶然、也許只是因為我對公司的業(yè)務流程、部門的考核體制、項目開發(fā)與管理方面提出了一些見解、讓部門老大覺得我比較有做管理的天賦。大概也有我日文不錯的緣故吧。不過不管怎么說、項目經(jīng)理還真是個偶然性非常強的職位呢、也許你是技術骨干、也許你為公司做出了什么比較大的貢獻、也許只是客戶向領導跨了你幾句、都有可能成就這個職位。于是在這個職位上開

3、始了不斷的掙扎與努力、承受了很多、也分享了很多、滿足了很多。06年也考下了pmi的 pmp。一、總括要做好一個項目一定要有好的思維這個是我一直以來始終信奉的有一句話。是什么意思呢、就是說作為一個項目經(jīng)理也好、一個程序員也好、你必須要思考：“我如何能做好這個項目”。具備了這一點后、才有了做好一個項目基礎。否則如果單純的為了完成一個項目而去做項目、說的不好聽了，做的癡癡呆呆的、墨守成規(guī)的、那么我認為這個項目不可能被做好。當然了只是想做好是不夠的、一方面巧婦難為無米之炊、你要有資源、有啟動并且開展這個項目的資源支持。同時還要講求方法、只是想做好但是蠻干、那也是絕對行不通的。在這里我可以給一些想進入項

4、目管理行業(yè)的朋友推薦pmp體系、cmmi、等。這些知識體系只可以給你提供一種方法的導引、而不能硬性的照搬。只能用他們來開發(fā)自己的思維、為項目成功增添一些砝碼而已。所以想要成為一名好的項目經(jīng)理就要有正確的理念、思維和態(tài)度。有很多人說、這個項目經(jīng)理的技術很差、我想很多人也都經(jīng)常聽或說這句話吧。其實項目管理者不一定要技術強、技術太強反而容易陷入技術細節(jié)、而忽略全局。此外成為一名優(yōu)秀的項目管理者一定要有綜合處理事件的能力、良好的溝通技巧、已經(jīng)有條不紊的文檔話能力和提案能力。二、關于項目的定義：這里我引用pmp關于項目的定義、為提供某種獨特的產(chǎn)品或服務所做的臨時性的努力說的通俗一點、日常生活中的很多事情

5、都可以當作一個項目、比如：在一個孩子5歲前讓他能夠背誦下來一整本宋詞。1年內(nèi)存夠10萬塊錢。 我覺得都是可以當做一個項目來做。那么項目的特點如下：臨時性 (不是永久不變的)為了完成某種特定的產(chǎn)品或服務而做。項目管理的過程啟動、計劃、執(zhí)行、控制、收尾三、對日項目的特點我前面幾年都是做對日項目的、所以在這里我主要和大家分享對日項目管理的心得。日本企業(yè)一般注重細節(jié)、注重軟件工程、注重里程碑管理、必須在每個階段提交每個階段應有的成果物或稱為納品物。比如：概要設計、詳細設計、測試式樣(一般寫些test case)、源代碼、測試結(jié)果報告(一般沿襲測試式樣、包括很多階段、單體測試、功能測試、系統(tǒng)測試等)。他

6、們重視項目管理的數(shù)據(jù)性證據(jù) 也就是量化的結(jié)果特點一：開發(fā)階段的劃分、里程碑的管理在項目啟動之前、會把一個大的項目切分成幾個小項目、從而明確每個時間段我們應該完成的目標 比如把概要設計階段當成一個項目來做、那么這個項目完成的標志就是給客戶提供讓他們基本滿意的概要設計書。概要設計階段提交相應的成果物后、客戶驗收合格、我們可以順利的進入到詳細設計階段、之后代碼階段不過也不是完全固定的、有的時候為了縮短項目開發(fā)的整體周期、我們可以把幾個項目階段重合進行、比如在概要設計階段完成50%后就開始進入到詳細設計階段。這樣做要注意的就是、要把成果物的驗收細分到每一本設計書上去。關于里程碑最直觀的劃分就是按照項目

7、階段來劃分了、每個階段完成后按照該里程碑完成要求進行驗收、并提交相應的成果物、比如1本設計書、10本設計書、5本測試式樣書等特點二：項目管理的量化、與證據(jù)化做任何事情都要講求證據(jù)、特別是對日的項目、做為一個項目經(jīng)理我們?nèi)ズ涂蛻魷贤ê屠习鍦贤ǘ际切枰欢ǖ淖C據(jù)、從而才能有效的獲得支持。項目的估算、有很多估算的方法、我一般采用功能點估算。不過這個需要前期的數(shù)據(jù)積累、個人覺得比較適用于成熟的團隊、成熟的業(yè)務系統(tǒng)。估算過后、會有一個項目分解的表格、詳細記述項目的整體規(guī)模(人月)項目被分解后的單位規(guī)模：比如一本詳細設計書 0.2人月(4天左右)項目成員的能力估算做任何一個項目前、都必須要組建起一支隊伍、

8、也許這只隊伍是你平時所熟悉、也許是你不熟悉的、如果你沒有選擇的余地、那么你只有接受。一般情況下要先整理出一份團隊的列表、不一定要有聯(lián)系方式、根據(jù)自己的項目規(guī)模來判斷是否需要、因為聯(lián)系方式太全了、資料容易造成外泄、造成項目中成員流失從而帶來風險。在這份表格里、必須要有的就是團隊的核定、什么叫核定呢、從字面上的意思來說就是一個人對比他的能力是否可以當成完整的一個人來使用。當然什么叫完整的人、需要在事前定下一個標準。 舉個例子來說吧、有一個標準化的 增刪改查的程序、a成員可以比較有效率的、低bug的 用5小時來完成、我們把這個人當作是標準、做我們的參照物。 而b成員同樣的bug率要用10小時來完成的

9、話、我一般把b員工的能力系數(shù)定為0.5。 一般來說我稱呼這個為邏輯能力=0.5 物理能力=1一個團隊的核定一般我就如上面這樣通過一些途徑來大致的判斷一下、至于有哪些途徑來判斷、就不再細說。我們重要的是要知道要做什么、目標明確了只要努力、相信總歸會做到。之后要做的就是核定整個團隊的整體邏輯能力、比如我的團隊有30人、可能經(jīng)過我的核定、邏輯能力只能有20。 這個時候我需要參照項目的周期、和估算的規(guī)模、進行判斷、是否能完成。 如果差距實在太大的話、我會起草正式文件、mail到各位老大手里、他們怎么決定是他們的事情、至少作為項目經(jīng)理、我們有職責提出這樣的風險、同時記錄到風險識別的列表。如果被授權招聘了

10、那么就去招聘、或者從其他部門借調(diào)、途徑很多。但是要強調(diào)的就是我認為邏輯能力的核定是肯定要做的。團隊組建了之后、我們還要了解他們每個人的專長、如果是被迫接受這個團隊的話、每個人我都會拿出至少30分鐘的時間和他們?nèi)チ奶?、也許我不會去問他們具體的技術、也許只是和他們聊一些工作的瑣碎事情、或是他們是日常生活、但是通過這些我就大致可以知道哪些人有什么樣的特點、性格如何等、看待工作的態(tài)度等、對哪些技術有興趣以及造詣等。成員工作量的統(tǒng)計、依據(jù)上述的量化結(jié)果、在項目過程中、嚴格監(jiān)控成員的工作量一覽。從而為以后的項目估算提供歷史數(shù)據(jù)。也作為項目獎金的分配依據(jù)、能者多得。qa一覽表的完整備案這個東西、一直貫穿整個

11、項目的進程、需要嚴格的分析、整理、共享項目進展的過程中不可避免的會有非常多的困惑、這些基本都可以通過這張表格來完成和客戶的探討。同時、項目組成員根據(jù)qa表的分類、主題等、可以查看到是否其他人問的問題也正是自己不懂的、從而提高效率。另外qa表也作為和客戶溝通的證據(jù)而需要重點保護、因為很多變更可能都是依據(jù)qa表來先期變更的。bug管理的量化對于bug的管理、分類也是很重要的、通過對bug的分類 你可以了解到你的項目中bug的大致類型、是哪些人犯的錯誤、什么原因會出現(xiàn)這樣的bug、從而及時準確的抓到關鍵點避免重復。對于bug數(shù)的分析、如果太多了、肯定要分析bug類型 及時對應、及時調(diào)整、是追加培訓還

12、是通過其他途徑。如果bug過少、反思一下自己的測試是否充分、到了客戶那邊再測試出比較多的問題就不是只丟面子的問題了。特點三：安全管理注重數(shù)據(jù)的備份、病毒防范、數(shù)據(jù)加密、成員出入考勤等四、項目成功的支柱-開發(fā)的團隊打造團隊精神培養(yǎng)下屬的自我激勵意識、基于一種成功、成就、成長的意愿而自我激勵與提升。在開發(fā)過程中不僅是做好自己的本職工作、還要積極的參與、從而為項目的成功添磚加瓦。培養(yǎng)下屬的換位思考能力我做項目經(jīng)理的時候、也碰到過不少人對我的技術與管理方式不認同的人、我想這個也是很多項目經(jīng)理都曾經(jīng)碰到過的問題。所以我們要持之以恒的培養(yǎng)下屬換位思考的能力、避免團隊成員之間產(chǎn)生誤解、創(chuàng)造和諧的作業(yè)范圍。也

13、可以避免因為自己的問題而給其他同事帶來困擾。項目開發(fā)團隊是伙伴的關系、需要基于共同成功的目標而互相支持與幫助。項目團隊的階梯打造我不會在一個項目中放一堆的牛人、這個也是不現(xiàn)實的、資源畢竟是有限的。另外一個方面、牛人與菜鳥的搭配我認為才可以激發(fā)戰(zhàn)斗力、牛人有自豪感、菜鳥有奮斗的目標。五、溝通對項目的成功起到非常重要的作用影響到溝通的有很多因素：比如管理的問題、團隊成員不信任的問題、項目成員的個性問題等。作為一個項目管理者、不解決溝通問題是不可能做好一個項目的。不定時的調(diào)整座位一方面也是為了成員之間更好的溝通。 項目啟動之前要明確定義出來該項目的溝通途徑等。msn、ip messenger、mai

14、l、phone都是可選的。什么樣的事情向誰去報告、都在這份溝通定義文件里指定。根據(jù)項目的需要、看看是否每天必須有會議、可以靈活的進行。作為項目經(jīng)理、是一個中心的環(huán)節(jié)、弄的不好客戶 老板 上司 下屬都會對你不滿意、所以時刻要記住溝通的重要性。有時間的話多和上司去聊聊、聽聽他的想法、至少你和他多溝通會增加他對你的支持。多和下屬聊聊、搞好關系、天熱了請他們吃吃冰棍兒. 下班了請他們出去唱唱歌放松一下、預算多的可以和老大去申請、也可以記入項目經(jīng)費。其實人的本質(zhì)中、最渴望得到的就是被肯定吧、所以多去肯定他們、啟發(fā)他們的思維。不過這些都要把握好尺度、過尤不及.我們中國人講究人情、喜歡稱兄道弟、但是太熟悉了

15、他們就不在乎你了。出了問題也不好處理、所以要把握好尺度。所有給客戶發(fā)的郵件一般來說 我都cc給我的上司、碰到有的客戶不講理的、我就直接cc給客戶的上司。郵件是一種證據(jù)、需要嚴格的保存好。碰到什么事情說不清楚了、能拿出證據(jù)就是王道六、關于項目的變更我做對日項目、碰到最多的問題就是變更、也許這個機能都快做好了、客戶突然說他要變更、很讓人頭疼的事情。 一般有這樣的變更出現(xiàn)的時候、我都會自己先理解一下客戶想要做什么、為什么他要變更、條件允許的話直接電話和客戶交流確認一下、因為我以前發(fā)現(xiàn)過、他們想要實現(xiàn)的功能不要如此麻煩的變更就可以實現(xiàn)。所以大家碰到這樣的問題一定要先理解客戶想要什么。不管怎么說、只要他

16、們有變更來我都會記錄到一份變更管理的文件里、我會把他們分類處理。那么如何分類呢、我一般分成流程變更 是客戶廢棄原來的流程而改用新的流程、肯定需要追加工數(shù)bug因為我們的bug而提出的程序修正 不需要追加工數(shù)性能優(yōu)化 根據(jù)具體情況來決定是否需要追加工數(shù)機能追加 追加新的機能 肯定需要追加工數(shù)每個人的著眼點不同可能分類也不同、這樣要強調(diào)的就是一定要非類、至于你怎么分、至少可以體現(xiàn)出責任在誰 工數(shù)大概多少就成。七、總結(jié)時間比較倉促、單純的為了一篇征文而寫、所以不能寫的非常全面、總體上作為一個項目管理者來說下面的列表可能比較有用。建立工作結(jié)構(gòu)分解-wbs文檔化管理項目估算-包括工作量的估算、成本的估算

17、、管理風險-定義和確立風險的影響和處理管理進度-建立進度表以及關鍵里程碑跟蹤項目的過程-監(jiān)控項目團隊的執(zhí)行力、使用定義好的量化標準監(jiān)督控制項目的進展頭腦風暴的使用分布在所有過程中的團隊績效管理管理變更培養(yǎng)自己的領導力、同時強化溝通技巧歷程我的職業(yè)生涯可以說基本上是一帆風順的、也許這個和我的外語能力有關。2000年的2月份進了當時在大連還是比較有名氣的一家軟件公司做對日項目，用pb來開發(fā)一些c/s系統(tǒng)。因為可以寫程序日文也不錯、很快就受到重用、本以為愉快的生活可以就這樣一天天的過去、卻3個月后公司就宣告日本業(yè)務繼續(xù)不下去而解散。經(jīng)過和公司的洽談、同意轉(zhuǎn)到總公司做國內(nèi)的銀行軟件、使用unix c。

18、沒有了外語的支持就是一個普通的不能再普通的程序員了、沒有了往日的優(yōu)越、好在同事之間相處的到還融洽。只是作為一個新人、總是被安排做一些比較瑣碎的工作而已。就這樣過了2年上面因為是我的第一份工作 所以稍微寫的多了點、之后就展轉(zhuǎn)到日資企業(yè)里做一些java和.net 的項目、逐漸覺察到自己的日文還是比較有基礎的、就這樣做一些詳細設計、現(xiàn)在想起來雖然沒什么技術含量 也積累了自己對很多業(yè)務系統(tǒng)的了解。之間過的很快、轉(zhuǎn)眼已經(jīng)2004年下半年、在一家大概300多人規(guī)模的外包公司做項目經(jīng)理、做的很偶然、也許只是因為我對公司的業(yè)務流程、部門的考核體制、項目開發(fā)與管理方面提出了一些見解、讓部門老大覺得我比較有做管理的天賦。大概也有我日文不錯的緣故吧。不過不管怎么說、項目經(jīng)理還真是個偶然性非常強的職位呢、也許你是技術骨干、也許你為公司做出了什么比較大的貢獻、也許只是客戶向領導跨了你幾句、都有可能成就這個職位。于是在這個職位上開始了不斷的掙扎與努力、承受了很多、也分享了很多、滿足