持續傳遞中的業務分析

在需要頻繁交付、不斷收集使用者反饋、擁抱變化、追求業務敏捷的項目中，軟體的開發和交付是迭代式進行的。在這樣的項目團隊中，BA（商務分析師）通常需要在一個開發迭代開始之前完成該反覆式開發法任務的分析。但在特殊情況下，從收集客戶需求到將功能細節傳達給Team Dev的周期會縮短到一至兩天。BA可以用于思考和分析的時間遠遠少於可以預先做出所有設計的瀑布式項目。

相關廠商內容

Sybase線上研討會：雲時代的列式資料庫——Sybase IQ15.3新特性(8月22日 周一)

百度技術沙龍第十七期：富用戶端時代的JavaScript架構（8月20日 周六）

2011系統架構師大會隆重召開請關注

百度世界2011大會，9月2日國家會議中心盛大開幕！免費報名中！

InfoQ誠聘：策劃編輯、專案經理、商務經理等

那麼在這樣的敏捷項目中，BA如何能夠適應這種交付模式，完成高品質的業務分析，協同團隊為客戶交付高價值的軟體呢？

項目背景

ABC公司是一家知名的國際性會計師事務所，業務規模龐大，分公司遍布全球170多個國家。

ThoughtWorks受邀對其“全球派遣服務(International Assignment Service)”業務部門提供IT解決方案，以及軟體系統的開發。該系統包括收集其客戶的全球派遣僱員的報稅資料，以及管理ABC公司稅務諮詢師對這些資料的進行審核、彙算和出具報告的商務程序；逐步替換其目前已遠遠不能滿足業務和效能需求的遺留系統。

該系統主要有兩類使用者，一類是ABC公司客戶方被派往不同國家工作的僱員（以下簡稱Mary），這些僱員使用該系統填入報稅需要的資料。另一類使用者是ABC公司的稅務諮詢師（以下簡稱Kim），負責審核、處理Mary提交的資料。

BA在該項目中面臨的主要挑戰

• 該項目為分布式開發，ABC公司的決策方在美國，而ThoughtWorks的Team Dev在中國，溝通反饋周期有時較長。
• 由於ABC公司對使用者體驗的重視，需要頻繁交付軟體，以便收集使用者反饋並及時調整解決方案和後續開發計劃。這大大縮短了從收集需求、開始分析到進入開發的周期，增加了分析中出現缺陷的風險。
• 當開發過程中發現問題時，無法馬上與客戶取得溝通，開發進度可能會受到影響。

識別業務價值

業務分析的重要性在於首先做正確的事情。理解客戶的業務，關注需求背後的價值可以協助項目團隊在軟體的設計方面做出正確的選擇。

而我們面臨的困難是，客戶提出的需求，往往都是直接的軟體功能，而不是需要解決的業務問題。如果BA只專註於針對客戶需要的功能進行系統分析，就喪失了協助客戶最佳化解決方案以及改進商務程序的機會。

如何尋找業務價值？

以敏捷開發方法中的使用者故事為例，找出客戶要解決的業務問題的一個簡單辦法是，用以下方式概括每個使用者故事的內容：

As…（角色），I want to…（完成什麼樣的功能）,So that…（解決什麼問題，帶來什麼價值）

“So that…”說明了該故事的業務價值，即要解決的業務問題。準確的尋找業務價值將有利於我們設計出最適合的“I want to”，這很可能優於客戶直接提出的功能要求。

需要注意的是，不要把解決方案或功能當成該使用者故事的價值。以ABC公司業務系統中的一個使用者故事為例，BA對該需求業務價值的瞭解程度將直接影響到解決方案的優劣。

作為(As…)	我想要 (I want to…)	以便 (So that…)	是否闡明了價值？
Mary	即時瀏覽我的行程統計資料	瞭解我在各個國家或地區停留的時間以及從事的活動	否
Mary	即時瀏覽我的行程統計資料	我可以迅速地檢查我所輸入的在各國家或地區停留時間及從事活動的資料是否正確（以保證我可以依照法律要求提交準確的報稅資料）	是

