軟件開發者的軟實力:溝通與協作
作者:網絡轉載 發布時間:[ 2011/12/9 14:50:34 ] 推薦標簽:
我們工作當中處處需要協作,協作必然需要溝通。溝通和協作的重要性大家都知道,我在這里不贅述了,直接切入主題。我給大家講幾個團隊協作溝通過程中的常見問題與解決方法。
如何帶新人
老板不可能讓一個團隊都是熟練手和高手。那樣成本高,而且這些成熟手工作資歷都差不多,凝聚在一起是一股很有實力的團隊,但一旦土崩瓦解也是相當快的,這樣會對公司正常運營帶來很大的影響。
所以,我們每年都會擴招應屆畢業生,讓團隊呈階梯狀。這樣在管理上也容易。試想,如果呼拉一下子涌入一大批應屆畢業生,大家剛開始都一個職位差不多的工資,但是過了一年,肯定要有一些人升上去、一些人原地踏步。在企業,特別出眾、大家都很心服口服的人算是比較特異,這類人也比較少。大部分人都是差不多能力?赡苡腥烁毿囊恍炭嘁恍,更負責任一些,于是升上去了。但是,過去同一級別一起來的,這時候有人埋怨:“他何德何能比我們工資多職位高,還管我們?肯定是人家會拍領導的馬屁合領導的胃口”。很多流言都有,工作自然難以開展。
所以,我建議大家在招聘的時候,年齡、資歷階梯化一些。新人不要進得太多,或者新人不要過于集中在同一部門,否則隱藏的危機很大。業務擴展實在太快,也得掌握一下節奏,少量多批次的入職。階梯化后,老人走,新人來,企業才會持續經營。
新人來了,我們是師傅制的引導。師傅不是一個職位,和工資也不掛鉤。以后也不一定一直會是這個師傅領導這個新人。這個道理一定要提前和即將當師傅的員工說清楚。否則員工以為他成了小組長了。
師傅要負責新人在試用期的工作安排、學習、代碼檢查、開發中使用的框架講解,還包括公司的行政人事財務等規章制度、企業文化、公司注意事項,以及試用期結束時對新人的評價。
一個新人,來到陌生的新環境,企業真實是什么樣子,到底是怎么個工作方法,怎么快速融入現在的工作內容中,怎么和現有團隊快速磨合,人力資源部門是不可能做到這么深入和細致的。每個公司都有掛在墻上的制度,也有行走在日常行為中的潛規則,有個師傅帶著,新人不覺得孤單茫然,而能很快融入。沒有師傅帶著,新人們會自然集結成一團,那么每進入一批新人,新人抱成一個團,那公司成了一個個的利益團伙,真成烏合之眾了。
如何與高手打交道
這個也是很常見的一個問題。一個團隊肯定會有一個或幾個出眾的技術能手,承擔著軟件開發的核心編碼。常出現的問題是高手因資歷和能力強,覺得自己很可以了、自己是不可或缺的,所以對其他團隊成員脾氣暴躁、傲慢、訓斥、恥笑。但不能縱容這種情況的發生。因為大家都在一個團隊工作,大家都是員工,憑什么要聽你這個所謂的大牛吆五喝六的?如果團隊主管睜一只眼閉一只眼,一味捧著,每每開綠燈,而大牛還覺得自己是應該得到的,那其他員工會覺得太不公平。如此一來,這個主管連一個支持者都沒有了。
不管是有人問我如何管理現在已經牛氣沖天的大牛,還是如何除掉手持核心整天哼哼唧唧的大牛,我想說的方法是一個:分工。
一個軟件的開發,功能設計誰來做?整個過程的計劃、分配、推進、異常解決、報告誰來負責?數據庫設計誰來做?UI設計誰來做?質量誰來保證?文檔誰來做?……只要把軟件生產整個鏈條分解成若干個環節(當然需要根據手頭的人數和人的能力來劃分需要多少個環節),每個人負責自己其中的一環,項目經理主管計劃與推進,那么每個環節都是成功的必備環節,但又不至于成為生死懸于一線的環節。
這樣,才能成為團隊。如同CS游戲一樣,有人掩護,有人沖鋒,有人扔雷,有人守衛。團隊是這么來的。
如何與上層溝通
與上層溝通不難。難的是,上層如果是老板,那比較難。因為如果上層也是職業經理人,反正大家都是打工,從老板意義上來說都是公司員工而已。那這樣的溝通大家都沒有多大問題。大家頭疼的,也都是和老板的溝通,而且老板很有可能還是你的直接上級,但老板基于客戶、銷售、工資、公司流動現金壓力、“畫大餅”、士氣、老板自己的小算盤等等很多因素,老板不會全盤托出。當然,老板決定一個人的去留,一個人的職位升遷和工資增降,員工也拿不準如何和老板通暢溝通。于是,察言觀色成了必修課。有的人還覺悟不高,觀察不出來,琢磨不透老板到底想要什么,那工作被動了。
這是很多技術出身升為管理職位后的經理們面臨的大問題。我也處理得不是特別好。但我有幾個感悟和大家分享一下:
1.老板也是人。這個心態大家得理解。老板不是英明神武。他也有許多事情判斷不準確,他也有他的孩子老婆老爹老媽,他也是從上大學給人打工出來的,他也在Down電影聊QQ,只不過不讓你看見而已。如果你心態能這么放,那比較好互相諒解了。有的人,一見到老板不知道手該放哪里,蹭地站起來,惶恐地看著等待吩咐。這種心態很容易露怯。管理者要在危難之際顯身手,現在面對老板都誠惶誠恐,有了突發事件還不得腦袋空白?
2.老板是用人也疑、疑人也用。首先把自己的心態降一降,別期望你用我得用人不疑。這樣的期望值太高了。俗話說千里馬常有而伯樂不常有。在一個公司,你盡管有抱怨,但你畢竟現在沒有離職,那必然有你留下的原因。既然在,要面對,要接受,不接受也得接受,否則你走。可能走的地方多了,你也會接受這是現實,只不過我們不甘心接受而已。既然如此,那么我們做好計劃、做好報告、勤報告、說明來龍去脈。你越不讓老板放心,你越得不到資源。越得不到資源,做事越困難,顯得你也越沒本事。所以,得主動讓老板放心。老板看不看是老板的事,你寫不寫是你自己的事。孰重孰輕,咱們都知道。
3.不要把問題推給老板。老板不是救火隊員,人家是老板。人家找你來給你工資是讓你解決問題的。你把問題報告給老板然后等著老板解決,這是你的能力問題。正確的方法是把下列細節說清楚:事情原委;你的擔心;你分析后認為可能會出現哪幾種結果,哪種對我們有利,我們如何做,需要什么資源做,需要什么其他部門配合做比較合適?老板要的是決策與重組資源,而不是老板自己想著怎么解決。不要給老板問答題,要給老板選擇題。
如何做好售前與售后的協作溝通
研發和銷售的矛盾歷來已久。銷售為了簽單,不能做的經常都答應。但研發是執行落實部門,做不了的肯定不能嘴上過過癮OK的。怎么辦?
為了讓售前與售后不至于落差太大,必須有研發人員參與到跟單過程中。
研發人員一般在售前會參與這幾方面事情:
1.客戶需求討論。
2.客戶方案??技術方案部分制作、開發工作量與開發計劃部分制作。
3.客戶軟件演示與問答討論。
研發部門派出的人員一般都是項目經理,未來會接手這個項目的開發工作。客戶到底想要什么?什么業務問題適合用軟件解決?什么業務問題用什么方法能夠比較好地解決?解決周期大概多長?解決復雜度、難度、成本、人力到底多大?
只有商務經理和項目開發經理一起從頭到尾的參與,雙方才能達成一致,評估出這個項目的真正難度、周期、所需人工。而終的報價,是建立在這種綜合考量基礎上的。
而售后部門,一般會抱怨軟件怎么這么難用,怎么這么多Bug。所以,研發部門會有兩個角色來對售后部門進行支持。一個是測試兼技術支持,另一個是文檔員。
原因是版本在不斷升級。版本的特性來自于很多部門,有的來自于客戶,有的來自于客服支持,有的來自于銷售,有的甚至直接來自于老板。為什么要這樣設計這個功能,是為了滿足誰的需求?特性多了,版本多了,連售后實施部門的人也不清楚了。
誰能對軟件現有版本有比較深刻的理解,那肯定是研發部的人。而研發部一般不想打亂程序員的開發進程,而且程序員的思維風格和實施人員差異挺大,所以研發部門派出文檔人員在每個版本發布之后,進行版本新功能的培訓。而且軟件文檔寫得實用不實用,閱讀習慣是否容易理解,在這一環節都會得到檢驗。所以,研發部門文檔人員來做新版本內部推廣與培訓是好不過了。一方面校驗了文檔的質量與水平,另一方面更能加深文檔人員對產品細節的理解,從而寫出更實用的文檔。
技術支持也同樣。一般服務部門解決不了的問題,屬于深層次的技術問題,需要求助于開發人員。這也會打擾到開發正常計劃進程。那么由測試人員兼任技術支持。一方面,測試人員為了深度測試,他熟悉產品的很多細微之處,解決問題快。另一方面,在實施階段或客戶使用階段才暴露出問題,說明是當初測試的不嚴格,到底為什么會出現這樣的情況,測試人員通過這種支持也會得到反思,以利于后續做更專業的測試。
如何與客戶做好協作溝通
客戶往往是業務人員,不了解IT,也不了解問題的解決成本。他只想完成他的工作,其余的他一概不想知道,你給他的解釋他也聽不懂,只是催促你趕快做完。這種狀況下如何做好溝通?
我們仍然要使用專職的項目經理來解決這個問題。在項目啟動會上,項目經理要說明這個項目的目標、周期、難點、我們的工作方法、雙方各自的配合角色、容易出現的風險。這讓客戶有了一個預期。原來軟件不是安裝后用這么簡單,有這么多復雜辛苦的事情要做。而且大家也有了共識的工作方法。大家方法一致,才不會出現雞同鴨講。
在這樣的基礎共識上,每周的工作計劃,細化到每半天,落實到每個人,包括客戶方的每個人的工作責任、事情。每天日報、每周總結與檢查、微調、下周計劃等。
每次開會,我們都要留下會議紀要。會議的主題是什么,參與人是哪些人?每個分主題,每個人的觀點是什么,后大家的討論結果是什么?這都要記下來,否則極容易出現說了不算、算了不說的扯皮事情。
有了這么多過程文檔,要及時群發郵件給項目組的各個人,尤其是雙方的老板。做項目,我們往往稱為一把手工程。沒有大領導方的支持,項目中出現的客戶內部各個業務部門互相斗爭扯皮,經常會影響業務功能假需求、軟件不修改完不能上線、軟件流程被修改得面目全非十分怪異、反復培訓都不會的難題現象。
雖然每個項目都會有許多異常和磕磕碰碰,但大家都是一路走過來的,理解了整個來龍去脈,大家都知道已經盡力了。這OK了。
我在這篇文章中只是以研發部門為中心,上下左右,介紹了與內部、與老板、與銷售、與售后、與客戶各個利益方的協作方法。其實是有一整套組織結構、職能分工、過程管理、考核監督的方法論的,限于篇幅這里只能點到為止,詳細細節大家可看《走出軟件作坊》。
相關推薦

最新發布
性能測試之測試環境搭建的方法
2020/7/21 15:39:32軟件測試是從什么時候開始被企業所重視的呢?
2020/7/17 9:09:11Android自動化測試框架有哪些?有什么用途?
2020/7/17 9:03:50什么樣的項目適合做自動化?自動化測試人員應具備怎樣的能力?
2020/7/17 8:57:06幾大市面主流性能測試工具測評
2020/7/17 8:52:11RPA機器人能夠快速響應企業需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消滅嗎?為什么?
2020/7/17 8:43:03軟件測試基本概念是怎么來的?軟件測試生命周期的形成歷經了什么?
2020/7/16 9:11:10