研發管理 - 流程篇
研發管理-流程篇
標籤： 專案管理 研發管理
情況介紹
2011年-2014年主要致力於國內某大型企業財務公司資金結算系統，系統主要業務包括對公、對私、代理資金劃轉交易，交易金額少則幾萬多則億元，不容閃失。值得驕傲的是在我擔任專案經理期間沒有出現一筆問題，回想那段時間我個人壓力巨大，每天琢磨系統哪兒容易出現問題，如何防範，出現問題如何補償。帶領團隊完成系統監控研發上線，確保問題交易提早發現通知銀行協同解決。
2015至-2018年初主要負責某e寶研發工作，主要分為兩個階段，第一階段，2015年-2016年底主要負責APP研發，帶領團隊完成某寶APP v1-v3版本研發上線。2017年-2018年主要負責某寶全部系統的研發管理，包括前端APP和後端核心系統，在這期間帶領兄弟們夜以繼日工作，完成一項一項艱鉅任務。每想到此，心中尤為感概，特別感謝曾經一起共事的兄弟們，道一聲“感謝 & 珍重”。
2018年，總部新成立****事業部，讓我負責研發管理工作，由於涉及到電費相關，系統出現異常容易造成企業使用者損失，為降低系統風險，確保流程規範順暢，制定一份切實可行專案研發管理，爭取2019年做到系統零事故。
專案研發管理
專案管理階段
研發專案主要從產品需求作為入口，線上驗證作為結束，主要分為:
需求評審
專案設計
專案研發
專案測試
專案上線
線上驗證
六個階段分別闡述每個階段的主要工作職責和內容。
需求評審
需求評審主要評審什麼？一直以來我們對需求的評審不夠嚴格或者僅僅是過了一遍需求，讓大家都知道有這個需求需要研發上線，缺乏對業務、系統整體風險的揭示，業務評審主要考慮從業務、技術兩個層面規避風險和處理風險。我要求團隊對需求的評審主做到如下四點：
- 分析新上產品（需求）對現有產品是否存在衝擊風險
- 分析新上產品（需求）自身的業務風險，如果出現系統風險，業務層面是否有解決辦法
- 分析新上產品（需求）業務流程是否邏輯清晰，業務是否考慮後續產品擴容
- 分析新上產品的接入方（銀行、內部系統、其他廠商）的產品和我們產品的融合能力和技術實現
專案設計
技術經理或研發組長在需求評審結束後開展專案設計工作，如果做好如下的三條應可以滿足我們當前的研發要求，太多的要求擔心時間的損耗大還未必能夠達到好的效果，本著實用好用的原則做好如下三條。
-
資料庫架構設計（表名，欄位名命名規範、充分思考業務發展，滿足業務擴充套件、查詢多變更少的採用快取資料庫（redis+oracle）結合使用，基礎欄位必須包含如：操作使用者編碼、建立時間，可以適當的冗餘欄位方便管理平臺的統計分析和查詢工作）
-
應用架構設計（應用架構圖，描述系統應用關係，描述不同系統間的職責範圍（銀行、財務公司、內部系統、其他外部系統）、設計測試環境和正式環境的虛擬機器數量、說明相關網路許可權的申請和開通）
-
安全架構設計（資料脫敏、資料加密、網路安全（專線、https、證書）、使用者許可權、Xss、SQL注入等基本安全防範）
重點：設計必須評審，這個是我必須要過的一道程式。
專案研發
專案研發需要經過九大步驟，主要包括：
- 分支建立
- 工作分配
- 環境申請（測試）
- 程式碼編寫
- 程式碼審查
- 程式碼合併
- 整合測試
- 環境申請（正式）
- 測試提交
分支建立
研發經理根據專案需求、應用架構設計、《git管理辦法》做出專案分支（future_branch）建立工作。
工作分配
研發經理建立好分支後，在分支下將包建立好後，將分支許可權分配和具體研發人員。
環境申請（測試）
申請虛擬機器、開通對外網路、內部網路、申請redis、memcached的key。
程式碼編寫
程式碼編寫必須做到如下規範日誌輸出、規範註釋編寫、規範命名規範（應用、包、類、方法、欄位）、規範單元測試、規範異常處理、規範快取使用、規範SQL、規範使用通用類、規範任務處理呼叫、關鍵程式邏輯處理、QAPlug程式碼檢查。
程式碼審查
- 為什麼程式碼審查在合併之前？
研發經理層面：1）審查程式碼實現是否符當初的設計。2）投提前瞭解合併可能存在衝突。
研發工程師層面：1）團隊其他成員通過審查，能夠理清（加強理解）隊友程式碼實現和自己程式碼的邏輯關係。2）通過程式碼審查，瞭解技術實現儘早實現技術層面提升。- 程式碼審查的成員
程式碼審查包括所屬專案組所有成員- 程式碼審查的內容
日誌輸出、註釋使用、命名規範（應用、包、類、方法、欄位）、單元測試情況、異常捕獲、許可權處理、事務處理、快取使用、資料庫使用、SQL編寫、程式碼邏輯、通用類使用情況、任務處理、關鍵程式處理。
程式碼合併
程式碼合併的工作必須由研發經理執行，研發經理解決合併的程式碼問題。合併完成後使用程式碼檢測工具（Sonar）開展程式碼檢查工作。
整合測試
完成業務基本測試和效能測試。將研發的包放入整合測試環境（暫時正在搭建），主要測試核心邏輯、外部系統呼叫、內部系統呼叫、資料量千萬級、資料量億級處理時長，考慮業務量大的情況效能和基本功能測試。
環境申請（正式）
申請正式環境的虛擬機器、開通正式的網路、可提前部署相關的硬體或者軟體（如：銀行前置機）。
測試提交
準備發版文件，將發版文件提交給測試，測試按照發版文件部署配置（jenkins、 git）服務。
後續將測試環境當做生產，確保提交給測試的環境配置無錯誤。
專案測試
用例編寫
測試用例編寫開始於需求評審完成後，包括覆蓋基礎功能、本次上線功能、環境變化調整功能。
用例評審
測試用例評審，包括必須複測的基礎功能，包括本次上線功能的完整性，包括因程式碼、環境調整等因素需要測試和恢復測試用例。測試用例的評審包括開發（最低2人）+測試本專案組全體成員。
分配工作
測試工作的分配，通過專案計劃將模組分配給相關的測試測試人員，（考慮交叉測試，希望明年能夠實現，交叉測試需要人員較多，成本較高）。
系統測試
系統主要測試三輪：
- 第一輪主要是業務流程跑通測試，目前由於測試環境和研發環境較大差異（配置、資料、外部環境）所以第一次的測試以跑通為主；
- 第二輪測試主要包括業務實現邏輯及細節測試，包括日誌輸出、相關係統處理時間、業務資料、異常資料測試等。
- 第三輪主要是迴歸測試，出具測試報告，提出因測試條件缺失的風險，讓業務人員簽字確認風險。出具程式碼研發質量報告，根據程式碼行數和bug的比率、相似功能bug比率提出研發質量報告。
產品上線
發版準備
- 做發版計劃，環境準備提前一週，發版計劃提前3天。
- 準備發版的工作票，封版前完成。
- 做好發版材料的審查
發版跟蹤
- 發版當天安排技術經理值班。
- 跟蹤運維繫統啟動情況、日誌輸出情況（檢查kibana日誌查詢）、系統的初步驗證
線上驗證
線上驗證
我們的產品主要TO-B，線上的驗證難度大，所以19年我們需要實現灰度+白名單客戶幫助業務便於線上業務驗證。
《以上是我研發管理經驗分享，目前整個部門都在推行。感謝您閱讀到此，希望您多多指正。》