---
# System prepended metadata

title: 會議的調整

---


## 現在遇到的問題
## 敏捷
最主要是解決快速變動及模糊，增量交付。

## 困境
資源不足，需求模糊，敏擬，可以去收斂這些狀況

## 站立會議的目的
* 大家都是知識工作者，即然很多大廠使用這方法，
* 自主管理，提昇團隊協作品質
* 這是讓大家練習說話的管道
* 當各位往下個階段，也必須學習如何報告工作
* 每個人都希望自己的專業有所發揮
* PM 需要和美國老闆報告我們做什麼他必須了解我們的工作 ( 我想每位主管都是資訊焦慮的，如果沒有人同步資訊過來 )
* 了解同事在做什麼，

## 分組
* 項目分組有助於聚焦，可能講的東西怕其他人聽不懂，變成大家都不講話了

## 主持人
每週一位，輪流當主持人，主管最後做總結

因為主管會越來越忙，

Kevin > Jamie > Kelly > Yan

## 每一位成員都是
![](https://hackmd.io/_uploads/SJgDKH3n3.png)


## 會議的調整
1. 隨著我們人越來越多，因此會有很多資訊同步上的落差
2. 項目越來越多，混雜無法專注目標
3. PM 需要和美國老闆報告我們做什麼，他必須了解我們的工作
4. 過去的開發方式，可能會RUN成大家太在意時間，而忽略把手邊事情做好。
5. 我 PM 和REX 談，希望自主管理，在信認的前提下，希望導入敏捷開發，但工作舒服的前提下，需要大家的自律及團隊協作的資訊共享
6. 我想公司，未來可能會有更多的 country，未來你們也會帶人
(我想每個 country 如果都能做的起來， 一個 lead + two jor developer )


## 每天會議分組
敏捷的精神，其實PM是不用參與的，
PM 應該是 Product Ower，負責傳達 user 想要什麼，但因為我們人有限，所以PM原則是主持會議

Us =>  => allen 、mark 、jamie 、kevin =>host allen 
De、vn => =>  mark、jamie 、kevin => host mark 

## 會議中，原則上不追時程，如果有很重要的功能要 delay，只討論怎麼解決，專注在每兩週的交付

## 
會議只加入需要的人

一、昨日在做了什麼(這個分組項目)

二、今日做了什麼(這個分組項目)
如果沒有做，就說沒做
如果需要研究，或研究到一半也一樣同步，
或需要協助或

三、遇到問題要討論(這個分組項目)

## 避免
1.會議過長，每個人發言，盡量在3~5分鐘，太細節的內容，會議中提出，會後討論
2.時程額外的追，任何時間都是做的人去評估，不用當下回，也都可以談

## 還贏


https://www.timingasia.com/%E6%95%8F%E6%8D%B7%E7%AE%A1%E7%90%86%E6%8A%80%E5%B7%A7%EF%BC%9A%E6%AF%8F%E6%97%A5%E7%AB%99%E7%AB%8B%E6%9C%83%E8%AD%B0/






