要做乙個專案負責人，首先要做乙個好人。最自己負責，對領導負責，對組員負責，而如果想形成乙個好的團隊對組員負責是乙個關鍵的問題。93年我第一次帶團隊的時候，我們在江蘇開發乙個專案，有一次，我的領導找到我談工作，在談到乙個組員的時候，我問他為什麼自己花錢給那個人買皮鞋。領導對我說，你難道沒有看到他的手和腳都長凍瘡了嗎？你作為專案組長，你的組員才大學畢業，就和我們一起出差，第一次獨身在外，你難道不能更加關心他嗎？這件事情給我感觸很大。作為乙個專案負責人，不但要在專業上關心你的組員，在平時的生活中也要關心他們。這樣才能形成乙個好的團隊。
對新參加工作的同志的關心要細緻
新參加工作的同志和老同志的差別很大,我們這裡的新同志都是剛畢業的大學生或者研究生.社會經驗都比較少,對他們的關心就需要格外細緻,比如在他們剛來的時候,機器裝置的配置,軟體的安裝,各部門情況的介紹,都要和他們講得比較細,這樣比較容易消除他們的陌生感,很快的融合到集體中來,另外乙個要注意的是,對他們的工作的安排和檢查要細緻.一般來說,我對他們工作的安排一般乙個階段不會超過兩天,也就是說,兩天比檢查他們工作一次,在檢查工作的時候,首先要表揚他們的成績,然後告訴他們存在的問題,以及問題的解決方法.在讓他們去試驗(不可包辦代替,讓他們自己去做,這樣才可以積累他們的工作經驗).而且在檢查的過程中盡量保持談話環境的輕鬆愉快,(可以講一些我們原來的臭事,避免單純的說教式的檢查方法),這樣新同志一般都會接受我們建議,同時為以後的工作打下乙個好的工作氛圍,工作要細緻的另外乙個體現是要根據不同的人安排工作.比如我們今年招的測試人員,其中乙個是計算機專業的本科,又在單位實習了3個月,我安排他的工作就是學習td和qtp進行測試,原因很簡單.他在單位做過測試,對測試理論的認識也比較到位,而且有一定的開發經驗,那麼如何早日將他培養成乙個優秀的測試人員就是我的目標。
而測試工作的使用實施對他的個人發展就顯得很重要了.另外乙個是本科非計算機專業,他的主要工作就是不斷重複的作乙個系統的測試.每測試一次,我都要給他講解一次,沒有辦法,他累我也累.但他沒有開發經驗也沒有測試經驗,如果一下上太複雜的東西,他不但不能掌握所學的知識,而且對工作會產生一種畏懼心理,這對他以後的發展是很不利的.所以我對他的安排就是在3個月內不斷的進行實際的測試,並且不斷總結經驗,這樣三個月的時間內,他基本就可以掌握測試的基本方法和理論,而在三個月之後,他也要開始測試工具的學習,而那時我的第乙個測試人員已經記基本掌握了qtp,可以幫助他了.對不同開發人員測試人員的具體情況進行分析,讓他們做適合他們做的工作,並且在每一次工作中都讓他們不斷增強自信心,而且提高自己的技術水平,你的組員怎麼會不聽你的指揮。
作為乙個專案要勇於決斷
作為乙個專案組長要勇於決斷,專案組長是最了解專案的管理人員,無論是使用者,組員還是測試人員和質量保證人員以及客戶都是以專案組長為中心的,這個地位決定了專案組長應該是對專案最了解的人,那麼他在關鍵時刻的判斷和決斷就對專案起著關鍵的作用.而作為專案組長如果不敢和不能決斷的話,必然給專案的開發造成極大的困難,說兩個故事。
乙個是我的哥們,有一次他去客戶那裡沒有參加技術討論會,回來的時候,他的開發人員的討論會還在激烈的爭吵著,見他回來了,分成兩派的開發人員就讓他來判斷那個演算法更好,我的哥們聽了一會說,我來告訴你們如何取捨,於是從兜裡掏出乙個硬幣,正面用a方案,背面用b方案,然後一扔,於是結果出來了.當時我聽了這個故事直笑.問他為什麼這麼做.他說,我不搞技術很多年了,但聽他們說得,兩個方案差別不多,不過是a+b=c還是b+a=c的問題,這個時候如果你去參加參加討論,無論採用a還是b都要費很多的口舌,而有那個時間早開發出來了,於是就想了這個方法.當然採用這個方案的時候,開發人員都看傻了,別忘了給你的開發人員講解一下你為什麼採用這樣的選擇方法 。
另外乙個專案就很有意思了,表面上這個專案組長很尊重開發人員,每週都要開一次週會,而且開會的時間還不短,可很快開發人員就不在會議上發言了,有一次和他們組的開發人員閒談的時候,問他們為什麼不在會上發言了,那個開發人員告訴我,每一次提出問題,組長都是侃侃而談一番,沒有任何實質內容,最好的情況是說這個問題下面讓某某,於是坐在一邊不說話了,更多的情況是說這個問題很重要,我們先放一放.下回討論.可是問題既沒有記錄,也沒有安排人去做專門的研究,往往是不了了之.一次兩次,慢慢的開發人員都認為提的問題不可能得到解決,於是每次的週會就成了專案組長的獨角戲,而其他人員的手機發簡訊的水平,以及圖畫水平倒提高了很多。
很多專案組長往往感覺自己的權威性不夠,經常會說給我這個權力那個權力,我就可以怎麼怎麼樣,其實,專案組長的權威不是建立在對開發人員的工資或者其他的控制上,而是建立在你的做事方法,開發能力等這些軟體水平上的,如果在你的組員遇到問題的時候,你可以為他們解決,提出可行的解決方法,什麼和他們一起同甘共苦的去完成那些最艱難的問題,你的組員怎麼會不信服你,你又怎麼會沒有威信呢。
對不同的人員採用不同工作的方法
作為專案組長最重要的乙個特點是要細緻，在安排和檢查工作的時候尤其要細緻。對待剛參加工作的工作人員和老工作人員也要區別對待，一般來說剛參加工作的人員工作熱情都比較高，但工作方法的掌握都會有一些這樣或者那樣的缺陷，如何做到既不打擊他們的工作熱情，又防止他們的工作走偏是乙個很重要的事情，我帶專案組的時候，有一次給了我四個剛畢業的工作人員。我給自己定了幾個原則，1要大膽使用他們，要幫助他們解決主要的開發問題，3檢查工作要仔細，防止工作出現大的偏差，4分層次，區別使用，盡量作到用對他們。
先說1大膽使用他們，新同志一般工作都會存在這樣或那樣的問題，而且有時候問題比較明顯，我原來也覺得使用他們不如自己開發快，所以總是越俎代庖，這樣的結果就是我自己累得夠嗆，開發人員閒得要命，而且工作情緒不高i。為了防止這個問題的發生。這回我努力克制自己開發的慾望，將所有的設計、編碼的任務都安排給他們，自己只負責總體設計、關鍵技術問題的解決和工作的檢查。事實證明，只要你控制得好，開發人員都會比較好的完成開發任務，而且在開發過程中進步也是很明顯的。我的這幾個開發人員由於我敢於放權，不但開發完成的比較好，而且經驗的積累也比同時間來的開發人員要快，很快成為了單位的開發骨幹。
放權不是不管，而是該管的管，不該管的不管。對於新同志他們都有一定的開發能力的欠缺，但主要問題體現在兩個地方，乙個是設計能力，乙個是開發的規範性。總體設計是我來做的，然後給他們逐步講解，使他們了解我這麼設計的目的和方法。再讓他們做自己部分的設計，開始這是很困難的事情。因為我們的系統需要很強的可擴充性和維護性，所以很多方面的設計方法和他們原來的開發有很大的區別。而他們在學校做的設計根本不用考慮系統的可擴充性和維護性，所以在很多設計思路上彼此差別很大，我不但要完成設計，講解給他們聽，而且要讓他們接受我的觀點，說實在的真是很困難的，我採用了和實際相結合的方法，告訴他們每乙個設計的目的和實現的方法，如果他們有不同的設計也可以，大家一起討論，如果他們的設計可以滿足系統的需求那麼我也很樂意接受。
另外乙個是開發的規範性，我們的同志在學校的時候基本上都沒有接受過規範性開發的培訓，而這是在實際工作中必須特別強調的東西，比如**的規範性、文件格式的規範性等，我就作為強制執行。當然如果一味的強調這是規範必須執行還是不夠的（容易產生逆反心理），在具體執行過程，還要和他們去交流。比如如何寫文件效果會比較好，如何避免有話說不出來的問題，一般來說，我都採用他們先寫文件（或**），我來檢查，然後講解，他們再修改。再檢查、講解，（編碼也是一樣），一般來說，第一次的文件他們會寫4-6次，但經過一次這種訓練，他們的文件撰寫水平和編寫**的規範性就可以過關了。
新同志的工作週期我一般安排是1.5---2天的時間。一般來說。新同志的工作我都安排得比較細，他們的工作都在一天之內可以完成，這樣主要是防止工作出現比較大的偏差。而且即使出現了問題，我也可以及時發現和調整，不至於對工作造成太大的危害。工作檢查不是乙個簡單的評判過程，更是對他們的乙個培養過程。一些工作方法，工作技巧都是在這個時候教授的。在這個環節要特別注意簡單粗暴地對待開發人員，一定要將問題講透講清楚，最後還要讓開發人員再講一遍你的講解內容和後面的工作安排（很重要的，在你聽他們敘述的時候，往往會發現他們的理解和你的想法有很大的差別），防止交流的無效性發生，一般來說新參加工作的人員如果真接受了你的觀點，使會主動改正他自己的問題的（雖然會有反覆） 。
即使是新工作人員，也會有很大的差別，作為專案負責人，要善於發現發現這些差別。比如在這個專案中，有乙個工作人員作過oa專案（畢業設計），對oa的理解比較多，那我就讓他負責系統最重要部分的設計，有的人比較細心，就讓他負責配置管理，有的人比較善於鑽研，就讓他負責許可權管理部分的設計（那部分比較難），總之，沒有不可用的人，關鍵是看你是否用的對地方。只要用對地方，便可以達到事半功倍的效果。
學會向使用者匯報工作
當然了，也包括領導匯報工作。道理基本一樣。說乙個在科委專案的課題的故事吧，那個課題是乙個做的不太好的專案。使用者對我們很不滿意。專案組長被撤了，開發人員也都走了，讓我接手這個專案，我的目標是完善專案，我到專案經費（還有40%），其中的開發工作就不多說了，只說說向使用者匯報的事情，使用者的領導是乙個50多歲的大媽(大媽是很聰明的，否則也不會在那裡做到這個職位)，對我們很不滿意，開始的時候，我堅決承認錯誤，絕不隱瞞（獲得對方的認可），其次在後來的時候每次去使用者那裡，我都會琢磨一下是否要去向她匯報，如果沒有太重要的事情，就想想最近在做什麼事情，這樣在見到大媽的時候，可以匯報，如果真是需要匯報，就要特別考慮一下幾個問題，1我現在的工作進展，2我遇到的問題，3問題那些是我可以解決的，什麼時候會有答覆，4什麼問題需要使用者配合。（比如硬體裝置的改善等）具體配合的內容是什麼。在匯報的時候，我會私下掰手指頭，乙個問題乙個問題說，防止遺漏，同時要記住對方的回答。這樣幾回之後，大媽對我的感覺很好，後邊的工作就好做了，後來專案順利完成。經費自然也回來了，所以在和使用者匯報工作的時候要特別注意幾點：
1專案是最重要的，無論你採用什麼作客戶關係的方法，專案或產品必須過關，否則一切都是無用功（國家專案不一定）
2在匯報的時候，態度要認真。特別是出現問題的時候不要一味推卸責任，講理由，這是沒有效果的（在單位匯報工作的時候也一樣，沒有人會理會你的理由）
3匯報之前一定要準備，這樣條例清楚，事情完整。防止因為一點小事情連續打擾客戶。要讓客戶在每一次交流時都有很大的成果。
4匯報的時候要掰手指頭，主要是防止問題的遺忘，特別是大家在就具體問題討論的時候容易干擾你的思路，使你遺忘事情 。
5在匯報之後要將所有問題都過一遍，是否所有的問題都有解決方法了，如果什麼事情不清楚，馬上問，這樣總比再次來好，在說出來，和使用者一起確認問題的解決方法 。
6實在怕遺忘，最好帶乙個錄音筆，但千萬不要讓使用者看到，也不要用這個東西作為以後爭執的證據用（沒有好處的），只是作為資料整理的乙個備份，否則使用者會反感而不配合你以後的工作。
專案經驗分享
這是我經歷的第二個專案，這個專案相對於第乙個專案dzpay相對較簡單，介紹 第乙個專案名稱 dzpay。大宗商品交易，類似某寶 這次主要總結我測試billbank的一些個人經歷 測試第一要義就是要詳讀產品需求，產品需求中有哪些模組，每個模組中又有哪些子模組，每個模組以及子模組對應的需求點都要搞清楚。...
專案經驗分享
color cyan dh師兄的經驗分享 color color olive 就在公司工作的經驗，針對shopxx專案的交流。color color darkblue 1.乙個專案，要先分出模組來。不要把所有功能都寫在乙個模組裡。如果這樣的話，專案會變得非常臃腫，模組間的耦合性太強，維護起來很困難。...
專案經驗分享
最近一直在想自己在專案中的一些得失，在每乙個專案結束都要問自己一下 這個專案中自己獲得哪些成長，下次是不是可以做到更好。長期的專案過程往往會讓人陷入一種思維的定式 好像每個專案的工作都一樣，這樣很容易進入一種比較消極的狀態，會忘記自己曾經給自己設定的目標。以前看過這樣乙個問題 什麼才算得上有效經驗？...