網際網路公司如何管理研發團隊
需求管理平臺 Req
在網際網路公司，每天都會有不同的需求被反饋，可能是線上bug、可能是使用者體驗最佳化、也可能是新的專案需求等等。這些需求按類別可以分為三類：日常需求、缺陷需求、專案需求。與之對應的有3個管理池：需求池、缺陷池和專案池。
需求池
需求池裡可以建立簡單的日常需求，這些需求一般是一對一可以指派的問題。比如運營提出的可以提高使用者體驗的一些最佳化建議、UI提出的視覺方面的修改和調整。這些問題一般不屬於線上BUG，可以短期（1到2天）內修復上線的。日常需求的生命週期如下：
建需求 －> 拉分支 －> 本地開發測試 －> 程式碼評審 - > 預釋出驗證 -> 正式釋出驗證
缺陷池
缺陷池是給測試部門使用的。無論是日常需求還是專案釋出都會有測試工程師介入測試，測試過了才能發上線。測試過程中發現的一切問題都要如是記錄在缺陷池裡，指明對應的責任人和處理人，並跟蹤此缺陷的生命週期。缺陷按照嚴重性可以分為P0～P5，P0最為嚴重，一般發生P0缺陷，整個網站或者系統將無法正常執行，責任人和處理人需要在1個小時之內解決，如果解決不了需要立即回滾程式碼。如果你造成P0缺陷，那麼對不起，輕則季度考核不合格，重則直接勸退。
而P級數字越大，缺陷嚴重程度越低。不過如果無法在規定時間內解決該缺陷，會自動上升一級。所以一旦出現缺陷，壓力還是很大的，開發工程師應該在自測完全沒問題之後才能申請測試工程師進行專業型測試。
專案池
一般一個需求的生命週期超過8天的必須申請立項——即成為一個單一專案進行管理。一個專案完整的生命週期如下：
需求評審 -> 產品出文檔和互動 -> UI 製作視覺稿、標註稿 -> 後端給出Mock資料介面 --> 前端編寫頁面，繫結資料 -->視覺UI走查 --> 前後端線下連調 --> 後端介面上線 --> 用例測試 ---> 前端頁面上線 --> 使用者反饋和最佳化
每個專案會有一個產品經理、專案經理整體跟進，如果專案成員多的會設立專門的專案室（所謂的“小黑屋“）進行開發和溝通，以提高溝通效率。
wiki文件管理平臺 Doc
每個研發團隊都需要有一個統一的平臺來管理一些文件，包括介面的API文件、程式碼規範、最佳實踐和技術分享等東西。在網際網路公司我們不會寫一大堆的word文件或者整一些PPT，所有的文件都採用markdown語法編寫，簡約又易於分享。
介面API文件
介面文件的作用是為了前後端解耦。現在前後端分離的開發模式已經深入人心的，如果你還發現你的公司仍然搞一大堆什麼JSP、Smarty、Velocity、FreeMarker等所謂的後端模板引擎的，趕緊告訴他們已經Ou t了！前端模板引擎的效能和使用者體驗都遠遠高於後端。呵呵，可能這時遠方飄飄然會傳來一聲不屑——胡扯，後端模板引擎的效能怎麼會輸給前端呢？會這麼想你肯定不知道前端模板引擎強大的預編譯功能——模板引擎再厲害還是會有編譯過程，預編譯則把編譯事先做了。
好了迴歸主題，規範的介面API文件應該包含以下幾個內容：
第一：介面的用途
第二：介面的型別、是否需要登入
第三：介面的引數列表和欄位說明
第四：介面成功返回的資料欄位說明
第五：介面失敗返回的資料欄位說明
第六：介面對應的mock資料入口
程式碼規範
說到程式碼規範，各個團隊有所不同。前端、後端、客戶端、測試、大資料等各有各的程式碼規範。程式碼規範的作用是統一編碼風格，提高程式碼複用能力。這個規範可以是長期開發經驗積累整理的一套編碼風格。前端的話應該包括：檔案命名規範、HTML文件規範、less或Sass編寫規範、JavaScript編碼規範等。程式碼規範應該隨著變成語言的升級而不斷更新，並且每次更新後應該對每位開發人員進行程式碼規範 考試。
最佳實踐
最佳實踐是指標對某個問題總結出的最佳的`處理方式，可以是程式碼片段、設計模式或框架設計等。每次專案完成之後應該做這樣的總結工作，梳理一下專案的脈絡和技術實現，思考效能最佳化和使用者體驗細節提升的技巧，然後積土成山，並長期維護和更新，構建團隊自己的技術棧。
技術分享
技術分享應該以專題的方式進行，理論上團隊每個成員定期都應該做特定專題的技術分享，並和各自的績效掛鉤。分享方式很簡單，簡報和markdown文件，如果是技術實踐應該還有配套的demo程式碼，最好在小組的週會上進行，鼓勵討論和反駁，一起進步。最後這些分享資料以期刊形式進行整理和出版，構建團隊的技術棧。
開發管理平臺
開發管理平臺主要用於開發過程中的所有流程的把控和個人質量統計。這個平臺應該和需求管理平臺以及程式碼管理平臺聯通，協同使用。
個人缺陷管理
該模組可以反應開發者目前的程式碼質量水平，統計扣分情況。上面說了程式碼缺陷等級分為P0～P5，開發者一旦出現缺陷會被統計在缺陷池裡，並以扣分的形式呈現在這裡。並且扣分排名前30名會上榜，全公司的開發人員都可以看到，互相督促。
開發任務跟蹤
該模組裡會呈現開發人員當前的任務佇列，每個開發任務的生命週期只要沒有走完，都可以申請釋出計劃或取消釋出，任務一旦釋出成功該任務就會從列表裡隱藏。
釋出計劃
開發任務一旦成功生成釋出計劃，會自動從trunk裡產生新的分支，並給出新生成的分支號，然後開發者把程式碼切到該分支，在此分支上進行新的開發。
程式碼評審 codeReview
開發者一旦完成本地開發並自測沒有問題，申請釋出前必須先經過上一級的程式碼評審。程式碼評審包括編碼風格審查，程式碼執行效率、業務邏輯實現的效能等多方面的排查。評審通過了才允許繼續釋出。否則打回上一步，問題修改完成後繼續提交評審。
程式碼釋出
程式碼評審通過後，會進入當天的釋出佇列。
釋出佇列
平臺管理員每天在規定時間把釋出佇列裡的釋出計劃進行預釋出操作，即把分支合併到trunk。
預釋出
程式碼正式釋出前先進入預釋出環境。預釋出環境和正式環境一模一樣，測試人員需要把本地的hosts配置成預釋出的IP地址。然後進行預釋出驗證。驗證如果不透過會被打回，開發人員需要在30分鐘內進行修改，問題解決後管理員會重新合併程式碼，繼續預釋出驗證。超時或無法解決問題，回滾程式碼。該釋出計劃失敗。
正式釋出
預釋出驗證沒問題了，釋出佇列裡的任務會進入正式環境。測試人員需要把本地hosts配置成正式的IP地址。然後進行正式釋出驗證，一般不會再出現問題。
緊急釋出
每天進行釋出的時間是規定的。過了規定的釋出時間如果還需要釋出程式碼的，需要走緊急釋出。緊急釋出每個開發人員都有次數限制，一般如果存在未知風險或涉及核心程式碼的，不允許緊急釋出。
程式碼回滾
如果正式環境出現問題，在規定時間內開發人員無法解決的，必須回滾到上一個版本。
程式碼管理平臺 gitLab、SVN
每個開發團隊都需要一個程式碼管理工具，svn或者git 是目前常用的工具之一。如果使用svn則只需要提供兩臺svn伺服器（正式和預發）。如果使用git則需要搭建gitLab作為程式碼的私有倉庫。
分支管理
開發統一拉分支進行開發，然後合併到trunk。並且trunk上一般開發人員沒有寫的許可權，保護trunk的安全。
版本控制
各分支之間允許合併和回滾，由開發人員自己管理。
團隊管理平臺 team
每個小組應該成立一個team平臺進行管理。在這個平臺上可以檢視隊伍各個成員之間的工作情況（日報、週報、專案進度等）
日報
每日一報，寫一下今天做的日常需求，如果是專案，就寫一下專案的進度。
週報
每週一報。本週工作總結和下週工作計劃。
專案進度
開發管理平臺各自的任務的生命週期應該同步到這裡。方便你的leader進行檢視和工作彙報。
員工管理平臺 oa
這個幾乎每個公司都有，就不介紹了。
規章制度
保密。
人事流程
請假、考勤、打卡、離職、入職等。
場地申請
會議場地、專案室申請。
會議通知
會議開始前會定時通知與會人員。
組織架構
研發團隊是網際網路公司強大的後盾，“養“著一群技術人員。這些人員不僅更具崗位職能進行劃分。還有一個更重要的分法是根據工作性質進行分配。
業務部
負責新業務開發和舊業務的維護。
基礎部
負責開發服務化工具和大資料分析。
系統部
負責系統架構設計和新技術研究。
運維部
負責伺服器管理和維護。
質量保證部
我們的測試工程師同胞們。