更新於 2019/08/05發佈於 2019/08/05閱讀時間約 10 分鐘

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

Domain5

下結論很容易，下對結論就沒那麼容易。

當你看到天堂大門就在你面前的時候，千萬不要太緊張，也不要太興奮，因為，你還只是到達這個充滿光輝的大門面前，還沒有踏進門內任何一步。

人生中第一次結案，已經是遙遠的 1995 年的事了。還記得那個時候，年輕氣盛的我差點被那個案子搞到想要直接放棄不結案了，但是為了錢，對，沒錯，就是為了爭那一口氣所要拿的錢，我不得不耐著性子，繼續跟客戶玩下去。

還記得第一次帶著幾張裝著資料的 3.5 吋磁片，去客戶辦公室安裝的時候，是在客戶公司的下班時間，由客戶的工程師帶著我進去，印象中整個辦公室裡只有副總和工程師在而已，其他人下班的下班、吃飯的吃飯。

磁碟機喀嗤喀嗤地 copy 著切割的壓縮檔，一片一片地複製完之後，準備要解壓縮了，由於為了節省檔案的大小，我習慣用多重壓縮，也就是ARJ+UC2，所以解壓的時間也比較久，比較麻煩一點。安裝完之後，打開了網站，副總眼睛一亮。雖然是小小的五頁網站，但這是他第一次看到有稍微設計、排版過的公司網站。

以現在的角度來看，簡直和初學者的程度差不多，但在當時，其實很多公司就只要這樣就夠了。副總看了很高興，交代工程師要把網站放到公司的電腦去，簡單握握手，說了謝謝，他就離開辦公室去忙了，只剩下我和工程師兩個人對望著。

說實在的，既然副總都覺得沒問題了，那就沒事了吧？於是我簡單地跟工程師聊了一下之後，東西收了收也就離開了，但我沒想到這一轉身，才剛是這個結案的開始。

看到這裡，我想有經驗的你應該不用我多說，後來究竟發生了什麼事？我想，我就不用在這裡賣關子了，後來隔了一個月又開了一次會，開始提出一堆問題，還有想要增加的東西，而且重點是老闆不想再多花錢。然後，經過中間許多的紛紛擾擾之後，隔了兩個月才真正簽下那個結案同意書，然後又隔了六個月之後才付款給我。

這中間的各種勾心鬥角和藉故拖延，真的是讓我開了眼界，直到後來和更有經驗的朋友做事之後，才發現當時我做錯了什麼，花了多少白費的功夫在無用的事情上面。

而這些事，其中一部分就是今天這篇文章要講的內容，也就是 PBA 的 Domain 5。

Part 5：評估產出 (Evaluate Deliverables)

在這個階段中，重點其實不在你規劃得有多好，或是盯得有多緊，而是你合作的人是否能夠在你背後挺你到底，而且對客戶或是老闆的角度來說，這個階段就是要驗證成效的階段，他們心裡想著的是：「你最好給我拿出些好東西，不然你就不好過了。」

如果你平常的做人處事不夠好，或是太過搶眼讓你的光芒刺傷了別人眼睛的話，這個時候就真的要小心注意，千萬不要有哪些事沒做仔細而落人話柄喔。接下來，讓我們來看看這個階段會遇上哪些...好人們吧。

