關于Jeff：傳統(tǒng)保險行業(yè)電子商務需求分析師辆沦，原ERP咨詢顧問裳涛。得益于其在ERP行業(yè)的工作經驗，其對需求引導众辨、企業(yè)流程梳理有著較為獨到的認識，也致力于在需求分析領域進一步深耕舷礼。
十年的工作經驗鹃彻，可以是用同樣的方法將工作重復十遍，也可以是在每一次工作中有不同的收獲妻献。其中的區(qū)別就在于——是否有不斷的思考和總結蛛株。
Jeff的需求分析札記，素材都取自于Jeff的真實工作經歷育拨。每一篇總結包含了：一個需求的故事谨履，以及Jeff的復盤。Jeff希望通過對工作細節(jié)的整理熬丧，幫助自己更清晰的認識需求分析笋粟。并且在分享的同時，Jeff也期待得到志同道合者的反饋。
8月21日上午10:30 @辦公室
“終于搞定了害捕！”小J在座位上舒舒服服的伸了個懶腰绿淋。
昨天一下午需求通過了業(yè)務部門評審。今天上午又對幾個細節(jié)做了調整尝盼，需求文檔就算是完成了吞滞。
又花費了5分鐘，小J從上頭到尾又瀏覽了一遍文檔盾沫。說心里話裁赠，他對文檔的質量還是頗為滿意的。
他知道赴精，需求文檔必須層次段落清楚佩捞。并且為了便于閱讀和理解，語言組織要盡可能精簡祖娘，同時失尖，最好是使用小段落來展現(xiàn)對功能點的描述。
如果就拿上面這個段落就是需求文檔都一個章節(jié)渐苏，如果修改成更容易理解的形式掀潮，應該是這樣的：
更清晰表達的注意事項：
- 層次段落清楚
- 語言精簡
- 使用小段落
需求文檔的最終目的是讓寫代碼的兄弟看明白。應該讓他們的腦力更多的用于代碼的架構琼富，而不是理解需求上……
想著想著仪吧，小J不經又欣賞了一遍自己的“作品”……
8月25日上午9:20 @辦公室
“叮鈴鈴”
“喂”
“小J，和你確認一個需求鞠眉∈硎螅”電話那一頭傳來R的聲音。
R是項目組的測試械蹋，項目繁重的測試任務練就了R飛一般的操作手速出皇，如果這樣的微操來玩魔獸，也絕對是把好手哗戈。
“怎么了郊艘？”
“是這樣的，在需求文檔里面有提到一個流水號的概念唯咬。但目前似乎大家的理解有一些不一致纱注。”
“流水號還不好理解嗎胆胰？同一種類型的優(yōu)惠卡流水號順序往下排唄~”
“可問題是狞贱，每一次生成卡號時流水號唯一，還是系統(tǒng)內的流水號就是唯一蜀涨？”
“當然是系統(tǒng)內同一個流水號只能存在一個咯瞎嬉！”
“但目前他們做的效果是每一次生成流水號的時候都從“1”開始編號蝎毡，這樣也不能說和需求不一致，因為這個點需求上也沒寫明確佑颇。但我覺得實際需要的應該不是這樣的顶掉，所以和你確認一下√粜兀”
“嗯痒筒，你理解的沒錯……”
“好的，我剛才給你發(fā)了個郵件茬贵，你答復確認一下吧簿透。”
“沒問題……”
掛了電話解藻，小J顯得有一些局促老充。
雖然和項目組的私交不錯，這樣的小問題不至于通過需求變更來處理螟左。但畢竟是對需求理解歧義造成的問題啡浊，如果就這樣上線，那還真不好說還算不算一個“小問題”了胶背。
復盤
從上面的例子中可以看到巷嚣，就一個如此簡單的“流水號”的概念就可以產生如此巨大的偏差，要保證需求文檔中的描述準確其實并不那么簡單钳吟。
雖然廷粒，大部分業(yè)務場景中，流水號就是整個系統(tǒng)中唯一的红且，但確實可能存在一些業(yè)務需要會在每一個事務狀態(tài)下從1開始生成流水號坝茎，以便于知道某一條記錄在事務中的處理順序。
比如足彩3D的開獎程序暇番，就必須記錄每一次開獎的第1嗤放、2、3個數(shù)字壁酬，并且三個數(shù)字的順序不能替換斤吐；到下一次開獎時需要記錄的還是第1、2厨喂、3個數(shù)字，而不是第5庄呈、6蜕煌、7個數(shù)字。
所以诬留，如上的理解差異并不能說案例中的程序員理解是錯誤的斜纪。
甚至可以說贫母，在一個有需求分析師的開發(fā)團隊中，保證需求傳遞不失真就是需求分析師的職責盒刚。
雖然通過書面表述的確會存在各方理解不一致的情況腺劣；雖然一些理解能力欠缺或者缺乏責任心的程序員也會導致需求理解的扭曲。但需求分析師的存在因块，就是需要去采用各種手段來化解各方對需求理解的不一致橘原，減少需求傳遞失真導致的開發(fā)風險。
所以在上面這個案例中涡上，雖然可以認為程序員也沒有必要的開發(fā)常識或者責任心趾断。但出現(xiàn)這樣的錯誤歸根到底仍然是需求分析師的責任。
需求文檔的質量就是需求分析師的基本功吩愧。雖然不可能直接通過文字傳遞來保證各方理解100%的準確芋酌，但事實上仍有辦法來避免一些可以預見的歧義。
在一些需求文檔的模版中雁佳，都會有一個“項目背景”或者“需求背景”的章節(jié)脐帝。在一些項目團隊中，這個章節(jié)也就是形式上必須得寫糖权，以提高逼格的部分堵腹。
但事實上，在闡明需求的細節(jié)前温兼，介紹清楚需求的背景和目的秸滴，是幫助讀者理解需求文檔必不可少的環(huán)節(jié)。
任何需求細節(jié)的描述都是為了一個統(tǒng)一的業(yè)務背景服務募判。說明白了業(yè)務背景荡含，事實上就是解釋明白了“為什么要做這個需求”。這是在需求細節(jié)之外的更高層次的東西届垫。如果在這個層面能讓讀者保持理解上的一致释液，那么下一層的理解往往可能就水到渠成。
比如在本文的例子中装处，編寫流水號的目的是為了：“讓卡片在系統(tǒng)內有一個唯一識別的編號误债，以便于未來運營分析時可以追溯每一張卡的去處”。如果解釋清楚了這一層的意思妄迁，就不再需要詳細的解釋更細節(jié)的東西寝蹈，開發(fā)者自動就會知道要實現(xiàn)這個目的，絕不是每次生成流水號都從1開始登淘。
再舉一個例子箫老，我們需要在app中做一個消息推送的功能。
如果我們就寫成：“app能夠推送消息黔州，用戶點擊推送的消息就可以查看對應的內容”耍鬓。而這一個描述還有很多的歧義阔籽，如果要描述清楚，我們必須在增加很多細節(jié)：
- 推送消息是必須在APP打開時才能收到還是關閉時也能收到牲蜀？
- 消息推送是指定推送笆制，還是在預裝app的所有軟件中都進行推送？
但如果我們直接的表述清楚需求的目的和背景：推送消息是為了激活長久不使用app的用戶涣达。這樣在更高的層次上和讀者達成了一致在辆，那么就算缺少那些細節(jié)，理解上也不會有太大的誤差峭判。
- 因為目標是長時間不使用app的用戶开缎，所以推送的消息必須在App關閉時也能夠送到
- 對于用戶激活來說，需要能夠識別出那些不經常登錄的用戶林螃，然后進行精準的推送
我們可以看到奕删，當開發(fā)者知道了需求的最終目的和背景，很多細節(jié)上的東西就會主動的去尋求確認疗认，甚至自主的決策（因為目標已經一致了完残，所以一些細節(jié)上的差異想法也不會有太大的偏差）。
