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都是怎模样制订出来的，怎么样让过程尽量有效率一点呢？