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

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

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。