如何組織一個高效的開發團隊(轉)

如何組織一個高效的開發團隊

俗語云：“三個臭皮匠，抵上一個諸葛亮。”天下臭皮匠多如牛毛，可找到能抵得上諸葛亮的三個臭皮匠比找諸葛亮還難。昔有司馬德操言：“伏龍、鳳雛，兩人得一，可安天下。”劉備同得伏龍、鳳雛二人，而漢室終不可興。以上兩者說明一個道理：優秀的人才是不可替代的；有了優秀的人才，也不一定能幹成一番大業。

一、怎樣挑選優秀的專案經理

衡量一個人才的是否優秀，不同人有不同的看法。現在比較流行的兩大標準是：智商和情商（呵呵，真是在商言商）。
智商，很好理解。這是看這個人是否聰明。微軟公司在選擇經理人員時，總是把他們的技術知識和運用技術去賺錢的能力放在首位。程式經理一般就是程式設計師隊伍中最聰明的那個傢伙。比爾·蓋茨在1996年出版的一本名為Cusumano的書中曾這樣描述聰明人：聰明人一定反應敏捷，善於接受新事物。他能迅速進入一個新領域，給你一個頭頭是道的解釋。他提出的問題往往一針見血、擊中要害。他能及時掌握所學知識，並且博聞強記，他能把本來認為互不相干的領域聯絡在一起使問題得到解決。他富有創新精神與合作精神……
情商這玩意兒說來話就長了。這些年，我也懶得去翻一些管理方面的論著，不知道專家們對情商一詞作何解釋。在我出道之前，曾在一個國家事業單位呆過。我的上級領導是一個出了名的好好先生，極會左右逢緣，工作也踏踏實實，從不隨地大小便。只是業務水平不怎麼樣，跟著他兩年，沒看他幹出過什麼特別的成績。當然，也沒看見他犯過什麼錯誤。此君官運享通，在阿呆離開時已經當上了副院長。阿呆非常納悶，一日，酒醉，問其故。答曰：“豎子，爾何糊塗至此？豈不知當今世上最重EQ乎？。“言罷伏桌而睡。阿呆聽後還是不解，又不好意思再問，便無聊地拿著酒瓶在桌子邊滾來滾去，忽見酒瓶上“小糊塗仙”四字，頓時恍然大悟：情商，酒也。
上面只是一則半真半假的笑話。不過，今人對情商的迷信也確實太厲害了。阿呆接觸過不少公司的管理人員，十有八九開口必談情商。情商重要嗎？當然重要。一個優秀的人才不光要有才，還得要有德，同時又要為人隨和，接物待人，知得大體。但從用人的角度來講，也用不著責全求備，墨守成規。要知道金無赤金，人無完人。更何況大凡聰明之人，多一身傲骨。若未得明主，平生學無處施展。寶刀雖利，不動文士之心；駿馬雖良，不中農夫之用。英雄雖有掀天揭地手段。無人識他、重他，還要奚落他。又怎能讓他心平氣和，屈首低眉。故伏龍呤樑父，雛鳳醉耒陽,周處害鄉鄰。伯樂選千里馬，必先看病者異者，老人家這樣做不是沒有道理的。雖為千里駒而不能挾風雷以縱橫沙疆，雖為利錐而不能置於囊中以求破綻鋒芒。惜哀鴻而遍於諸史,阿呆後子昂而獨愴然而涕下。

