CIO的管理經

 

要作一個項目負責人，首先要作一個好人。對本身負責，對領導負責，對組員負責，而若是想造成一個好的團隊對組員負責是一個關鍵的問題。93年我第一次帶團隊的時候，咱們在江蘇開發一個項目，有一次，個人領導找到我談工做，在談到一個組員的時候，我問他爲何本身花錢給那我的買皮鞋。領導對我說，你難道沒有看到他的手和腳都長凍瘡了嗎？你做爲項目負責人，你的組員才大學畢業，就和咱們一塊兒出差，第一次獨身在外，你難道不能更加關心他嗎？這件事情給我感觸很大。做爲一個項目負責人，不但要在專業上關心你的組員，在平時的生活中也要關心他們，這樣才能造成一個好的團隊。

關心組員，有幾個方面，其中一個是注意組員可能的發展方向，好比我原來的領導建議我作測試或者QA，說我比較適合作個工做，開始的時候我的認爲測試並無什麼重要的，仍是喜歡作開發，後來由於一些偶然的緣由做測試和QA工做，的確很爽(不過要沒有那些年的開發經驗會這麼爽嗎?)。在我本身的項目組裏也出現這種狀況，好比我原來的一個開發人員就是不肯意作開發，搞得我很難受，後來和他交流發現他想作網絡管理，在項目結束後，給他找了一個單位，作網絡系統管理員，他又自學了CCNP什麼的，幹得不錯，因此,做爲一個項目負責人,在關心你的組員的時候,要注意他們的特長和潛質,若是個人組員願意作開發工做,我會爲他們訂製一個培養計劃,而後給他們提一些要求,這樣能夠幫他們快速提升開發水平，而若是他們不肯意作開發工做，就要及時得到他們的真實想法，並幫助他們去實現他們的目標，這樣開發組的內的氣氛會很好。

對新參加工做的同志的關心要細緻

新參加工做的同志和老同志的差異很大，咱們這裏的新同志都是剛畢業的大學生或者研究生，社會經驗都比較少，對他們的關心就須要格外細緻，好比在他們剛來的時候，機器設備的配置，軟件的安裝，各部門狀況的介紹，都要和他們講得比較細，這樣比較容易消除他們的陌生感，很快的融合到集體中來；另一個要注意的是，對他們的工做的安排和檢查要細緻，通常來講，我對他們工做的安排通常一個階段不會超過兩天，也就是說，兩天必須檢查他們工做一次，在檢查工做的時候，首先要表揚他們的成績，而後告訴他們存在的問題，以及問題的解決方法。再讓他們去試驗(不可包辦代替，讓他們本身去作，這樣才能夠積累他們的工做經驗)，並且在檢查的過程當中儘可能保持談話環境的輕鬆愉快(能夠講一些咱們原來的臭事，避免單純的說教式的檢查方法)，這樣新同志通常都會接受咱們建議，同時爲之後的工做打下一個好的工做氛圍；工做要細緻的另一個體現是要根據不一樣的人安排工做，好比咱們今年招的測試人員，其中一個是計算機專業的本科，又在單位實習了3個月，我安排他的工做就是學習TD和QTP進行測試，緣由很簡單，他在單位作過測試，對測試理論的認識也比較到位，並且有必定的開發經驗，那麼如何早日將他培養成一個優秀的測試人員就是個人目標。而測試工做的使用實施對他的我的發展就顯得很重要了，另一個是本科非計算機專業，他的主要工做就是不斷重複的做一個系統的測試，每測試一次，我都要給他講解一次，沒有辦法，他累我也累，但他沒有開發經驗也沒有測試經驗，若是一下上太複雜的東西，他不但不能掌握所學的知識，並且對工做會產生一種畏懼心理，這對他之後的發展是很不利的，因此我對他的安排就是在3個月內不斷的進行實際的測試，而且不斷總結經驗，這樣三個月的時間內，他基本就能夠掌握測試的基本方法和理論，而在三個月以後，他也要開始測試工具的學習，而那時個人第一個測試人員已經記基本掌握了QTP，能夠幫助他了。對不一樣開發人員和測試人員的具體狀況進行分析，讓他們作適合他們作的工做，而且在每一次工做中都讓他們不斷加強自信心，並且提升本身的技術水平，你的組員怎麼會不聽你的指揮。

做爲一個項目負責人要敢於決斷

做爲一個項目負責人要敢於決斷，項目負責人是最瞭解項目的管理人員，不管是用戶、組員仍是測試人員和質量保證人員以及客戶都是以項目負責人爲中心的，這個地位決定了項目負責人應該是對項目最瞭解的人，那麼他在關鍵時刻的判斷和決斷就對項目起着關鍵的做用。而做爲項目負責人若是不敢和不能決斷的話，必然給項目的開發形成極大的困難，說兩個故事：

