團隊建設

u014249394發表於2017-02-24
  • 介紹

做很多事情,都是需要一個團隊的。我主要介紹的是如何才能打造一個有自己文化的越來越好的軟體研發團隊。這裡涉及到了三個問題:為什麼需要打造、什麼是團隊文化、好團隊的標準。
  • 打造

首先,我不認為花錢把一堆人招聘過來,然後每天拼命地加班幹活,就算是一個團隊了。尤其對於新組建,或者是隊伍中新加入的成員比較多的情況,“團隊建設”就是一件非常重要的事情。對,我認為團隊是“建設”起來的,而不是“買”來,更加不是通過“傘兵空降”來的。而建設這個詞,大家應該多少有點認識吧,絕非是一朝一夕來的——即使是3D列印技術也是要一個一個部件來列印的。 一把好劍,是打鐵匠一錘一錘地用心打造出來的。這樣的劍,鋒利無比;這樣的劍,能在關鍵時刻發揮應有的作用;這樣的劍,是受眾人的肯定的。一個好的團隊,同樣是需要Leader帶領每個成員一同打造的。這樣的團隊中,每個成員之間都不僅僅是工作和任務的關係;這樣的團隊中,每個成員都是有其重要的位置;這樣的團隊中,每個成員都儘可能快樂地得到成長;這樣的團隊中,每個成員都是在積極主動地向前奔跑;這樣的團隊中,自己的文化不會丟失。 每個年輕的團隊,都會有很多值得改進和提升的地方。而什麼的團隊,是我這裡說的“年輕”的團隊呢?某個公司成立十年,而某個專案組又是從一開始就存在的;這樣的團隊就一定不是年輕的團隊嗎?我這裡的“年輕”更加強調的是——幼稚、沒有形成自己的做事風格。每個團隊,都會有人員的變動;如果變動的過於頻繁,也是“年輕”的一個體現。這裡簡單地引入一個思考:如果一個新加入的成員,效率或者態度讓人有點不滿意,那我們該怎麼辦,直接拋棄呢還是任其發展呢?
  • 文化

什麼是文化呢?這個問題很難回答,只能是談一點自己的認識。有自己文化的團隊,並不需要依靠公司制度、強制加班等等生硬的東西來改造成員。文化應該是能夠在團隊中每個人的一言一行中傳播的,是薰陶出來,不是加工好的。 強迫大家每天加班到很晚是一個件非常自私的事情(排除公司制度要求的情況),這完全是Leader害怕完成不了專案而出的下下策。在絕大多數情況下,必須通過加班才能搞定的事情,其實不加班也能搞定。那麼,你有沒有反覆地思考這個問題呢?怎麼樣才能不加班就把“活兒”幹完呢? 如何才能做到團隊成員之間溝通交流都比較Open,想要說、敢說、會說意見或者建議。這是Leader每天都應該思考的問題。沒有了平等、積極的溝通,團隊就是一潭死水。
  • 標準

每時每刻,每人都應該在積極主動地思考:如何才能進一步提高工作效率(我這裡的效率,當然是建立在高質量的基礎上)。這是我所認為的好團隊,這樣的團隊不是隻會搞定上面分配的任務,而會有團隊內部的沉澱,是有自己文化的團隊。 對團隊成員整體研發素質的提高,減少木桶效應帶來的問題。是Leader或者團隊中的技術達人所值得思考的問題。自己能夠在不斷地成長,很簡單;能帶領整個團隊一起成長才是件有挑戰的事情。 讓大家的基礎技術能力、意識保持在一個比較均衡的狀態。 利用一個工具來來做到能對團隊成員的技能分佈有個清晰的認識。人類之所以偉大的一個特點,就在於學會了使用工具。工欲善其事必先利其器,沒有一整套高效率的工具的支撐,那麼你的團隊還處在並將長期處在原始階段。
  • 測試人員

測試人員不能僅僅停留在手工測試,看功能能不能完成、有沒有頁面上的錯誤提示等。 程式或者系統、工具,開發完成後,都是要實施的,僅僅把功能測試完成並不算結束。在實施和運維的階段,也可能會出現很多問題。所以,我的想法是要讓測試人員提前介入到這些階段。 測試還要對系統的部署過程進行測試。例如:要學會安裝程式、資料庫使用、服務的啟動和停止等。 系統執行起來後,最好要檢視日誌檔案中是否有不應該出現的異常、報錯,瀏覽器控制檯是否有錯誤資訊,是否有無法載入的js、css、image等資源。
  • 開發人員

很多開發人員,只知道Coding,對Web應用部署、Jenkins持續構建工具、Linux作業系統等都不瞭解。這是非常不應該的——如果連自己寫的系統或者程式都不會部署,怎麼能說的過去呢。
  • 資產沉澱

對一個團隊來說,一定會有很多資產需要持續地積累、沉澱,包括:制度、開發規範、專案文件、技術資料等等。那麼用什麼形式來維護比較好呢,word是我不推薦的一種方式。 我維護過的一些幫助文件,有一些是非常大的,可能會有幾十甚至上百頁,每次修改都是很痛苦的。除了它的笨重以外,還有很多致命的缺點:無法多人協作、難以進行版本維護、難以檢索。經驗證明,難用的文件就約等於沒有。wiki這種web的形式就是非常好的,還可以生成多種格式的文件。
  • 分享

在團隊中,每個人的具體職責不同,所專長的領域也不同。我們應該逐漸建立起來成員之間熱衷於分享的精神。 對於開發人員來說,每當解決一個較大模組的問題時,就可以給其他人做個分享。第一,可以檢驗自己對這個問題理解的是否夠清楚明白;第二,其他人再次遇到這類問題時,就可以減少不必要的重複勞動,當然會提高效率。 更多有關分享的介紹,請參考《Java開發成長之路第七年》。

檢視原文:http://surenpi.com/2017/01/01/team_build/

相關文章