靠著一張表就期望能追蹤所有的需求，就好像吃了臭豆腐，還覺得很香一樣。是真的，但也是一種幻覺。
身為一個 BA，最重要的職責真的不在於挖掘需求，因為你怎麼挖都一定會歪掉，因為你再怎麼挖，需求一定還會有變化。
這是因為並不是你一做完分析之後，Business Needs 就會在那邊靜悄悄地不動等著你提供 Solution。你必須抓緊時間，在地球自轉還沒停止之前，持續地追蹤、維護、更新並且選擇性地放棄某些已不符合當下 Needs 的需求，而且更必須持續向 Team Member 溝通所有被保留、被更新甚至是被放棄的需求的必要性。
為什麼要這麼費功夫做這件事就不用我多講了吧？你可以選擇不做，然後等著背後莫名其妙中了無數隻黑箭，還以為自己很受歡迎，大家都聽你的話、對你很好。
為了協助 BA 能夠更好地扮演背後插箭的角色也許 PMI 在設計 PBA 證照的時候，受到某種神聖的感召，而在 Chapter 5 (Domain 4，簡稱 D4) 中，花上一整個章節專門在講如何利用一張 Requirement Traceability Matrix(簡稱 RTM) 來做需求追蹤，彷彿 RTM 是個給 BA 的指南針，讓團隊可以在汪洋大海中，靠著作戰計畫(Documents)的指引，一步步地往目標前進。
如果你要這樣想，我也不反對，但別到時候來跟我哭說：「為何不早跟我講其中的秘密。」，因此，依照我寫文章的套路，想也知道前面講得這麼正經一定是在鋪梗。
沒錯，上面這幾段文字都只不過是個梗而已，因為在管理 Requirement 的時候，最重要的根本不是那張 RTM，而是你如何和 Team Member、Stakeholder 溝通 Requirements 的順序、資源的分配，以及增刪修各種需求所需花費的時間和精力。
做出 RTM根本不是重點，如何管理需求變更才是 BA人生中最重要的事。
說真的，其實這篇文章已經寫完了。如何管理變更還需要我講嗎？大家都是成年人了，喝酒、抽煙、吃飯、打屁、八卦、顏值勝…請拿出你的看家本領，在各方的豺狼虎豹還沒把你吞掉之前，跟大家搞好關係，讓所有人信任你是有本事應付各式各樣變更的。
說穿了，在 D4 中講的 RTM 其實根本沒有一個固定的樣貌。雖然的確可以參考 P.140到 P.141 中列出來的屬性，但在不同公司都會有不同的屬性需要管理，即使那些新增的屬性不一定有用，但老闆要你死，你不得不死…
不同文化有不同的 RTM，因此簡單來說，好的 RTM 帶你上天堂，壞的 RTM 帶你進廚房。「嗯？不是下地獄嗎？怎麼去廚房了？」嘖嘖，在職場上，如果碰到糟糕的事，第一個想到的絕對不要是「喔！Ｘ！這真是坨他Ｘ的大Ｘ搞出來的地獄爛泥巴！」
你該想的是「喔喔！又是該請客的時候到了。」
有經驗的你，這時候就知道為什麼不是下地獄，而是進廚房了吧？要知道，人都是愛吃的動物，沒有人會在香噴噴的美食面前拒絕你所有的要求，這也是為什麼台灣的熱炒店，會隨著經濟的景氣循環開了又關、關了又開的原因。
當然啦，這裡講的只是當你不小心踏到爛泥巴的時候，逼不得已的做法而已。接下來，要談的當然是如何讓你上天堂的RTM啊。
好的 RTM 有兩種(就像老梗有兩種！)，一種給老闆看的，一種給團隊看的。
給老闆看的，當然是盡量精簡、取大項目，每個 Requirement 都要能夠連結到它創造出來的 Business Value，不連上你就等著死；
給團隊看的，要仔細安排好每個工作的邏輯關係，以及所需用上的資源(人力、時間、材料等等)，至於 Business Value 就不必太過著墨，把眼前的工作完成才是團隊該做的事。
但是絕對不是叫你不要寫，你必須要能將該項工作所產生的 Business Value ，和負責該項工作的成員所期望的成就連結在一起。雖然這聽起來很像是 PM 該負責的工作，但實際上 BA 在其中扮演的是透過文件與低調陪伴的方式，弭平所有可能的紛爭。
於是乎，RTM 在順利地 Approval 之後，你才能憑藉著 Requirements Baseline 讓 Team Member 有個可以實際開始工作的依據。
然後，工作就可以順利展開了嗎？不，哪有這麼簡單。我假設你是真切地活在世界上，而不是在幻想空間裡，想像著事情就這麼順利地下去。
別忘了，世界在變化、企業也在變化，需求怎麼可能會不變化呢？更何況，那搞不好一開始就是你的錯，是你搞錯內容，而且還不小心被 Approval 了。因此，你必須一直監視著所有的變化，是的，監視就好，不要手賤想去控制它。
雖然話說如此，但在台灣的你應該是PM+BA(甚至還是 Tech Leader)，所以你還是得去控制變化的程度，也就是說你必須在 BA 和 PM 的角色中取得平衡，以及清楚地認知每種角色的不同與變化時機。
如此一來，才能夠在不同的 Requirement Life Cycle (BAG P.149)中，順利地轉換角色，並且協助 Team Member 在不同 State 下順利完成、暫停或放棄手頭上的工作。
但無論你用什麼方式管理需求變更，都要記得分析 Change 可能會造成的影響，以及要讓這個影響別對整個專案衝擊過大。
因此，你要隨時檢查 BAG P.152 和 P.153中列出來的四個 Impact可能性：
- Requirements Baseline：對 Baseline 造成衝擊就會嚴重打亂所有工作的安排與進度，因此必須要非常小心。萬一發生的時候，就要馬上將造成影響的事件狀態掌握住。
- Conflicts with other Requirements：當 Requirements 互相造成影響時，往往都是已經進行到一半的時候才會猛然地發現這狀況，這時候最忌諱把眼睛矇起來繼續往下做，雖然我知道逃避是人性所趨，但你是 BA，別人不會把你當人看，所以你也別把自己當成是這麼有人性的生物看待(嗯？有人發現我講雙關語了嗎？)。要勇敢地面對 Conflict，坦然接受並認真處理它。
- Business Analysis：一但對商業分析的 Process 造成影響的話，想也知道就像生產線突然被雷打到一樣，在產線上的物料是沒壞，但是必須馬上停線檢查是否有哪些地方損害到無法正常運作。
然而，你老闆不會答應讓你把產線停下來不走的，所以如果你帶著「等我確認一切安好之後，再繼續生產」的幻想，那還是快醒過來吧，你一定得冒著生命危險，在產線不停工的狀態下，非常低調且快速地在各種機器手臂間穿梭，趕緊找出並修好對 Process 影響的部分。 - Project Management：當對 Project Management 造成衝擊的時候，別傻傻地侵門踏戶搶了 PM 的工作。那是 PM 的工作，不是 BA 的…啊！我忘了你八成也是 PM。(拍肩)
但是你知道的，BA 的工作就是要低調，不能搶了 PM 的風頭，而且還要在衝擊發生的時候，提供充滿智慧與可行性的行動建議方案給 PM，讓他們去做出決定並執行它，然後建議方案還要顧及不能造成新的問題或缺陷，這時候，老闆對你的期待通常會補上一句：「想要馬兒跑，也要馬兒不吃草。」你以爲老闆會多給你資源去做嗎？別癡心妄想了，快回到地球上來吧你。
不合理嗎？對，BA的工作就是在所有不合理中，找出一條看似合理的道路。
還要在不確定腦袋正不正常的 PM 帶領下，陪著 Team Member 上刀山下油鍋，而且直到 Solution 完成並上線的那一刻為止(和之後，D5會談到)，你都不是主角，甚至連配角都算不上，你只是個萬能場務，對，就是那個從來沒出現在鏡頭前，甚至是在沒人可用的時候，偶爾跑跑龍套、當當屍體、湊個背景的角色而已。
對，你就是BA，穿梭在煙硝砲火之間管理著需求變更，榮耀的BA。(淚)
如果這篇文章你想用聽的，可以在這裡找得到：
https://www.ears.tw/sounddetails/1748
如果你覺得這篇文章不錯，值得拍拍手，可以拍五下 Like 給我一些鼓勵：