一個是個人哥們，有一次他去客戶那裏沒有參加技術討論會，回來的時候，他的開發人員的討論會還在激烈的爭吵着，見他回來了，分紅兩派的開發人員就讓他來判斷哪一個算法更好，個人哥們聽了一會說，我來告訴大家如何取捨，因而從兜裏掏出一個硬幣，正面用A方案，背面用B方案，而後一扔，因而結果出來了，當時我聽了這個故事直笑，問他爲何這麼作，他說，我不搞技術不少年了，但聽他們說得，兩個方案差異很少，不過是A+B=C仍是B+A=C的問題，這個時候若是你去參加參加討論，不管採用A仍是B都要費不少的口舌，而有那個時間早開發出來了，因而就想了這個方法，固然採用這個方案的時候，開發人員都看傻了，別忘了給你的開發人員講解一下你爲何採用這樣的選擇方法。

另一個項目就頗有意思了，表面上這個項目負責人很尊重開發人員，每週都要開一次週會，並且開會的時間還不短，可很快開發人員就不在會議上發言了，有一次和他們組的開發人員閒談的時候，問他們爲何不在會上發言了，那個開發人員告訴我，每一次提出問題，項目負責人都是侃侃而談一番，沒有任何實質內容，最好的狀況是說這個問題下面讓某某來談，因而坐在一邊不說話了，更多的狀況是說這個問題很重要，咱們先放一放，下回討論，但是問題既沒有記錄，也沒有安排人去作專門的研究，每每是不了了之，一次兩次，慢慢的開發人員都認爲提的問題不可能獲得解決，因而每次的週會就成了項目負責人的獨角戲，而其餘人員的手機發短信的水平，以及圖畫水平倒提升了不少。

不少項目負責人每每感受本身的權威性不夠，常常會說給我這個權力那個權力，我就能夠怎麼怎麼樣，其實，項目負責人的權威不是創建在對開發人員的工資或者其餘的控制上，而是創建在你的作事方法，開發能力等這些軟件水平上的，若是在你的組員遇到問題的時候，你能夠爲他們解決，提出可行的解決方法，什麼和他們一塊兒患難與共的去完成那些最艱難的問題，你的組員怎麼會不信服你，你又怎麼會沒有威信呢。

對不一樣的人員採用不一樣工做的方法

做爲項目負責人最重要的一個特色是要細緻，在安排和檢查工做的時候尤爲要細緻。對待剛參加工做的工做人員和老工做人員也要區別對待，通常來講，剛參加工做的人員工做熱情都比較高，但工做方法的掌握都會有一些這樣或者那樣的缺陷，如何作到既不打擊他們的工做熱情，又防止他們的工做走偏是一個很重要的事情，我帶項目組的時候，有一次給了我四個剛畢業的工做人員。我給本身定了幾個原則，1要大膽使用他們，2要幫助他們解決主要的開發問題，3檢查工做要仔細，防止工做出現大的誤差，4分層次，區別使用，儘可能做到用對他們。

一、大膽使用他們，新同志通常工做都會存在這樣或那樣的問題，並且有時候問題比較明顯，我原來也以爲使用他們不如本身開發快，因此老是越俎代庖，這樣的結果就是我本身累得夠嗆，開發人員閒得要命，並且工做情緒不高。爲了防止這個問題的發生。這回我努力剋制本身開發的慾望，將全部的設計、編碼的任務都安排給他們，本身只負責整體設計、關鍵技術問題的解決和工做的檢查。事實證實，只要你控制得好，開發人員都會比較好的完成開發任務，並且在開發過程當中進步也是很明顯的。個人這幾個開發人員因爲我勇於放權，不但開發完成的比較好，並且經驗的積累也比同時間來的開發人員要快，很快成爲了單位的開發骨幹。

二、放權不是無論，而是該管的管，不應管的無論。對於新同志他們都有必定的開發能力的欠缺，但主要問題體如今兩個地方，一個是設計能力，一個是開發的規範性。整體設計是我來作的，而後給他們逐步講解，使他們瞭解我這麼設計的目的和方法。再讓他們作本身部分的設計，開始這是很困難的事情。由於咱們的系統須要很強的可擴充性和維護性，因此不少方面的設計方法和他們原來的開發有很大的區別。而他們在學校作的設計根本不用考慮系統的可擴充性和維護性，因此在不少設計思路上彼此差異很大，我不但要完成設計，講解給他們聽，並且要讓他們接受個人觀點，說實在的真是很困難的，我採用了和實際相結合的方法，告訴他們每個設計的目的和實現的方法，若是他們有不一樣的設計也能夠，你們一塊兒討論，若是他們的設計能夠知足系統的需求那麼我也很樂意接受。另一個是開發的規範性，咱們的同志在學校的時候基本上都沒有接受過規範性開發的培訓，而這是在實際工做中必須特別強調的東西，好比代碼的規範性、文檔格式的規範性等，我就做爲強制執行。固然若是一味的強調這是規範必須執行仍是不夠的（容易產生逆反心理），在具體執行過程，還要和他們去交流。好比如何寫文檔效果會比較好，如何避免有話說不出來的問題，通常來講，我都採用他們先寫文檔（或代碼），我來檢查，而後講解，他們再修改。再檢查、講解，（編碼也是同樣），通常來講，第一次的文檔他們會寫4-6次，但通過一次這種訓練，他們的文檔撰寫水平和編寫代碼的規範性就能夠過關了。

