在大數(shù)據(jù)時(shí)代，規(guī)范地進(jìn)行數(shù)據(jù)資產(chǎn)管理已成為推動(dòng)互聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能和實(shí)體經(jīng)濟(jì)深度融合的必要條件。貼近業(yè)務(wù)屬性、兼顧研發(fā)各階段要點(diǎn)的研發(fā)規(guī)范，可以切實(shí)提高研發(fā)效率，保障數(shù)據(jù)研發(fā)工作有條不紊地運(yùn)作。而不完善的研發(fā)流程，會(huì)降低研發(fā)效率，增加成本與風(fēng)險(xiǎn)。

數(shù)據(jù)中臺(tái)數(shù)據(jù)開發(fā)規(guī)范旨在為廣大數(shù)據(jù)研發(fā)者、管理者提供規(guī)范化的開研發(fā)流程指導(dǎo)方法，目的是簡化、規(guī)范日常的數(shù)據(jù)中臺(tái)管理和開發(fā)工作，提高工作效率，減少無效與冗余工作，賦能企業(yè)、政府更強(qiáng)大的數(shù)據(jù)掌控力來應(yīng)對(duì)海量增長的業(yè)務(wù)數(shù)據(jù)，從而釋放更多人力與財(cái)力專注于業(yè)務(wù)創(chuàng)新。鑒于對(duì)日常數(shù)據(jù)中臺(tái)開發(fā)工作的總結(jié)與歸納，將數(shù)據(jù)中臺(tái)開發(fā)流程抽象為如下幾點(diǎn)：?

需求階段：數(shù)據(jù)產(chǎn)品經(jīng)理應(yīng)如何應(yīng)對(duì)不斷變化的業(yè)務(wù)需求。 設(shè)計(jì)階段：數(shù)據(jù)產(chǎn)品經(jīng)理、數(shù)據(jù)開發(fā)者應(yīng)如何綜合性能、成本、效率、質(zhì)量等因素，更好地組織與存儲(chǔ)數(shù)據(jù)。?

開發(fā)階段：數(shù)據(jù)研發(fā)者如何高效、規(guī)范地進(jìn)行編碼工作。?

測試階段：測試人員應(yīng)如何準(zhǔn)確地暴露代碼問題與項(xiàng)目風(fēng)險(xiǎn)，提升產(chǎn)出質(zhì)量。?

發(fā)布階段：如何將具備發(fā)布條件的程序平穩(wěn)地發(fā)布到線上穩(wěn)定產(chǎn)出。 運(yùn)維階段：運(yùn)維人員應(yīng)如何保障數(shù)據(jù)產(chǎn)出的時(shí)效性和穩(wěn)定性。?

01具體開發(fā)流程?

需求：與運(yùn)營產(chǎn)品討論需求。業(yè)務(wù)方把需求提交到JIRA，并且和產(chǎn)品溝通過。?

PRD評(píng)審：產(chǎn)品評(píng)審PRD文檔。?

技術(shù)方案討論：最好是負(fù)責(zé)人先溝通一個(gè)初級(jí)的方案，然后找大家一起討論（可能比直接頭腦風(fēng)暴效率搞，根據(jù)負(fù)責(zé)人的經(jīng)驗(yàn)來討論）；然后找大家一起討論。?

技術(shù)設(shè)計(jì)評(píng)審：設(shè)計(jì)評(píng)審叫上測試。?

設(shè)計(jì)評(píng)審的原則：評(píng)審會(huì)議應(yīng)該是設(shè)計(jì)方案大家基本認(rèn)同的前提下，做方案的文檔。?

設(shè)計(jì)接口：重點(diǎn)準(zhǔn)確描述輸入和輸出。 設(shè)計(jì)字段：根據(jù)需求定義字段，并確定字段指標(biāo)和獲取來源，建立數(shù)據(jù)字典。?

開發(fā)：開分支，寫代碼。做好測試case的建立，然后自測。 代碼review：叫上測試和一個(gè)其他開發(fā)同學(xué)，給出review的結(jié)果。目的是讓其他同學(xué)幫忙review其中的邏輯。 提測：給出提測報(bào)告，包括羅列測試點(diǎn)。 上線：提前告知運(yùn)維，提前申請(qǐng)機(jī)器資源，根據(jù)業(yè)務(wù)預(yù)估好CPU、存儲(chǔ)、帶寬等資源。 文檔：開發(fā)完成后，文檔記錄一下流程以及提供數(shù)據(jù)表字段說明，方便重構(gòu)。

