業務分析處在開發過程的上遊，提高業務分析的品質，可以減少後續開發、測試和內建過程中的反複确認，場景遺漏。采用可視化的業務分析工具箱可以大幅度避免文字版的業務需求描述所帶來的不夠完整，有誤解等問題。CODING 特邀靈活顧問、“業務分析工具箱”創始人王洪亮老師将在本次 《可視化業務分析》 課程中，帶領大家掌握可視化業務分析的基本工具和方法，以提高業務分析的品質和效率。
今天我為大家介紹可視化業務分析。提到業務分析，是指以文字為主的業務描述文檔 SRS，即軟體需求規格說明書。線上下教育訓練時，我會讓學員做個小互動來直覺感受詳細的業務分析的重要性：首先讓學員分組，每組選一位代表來觀看展示在螢幕上的圖形，把看到的内容記下來并以口頭表達的方式傳達給組員，組員在 A4 紙上來複現。
因為涉及到很多精确的元素位置，以口頭的方式并不能正确複現。比如組員描述：“這個焦點叫圓心，正方形的邊長是圓形半徑的一半。”組員在複現尺寸時則會産生較大的偏差。可想而知，當我們用口頭或者文字的形式，去表達很複雜的需求時，我們的開發團隊、測試團隊會在了解上産生偏差，進而在複現上産生錯誤。如果讓組員把圖形拍照之後交給團隊去複現，則複現錯誤的可能性會大大降低。同樣道理，我們在表達業務需求時，能夠表達的資訊帶寬越寬、表達的資訊越充分，我們傳遞的資訊就越準确，組員了解越透徹，産品做出來就越精準。
舉個例子，從 ATM 機上取錢的形式叫 IPO（Input Process Output），分别是輸入參數、處理過程和輸出參數。賬戶如果扣減失敗，需要提前把扣減的賬戶餘額退回賬戶，但如果隻在這個條件下進行了描述，其他條件下沒有标注，就有可能産生遺漏且難以被識别。而當我們發現了需要補充相關的資訊時，就會引起格式上的調整。
如果我們采用如下格式來書寫 SRS ，想要準确的表達給開發團隊就要在文檔上花很多功夫。由于全是文字，如果複制時産生了覆寫就會造成資訊的丢失，是以采用純文字方式描述業務需求會産生問題：一是難以閱讀；第二是會産生一些錯誤并且不容易被發現；最後是修改時會産生格式調整，引起不必要的新錯誤。
同樣的業務需求，我們可以換一種表達方式——泳道形流程圖。圖上矩形、菱形分别表示處理和條件，加上使用者、ATM 和賬戶三個泳道，讓每個處理者能清晰了解是誰在負責；當發生變更時，就能明顯呈現出哪裡發生了變更。采用可視化的方式表達業務需求，可以更好地呈現所有資訊。
語言表達會增加誤解的可能性，更何況語氣無法在文字中表達，是以當開發人員和測試人員産生了解偏差，他們就會争論到底誰是正确的。當沒法判斷時，就到上遊來詢問 BA，如果 BA 也沒法判斷就會繼續向上詢問，為了避免浪費時間，在 BA 向開發和測試團隊傳達需求時，就應該清晰地傳達，確定需求的正确性和可讀性。如果 BA 最開始對需求描述就是錯誤的，而且通過文字表述的方式向客戶确認，客戶也沒有發現錯了，就會導緻開發和測試白幹；如果在測試時才發現場景或條件有遺漏，就會導緻産品品質下降、項目延期，如果在初期能夠發現遺漏，這些隐患就可以及早消除，不至于産生反複、推遲的問題；還可能遇到因為多個 BA 處理自己負責的部分，根據自己的了解去需求，導緻最終結果不一緻，開發無法進行的情況，這可以通過互查工具來避免。
當業務需求分析人員遇到了需求分析，簡略寫過後讓開發人員自行發揮，就有可能與原始需求不一緻，之後發現問題進行返工就會導緻開發時間過度消耗。為了避免出現這樣的情況，在最初就要将需求細化到一定程度，讓開發人員能夠按照明确需求做出正确版本。
需求沒有優先級會導緻使用者發現産品的各種問題，這種情況可以通過疊代的方式解決，每個疊代傳遞一次，按照價值的優先級進行排序，使用者可以更短周期地給出回報，開發就可以做出更正确的産品；如果總是需求變更，當發生變更時，BA 機械地從上遊把變更情況傳遞給開發人員，會産生 BA 沒有責任，都是開發人員背鍋的情況，那二者之間可能産生沖突，打擊士氣。其實需求變更就是 VUCA 時代，誰能更好地響應變更，就具有更強的競争力，這對整個團隊來說都是非常好的事情。
例如判定矩陣，我遇到過一幫業務專家研究什麼情況下叫故障，我問判斷裝置是否故障有多少因素？專家說共四個因素，那麼每個因素有兩個選項，列成表格形式，一共是 16 種組合。這個問題就迎刃而解，整個項目可以快速往下推動。軟體開發團隊使用正确的工具，可以起到非常大的改進作用，甚至縮短傳遞周期進而提高整體代碼品質。在整個軟體開發的過程中，BA 的角色叫業務分析師，他的定位是在領域專家和技術專家之間搭建起一個橋梁，将領域專家提出的領域需求翻譯成一個技術需求，讓技術專家能夠實作正确的過程。BA 拿出一份需求文檔，兩方都有相同的了解，這才是一個優秀的 BA 應該做的事情。
以 Scrum 環境為例，在 Scrum 中團隊沒有進行細化，是以 BA 也是團隊的一部分。在團隊裡 PO 跟最終使用者進行溝通，将收集到的最初業務需求分解成使用者故事，進行價值排序并設定産品計劃、産品戰略等等，那麼 BA 就應該是把最初拿到的以使用者故事為機關的需求，轉換翻譯成開發團隊能夠看懂，并且能夠正确實施的需求過程，是以 BA 是介于這二者之間的一個溝通橋梁。需求處在開發過程的最上遊，那麼需求分析的品質改善就會對下遊産生一個杠杆作用，是以 BA 不要去做低價值的事情，而是需要讓團隊價值得到更好地展現。
需求變更是常态，如果能夠提前去想到應對變化的措施，那就真正掌握了如何提高靈活性。變化不僅展現在代碼上，在需求層面也需要響應變化，才能夠真正推進整個軟體工程。需求文檔寫出來開發團隊要看、測試團隊要看，在 Scrum 中 Scrum Master、PO、UI、最終使用者、幹系人都要看，但每個人所處的立場不一樣，希望看到資訊也是不同的，如果把文檔以合适的形式來組織，讓每個角色都能快速了解并且保證高品質，那麼整個軟體開發過程都能得到很大程度的提升。
例如虛拟一個巴士租賃項目：國内旅行社要租賃國外的巴士安排旅客行程，接到訂單就将乘客安排上巴士，行程結束司機結算相應費用。用如下流程圖的方式将巴士租賃的主要業務邏輯畫出來，可以發現在某些情況下并沒有說明判斷基準。遇到一個業務需求時，可能會有各種各樣的條件來判斷這些步驟是否可以往下推動，把這些條件全部列出時整個流程圖會變大、沒有分層導緻難以閱讀和維護，而且非常難以變更，如果想實作不論條件如何判斷這張圖都不發生改變，那麼就需要通過解耦合的方式讓文檔産生一份固定和一份可變動的。
可以從下圖看出判定矩陣的構成形式，前面是條件，每一個條件的選項按照 Excel 的形式列出，用這種方式列出所有的四種組合，動作全是派車，那麼最後的結論就很清晰。用這種方式可以確定條件覆寫率達到 100%。如果有遺漏那是因為所采用的工具沒法達到 100% 覆寫率，比如純文字描述。如果是一個更龐大的表格，達到上百甚至上千行時，也可能産生人為的遺漏，是以需要采用更科學的工具進行自我校驗。
下圖表格的構成形式，前面是條件、中間是操作、後面是預期，這種 Give When Then 的形式就是測試用例，測試人員拿到表格，可以直接作為測試用例使用。這個判定矩陣不僅能提供 100% 的覆寫率，還能夠引導程式員開發出正确的代碼，達到一個好的效果。
狀态之間是通過具體的操作進行切換的，例如狀态 4 無法切換到狀态 1，用這種方式把前面流程相應的狀态全部梳理出來，就可以進行下一步的分析。舉兩個例子：一是貸款審批，實際上内部有三個步驟，第一步核實使用者的真實身份，第二步核實使用者的征信狀況，第三步核實銀行卡與使用者資訊的一緻性。内部在處理資料時有子狀态，但是對外都顯示“貸款審批”，是以會分為内部狀态和外部狀态。另一種叫主狀态和子狀态，比如說出國手續的步驟可以分為機票——酒店——簽證，每一個子過程都有自己的狀态，并且三者是并行，全部狀态完成之後整個過程才算完結。
如圖所示，在目前狀态下能否進行左邊的操作，如果能就打勾，這就是所謂的決策矩陣。如果列出一個 M×N 的矩陣，那麼該矩陣一定是覆寫所有的場景，列出了所有的狀态操作。實際上在畫流程圖時隻提供畫對勾的操作，不會表達出空白格所代表的資訊，是以決策矩陣可以用來了解列出的異常資訊。
善用工具可以更好地呈現業務需求，讓開發人員的了解更深刻。例如綱舉目張：在需求中每一個未确認點就是漁網的一個孔，把網子撐起來才能夠看到有多少孔沒有填充，利用數學或者客觀規律來找到這些潛在的點，然後逐個确認，才能夠達到提升品質、提高效率的目的。如果遵循這些原則，可以發展出新的工具，也能夠更好适應不同的業務場景。
一圖勝千言，以上的所有案例都在講如何用可視化的方式去展示相應的業務需求，例如圖示、圖檔、圖表、表格、流程圖等等。業務需求分析一定要完整，要保證以下幾個方面：
- 正确性：一定要讓需求得到正确的表達；
- 精确性：在表達業務需求時一定要精确，表達不夠清晰就會産生誤解，如果用數學表達式誤解就會消除，是以要用精确的方式來表達需求，而不是過多地采用自然語言；
- 一緻性：盡量保持書寫格式、措辭習慣、表達方式等的一緻，用同一種工具表達可以讓成員了解起來更順暢，讓團隊協助更順利；
- 柔軟性：需求變更一定會發生，是以文檔書寫越具有柔軟性的響應，變更能力就越強。還要記住分層表達，采用不同的層将主流程和條件判斷分開，可以讓文檔具有更高的柔軟性。在需求發生變更時盡可能減少所影響的範圍，可以更快、更準确、更好的讓開發團隊傳遞所有的需求變更資訊；
- 解耦合：包括依賴注入，主業務和依賴是基于界面和校驗的，界面用原型表示，校驗用 Excel，主要邏輯和次要邏輯進行分離。通過解耦合的方式，可以很大程度上提高文檔響應變化能力，更好地讓團隊以更高的效率、更好的品質來提高複用性；
- 多面性：需求讀者是多種多樣的，要考慮每種讀者所站的立場和他們所希望擷取的資訊，是以提供的需求要讓讀者能夠輕松獲得想要知道的資訊，提高讀者的了解程度加快效率；
- 節約時間：BA 在工作上節約的時間都會變成開發的時間，在文檔書寫上盡可能讓調整格式的工作減少，盡早傳遞反複疊代，在保證品質的情況下完成并且傳遞，可以更快的推動開發前進，完成比完美更重要；
- 投入時間：把時間花在有意義的事情上，比如品質、需求表達可讀性的提升，減少開發和測試時間投入，包括減少遺漏或錯誤造成反複溝通确認的問題；
- 未雨綢缪：有很多内容可以提前準備，如果能預先準備好相應問題，在遇到該場景時，可以馬上檢查是否分析全面，是否還有遺漏，同時内容複用率也可以得到很好的提升；
- 最後是墨菲定律，要記住：凡是你不分析的地方一定有問題。
點選觀看完整錄播視訊