“提需求的”與“拉SQL的”如何有效溝通
這個(gè)題目筆者改了又改,最終還是感覺這樣寫更具有可讀性,畢竟一篇文章最終還是以能夠讀懂為初衷的,現(xiàn)階段,各個(gè)公司里科技開發(fā)、數(shù)據(jù)編制成為必不可少的崗位,技術(shù)和業(yè)務(wù)的溝通也日益頻繁。于是,一對(duì)相愛相殺的歡喜冤家見面了~
作為一個(gè)非資深但工作有幾年的程序員,工作中聽到最多的,可能就是需求溝通了。業(yè)務(wù)有了一個(gè)新的方案,技術(shù)合作落地,原本珠聯(lián)璧合的伙伴,卻因?yàn)樗莆罩R(shí)儲(chǔ)備不同導(dǎo)致難以溝通。
寫這篇文章之前,筆者也溝通了一些小伙伴,聊一聊溝通中遇到的那些問題,結(jié)果,話題一打開,苦水便隨口而來了,筆者做了一些簡單的總結(jié):
一個(gè)做了多年技術(shù)的程序員小哥哥是這么說的:
- 一個(gè)詞我說的是這個(gè)意思,他理解的是另外一個(gè)意思;
- 技術(shù)思維和業(yè)務(wù)思維不一樣,實(shí)現(xiàn)上技術(shù)懂得多,業(yè)務(wù)不明白怎么實(shí)現(xiàn),講半天也還是不懂;
- 業(yè)務(wù)非要實(shí)現(xiàn)本來沒有必要的功能,而這個(gè)功能在開發(fā)看來可以替代,而且耗時(shí)很長,不愿意開發(fā);
- 業(yè)務(wù)在理解需求的時(shí)候不能確定,導(dǎo)致隨時(shí)變更需求,引起重復(fù)勞動(dòng)。
從程序員的角度看,這似乎滿是道理,但是在業(yè)務(wù)眼里,卻又是另外一番天地了,我們來聽一下業(yè)務(wù)的心聲:
- 我不是做技術(shù)的,怎么實(shí)現(xiàn)不是我的職責(zé)范圍了吧;
- 說我理解不清楚需求,我認(rèn)為不合適,畢竟如果看不到數(shù)據(jù),我也不知道對(duì)錯(cuò)對(duì)吧,看到結(jié)果我才能調(diào)整啊;
- 有些數(shù)據(jù)我一眼就看出偏差,程序員卻發(fā)現(xiàn)不了,提供了一個(gè)差異在100倍的數(shù)據(jù);
- 有一個(gè)可能實(shí)現(xiàn)不了的想法:就是我希望程序員能了解我的取數(shù)目的,一起討論怎么完成更合理;
- 和技術(shù)之間有明顯的gap,我以為很簡單的東西,沒想到實(shí)現(xiàn)起來卻如此復(fù)雜;
兩邊各執(zhí)一詞,于是,溝通成本出現(xiàn)了,一個(gè)簡單的需求溝通半天,最后還是免不了反復(fù)調(diào)整的命運(yùn)。
筆者認(rèn)為,如果結(jié)合業(yè)務(wù)和技術(shù)的角色定位,或許就可以理解一二了。
對(duì)于運(yùn)營和營銷來講,最重要的是如何提高月活?如果獲取利潤?至于怎么證明月活?怎么證明利潤?卻不是第一位的職責(zé)。
對(duì)于技術(shù)而言,最重要的是如何實(shí)現(xiàn)功能?如何提高性能?至于實(shí)現(xiàn)什么樣的功能?卻是需求說了算的。
一時(shí)溝通起來,像是不同語言在交流,兩頭霧水~
一位不愿意透露姓名的資深人士講到:需求溝通的問題,要么是缺少職能,要么是缺少能力。著眼這兩方面,gap也就產(chǎn)生了。
對(duì)于這一問題,筆者請(qǐng)教了一些能夠在技術(shù)和業(yè)務(wù)間順暢溝通的人士,總結(jié)了一些需求溝通的小技巧,只是提出一些數(shù)據(jù)需求的思考方法,未必能覆蓋所有的場(chǎng)景,供大家參考,希望有些許幫助。
一、需求包含背景
對(duì)于數(shù)據(jù)需求而言,需求背景的描述是非常重要的,一方面能協(xié)助自己理清楚提數(shù)的思路,另一方面也可以讓那個(gè)“拉SQL的”快速的了解到有哪些字段能夠匹配當(dāng)下的需求;
此處筆者想描述一下程序員接到需求時(shí)的一個(gè)心理反應(yīng),或許未必準(zhǔn)確,權(quán)當(dāng)是拋磚引玉吧,歡迎大家分享提需求和接需求時(shí)的心理邏輯:
遇到一個(gè)需求,程序員心理往往是:
- 他在講什么?
- 他講的東西在哪張表里?
- 這些表里的字段口徑是否一致?
所以,遇到一個(gè)反應(yīng)緩慢的程序員,請(qǐng)見諒,畢竟,他想的挺多的~
我們用一個(gè)案例來分析需求的背景問題吧:
“我們前兩周針對(duì)持續(xù)三十天未登錄口袋的客戶做了一場(chǎng)促活的活動(dòng),想了解一下這兩周時(shí)間里用戶新增有多少?”
在筆者看來,這應(yīng)該是一個(gè)比較全面的需求了,我們來具體分析一下:
(1)需求背景是“前兩周做了一場(chǎng)促活的活動(dòng)”。
鎖定了時(shí)間指標(biāo)和統(tǒng)計(jì)的功能范圍,這樣的背景描述可以協(xié)助程序員了解這次需求的全貌,也只有在這樣的基礎(chǔ)上,一些有思想的程序員才能夠提出一些建設(shè)性的意見,也有助于了解這場(chǎng)促活活動(dòng)的全貌。
(2)需求客群是“持續(xù)三十天未登錄口袋的客戶”。
客群是數(shù)據(jù)統(tǒng)計(jì)、數(shù)據(jù)分析過程中非常重要的一方面,不同的客群針對(duì)同一指標(biāo)可能會(huì)有天壤之別,比如統(tǒng)計(jì)客戶的投資興趣時(shí)如果圈出的客群是“資產(chǎn)為零的客戶”和“五百萬以上資產(chǎn)的客戶”,統(tǒng)計(jì)出來的結(jié)論一定是不一致的,除非需求就是要看一下他們有多么不一致,就另當(dāng)別論了。
(3)統(tǒng)計(jì)指標(biāo)是“兩周時(shí)間里用戶新增有多少”。
需求的目的就是要了解一些指標(biāo),那么,提需求時(shí)最重要的當(dāng)然也就是說清楚這些指標(biāo)是什么了,統(tǒng)計(jì)時(shí)間是“兩周”,統(tǒng)計(jì)指標(biāo)是“用戶新增”,基本上可以判斷是計(jì)算UV了,至于什么樣的字段來計(jì)算UV,估計(jì)程序員會(huì)非常主動(dòng)的去溝通了。
總結(jié)一下的話,一個(gè)較為合理的需求往往需要解決一句話:我們?cè)谑裁磿r(shí)間,針對(duì)什么人,做了一件什么事情,需要了解什么指標(biāo)?
當(dāng)然,我們?cè)谔幚硇枨髸r(shí)未必如上文一樣簡單,本文也是想給大家提供一些思路而已,讓大家在分析需求時(shí)能夠有的放矢,歡迎大家溝通。
二、梳理需求邏輯
另一個(gè)需要大家關(guān)注的點(diǎn)就在于邏輯,筆者在接需求的時(shí)候經(jīng)常會(huì)遇到一些邏輯較為復(fù)雜的需求。
比如:“我想統(tǒng)計(jì)一下看得見頂部XX按鈕的客戶,對(duì)理財(cái)、轉(zhuǎn)賬等多個(gè)常規(guī)tab的點(diǎn)擊和瀏覽情況,而后計(jì)算近兩周點(diǎn)擊過理財(cái)、轉(zhuǎn)賬等多個(gè)常規(guī)tab的人在8月份每天對(duì)相應(yīng)tab的訪問PV和UV,最后按照各tab分組呈現(xiàn)?!毙枨蟊磉_(dá)也可以做一下相應(yīng)的調(diào)整:
“統(tǒng)計(jì)人群:客戶號(hào)為偶數(shù)的人群。
統(tǒng)計(jì)指標(biāo):
- 看得見頂部XX按鈕的客戶,對(duì)理財(cái)、轉(zhuǎn)賬等多個(gè)常規(guī)tab的點(diǎn)擊和瀏覽;
- 計(jì)算近兩周點(diǎn)擊過理財(cái)、轉(zhuǎn)賬等多個(gè)常規(guī)tab的人在8月份每天對(duì)相應(yīng)tab的訪問PV和UV;”
這樣的表達(dá)怎么樣呢?
這是一個(gè)相對(duì)復(fù)雜的需求,他不僅多次圈定人群,還存在多次計(jì)算以及運(yùn)算場(chǎng)景的轉(zhuǎn)換(一個(gè)是計(jì)算每天的點(diǎn)擊情況,另一個(gè)是計(jì)算不同時(shí)間段的點(diǎn)擊值并比較)。
如果是一些較為簡單的需求,上面的描述幾乎可以說是完美了,一個(gè)偏向業(yè)務(wù),描述了需求邏輯,一個(gè)偏向于技術(shù),也描述了數(shù)據(jù)邏輯,足以看出“提需求的”人的功底,但是如果是較為復(fù)雜的需求呢?
我們?cè)囅胍幌拢绻麥贤ㄟ^程中僅僅告訴程序員上面一句話,程序員最大可能會(huì)“根據(jù)這一句話”+“自己對(duì)這一需求目的的理解”整理出SQL語句,如此取出的數(shù)據(jù)準(zhǔn)確性是很難保證的;
“俗話”說的好:在看到數(shù)據(jù)表之前“拉SQL的”都不知道該怎么寫語句合適,更何況不經(jīng)常接觸表的人呢。
我們可以將上面的需求做一下調(diào)整:
統(tǒng)計(jì)背景:
我們正在做一個(gè)對(duì)比實(shí)驗(yàn),客戶號(hào)為偶數(shù)的人群能夠看到頂部XX按鈕,客戶號(hào)為奇數(shù)的客戶看不到,看得到頂部XX按鈕的客戶轉(zhuǎn)賬、理財(cái)?shù)瘸R妕ab顯示在首頁最高位置,想了解一下頂部XX按鈕對(duì)客戶行為的影響。
統(tǒng)計(jì)思路:
- 統(tǒng)計(jì)看得見頂部XX按鈕的客戶,對(duì)理財(cái)、轉(zhuǎn)賬等多個(gè)常規(guī)tab的點(diǎn)擊和瀏覽情況,目的是了解一下客戶在新環(huán)境下主要點(diǎn)擊哪些按鈕;
- 結(jié)合歷史數(shù)據(jù)做對(duì)比,統(tǒng)計(jì)一下實(shí)驗(yàn)之前看不見頂部XX按鈕的客戶對(duì)理財(cái)、轉(zhuǎn)賬等多個(gè)常規(guī)tab的點(diǎn)擊與實(shí)驗(yàn)之后的點(diǎn)擊差異,即:計(jì)算近兩周點(diǎn)擊過常規(guī)tab的人在8月份每天對(duì)常規(guī)tab的訪問PV和UV,最后按照常規(guī)tab分組呈現(xiàn)。這樣調(diào)整是不是可以清楚一點(diǎn)呢?
“背景”+“目的”+“統(tǒng)計(jì)思路”
一個(gè)較為清晰的數(shù)據(jù)方案就會(huì)在“提需求的”和“拉SQL的”人頭腦中形成,中間的一些細(xì)節(jié)問題才能較為順暢的溝通,程序員也可發(fā)揮自己的主觀能動(dòng)性提一些思路,而不是簡單的做個(gè)取數(shù)的人。
需求背景和目的的重要性就躍然于紙上了~
另外,還有一個(gè)需要注意的小細(xì)節(jié),就是:需求落在紙上,我想大家都很難想象上面的需求通過電話或者聊天就能清晰的讓人理解吧?
需求落在紙上的兩個(gè)好處主要是:
- 協(xié)助“提需求的”整理思路,編輯需求的過程實(shí)際上也是整理思路的過程,能寫出來的需求基本上就能解決一半了;
- 協(xié)助“拉SQL的”翻譯邏輯和理解需求,上面的需求全程語言溝通估計(jì)會(huì)事倍功半吧。
三、常用的模型聊口徑
上面的兩個(gè)思路基本上可以解決大部分需求了,不過很多讀者可能會(huì)疑惑了:“大佬,上面是散打吧?有沒有套餐啊,也方便我們系統(tǒng)的了解提需求的思路?”
系統(tǒng)提需求的思路其實(shí)有很多的,大多是工作中的真大佬溝通過程中總結(jié)出的經(jīng)驗(yàn)教訓(xùn),下面我們來介紹兩個(gè)比較常用的:
1. 5W2H模型整理思路
這個(gè)模型可以協(xié)助提需求的人在整理需求時(shí)有思路可尋,提出的需求能有一個(gè)完整的思維邏輯,而不是漫天撒花,當(dāng)然了,很多人可能看到這個(gè)模型瞬間原地爆炸,“我就提個(gè)需求而已,這模型這么多元素,豈不麻煩,增加工作成本”,其實(shí)我想說的是兩點(diǎn):
- 增加的是學(xué)習(xí)成本,但是減少的是溝通成本,整體核算下來,利大于弊;
- 針對(duì)不同的需求,可以選擇部分元素,未必一定照本宣科;
但凡提煉成文字的解決思路,大多不是按部就班的,研究一下模型的思路,找合適的部分融合到自己的需求里面,或許,你提出的一句話需求也可以讓程序員秒懂。
我們來具體介紹一下:
- WHAT(什么需求):即統(tǒng)計(jì)什么指標(biāo),需求的主題部分,講清楚要什么,例如:“需要PV還是UV,還是轉(zhuǎn)化率”等;
- WHY(何因):需求的背景和目的,為什么要統(tǒng)計(jì)這些指標(biāo),例如:“在做AB測(cè)試,需要查看一下AB兩個(gè)方案的差異”;
- WHEN(何時(shí)):需求的時(shí)間要求,即統(tǒng)計(jì)什么時(shí)間段?統(tǒng)計(jì)的時(shí)間頻率是多少?每月?每天?還是每周?。
- WHERE(何地):需求的位置要求,即統(tǒng)計(jì)哪些頁面?或者頁面上哪些tab,協(xié)助程序員定位分析的流程和統(tǒng)計(jì)的目標(biāo)。
- WHO(什么客戶):需求統(tǒng)計(jì)的是哪些客戶,這個(gè)是非常重要的一個(gè)指標(biāo),即客群定位,客群清晰是分析的基礎(chǔ),否則容易南轅北轍,試想一下,如果我們?cè)谇嗌倌曛薪y(tǒng)計(jì)貸款情況,估計(jì)很難得到好的效果。
- HOW(怎么做):需求的邏輯要求,這一元素可以將前面的幾點(diǎn)串聯(lián)起來,告訴程序員具體要怎么分析數(shù)據(jù),例如:計(jì)算“近兩周點(diǎn)擊過底部其他tab的人在8月份每天對(duì)底部tab的訪問PV和UV”。
- HOW MUCH(開發(fā)成本):預(yù)計(jì)花多少時(shí)間,提需求的人對(duì)開發(fā)周期是會(huì)有一個(gè)預(yù)估的,統(tǒng)計(jì)一個(gè)指標(biāo)搞一個(gè)月和統(tǒng)計(jì)十幾個(gè)指標(biāo)搞兩天都是不合理的,可以根據(jù)需求的大小與程序員做相應(yīng)的溝通。正如前面所說,模型是固定的,但需求是靈活的,上面的模型也僅僅是為大家思考需求提出了一個(gè)思路,讓大家能夠有跡可循,平時(shí)工作中用到哪些指標(biāo)還需要具體需求具體分析的~
2. 口徑顆粒度對(duì)齊字段邏輯
顆粒度是針對(duì)統(tǒng)計(jì)的字段而言的,主要是查看統(tǒng)計(jì)的字段之間口徑是否一致,是否會(huì)有錯(cuò)位等,我相信這一問題幾乎困擾了大半的“提需求的”和“拉SQL的”,都曾為口徑聊得口干舌燥;
筆者介紹一個(gè)較為常用的方法——“流程圖分層”。即將不同層級(jí)的字段從上到下串起來,思路是否會(huì)清晰好多。
我們可以先看一個(gè)案例:新活動(dòng)上線數(shù)據(jù)統(tǒng)計(jì):
統(tǒng)計(jì)口徑為:
統(tǒng)計(jì)背景是開展行員推送新活動(dòng)給500萬資產(chǎn)的客戶,以促進(jìn)客戶新增和活躍。
統(tǒng)計(jì)目的是為了查看行員每次推送是否達(dá)到了預(yù)期的價(jià)值。
我們可以把上面的需求做一些分解,整理出需求中顆粒度由粗到細(xì)的流程圖:
(1)行員推送活動(dòng)的流程:
這一流程可以統(tǒng)計(jì)出行員推送多少活動(dòng)給到客戶,從推送級(jí)別定位口徑,行員和活動(dòng)之間是多對(duì)多的關(guān)系,即:每個(gè)行員推送多個(gè)活動(dòng)給到客戶,每個(gè)活動(dòng)也會(huì)被多個(gè)行員推送。
(2)客戶接收活動(dòng)信息的流程:
這一流程可以顯示出多少客戶訪問和轉(zhuǎn)發(fā)了活動(dòng),從訪問級(jí)別定位口徑,直接訪問即從行員處直接獲取到的活動(dòng)信息,間接訪問即從客戶轉(zhuǎn)載中獲取到的訪問信息,兩次訪問單獨(dú)計(jì)算,又是一個(gè)多對(duì)多的關(guān)系,整個(gè)邏輯還是有一定復(fù)雜度的。
(3)活動(dòng)引發(fā)訂單的流程:
AUM是一個(gè)比較難處理的流程,首先AUM訂單是從活動(dòng)級(jí)別的口徑,分析整個(gè)分享活動(dòng)帶來的所有AUM訂單,其次AUM余額又是客戶級(jí)別的口徑,分析客戶最新的AUM余額是多少,原則上是多對(duì)多和一對(duì)一的關(guān)系。
四、驗(yàn)證結(jié)果很重要
在程序員的眼里,或許只有“NULL”、“空值”、“亂碼”才會(huì)意識(shí)為錯(cuò)誤數(shù)據(jù),這些基本上都是技術(shù)性報(bào)錯(cuò)。而在業(yè)務(wù)眼里,結(jié)合自己的業(yè)務(wù)邏輯不同范圍的數(shù)據(jù)也是明顯的報(bào)錯(cuò)。
比如:統(tǒng)計(jì)百分比的數(shù)據(jù)得到的是1.01,整理年齡字段時(shí)發(fā)現(xiàn)有200歲,這些算是比較明顯的錯(cuò)誤,或許程序員也可以發(fā)現(xiàn),那么,再細(xì)致一點(diǎn)呢?
比如,推廣一個(gè)活動(dòng)查看PV值是100000,UV值是1000;客戶登錄銀行設(shè)備平均數(shù)是100,這些是否就這么明顯呢?
我想就未必了吧,所以,在驗(yàn)數(shù)階段,最好的方式是“提需求的”與“拉SQL的”相互溝通驗(yàn)數(shù)標(biāo)準(zhǔn):“提需求的”告訴“拉SQL的”因?yàn)槭裁磩h除了哪些技術(shù)上錯(cuò)誤的字段?“拉SQL的”告訴“提需求的”在什么范圍內(nèi)的數(shù)據(jù)是合理的?
經(jīng)過反復(fù)的溝通,才能得出一個(gè)相對(duì)合理的數(shù)據(jù)分析結(jié)果。
總結(jié)
上面說了這么多,我們做一下總結(jié)吧~相愛相殺的小冤家們,我們開始畫重點(diǎn)了:
- 我們?cè)谑裁磿r(shí)間,針對(duì)什么人,做了一件什么事情,需要了解什么指標(biāo)?
- “背景”+“目的”+“統(tǒng)計(jì)思路”;
- ?需求落在紙上;
- 5W2H模型可以協(xié)助提需求的人整理需求思路;
- “流程圖分層”協(xié)助對(duì)齊數(shù)據(jù)口徑;
- “提需求的”與“拉SQL的”相互溝通驗(yàn)數(shù)標(biāo)準(zhǔn)。
通過流程圖來整理思路可以協(xié)助大家在溝通需求時(shí)保證口徑的準(zhǔn)確性和一致性,可視化的手段解決邏輯溝通的問題,減少了提需求和拉SQL的人的溝通障礙,畢竟流程是大家都熟悉的東西。
文章寫到這里就告一段落了,主要是對(duì)常見的一些需求溝通問題做了總結(jié),未必適合所有的需求,但可以覆蓋一部分溝通,筆者也會(huì)持續(xù)總結(jié),希望能找到更簡單的溝通方式,搭建“提需求的”與“拉SQL的”之間的鵲橋。還是那句話:歡迎大家溝通~
作者:livandata;個(gè)人公眾號(hào):livandata,歡迎大家關(guān)注溝通~
本文由 @livandata 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
- 目前還沒評(píng)論,等你發(fā)揮!