※ 引述《yukimatoi (纏)》之銘言：
: 工時預估準確 ─┬→ 可喜可賀
: └→ 規格變更 ─→ 完成時間延長(然後叫你再估一次工時)
: 工時預估不準 ─┬→ RD遜砲，請重估
: ├→ RD報喜不報憂 留下技術債
: └→ 規格變更 ─→ 完成時間延長(再估一次)
: 工時不管預估準不準確，都不能影響專案目前的進度以及實際上需要的時間
: (實際需要的時間 大概只有神知道)
: 但預估工時反而會給PM「一切都在我的掌握之中 專案都在軌道上」的錯覺
: 還是說我誤解了預估工時的目的 有沒有人可以指點一下？ 謝謝
估計準不準,不同功力的工程師還是有差.
我記得我上次寫過資深工程師的差異.就有提到這點.等等我再貼連結.
我換過 八間 大到幾千人 小到十人的不同規模公司.
我甚至還寫過遊戲軟體管理的文章.
原PO講得這些問題都發生過.有些是制度文化問題.有些是工程師自己想太多.
很難概括而論.每間公司每個團隊每個主管可能問題都不一樣.
只能回歸一句. 找適合自己"文化"的公司/團隊/主管 很重要.
除此之外我只能分享我的經驗.
我目前專案是上線專案.每個月要固定更新.也就是每個月都在壓死線.
對我們來講每個月就是一直重複 設計/估計時程/實作/測試/上架/更新.
一旦上架延遲,更新就會延遲. (因為蘋果商城審核的時間不是我們能夠控制的)
所以在這種環境下時程比規格重要.
一旦發生有危及時程的狀況.就是砍規格. 寧願少一個功能道具/不要延遲整個更新.
但是當然這種事情最好不要發現/發生太晚.要砍規格調整時程都已經來不及了.
(更新延遲在我一年半的觀察以來還是發生過一次)
(每個月拚上架一年來只有一次不加班)
我目前直屬主管跟專案主管都是蠻實際(practical)的印度人.
專案主管(PM)面試我的時候就談過類似的問題,他是這樣講的:
"我寧願你早點告訴我(做不到),不要放馬後炮(說早告訴過你)"
直屬主管(TD)在我反映這個議題上也直接明講:
"如果你覺得要留測試*的時間,記得報時程的時候自己要抓緩衝(浮報)"
(補充:這邊TD不能明講一些灰色地帶.留測試只是好聽.
因為不懂開發的人會覺得實作就應該要高效能,應該要正確,
但是實務上一定會有做完了但是不滿意的情況.
尤其是在表現上的功能,如動畫,粒子特效,介面,甚至是介面流程.
如前述,我們的每個周期是約二十天,設計可能只有五天.
五天不是只設計一個東西.一個月可能是幾十項.
很多功能就是丟一句話就要幹了.
自然無法準確預估.但是經驗還是讓我可以估出一個可能要預留這些改來改去的時間
緩衝就是不要讓管理層排出一個沒有風險管理太理想的時程.
避免臨時有狀況,結果時程就爆炸要加班砍規格大家都不爽)
為什麼我敢實話實說? (而原PO工程師朋友們老是擔心報太多會黑?)
我研判是這樣
因為我團隊同職缺目前就配三個工程師(PG)就算剛好.
如果一個休長假,另外兩個人還可以輪流請假.不會任何一天沒PG開天窗.
然這個職缺新聘進來到理解7成功能能扛專案.要訓練至少半年.
所以公司禁不起人離職.找人很難.人進來要半年才能回到三人效率.
所以對工程師都畢恭畢敬.(當然地位沒有到橫著走)
沒有那種台灣職場常聽到的名言:"後面能接替你工作的很多"
(公司大,想進來的是很多,但是專案的knowhow太多,每個人進來都得花時間慢慢搞懂)
給各位參考.