※ 引述《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..
以上仅供参考