[討論] spec是怎麼被制訂出來的呢?

看板Tech_Job作者 (rosemary)時間12年前 (2013/06/29 10:57), 編輯推噓21(21推 0噓 35→)
留言56則, 30人參與, 最新討論串1/2 (看更多)
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都是怎模樣制訂出來的，怎麼樣讓過程盡量有效率一點呢？ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 122.116.153.199
推
06/29 10:59, , 1F
初步方案決定後 請機構用殺哩窩克畫個簡圖
06/29 10:59, 1F
→
06/29 11:00, , 2F
然後深入討論細部修改的內容
06/29 11:00, 2F
→
06/29 11:00, , 3F
最後是由PM和RD leader兩個人決定最終方案
06/29 11:00, 3F
→
06/29 11:00, , 4F
然後客戶要求就盡量配合這樣…
06/29 11:00, 4F
推
06/29 11:02, , 5F
美大廠 產業龍頭 然後version 0.x 直到訂好1.0
06/29 11:02, 5F
推
06/29 11:57, , 6F
一間公司有沒有效率,就是看這些地方啊.
06/29 11:57, 6F
推
06/29 11:59, , 7F
定國際標準更麻煩,各公司角力,通常要訂個兩三年
06/29 11:59, 7F
推
06/29 12:00, , 8F
解決不了的 bug 會變成 spec
06/29 12:00, 8F
→
06/29 12:18, , 9F
如果是解決不了的bug 那spec當初可能就有問題了
06/29 12:18, 9F
推
06/29 12:21, , 10F
Spec是由出錢的那個人嘴裡說出來
06/29 12:21, 10F
→
06/29 12:21, , 11F
我覺得工程人員訂出來的通常不會離譜到哪去
06/29 12:21, 11F
→
06/29 12:22, , 12F
最怕的是有大魔王(高層)亂入 加入大而無用的功能
06/29 12:22, 12F
推
06/29 12:25, , 13F
最大那個說的就是對的阿~出包後背黑鍋的也不是他
06/29 12:25, 13F
→
06/29 12:25, , 14F
最怕的是,連spec都沒定,走一步看一步.
06/29 12:25, 14F
→
06/29 12:28, , 15F
加入某功能後. 高層: die size這麼大怎麼賣? 拿掉
06/29 12:28, 15F
推
06/29 12:34, , 16F
今天看到的: 定spec很簡單啊, 高層/PM吃個飯,三小時就訂好了
06/29 12:34, 16F
→
06/29 12:34, , 17F
連schedule也一起訂好了
06/29 12:34, 17F
推
06/29 12:37, , 18F
有時亂答應吃虧是自己 做不出來就會被嗆 你之前不是說可
06/29 12:37, 18F
→
06/29 12:38, , 19F
以 怎麼現在不行
06/29 12:38, 19F
→
06/29 12:39, , 20F
你打這篇也是抱怨,可以針對你的抱怨點尋找解決方法
06/29 12:39, 20F
→
06/29 12:40, , 21F
這就是企業浪費時間開會的文化 不然你以為有那麼多事做?
06/29 12:40, 21F
→
06/29 12:42, , 22F
spec簽名 影印 cc啊 科科
06/29 12:42, 22F
→
06/29 12:51, , 23F
不答應也會被嗆~這也做不出來喔...其他公司都叭啦叭啦
06/29 12:51, 23F
推
06/29 13:26, , 24F
溝通協調的重要性
06/29 13:26, 24F
推
06/29 13:28, , 25F
當然是一群傻B聚在一起聊天假裝開會 大家喊一喊亂殺價
06/29 13:28, 25F
→
06/29 13:28, , 26F
就後說：好像這樣也行 就這樣定下去了
06/29 13:28, 26F
→
06/29 13:48, , 27F
自己去看程式設計師名言(格言)吧，裡面寫得很清楚 。
06/29 13:48, 27F
推
06/29 14:27, , 28F
可善用meeting minutes 作記錄
06/29 14:27, 28F
→
06/29 15:45, , 29F
開會最大的結論就是訂好下次開會的時間
06/29 15:45, 29F
推
06/29 15:56, , 30F
大半的人士希望靠著無效率會益把自己上班時間 度過
06/29 15:56, 30F
→
06/29 15:56, , 31F
所以拖的越久越好 講話竟量喇豬屎為佳
06/29 15:56, 31F
→
06/29 15:57, , 32F
通常只有要做事的RD很想快點結束會議
06/29 15:57, 32F
→
06/29 15:58, , 33F
當然不做事的RD或者比較閒的RD主管也是比較希望哈拉久一點
06/29 15:58, 33F
→
06/29 15:59, , 34F
由其是人多的時候能露臉的時候就盡量拖時兼增加曝光度
06/29 15:59, 34F
→
06/29 15:59, , 35F
所以選擇誰去開會對效率大有幫助。
06/29 15:59, 35F
推
06/29 16:43, , 36F
會議紀錄->簽名->定期追蹤,監督,協助;不然會都是開個樣子
06/29 16:43, 36F
推
06/29 17:22, , 37F
基本上還是客戶決定居多
06/29 17:22, 37F
推
06/29 19:33, , 38F
推解決不了的bug 改SPEC...ORZ
06/29 19:33, 38F
→
06/29 20:36, , 39F
開會都不寫會議紀錄的?
06/29 20:36, 39F
推
06/29 23:17, , 40F
PM如果不是工程背景的 常常都亂搞!!!
06/29 23:17, 40F
推
06/30 02:51, , 41F
解決這種問題開會已經不是重點了，重點是記錄!
06/30 02:51, 41F
→
06/30 02:52, , 42F
記下來那些亂提意見又沒腦袋的婊子們說過的話..
06/30 02:52, 42F
→
06/30 02:52, , 43F
然後下一次遇到客訴或者內部抱怨的時候統他一刀
06/30 02:52, 43F
→
06/30 02:53, , 44F
以後他就會乖乖閉嘴，記得 重點是記錄!! 開完會要他簽名!
06/30 02:53, 44F
推
06/30 06:37, , 45F
用數據講話啊= = control是多少? sigma是多少? range多少?
06/30 06:37, 45F
→
06/30 06:38, , 46F
這不是用統計學就可以討論了嗎= = 應該超快吧= =
06/30 06:38, 46F
→
06/30 06:38, , 47F
哪一間公司這麼沒效率啊?
06/30 06:38, 47F
→
06/30 10:02, , 48F
你想多了~ D大 看來很少去開會喔~
06/30 10:02, 48F
→
06/30 10:02, , 49F
基本上愈多大頭的會,愈易出現這樣的情形
06/30 10:02, 49F
→
06/30 10:03, , 50F
有客戶的會議,也易出現這樣的情形.
06/30 10:03, 50F
→
06/30 10:03, , 51F
如果有客戶的高層會議... 哈哈....
06/30 10:03, 51F
→
06/30 10:05, , 52F
y大說的就是較和事實接近....(接近是客氣,根本是事實..)
06/30 10:05, 52F
推
06/30 14:11, , 53F
開會快不快決定權不在報告的人，在上頭的爭權爭到什麼程度
06/30 14:11, 53F
推
06/30 21:59, , 54F
統計學真的在會議室裡,我看到最常的狀況是被人誤用為脫身
06/30 21:59, 54F
→
06/30 21:59, , 55F
的工具.
06/30 21:59, 55F
→
07/14 16:28, , 56F
老闆說:我要做這個，這是我畫的圖，發包開始做軟體吧
07/14 16:28, 56F
‣ 更多 rosemary0401 的文章
文章代碼(AID): #1HpaqTZB (Tech_Job)
‣ 更多 rosemary0401 的文章
文章代碼(AID): #1HpaqTZB (Tech_Job)