預估工時本身沒有錯，問題是我們怎麼看待預估的結果
『預估工時』本身只是個工具，不是結果
如果真的要從虛工的角度來看，坦白說，連講話都是虛工。
開會更是浪費時間的極致
程式碼不就是一堆字，把字打完就收工，其他都多餘的
但是軟體開發真的是這樣嗎？
從另外一方面來看，真正的虛工經常是管理層對於管理手段和工具的不熟悉所造成的
而不是工具本身所造成
如果每天只要上班有打卡下班有打卡就有錢拿那我每天上班兩分鐘就好
這世界就不是這麼運作的
打卡會成為一種管理工具不就是在某些組織文化下的平衡
造成一定浪費下但又能達到一定效益的結果
預估工時或是工作量 (point) 也就只是一種溝通的手段
為了讓不同背景不同經驗不同能力的人能夠有一個比較一般化的方式溝通
他是溝通的『起點』而不是終點
我不懂為什麼為了要表達其他工具也很重要的論點就要把預估工時當做沒有幫助
實際上如果連下一秒軟體專案能不能『符合預期』的運作都不能保證
其他根本都是多餘，你 QA 跟 Review 能做什麼事？
QA 完還是不知道能不能動不是搞笑嗎
預估工時的目的當然隨著專案或組織特性有所不同
但是他終究是工具的一種，不要把它當作天條，但把它當一無不值一定是有問題的

到底怎樣保證下一秒軟體專案能『符合預期』的運作?

而怎麼讓專案越早關的方法很多，改需求也是一種聚焦在可完成的需求跟可接受的品質下盡早產生產品獲得回饋

推

我自己想法努力的讓專案越早關越好，不止維護分開，甚至原型跟產品開發階段都可以分成多個階段，才能聚焦需求保持品質

以專案管理的角度來說，一個專案必定有始有終如果完成專案之後還要進行改進，那麼要再開一個維護案

Hi 樓上，您上面那幾句，正是我的想法。

不是很確定樓上的意思，也許我們要先定義意義的是什麼 XD從另一個角度來說，應該說誰能真的知道東西『完成』了也許這輩子都沒有『完成』的一天?

我覺得意義是1.完成2.未完成，沒了。

如果你認為讓資深的帶真的就沒問題，那為什麼不提看看?每個專案組織的權力結構不同，組織的運作不是偶然但也不是必然。正常情況下沒人想期待專案失敗我個人的信仰是比較接近敏捷的，所以我理解與許多人價值不同最近有分享一些粗淺想法，請參考: https://reurl.cc/RNdrz

我覺得要讓不會寫的人估 可以 但可能要有一個資深的帶不然改道死也不知道改錯了甚麼 還影響到系統正常運作這就很麻煩了還是要為功能買點保險吧(?)

所以是溝通的『起點』。會讓不會寫的人估不是偶然人事時地物都可能影響估計的結果，但是不代表估是錯的拿來壓榨就只是工具使用錯誤

如果玩遊戲沒顯示經驗值你的感覺如何？ 工時是必要的，但被濫用來壓榨就不對

預估工時有其必要性 但我個人認為不應該是連寫都不會寫的人去估 這件事情或者lv80 用自己的等級去評估 lv20的人應該做完的時間

為了做好事情的期望值,被扭曲成評價個人能力搾出產能的手段