我們工作當中處處需要協(xié)作，協(xié)作必然需要溝通。溝通和協(xié)作的重要性大家都知道，我在這里不贅述了，直接切入主題。我給大家講幾個團隊協(xié)作溝通過程中的常見問題與解決方法。

如何帶新人

老板不可能讓一個團隊都是熟練手和高手。那樣成本高，而且這些成熟手工作資歷都差不多，凝聚在一起是一股很有實力的團隊，但一旦土崩瓦解也是相當快的，這樣會對公司正常運營帶來很大的影響。

所以，我們每年都會擴招應屆畢業(yè)生，讓團隊呈階梯狀。這樣在管理上也容易。試想，如果呼拉一下子涌入一大批應屆畢業(yè)生，大家剛開始都一個職位差不多的工資，但是過了一年，肯定要有一些人升上去、一些人原地踏步。在企業(yè)，特別出眾、大家都很心服口服的人算是比較特異，這類人也比較少。大部分人都是差不多能力？赡苡腥烁毿囊恍，更刻苦一些，更負責任一些，于是升上去了。但是，過去同一級別一起來的，這時候有人埋怨：“他何德何能比我們工資多職位高，還管我們？肯定是人家會拍領(lǐng)導的馬屁合領(lǐng)導的胃口”。很多流言都有，工作自然難以開展。

所以，我建議大家在招聘的時候，年齡、資歷階梯化一些。新人不要進得太多，或者新人不要過于集中在同一部門，否則隱藏的危機很大。業(yè)務(wù)擴展實在太快，也得掌握一下節(jié)奏，少量多批次的入職。階梯化后，老人走，新人來，企業(yè)才會持續(xù)經(jīng)營。

新人來了，我們是師傅制的引導。師傅不是一個職位，和工資也不掛鉤。以后也不一定一直會是這個師傅領(lǐng)導這個新人。這個道理一定要提前和即將當師傅的員工說清楚。否則員工以為他成了小組長了。

師傅要負責新人在試用期的工作安排、學習、代碼檢查、開發(fā)中使用的框架講解，還包括公司的行政人事財務(wù)等規(guī)章制度、企業(yè)文化、公司注意事項，以及試用期結(jié)束時對新人的評價。

一個新人，來到陌生的新環(huán)境，企業(yè)真實是什么樣子，到底是怎么個工作方法，怎么快速融入現(xiàn)在的工作內(nèi)容中，怎么和現(xiàn)有團隊快速磨合，人力資源部門是不可能做到這么深入和細致的。每個公司都有掛在墻上的制度，也有行走在日常行為中的潛規(guī)則，有個師傅帶著，新人不覺得孤單茫然，而能很快融入。沒有師傅帶著，新人們會自然集結(jié)成一團，那么每進入一批新人，新人抱成一個團，那公司成了一個個的利益團伙，真成烏合之眾了。

如何與高手打交道

這個也是很常見的一個問題。一個團隊肯定會有一個或幾個出眾的技術(shù)能手，承擔著軟件開發(fā)的核心編碼。常出現(xiàn)的問題是高手因資歷和能力強，覺得自己很可以了、自己是不可或缺的，所以對其他團隊成員脾氣暴躁、傲慢、訓斥、恥笑。但不能縱容這種情況的發(fā)生。因為大家都在一個團隊工作，大家都是員工，憑什么要聽你這個所謂的大牛吆五喝六的？如果團隊主管睜一只眼閉一只眼，一味捧著，每每開綠燈，而大牛還覺得自己是應該得到的，那其他員工會覺得太不公平。如此一來，這個主管連一個支持者都沒有了。

不管是有人問我如何管理現(xiàn)在已經(jīng)牛氣沖天的大牛，還是如何除掉手持核心整天哼哼唧唧的大牛，我想說的方法是一個：分工。

一個軟件的開發(fā)，功能設(shè)計誰來做？整個過程的計劃、分配、推進、異常解決、報告誰來負責？數(shù)據(jù)庫設(shè)計誰來做？UI設(shè)計誰來做？質(zhì)量誰來保證？文檔誰來做？……只要把軟件生產(chǎn)整個鏈條分解成若干個環(huán)節(jié)（當然需要根據(jù)手頭的人數(shù)和人的能力來劃分需要多少個環(huán)節(jié)），每個人負責自己其中的一環(huán)，項目經(jīng)理主管計劃與推進，那么每個環(huán)節(jié)都是成功的必備環(huán)節(jié)，但又不至于成為生死懸于一線的環(huán)節(jié)。

