軟體開發人員的軟實力：溝通與協作

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

 

如何帶新人 

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

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

所以，我建議大家在招聘的時候，年齡、資曆階梯化一些。新人不要進得太多，或者新人不要過於集中在同一部門，否則隱藏的危機很大。業務擴充實在太快，也得掌握一下節奏，少量多批次的入職。階梯化後，老人走，新人來，企業才會持續經營。  

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

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

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

 

如何與高手打交道 

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

不管是有人問我如何管理現在已經牛氣衝天的大牛，還是如何除掉手持核心整天哼哼唧唧的大牛，我想說的方法就是一個：分工。 

一個軟體的開發，功能設計誰來做？整個過程的計劃、分配、推進、異常解決、報告誰來負責？資料庫設計誰來做？UI設計誰來做？品質誰來保證？文檔誰來做？……只要把軟體生產整個鏈條分解成若干個環節（當然需要根據手頭的人數和人的能力來劃分需要多少個環節），每個人負責自己其中的一環，專案經理主管計劃與推進，那麼每個環節都是成功的必備環節，但又不至於成為生死懸於一線的環節。 

這樣，才能成為團隊。就如同CS遊戲一樣，有人掩護，有人衝鋒，有人扔雷，有人守衛。團隊就是這麼來的。

 

如何與上層溝通

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

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

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

2.老闆是用人也疑、疑人也用。首先把自己的心態降一降，別期望你用我就得用人不疑。這樣的期望值就太高了。俗話說千裡馬常有而伯樂不常有。在一個公司，你儘管有抱怨，但你畢竟現在沒有離職，那必然有你留下的原因。既然在，就要面對，要接受，不接受也得接受，否則你走。可能走的地方多了，你也會接受這就是現實，只不過我們不甘心接受而已。既然如此，那麼我們就做好計劃、做好報告、勤報告、說明來龍去脈。你越不讓老闆放心，你就越得不到資源。越得不到資源，做事越困難，顯得你也越沒本事。所以，得主動讓老闆放心。老闆看不看是老闆的事，你寫不寫是你自己的事。孰重孰輕，咱們都知道。

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

如何做好售前與售後的協作溝通

研發和銷售的矛盾曆來已久。銷售為了簽單，不能做的經常都答應。但研發是執行落實部門，做不了的肯定不能嘴上過過癮就OK的。怎麼辦？

為了讓售前與售後不至於落差太大，就必須有研發人員參與到跟單過程中。

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

1.客戶需求討論。

2.客戶方案——技術方案部分製作、開發工作量與開發計劃部分製作。

3.客戶軟體示範與問答討論。

研發部門派出的人員一般都是專案經理，未來會接手這個項目的開發工作。客戶到底想要什嗎？什麼業務問題適合用軟體解決？什麼業務問題用什麼方法能夠比較好地解決？解決周期大概多長？解決複雜度、難度、成本、人力到底多大？

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

而售後部門，一般會抱怨軟體怎麼這麼難用，怎麼這麼多Bug。所以，研發部門會有兩個角色來對售後部門進行支援。一個是測試兼支援人員，另一個是文檔員。

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

誰能對軟體現有版本有比較深刻的理解，那肯定是研發部的人。而研發部一般不想打亂程式員的開發進程，而且程式員的思維風格和實施人員差異挺大，所以研發部門就派出文檔人員在每個版本發布之後，進行版本新功能的培訓。而且軟體文檔寫得實用不實用，閱讀習慣是否容易理解，在這一環節都會得到檢驗。所以，研發部門文檔人員來做新版本內部推廣與培訓是最好不過了。一方面校正了文檔的品質與水平，另一方面更能加深文檔人員對產品細節的理解，從而寫出更實用的文檔。

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

如何與客戶做好協作溝通

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

我們仍然要使用專職的專案經理來解決這個問題。在項目啟動會上，專案經理要說明這個項目的目標、周期、痛點、我們的工作方法、雙方各自的配合角色、容易出現的風險。這就讓客戶有了一個預期。原來軟體不是安裝後就用這麼簡單，有這麼多複雜辛苦的事情要做。而且大家也有了共識的工作方法。大家方法一致，才不會出現雞同鴨講。

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

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

有了這麼多過程文檔，就要及時群發郵件給項目組的各個人，尤其是雙方的老闆。做項目，我們往往稱為一把手工程。沒有最大領導方的支援，項目中出現的客戶內部各個業務部門互相鬥爭扯皮，經常會影響業務功能假需求、軟體不修改完不能上線、軟體流程被修改得面目全非十分怪異、反覆培訓都不會的難題現象。

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

我在這篇文章中只是以研發部門為中心，上下左右，介紹了與內部、與老闆、與銷售、與售後、與客戶各個利益方的協作方法。其實是有一整套組織圖、職能分工、過程管理、考核監督的方法論的，限於篇幅這裡只能點到為止，詳細細節大家可看《走出軟體作坊》。

作者簡介：

阿朱，本名呂建偉。《走出軟體作坊》一書作者。10年以上商業軟體從業經驗，10餘年來一直專註行業管理資訊化領域，7年職業經理人生涯，在商務分析、產品體系規劃、研發人才體系搭建、研發過程管理、技術架構、貫通售前\研發\售後方面有多年經驗。

（本文來自《程式員》雜誌10年01期）