商業分析真的沒那麼難，只要你在對的時間找到對的人(5/7)

當你咬著牙爬過天堂路之後，才會發現接下來才是真正考驗的開始。

1. Part 3–1：引出需求 (Elicit Requirements)
2. Part 3–2：開發過程中的圖像化溝通 (Models)
3. Part 3–3：驗證與確認 (Validation and Verification，簡稱 V&V)

1. 最高主管(執行長/總裁/部門主管)Master Manager：
   吉祥物，這裡應該不用再重複說明了，前面的文章已經說過 N 次了。這是個最重要、但在開發過程中也最沒用的角色。
   雖然說 Master Manager 同時扮演著吉祥物和 Sponsor 的角色，但他只會在最後一次 V&V 的時候，因為要畫押、簽下 Approval 這個大字，所以出現的時間比較長一點；其他時候頂多來沾沾醬油，出現一下幫大家打打氣，而且這還是一切都很順利的時候。
2. 產品經理/Product Manager：
   當 Master Manager 沒出現，但 Product Manager 戴著一副八百年沒洗的吉祥物頭罩，進入會議室的時候，皮就要繃緊一點了。
   這時候，我們要仔細觀察，如果他眼神呆滯或甚至帶點怒氣，那多半是才剛從 Master Manager 那裡被訓了一頓；如果看起來很開心或是有說有笑的，那八成是他還搞不清楚今天是開哪個會，或者剛接到新工作的錄取通知，準備跳槽了。
   聽起來和吉祥物一樣沒用對吧？嗯，對，Product Manager 雖然是很重要的代理吉祥物，甚至是 Master Manager 躲起來不願意畫押的時候，Product Manager 的作用就是獻出他的手，但除此之外，開發過程中別來亂就好。
3. 業務/商業暨產品開發/Sales＆BD：
   通常來說，V&V 的時候，如果產品不是客戶一直盯著 Sales&BD 要的話，最常消失的角色就是 Sales&BD了。
   原因很簡單，因為要開會的時候，他們應該都不在座位上，這也沒辦法，畢竟 Sales&BD 多半心裡想的是往外抓訂單，那些什麼產品開發與製作根本不關他們的事，只要最後能拿出可以能讓他們賣的東西就可以了。
   但是要知道，開發團隊並不是神，也沒有通靈能力，他們不會知道客戶神明大人們，心裡真正想要的是什麼，唯一跟客戶有連結的是身為 Sales&BD 的你。
   如果開發過程中你從來不出現，那就等於是你坐在副駕駛座上，將方向盤交給矇著眼睛的司機開車，這樣就算前面要撞山了，也會帶著你一起撞下去。
4. 其他的商業分析師(Other BAs)：
   對，要找你親愛的 BA 同事們一起來背黑鍋，你背我背大家一起背。雖然我很想這樣幹，但畢竟大家都有各自的鍋子要背，所以就別害人了。
   既然鍋子每個人都有一頂，那麼大家當然都累得要死，每個人手上都有一堆資料、文件和市場要分析，有誰會真的有時間認真地幫你看案子？忙都忙不過來了，頂多會在第一或第二次 V&V 中出現一下，幫你看看有沒有缺少什麼，是你沒注意到的事情而已。然而，這種時候就可以看得出你平常的人緣好不好。
   如果你的人緣好，你會發現有些 BA 默默地拿出他的壓箱寶，幫你補齊某些資料或文件，甚至提點你一些角度和方向；如果你的人緣不好，就會看到他們笑笑地跟你說：「什麼都沒問題。」然後轉身就去做自己的事。
   雖然說不是絕對的啦，畢竟當個 BA 也不會要把心黑成這樣，但是如果遇到願意多幫你一些的同事，要嘛你上輩子的祖先有積德，不然他們一定是你的好朋友。
5. 專案經理/Project Manager：
   講了半天，終於講到一個真正會被要求負起責任、扛起成敗的人了。嗯？Product Manager 不用嗎？你想太多了，他們手上有那麼多產品，並不缺你一個。
   但如果他手下只有你一個產品，那你也不用想太多，因為你們是生命共同體，你的責任就是他的，他的責任還是他的，所以，只要做好你該做的，盯好你該盯的進度和團隊運作，其他事情就交給老天和代理吉祥物去煩惱吧。
6. 使用經驗設計師/UE：
   看到這裡，你也許會想：「UE 來 V&V 做什麼？來泡茶的嗎？」對，他來泡茶的，不過這個茶通常都不太好喝。
   通常來說，UE 在 V&V 出現的目的，是為了讓成果變得更合乎使用者的想法和需求，講得更直接一點，UE就是要來面對 Sales&BD 的挑戰的，但可惜的是，Sales&BD 通常都不會出現在 V&V 中，所以，既然沒機會可以談到客戶端的想法，那麼在 V&V中，多半沒有 UE 說話的空間，反而找的人多半是技術經理或主工程師。
   這時候我心裡都會幹樵著：「現在是來確認目前的成果，是否和使用者的想法一致，找技術的人來幹嘛？」
   你有發現這麼奇怪的狀況嗎？明明談的是確認需求做得對不對，但只要 QA 開始討論問題的時候，技術經理(或工程師們)就會開始解釋技術上為什麼會這樣，為什麼不會那樣。但是，現在談的是成果確認，不是技術，講那麼多技術根本幫不上忙，那是開發流程中的 Daily(Routing) Review 該做的事。
7. 主測試工程師/QA：
   講了老半天，真正的重點人物終於來了。在整個 Part 3–3 中，主測試工程師扮演的角色，就像是拿著十誡石板的摩西一樣重要。只要有這個石板，無論團隊有多少人走偏了路，看著石板上刻著的條文，就可以儘早地拯救路走偏了的羔羊們。嗯…話是這樣說啦，但想也知道「人在做、天在看」，再高明的天神也只有看著而已，不會下來做，因為是人要做、不是神。所以聰明的 BA，希望你會知道我接下來要建議些什麼，對，你是人，所以你來做。
   不過，先等等，這裡要你來做的不是去寫程式、挖大坑把自己埋起來，這裡講的是，你要在QA 摩西尚未公布十誡之前，偷偷趁著四下無人、無風、沒有鳥獸蟲鳴聲的夜晚，去找 QA 討論十戒的內容。
   你必須從整體思考每一個條文是否恰當，是否可以符合想要達成的效益，是否在團隊的能力範圍之內，PM 們是否會同意這樣的條文，甚至要帶著 PM 來跟 QA 做私下協商等等。
   這裡不是要你做黑的，是要你在非正式的場合，先把一切死板板的條文都先談好，就像談判會議前的寧靜時刻一樣，不可能沒有事情發生，只是大家都有默契不說話，而且要記得，談判，絕對不會是談完了一次就結束的事。

但是，我得在這裡特別提醒你，如果你是個要考 PBA 證照的考生，千萬不要在考試的時候，認為我說的是對的。請順著 PMI 的毛刷下去， PMI 說的是什麼就是什麼，他說是驗證與確認就是驗證與確認，畢竟 PBA 證照是 PMI 發的，不是我。