商業分析真的沒那麼難,只要你在對的時間找到對的人(4/7)

2019/07/29閱讀時間約 10 分鐘

開發會議不是重點,重要的是開完會之後有沒有照著結論做。

Part 3–2:開發過程中的圖像化溝通 (Models)
從第一次參與開發會議以來到今天(2019),不知不覺已經過了20幾個年頭,沒有感嘆歲月如梭,也沒有撚著白髮蒼蒼的蹉跎,唯一不變的仍然是沒有效率的會議和互相指責的場景。
如果你在開發會議的時候,面對的是同樣的場景,那麼恭喜你,你也是 80/20法則當中的那個 80%,而且這樣的場景除非你自己做出改變,不然永遠都不會變得陌生。
在生涯中,經歷過無數次的開發會議,其實已經想不起來有哪個比較特別可以挖出來寫的,但無論是在小公司或大公司,開發會議永遠都離不開幾個必經的過程:
  1. 開場
    通常是由 PM 喊聲,然後有老闆在的時候,底下的團隊成員多半已經在會議室坐好在那裡等;沒老闆在的時候,底下的團隊成員多半還在自己的座位上等 PM 叫。
  2. 人物介紹
    如果都是自己人,介紹就免了,直接進入喊聲的主題。但如果是跨部門而且彼此都不熟的,那就一個個介紹,別隨意跳過任何一個人,因為你永遠不知道被你跳過的那個或那些人以後會怎麼搞你。
  3. 進入主題
    如果是有經驗的 PM,就會在短暫寒暄過後(Just say HELLO),馬上說明今天會議的時間長度以及要達成的結論,有時候會多講一些現況背景,但通常開會到一半都會被忘光光,然後又得重講一次,所以我勸你還是別浪費時間。這時候你可能會問,只講長度和要達成的結論,那主題呢?目標呢?準備好要問的問題呢?在實務上,我會勸你把這些通通都忘掉…
    叫你忘掉的意思不是要你別準備,而是相反地你一定要準備,但是不用在開會的時候提這些事,因為整場會議中唯一在乎有沒有達成目標、做出結論的人,大概只有你一個。
  4. 開始朝結論前進
    咦?怎麼這麼快就要跳結論啦?其實,在開會的過程中,如果你心裡面不先有個定案,帶著開放的心態在這個主軸上討論的話,到最後整個會議只會變成聊天大會或者是究責大會。
    所以,會議中身為 BA 的你,要手拿青龍偃月刀,摸著大鬍子坐鎮在 PM 旁邊,隨時提供可以佐證的火力給 PM ,去掃射一堆根本沒在聽你說話的人。
    雖然,開會的過程中,四處的砲火猛射是正常的,但不管開發會議是要做成什麼樣的解決方案,BA 一定要耐住性子聽取各方的意見,並且相信這些意見都不是針對你而來,只有做到置身事外…不是,是立場客觀,你才能夠好好地從每次的開發會議中存活下來。
    不然,會議不只可能會讓憋尿憋到住院,甚至還可能害你心臟血管爆裂,所以,唯有廣納意見的 BA 才能夠成為真正的 BA。
  5. 達成結論
    握握手、聊聊天,那我們就這樣做囉!結案。你想,有可能這麼簡單嗎?通常在開發會議中達成的結論,都是各方角力和進退取捨之中得到的,那麼你想想看,在開發的過程中,能力越強的是否通常都會有所堅持,但卻都在會議上不願意說出口。沒碰過?那你真的很幸運有個好團隊。
  6. 追蹤結論
    接續著第五個項目談到「不願意說出口」的人,你得在會議之後,日常在追蹤結論執行狀況時,隨時注意是否有人勉強自己順著結論做事,說實話,這個項目不應該放在開會的流程之中,而是應該放在日常的管理活動當中,不過,為了避免你一不小心忘記這件事,所以我還是把它列上來,因為這個項目是整個六件事中,最重要的關鍵。開會真的不是重點,是否有照著彼此的共識和結論做事,才是重點中的重點。
