Meeting

Meeting 其實就是浪費時間和消耗體力精神的最好方法. 而 RD 要開會的目的如果是工作上專業有關的就算了, 比如說系統架構, 程式方面等等, 並且確保程式出來是 spec 和 user 需要的東西. Spec meeting 我倒是覺得改叫 spec 同意大會或是批鬥大會算了. 一方面 RD 在 spec meeting 來說, 主要應該負責看這種架構合不合理, 容不容易做, 需要多少技術跟工作時間. 但是往往在 S 公司 RD 是 design spec 全權主導的對象.TM 收集了 user requirements, 本來 spec 就是他們的工作卻一直都落在 RD 身上, 所以 RD 不僅只要會寫 code 也還會要開 spec, 還要制定 use model; 最好 programmer 身兼 layout designer 還知道他們需要什麼, 要怎麼操作比較方便. 開完一場 spec 下來其實根本也還沒完全定案, 會中討論的不定性還要跟 customer 或是 TM 自行再去確定.
總歸簡單的來說, spec meeting 就只是批鬥大會, 一堆 TM 在裡面爭論各自的論點. 不過請你們自己 TM 部門都確定了 user requirement 和 use model 再來請 RD 做完整 design spec 不是更好. RD 作 use model & spec 只是更浪費時間, RD 要寫 code 改 bugs, 找 TM 問 spec 常常找不到人. 所以說 TM 自己忙得沒時間寫 spec, 要 RD 寫只是再繼續拖累 RD schedule. 我只能說我乾脆先幫你們 booking 時間讓你們自己去開會去爭論, 然後結束了再 call RD 進去整理你們的定案.
最扯的是連 spec 或是 use model 都不知道, 只有 user requirements 的一些 description, 上面高層就排定說這個版本要做這功能. 如果 spec 有問題或是根本不需要, 是不是不用作了, 所以這個 release 階段個人的 schedule 就鬆了? 我猜也不是, 反正都排了就大家批鬥完, 看誰認輸誰勝出, 就照那個做. 沒有達到 user 真正要的, 沒關係下次出 patch 再繼續改.
RD: patch 只有一個月的時間又有一堆其他 bugs 要改, 這個 user 要的 model 根本跟之前 spec 提的不同, 怎是 patch?
Head: 有什麼完全不同嗎? 不就是把這個改成那樣? (真是xx比雞腿. 見識一下 Oral programming)