三、新同志的工做週期我通常安排是1.5---2天的時間。通常來講。新同志的工做我都安排得比較細，他們的工做都在一天以內能夠完成，這樣主要是防止工做出現比較大的誤差。並且即便出現了問題，我也能夠及時發現和調整，不至於對工做形成太大的危害。工做檢查不是一個簡單的評判過程，更是對他們的一個培養過程。一些工做方法，工做技巧都是在這個時候教授的。在這個環節要特別注意簡單粗暴地對待開發人員，必定要將問題講透講清楚，最後還要讓開發人員再講一遍你的講解內容和後面的工做安排（很重要的，在你聽他們敘述的時候，每每會發現他們的理解和你的想法有很大的差異），防止交流的無效性發生，通常來講新參加工做的人員若是真接受了你的觀點，使會主動改正他本身的問題的（雖然會有反覆）

四、即便是新工做人員，也會有很大的差異，做爲項目負責人，要善於發現發現這些差異。好比在這個項目中，有一個工做人員做過OA項目（畢業設計），對OA的理解比較多，那我就讓他負責系統最重要部分的設計，有的人比較細心，就讓他負責配置管理，有的人比較善於鑽研，就讓他負責權限管理部分的設計（那部分比較難），總之，沒有不可用的人，關鍵是看你是否用的對地方。只要用對地方，即可以達到事半功倍的效果。

學會向用戶彙報工做

固然了，也包括領導彙報工做。道理基本同樣。說一個在科委項目的課題的故事吧，那個課題是一個作的不太好的項目，用戶對咱們很不滿意，項目負責人被撤了，開發人員也都走了，讓我接手這個項目，個人目標是完善項目，個人項目經費（還有40%），其中的開發工做就很少說了，只說說向用戶彙報的事情，用戶的領導是一個50多歲的大媽(大媽是很聰明的，不然也不會在那裏作到這個職位)，對咱們很不滿意，開始的時候，我堅定認可錯誤，毫不隱瞞（得到對方的承認），其次在後來的時候每次去用戶那裏，我都會琢磨一下是否要去向她彙報，若是沒有過重要的事情，就想一想最近在作什麼事情，這樣在見到大媽的時候，能夠彙報，若是真是須要彙報，就要特別考慮一下幾個問題，一是我如今的工做進展，二是我遇到的問題，三是問題那些是我能夠解決的，何時會有答覆，四是什麼問題須要用戶配合。（好比硬件設備的改善等）具體配合的內容是什麼。在彙報的時候，我會私下掰手指頭，一個問題一個問題說，防止遺漏，同時要記住對方的回答。這樣幾次以後，大媽對個人感受很好，後邊的工做就好作了，後來項目順利完成。經費天然也回來了，因此在和用戶彙報工做的時候要特別注意幾點：

一、項目是最重要的，不管你採用什麼做客戶關係的方法，項目或產品必須過關，不然一切都是無用功（國家項目不必定）

二、在彙報的時候，態度要認真。特別是出現問題的時候不要一味推卸責任，講理由，這是沒有效果的（在單位彙報工做的時候也同樣，沒有人會理會你的理由）

三、彙報以前必定要準備，這樣條理清楚，事情完整。防止由於一點小事情連續打擾客戶。要讓客戶在每一次交流時都有很大的成果。

四、彙報的時候要掰手指頭，主要是防止問題的遺忘，特別是你們在就具體問題討論的時候容易干擾你的思路，使你遺忘事情。

五、在彙報以後要將全部問題都過一遍，是否全部的問題都有解決方法了，若是什麼事情不清楚，立刻問，這樣總比再次來好，在說出來，和用戶一塊兒確認問題的解決方法。

六、實在怕遺忘，最好帶一個錄音筆，但千萬不要讓用戶看到，也不要用這個東西做爲之後爭執的證據用（沒有好處的），只是做爲資料整理的一個備份，不然用戶會反感而不配合你之後的工做。

(李超 IT商業新聞網)