02 數(shù)據(jù)需求流程

各個(gè)角色職責(zé)

這個(gè)流程針對(duì)的是項(xiàng)目是開發(fā)，在項(xiàng)目立項(xiàng)的開始，就需要明確各個(gè)角色的職責(zé)，而且需要和多個(gè)角色進(jìn)行配合。作為數(shù)據(jù)開發(fā)人員，需要協(xié)調(diào)和各個(gè)角色之間的交互： 需要和產(chǎn)品評(píng)估該需求的合理性，現(xiàn)有技術(shù)棧能否支持該需求，例如：公司想要做個(gè)實(shí)時(shí)數(shù)據(jù)大盤，如果沒有實(shí)時(shí)數(shù)倉的架構(gòu)，是沒法完成這塊需求。一旦確定開發(fā)，需要協(xié)調(diào)資源，包含開發(fā)資源、設(shè)備資源等等。 需要和業(yè)務(wù)方、產(chǎn)品方評(píng)估數(shù)據(jù)可行性，數(shù)據(jù)開發(fā)的數(shù)據(jù)源并不是憑空出現(xiàn)的，需要和業(yè)務(wù)方明確已有數(shù)據(jù)能否支撐需求開發(fā)，如果缺少數(shù)據(jù)，則需要另行規(guī)劃缺失數(shù)據(jù)的抽取方案。 需要自己評(píng)估技術(shù)可行性，數(shù)據(jù)開發(fā)可能涉及到數(shù)據(jù)傳輸、數(shù)據(jù)同步、ETL、實(shí)時(shí)開發(fā)、離線開發(fā)等等，要評(píng)估從數(shù)據(jù)源獲取到數(shù)據(jù)展現(xiàn)一套流程的可行性，例如：數(shù)據(jù)源如果為多個(gè)地方產(chǎn)出，可能需要從binlong獲取、Kafka讀取、業(yè)務(wù)庫同步、HDFS讀取等等，數(shù)據(jù)輸出也可能到各個(gè)地方，例如：mysql、hive、ES、Kafka、redis等等多個(gè)存儲(chǔ)，需要在開發(fā)之前確定整套數(shù)據(jù)的流程。 需要確定是否滿足安全與合規(guī)要求，對(duì)于一些敏感數(shù)據(jù)如何處理，是一個(gè)很重要的組成部分，作為數(shù)據(jù)開發(fā)人員，可能接觸的數(shù)據(jù)比較多，但是哪些數(shù)據(jù)可以展現(xiàn)、哪些數(shù)據(jù)脫敏后可以展現(xiàn)、哪些數(shù)據(jù)不能落地等等，而且在數(shù)據(jù)流轉(zhuǎn)過程中，也要關(guān)注數(shù)據(jù)的安全性，能否落地、能否轉(zhuǎn)存等等。

需要和測試同學(xué)同步數(shù)據(jù)處理邏輯，并將一些邏輯的SQL進(jìn)行文檔化，方便測試同學(xué)進(jìn)行單元測試，在交付測試之前，需要對(duì)代碼進(jìn)行自測，以便保障流入到測試執(zhí)行環(huán)節(jié)的代碼達(dá)到一定的質(zhì)量標(biāo)準(zhǔn)。同時(shí)最好能讓代碼通過配置在不同環(huán)境進(jìn)行切換，方便測試同學(xué)在測試環(huán)境、預(yù)發(fā)環(huán)境進(jìn)行測試，測試通過后同一套代碼能夠直接上線。

除了項(xiàng)目式的開發(fā)外，數(shù)據(jù)開發(fā)人員大部分情況下都會(huì)面對(duì)產(chǎn)品提出來的一些臨時(shí)性的數(shù)據(jù)需求，例如拉去一下近半年的銷售情況、用戶訪問情況等等，這部分?jǐn)?shù)據(jù)支撐不需要后端配合、可能也不需要進(jìn)行測試，而是在已明確的數(shù)據(jù)指標(biāo)的基礎(chǔ)上，定期或者不定期的提供一個(gè)數(shù)據(jù)報(bào)表。這部分的數(shù)據(jù)開發(fā)模式相對(duì)來說比較簡單和快速，但是也需要明確：明確數(shù)據(jù)需求模板、常規(guī)需求申請(qǐng)單等等，提供需求單的目的是避免長時(shí)間的溝通，特別是已經(jīng)有的數(shù)據(jù)指標(biāo)，只需要讓產(chǎn)品提供一份詳細(xì)的數(shù)據(jù)需求單，按照需求單的模版進(jìn)行提供數(shù)據(jù)即可。模版如下：

