PM從客戶那邊帶回需求，
經由公司內部討論出spec，再把spec拿給客戶確認，
若有需要修改的地方，公司內部再討論出新版的spec，
以上來回幾次把最終版的spec定下來，然後RD開始實作。
以上是我們公司在制定spec的過程，
我覺得在開會的共過程中，總覺得很多地方沒有效率，
1. 針對一個功能，在會議中討論有ABCD四種可行的作法，會後大家決定用A作法。
但是下次開會時，總是有些人忘記最終決定的是A作法。
然後就說"上次我聽到有人說用B作法比較好，為什麼決定要用A作法"
於是又把上次討論過，決定過的東西又花時間重新討論過一次。
2. 開會的過程就為一個還沒有型體的東西制定它的功能，想像力很重要，
開會時必須考慮到，將來使用者要怎麼用它，然後會遇到什麼問題，所以要怎麼解決，
或是將來實作時會遇到什麼問題，會不會和現有的系統有什麼衝突。
你必須憑空去想像一下將來作出來會長怎樣，會遇到什麼問題，
當產品的功能越複雜，就越難去想像，最後spec制定出來總有不夠周全的地方，
而過程中當講者的表達能力不好，或是聽者的理解能力不好，常會出現雞同鴨講的狀況。
3. 會議上大家的背景不同，有RD、QA、PM、UX(使用者經驗部門)的人，
每個人考量的點不同，有時候很難達成共識，因為不清楚對方的專業，
甚至輕視對方的專業，有時候總是看誰位階大、或是講話比較大聲來決定最終版本。
曾看過RD leader抱怨過 "PM什麼都不懂，卻喜歡搞一些不切實際的東西出來"
或抱怨 "UX說要做的東西，我很懷疑到底有多少使用者覺得好用，我個人覺得很難用..."
4. 客戶是老大，往往大家討論了半天，定了一個最終版本，結果客戶說不要，
大家又得重新開會來重新討論。
很多人都覺得開會大部分時間都是浪費，這時總想起水桶哥obov說過的話
"團體本身就存在著無效率，一家公司要永續經營 就一定要包容這樣的無效率"
不知道大家的spec都是怎模樣制訂出來的，怎麼樣讓過程盡量有效率一點呢？