在該使用者故事的兩種不同表述中，由於第一種表述只說明了需要的功能，沒有說明業務價值，在功能設計時，我們可能會將“行程統計資料”的內容設計的過於詳細而造成浪費，使使用者不明白此功能的意圖。而第二種表述的營運目標就非常明確，可以協助我們更加容易地設計出適合的解決方案。

此外，BA在瞭解客戶的業務問題時，最好請客戶提供一些真實案例/情境來證實其觀點並加深自己的理解。

避免分析錯誤

在實際工作中，我們發現有以下兩個方面的分析工作容易被BA忽略，而做出錯誤的決定。

1. 客戶要求實現某些現有商務程序或遺留系統的功能

   例如，客戶需求的功能，是當前遺留系統中已經使用多年、且未收到過任何抱怨的功能。所以客戶和BA往往認為這個功能是合理的，忽略了深入的分析和思考。而這種思考不全面而做出的決定可能會與可以預見的新功能產生衝突。

   在ABC公司的遺留系統中，用來收集報稅資料的問卷內容是通過excel表來維護的，而Mary在前台也是通過下載excel問卷，填寫完畢後再上傳。

   在新開發的系統中，問卷被改為線上方式，並輔助以其他必要功能提升Mary的使用者體驗和滿意度。但由於客戶方的員工都是財務背景出身，非常喜歡使用excel表，而之前用excel表維護問卷內容也被證明是非常有效，所以客戶堅持在新系統中延用這種方式。經過仔細的分析，我們發現在針對提高Mary使用者體驗的新功能上線後，使用excel表維護問卷內容將大大增加維護的工作量及錯誤率，而這與項目的相關目標背道而馳。ThoughtWorks在列舉了問題的細節後，說服客戶採用了新的解決方案。

2. 客戶要求利用新的IT系統改變當前的商務程序

   客戶發現目前的商務程序有不合理的地方，希望在新的IT系統裡直接改變這些流程。如果不經過仔細的分析，這種做法可能會很危險，商務程序的盲目改變可能會對一部分使用者造成麻煩，為客戶實施該軟體形成強大阻力。那麼瞭解清楚目前這些流程存在的價值和原因事關重要，從而可以協助我們為客戶提供科學的、逐步最佳化其流程的IT解決方案。

在ABC公司的商務程序中，Kim和Mary之間的一些交流是通過郵件來完成的。這裡存在兩個業務風險：1）Kim和Mary交流的重要訊息被散落在各自的郵件裡，系統無法記錄，在遇到法律問題時，難以劃分責任；2）Kim和Mary可能會使用郵件發送一些保密性較強的內容，如果發錯，後果不堪設想。

在開發新系統時，客戶要求我們增加了一個訊息功能，使Kim和Mary之間的交流可以方便地在系統內部完成。該功能上線後，很好地化解了這兩個業務風險，同時收到了Mary這類使用者的良好反饋。然而這對該會計師事務所在某些國家分公司裡的Kim這類使用者的工作卻帶來了不小的影響。由於之前使用郵件系統，Kim可以將Mary的郵件轉寄給相關的同事，並利用郵件豐富的功能進行結果的跟蹤。而新上線的訊息功能達不到郵件的所有要求，所以增加了他們的工作難度。此外，由於Mary對這個功能的青睞，發送訊息的數量遠遠超過了在使用遺留系統時發送郵件的數量，超過了客戶想提高Mary的滿意度而在短期內所能承受的代價。

在遇到以上問題時，我們與客戶一同分析，提出了折中的解決方案，花費了較少的代價將訊息系統和客戶的郵件進行整合，同時協助客戶制定了對此項商務程序改進和配套IT解決方案的藍圖。

理清需求優先順序

在頻繁上線的項目中，其中一個重要的實踐是確定需求的優先順序，使得重要的功能能夠先被開發出來投入使用以便及時收集使用者反饋。一般的做法是要求客戶排好需求優先順序，然後與項目相關成員一同制訂反覆式開發法和上線計劃。但由於客戶決策方所處角色以及思維角度的局限性，對優先順序的評定可能存在盲目。建議BA參照以下價值維度協助客戶對優先順序進行評定。

