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

看板Soft_Job作者 (坐吃山空)時間4年前 (2019/07/24 23:14), 編輯推噓2(2推 0噓 30→)
留言32則, 8人參與, 4年前最新討論串5/9 (看更多)
預估工時本身沒有錯，問題是我們怎麼看待預估的結果 『預估工時』本身只是個工具，不是結果 如果真的要從虛工的角度來看，坦白說，連講話都是虛工。 開會更是浪費時間的極致 程式碼不就是一堆字，把字打完就收工，其他都多餘的 但是軟體開發真的是這樣嗎？ 從另外一方面來看，真正的虛工經常是管理層對於管理手段和工具的不熟悉所造成的 而不是工具本身所造成 如果每天只要上班有打卡下班有打卡就有錢拿那我每天上班兩分鐘就好 這世界就不是這麼運作的 打卡會成為一種管理工具不就是在某些組織文化下的平衡 造成一定浪費下但又能達到一定效益的結果 預估工時或是工作量 (point) 也就只是一種溝通的手段 為了讓不同背景不同經驗不同能力的人能夠有一個比較一般化的方式溝通 他是溝通的『起點』而不是終點 我不懂為什麼為了要表達其他工具也很重要的論點就要把預估工時當做沒有幫助 實際上如果連下一秒軟體專案能不能『符合預期』的運作都不能保證 其他根本都是多餘，你 QA 跟 Review 能做什麼事？ QA 完還是不知道能不能動不是搞笑嗎 預估工時的目的當然隨著專案或組織特性有所不同 但是他終究是工具的一種，不要把它當作天條，但把它當一無不值一定是有問題的 -- 【一座花崗岩島‧一段烽火歲月】 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.140.83.150 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1563981252.A.46B.html
→
07/24 23:16, 4年前 , 1F
預估工時有其必要性 但我個人認為不應該是連寫都不會寫
07/24 23:16, 1F
→
07/24 23:16, 4年前 , 2F
的人去估 這件事情
07/24 23:16, 2F
→
07/24 23:17, 4年前 , 3F
或者lv80 用自己的等級去評估 lv20的人應該做完的時間
07/24 23:17, 3F
→
07/24 23:17, 4年前 , 4F
如果玩遊戲沒顯示經驗值你的感覺如何？ 工時是必要的，
07/24 23:17, 4F
→
07/24 23:17, 4年前 , 5F
但被濫用來壓榨就不對
07/24 23:17, 5F
→
07/24 23:18, 4年前 , 6F
所以是溝通的『起點』。會讓不會寫的人估不是偶然
07/24 23:18, 6F
→
07/24 23:19, 4年前 , 7F
人事時地物都可能影響估計的結果，但是不代表估是錯的
07/24 23:19, 7F
→
07/24 23:19, 4年前 , 8F
拿來壓榨就只是工具使用錯誤
07/24 23:19, 8F
→
07/24 23:23, 4年前 , 9F
我覺得要讓不會寫的人估 可以 但可能要有一個資深的帶
07/24 23:23, 9F
→
07/24 23:24, 4年前 , 10F
不然改道死也不知道改錯了甚麼 還影響到系統正常運作
07/24 23:24, 10F
→
07/24 23:24, 4年前 , 11F
這就很麻煩了
07/24 23:24, 11F
→
07/24 23:25, 4年前 , 12F
還是要為功能買點保險吧(?)
07/24 23:25, 12F
→
07/24 23:25, 4年前 , 13F
如果你認為讓資深的帶真的就沒問題，那為什麼不提看看?
07/24 23:25, 13F
→
07/24 23:26, 4年前 , 14F
每個專案組織的權力結構不同，組織的運作不是偶然
07/24 23:26, 14F
→
07/24 23:28, 4年前 , 15F
但也不是必然。正常情況下沒人想期待專案失敗
07/24 23:28, 15F
→
07/24 23:32, 4年前 , 16F
我個人的信仰是比較接近敏捷的，所以我理解與許多人價值不同
07/24 23:32, 16F
→
07/24 23:35, 4年前 , 17F
最近有分享一些粗淺想法，請參考: https://reurl.cc/RNdrz
07/24 23:35, 17F
→
07/25 00:28, 4年前 , 18F
我覺得意義是1.完成2.未完成，沒了。
07/25 00:28, 18F
→
07/25 00:31, 4年前 , 19F
不是很確定樓上的意思，也許我們要先定義意義的是什麼 XD
07/25 00:31, 19F
→
07/25 00:32, 4年前 , 20F
從另一個角度來說，應該說誰能真的知道東西『完成』了
07/25 00:32, 20F
→
07/25 00:33, 4年前 , 21F
也許這輩子都沒有『完成』的一天?
07/25 00:33, 21F
→
07/25 09:44, 4年前 , 22F
Hi 樓上，您上面那幾句，正是我的想法。
07/25 09:44, 22F
→
07/25 11:40, 4年前 , 23F
以專案管理的角度來說，一個專案必定有始有終
07/25 11:40, 23F
→
07/25 11:43, 4年前 , 24F
如果完成專案之後還要進行改進，那麼要再開一個維護案
07/25 11:43, 24F
→
07/25 11:57, 4年前 , 25F
我自己想法努力的讓專案越早關越好，不止維護分開，甚至原
07/25 11:57, 25F
→
07/25 11:57, 4年前 , 26F
型跟產品開發階段都可以分成多個階段，才能聚焦需求保持品
07/25 11:57, 26F
→
07/25 11:57, 4年前 , 27F
質
07/25 11:57, 27F
推
07/25 11:58, 4年前 , 28F
推
07/25 11:58, 28F
→
07/25 11:59, 4年前 , 29F
而怎麼讓專案越早關的方法很多，改需求也是一種
07/25 11:59, 29F
→
07/25 12:07, 4年前 , 30F
聚焦在可完成的需求跟可接受的品質下盡早產生產品獲得回饋
07/25 12:07, 30F
→
07/25 16:47, 4年前 , 31F
到底怎樣保證下一秒軟體專案能『符合預期』的運作?
07/25 16:47, 31F
推
07/28 09:27, 4年前 , 32F
為了做好事情的期望值,被扭曲成評價個人能力搾出產能的手段
07/28 09:27, 32F
‣ 更多 Feis 的文章
文章代碼(AID): #1TE7N4Hh (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 5 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
‣ 更多 Feis 的文章
文章代碼(AID): #1TE7N4Hh (Soft_Job)