# 為什麼都是我在加班？揭開團隊高效工作的秘密
###### date: `2024-09-03`
###### tags: `大神來六角`
---

## 主持人

- [Ray](https://portaly.cc/israynotarray)

## 近期活動

- [JS 直播班](https://www.hexschool.com/courses/js-training.html)

## 講者介紹


## 直播大綱

你是否常常發現自己是最後一個離開辦公室的人？專案的變化是否讓你手足無措，忙得不可開交？
在我的職業生涯中，我曾在台、日、美等多國企業工作，經歷過在小公司從零建立開發團隊，也帶領過大公司的跨國開發項目。這些經驗讓我深刻理解團隊常常面臨的各種挑戰。

所謂魔鬼藏在細節裡。在這場講座中，我將與大家分享打造高效團隊的秘訣，包括：

1. 必須建立的關鍵流程
2. 需要重點把控的關鍵點
3. 減少人為錯誤和加班需求的技術方法

歡迎大家帶著自己的問題，在直播時和我一起聊聊天。

## 相關連結

- [Sli.do 提問區](https://app.sli.do/event/pxmDMjrLAyvcF2QAo6c9mY)
- 《跨部門協作開發》線上課程：https://hahow.in/cr/rqmt-intro
- 《程式猿吃香蕉🍌》粉絲團：https://www.facebook.com/banana4coder
- 《程式猿吃香蕉🍌》部落格：https://banana4coder.cc/blog
- [簡報連結](https://docs.google.com/presentation/d/1PDMnNhUcOSsBA0dhaBTDVuC1q4C7rrR5T9c0d-weU08/edit#slide=id.p)
- Project 🚩隔離變化是並行工作的關鍵
> https://link.medium.com/gGsyWmiUEMb

---

## NOTES

- 為什麼團隊合作很困難
- 軟體開發週期變短
- 跨職能團隊的合作更密切
- 並行工作模式

- 加班的元兇
- 變化
- 比如臨時出現 BUG
- 太晚知道消息

:::success
以 **變化** 少的部分
做為 **起點** 來開展工作
:::

- 把範圍確定好
- 像幫牆壁塗油漆先分區塊

- 前端工程師
- 以 API 文件來隔離變化

- PM
- ==**產品需求文件**==
- 使用案例（Use Case）

- 工程師
- ==**工程設計文件（EDD）**==
- 系統架構圖
- 流程圖

- 需求下來後，比起先動手寫程式
- 可以先記錄思考大概要改動哪些東西（範圍、邏輯、條件）
- 資料庫設計（狀態、腳本、索引）
- 風險（效能、安全）

- 上線計畫（release plan）
- 發佈順序（通常後端先發、再前端）
- 設定檔、初始化（權限）
- 復原方案（Rollback）
- 驗證

- QA
- 以 ==**測試案例**== 來隔離變化
- 範圍完整性
- 獨立性（測試不會互相依賴）
- 可重復性
- 專注於測試單一功能點
- 正面和負面測試
- 自動化
- 性能考慮（讓測試跑快一點）
- 數據驅動
- 即時更新維護

---

## QA

> 無法立即暸解專案的全貌（資訊不透明、不對等），怎麼降低變化？

- 利用 EDD 等系統化的方式來詢問，讓迷霧可以稍微解開一點（雖然開完會還是迷霧）
- 即便不是 PM 也可以利用 Use case 來釐清需求

> 在非同步溝通的時候，為了等待回覆而導致加班的時候，該如何處理？

- 提早開始詢問，拉長時間
- 向上反應，請自己的主管與對方的主管溝通

> 課程會有利害關係的應對處理嗎？
- 會提到與不同職位要如何詢問，但課程提到比較多是方法論

> 文件以文字為主，以前端為例，開發前要畫流程圖嗎？
- PM 會畫 wireframe，更前面可能都用文字或卡片，不會過早把畫面畫出來，會有限制
- 前半部用文字、後半部用畫面

> sprint 如何估算點數？
- 以實作的本人為主，不是大家覺得，如果重複多次不準才檢討

> 測試的獨立性要如何做？
- 比如測試下單的功能，不依賴退貨功能的測試，簡單理解就是單獨執行

> plan 的時間佔 sprint 兩個禮拜裡面的幾趴？
- 開會的時候就同時進行，看專案的難度，3 或 4 日

> 常常在開發的時候才發現沒有提前想到，所以邊做邊討論邊修改，是正常的嗎？
- 如果修改會碰到邊界影響到他人的，就不太好
- 可以記錄下來，下次避免

> 公司拼命徵人，一直在帶新人，沒時間開發
- 把團隊的步調緩下來，先把文件、流程、自動化建立出來
- 跟主管溝通把問題反應上去
- 主管會希望事情可控

> 如何抽絲剝繭出真正的需求？
- PM 把故事講出來，使用者為了什麼原因等等
- 往前參加跟業務的會議，不透過轉手

> 公司不會討論格式規格，如何帶頭開始改變？
- 從自己開始著手，可以自己先列出規格，再去詢問對方

> 80/20 法則，如何用 20% 的精力產出 80% 的成果？
- 反問自己這件事情重不重要