自從上一家公司之后，我很少有機(jī)會(huì)去帶一些新人（公司一般都招一些技術(shù)獨(dú)立性的工程師），特別是經(jīng)驗(yàn)不是特別多的新小伙伴。在如今管理扁平化的公司，我正逐漸搭建自己的小team，并試圖讓團(tuán)隊(duì)成員快速融入并成長(zhǎng)。整理了一下最近實(shí)踐的經(jīng)驗(yàn)，我采用的方式如下：

1.文檔化

其實(shí)說這個(gè)文檔化，相當(dāng)一部分人是反感或者不屑的，每個(gè)人對(duì)這個(gè)項(xiàng)目或者一系列接口都是希望有詳盡的文檔，而當(dāng)需要自己去寫的時(shí)候就顯得十分抗拒。但是當(dāng)項(xiàng)目成員逐漸增加，當(dāng)項(xiàng)目代碼量和業(yè)務(wù)復(fù)雜度規(guī)模逐漸壯大，如果還是沒有一份靠譜的文檔來支撐，我想新來的研發(fā)人員應(yīng)該會(huì)看著龐然大物一般的代碼而笑容逐漸消失。

文檔的好處，不必說能更快讓成員有依據(jù)的了解代碼邏輯，也是對(duì)寫文檔的人一次歸納總結(jié)的提升。當(dāng)然文檔也不局限于項(xiàng)目整理或者業(yè)務(wù)邏輯整理，也可以是一些工作流、代碼規(guī)范相關(guān)的約束性的文檔，這對(duì)整個(gè)項(xiàng)目的規(guī)范化和工作協(xié)同的一致性有著非常重要的影響。文檔的形式也不僅局限于文字，也可以是圖表，甚至視頻。

我開始的時(shí)候還是采用盡可能文檔化來讓新成員更快了解現(xiàn)有項(xiàng)目，盡量做到可以通過文檔獨(dú)立（脫離人工引導(dǎo)）去熟悉項(xiàng)目的代碼結(jié)構(gòu)，敲黑板，劃重點(diǎn)，并且留出一些預(yù)留的期望任務(wù)。對(duì)于不同的人可以從同一份文檔理解不同層次的要求。對(duì)自己無要求或者要求不高的，我只能要求他能順利fix bug，不會(huì)因?yàn)楦膭?dòng)而影響到相關(guān)的功能或者代碼塊。對(duì)于一些有想法和能力的，我會(huì)提一些新的要求，比如去提前熟悉一些功能，試著去優(yōu)化原有邏輯，甚至改造底層框架。

不同的人，不同的性格，應(yīng)該用不同的方式去溝通，給予的預(yù)設(shè)期望也是不同的。不以物喜不以己悲，淡然地面對(duì)不同的人來人往。

我覺得最好看出一個(gè)人是否對(duì)代碼嚴(yán)謹(jǐn)并有編碼能力，就是從現(xiàn)有項(xiàng)目中發(fā)現(xiàn)不足且提出自己的想法。例如，我讓w同學(xué)在熟悉項(xiàng)目后，試著去增加中間件支持到框架流程中（之前老項(xiàng)目缺失對(duì)中間件良好導(dǎo)入的支持）。也許有人會(huì)說，我平時(shí)根本就用不著去關(guān)心已經(jīng)搭建好的框架，我只需要天天curd，天天copy paste之前的業(yè)務(wù)再改改，天天能跑通就得了。這可能就是有的人工作了三年還是用一年的經(jīng)驗(yàn)去做事的原因吧。

2.代碼規(guī)范

其實(shí)對(duì)于一些非靜態(tài)類的自由度高的編程語言，比如:javascript、php等，由于語言本身的自由度和開發(fā)人員的水平不同，代碼量和協(xié)同開發(fā)人數(shù)一增加，代碼風(fēng)格就很難統(tǒng)一，各種各樣的寫法會(huì)逐步蔓延到整個(gè)項(xiàng)目代碼邏輯中。初期不管，可能只是辣眼睛，后期不管可能拖垮整個(gè)相關(guān)功能甚至項(xiàng)目。所以在早期的時(shí)候就要盡量規(guī)范代碼，一起協(xié)商出一個(gè)通用性的代碼規(guī)范，統(tǒng)一所有人的代碼風(fēng)格。

代碼規(guī)范大致分成兩大部分，第一部分是代碼格式，第二部分是編程規(guī)范。代碼格式php方面有code sniffer，nodejs則可以用eslint去做強(qiáng)制規(guī)范。至于編程規(guī)范可以根據(jù)項(xiàng)目之前的風(fēng)格和一些通用性的規(guī)則來約束，比如變量名，函數(shù)名的可讀性，通用功能的封裝，面向?qū)ο蟮囊?guī)范等等。

所謂：沒有規(guī)矩，不成方圓。統(tǒng)一的好處在于工程師們能更好地理解代碼，提高工作效率，減少不必要的誤解。

?

3.規(guī)范工作習(xí)慣

?

這個(gè)內(nèi)容認(rèn)真講起來幾乎和“怎么成為一個(gè)優(yōu)秀的工程師”一樣寬泛，我這里主要是講的解決問題和處理問題方式。比如我們往往在開發(fā)的過程中會(huì)遇到一些讓人長(zhǎng)時(shí)間阻塞的bug或者業(yè)務(wù)邏輯，我們是否總是選擇死磕到底，耗盡deadline也沒有找到確切的解決方案？

我個(gè)人的建議是給自己解決一個(gè)問題設(shè)置一個(gè)deadline，可以是30分鐘，也可以是一個(gè)小時(shí)，由自己來定。一旦超過了這個(gè)期限，那么就必須果斷去尋求幫助。有相當(dāng)一部分工程師會(huì)覺得向他人尋求幫助是很羞恥的一件事，然而這通常只是face的問題，尋求外部資源和幫助是一個(gè)非常高效的解決途徑。

?

3.屬于自己的團(tuán)隊(duì)反饋

?

做產(chǎn)品或者運(yùn)營(yíng)的人是最能理解反饋的重要，同樣的團(tuán)隊(duì)建設(shè)里面隊(duì)員們的反饋也是不斷改進(jìn)的源頭。我采用的是不定期地溝通，隨時(shí)跟進(jìn)各個(gè)小伙伴的進(jìn)度，遇到怎樣的問題，是否需要外部的支持。也會(huì)相互做一些頭腦風(fēng)暴，或者結(jié)對(duì)編程來解決一些單人局限思維的問題。在每周五也會(huì)有小組范圍的review會(huì)，用來對(duì)本周或近階段來總結(jié)反思。

人和代碼一樣，如果不定時(shí)地去review，也會(huì)在不知不覺地滋生一些bad smell。比如某小伙伴狀態(tài)不太up，是否是給他/她分配的任務(wù)過于繁雜，是否是技術(shù)方面有倦怠感。在能力和資源所及的范圍內(nèi)盡可能讓每個(gè)人找到自己所喜歡的事物，能在繁重的工作之余，也能有一些成長(zhǎng)和收獲。

?

目前我還在做更多的嘗試，利用敏捷開發(fā)的一些原理，慢慢讓自己和小組一起成長(zhǎng)，變得更優(yōu)秀。

轉(zhuǎn)載于:https://www.cnblogs.com/freephp/p/9296416.html

總結(jié)

以上是生活随笔為你收集整理的尝试create tech team的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。