我們公司的流程是
評估市場需求→PM提案→設計師開規格→RD實作→QA→發布
實際上是什麼開發流程我是不知道
網路上有看過離職的前輩說這是瀑布式
公司這幾年又把一些敏捷的思想帶進來...
說因為沒有一個人神到可以設計出最終規格
所以產品要不斷迭代 RD可以先做出一個成品給設計師看 跟設計師互相討論
但矛盾的是 我們的產品上線時間很早就被敲定
所以大部分的專案 下場就是沒有得到足夠的迭代
最後不是砍規格 就是RD跟設計師一起加班趕進度
甚至還有上線兩個月前規格才完成的狀況
我也問過主管 這樣迭代真的足夠嗎？ 主管只說：恩，公司要賺錢
PM最喜歡的就是預估時程 畫滿甘特圖 預期最後有幾個功能會完成
但最常見的狀況就是規格大改(因為我們會迭代)
不然就是RD為了進度hard code才勉強滿足進度
反正有問題就看誰倒楣誰修誰接手
RD大老雖然說要推行test 但是跟PM根本沒有共識 專案進度也沒有排入test撰寫的閒暇
所以RD要不就是自願加班寫test 要不就是乾脆不寫 或是寫一些無關緊要的test
我不知道是不是只有我們公司才這樣
還是這是業界常態只是我太菜了
我是真的不太懂預估工時的意義到底在哪
工時預估準確 ─┬→ 可喜可賀
└→ 規格變更 ─→ 完成時間延長(然後叫你再估一次工時)
工時預估不準 ─┬→ RD遜砲，請重估
├→ RD報喜不報憂 留下技術債
└→ 規格變更 ─→ 完成時間延長(再估一次)
工時不管預估準不準確，都不能影響專案目前的進度以及實際上需要的時間
(實際需要的時間 大概只有神知道)
但預估工時反而會給PM「一切都在我的掌握之中 專案都在軌道上」的錯覺
還是說我誤解了預估工時的目的 有沒有人可以指點一下？ 謝謝