PTT職涯區 / Soft_Job (軟體人)

[請益] 預估工時的意義在哪？

看板Soft_Job (軟體人)作者 (纏)時間5年前 (2019/07/21 15:01), 5年前編輯推噓20(22推 2噓 62→)
留言86則, 37人參與, 5年前最新討論串1/9 (看更多)
我們公司的流程是 評估市場需求→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://www.ptt.cc/bbs/Soft_Job/M.1563692517.A.FF3.html
→
07/21 15:08, 5年前 , 1F
先卡
07/21 15:08, 1F
→
07/21 15:20, 5年前 , 2F
工時就是用來delay的 （誤
07/21 15:20, 2F
推
07/21 15:20, 5年前 , 3F
真正落實敏捷也是種神話
07/21 15:20, 3F
推
07/21 15:22, 5年前 , 4F
預估工時可以用來評估開出的規格是否可行
07/21 15:22, 4F
→
07/21 15:29, 5年前 , 5F
估工時是因為成本和報價，通常只有縮短
07/21 15:29, 5F
推
07/21 15:38, 5年前 , 6F
工時本來就是參考用阿...delay是正常的
07/21 15:38, 6F
→
07/21 15:39, 5年前 , 7F
看那些遊戲大作整天coming soon就知道了吧XD
07/21 15:39, 7F
推
07/21 16:00, 5年前 , 8F
因為是用在管理上，高層就是看這些東西
07/21 16:00, 8F
→
07/21 16:00, 5年前 , 9F
工時就是拿來壓榨你用的 做不出來你的問題
07/21 16:00, 9F
推
07/21 16:21, 5年前 , 10F
就是一個半套的工作流搞的程式很爆炸
07/21 16:21, 10F
→
07/21 16:44, 5年前 , 11F
敏捷一般常見的是fixed deadline, 但scope是變動的
07/21 16:44, 11F
→
07/21 16:44, 5年前 , 12F
07/21 16:44, 12F
→
07/21 16:45, 5年前 , 13F
一般公司最大的誤解就是time跟scope都不可變動
07/21 16:45, 13F
→
07/21 16:45, 5年前 , 14F
那當然穩死的，這不是敏捷的問題，是濫用的問題
07/21 16:45, 14F
→
07/21 16:46, 5年前 , 15F
還有一個大前提，簽敏捷宣言的大神們，其實都是技術大神
07/21 16:46, 15F
→
07/21 16:47, 5年前 , 16F
他們發現要解決人跟協作的問題，避免流程冗重浪費的問題
07/21 16:47, 16F
→
07/21 16:47, 5年前 , 17F
所以用敏捷宣言來補上這一塊，因為他們已經沒啥技術問題
07/21 16:47, 17F
→
07/21 16:47, 5年前 , 18F
現在搞敏捷的公司，技術跟工程基底能力普遍不足
07/21 16:47, 18F
→
07/21 16:48, 5年前 , 19F
那根本敏捷不起來的，就像 http://bit.ly/30KC4nX
07/21 16:48, 19F
→
07/21 16:49, 5年前 , 20F
"為什麼 Scrum 害你們產能下降、品質低落、時程 delay"
07/21 16:49, 20F
→
07/21 16:50, 5年前 , 21F
講個結論，從你的描述看來，你公司只是把敏捷當銀彈用
07/21 16:50, 21F
→
07/21 16:50, 5年前 , 22F
跟人家在追求潮流詞彙而已，但結果會比原本的瀑布還差
07/21 16:50, 22F
實際上我們公司的規格也幾乎都是口傳 文件只是當參考註記用 沒有common lang 更沒有什麼user story的概念 或sprint的名詞 只是一直講產品要迭代 規格會改 進到QA後規格調整功能追加也是常態 ※ 編輯: yukimatoi (1.163.98.5 臺灣), 07/21/2019 16:54:41
→
07/21 16:56, 5年前 , 23F
工程師能力不一跟對專案了解度不一 跑敏捷真的是會絕頂
07/21 16:56, 23F
→
07/21 16:56, 5年前 , 24F
昇天
07/21 16:56, 24F
→
07/21 16:56, 5年前 , 25F
恩，所以只是被「buzzword形式的agile」強暴了
07/21 16:56, 25F
→
07/21 17:47, 5年前 , 26F
工時是拿來讓pm排開發功能的優先順序
07/21 17:47, 26F
→
07/21 17:48, 5年前 , 27F
一個功能複雜度13 另一個3 無相依 看pm是想先做13還是
07/21 17:48, 27F
→
07/21 17:48, 5年前 , 28F
先做3的
07/21 17:48, 28F
→
07/21 17:56, 5年前 , 29F
工時主要就用在管理 上面喜歡看到有在前進的感覺，二
07/21 17:56, 29F
→
07/21 17:56, 5年前 , 30F
來就是報價用讓上面知道要開發這個東西大約需要多少
07/21 17:56, 30F
→
07/21 17:56, 5年前 , 31F
成本。但預估歸預估實際上很難估得準，需求規格的不確
07/21 17:56, 31F
→
07/21 17:56, 5年前 , 32F
定是主因，會壓縮到後續相關的時程。
07/21 17:56, 32F
→
07/21 18:07, 5年前 , 33F
敏捷只做半套就是在壓榨工程人員..
07/21 18:07, 33F
推
07/21 20:27, 5年前 , 34F
遇過很有趣的 工時不能估太長 太長的話強制拆成兩個
07/21 20:27, 34F
→
07/21 20:28, 5年前 , 35F
以上的排程 但根本就還沒做也沒確認規格
07/21 20:28, 35F
→
07/21 20:39, 5年前 , 36F
樓上那個我遇過喔
07/21 20:39, 36F
噓
07/21 21:28, 5年前 , 37F
你能說不嗎？工時估多一點，馬上就說要這久，估少，你天
07/21 21:28, 37F
→
07/21 21:28, 5年前 , 38F
天要加班加到死，估時程是對老闆超有利的，反正工時開多
07/21 21:28, 38F
→
07/21 21:28, 5年前 , 39F
老闆會點頭嗎？跟本就是有依據讓你加班不給加班費的
07/21 21:28, 39F
推
07/21 21:48, 5年前 , 40F
推landlord大
07/21 21:48, 40F
推
07/21 21:49, 5年前 , 41F
我也遇過只有一句話就要你估工時的，估完還不能改
07/21 21:49, 41F
→
07/21 21:50, 5年前 , 42F
通常壓辦年或是八個月上線然後會延兩次
07/21 21:50, 42F
推
07/21 22:02, 5年前 , 43F
你的抱怨超寫實超有既是感哈哈哈
07/21 22:02, 43F
→
07/21 23:36, 5年前 , 44F
我遇過可能工程師裡面那段只有一個人碰過 要其他人盲估
07/21 23:36, 44F
→
07/21 23:36, 5年前 , 45F
的 這種我就覺得很微妙
07/21 23:36, 45F
推
07/22 03:08, 5年前 , 46F
壓久了 人都走光
07/22 03:08, 46F
推
07/22 04:12, 5年前 , 47F
會問這個問題的估計是連預估都不會或常常預估錯誤
07/22 04:12, 47F
→
07/22 04:13, 5年前 , 48F
但也不能怪妳啦因為預估時間這東西沒人會教你
07/22 04:13, 48F
→
07/22 08:22, 5年前 , 49F
估工時 目前看到最經典的還是 公司老工程師估完新工程師承
07/22 08:22, 49F
→
07/22 08:22, 5年前 , 50F
擔 這種絕頂升天的程度不亞於實力或認知不同時實跑scrum
07/22 08:22, 50F
推
07/22 09:07, 5年前 , 51F
不估時程，誰知道大概做多久，蓋個房子也要估時程阿，
07/22 09:07, 51F
→
07/22 09:07, 5年前 , 52F
敏捷跟瀑布一樣，前面需求分析架構做足，時程變動少，
07/22 09:07, 52F
→
07/22 09:07, 5年前 , 53F
除非中間又更動到功能跟規格
07/22 09:07, 53F
我們就是三餐在改啊
→
07/22 09:17, 5年前 , 54F
都說是估了，當然不會準啊
07/22 09:17, 54F
※ 編輯: yukimatoi (1.163.98.5 臺灣), 07/22/2019 09:25:33
→
07/22 09:28, 5年前 , 55F
跟小弟公司碰到的蠻像的 公司甚至sa跟pg是同步的 很常pg
07/22 09:28, 55F
→
07/22 09:28, 5年前 , 56F
這邊開發完了sa寫出來發現不一樣pg這又要再改
07/22 09:28, 56F
推
07/22 10:24, 5年前 , 57F
我們公司還發生新產品評估階段 業務已經賣出去好幾套
07/22 10:24, 57F
推
07/22 10:55, 5年前 , 58F
1掌握進度避免無法如期交付而被罰錢
07/22 10:55, 58F
→
07/22 10:56, 5年前 , 59F
2計算人力估價報價
07/22 10:56, 59F
→
07/22 10:56, 5年前 , 60F
比如我現在的維護案，需求來了先評估人力、工時，然後回
07/22 10:56, 60F
→
07/22 10:56, 5年前 , 61F
報這個需求需要多少人力做多久所以報價是多少，要做就開
07/22 10:56, 61F
→
07/22 10:56, 5年前 , 62F
單不做就不開單
07/22 10:56, 62F
推
07/22 12:37, 5年前 , 63F
簡單啦 預估完的時間全部乘以1.5 這樣就準多惹
07/22 12:37, 63F
推
07/22 17:48, 5年前 , 64F
改動頻率也太常了吧. 這個應該是規格溝通問題. 一直改啥
07/22 17:48, 64F
→
07/22 17:49, 5年前 , 65F
方法都沒用, 做一做, 反正還要改.
07/22 17:49, 65F
→
07/22 17:50, 5年前 , 66F
壓時間壓久了, 受不了走人, 然後loop, 公司沉淪下去.
07/22 17:50, 66F
推
07/22 18:00, 5年前 , 67F
講這麼多，幾個字就定義完了：隕石式開發
07/22 18:00, 67F
→
07/22 21:29, 5年前 , 68F
評估的時候 最好是能多花點時間 另外在評估之前 需求
07/22 21:29, 68F
→
07/22 21:29, 5年前 , 69F
應該已經有至少八成的確定 如果推倒重來 那時間肯定要
07/22 21:29, 69F
→
07/22 21:29, 5年前 , 70F
重估 返工肯定是往需求推
07/22 21:29, 70F
→
07/22 21:31, 5年前 , 71F
如果需求連讓你想像功能畫流程圖都不行 那就退貨吧 另
07/22 21:31, 71F
→
07/22 21:31, 5年前 , 72F
外需求通常都會比當前sprint 提早 最好還有人能夠 rev
07/22 21:31, 72F
→
07/22 21:31, 5年前 , 73F
iew
07/22 21:31, 73F
→
07/22 22:14, 5年前 , 74F
推同感~有一樣的疑問+1
07/22 22:14, 74F
推
07/23 00:18, 5年前 , 75F
卡
07/23 00:18, 75F
推
07/23 10:55, 5年前 , 76F
估時間只能竟量估長0.0 有時候時間真的很難估
07/23 10:55, 76F
→
07/23 10:56, 5年前 , 77F
*儘量
07/23 10:56, 77F
噓
07/24 17:14, 5年前 , 78F
加油!
07/24 17:14, 78F
推
07/25 18:58, 5年前 , 79F
這是好問題耶 但如果都不估時程 功能隨意做做個一年 這樣
07/25 18:58, 79F
→
07/25 18:58, 5年前 , 80F
公司會倒吧 估時程主要還是讓公司判斷這個產品成本多少錢
07/25 18:58, 80F
→
07/25 18:58, 5年前 , 81F
啊
07/25 18:58, 81F
→
07/25 19:00, 5年前 , 82F
我們是工程師自己估，其實估久了真的就越來越準了，有時
07/25 19:00, 82F
→
07/25 19:00, 5年前 , 83F
候發現自己估很準其實也蠻有成就感的XD
07/25 19:00, 83F
推
07/26 01:25, 5年前 , 84F
這什麼問題 RD看世界？你換個角色重新思考專案就知道預估工
07/26 01:25, 84F
→
07/26 01:25, 5年前 , 85F
時的重要性，而且預估工時是RD的基本功...
07/26 01:25, 85F
推
07/28 09:16, 5年前 , 86F
RD自估最準 但高層一句"這麼簡單哪要這久你能力不足"就...
07/28 09:16, 86F
‣ 更多 yukimatoi 的文章
文章代碼(AID): #1TD0tb_p (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 yukimatoi 的文章
文章代碼(AID): #1TD0tb_p (Soft_Job)