這是因為並不是你一做完分析之後,Business Needs 就會在那邊靜悄悄地不動等著你提供 Solution。你必須抓緊時間,在地球自轉還沒停止之前,持續地追蹤、維護、更新並且選擇性地放棄某些已不符合當下 Needs 的需求,而且更必須持續向 Team Member 溝通所有被保留、被更新甚至是被放棄的需求的必要性。
給老闆看的,當然是盡量精簡、取大項目,每個 Requirement 都要能夠連結到它創造出來的 Business Value,不連上你就等著死;
給團隊看的,要仔細安排好每個工作的邏輯關係,以及所需用上的資源(人力、時間、材料等等),至於 Business Value 就不必太過著墨,把眼前的工作完成才是團隊該做的事。
但是絕對不是叫你不要寫,你必須要能將該項工作所產生的 Business Value ,和負責該項工作的成員所期望的成就連結在一起。雖然這聽起來很像是 PM 該負責的工作,但實際上 BA 在其中扮演的是透過文件與低調陪伴的方式,弭平所有可能的紛爭。
於是乎,RTM 在順利地 Approval 之後,你才能憑藉著 Requirements Baseline 讓 Team Member 有個可以實際開始工作的依據。
Conflicts with other Requirements:當 Requirements 互相造成影響時,往往都是已經進行到一半的時候才會猛然地發現這狀況,這時候最忌諱把眼睛矇起來繼續往下做,雖然我知道逃避是人性所趨,但你是 BA,別人不會把你當人看,所以你也別把自己當成是這麼有人性的生物看待(嗯?有人發現我講雙關語了嗎?)。要勇敢地面對 Conflict,坦然接受並認真處理它。
Business Analysis:一但對商業分析的 Process 造成影響的話,想也知道就像生產線突然被雷打到一樣,在產線上的物料是沒壞,但是必須馬上停線檢查是否有哪些地方損害到無法正常運作。
然而,你老闆不會答應讓你把產線停下來不走的,所以如果你帶著「等我確認一切安好之後,再繼續生產」的幻想,那還是快醒過來吧,你一定得冒著生命危險,在產線不停工的狀態下,非常低調且快速地在各種機器手臂間穿梭,趕緊找出並修好對 Process 影響的部分。
還要在不確定腦袋正不正常的 PM 帶領下,陪著 Team Member 上刀山下油鍋,而且直到 Solution 完成並上線的那一刻為止(和之後,D5會談到),你都不是主角,甚至連配角都算不上,你只是個萬能場務,對,就是那個從來沒出現在鏡頭前,甚至是在沒人可用的時候,偶爾跑跑龍套、當當屍體、湊個背景的角色而已。