指標(biāo)需求中通常會(huì)涉及到下表中的約定項(xiàng)，如果需要自定義約定項(xiàng)，可以在自定義格式列進(jìn)行填寫。

明確需求的指標(biāo)含義，和所需求的字段明細(xì)、統(tǒng)計(jì)周期、開發(fā)周期等。

?

需求評(píng)審?fù)瓿珊螅绻l(fā)生需求變更或者迭代，一定需要提供迭代/變更的需求申請(qǐng)單，或者提供JIRA，避免需求不可追溯。 ?

對(duì)于一些重要指標(biāo)的定義，就算文檔中寫了，也要和產(chǎn)品進(jìn)行確定，例如產(chǎn)品需要近半年的所有銷量，那么要明確這個(gè)銷量是否包含退款、是按照成交時(shí)間還是付款時(shí)間來計(jì)算等等。避免數(shù)據(jù)指標(biāo)不匹配，導(dǎo)致二次開發(fā)。 開發(fā)過程中，文檔要規(guī)范，先設(shè)計(jì)在開發(fā)，而且在做系統(tǒng)建設(shè)的時(shí)候，要有全局視野，不局限某一個(gè)點(diǎn)，并不是發(fā)布完成了，就算結(jié)束，代碼開發(fā)完成只是第一步，后續(xù)的文檔建設(shè)、代碼復(fù)盤、數(shù)據(jù)監(jiān)控、數(shù)據(jù)告警、穩(wěn)定性等等，都需要在開始規(guī)劃好。?

及時(shí)反饋，在開發(fā)過程，不論進(jìn)行到哪個(gè)階段，項(xiàng)目期間每天都需要和前后端同步一下進(jìn)度，避免延期的風(fēng)險(xiǎn)。 故障處理，在程序上下后，可能會(huì)因?yàn)榭陀^或者代碼的原因出現(xiàn)一些BUG，不同的故障處理方案不同，但是注意復(fù)盤和故障記錄，避免下次出現(xiàn)相同的BUG。 故障等級(jí)定義：P0?：1.全局問題，影響所有用戶，例如系統(tǒng)必現(xiàn)崩潰，主要功能不可用，嚴(yán)重影響用戶正常交易。

2.涉及到用戶資金損失的問題。解決時(shí)間：2小時(shí)內(nèi)。

反饋時(shí)間：0.5小時(shí)。反饋方式：comments自動(dòng)郵件方式+即時(shí)通信：例如QQ\微信\釘釘\電話 P1：1.全局問題，影響所有用戶，例如系統(tǒng)次要功能不可用，系統(tǒng)偶現(xiàn)崩潰且崩潰率超過50%。

2.局部問題，影響超過20%的用戶，例如系統(tǒng)主要功能不可用，系統(tǒng)必現(xiàn)崩潰。解決時(shí)間：待定不過夜。

反饋時(shí)間：1小時(shí)。反饋方式：comments自動(dòng)郵件方式+即時(shí)通信：例如QQ\微信\釘釘\電話 P2：1.局部問題，影響用戶10%-20%，例如系統(tǒng)次要功能不可用，或者系統(tǒng)某一個(gè)邏輯不可用，系統(tǒng)崩潰率20-50%。

解決時(shí)間：待定48小時(shí)。反饋方式：comments自動(dòng)郵件方式。 P3：1.局部問題，影響用戶10%以下，例如系統(tǒng)次要功能不可用，系統(tǒng)部分邏輯不正常，僅在某一單一機(jī)型或單一用戶出現(xiàn)的問題。解決時(shí)間：待定下個(gè)版本發(fā)布。

反饋方式：下個(gè)版本的需求計(jì)劃中體現(xiàn)。 P4：1.系統(tǒng)文本錯(cuò)誤，系統(tǒng)樣式錯(cuò)誤，系統(tǒng)交互友好性等不影響用戶正常使用的功能。（包含全局性質(zhì)）

解決時(shí)間：下個(gè)版本上線時(shí)。

反饋方式：下個(gè)版本的需求計(jì)劃中體現(xiàn)。 注意：P0\P1級(jí)別問題在規(guī)定時(shí)間內(nèi)無法解決的，需要該問題的研發(fā)同學(xué)在問題comments內(nèi)說明無法在規(guī)定時(shí)間內(nèi)解決的合理的解釋，并告知該問題具體的解決時(shí)間點(diǎn)同時(shí)郵件說明。歡迎交流探討。