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

看板Soft_Job作者 (得理饒人)時間4年前 (2019/07/24 09:01), 4年前編輯推噓27(27推 0噓 85→)
留言112則, 33人參與, 4年前最新討論串4/9 (看更多)
※ 引述《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://www.ptt.cc/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
→
07/24 09:12, 4年前 , 1F
sales拿到PM預估的工時是要換算後報價給客戶的
07/24 09:12, 1F
→
07/24 09:13, 4年前 , 2F
三本柱
07/24 09:13, 2F
→
07/24 09:15, 4年前 , 3F
正規的專案公司還有養PM Team, 怎麼可能只有協助
07/24 09:15, 3F
→
07/24 09:20, 4年前 , 4F
人柱力
07/24 09:20, 4F
→
07/24 09:24, 4年前 , 5F
這篇一看就知道沒當過專案經理，你說的時程就是
07/24 09:24, 5F
→
07/24 09:25, 4年前 , 6F
你的頭銜不是專案經理是因為不是專案公司
07/24 09:25, 6F
看不懂你在講什麼，先組織組織再回吧。
推
07/24 09:29, 4年前 , 7F
是不是要先抓一隻神獸封印在身上才能當柱子?
07/24 09:29, 7F
那個叫祭品，不是柱子喔。QQ
推
07/24 09:46, 4年前 , 8F
這篇就技術base的PM+PL啊, 我支持..
07/24 09:46, 8F
→
07/24 10:21, 4年前 , 9F
第三根柱子是user?
07/24 10:21, 9F
這裡我講的 user 比較算是企劃或是負責需提供求的角色，有所節制的 user 是很重要的。
推
07/24 10:39, 4年前 , 10F
原來是Tonyq
07/24 10:39, 10F
→
07/24 10:41, 4年前 , 11F
架構規劃已經倒了 還有沒有救...
07/24 10:41, 11F
理論上其實要把架構做倒但公司不倒，還滿難得，通常的情況是人倒了而不是架構倒了。
推
07/24 10:53, 4年前 , 12F
蠻認同，不過還是需要PM幫忙盯不然容易漏東西。
07/24 10:53, 12F
這篇是在談時程預估對專案管理的影響，如果談專案本身的管理要補的也不是這三言兩語而已。 ※ 編輯: 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
→
07/24 12:15, 4年前 , 13F
不認同，預估工時跟品質當然有關
07/24 12:15, 13F
廣義來說，所有事情都跟結果有關，員工家庭生活是否和諧都會跟品質有關。 但實際上還是有些更核心的事情要探討。舉例，如果沒有人釘時程，那時程就會形同虛設。 這種情況下他對專案影響就不會太大。 又舉例，老闆是個 asshole 整天叫你用一天做一個月的事情，你就會覺得預估時間真是問題的根源。 但真正的問題並不是預估時間本身，而是權力怎麼被揮舞跟決策怎麼形成。 你越認為預估時間重要，他對你來說的傷害就越重要。 我的風格比較算是價值管理，每個東西的時間是分級的，有些時間重要，有些時間不重要。 會覺得預估時間對品質重要的，實質上是因為環境把權力寄生在無辜的預估時間上而已。 另外預估時間對改善品質，我還是要強調，我認為沒有幫助。
→
07/24 12:40, 4年前 , 14F
預估工時就是預計時間成本 講那麼多平行世界要尬嘛？
07/24 12:40, 14F
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 12:54:52
推
07/24 12:57, 4年前 , 15F
pm就是為了給老闆交代產出產品，pg就是被要求使命必達
07/24 12:57, 15F
→
07/24 12:57, 4年前 , 16F
達不到就加班
07/24 12:57, 16F
→
07/24 13:12, 4年前 , 17F
如果連明天能不能上架都無法預估，真不知道怎麼做專案…
07/24 13:12, 17F
假設是正常的專案流程，到上架之前至少有六次的預估跟檢核要做。 如果你跳過所有的檢核，直接到上架前一天才來倚賴預估，我想是真的不知道要怎麼做專案沒錯。 沒有準確的預估，不代表你放棄 QA 放棄 review ，放棄所有確認專案目前狀態的手段好嗎？
→
07/24 13:14, 4年前 , 18F
見識太少，尊重你的看法
07/24 13:14, 18F
不是不預估，而是估不準不會死。 ※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 13:29:25 ※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 13:31:23
推
07/24 14:49, 4年前 , 19F
中肯推
07/24 14:49, 19F
推
07/24 15:28, 4年前 , 20F
推
07/24 15:28, 20F
推
07/24 16:26, 4年前 , 21F
理想總是美好的
07/24 16:26, 21F
推
07/24 17:31, 4年前 , 22F
感謝分享
07/24 17:31, 22F
推
07/24 19:10, 4年前 , 23F
一直想到陳綺貞的歌
07/24 19:10, 23F
推
07/24 22:22, 4年前 , 24F
扳手 不是板手QQ
07/24 22:22, 24F
→
07/24 22:23, 4年前 , 25F
最近靠北樂團才在吵這個(X
07/24 22:23, 25F
推
07/24 22:27, 4年前 , 26F
「預估時間對品質，我認為沒有幫助」這中文理解有障礙
07/24 22:27, 26F
→
07/24 22:27, 4年前 , 27F
我有說要放棄其他方法嗎
07/24 22:27, 27F
→
07/24 22:28, 4年前 , 28F
我只是不認同沒幫助這件事，沒幫助還是要做，所以就是有幫助
07/24 22:28, 28F
→
07/24 22:28, 4年前 , 29F
呀
07/24 22:28, 29F
→
07/24 22:28, 4年前 , 30F
這邏輯……
07/24 22:28, 30F
還有 50 則推文
還有 8 段內文
→
07/25 10:03, 4年前 , 81F
上述的規劃應該是指產品設計面上的規劃, 不包含時間
07/25 10:03, 81F
→
07/25 10:05, 4年前 , 82F
照這意思是產品設計時不考慮做不做得完，那我就完全理解了
07/25 10:05, 82F
→
07/25 10:05, 4年前 , 83F
感恩
07/25 10:05, 83F
你只做做得完的事情跟品質提升有什麼關係? 通常就是因為你只做做得完的事情品質才會下降啊. [品質]不是專案的唯一指標, 更多的時候我們是不考慮品質的再進行專案, 我是覺得你把[品質]跟[完成專案]這兩個詞弄混了. ※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:10:17
推
07/25 10:12, 4年前 , 84F
謝謝解釋
07/25 10:12, 84F
→
07/25 10:14, 4年前 , 85F
我沒誤會，我以為品質是建立在有做完產品的前提
07/25 10:14, 85F
我認為完成產品是完成產品, 品質是品質. 不然在你這定義底下的 [完成產品], 會很容易變成被情緒勒索的基礎, 任何人只要試著透過政治力加需求讓你無法完成, 就可以靠北你品質很爛了. 在這樣基礎上你在技術上的攻防會花非常多的時間, 在處理需求的進出. 品質跟完成還是獨立線, 才是比較適合的評估工具. 通常我都會說, 你想要改善專案品質我明白, 但你改善品質的手段過頭專案就會無法完成. 所以我說, 預估時間是個政治問題, 不是品質工具. ※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:17:50
→
07/25 10:14, 4年前 , 86F
是我誤解品質，抱歉
07/25 10:14, 86F
→
07/25 10:16, 4年前 , 87F
這產品品質很好只是沒做完，我以為這不是前提的
07/25 10:16, 87F
所以現實上才會有砍產品品質要素, 來加速上線的手段啊. 完成專案也是重要的, 只是完成專案本身也不是一個品質指標, 為了讓專案完成本身並不會提高體驗, 也不會讓產品更好. 沒人說你要只顧品質而不讓專案完成. 只是講清楚專案完成跟品質一點屁關係也沒有. ※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:20:49
→
07/25 10:20, 4年前 , 88F
我不覺得獨立比較好，不過尊重你論點
07/25 10:20, 88F
→
07/25 10:20, 4年前 , 89F
加速上市不一定要犧牲品質
07/25 10:20, 89F
我說有 (犧牲品質(P) -> 加速上市(Q) 的手段) 是基於這樣的目的. 你要跟我說有 加速上市 Q -> 非P (不用犧牲品質), 這兩個不是衝突的好嗎...... 我說的是在某些時候我們會選擇犧牲品質來加速上市, 並不等於我說所有的加速上市都是犧牲品質..... 如果你連這麼基本的理則學都沒辦法想清楚再回, 我會建議你, 先再想一想....... 不然你會一直搞不懂別人再回什麼. ※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:23:13
→
07/25 10:21, 4年前 , 90F
不過還是回到品質的定義問題，是我誤會。
07/25 10:21, 90F
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:23:58
→
07/25 10:24, 4年前 , 91F
了解，我那句並不是要否定。抱歉
07/25 10:24, 91F
→
07/25 10:24, 4年前 , 92F
預估工時的時候就要把品質預估進去
07/25 10:24, 92F
那你預估工時的時候, 要不要把明天會發生七級大地震的風險也估進去. ※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:25:31
→
07/25 10:26, 4年前 , 93F
估出來的工時就是品質預測後所定的時程
07/25 10:26, 93F
→
07/25 10:27, 4年前 , 94F
你所謂的品質也是你預測做出來會是怎樣的
07/25 10:27, 94F
→
07/25 10:32, 4年前 , 95F
時程3個人月和6個人月，做出來的品質本來心裡就要有底
07/25 10:32, 95F
→
07/25 10:40, 4年前 , 96F
開發中期review後發現要tune, 要看有沒buffer可以用
07/25 10:40, 96F
→
07/25 10:41, 4年前 , 97F
這個buffer也是當初預估工時就要留的
07/25 10:41, 97F
這串在討論的就是預估過程中產生的變化, 導致原本的估計是異常的, 在這樣的前提下在探討預估的價值. 不會變動的或可預測的, 自然不會有這種問題. ※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 11:06:07
推
07/25 11:32, 4年前 , 98F
一般要做一年案子，前家公司總經理要求三個月上線，理
07/25 11:32, 98F
→
07/25 11:32, 4年前 , 99F
由是要讓業務員早點使用，這也是我有有史以加班破表，
07/25 11:32, 99F
→
07/25 11:32, 4年前 , 100F
當然上線品質不佳，假日被on call。
07/25 11:32, 100F
推
07/25 11:37, 4年前 , 101F
認同估工時就只是個政治工具，通常就是為估而估，搞到最
07/25 11:37, 101F
→
07/25 11:37, 4年前 , 102F
後還是會有對內對外兩套工時....
07/25 11:37, 102F
推
07/25 11:42, 4年前 , 103F
我那是完全沒估，PM應當手上有多少資源，排出工期工時
07/25 11:42, 103F
→
07/25 11:42, 4年前 , 104F
，只會壓時程。
07/25 11:42, 104F
推
07/25 13:54, 4年前 , 105F
沒錯！一堆方法 人不配合 還是搞不出什麼毛 人才是最大的
07/25 13:54, 105F
→
07/25 13:54, 4年前 , 106F
變因 其實也差不多什唯一嚴重的變因
07/25 13:54, 106F
推
07/25 16:11, 4年前 , 107F
推這篇
07/25 16:11, 107F
→
07/26 03:00, 4年前 , 108F
我在國外看到的PM是真的可以主導產品走向的要角
07/26 03:00, 108F
其實職稱是假的，重點是他被賦予的職責才是真的。我在美國也待了一年，國外沒比較厲害，重點還是在不同角色之間的彼此妥協。 ※ 編輯: TonyQ (223.137.92.174 臺灣), 07/26/2019 08:10:11
推
07/28 23:33, 4年前 , 109F
推
07/28 23:33, 109F
推
07/29 08:31, 4年前 , 110F
推 跟我看的的狀況比較吻合
07/29 08:31, 110F
推
08/15 09:19, 4年前 , 111F
認同Tony大觀點，不過很清楚的看到PG跟PM所認定的品
08/15 09:19, 111F
→
08/15 09:19, 4年前 , 112F
質不同 科科
08/15 09:19, 112F
‣ 更多 TonyQ 的文章
文章代碼(AID): #1TDwtT3V (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
‣ 更多 TonyQ 的文章
文章代碼(AID): #1TDwtT3V (Soft_Job)