這樣，才能成為團隊。如同CS游戲一樣，有人掩護，有人沖鋒，有人扔雷，有人守衛(wèi)。團隊是這么來的。

如何與上層溝通

與上層溝通不難。難的是，上層如果是老板，那比較難。因為如果上層也是職業(yè)經(jīng)理人，反正大家都是打工，從老板意義上來說都是公司員工而已。那這樣的溝通大家都沒有多大問題。大家頭疼的，也都是和老板的溝通，而且老板很有可能還是你的直接上級，但老板基于客戶、銷售、工資、公司流動現(xiàn)金壓力、“畫大餅”、士氣、老板自己的小算盤等等很多因素，老板不會全盤托出。當然，老板決定一個人的去留，一個人的職位升遷和工資增降，員工也拿不準如何和老板通暢溝通。于是，察言觀色成了必修課。有的人還覺悟不高，觀察不出來，琢磨不透老板到底想要什么，那工作被動了。

這是很多技術(shù)出身升為管理職位后的經(jīng)理們面臨的大問題。我也處理得不是特別好。但我有幾個感悟和大家分享一下：

1.老板也是人。這個心態(tài)大家得理解。老板不是英明神武。他也有許多事情判斷不準確，他也有他的孩子老婆老爹老媽，他也是從上大學給人打工出來的，他也在Down電影聊QQ，只不過不讓你看見而已。如果你心態(tài)能這么放，那比較好互相諒解了。有的人，一見到老板不知道手該放哪里，蹭地站起來，惶恐地看著等待吩咐。這種心態(tài)很容易露怯。管理者要在危難之際顯身手，現(xiàn)在面對老板都誠惶誠恐，有了突發(fā)事件還不得腦袋空白？

2.老板是用人也疑、疑人也用。首先把自己的心態(tài)降一降，別期望你用我得用人不疑。這樣的期望值太高了。俗話說千里馬常有而伯樂不常有。在一個公司，你盡管有抱怨，但你畢竟現(xiàn)在沒有離職，那必然有你留下的原因。既然在，要面對，要接受，不接受也得接受，否則你走？赡茏叩牡胤蕉嗔耍阋矔邮苓@是現(xiàn)實，只不過我們不甘心接受而已。既然如此，那么我們做好計劃、做好報告、勤報告、說明來龍去脈。你越不讓老板放心，你越得不到資源。越得不到資源，做事越困難，顯得你也越?jīng)]本事。所以，得主動讓老板放心。老板看不看是老板的事，你寫不寫是你自己的事。孰重孰輕，咱們都知道。

3.不要把問題推給老板。老板不是救火隊員，人家是老板。人家找你來給你工資是讓你解決問題的。你把問題報告給老板然后等著老板解決，這是你的能力問題。正確的方法是把下列細節(jié)說清楚：事情原委；你的擔心；你分析后認為可能會出現(xiàn)哪幾種結(jié)果，哪種對我們有利，我們?nèi)绾巫，需要什么資源做，需要什么其他部門配合做比較合適？老板要的是決策與重組資源，而不是老板自己想著怎么解決。不要給老板問答題，要給老板選擇題。

如何做好售前與售后的協(xié)作溝通

研發(fā)和銷售的矛盾歷來已久。銷售為了簽單，不能做的經(jīng)常都答應。但研發(fā)是執(zhí)行落實部門，做不了的肯定不能嘴上過過癮OK的。怎么辦？

為了讓售前與售后不至于落差太大，必須有研發(fā)人員參與到跟單過程中。

研發(fā)人員一般在售前會參與這幾方面事情：

1.客戶需求討論。

2.客戶方案??技術(shù)方案部分制作、開發(fā)工作量與開發(fā)計劃部分制作。

3.客戶軟件演示與問答討論。

研發(fā)部門派出的人員一般都是項目經(jīng)理，未來會接手這個項目的開發(fā)工作。客戶到底想要什么？什么業(yè)務(wù)問題適合用軟件解決？什么業(yè)務(wù)問題用什么方法能夠比較好地解決？解決周期大概多長？解決復雜度、難度、成本、人力到底多大？

只有商務(wù)經(jīng)理和項目開發(fā)經(jīng)理一起從頭到尾的參與，雙方才能達成一致，評估出這個項目的真正難度、周期、所需人工。而終的報價，是建立在這種綜合考量基礎(chǔ)上的。

