個人背景與工作內容

過去的背景為電商業網頁開發程式設計師，目前在金融業擔任PM兼BA，工作內容包含專案管理與需求訪談、需求確認、需求驗收等。

選課動機

因初次擔任BA需求負責人，從未學習如何當BA，僅憑自己印象與身邊的BA當學習對象，需求分析文件不知如何撰寫才到位，需求訪談階段不知如何談判，希望透過課程了解正確的需求分析方式。

講師教學特色與助益

BA(Business Analyst)最快的上手的方式：建議IT調到業務/使用單位，由IT學習User的語言比較快。

BA與SA最好不要兼任，BA做的是需求文件(與技術無關)；SA寫的是規格文件(與技術相關)。

需求分析的層次：法規、商業(戰術、戰略、內規)、使用者需求、功能性需求、非功能性需求、其他(資料轉換、教育訓練)。

驗證需求(BA)：Make The Right Product v.s. 驗證規格(SA)：Make The Product Right

面對需求五提問：1.Who 2. What 3. When 4.Why 5.How

課程收穫與技術學習

BA與SA的差異，因為公司多為BA與SA兼任，比較混淆這兩者差別，覺得BA就是做SA的工作，進行規格確認，系統可行性分析、Table欄位規劃…等，但實際上了課才發現兩者完全不同，BA是針對使用者需求流程的確認，SA是針對技術可行性做規格確認，BA不需考量技術可行性，完全以使用者角度為考量，確認需求範疇後，再交給SA做技術規格分析，兩者是不同階段的規劃者，因IT的觀點多數以系統為出發點，非以使用者角度考量，需求分析需要多理解使用情境，依據需求分析的六個層次解析，避免需求矛盾與規劃不全，才能建立User與IT之間良好的溝通橋樑。

實務應用與職涯發展

目前擔任PM兼BA，初次擔任需求負責人，還無法掌握需求如何與使用者談判的訣竅，常常以為自己了解需求，但進入開發時，才發現缺少很多細節，導致開發重工或方向錯誤，浪費不少時間成本，若能利用課堂學習的知識，在需求訪談階段便掌握需求細節，必定能為專案節省不少時間成本，也提升專案成員合作的效能。將運用課堂所學，在與User對焦時，對需求抱持五提問：Who,What,When,Why,How，了解需求的具體使用情境，由哪個角色來操作使用，完全了解後再簽回細則，避免開發時對需求一知半解，對需求產生誤解，增加使用者及開發者的負擔，故BA對於軟體開發擔任重要的角色。