探討數據分析需求訪談中的需求分析－為什麼我們會需要做實地考察？
不知道大家在企業當中，都如何進行需求訪談？
相信所有在企業內服務、或是協助企業設計解決方案的朋友，在設計任何系統或是功能性需求之前，都會先針對用戶（或客戶）的需求進行分析或評估。
在這篇文章當中，並不會聊到如何進行一個好的需求訪談，或是需求訪談裡面應該要談些什麼。
在這篇文章裡更想跟大家分享的內容，是從我自身的經驗出發，作為一個幫助用戶設計一個數據分析解決方案的角色，除了評估解決方案的時程和成本之外，更重要的是也需要幫助用戶分析『這個方案是否能真正解決用戶通點』。
那麼如何協助用戶分析解決方案是否合適呢？
往往我自己在進行需求訪談時，除了用戶自己提出來的需求描述（口述、書信、或任何輔助描述需求的文件）之外，我還會實際走一遭用戶產生痛點的業務地點，去『體會』一下用戶的痛點在哪裡，做這個需求背景的『實地考察』。
為什麼會需要進行實地考察？
大家可能會很好奇，為什麼會需要實際走一趟用戶的業務地點呢？
作為一個負責開發與管理專案的ＰＭ或工程師，我們不是就把使用者自己提出來的需求給開發出來就好了？畢竟我們並不是實際負責這個業務的角色，我們怎麼會知道他們要什麼呢？
沒錯！在多數的狀況下，使用者確實更了解他們的業務情境和業務痛點。
但是以我自己的經驗來說，我曾經擔任過提出需求的用戶、擔任過導入系統專案的ＰＭ、也擔任過實際開發系統的工程師，站在用戶的角度來看，他們比其他人更理解業務痛點與商業邏輯，但是凸長有一點不會理解的是：『數據分析的技術或解決方案要如何解決我們的業務痛點？』。
鮮少有用戶會理解資訊系統是怎麼運作的，不過，也鮮少有工程師充分理解業務情境是如何發生的，在這樣子的背景之下，往往在開發的過程中就會有許多的誤會，導致最後實際開發出來的內容，並不一定能真正解決業務痛點。
所以擔任協助用戶擬定數據分析解決方案的角色，更需要實際走一遭業務發生的地點，扮演一個業務與系統間『翻譯官』的角色，看看用戶的數據是如何被搜集進系統裡面，這些搜集進系統的資料，在用戶發生業務的情境底下，他們為什麼會需要看這些數據？以及如何進行這些數據的分析？
該怎麼進行這個需求分析的實地考察？
這個考察的方式呢，是源自於我自己過去在製造業做改善專案學習到的習慣，是來自工時分析的一個環節。
過去在協助工廠擬定生產的改善方案之前，我們往往會分析生產流程的瓶頸（Bottleneck），看最花時間的生產工序在哪一個生產流程中，透過80/20的法則，從最花時間的生產流程開始改善起，由大問題先著手，讓整體的產量能有顯著的提升。
在分析瓶頸工序時，我們都會先去實際的生產線上，用影片錄製每一個生產流程，事後帶回去分析每一個在生產過程中的動作，從中評估是否有生產中行為的『浪費』。
透過這樣分析生產的行為，來找出產生瓶頸的原因為何，近一步設計解決方案。
這樣子的習慣，隨著我從製造業到金融業中，協助金融業的用戶透過一樣的方式，來設計能真正解決業務痛點的解決方案。
還記得我第一次向資訊單位的主管提出這樣的觀點時，收到主管瞪大大的眼睛看著我問說：『為什麼要去看用戶怎麼處理案件？』。
然而在反覆實際走訪幾次使用單位，透過這樣的方式『分析辦理案件的行為』，並提出真正能解決用戶的方案之後，後面還會收到主管提說ＯＯＯ案子一定要安排時間去實際看一下用戶的情境。
其實實際進行的方式也很簡單，就是拿著一部攝影機（或是其實現在手機很方便，拿手機也可以），再帶著一個小小的腳架，到使用單位『錄製』他們的業務辦理方式，如果是因為考量機密，在不能錄製的狀況下，也儘可能帶著紙筆，把他們操作的流程『畫』下來。
在錄製的影片中要分析什麼？
其實在影片錄製的過程中，透過觀察用戶如何處理他們的業務內容，可以評估我們技術上的解決方案是否能真正解決用戶的痛點，也能評估用戶提出這樣需求的出發點和背景為何？更可以『體會』用戶實際面對的狀況，讓後續在設計系統功能或是分析資料時，更可以貼近實務上的需求，也避免有漏掉該考慮的內容。
進行影片的動作分析，有興趣的朋友們可以參考工時分析裡面的相關概念，做進一步的研究，這邊就簡單跟大家分享幾個我自己會評估的內容：
詳細觀察用戶的每一個動作，看他們執行這些業務的流程是什麼？
在辦理一個案件時，他們都做了哪些事情？
為什麼他們會需要做這些事情？是否有其他限制因素？
評估每一個動作執行的時間？
從過程中評估他們做這件事情的人力。
評估需求的規格是否合理？
系統流程的設計是否合理？
更重要的是，站在用戶的角度思考問題。
透過思索上面的這些問題，在數據分析的專案上，就可以打磨出很多不一樣的事情：
這些資料是從哪個環節被搜集進來的？
為什麼會需要搜集這個數據？
這個數據是怎麼被產生的？
有沒有更有效的方式來搜集數據？
有沒有哪些數據是應該被搜集，但還沒有被搜集進來的？
用戶追蹤這個數據是否合理？是否有其他數據應該被追蹤？
有沒有可能透過機器學習或AI的方式去解決？或是他們只是需要一個流程的自動化而已？
……諸如此類等等的內容。
透過實際分析用戶處理業務內容的動作與行為，我們可以進一步去對照使用者所提出的需求規格，評估是否能真正解決該用戶所面對的問題，進而與用戶一起找出能解決痛點的方案。
最後
有一位對我影響很大的顧問前輩曾經分享說，在設計解決方案之前，會習慣花較多的時間來釐清問題，當真正的問題被釐清出來之後，往往可以透過很簡單的方式來解決。
我自己到現在也不斷承襲著這樣的觀念，不論是在協助用戶設計報表，或是設計機器學習或人工智慧的解決方案之前，都會先分析用戶的使用情境，確定這樣子的方案可以解決用戶痛點後再進行開發。
有時候往往用戶會想要透過ＡＩ的技術解決所有業務上的痛點，但透過分析之後，往往只是需要把幾個流程自動化，或是多呈現幾個指標作為業務分析的參考，並不會需要很複雜的解決方案。
透過錄製影片做業務情境的動作分析，是能夠幫助ＰＭ和工程師更理解業務痛點的一個很棒的方法，這樣的方法在製造業非常常見，但可能在其他做數據分析的產業中還不太常見，希望透過這篇文章，將這樣的方法分享給各位，幫助大家設計出能真正解決痛點的數據分析方案。