一個合格的專案經理應該具備哪些素質呢？
阿呆認為：專案經理首先要懂管理。管理是一門重要的學問。管理者不僅要懂得管理這門學科，還要熟悉自己直接下屬所從事的工作。好象現在又流行起“外行管理”了。即所謂的外行管理內行。阿呆對此理解為，管理者首先得懂管理，有管理方面的知識積累。但也不能說他就可以完全不懂業務了。要是他不懂得直接下屬所從事的工作，任他拿多少個管理學博士，出版過多少管理方面的論著，都是瞎搬。我覺得要想搞管理，還是得多看些管理方面的論著。我聽過不少人說，現在管理方面的書太多了，理論太多了，學了沒啥子用，實際都用不上。真是這樣嗎？阿呆認為，不盡然。阿呆學電腦很有體會。阿呆在學新一門新軟體，或者學一門新程式設計語言之前，是很少去啃大本本的。只是隨便找幾個網友問問。但當學到一定程度之後，再回過頭去讀書本，阿呆覺得大有斬獲，很多地方都是茅塞頓開，心胸透亮。學管理一樣，有的手只可觀其大略，但有的書必須看懂，理會得人家的高明之處。不能象許世友看紅樓夢，只為看書而看書。
其次要頭腦靈活，思維敏捷，知識面寬廣，考慮問題比較全面。
現在IT技術發展非常快，常常是一袋煙的功夫，一項新技術就出來。多運用一項成熟的新技術就意味著節約大量的人力物力。要是專案經理是一個程咬金式的人員，來來去去就那三板斧。得，在這樣的人領導下開發出來的產品，你忙著去為客戶更新換代吧。
再者，專案經理必須技術精湛，足以服眾。外行管理內行，對做大官的來說，還行得通，人家有條件配一個精通業務的副手。專案經理不過一區區小職，他面對的是最直接的技術問題。 當專案遇到困難時，需要專案經理能正確而迅速地做出確定。能充分利用各種渠道和方法來解決問題。要是作為專案經理，一旦遇到難題就一籌莫展，眼等著下面的人來為你解決。完了，你還是悠著點吧，今後誰能服你？又有誰能聽你的呢？
第四，作為專案經理，他還要能跟蹤任務，有很好地日程觀念。別幹什麼事，都要對老闆說我這活還需順延多少多少時間。一招鮮，走遍天，要是競爭對手先把同類的產品開發出來了，市場份額也就被人搶得差不多了，產品也過了最高利潤點。做專案開發的要做到按時完成或者提前完成，很不容易。這裡面有諸多因素。有僱主的原因，有專案經理的原因，也還有團隊的緣因。關鍵還是在於專案經理沒做好前期的三項調查工作（具體見阿呆前期寫的《軟體開發中的專案管理》以及《如何控制專案的開發進度》）。
第五，專案經理還應該善於協調，並且具有良好的溝通技巧。

二、 專案人力資源管理

一個開發團體，小至兩人，多則不知幾何。除了專案經理外，可能還有系統分析員、程式設計師、資料庫管理人員、文件開發人員等。但再少不能少了測試人員。

專案管理中的人力資源管理，主要包括對團隊所有成員的監督、培植和激勵。
監督 主要根據預先制定的日程安排和進度表，核對所有成員的開發進度。如果專案大，參於人員眾多，進度則訂細些；反之，進度訂個大略就行了。
培植 很重要。你領一幫人幹活。你得能教人家點東西。或者幫助人家學點東西。要是人家跟你幹，什麼也學不到，甚至連學的機會也沒有。人家能長久地跟你嗎？除非是那種碌碌無為沒有什麼抱負的人。
激勵 1966年，凱司西部大學心理系主任匹茲伯格在一份1685名僱員參與的調查研究中，他分析了影響生產力的因素。那時流行的觀點認為工作成果主要取決於更高的工資、更多的監督，以及更吸引人的工作環境，根據匹茲伯格的研究，這些因素如果不滿足會產生不滿意的情形。但是如果滿足了也不能激勵員工更賣力地工作，匹茲伯諾發現人們工作的主要激勵因素來自於個人成績表現以及由些獲得的認可度，匹茲伯諾總結出激勵因素包括工作成就，認可度、工作本身、責任、晉升和發展。我曾遇到過這樣一個老闆，常常開口就是對研發人員煩。結果你煩我煩大家都很煩，士氣低落，萬馬齊黯。背地裡不知捱了多少人埋怨。試想要是有人老對你說，我很煩你。你會喜歡他嗎？
大膽提撥或向上級主管推薦可造之才，是專案經理之一大責。因為專案經理最瞭解自己手下人的能力，最瞭解他們的耿性。我記得曾經有一位管理先輩說過：一個經理要是一年之內沒有向公司人力資源部推薦過任何自已的下級，那麼他就不是一個稱職的經理。

