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都是怎模樣制訂出來的，怎麼樣讓過程盡量有效率一點呢？
然後深入討論細部修改的內容最後是由PM和RD leader兩個人決定最終方案然後客戶要求就盡量配合這樣…
作者:
wait (有言論自由!?)
2013-06-29 11:02:00美大廠 產業龍頭 然後version 0.x 直到訂好1.0
作者:
bxxl (bool)
2013-06-29 11:57:00一間公司有沒有效率,就是看這些地方啊.
作者:
bxxl (bool)
2013-06-29 11:59:00定國際標準更麻煩,各公司角力,通常要訂個兩三年
如果是解決不了的bug 那spec當初可能就有問題了
作者:
wj1009 (wj1009)
2013-06-29 12:21:00Spec是由出錢的那個人嘴裡說出來
作者:
mooto (退出會比較好, 就退出)
2013-06-29 12:21:00我覺得工程人員訂出來的通常不會離譜到哪去
作者:
mooto (退出會比較好, 就退出)
2013-06-29 12:22:00最怕的是有大魔王(高層)亂入 加入大而無用的功能
作者:
sai1268 (....)
2013-06-29 12:25:00最大那個說的就是對的阿~出包後背黑鍋的也不是他
作者:
b6byc (oopp)
2013-06-29 12:25:00最怕的是,連spec都沒定,走一步看一步.
作者:
mooto (退出會比較好, 就退出)
2013-06-29 12:28:00加入某功能後. 高層: die size這麼大怎麼賣? 拿掉
作者:
bxxl (bool)
2013-06-29 12:34:00今天看到的: 定spec很簡單啊, 高層/PM吃個飯,三小時就訂好了連schedule也一起訂好了
有時亂答應吃虧是自己 做不出來就會被嗆 你之前不是說可
作者: buddar 2013-06-29 12:39:00
你打這篇也是抱怨,可以針對你的抱怨點尋找解決方法
這就是企業浪費時間開會的文化 不然你以為有那麼多事做?
作者:
QQ5566 (哭哭5566)
2013-06-29 12:42:00spec簽名 影印 cc啊 科科
作者:
sai1268 (....)
2013-06-29 12:51:00不答應也會被嗆~這也做不出來喔...其他公司都叭啦叭啦
當然是一群傻B聚在一起聊天假裝開會 大家喊一喊亂殺價就後說：好像這樣也行 就這樣定下去了
自己去看程式設計師名言(格言)吧，裡面寫得很清楚 。
作者: brucemets (態度!) 2013-06-29 14:27:00
可善用meeting minutes 作記錄
作者:
ypxx (我想要百匹駿馬)
2013-06-29 15:45:00開會最大的結論就是訂好下次開會的時間
作者:
yozeng (呦!)
2013-06-29 15:56:00大半的人士希望靠著無效率會益把自己上班時間 度過所以拖的越久越好 講話竟量喇豬屎為佳
作者:
yozeng (呦!)
2013-06-29 15:57:00通常只有要做事的RD很想快點結束會議
作者:
yozeng (呦!)
2013-06-29 15:58:00當然不做事的RD或者比較閒的RD主管也是比較希望哈拉久一點
作者:
yozeng (呦!)
2013-06-29 15:59:00由其是人多的時候能露臉的時候就盡量拖時兼增加曝光度所以選擇誰去開會對效率大有幫助。
作者:
Egriawei (賀陽明盃連霸~)
2013-06-29 16:43:00會議紀錄->簽名->定期追蹤,監督,協助;不然會都是開個樣子
作者: KingCrimson (歐拉~) 2013-06-29 19:33:00
推解決不了的bug 改SPEC...ORZ
作者: furuuchi (宅心邪王) 2013-06-29 20:36:00
開會都不寫會議紀錄的?
作者: fredsaki (海風一直眷戀著沙) 2013-06-30 02:51:00
解決這種問題開會已經不是重點了，重點是記錄!
作者: fredsaki (海風一直眷戀著沙) 2013-06-30 02:52:00
記下來那些亂提意見又沒腦袋的婊子們說過的話..然後下一次遇到客訴或者內部抱怨的時候統他一刀
作者: fredsaki (海風一直眷戀著沙) 2013-06-30 02:53:00
以後他就會乖乖閉嘴，記得 重點是記錄!! 開完會要他簽名!
作者:
DrumBee (slow try)
2013-06-30 06:37:00用數據講話啊= = control是多少? sigma是多少? range多少?
作者:
DrumBee (slow try)
2013-06-30 06:38:00這不是用統計學就可以討論了嗎= = 應該超快吧= =哪一間公司這麼沒效率啊?
作者: kdid 2013-06-30 10:02:00
你想多了~ D大 看來很少去開會喔~基本上愈多大頭的會,愈易出現這樣的情形
作者: kdid 2013-06-30 10:03:00
有客戶的會議,也易出現這樣的情形.如果有客戶的高層會議... 哈哈....
作者: kdid 2013-06-30 10:05:00
y大說的就是較和事實接近....(接近是客氣,根本是事實..)
作者:
linyap (miche)
2013-06-30 14:11:00開會快不快決定權不在報告的人，在上頭的爭權爭到什麼程度
作者:
hsinggg (星居居)
2013-06-30 21:59:00統計學真的在會議室裡,我看到最常的狀況是被人誤用為脫身的工具.
老闆說:我要做這個，這是我畫的圖，發包開始做軟體吧