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