剛在某客戶做了3個月的需求調研，親自體驗了需求調研的過程，有一些感想，總結下來。
客戶方配備了BA和SA，BA是業務專家，SA是技術專家，負責輸出一個描述業務需求文檔XXXS，將流程和需求都記述在該文檔中，和大多數客戶一樣，客戶的優勢在于對他們的業務比較了解，但是對于如何去抽象業務，比較系統的把他們的業務需求歸納并描述下來，并不擅長，至少很多人不擅長，這就導致客戶方的XXXS文檔中通常是一些需求片段和樣例。
我方對一個topic，分配了SA和BA，其中SA負責技術方案，而BA負責理解業務并澄清業務，topic的輸出件有XXD和XXS，XXD主要記述業務流程和topic級的solution，XXS主要記述系統的功能。
XXD中的業務流程，準確的來講，應該改名叫系統流程，是講述業務功能操作是如果由解決方案各個內部子系統及外部系統協同完成的。這其中的actor是系統，因此，是從系統的角度來描述的。
XXXS中，模板像系統用例文檔，但是里面的一個個單元是叫功能，功能與用例的差別就是，一個是從系統的角度出發，一個是從Actor（即用戶）的角度出發，對每個功能，有功能描述，功能的前置條件、后置條件、功能的用戶角色、業務規則，輸入規格，輸出規格，如果涉及到界面，就有界面原型。具體的內容，通常pre-condition是千篇一律的，如用戶必須已登錄什么的，后置條件通常是結果，而角色通常是一個很泛的一個總稱（比如在廚房干活的分切菜的，炒菜的，統稱廚子）。
對于客戶方描述的不清楚或者只描述了幾個片段或例子的需求，我們采用prototype的方式，先按照自己的理解做prototype，然后給客戶去演示，由客戶來決定是否符合他們要求。
是不是看上去很完美？
再看看幾個問題：
問題一：對客戶方的某個需求，我方一直不理解客戶方為什么會提這么怪異的需求，覺得不可思議，而客戶方一直堅持要這個功能！
問題二：客戶方并不具備多么深厚的業務抽象功力，我們自己通過蒙著眼睛摸象的方式作出原型給客戶方評審，客戶方say ok就ok，不ok就不ok，客戶方不會犯錯誤嗎？客戶方會照顧你其它客戶的需求嗎？我們拒絕客戶方的理由通常是實現不了，或者工作量太大。我們絕大多數人沒法使用客戶的業務語言告訴客戶，你的目的是什么，你要求怎么來做，這樣做有什么樣的壞處，我建議這么做，這么做能獲得什么樣的好處。
問題三：我們把一些業務角色使用的功能和運維人員使用的功能放置于一個界面中，從功能上來講，我們可以自豪的告訴客戶，我們實現了你要的功能。
。。。
我相信我了解到的問題絕不是全部，還有很多我不知道的問題。
對這種狀況，我逐一分析了一下原因：
問題一：因為我們理解的業務概念跟客戶理解的客戶概念不一樣，雖然我們叫的是同一個名詞，但實際上并不是同一個東西，從而導致我們覺得客戶提的要求匪夷所思；
問題二：我可以說，其實我們的做法是去摸清楚客戶要什么，但沒有去理解他為什么要；
問題三：很明顯，我們實現了功能，但忽略了功能的使用者是誰；
這一切的根源是什么？我認為，這根源是我們一直從系統的角度去思考問題，思考我們的系統功能，思考我們的系統流程，對一個經驗豐富的專家來講，也許會考慮的比較全面，但絕大多數人往往是重視了功能的描述，而且描述是基于我方的語言，忽略了功能的用戶，而我們沒有一個萬能的客戶和萬能的專家幫我們指出交付件的所有的問題。
即便是我們成功交付了一個系統，我們還是沒有消化客戶為什么要這么做的原因，對業務系統來講，這是最核心的價值之一。
我們要怎么改？我的建議是：
1、加入對“用戶需求背景”的調研，即真正的“業務調研”，在這個階段的主角是BA，BA是業務專家，對IT技術不熟，這是他的優勢，這個階段的輸出件要包括客戶的業務架構，包括組織結構，人員角色，業務流程（是各業務人員如何協同來完成工作，跟系統流程有本質區別），業務模型（用戶做的事情中涉及到的一些概念，這里指純業務概念，客戶能感知的，非系統概念）。經過這個階段，我們應該能明白客戶為什么會提這個那個需求，能夠有效避免因為客戶的片面和狹隘導致我們跟著片面和狹隘，并且我們知道了客戶說的概念A是指什么，概念B是指什么，跟我們平常所說的有什么不同。
2、扭轉“功能分析”的角度，由從系統的角度分析轉變成由用戶的角度分析。把功能變成用戶基于系統所做的操作分析（系統用例），首先搞清楚是誰，然后是要基于系統做什么事情，有什么業務規則，前置條件和后置條件是什么，再次是系統通過什么樣的界面或接口來支持。輸出的內容看似都差不多，但因為是從用戶的角度出發分析的，提供的功能自然會更貼用戶的心。
3、我們要明白一個基本原則，業務架構是不依賴于IT系統存在的，IT系統是規范業務運作和提升業務效率的工具，IT系統中的軟件概念是業務概念在軟件系統中的投影，千萬不能從技術的角度出發，視圖去重定義業務概念。