關(guān)于Jeff：傳統(tǒng)保險(xiǎn)行業(yè)電子商務(wù)需求分析師，原ERP咨詢顧問。得益于其在ERP行業(yè)的工作經(jīng)驗(yàn)，其對(duì)需求引導(dǎo)、企業(yè)流程梳理有著較為獨(dú)到的認(rèn)識(shí)，也致力于在需求分析領(lǐng)域進(jìn)一步深耕。
十年的工作經(jīng)驗(yàn)，可以是用同樣的方法將工作重復(fù)十遍，也可以是在每一次工作中有不同的收獲。其中的區(qū)別就在于——是否有不斷的思考和總結(jié)。
Jeff的需求分析札記，素材都取自于Jeff的真實(shí)工作經(jīng)歷。每一篇總結(jié)包含了：一個(gè)需求的故事，以及Jeff的復(fù)盤。Jeff希望通過對(duì)工作細(xì)節(jié)的整理，幫助自己更清晰的認(rèn)識(shí)需求分析。并且在分享的同時(shí)，Jeff也期待得到志同道合者的反饋。
8月21日上午10:30 @辦公室
“終于搞定了！”小J在座位上舒舒服服的伸了個(gè)懶腰。
昨天一下午需求通過了業(yè)務(wù)部門評(píng)審。今天上午又對(duì)幾個(gè)細(xì)節(jié)做了調(diào)整，需求文檔就算是完成了。
又花費(fèi)了5分鐘，小J從上頭到尾又瀏覽了一遍文檔。說心里話，他對(duì)文檔的質(zhì)量還是頗為滿意的。
他知道，需求文檔必須層次段落清楚。并且為了便于閱讀和理解，語言組織要盡可能精簡，同時(shí)，最好是使用小段落來展現(xiàn)對(duì)功能點(diǎn)的描述。
如果就拿上面這個(gè)段落就是需求文檔都一個(gè)章節(jié)，如果修改成更容易理解的形式，應(yīng)該是這樣的：
更清晰表達(dá)的注意事項(xiàng)：
- 層次段落清楚
- 語言精簡
- 使用小段落
需求文檔的最終目的是讓寫代碼的兄弟看明白。應(yīng)該讓他們的腦力更多的用于代碼的架構(gòu)，而不是理解需求上……
想著想著，小J不經(jīng)又欣賞了一遍自己的“作品”……
8月25日上午9:20 @辦公室
“叮鈴鈴”
“喂”
“小J，和你確認(rèn)一個(gè)需求?！彪娫捘且活^傳來R的聲音。
R是項(xiàng)目組的測試，項(xiàng)目繁重的測試任務(wù)練就了R飛一般的操作手速，如果這樣的微操來玩魔獸，也絕對(duì)是把好手。
“怎么了？”
“是這樣的，在需求文檔里面有提到一個(gè)流水號(hào)的概念。但目前似乎大家的理解有一些不一致?！?/p>
“流水號(hào)還不好理解嗎？同一種類型的優(yōu)惠卡流水號(hào)順序往下排唄~”
“可問題是，每一次生成卡號(hào)時(shí)流水號(hào)唯一，還是系統(tǒng)內(nèi)的流水號(hào)就是唯一？”
“當(dāng)然是系統(tǒng)內(nèi)同一個(gè)流水號(hào)只能存在一個(gè)咯！”
“但目前他們做的效果是每一次生成流水號(hào)的時(shí)候都從“1”開始編號(hào)，這樣也不能說和需求不一致，因?yàn)檫@個(gè)點(diǎn)需求上也沒寫明確。但我覺得實(shí)際需要的應(yīng)該不是這樣的，所以和你確認(rèn)一下?！?/p>
“嗯，你理解的沒錯(cuò)……”
“好的，我剛才給你發(fā)了個(gè)郵件，你答復(fù)確認(rèn)一下吧。”
“沒問題……”
掛了電話，小J顯得有一些局促。
雖然和項(xiàng)目組的私交不錯(cuò)，這樣的小問題不至于通過需求變更來處理。但畢竟是對(duì)需求理解歧義造成的問題，如果就這樣上線，那還真不好說還算不算一個(gè)“小問題”了。
復(fù)盤
從上面的例子中可以看到，就一個(gè)如此簡單的“流水號(hào)”的概念就可以產(chǎn)生如此巨大的偏差，要保證需求文檔中的描述準(zhǔn)確其實(shí)并不那么簡單。
雖然，大部分業(yè)務(wù)場景中，流水號(hào)就是整個(gè)系統(tǒng)中唯一的，但確實(shí)可能存在一些業(yè)務(wù)需要會(huì)在每一個(gè)事務(wù)狀態(tài)下從1開始生成流水號(hào)，以便于知道某一條記錄在事務(wù)中的處理順序。
比如足彩3D的開獎(jiǎng)程序，就必須記錄每一次開獎(jiǎng)的第1、2、3個(gè)數(shù)字，并且三個(gè)數(shù)字的順序不能替換；到下一次開獎(jiǎng)時(shí)需要記錄的還是第1、2、3個(gè)數(shù)字，而不是第5、6、7個(gè)數(shù)字。
所以，如上的理解差異并不能說案例中的程序員理解是錯(cuò)誤的。
甚至可以說，在一個(gè)有需求分析師的開發(fā)團(tuán)隊(duì)中，保證需求傳遞不失真就是需求分析師的職責(zé)。
雖然通過書面表述的確會(huì)存在各方理解不一致的情況；雖然一些理解能力欠缺或者缺乏責(zé)任心的程序員也會(huì)導(dǎo)致需求理解的扭曲。但需求分析師的存在，就是需要去采用各種手段來化解各方對(duì)需求理解的不一致，減少需求傳遞失真導(dǎo)致的開發(fā)風(fēng)險(xiǎn)。
所以在上面這個(gè)案例中，雖然可以認(rèn)為程序員也沒有必要的開發(fā)常識(shí)或者責(zé)任心。但出現(xiàn)這樣的錯(cuò)誤歸根到底仍然是需求分析師的責(zé)任。
需求文檔的質(zhì)量就是需求分析師的基本功。雖然不可能直接通過文字傳遞來保證各方理解100%的準(zhǔn)確，但事實(shí)上仍有辦法來避免一些可以預(yù)見的歧義。
在一些需求文檔的模版中，都會(huì)有一個(gè)“項(xiàng)目背景”或者“需求背景”的章節(jié)。在一些項(xiàng)目團(tuán)隊(duì)中，這個(gè)章節(jié)也就是形式上必須得寫，以提高逼格的部分。
但事實(shí)上，在闡明需求的細(xì)節(jié)前，介紹清楚需求的背景和目的，是幫助讀者理解需求文檔必不可少的環(huán)節(jié)。
任何需求細(xì)節(jié)的描述都是為了一個(gè)統(tǒng)一的業(yè)務(wù)背景服務(wù)。說明白了業(yè)務(wù)背景，事實(shí)上就是解釋明白了“為什么要做這個(gè)需求”。這是在需求細(xì)節(jié)之外的更高層次的東西。如果在這個(gè)層面能讓讀者保持理解上的一致，那么下一層的理解往往可能就水到渠成。
比如在本文的例子中，編寫流水號(hào)的目的是為了：“讓卡片在系統(tǒng)內(nèi)有一個(gè)唯一識(shí)別的編號(hào)，以便于未來運(yùn)營分析時(shí)可以追溯每一張卡的去處”。如果解釋清楚了這一層的意思，就不再需要詳細(xì)的解釋更細(xì)節(jié)的東西，開發(fā)者自動(dòng)就會(huì)知道要實(shí)現(xiàn)這個(gè)目的，絕不是每次生成流水號(hào)都從1開始。
再舉一個(gè)例子，我們需要在app中做一個(gè)消息推送的功能。
如果我們就寫成：“app能夠推送消息，用戶點(diǎn)擊推送的消息就可以查看對(duì)應(yīng)的內(nèi)容”。而這一個(gè)描述還有很多的歧義，如果要描述清楚，我們必須在增加很多細(xì)節(jié)：
- 推送消息是必須在APP打開時(shí)才能收到還是關(guān)閉時(shí)也能收到？
- 消息推送是指定推送，還是在預(yù)裝app的所有軟件中都進(jìn)行推送？
但如果我們直接的表述清楚需求的目的和背景：推送消息是為了激活長久不使用app的用戶。這樣在更高的層次上和讀者達(dá)成了一致，那么就算缺少那些細(xì)節(jié)，理解上也不會(huì)有太大的誤差。
- 因?yàn)槟繕?biāo)是長時(shí)間不使用app的用戶，所以推送的消息必須在App關(guān)閉時(shí)也能夠送到
- 對(duì)于用戶激活來說，需要能夠識(shí)別出那些不經(jīng)常登錄的用戶，然后進(jìn)行精準(zhǔn)的推送
我們可以看到，當(dāng)開發(fā)者知道了需求的最終目的和背景，很多細(xì)節(jié)上的東西就會(huì)主動(dòng)的去尋求確認(rèn)，甚至自主的決策（因?yàn)槟繕?biāo)已經(jīng)一致了，所以一些細(xì)節(jié)上的差異想法也不會(huì)有太大的偏差）。