三、 團隊的溝通

一個IT專案需要進行大量的溝通協調。不光是跟團體內部成員，有時還要跟其它關人員。所以說，一個專案的成功是否，上級領導的支援度佔了很大的權重。在本文中，阿呆僅談談團體內部成員之間的溝通。
通常一個團隊組成人員越多，溝通也就越複雜。除了有更多的個人溝通偏好外，還有更多的溝通渠道。我記得有一本書，書名我忘了，上面曾列有這麼一個公式。
溝通渠道的數目=N（N-1）/2
公式裡的N是指團隊中的成員人數。比方說吧，要是這個團體只有2人，那麼溝通渠道就只有一條。要是3人，則有3條，要是10人呢，則有45條。
呵呵，其實算這玩意兒也沒有什麼意思，只當作個遊戲。我們接著談溝通。
人家問我作老師有什麼好處。我告訴他：作老師的時候，我學會了怎麼樣把事情考慮得更全面。
作老師，你面對的是幾十個甚至於幾百個學生（我曾教過一個二百多人的班）。你面對的是幾十個甚至幾百個腦袋。每個腦袋裡面裝的東西不一樣，同一個問題，可能會有不同的理解，同一個方程，可能會有不同的演算法，通常還會包含不同的錯誤。我讀了兩年的程式碼，找了兩年的錯誤。當時非常鬱悶，非常難受。現在回想起來，那兩年，其實是我收穫最大的兩年，我從那麼多的學生那兒學到了那麼多的思維方式。要不，阿呆比現在還不知要呆多少倍呢。
不要怕與他人溝通。不論是高手還是菜鳥，他們都會對你有所幫助。很多靈感都來自他人的隻言片語。

溝通通常有口頭溝通，會議溝通，電話溝通，郵件溝通這幾種形式。
我不喜歡郵件溝通，只是把它當作其它溝通的一種輔助形式。郵件內容也非常簡短。除非你發給對方的是笑話之類的消遣式的東西，否則沒有多少人會反把你的長篇大論仔仔細細地看完的。很多重要的資訊往往被接收者疏忽了。要是實在太長了的話，最好把你需要重點表達的內容用不同的顏色不同的字型顯出來。
電話溝通也不是特別好。特別是幾張辦公桌共一臺電話機的。阿呆就是這樣的。身邊的電話機老響，老有人打電話過來找張三李四的。不厭其煩。阿呆工作時又是極不喜被人打擾的。後來好不容易從煙錢中省出一副耳機，誰知公司又說上班時間不能戴耳機。真不知道這年頭做人怎麼就這麼難啊。可見做管理，也不能光坐在辦公桌前照本宣科，光想著怎麼罰人，悶著頭寫什麼三大紀律八項注意之類的破玩意兒。還是把心思主要放到怎麼為員工謀福利改善大家工作環境上吧。阿呆認為，衡量一個公司的管理者的水平，不能看他處罰了多少人，關鍵要看獎勵了多少人。
會議溝通的效果真不錯。不過開會之前，會議發起人最好能把會議的主題、需要討論哪些問題、需要達到什麼樣的效果等預先通過郵件的方式傳給所有參會者。讓大家有思想準備，這樣討論起來才更有針對性。搞研發都有這樣的體會，工作一旦忙起來，就什麼都忘了，當需要開會討論某個具體問題時，又有些好多東西想不起來了。所以，要是會議的專業性比較強的話，會議通知寫得越詳盡越好。
口頭溝通是最好的了，能口頭溝通最好口頭溝通，兩、三人，佔據一個角落，暢所欲言，各抒已見。 只是注意別影響身邊不相干的人罷了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21172/，如需轉載，請註明出處，否則將追究法律責任。