作者TonyQ (得理饒人)
看板Soft_Job
標題Re: [請益] 預估工時的意義在哪？
時間Wed Jul 24 09:01:15 2019
※ 引述《yukimatoi (纏)》之銘言：
: 我們公司的流程是
: 評估市場需求→PM提案→設計師開規格→RD實作→QA→發布
: 實際上是什麼開發流程我是不知道
: 網路上有看過離職的前輩說這是瀑布式
: 公司這幾年又把一些敏捷的思想帶進來...
: 說因為沒有一個人神到可以設計出最終規格
: 所以產品要不斷迭代 RD可以先做出一個成品給設計師看 跟設計師互相討論
: 但矛盾的是 我們的產品上線時間很早就被敲定
: 所以大部分的專案 下場就是沒有得到足夠的迭代
: 最後不是砍規格 就是RD跟設計師一起加班趕進度
: 甚至還有上線兩個月前規格才完成的狀況
: 我也問過主管 這樣迭代真的足夠嗎？ 主管只說：恩，公司要賺錢
: PM最喜歡的就是預估時程 畫滿甘特圖 預期最後有幾個功能會完成
: 但最常見的狀況就是規格大改(因為我們會迭代)
: 不然就是RD為了進度hard code才勉強滿足進度
: 反正有問題就看誰倒楣誰修誰接手
: RD大老雖然說要推行test 但是跟PM根本沒有共識 專案進度也沒有排入test撰寫的閒暇
: 所以RD要不就是自願加班寫test 要不就是乾脆不寫 或是寫一些無關緊要的test
: 我不知道是不是只有我們公司才這樣
: 還是這是業界常態只是我太菜了
: 我是真的不太懂預估工時的意義到底在哪
: 工時預估準確 ─┬→ 可喜可賀
: └→ 規格變更 ─→ 完成時間延長(然後叫你再估一次工時)
: 工時預估不準 ─┬→ RD遜砲，請重估
: ├→ RD報喜不報憂 留下技術債
: └→ 規格變更 ─→ 完成時間延長(再估一次)
: 工時不管預估準不準確，都不能影響專案目前的進度以及實際上需要的時間
: (實際需要的時間 大概只有神知道)
: 但預估工時反而會給PM「一切都在我的掌握之中 專案都在軌道上」的錯覺
: 還是說我誤解了預估工時的目的 有沒有人可以指點一下？ 謝謝
這問題要看你從哪個角度來看,
基本上你是 PG / SA / PM / sales / Manager 角度都不一樣.
PG: 預估工時是為了估算自己的價值跟確保自己的產能順利不受干擾
SA: 預估工時是為了協調系統跟系統間界接,
確保對接的 frame 最小跟架構調整最適合
PM: 預估工時是為了確認業務單位(user side) 跟市場需求的滿足程度
SALES: 什麼時候可以開記者會(敲碗)
Manager: 用來評估 Cost & Resource 是否合理.
但請記得, 上面的其中沒有任何一點是為了[增進產品的品質] .
Product Quality 跟時間永遠是帶點矛盾的事情.
這就跟差勤或打卡紀錄或工作日報一樣, 本身是多做的虛工,
但卻為了組織的協調跟因為不存在上帝視角, 所以不得不存在的產物.
另外所有專案的成敗跟專案是不是正確的,
都應該有個 product owner 要為其負責. 誰做決定, 誰扛責.
如果負責人沒有話事權, 那就不會有穩定的專案.
不管你覺得自己是什麼式,
沒有腦袋清楚的人掌握產品線, 最後產品就會什麼都不是.
我管 team , 我手上的時程有兩種,
一種叫真的, 一種叫假的.
假的並不是說我估的不準, 而是只要有更重要的事情進來, 他就會被推後.
真的是時候到了沒做好, 那美剋星就會毀滅.
(雖然毀滅那美剋星的那前五分鐘通常會特別久,
但那肯定不是我們時程估的不準, 而是編劇想拖戲.(喂) )
我待過很多間公司, 不是公司想做好, 產品就會做好,
也不是有錢的公司就會做好,
這題本質重點還是在帶隊的人腦袋清不清醒.......
而且一間公司至少要有三隻柱子是清醒的,
一個是 leader 不能昏庸, 一個是開發端架構規劃不能蠢,
最後一個是 user 不能只想把責任丟給開發端.
pm 我倒不是非常看重,
多數情況下 pm 就是協助角色, 不是真正決定的角色.
這三個只要有一個不行, 基本上不用撐, 能閃多遠走多遠,
不然就自己站到這三隻腳的其中一隻腳去, 至少是自食惡果.
畢竟, 你面對生鏽報廢的引擎的時候,
不會去考慮你該拿螺絲起子還是六角板手吧?
換個新的引擎才是真的.
方法論只是方法論, 人才是執行方法論的主體,
錯誤的人的環境長不出什麼漂亮的花朵.
--
I have a dream, it's silly but beautiful.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.21.72 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1563930077.A.0DF.html
※ 編輯: TonyQ (61.231.21.72 臺灣), 07/24/2019 09:04:33
※ 編輯: TonyQ (61.231.21.72 臺灣), 07/24/2019 09:07:14
1F：→ pttworld: sales拿到PM預估的工時是要換算後報價給客戶的 07/24 09:12
2F：→ MOONY135: 三本柱 07/24 09:13
3F：→ pttworld: 正規的專案公司還有養PM Team, 怎麼可能只有協助 07/24 09:15
4F：→ benqm300: 人柱力 07/24 09:20
5F：→ pttworld: 這篇一看就知道沒當過專案經理，你說的時程就是 07/24 09:24
6F：→ pttworld: 你的頭銜不是專案經理是因為不是專案公司 07/24 09:25
看不懂你在講什麼，先組織組織再回吧。
7F：推 jack0204: 是不是要先抓一隻神獸封印在身上才能當柱子? 07/24 09:29
那個叫祭品，不是柱子喔。QQ
8F：推 xam: 這篇就技術base的PM+PL啊, 我支持.. 07/24 09:46
9F：→ ckp4131025: 第三根柱子是user? 07/24 10:21
這裡我講的 user 比較算是企劃或是負責需提供求的角色，有所節制的 user 是很重要的。
10F：推 ime5566: 原來是Tonyq 07/24 10:39
11F：→ fgh81113: 架構規劃已經倒了 還有沒有救... 07/24 10:41
理論上其實要把架構做倒但公司不倒，還滿難得，通常的情況是人倒了而不是架構倒了。
12F：推 massrelay: 蠻認同，不過還是需要PM幫忙盯不然容易漏東西。 07/24 10:53
這篇是在談時程預估對專案管理的影響，如果談專案本身的管理要補的也不是這三言兩語而已。
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 11:03:44
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 11:04:18
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 11:04:39
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 11:08:48
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 11:12:39
13F：→ Feis: 不認同，預估工時跟品質當然有關 07/24 12:15
廣義來說，所有事情都跟結果有關，員工家庭生活是否和諧都會跟品質有關。
但實際上還是有些更核心的事情要探討。舉例，如果沒有人釘時程，那時程就會形同虛設。
這種情況下他對專案影響就不會太大。
又舉例，老闆是個 asshole 整天叫你用一天做一個月的事情，你就會覺得預估時間真是問題的根源。
但真正的問題並不是預估時間本身，而是權力怎麼被揮舞跟決策怎麼形成。
你越認為預估時間重要，他對你來說的傷害就越重要。
我的風格比較算是價值管理，每個東西的時間是分級的，有些時間重要，有些時間不重要。
會覺得預估時間對品質重要的，實質上是因為環境把權力寄生在無辜的預估時間上而已。
另外預估時間對改善品質，我還是要強調，我認為沒有幫助。
14F：→ lnmlee: 預估工時就是預計時間成本 講那麼多平行世界要尬嘛？ 07/24 12:40
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 12:54:52
15F：推 banana13: pm就是為了給老闆交代產出產品，pg就是被要求使命必達 07/24 12:57
16F：→ banana13: 達不到就加班 07/24 12:57
17F：→ Feis: 如果連明天能不能上架都無法預估，真不知道怎麼做專案… 07/24 13:12
假設是正常的專案流程，到上架之前至少有六次的預估跟檢核要做。
如果你跳過所有的檢核，直接到上架前一天才來倚賴預估，我想是真的不知道要怎麼做專案沒錯。
沒有準確的預估，不代表你放棄 QA 放棄 review ，放棄所有確認專案目前狀態的手段好嗎？
18F：→ Feis: 見識太少，尊重你的看法 07/24 13:14
不是不預估，而是估不準不會死。
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 13:29:25
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 13:31:23
19F：推 ian90911: 中肯推 07/24 14:49
20F：推 hakama99: 推 07/24 15:28
21F：推 mathrew: 理想總是美好的 07/24 16:26
22F：推 menesn: 感謝分享 07/24 17:31
23F：推 SuperCry: 一直想到陳綺貞的歌 07/24 19:10
24F：推 gmoz: 扳手 不是板手QQ 07/24 22:22
25F：→ gmoz: 最近靠北樂團才在吵這個(X 07/24 22:23
26F：推 Feis: 「預估時間對品質，我認為沒有幫助」這中文理解有障礙 07/24 22:27
27F：→ Feis: 我有說要放棄其他方法嗎 07/24 22:27
28F：→ Feis: 我只是不認同沒幫助這件事，沒幫助還是要做，所以就是有幫助 07/24 22:28
29F：→ Feis: 呀 07/24 22:28
30F：→ Feis: 這邏輯…… 07/24 22:28
31F：→ Feis: 軟體專案以人為本，預估時間也是個工具，政治手段也是個工 07/24 22:31
32F：→ Feis: 具，不要以偏概全 07/24 22:31
33F：→ Feis: 抱歉，一開始就不應該回應… 07/24 22:34
你每天過馬路要看紅綠燈，這是個要做的事情。
他對你的幫助叫做保護你的安全。而不是讓你賺大錢。
當然你可以說你被撞死了就不能賺大錢，定義上不會有錯，但他畢竟不是直接相關。
同理，預估工時只是個概估的基準，他讓你的團隊心裡有個底。
但這個底跟品質沒關係。
要說的話，頂多只跟這件事情能不能被完成有關，但能不能被完成跟品質好不好是兩碼子事。
34F：→ thund: 沒幫助還是要做=有幫助 這等式不成立吧 07/25 00:32
35F：→ Feis: 是的，我們都在做沒幫助的事。我猜原作者的論點不是這方向 07/25 00:36
36F：→ Feis: 我原本的認知是要透過測試稽核之類的去決定狀態 07/25 00:38
37F：→ Feis: 而測試稽核不是建立在預估工時上是我原本以為的論點 07/25 00:39
38F：→ Feis: 我自己的論點是，短期的預估工時是無可避免的 07/25 00:40
39F：→ Feis: 而預估工時是個工具，工具有好有壞，有用對有用錯 07/25 00:41
我不太理解為什麼對品質沒幫助等於不需要做的事情。
專案中多的是對品質沒幫助，但需要做的事情。
比方說砍功能或在功能未完成時，提早上線，就是個犧牲品質來成就市場的手段。
品質不是一切啊。
40F：→ thund: 本篇也沒說要放棄預估工時啊 只是說對品質沒有幫助 07/25 00:42
41F：→ thund: 重點是在更上層的問題 而不是預估工時這件事的好壞 07/25 00:43
42F：→ Feis: 了解，所以現在主題變成為什麼要做沒幫助的事 ? 07/25 00:43
43F：→ thund: 沒啥毛病啊 07/25 00:43
44F：→ Feis: 是嗎？如果完全沒辦法預估工時，你怎麼決定什麼時候稽核? 07/25 00:44
不管我我預估多久，我還是可以每週稽核啊。
45F：→ thund: 喔 我的天 我看是你理解有問題....... 07/25 00:46
46F：→ Feis: 我能理解有更上層的問題，但是這篇的意思就是『預估時間對 07/25 00:46
47F：→ Feis: 品質沒有幫助』 07/25 00:46
48F：→ Feis: 可以指教一下嗎？ 07/25 00:46
49F：→ Feis: 我只是對這點表達不認同 07/25 00:47
50F：→ Feis: 『估不準不會死』我也認同，要估六次十次我也認同 07/25 00:57
51F：→ Feis: 那結論不就是要嘛做這些事與品質無關要嘛有關 07/25 00:58
52F：→ Feis: 原作者論點是『無關』，但我無法認同而已 07/25 00:58
53F：→ Feis: 抱歉糾正，是有沒有幫助 07/25 00:58
54F：→ Feis: 如果『沒有幫助』卻又要『做』的邏輯是什麼，需要有人指導我 07/25 00:59
55F：→ Feis: 我想表達的是工具本身是中性的，使用工具的人才是問題 07/25 01:05
56F：→ Feis: 不要因為人的問題就去說工具沒有用 07/25 01:05
我沒說他沒用，只是他的用途不是提高品質。
57F：→ Feis: 而工具有學習成本有使用風險，這些都是專案管理要考量的 07/25 01:08
58F：→ Feis: 挑適合的工具給適合的團隊創造適合的文化 07/25 01:28
59F：→ Feis: 才是專案管理者該走的路跟價值 (當然是我自以為 07/25 01:31
60F：推 bakedgrass: 不太明白User不能把責任都丟給開發端是甚麼意思？ 07/25 02:16
61F：→ bakedgrass: 是指User必須試著適應開發出來的軟體？ 07/25 02:16
62F：→ bakedgrass: 一般說來User不會是開發團隊可以掌握的因素吧 07/25 02:17
這裡的 user 基本上是企劃或是自認為自己是 user 代表的人。
舉例，明明就是個 toto list ， user 要求系統要能看客戶的行事曆猜到他要幹嘛幫他寫 todo 就是個 over kill 的要求。
很多時候他們會跳入提供更多功能，而不是解決問題的陷阱裡面。
63F：推 zombiesky: To Feis, 人活著需要氧氣和食物,氧氣和飽足無關,但沒有 07/25 08:14
64F：→ zombiesky: 氧氣會死, 所以還是要氧氣 07/25 08:15
65F：→ zombiesky: 專案管理要顧的不是只有品質,預估時程的目的不是提升品 07/25 08:17
66F：→ zombiesky: 質,但有其他作用,本文有提到 07/25 08:18
67F：推 zombiesky: To Bakedgrass,前面TonyQ有回應,這裡的User指的是代表 07/25 08:21
68F：→ zombiesky: User的人,ex. Product Owner 07/25 08:21
69F：推 ku399999: ...開宗明義不是就講估工時的功能了嗎 07/25 08:36
70F：推 jjwei: push 07/25 08:37
71F：推 bakedgrass: 看到了，謝謝zombiesky 07/25 08:46
72F：→ Feis: 了解，可能是大家對品質的定義不同。可能是我誤解，謝謝 07/25 09:08
73F：→ Feis: 沒有氧氣會死，所以飽足跟氧氣無關。可能是這邏輯我誤會了 07/25 09:10
74F：→ Feis: 我原本以為是不需要預估時程也可以確保品質。 07/25 09:10
的確是不需要準確的預估工時也能確保品質，準確的預估工時實際上是跨團隊合作才需要的東西。你跨的團隊越多他準確性越重要。
但他實際上是個政治工具，而不是品質工具。
就算你能把時間都估到神準，還是不會讓產品變厲害，要讓品質變好需要的是別的東西，例如正確的規劃跟品管。
時間是品質的劣化指標，加入對時間的要求都很難避免對品質的負面影響。
(但我的意思並不是因為這樣就不要求時間，而是要留意到趕工跟品質的取捨。)
75F：→ Feis: 每個人對專案品質的定義不同，打擾大家了 QQ 07/25 09:11
76F：→ DrTech: 這根公司產品性質強相關吧。有些工時估不準，或隨意延後。 07/25 09:16
77F：→ DrTech: 公司會被罰鉅額的。 07/25 09:16
78F：→ DrTech: 某些產業或環境，亂估工時真的是會沒工作的。要看環境。 07/25 09:18
但那是環境給他的限制，而不是預估工時本身的需求。
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/25/2019 09:28:25
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/25/2019 09:30:06
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/25/2019 09:31:02
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/25/2019 09:31:39
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/25/2019 09:32:13
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/25/2019 09:34:47
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/25/2019 09:39:19
79F：→ Feis: 所以規劃不需要預估時間的意思嗎，我越來越混亂XD 當然不用 07/25 09:50
80F：→ Feis: 神準 07/25 09:50
我從來沒說不需要預估時間, 這應該是我第三次強調了,
我說的是預估時間不會提升品質.
是你要加上[不會提升品質的就不用做]的前提才會解讀成這樣.
81F：→ Jockey66666: 上述的規劃應該是指產品設計面上的規劃, 不包含時間 07/25 10:03
82F：→ Feis: 照這意思是產品設計時不考慮做不做得完，那我就完全理解了 07/25 10:05
83F：→ Feis: 感恩 07/25 10:05
你只做做得完的事情跟品質提升有什麼關係?
通常就是因為你只做做得完的事情品質才會下降啊.
[品質]不是專案的唯一指標, 更多的時候我們是不考慮品質的再進行專案,
我是覺得你把[品質]跟[完成專案]這兩個詞弄混了.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:10:17
84F：推 bakedgrass: 謝謝解釋 07/25 10:12
85F：→ Feis: 我沒誤會，我以為品質是建立在有做完產品的前提 07/25 10:14
我認為完成產品是完成產品, 品質是品質.
不然在你這定義底下的 [完成產品], 會很容易變成被情緒勒索的基礎,
任何人只要試著透過政治力加需求讓你無法完成, 就可以靠北你品質很爛了.
在這樣基礎上你在技術上的攻防會花非常多的時間, 在處理需求的進出.
品質跟完成還是獨立線, 才是比較適合的評估工具.
通常我都會說, 你想要改善專案品質我明白,
但你改善品質的手段過頭專案就會無法完成.
所以我說, 預估時間是個政治問題, 不是品質工具.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:17:50
86F：→ Feis: 是我誤解品質，抱歉 07/25 10:14
87F：→ Feis: 這產品品質很好只是沒做完，我以為這不是前提的 07/25 10:16
所以現實上才會有砍產品品質要素, 來加速上線的手段啊.
完成專案也是重要的, 只是完成專案本身也不是一個品質指標,
為了讓專案完成本身並不會提高體驗, 也不會讓產品更好.
沒人說你要只顧品質而不讓專案完成.
只是講清楚專案完成跟品質一點屁關係也沒有.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:20:49
88F：→ Feis: 我不覺得獨立比較好，不過尊重你論點 07/25 10:20
89F：→ Feis: 加速上市不一定要犧牲品質 07/25 10:20
我說有 (犧牲品質(P) -> 加速上市(Q) 的手段) 是基於這樣的目的.
你要跟我說有 加速上市 Q -> 非P (不用犧牲品質),
這兩個不是衝突的好嗎......
我說的是在某些時候我們會選擇犧牲品質來加速上市,
並不等於我說所有的加速上市都是犧牲品質.....
如果你連這麼基本的理則學都沒辦法想清楚再回,
我會建議你, 先再想一想.......
不然你會一直搞不懂別人再回什麼.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:23:13
90F：→ Feis: 不過還是回到品質的定義問題，是我誤會。 07/25 10:21
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:23:58
91F：→ Feis: 了解，我那句並不是要否定。抱歉 07/25 10:24
92F：→ pttworld: 預估工時的時候就要把品質預估進去 07/25 10:24
那你預估工時的時候,
要不要把明天會發生七級大地震的風險也估進去.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:25:31
93F：→ pttworld: 估出來的工時就是品質預測後所定的時程 07/25 10:26
94F：→ pttworld: 你所謂的品質也是你預測做出來會是怎樣的 07/25 10:27
95F：→ pttworld: 時程3個人月和6個人月，做出來的品質本來心裡就要有底 07/25 10:32
96F：→ pttworld: 開發中期review後發現要tune, 要看有沒buffer可以用 07/25 10:40
97F：→ pttworld: 這個buffer也是當初預估工時就要留的 07/25 10:41
這串在討論的就是預估過程中產生的變化, 導致原本的估計是異常的,
在這樣的前提下在探討預估的價值.
不會變動的或可預測的, 自然不會有這種問題.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 11:06:07
98F：推 yahuichang: 一般要做一年案子，前家公司總經理要求三個月上線，理 07/25 11:32
99F：→ yahuichang: 由是要讓業務員早點使用，這也是我有有史以加班破表， 07/25 11:32
100F：→ yahuichang: 當然上線品質不佳，假日被on call。 07/25 11:32
101F：推 Arctica: 認同估工時就只是個政治工具，通常就是為估而估，搞到最 07/25 11:37
102F：→ Arctica: 後還是會有對內對外兩套工時.... 07/25 11:37
103F：推 yahuichang: 我那是完全沒估，PM應當手上有多少資源，排出工期工時 07/25 11:42
104F：→ yahuichang: ，只會壓時程。 07/25 11:42
105F：推 strlen: 沒錯！一堆方法 人不配合 還是搞不出什麼毛 人才是最大的 07/25 13:54
106F：→ strlen: 變因 其實也差不多什唯一嚴重的變因 07/25 13:54
107F：推 vencil: 推這篇 07/25 16:11
108F：→ umum29: 我在國外看到的PM是真的可以主導產品走向的要角 07/26 03:00
其實職稱是假的，重點是他被賦予的職責才是真的。我在美國也待了一年，國外沒比較厲害，重點還是在不同角色之間的彼此妥協。
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/26/2019 08:10:11
109F：推 DirtyVegas: 推 07/28 23:33
110F：推 justbecause0: 推 跟我看的的狀況比較吻合 07/29 08:31
111F：推 masan22305: 認同Tony大觀點，不過很清楚的看到PG跟PM所認定的品 08/15 09:19
112F：→ masan22305: 質不同 科科 08/15 09:19