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