最高主管(執行長/總裁/部門主管)Master Manager：這次他終於不是個吉祥物了！反而是在這個階段中，扮演著最重要角色的決策者，他必須根據所有的階段性報告、測試報告、業務報告、客服報告...等等的資料，總結出是否允許最終的產出要交給客戶，或者是上架開賣，亦或是開始在內部採用之類的決定，不同的產品或解決方案，都有不同的後續進行方式，吉祥物...不，決策者必須要在這個時候，勇敢採用或是拒絕下面這些人的評估報告，來決定後續該怎麼做。
業務/商業暨產品開發/Sales＆BD：如果是要交給客戶或者上架開賣的產品或解決方案，Sales&BD 一定會在這時候出現，畢竟這是跟他的身家安全息息相關的階段，他必須親身了解究竟最終產出，是否符合客戶的需求，因為他是面對客戶的唯一防線，如果搞砸了，客戶幹樵的人不會是研發單位，而是讓 Sales&BD 在客戶辦公室裡，罰站被罵到臭頭也不一定能夠全身而退。所以，這麼重要的事怎麼可以不出現？
行銷/社群經理/Marketing：如果是內部系統，行銷不一定有出現的必要。如果是客製化產品，則要看客戶端的合作是採取哪一些方式，後續是否有相關的推廣計畫。但如果是上架開賣的產品，則就關係大了...在這個階段中，Marketing 的人就要開始注意各個評估成果，甚至是在規劃評估方式之前，就要提早參與規劃，以便在進行評估的過程當中，盡快取得可以用來製作做行銷的內容，千萬不能等到產品最終評估結果出來之後，才在一堆資料中試著尋找可用的素材，拼拼湊湊地以為這樣就可以說服客戶買單？這是不可能的事，就算做到了也是運氣好，或是這個產品一開始的規劃就在市場的風口上，風吹來了豬也會飛，但那是豬自己的功勞，不是 Marketing 的。
產品經理/Product Manager：產品或解決方案終於到了最後階段，整個產品的主負責人怎麼可以不出現？身為吉祥物代理人的產品經理，這時候要扮演的更像是吉祥物助理的角色，而不是代理人，畢竟 Master Manager 自己就已經出席這個階段的會議了，助理當然是要在旁邊盡量提供可以輔助決策的資料，讓 Master Manager 能夠快速地在腦中建立起決策結構，並且爽快地畫押。嗯？看到這裡的時候，不知道有沒有人發覺我講了某個黑暗的手法？如果沒發現，就回頭上去再仔細看一下，對，你這麼聰明怎麼可能看不出來，Master Manager 通常都是大忙人，怎麼可能有辦法對單一的產品或解決方案瞭解得夠多，還能夠下正確的決策？這都是因為產品經理身為吉祥物助理時，需要有意識地整理出一整套符合邏輯順序的資料，透過這份資料逐步在 Master Manager 的腦袋裡建立起特定決策的邏輯。於是乎，Master Manager 才能在感覺很爽、邏輯很清晰、證據很可靠的情況下，快速而且充滿信心地做出決策，而且不會發現其實是產品經理做的決定。
專案經理/Project Manager：這是個產品經理的幫凶...不是啦，沒這麼嚴重，專案經理的角色在這階段中，其實比吉祥物還更吉祥物，原因很簡單，因為在這階段裡，評估計畫不是他做是 BA，雖然說在台灣，PM+BA 是很正常的事，但我們要切開來說，才能將職責談得更清楚。整個評估計畫開始執行的時候，QA 反而扮演著更重要的角色，所以，我們在這個階段中，千萬要想辦法不讓 QA 出現在最後的評估會議中...為什麼這麼重要的角色反而不讓他出現？孩子，你別傻了，對 QA 來說，產品永遠沒有完美的一天，如果你讓他出現，那不就是拿石頭砸自己的腳？你要做的是在需求追蹤、V&V 的階段就將 QA 搞定，讓他們在最後的評估計畫和執行中，完全沒有任何的抱怨和問題，這要怎麼做？很簡單，就是在還沒進入產出評估階段之前，就將所有應該用在評估階段該做的事，全都在 V&V 之前做完，並且拿那些成果到評估階段來用。更簡單地說，就是評估產出的所有工作和數據，全都在之前都做完了，不會放到這個階段來做，這個階段做的評估，其實就是之前做了無數次的相同結果。
客服人員/Service ＆技術客服工程師/FAE：在這個階段中，大部分的公司或團隊，並不會想到要找客服人員或技術客服來參與，我想這樣做也不一定不好，但是反而會拖慢了後續的產品上線進度。所以，找客服或技術客服有什麼好處呢？其實，他們在這個階段參與的時候，可以在評估計畫中看到客戶可能會問什麼問題、會發生什麼事、預期可以怎麼處理，於是，他們可以提早做好各種準備和訓練規劃，以便在產品上架開賣之後，可以應付客戶各式各樣、奇奇怪怪的問題。
關鍵使用者/Key Users：最後一個重要角色當然就是 Key Users 啦，一個產品或解決方案要結案怎麼可能沒有客戶的人參與？不，這裡講的不單只是客戶的人，而是產品或解決方案的終端使用者，找來的人最好是每天都會用到它的人。為什麼找他們來，這應該不用我多說，因為只有他們點頭，Master Manager 才敢真正的簽下那個字，客戶也才敢真正地安心付錢，Sales&BD 才會真的放過研發團隊不再去煩他們，產品經理才能夠鬆了一口氣...嗯？真的嗎？產品經理真的能在這種時候鬆一口氣？真的別傻了，事情還沒結束呢，通常在 Key Users 來看過、用過、試過之後，不論產品或解決方案做得再完美，他們都還是會提出一些問題和新需求來，這並不是他們吹毛求疵，而是他們也有從上面來的壓力，如果都說好話，那不免會被懷疑是否跟廠商串通好了，所以，再怎樣也要提出一些問題來。所以呢？身為 BA 的你，一定要在最後評估階段之前，就先跟客戶端的 Key Users 混熟，這也是之前教你要和 Salse&BD 到客戶端的原因，先弄熟、串通好...對，你沒看錯，這個世界就是這麼樣的黑暗，我們要先跟 Key Users 先串好要講什麼事情、要挑哪些問題。雖然這樣講得好像非常的 under table，有些正義魔人可能還會覺得這樣不可取，但這世界是真實且殘酷的，你不先把這些問題都事先串好，你只會在這個階段的最後滑上一大跤。但這裡要你去串通的並不是什麼賄賂、關說之類的手段，而是要你事先就要了解 Key Users 的難處與目標，並且幫他們想好所有的解套方式，讓彼此都能夠好做事，事情才能夠圓滿地結束，甚至能夠順利地繼續合作下去。