從客戶價值維度分析需求優先順序

需求價值維度分析圖

價值維度	說明
願景目標	該功能點是否契合項目的願景和營運目標？ 與項目目標的契合程度越高者優先順序越高
時間限制	客戶的業務是否有一定的時間表？ 如果該功能點必須在某時間點前投入使用，則該需求必須被排入相應時間的發布計劃中
市場賣點	該功能點是否是吸引特定目標使用者的賣點？ 如果客戶的資金存在問題或者需要市場的快速認可，則可以考慮將該需求列為高優先順序
有無替代方案	該功能點有無方便的替代方案？ 如果有簡單易行的替代方案，則該需求的優先順序較低
客戶內部政治因素	該功能點是否存在客戶內部的政治因素？ 例如某功能只對小部分使用者提供價值，但會決定客戶內部某個重要組織對這個項目的投資和評價，則可以考慮將該需求列為高優先順序
投資收益	該功能點的開發成本和客戶所能獲得的收益是否匹配？ 例如客戶某工作流程浪費了一個小組人員大量時間，但對其他部門或工作環節無影響。如果開發相應的軟體功能造成的投入大於客戶在一定時期內可以節省的資金，則該需求的優先順序較低
技術依賴性	其他需求是否依賴於該功能點？ 如果依賴於這個功能點的需求優先順序高，那麼該功能的優先順序應更高

技術風險對優先順序的影響

除了來自客戶方面的決定因素，我們還應考慮技術實現方面的影響。如果一些技術風險較高的功能可以先進入開發階段，則問題會儘早地被暴露。開發人員在項目早期解決這些問題會有利於開發成本的節約。所以除以上客戶價值維度外，應再參考以下矩陣來權衡需求的優先順序。

需求優先順序矩陣

客戶價值維度和需求優先順序矩陣並不是優先順序高低的計算機，而是與客戶以及團隊溝通交流的工具。不同項目的影響維度也會有所不同。由於各項因素的複雜性，客戶價值維度和技術風險因素需綜合考慮，不可以權重來計算。BA可以與客戶對以上因素的內容達成一致，使得客戶在評定需求優先順序時可以快速、準確地做出判斷。同時，通過對價值維度分析，我們將有機會清晰地瞭解到功能優先順序高或低的原因，以便我們能夠準確地編製項目開發和上線計劃，併合理地劃分使用者故事範圍。

藉助價值維度分析，管理客戶期望值

有些客戶的決策人可能會依據自己的喜好劃分優先順序，這對於項目能夠按目標成功交付造成一定的風險。此外，客戶在功能的設計和驗收階段也容易對單個功能追求完美，造成額外工作量，增加專案範圍。而這部分額外工作可能並不合理或者價值較低。長期如此，團隊在開發過程中將逐漸偏離項目目標。如果能藉助優先順序維度對這些額外需求進行分析，則可以提供更令人信服的依據，協助客戶做出正確決定，達成BA和專案經理對客戶期望值的有效管理，從而降低交付風險。

發揮團隊其他成員在業務分析中的作用

在頻繁交付的項目中，如果BA獨自承擔業務分析工作，難免會出現疏漏。ThoughtWorks曾與ABC公司的IT部門合作完成其業務系統的一些整合工作。在合作過程中發現，ABC公司IT部門的開發人員在業務分析中參與度很低，由此造成了如下問題：

1. BA需要寫大量需求文檔，故從需求分析到軟體交付的周期較長
2. 設計缺陷的發現滯後
3. 在需要頻繁交付的情況下，解決方案品質較差，方案最佳化能力較弱

而ThoughtWorks的開發人員由於在業務分析中的參與度較高，則有效地避免了以上問題。

開發人員如何參與分析

開發人員是軟體功能的實現人員，對方案的實現工作量有較準確的估計。在明確項目目標或業務問題後，BA如果能夠和開發人員一同分析解決方案，將更有效地為客戶找到兼顧成本和效果的方案。

