要做一個項目負責人，首先要做一個好人。最自己負責，對領導負責，對組員負責，而如果想形成一個好的團隊對組員負責是一個關鍵的問題。93年我第一次帶團隊的時候，我們在江蘇開發一個項目，有一次，我的領導找到我談工作，在談到一個組員的時候，我問他爲什麼自己花錢給那個人買皮鞋。領導對我說，你難道沒有看到他的手和腳都長凍瘡了嗎？你作爲項目組長，你的組員才大學畢業，就和我們一起出差，第一次獨身在外，你難道不能更加關心他嗎？這件事情給我感觸很大。作爲一個項目負責人，不但要在專業上關心你的組員，在平時的生活中也要關心他們。這樣才能形成一個好的團隊。
關心組員,有幾個方面,其中一個是注意組員可能的發展方向,比如我原來的領導建議我做測試或者QA,說我比較適合做個工作.開始的時候個人認爲測試並沒有什麼重要的,還是喜歡做開發,後來因爲一些偶然的原因作測試和QA工作,的確很爽.(不過要沒有那些年的開發經驗會這麼爽嗎?),在我自己的項目組裏也出現這種情況,比如我原來的一個開發人員就是不願意做開發,搞鍀我很難受,後來和他交流發現他想做網絡管理,在項目結束後,給他找了一個會做單位的網絡系統管理員,他又自學了CCNP什麼,幹得不錯.所以,作爲一個項目組長,在關心你的組員的時候,要注意他們的特長和潛質,如果我的組員願意做開發工作,我會爲他們訂製一個培養計劃,然後給他們提一些要求,這樣可以幫他們快速提高開發水平.而如果他們他們不願意做開發工作,就要及時獲得他們的真實想法,並幫助他們去實現他們的目標.這樣開發組的內的氣氛會很好。
對新參加工作的同志的關心要細緻
新參加工作的同志和老同志的差別很大,我們這裏的新同志都是剛畢業的大學生或者研究生.社會經驗都比較少,對他們的關心就需要格外細緻,比如在他們剛來的時候,機器設備的配置,軟件的安裝,各部門情況的介紹,都要和他們講得比較細,這樣比較容易消除他們的陌生感,很快的融合到集體中來,另外一個要注意的是,對他們的工作的安排和檢查要細緻.一般來說,我對他們工作的安排一般一個階段不會超過兩天,也就是說,兩天比檢查他們工作一次,在檢查工作的時候,首先要表揚他們的成績,然後告訴他們存在的問題,以及問題的解決方法.在讓他們去試驗(不可包辦代替,讓他們自己去做,這樣纔可以積累他們的工作經驗).而且在檢查的過程中儘量保持談話環境的輕鬆愉快,(可以講一些我們原來的臭事,避免單純的說教式的檢查方法),這樣新同志一般都會接受我們建議,同時爲以後的工作打下一個好的工作氛圍,工作要細緻的另外一個體現是要根據不同的人安排工作.比如我們今年招的測試人員,其中一個是計算機專業的本科,又在單位實習了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實在怕遺忘，最好帶一個錄音筆，但千萬不要讓用戶看到，也不要用這個東西作爲以後爭執的證據用（沒有好處的），只是作爲資料整理的一個備份，否則用戶會反感而不配合你以後的工作。