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