[D4] 當你不小心踏入PMI-PBA的陷阱之後，要知道你的本分不是挖掘也不是管理需求。
2019/07/24閱讀時間約 8 分鐘
靠著一張表就期望能追蹤所有的需求，就好像吃了臭豆腐，還覺得很香一樣。是真的，但也是一種幻覺。
身為一個 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 在其中扮演的是透過文件與低調陪伴的方式，弭平所有可能的紛爭。
給團隊看的，要仔細安排好每個工作的邏輯關係，以及所需用上的資源(人力、時間、材料等等)，至於 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
https://www.ears.tw/sounddetails/1748
如果你覺得這篇文章不錯，值得拍拍手，可以拍五下 Like 給我一些鼓勵：
為什麼會看到廣告
留言0
查看全部