在收集到客戶需求後，BA可根據業務價值對需求進行分析，判斷客戶提出的功能或解決方案是否能很好地滿足該業務價值或要解決的業務問題；或者按照自己的理解設計出滿足該業務價值的功能或解決方案。

完成上述工作之後，BA應與開發人員就需求和業務價值進行充分溝通，驗證功能實現的可行性，同時積極探尋更優方法。如果開發人員提出符合業務價值的不同方案，BA則可以要求開發人員提供一些關於開發工作量、方案優劣、技術風險方面的比較資料，從而協助自己有效地與客戶溝通並挑選最佳方案。甚至可以根據分析結果協助客戶調整該需求的優先順序。對於技術難度和風險較高的功能點，建議邀請資深開發人員參與討論。

與開發人員溝通中遇到的挑戰與解決方案

由於上述方法需要與開發人員大量溝通，有些BA在應用以上實踐時也遇到了以下挑戰。

1. 開發人員缺少參與業務分析的熱情

   在ThoughtWorks，大多數開發人員都喜歡積極思考、主動為業務分析提供協助，大大減少了需求分析上的漏洞。然而在ABC公司的IT部門中，開發人員很少主動為業務分析出謀劃策，尤其是團隊中資曆較淺的成員，甚至不願意參與解決方案的討論。團隊成員的優勢沒有得到充分發揮，開發人員只管按需求埋頭苦幹，結果功能和解決方案的問題往往在測試或者驗收階段才暴露出來，不可避免地造成了浪費。

   站在開發人員成長的角度，從ThoughtWorks實踐來看，積極地理解業務、思考解決方案能夠更快地提高技術能力。故此BA可以找出一些實際案例，協同專案經理與團隊各成員進行溝通，鼓勵大家積极參与業務分析，逐步形成開發人員與BA協作的良好氛圍。

2. 開發人員容易就客戶需求或解決方案產生爭論

   開發人員在積極參於分析的過程中，有時會對軟體功能的價值吹毛求疵，在細節上與BA產生較多爭論，使BA在應付開發人員的問題以及與客戶求證答案之間疲於奔命。

解決此類問題，可採取以下方法：

• BA在收集需求時，儘可能充分地瞭解客戶要解決的業務問題，以便能夠快速回答開發人員的問題
• 面對開發人員對解決方案的質疑時，應保持良好的心態，清楚地瞭解開發人員顧慮的問題和原因
• 如果自己掌握的資訊確實不能證明現行方案的合理性時，協同開發人員，找到更優方案並與現行方案進行優缺點比較
• 將新舊方案與客戶溝通，則可快速協助客戶做出判斷

不要忽略測試人員在業務分析中的貢獻

由於測試人員所處角度和對細節的關注，往往可以發現一些功能細節的設計漏洞。所以在使用者故事進入開發前，BA與品質保證人員對相關業務價值進行充分溝通，會在功能進入開發之前為BA創造更正設計缺陷的機會。

做為品質保證人員，如果充分瞭解功能背後的業務價值，相對於只瞭解功能需求，將可以寫出更加完善的測試案例，提高測試覆蓋率。這會為交付高品質的軟體把好最後一道關。

結語

業務分析是困難的，特別是我們面對未知領域的時候。如果只是簡單地按照客戶的具體需求進行軟體開發，那麼我們交付給客戶的價值將非常有限。然而識別業務價值、協助客戶分析需求優先順序、保障團隊協作，將有效提升團隊對軟體的設計能力，解決客戶真正的業務問題，交付更大價值。

作為一名業務分析人員，當您在嘗試以上實踐時，可能會發現自己對客戶業務的理解變得更加深刻。在與客戶的溝通中，也能夠更加容易地提出有價值的問題以及建議，從而提升客戶對項目團隊的信任，為成功交付項目打下良好基礎。

*註：“客戶價值維度”的概念由ThoughtWorks諮詢師李光磊提出。在此對李光磊表示感謝。