而這個重點中的重點,就是這篇文章真正想談到的事情,那就是在開發會議的時候,該找的關鍵人物有哪些?
  1. 產品經理/Product Manager:
    負責接替 Master Manager 成為吉祥物的存在,除此以外沒別的作用了,通常他只在出現需要畫押的時候。
  2. 專案經理/Project Manager:
    負責敲鐘開會、拉著以下的人離開椅子進會議室的人,PM 最常幹的事就是一邊鋪著新軌道,一邊想辦法讓大家照著原來的軌道做事。
  3. 使用經驗設計師/UE &視覺設計師/VD/UI:
    在「商業分析真的沒那麼難,只要你在對的時間找到對的人(2/7)這篇文章中講過,在開發會議的時候,角色和負責的內容依然沒變,算是滿幸運、總是能避開砲火的一群人。
  4. 技術經理/架構設計師/SA&PL:
    負責坐鎮在會議中,聽著手底下的 RD 們談論技術內容,並適時地和 PM 勾結串通好,導正會議方向的人。你沒看錯,事實上,整場會議要能順利進行,PM 就是要先和 SA 或 PL 勾結串通好。
    因為在大部分的情況下,他們都是團隊 RD 們眼中的神明大人,當會議中吵得鬧哄哄的時候,神明站出來的目的不是要教化世人,而是用他們背後的光芒閃得所有人睜不開眼睛,然後就會安靜下來了。
  5. 前端主程式設計師/SD&PL:
    負責前端介面的程式架構設計並打造主程式架構程式碼,有些公司SD和SA是同一個人負責。當軟體的架構簡單時,這樣的好處是可以節省SA和SD的溝通時間以及設計的連貫性。SD必須要和SA非常緊密地合作,才能將產品的優勢透過所掌握的程式語言發揮得淋漓盡致。
    當產品逐漸發展得越來越大之後,軟體的架構將會逐漸地根據技術經理、產品經理的規畫而越來越大。這種時候SD應該抽離SA的範圍,交由更深入了解所使用的程式語言特性的工程師負責,才能讓產品的強固性、發展性與彈性能夠發揮得更好。
  6. 前端程式設計師/RD:
    負責實作前端介面的程式碼及細節的調整與撰寫,這個職位的人需要與UI和UE通力合作。通常是照著UE做出來的UX藍圖,將各元件與操作實現出來,然後再將UI提供的圖像資料(包含色碼、圖片檔案及名稱等等),根據不同尺寸螢幕的解析度,選擇適合的圖檔一一放到正確的位置上。
    在細節的調整中,UI和RD的合作是非常緊密的,尤其是在多螢幕設計的系統上,在每種尺寸的螢幕上所呈現的方式可能會大不相同,因此需要根據不同的情況一一地調整。
  7. 中介層主程式設計師/SD&PL:
    負責中介層的溝通介面程式(或稱之平台API)並打造主程式架構程式碼。由於此職位的責任是軟體產品的穩定度與通用性,因此通常為資深工程師的工作。
    此職位必須能夠將不同情況、不同環境、不同設備甚至不同程式語言間的隔閡融合起來,舉例來說,通常因為需要提供前端程式連接後端資料庫的API,而於中間層實現連接各式各樣的資料庫、檔案庫、雲端資料、類比資料等等的程式碼。
    只有打造了深具彈性的程式架構碼之後,才能夠以更好、更穩定的方式,讓RD實作各元件的程式碼,而整體設計的優劣也會嚴重影響系統的安全性,以及未來的擴充性。
  8. 中介層程式設計師/RD:
    負責實作中介層的程式碼,這個工作相較於其他職位更加單純,但也更困難,因為實作的品質將會大幅影響系統的使用體驗。
    沒有人希望一個設計得漂亮又好用的前端介面,卻因為後端程式不穩定而經常出錯,甚至影響系統的營運環境。
    而且在測試工程師進行測試時,因為很難測試到中介層的錯誤,所以有許多安全性的問題,會因為不嚴謹或考慮不周的實作方式,而產生嚴重的後果。
    譬如20年前著名的千禧蟲事件,就是實作程式的時候,並未考慮到電腦未來發展而造成的全球性問題。
  9. 主測試工程師/QA:
    負責規劃、實施產品的測試計畫與各項測試結果的建議統整。在絕大部分公司的QA都被軟體團隊視為接近邊緣的角色,所以常常會覺得被排除在團隊之外,然而最好的QA要從系統設計之初,就和產品經理、UE、UI和PM通力合作每個階段的測試計畫。
    因為只有了解整個系統的緣由、目的以及須達成的效果,才能在嚴謹的測試計畫中,完整地確認系統是否符合期望。因為在實務使用的過程中,就算是小小的錯誤都有可能會影響使用者的印象,嚴重的問題則更是有可能直接造成系統崩潰,甚至因此下架。因此更需要非常腳踏實地、嚴謹的測試計畫,作為產品在每個階段的總結。
    但是較可惜的是,在許多公司裡,如此重要的角色往往被公司甚至團隊所忽略,變成只是一個橡皮圖章,或是由專案經理兼任測試計畫的製作。
    於是,專案經理(球員)和主測試工程師(裁判)的角色,會因為產品時程的考量,而在彼此混淆的情況下,草草了事、睜一隻眼閉一隻眼地掩飾過去了。
