※ 引述《rosemary0401 (rosemary)》之銘言：
: PM從客戶那邊帶回需求，
: 經由公司內部討論出spec，再把spec拿給客戶確認，
: 若有需要修改的地方，公司內部再討論出新版的spec，
: 以上來回幾次把最終版的spec定下來，然後RD開始實作。
: 以上是我們公司在制定spec的過程，
: 我覺得在開會的共過程中，總覺得很多地方沒有效率，
: 1. 針對一個功能，在會議中討論有ABCD四種可行的作法，會後大家決定用A作法。
: 但是下次開會時，總是有些人忘記最終決定的是A作法。
: 然後就說"上次我聽到有人說用B作法比較好，為什麼決定要用A作法"
: 於是又把上次討論過，決定過的東西又花時間重新討論過一次。
沒寫meeting minute & action plan
: 2. 開會的過程就為一個還沒有型體的東西制定它的功能，想像力很重要，
: 開會時必須考慮到，將來使用者要怎麼用它，然後會遇到什麼問題，所以要怎麼解決，
: 或是將來實作時會遇到什麼問題，會不會和現有的系統有什麼衝突。
: 你必須憑空去想像一下將來作出來會長怎樣，會遇到什麼問題，
: 當產品的功能越複雜，就越難去想像，最後spec制定出來總有不夠周全的地方，
: 而過程中當講者的表達能力不好，或是聽者的理解能力不好，常會出現雞同鴨講的狀況。
招開會議者，技術力不夠，所以講啥RD聽不懂
比方說機構要怎麼開，要機構怎麼折，EE 要怎麼cost down
不用懂太多，但是要切到point
開會是討論後畫押，不適PM說了算
: 3. 會議上大家的背景不同，有RD、QA、PM、UX(使用者經驗部門)的人，
: 每個人考量的點不同，有時候很難達成共識，因為不清楚對方的專業，
: 甚至輕視對方的專業，有時候總是看誰位階大、或是講話比較大聲來決定最終版本。
: 曾看過RD leader抱怨過 "PM什麼都不懂，卻喜歡搞一些不切實際的東西出來"
: 或抱怨 "UX說要做的東西，我很懷疑到底有多少使用者覺得好用，我個人覺得很難用..."
不可能每個人都一樣的觀點，取得共識為主
東西不是這些人說了算，客戶最大
: 4. 客戶是老大，往往大家討論了半天，定了一個最終版本，結果客戶說不要，
: 大家又得重新開會來重新討論。
: 很多人都覺得開會大部分時間都是浪費，這時總想起水桶哥obov說過的話
: "團體本身就存在著無效率，一家公司要永續經營 就一定要包容這樣的無效率"
: 不知道大家的spec都是怎模樣制訂出來的，怎麼樣讓過程盡量有效率一點呢？
沒辦法，只有有GUTS PM 或是 sales 能先過濾需求
不然目標永遠在變，代表這團隊本身就有問題，也沒有人可以控制這情形，
跟失控的野馬無限迴圈...for looging..
以上僅供參考