而售后部門，一般會抱怨軟件怎么這么難用，怎么這么多Bug。所以，研發(fā)部門會有兩個角色來對售后部門進行支持。一個是測試兼技術(shù)支持，另一個是文檔員。

原因是版本在不斷升級。版本的特性來自于很多部門，有的來自于客戶，有的來自于客服支持，有的來自于銷售，有的甚至直接來自于老板。為什么要這樣設(shè)計這個功能，是為了滿足誰的需求？特性多了，版本多了，連售后實施部門的人也不清楚了。

誰能對軟件現(xiàn)有版本有比較深刻的理解，那肯定是研發(fā)部的人。而研發(fā)部一般不想打亂程序員的開發(fā)進程，而且程序員的思維風格和實施人員差異挺大，所以研發(fā)部門派出文檔人員在每個版本發(fā)布之后，進行版本新功能的培訓。而且軟件文檔寫得實用不實用，閱讀習慣是否容易理解，在這一環(huán)節(jié)都會得到檢驗。所以，研發(fā)部門文檔人員來做新版本內(nèi)部推廣與培訓是好不過了。一方面校驗了文檔的質(zhì)量與水平，另一方面更能加深文檔人員對產(chǎn)品細節(jié)的理解，從而寫出更實用的文檔。

技術(shù)支持也同樣。一般服務(wù)部門解決不了的問題，屬于深層次的技術(shù)問題，需要求助于開發(fā)人員。這也會打擾到開發(fā)正常計劃進程。那么由測試人員兼任技術(shù)支持。一方面，測試人員為了深度測試，他熟悉產(chǎn)品的很多細微之處，解決問題快。另一方面，在實施階段或客戶使用階段才暴露出問題，說明是當初測試的不嚴格，到底為什么會出現(xiàn)這樣的情況，測試人員通過這種支持也會得到反思，以利于后續(xù)做更專業(yè)的測試。

如何與客戶做好協(xié)作溝通

客戶往往是業(yè)務(wù)人員，不了解IT，也不了解問題的解決成本。他只想完成他的工作，其余的他一概不想知道，你給他的解釋他也聽不懂，只是催促你趕快做完。這種狀況下如何做好溝通？

我們?nèi)匀灰褂脤Ｂ毜捻椖拷?jīng)理來解決這個問題。在項目啟動會上，項目經(jīng)理要說明這個項目的目標、周期、難點、我們的工作方法、雙方各自的配合角色、容易出現(xiàn)的風險。這讓客戶有了一個預期。原來軟件不是安裝后用這么簡單，有這么多復雜辛苦的事情要做。而且大家也有了共識的工作方法。大家方法一致，才不會出現(xiàn)雞同鴨講。

在這樣的基礎(chǔ)共識上，每周的工作計劃，細化到每半天，落實到每個人，包括客戶方的每個人的工作責任、事情。每天日報、每周總結(jié)與檢查、微調(diào)、下周計劃等。

每次開會，我們都要留下會議紀要。會議的主題是什么，參與人是哪些人？每個分主題，每個人的觀點是什么，后大家的討論結(jié)果是什么？這都要記下來，否則極容易出現(xiàn)說了不算、算了不說的扯皮事情。

有了這么多過程文檔，要及時群發(fā)郵件給項目組的各個人，尤其是雙方的老板。做項目，我們往往稱為一把手工程。沒有大領(lǐng)導方的支持，項目中出現(xiàn)的客戶內(nèi)部各個業(yè)務(wù)部門互相斗爭扯皮，經(jīng)常會影響業(yè)務(wù)功能假需求、軟件不修改完不能上線、軟件流程被修改得面目全非十分怪異、反復培訓都不會的難題現(xiàn)象。

雖然每個項目都會有許多異常和磕磕碰碰，但大家都是一路走過來的，理解了整個來龍去脈，大家都知道已經(jīng)盡力了。這OK了。

我在這篇文章中只是以研發(fā)部門為中心，上下左右，介紹了與內(nèi)部、與老板、與銷售、與售后、與客戶各個利益方的協(xié)作方法。其實是有一整套組織結(jié)構(gòu)、職能分工、過程管理、考核監(jiān)督的方法論的，限于篇幅這里只能點到為止，詳細細節(jié)大家可看《走出軟件作坊》。