[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 帶你進廚房。「嗯?不是下地獄嗎?怎麼去廚房了?」嘖嘖,在職場上,如果碰到糟糕的事,第一個想到的絕對不要是「喔!X!這真是坨他X的大X搞出來的地獄爛泥巴!」
你該想的是「喔喔!又是該請客的時候到了。」
有經驗的你,這時候就知道為什麼不是下地獄,而是進廚房了吧?要知道,人都是愛吃的動物,沒有人會在香噴噴的美食面前拒絕你所有的要求,這也是為什麼台灣的熱炒店,會隨著經濟的景氣循環開了又關、關了又開的原因。
當然啦,這裡講的只是當你不小心踏到爛泥巴的時候,逼不得已的做法而已。接下來,要談的當然是如何讓你上天堂的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可能性:
  1. Requirements Baseline:對 Baseline 造成衝擊就會嚴重打亂所有工作的安排與進度,因此必須要非常小心。萬一發生的時候,就要馬上將造成影響的事件狀態掌握住。
  2. Conflicts with other Requirements:當 Requirements 互相造成影響時,往往都是已經進行到一半的時候才會猛然地發現這狀況,這時候最忌諱把眼睛矇起來繼續往下做,雖然我知道逃避是人性所趨,但你是 BA,別人不會把你當人看,所以你也別把自己當成是這麼有人性的生物看待(嗯?有人發現我講雙關語了嗎?)。要勇敢地面對 Conflict,坦然接受並認真處理它。
  3. Business Analysis:一但對商業分析的 Process 造成影響的話,想也知道就像生產線突然被雷打到一樣,在產線上的物料是沒壞,但是必須馬上停線檢查是否有哪些地方損害到無法正常運作。
    然而,你老闆不會答應讓你把產線停下來不走的,所以如果你帶著「等我確認一切安好之後,再繼續生產」的幻想,那還是快醒過來吧,你一定得冒著生命危險,在產線不停工的狀態下,非常低調且快速地在各種機器手臂間穿梭,趕緊找出並修好對 Process 影響的部分。
  4. 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 給我一些鼓勵:
為什麼會看到廣告
illustration
贊助支持創作者,成為他繼續創作的動力吧!
DK 耀尊
DK 耀尊
AGI人工智慧科學家 &商業與產品規劃顧問|分享關於策略思維、企業管理、商業開發、組織領導的知識與技巧,還有一些有點腹黑又真實的人性+人生經驗談。
留言0
查看全部
發表第一個留言支持創作者!
從 Google News 追蹤更多 vocus 的最新精選內容