上面這些角色,主要是以軟體產業為主。但如果你不是軟體產業的人也不用擔心,你可以很簡單地將這些角色歸類成:
  1. 大主管、部門主管:產品經理、專案經理。
  2. 專案負責人、小主管(課長、股長等):專案經理、技術經理。
  3. 組長(或工班班長):PL、SA、SD、UX、UI。
  4. 團隊/工班成員:RD(包含前端和中介)。
  5. 查核單位:QA。
所以,如果有注意看的人,可能會留意到我對每個關鍵人物的描述,越到後面的人講得越多,尤其是經常被邊緣化、被人討厭的QA,但其實這個職位是系統在開發的階段中,最常被忽略的人。
每一次在開發的過程中,如果總是靠著工程師自己去找臭蟲、挖 bug,那麼系統絕對不會有穩定的一天,所以必須要靠外部的審查力量,來督促工程師們認真地面對自己犯下的錯,而你身為一個 BA 在這種時候的態度就要非常謹慎,要保持立場客觀來看這件事。
這不是叫你站在牆壁上觀望,而是要你好好趁這個時候趕緊根據 QA 提出的回報,好好思考如何將這個解決方案結案的方法,這個方法中會包含和所有人溝通的眉角,還有如何強化優點、彌平缺點,並且訂出一個可以受人信任、驗證、評估並接受的評估方案。
在此同時,你也要跟著整個團隊的開發進程,一步步地找出這個解決方案沒能做到的事,並且開始偷偷規劃該如何用下一個方案來達成這些事了。
在這篇文章最後的最後,我是不是忘記跟你說一件事?雖然我們在這裡談的是開發會議,但如果你覺得開發會議一樣是在會議室中進行,那其實我根本不用寫這麼多。
開發會議和需求引出會議一樣,真正的會議都是發生在會議室之外。身為 BA 的你,要隨時隨地準備好跟著各種關鍵人物用不同的方式互動,找出他們習慣也喜歡的溝通方式還有地點,有些人喜歡用圖像討論,有些人喜歡邊抽煙邊畫圖或是看著程式碼討論,百種人有千種方式。
身為小小 BA 的你,千萬要記得「立場客觀中立」,即使這整個規劃都是由你一手誕生,也不要在開發的過程中太過於堅持立場,而造成團隊互動停滯,這反而不會是你想要的。
所以,在這最後的最後的最後…我得要說一句:「親愛的 BA,我們的天堂路才剛走到一半而已。」保留些體力,別累垮了,現在還在 Part 3 中,除了接下來的 V&V 之外,我們還有好幾關要過呢。

如果這篇文章你想用聽的,可以在這裡找得到:
https://www.ears.tw/sounddetails/1780

如果你覺得這篇文章不錯,值得拍拍手,可以拍五下 Like 給我一些鼓勵:
為什麼會看到廣告
illustration
贊助支持創作者,成為他繼續創作的動力吧!
DK 耀尊
DK 耀尊
AGI人工智慧科學家 &商業與產品規劃顧問|分享關於策略思維、企業管理、商業開發、組織領導的知識與技巧,還有一些有點腹黑又真實的人性+人生經驗談。
留言0
查看全部
發表第一個留言支持創作者!
從 Google News 追蹤更多 vocus 的最新精選內容