商業分析最重要的不是看數據說話,而是沿著人性的毛順順地摸下去。
好多年前的某個夜晚,大約半夜 12 點多的時候,我獨自一個人坐在公司 8 樓夾層的大會議室窗戶旁邊,看著窗外的街道,靜靜地抽著煙。
這時候,產品團隊的主工程師默默地走了進來,看了看我,點起一支煙,若有所思地坐在沙發上靜靜地抽著。幾分鐘後,另一個部門的技術經理和手下幾個主工程師說說笑笑地進來了。
他們談天說笑著,過沒多久,負責公司主產品的兩個專案經理也來了。
從他們臉上的表情來看,似乎沒想到這大半夜的,還有這麼多人聚在這裡抽菸聊天,於是原本靜悄悄的大會議室,頓時變成全公司最熱鬧的地方。
聊天的聊天、八卦的八卦,偶爾穿插幾句技術上的問題和討論。
我看了看錶,嗯,半夜 1 點鐘了。
如果上面這個場景,是你的日常生活的一部分,那麼也許你會瞭解接下來我要談的是什麼事,沒錯,這個系列終於來到第六篇了,這是擁有著最多不可見人的黑暗手法的第六篇。
是的,在這個場景中,你看到的幾乎都是研發單位的人,少數的例外是身為部門主管的我和兩個專案經理,當然啦,這並不是說我們天天都在這樣的煙霧瀰漫裡度過,而是當我們需要協商、討論的時候,這樣的場景多到變成我們的日常生活。
Part 4:需求監控與追蹤 (Monitor and Trace Requirements)
現在,我們來到了 PBA 證照中,稱之為 Domain 4 的需求監控與追蹤(Monitor and Trace Requirements)階段,在這個階段中,最重要的工具其實就只有那張開發功能表,或以 PBA 的術語來說,就是 Requirements Traceability Matrix,簡稱 RTM。
RTM 上面羅列著整個產品的各項功能,以及每個功能所需知道的事,包括開發現狀、負責人、交互關係、時程、工具和資源等等。而有些團隊也會用甘特圖來取代它,但基本上不論是哪一種型態,RTM 就是一張提供給研發製造單位的產品功能清單。
我們依賴著這張清單的指示,盡可能地以正確的順序和不太準確的時間估算,與各種單位「通力合作」完成所要達成的目標,對,這裡講的是目標,不是產品或解決方案。
原因很簡單,因為在多數工程師的眼中,其實並沒有產品或解決方案的存在,全都只有專案經理交派給他們的任務,而這個任務就是一條條的功能清單。而我們身為 BA 的責任,就是要協助 PM(Project Manager)對每個功能的開發現狀以及負責每個工作的工程師,有最清楚、最新的掌握和瞭解。
話說回來,其實這階段中,我們需要互動的關鍵人物都很簡單,但也都很困難,這是什麼意思呢?因為,雖然這裡要面對的人不多,但是大多數人都會在給你出了一堆難題之後,雙手一攤,要你去幫忙想辦法。
所以,接下來就讓我們看看,究竟有哪些關鍵人物在這裏作怪吧。
- 專案經理/Project Manager:
每次在這個階段的時候,我都覺得專案經理是一個最無助的人,因為要開發的功能通常都不是他想做的,他想做的通常也都不在這些功能中。
但是,因為他掛著 PM 的頭銜,所以得盯著整個任務順利進行。通常在整個團隊裡面,PM 手下的那群妖魔鬼怪通常能力都比他強,講的話又常常讓人摸不著頭緒,所以,專案經理當久了之後,如果沒有瘋掉,那快變成妖魔鬼怪了。
所以呢,看開點,我們要保持樂觀的心情。 你想想,既然 PM 遲早要變身,那當然就要提早做好準備,學習他們用的語言、說話方式和內容,才能在開發的過程當中,逐漸地融入這個群體,用無盡的愛和容忍的心,在抽煙、吃飯、下午茶之間,逐步感化這群鬼怪,讓這些鬼怪把你當作為他們打拼的同伴,在彼此的信任與信心建立之下,他們將會為你用盡生命的火花,在老闆的關愛眼神之下,順利地如期將功能交出來。
- 使用經驗設計師/UE:
UE 在開發的過程中,必須和產品經理、專案經理、架構設計師、UI以及主程式設計師們通力合作,也就是說如果功能有任何的狀況,都必須找 UE 來討論,並且在盡量不變動現有架構的情況之下,尋求解決方案。
所以,我們要將 UE 和工程師的距離拉近,將他們拉在一起做事,而不是當 UE 交出設計藍圖(UX)之後,就什麼事都沒有了。
- 視覺設計師/VD/UI:
UI 在這裏扮演的角色,可能會超乎多數人想像中的重要。因為,在開發的過程當中,會因為產品逐漸地成型,而發現視覺上的設計可能東缺一塊、西漏一點。
如果有客戶或是 Sales&BD 在 V&V 的時候,發了神經想多加一些功能、修改一些樣式和顏色,或者是多說了一句:「這裡可不可以做成像某某程式那樣的動畫效果?」如果發生這種情況,我想多數 UI 和工程師應該都想拿起榔頭,往客戶或 Sales&BD 頭上敲下去。
但是,我們是文明人,絕對不能讓衝動取代了我們的理性,而是要先微笑著點點頭,跟他們說:「先讓我們想想看能不能做。」 在這種關鍵時刻,千萬不能讓把這句話的意思誤會成「可以做,我們試試看。」而是一定要再三強調、暗示、明示:「除非多給點時間、多給些錢,否則做不到。」
要知道,客戶或 Sales&BD 最愛說的一句話就是:「別人都做得到,為什麼你們做不到?」
話說,這也沒辦法,客戶是神,他們都以為只要甩甩手指就能做到所有的事,他們不是人,所以不懂得人要多麽地辛苦,才能打造出他們想要的產品。
- 技術經理/架構設計師/SA&PL:
接下來,我們第一個會撞到的鋼鐵牆壁,就是這位仁兄或大姐了。因為在監控追蹤需求現況的時候,他多半都是站在我們和工程師之間的那道鐵板,而且非常不願意讓我們知道,目前工程進行的真實現況。
有些人可能會覺得奇怪,不都是同一個團隊的人,幹嘛阻擋我們瞭解真實情況?有問題的話,這樣我們才能想辦法幫忙啊。
但是,對於技術經理來說,他就像是整個技術團隊的頭,他代表的是團隊的技術與能力指標,如果底下的工程師技術不夠好,你認為他會讓你知道嗎?如果底下的工程師技術比他好,你也認為他會讓你知道嗎?別傻了。
所以,當你想探詢工程進度的時候,通常他就會像一座大山一樣跳出來擋在你面前,告訴你一句:「有什麼問題問我就好,別來吵我們的人。」然後我們就只好摸摸鼻子,偷偷地轉向另一個地方去問…
- 主測試工程師/QA:
沒錯,因為剛剛在大山旁邊碰了一鼻子的灰,所以我們直接轉到另一個他管不到的世界來問,那就是 QA 部門。
一般來說,研發和 QA 部門常常是死對頭,因為一個是負責開發產品、一個是負責挑開發的毛病,對研發單位來說,QA 是拖著他們進度後腿的討厭鬼,所以,怎麼可能會和平相處? 所以,既然我們在研發部門撞上了一座大山,那當然不是浪費時間挖出一條隧道穿過大山。那樣也太累了,我們只需要轉個彎,從山邊爬過去來到 QA 部門就好。
講到這裡,如果你是 BA,請記得我一個建議,你一定要和 QA 的所有人都搞熟、搞好關係,如果你是 PM,就更要如此,因為 QA 將會是你瞭解現狀的最佳夥伴。
不管是在 Daily Review、Retrospective 還是 V&V,所有的測試結果全都在 QA 這裏進行,我相信不會有任何一家腦袋正常的公司,會將測試的工作也交給研發部門自己管理才對,畢竟,球員兼裁判的結果一定會搞砸整場比賽。 當然啦,話雖如此,但要打進 QA 的世界並沒有那麼簡單。
你必須從測試部門主管或主測試工程師下手,然後一步步地,讓他們了解你是真的關心東西的品質好壞,也關心這些功能是否符合需求和企業目標,而這些也全都是 QA 關心的事。
你要知道,QA 在大部分公司裡都是被人嫌棄的邊緣單位,但這個邊緣單位通常都掌握著研發部門的生死關鍵,所以你不跟他們搞好關係,要跟誰搞?
在這個階段中就是要和以上這五種人打交道,其實說穿了,就是設計、研發和QA部門。在這裏,我們比較少看到 Master Manager 和 Product Manager 出沒,因為吉祥物通常都喜歡乾乾淨淨的,不想到現場把自己的手弄髒。
但也就是因為這樣的原因,身為喜歡研究、探索真理的 BA,必須代替吉祥物們和專案經理,瞭解真實的現況,從別人看不到的地方,對設計、研發和 QA 部門下手。
之前曾經說過,這個階段充滿著不能說出口的黑暗手法,不知道你有沒有從我上面幾個人物介紹中,嗅出一些味道來?如果沒有的話,也不用擔心,你只要知道下面這幾件事:
- 和 PM 交手的時候,請幫助 PM 學習妖魔鬼怪用的語言,讓他聽得懂、也會說個幾句,這樣才能讓他不至於被妖怪吞沒。
- 和 UE 作伴的時候,請幫助他不要被工程師妖怪們洗腦,而設計出一個又一個不屬於當下產品的功能和操作流程。
- 和 UI 遊蕩在想像空間的時候,請幫助他不要被 Sales&BD 和吉祥物們的天馬行空打擊得太深,太極拳將會是你幫助 UI 的最佳幫手。
- 撞上技術經理這座大山的時候,請和他們笑一笑、揮揮手,然後在山邊燒上精油,香氣環繞,目的是為了讓他覺得輕鬆自在,感覺我們沒有威脅。
- 潛入 QA 這個幽暗空間的時候,請相信你可以保持樂觀的心情,不要被 QA 在檢測品質時,散發出的怒氣打破防護罩,而是幫助他們瞭解這些問題、錯誤,和不知道怎麼發生的怪異狀況,都只是神蹟的一部分,目的是為了帶領產品或解決方案飛上天堂。
對,我們現在仍然走在邁向天堂的路上,距離終點還很遠,必須跨過好幾座 V&V 的山峰,押著吉祥物獻出他們的手指,簽下那個血淚的 Approval,我們才能夠得到解脫,才能夠從這個隨時要確認目標正確性和企業價值達成性,也要在時程與能力的範圍內,激發出最大成果的終極挑戰中存活下來。
當我們幸運地活下來之後,才終於能夠活著抵達最終的天堂大門,那就是即將迎來解脫(?)的「評估產出 (Evaluate Deliverables)」階段啊。
如果你覺得這篇文章不錯,值得拍拍手,可以拍五下 Like 給我一些鼓勵: