作者yukimatoi (纏)
看板Soft_Job
標題[請益] 預估工時的意義在哪？
時間Sun Jul 21 15:01:55 2019
我們公司的流程是
評估市場需求→PM提案→設計師開規格→RD實作→QA→發布
實際上是什麼開發流程我是不知道
網路上有看過離職的前輩說這是瀑布式
公司這幾年又把一些敏捷的思想帶進來...
說因為沒有一個人神到可以設計出最終規格
所以產品要不斷迭代 RD可以先做出一個成品給設計師看 跟設計師互相討論
但矛盾的是 我們的產品上線時間很早就被敲定
所以大部分的專案 下場就是沒有得到足夠的迭代
最後不是砍規格 就是RD跟設計師一起加班趕進度
甚至還有上線兩個月前規格才完成的狀況
我也問過主管 這樣迭代真的足夠嗎？ 主管只說：恩，公司要賺錢
PM最喜歡的就是預估時程 畫滿甘特圖 預期最後有幾個功能會完成
但最常見的狀況就是規格大改(因為我們會迭代)
不然就是RD為了進度hard code才勉強滿足進度
反正有問題就看誰倒楣誰修誰接手
RD大老雖然說要推行test 但是跟PM根本沒有共識 專案進度也沒有排入test撰寫的閒暇
所以RD要不就是自願加班寫test 要不就是乾脆不寫 或是寫一些無關緊要的test
我不知道是不是只有我們公司才這樣
還是這是業界常態只是我太菜了
我是真的不太懂預估工時的意義到底在哪
工時預估準確 ─┬→ 可喜可賀
└→ 規格變更 ─→ 完成時間延長(然後叫你再估一次工時)
工時預估不準 ─┬→ RD遜砲，請重估
├→ RD報喜不報憂 留下技術債
└→ 規格變更 ─→ 完成時間延長(再估一次)
工時不管預估準不準確，都不能影響專案目前的進度以及實際上需要的時間
(實際需要的時間 大概只有神知道)
但預估工時反而會給PM「一切都在我的掌握之中 專案都在軌道上」的錯覺
還是說我誤解了預估工時的目的 有沒有人可以指點一下？ 謝謝
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.163.98.5 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1563692517.A.FF3.html
1F：→ NDark: 先卡 07/21 15:08
2F：→ MOONY135: 工時就是用來delay的 （誤 07/21 15:20
3F：推 irvingray: 真正落實敏捷也是種神話 07/21 15:20
4F：推 rhox: 預估工時可以用來評估開出的規格是否可行 07/21 15:22
5F：→ pttworld: 估工時是因為成本和報價，通常只有縮短 07/21 15:29
6F：推 abccbaandy: 工時本來就是參考用阿...delay是正常的 07/21 15:38
7F：→ abccbaandy: 看那些遊戲大作整天coming soon就知道了吧XD 07/21 15:39
8F：推 art1: 因為是用在管理上，高層就是看這些東西 07/21 16:00
9F：→ fgh81113: 工時就是拿來壓榨你用的 做不出來你的問題 07/21 16:00
10F：推 anandydy529: 就是一個半套的工作流搞的程式很爆炸 07/21 16:21
11F：→ landlord: 敏捷一般常見的是fixed deadline, 但scope是變動的 07/21 16:44
13F：→ landlord: 一般公司最大的誤解就是time跟scope都不可變動 07/21 16:45
14F：→ landlord: 那當然穩死的，這不是敏捷的問題，是濫用的問題 07/21 16:45
15F：→ landlord: 還有一個大前提，簽敏捷宣言的大神們，其實都是技術大神 07/21 16:46
16F：→ landlord: 他們發現要解決人跟協作的問題，避免流程冗重浪費的問題 07/21 16:47
17F：→ landlord: 所以用敏捷宣言來補上這一塊，因為他們已經沒啥技術問題 07/21 16:47
18F：→ landlord: 現在搞敏捷的公司，技術跟工程基底能力普遍不足 07/21 16:47
20F：→ landlord: "為什麼 Scrum 害你們產能下降、品質低落、時程 delay" 07/21 16:49
21F：→ landlord: 講個結論，從你的描述看來，你公司只是把敏捷當銀彈用 07/21 16:50
22F：→ landlord: 跟人家在追求潮流詞彙而已，但結果會比原本的瀑布還差 07/21 16:50
實際上我們公司的規格也幾乎都是口傳 文件只是當參考註記用 沒有common lang
更沒有什麼user story的概念 或sprint的名詞
只是一直講產品要迭代 規格會改 進到QA後規格調整功能追加也是常態
※ 編輯: yukimatoi (1.163.98.5 臺灣), 07/21/2019 16:54:41
23F：→ MOONY135: 工程師能力不一跟對專案了解度不一 跑敏捷真的是會絕頂 07/21 16:56
24F：→ MOONY135: 昇天 07/21 16:56
25F：→ landlord: 恩，所以只是被「buzzword形式的agile」強暴了 07/21 16:56
26F：→ JingJing00: 工時是拿來讓pm排開發功能的優先順序 07/21 17:47
27F：→ JingJing00: 一個功能複雜度13 另一個3 無相依 看pm是想先做13還是 07/21 17:48
28F：→ JingJing00: 先做3的 07/21 17:48
29F：→ keyboard56: 工時主要就用在管理 上面喜歡看到有在前進的感覺，二 07/21 17:56
30F：→ keyboard56: 來就是報價用讓上面知道要開發這個東西大約需要多少 07/21 17:56
31F：→ keyboard56: 成本。但預估歸預估實際上很難估得準，需求規格的不確 07/21 17:56
32F：→ keyboard56: 定是主因，會壓縮到後續相關的時程。 07/21 17:56
33F：→ SimonAllen: 敏捷只做半套就是在壓榨工程人員.. 07/21 18:07
34F：推 TheOneisNEO: 遇過很有趣的 工時不能估太長 太長的話強制拆成兩個 07/21 20:27
35F：→ TheOneisNEO: 以上的排程 但根本就還沒做也沒確認規格 07/21 20:28
36F：→ MOONY135: 樓上那個我遇過喔 07/21 20:39
37F：噓 tx50xyz: 你能說不嗎？工時估多一點，馬上就說要這久，估少，你天 07/21 21:28
38F：→ tx50xyz: 天要加班加到死，估時程是對老闆超有利的，反正工時開多 07/21 21:28
39F：→ tx50xyz: 老闆會點頭嗎？跟本就是有依據讓你加班不給加班費的 07/21 21:28
40F：推 oopFoo: 推landlord大 07/21 21:48
41F：推 anandydy529: 我也遇過只有一句話就要你估工時的，估完還不能改 07/21 21:49
42F：→ neo5277: 通常壓辦年或是八個月上線然後會延兩次 07/21 21:50
43F：推 overhead: 你的抱怨超寫實超有既是感哈哈哈 07/21 22:02
44F：→ MOONY135: 我遇過可能工程師裡面那段只有一個人碰過 要其他人盲估 07/21 23:36
45F：→ MOONY135: 的 這種我就覺得很微妙 07/21 23:36
46F：推 molopo: 壓久了 人都走光 07/22 03:08
47F：推 expup: 會問這個問題的估計是連預估都不會或常常預估錯誤 07/22 04:12
48F：→ expup: 但也不能怪妳啦因為預估時間這東西沒人會教你 07/22 04:13
49F：→ bndan: 估工時 目前看到最經典的還是 公司老工程師估完新工程師承 07/22 08:22
50F：→ bndan: 擔 這種絕頂升天的程度不亞於實力或認知不同時實跑scrum 07/22 08:22
51F：推 doranako: 不估時程，誰知道大概做多久，蓋個房子也要估時程阿， 07/22 09:07
52F：→ doranako: 敏捷跟瀑布一樣，前面需求分析架構做足，時程變動少， 07/22 09:07
53F：→ doranako: 除非中間又更動到功能跟規格 07/22 09:07
我們就是三餐在改啊
54F：→ WunoW: 都說是估了，當然不會準啊 07/22 09:17
※ 編輯: yukimatoi (1.163.98.5 臺灣), 07/22/2019 09:25:33
55F：→ firtaily: 跟小弟公司碰到的蠻像的 公司甚至sa跟pg是同步的 很常pg 07/22 09:28
56F：→ firtaily: 這邊開發完了sa寫出來發現不一樣pg這又要再改 07/22 09:28
57F：推 hakama99: 我們公司還發生新產品評估階段 業務已經賣出去好幾套 07/22 10:24
58F：推 dong531: 1掌握進度避免無法如期交付而被罰錢 07/22 10:55
59F：→ dong531: 2計算人力估價報價 07/22 10:56
60F：→ dong531: 比如我現在的維護案，需求來了先評估人力、工時，然後回 07/22 10:56
61F：→ dong531: 報這個需求需要多少人力做多久所以報價是多少，要做就開 07/22 10:56
62F：→ dong531: 單不做就不開單 07/22 10:56
63F：推 sirius65482: 簡單啦 預估完的時間全部乘以1.5 這樣就準多惹 07/22 12:37
64F：推 b6byc: 改動頻率也太常了吧. 這個應該是規格溝通問題. 一直改啥 07/22 17:48
65F：→ b6byc: 方法都沒用, 做一做, 反正還要改. 07/22 17:49
66F：→ b6byc: 壓時間壓久了, 受不了走人, 然後loop, 公司沉淪下去. 07/22 17:50
67F：推 lordmi: 講這麼多，幾個字就定義完了：隕石式開發 07/22 18:00
68F：→ dancedolf: 評估的時候 最好是能多花點時間 另外在評估之前 需求 07/22 21:29
69F：→ dancedolf: 應該已經有至少八成的確定 如果推倒重來 那時間肯定要 07/22 21:29
70F：→ dancedolf: 重估 返工肯定是往需求推 07/22 21:29
71F：→ dancedolf: 如果需求連讓你想像功能畫流程圖都不行 那就退貨吧 另 07/22 21:31
72F：→ dancedolf: 外需求通常都會比當前sprint 提早 最好還有人能夠 rev 07/22 21:31
73F：→ dancedolf: iew 07/22 21:31
74F：→ viper9709: 推同感~有一樣的疑問+1 07/22 22:14
75F：推 Tatum0119: 卡 07/23 00:18
76F：推 shooter555: 估時間只能竟量估長0.0 有時候時間真的很難估 07/23 10:55
77F：→ shooter555: *儘量 07/23 10:56
78F：噓 b81314: 加油! 07/24 17:14
79F：推 sa0124: 這是好問題耶 但如果都不估時程 功能隨意做做個一年 這樣 07/25 18:58
80F：→ sa0124: 公司會倒吧 估時程主要還是讓公司判斷這個產品成本多少錢 07/25 18:58
81F：→ sa0124: 啊 07/25 18:58
82F：→ sa0124: 我們是工程師自己估，其實估久了真的就越來越準了，有時 07/25 19:00
83F：→ sa0124: 候發現自己估很準其實也蠻有成就感的XD 07/25 19:00
84F：推 zased: 這什麼問題 RD看世界？你換個角色重新思考專案就知道預估工 07/26 01:25
85F：→ zased: 時的重要性，而且預估工時是RD的基本功... 07/26 01:25
86F：推 JingX: RD自估最準 但高層一句"這麼簡單哪要這久你能力不足"就... 07/28 09:16