寫在前面
最近跟好些同是技術的朋友聊了下，發現其實很多規模不大的技術團隊，在從開發流程到專案管理，到日常的各項工作，不同職能部門的協作上都有不少的問題。我也嘗試動了動我這被技術腐蝕掉的小腦袋思考：
作為一箇中小團隊的技術負責人應該怎樣做好團隊建設提高生產力
本文是我日常腦子放空時的臆想，請辯證閱讀，歡迎討論和批評指正、補充；
中小團隊的定義
我這裡給出的中小團隊是：10-100人的技術/研發人員，產品、運維、dba等對應該規模若干；
中小團隊的技術負責人(下稱技術負責人)：大部分可能叫技術總監，一般下轄若干研發小組或者若干個專案組，零到若干個架構師；零到一運維支援部門；若干測試；
注意這裡的技術負責人不是CTO，只負責技術相關，不負責制定公司戰略的那種；
技術負責人職責
技術負責人在不同型別的公司（傳統或者網際網路），不同型別的業務（2b或2c），職責都有一定的差異，這裡總結他們共同職責：
- 人員管理：發掘同事的才能，把正確的人放在正確的位置，給制定正確的OKR，正向激勵團隊；
- 日常專案管理：多專案、多產品線管理和資源協調；
- 團隊目標與文化：制定技術團隊的年度OKR，中短期目標，長期目標和願景，明說或暗示確定團隊的文化；
- 提升開發效率保證軟體交付質量：設計軟硬體架構，確定各專案環境的具體定義；制定不同技術團隊的開發規範和生產、部署規範；提升專案；制定適合公司的軟體開發流程；提升開發效率和保證軟體交付質量；
- 提升跨職能協作效率：確定各種情況下的協作流程，提示團隊內協作效率，避免協作問題的無意義內耗；
- 演講職能：向上彙報，向下引導同事理解技術團隊的共同目標/上面的要求；
其他的暫時沒有很多分享，我想簡單說說人員管理和重點說說如何提升開發效率保證軟體交付質量怎麼提升跨職能協作效率
人員管理
-
組內成員有異議時，用“權力”或者說“上級”身份來脅壓是一大忌，應認真跟同事溝通，認真聽取對方意見，鼓勵表達不同意見，以理服人；
-
從心理認同開發者和管理人員只是工作職責不同；
-
善用deadline倒逼生產力；
-
部署下去有嚴格交付日期的任務不要等到最後一天才過問進度，自己心裡在各個時間點的進度情況都要有個譜；
怎麼提升跨職能協作效率
首先是確定組織架構和人員編排，選擇最有戰鬥力的方式組合團隊
產品經理：確定產品是跟研發小組/專案小組混編，還是單獨一個產品部門動態的方式跟不同的專案？單獨的話會不會增加溝通成本呢？混編的話會不會導致產品功能重疊/專案重疊呢？
研發：前後端/App等是按不同的產品線/專案固定小組，還是根據專案需要動態組合？還是用Scrum思想的指導動態根據專案組合？用固定小組方式偏僻會不會導致不同小元件技術閉塞不交流，重複造輪子呢？會不會導致不同小組間技術前景不一致而影響研發同事的流動性呢？
設計/UI：設計Ui這邊應當單獨部門，而不是混編；
運維團隊: 運維這邊也應該是單獨部門，注意控制好運維與開發的許可權，規範兩者的溝通。
測試： 測試這邊也應該是動態跟專案，不要跟研發或小組固定混編；
開會
- 如果是每天都開的晨會，建議不要超過15分鐘；最好就工位站立討論；
- 規定例會討論範圍，超過討論範圍的，相關人員私下召開；
- 不要把無關人員拉入無關的會議；
- 開會過程不要太嚴肅，要讓同事能表現自我，可能有意料之外的發現；
需求/問題溝通
- 大部分問題，最好當面溝通，不要在通訊軟體上大費周章的打字溝通；需要多方參與的，小會議室來個快會；但如果有需求變更等之類需要留底的，一定要在PM(專案管理系統)上留底，哪怕寥寥幾字；
- 口頭表述的需求，儘量讓研發同學簡單重述一遍；
- 避免口述的需求層層傳遞，產品需求提給研發A，研發A轉述給B，最後是研發C來做。應當產品直接對接到研發C；
如何提升開發效率保證軟體交付質量
需要個技術團隊的Wiki平臺
理由：一定要搭建個團隊內部的Wiki平臺，平時內部流程，技術文件需要個統一的文件平臺提供不能東一拉西一拉；
推薦：如果沒有很強的許可權管理的需求可以用Markdown支援很好的docsify，docsify直接提交Markdown檔案就可構建；
其他：BookStack 也不錯，整體和Gitbook、看雲比較像
備註：有的公司甚至多個不同地域的辦公點之間沒有專線搭自己的區域網，這點其實有必要的；
反面案例：沒有wiki平臺沒有統一管理文件手段，甚至你找某份需求文件久經周折找到對應的負責人後對方你發來一份word文件，真“傳不過三代”；
選擇合適的程式碼管理平臺
理由：這個不用說了
推薦：使用Gitlab，多年使用，體驗非常不錯；
反面案例：svn；
請使用介面管理平臺
理由：一定要搭建一個統一的Api管理平臺，避免各種Api重複編寫，沒有文件、文件到處放，幾經交接後找不到對應的維護人員等，混亂不堪；
推薦：使用YApi , 帶有豐富許可權管理、視覺化的介面管理、Mock支援、自動化測試、特別好用的是和Swagger和postman的資料相互轉換；
其他：另外是要去開發人員一定要維護好自己負責介面的Swagger，引數返回都必須是強型別的並且備註清楚；
反面案例：還是word文件；
選擇合理的git分支策略
理由：
- 什麼時候hot but fix分支，什麼時候是feature分支等；什麼情況適合用什麼型別分支，什麼時候要打tag等，並把命名規則給定下來；避免新人來手忙腳亂，開發自己回溯也方便；
- 應由架構師或資深開發結合現實情況選擇一中適合團隊的分支管理策略並寫到wiki上；
這塊需要單獨講，待我慢慢填坑；
定義程式環境
理由：明確的給出軟體開發的整個生命週期的各種環境定義，並部署好公共測試環境，在開發、協同開發過程中很重要；避免開發人員各方老在處理問題的時候因環境不同雞同鴨講（也就是統一環境這個無關變數）；
示例：
-
一般從開發=>測試=>上線，有對應的環境變數：Development(dev)=>Staging(stag)=>Production(prod)
-
Staging(預生產) 一般是是要提供給測試和產品等測試的，一般要使用區域網公共伺服器；
-
Development環境又因目前都是前後端分離的無論web和App或小程式，且前後端幾乎都要同時開發的，所以dev也是要使用區域網公共伺服器的；所以dev環境可以拆分成：local=>dev；
反面案例：
乾脆沒有Staging環境，甚至dev環境也沒有公共伺服器，前端需要等後端開發完才對接；且因為沒有dev公共環境，對接過程極其痛苦，甚至需要前端執行起後端的程式碼才能開發；
如此做法經常導致對接各方經常導致：“我這裡沒問題啊，要不要我幫你看看？”做無用功；
其他：
預生產環境維護的總體成本還是很高的，需要儘可能跟生產環境一模一樣，但帶來的回報也是客觀的，幾乎能避免大部分環境不一致忽略導致的問題；
單元測試整合測試
請儘量寫好單元測試和基礎測試，預生產環境上線要求，須通過測試才能打包/部署；
請衡量業務/團隊情況做出測試覆蓋率要求；
腳手架專案須給出單元/整合測試寫法的示例；
須有開發規範
理由：統一的開發規範，可以極大提高程式碼的可讀性和可維護性，降低維護成本提示開發效率；規範的開發可保證團隊的專業性，減小開發人員的流動性；
推薦：無論什麼語言，都可以參考阿里巴巴Java開發手冊https://github.com/alibaba/p3c，編寫出適合自己團隊的規範；
簡單舉例：
命名：方法用大駝峰還是小駝峰，類、介面、列舉、檔案、專案命名；私有、保護、公共方法、變數命名等等；
格式：if後面的大括號要不要回車；單語句的if要不要加大括號等；
資料返回格式：統一的返回格式，正確使用Http語義；
其他：
輕約束：用統一的外掛配置格式化程式碼，Visual Studio 推薦外掛CodeMaid(碼楸)，配置儲存就格式化；
強約束：用統一Ide外掛規範程式碼格式，格式不統一就編譯不通過，Visual Studio推薦EditorConfig；
前端的也一樣，可選工具更多；
資料庫使用規範
- 定義好各種命名規範；
- 定義安全規範；
- 文件給出索引使用注意點；
- 做好許可權控制，生產賬號只允許伺服器使用，開發人員只讀許可權等；
- 常見的各種錯誤用法集錦等，由資深開發或架構師整理好放到wiki；
前後端對接注意點
推薦：
有統一的返回格式，統一的異常處理等：
{
"code": 1,
"message": "success"
}
{
"code": 1,
"message": "success",
"data": {}
}
{
"code": 0,
"message": "fail"
}
{
"code": 40000,
"message": "exception 1"
}
{
"code": 40001,
"message": "exception 2"
}
要能做到前後端同時開發，要求後端先定義好介面，必須給出自文件Swagger並部署到區域網dev的伺服器；前端自己mock資料(瀏覽器外掛)或後端配合mock資料，前後端同時開發；
使用統一的介面授權邏輯，禁止每個人用不同的簽名/授權邏輯； 這裡推薦用OIDC(OpenId Connect) 也就是OAuth2.0擴充，.net的話使用 IdentityServer4；
快速開發框架(腳手架)有必要
無論前後端還是App來說來說都需要一個快速開發的框架(或者說腳手架)，一條指令生成模板專案；讓開發者把把精力放到業務開發上，同時模板專案已經寫好了很多遵循開發規範的示例，讓使用者快速上手，風格統一；
另外，模板專案裡面已經引用了很多公司內部的元件/中介軟體和基礎庫，快速整合使用；
另外還應有很多高頻程式碼的快速生成，比如curl生成對應前後端語言的Api呼叫程式碼；
反面案例：
開發從寫程式碼到搭好每人各異的專案框架開始寫業務，已經兩天過去了。然後後續每次需要用到第三方元件都自己去搜選一翻，一個專案光ORM就5個，三個Redis驅動；
選擇合適的專案管理(PM)工具
應當部署一套跟辦公通訊軟體聯動的PM工具，專案開發的整個生命週期都能及時有效的把通知有效送達到對應人員；
參考：
使用企業微信做辦公通訊軟體，可選用Tapd做PM工具，無論在專案立項、需求提出、需求變更、bug狀態更新等等狀態都能觸發到企業微信；
使用釘釘做辦公通訊軟體時，可選用Teambition做PM工具；
規範生產上線流程
開發者不應有生產環境寫檔案許可權，但讀許可權應該有且只有讀許可權；
上線過程必須有對應的審批流程，選擇一個適合本團隊的生產上線流程能避免很多不必要的問題，但也注意控制複雜度不要因流程影響效率；
參考：
開發者PM提出上線申請=>直屬上級審批=>運維組長審批並指定處理的同事;（整個流程不需要私下通知PM工具與辦公通訊軟體聯動）
反面案例：
開發者都有生產環境的上線許可權導致開發者對生產環境沒有敬畏心，經常頻繁更新；多個人部署衝突；直接拿生產環境做某些功能驗證等；
運維開發之間
很多東西不是提個工單給運維就能描述清楚了，工單是工單該當面溝通的還是要當面溝通；
像Nginx訪問日誌錯誤日誌，程式等目錄的可讀許可權應預設提供給開發，避免開發老是因為這些找運維浪費雙方時間；
提倡開發人員掌握基本運維知識，可由運維根據心得分享，提示開發人員解決問題思路；
如果有工具能顯著提示運維上線效率應當由運維衡量安全性後使用，比如Jenkins，docker，k8s等；
選用適合的產品原型管理工具
避免直接共享Axure匯出的html原型文件，應有共享的原型管理工具（區域網和商業產品均可）；
產品原型請嚴格做好版本管理，不能悄無聲息就把需求改了；
推薦：
區域網：直接搭個本地的的 axure.mysite.com
商業產品：
-
Axure本身支援；
-
Figma: https://www.figma.com/
做好知識分享/程式碼Review
-
鼓勵內部開發，運維等知識分享，但也要避免流於形式；
-
鼓勵同事之間做程式碼Review，定時分享同事寫的比較好的程式碼；
-
然後由小組長分享反面案例(不好的寫法)，時刻提醒大家程式碼有人review，三思再寫；當然要匿名的形式不然開發人員壓力太大了；
總結
感覺自己總體說的比較亂，整個題目也比較巨集大一時能想到的有限，有機會慢慢填坑；
部分要求也有一定的成本，但有的成本是不能節省的；
期待有更多不同觀點，也歡迎批評指正。
[參考]
無