顯示廣告
隱藏 ✕
回列表(←)
Disp BBS guest 註冊 登入(i) 線上人數: 233
首頁(home) 上頁(↑) 下頁(↓) 末頁(end)
※ 本文為 layzer 轉寄自 ptt.cc 更新時間: 2019-07-26 11:35:56
看板 Soft_Job
作者 TonyQ (得理饒人)
標題 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 (臺灣)
※ 文章代碼(AID): #1TDwtT3V (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1563930077.A.0DF.html
※ 同主題文章:
　 07-22 03:08 NDark. ■ Re: [請益] 預估工時的意義在哪？
● 07-24 09:01 TonyQ ■ Re: [請益] 預估工時的意義在哪？
　 07-24 23:14 Feis. ■ Re: [請益] 預估工時的意義在哪？
※ 編輯: TonyQ (61.231.21.72 臺灣), 07/24/2019 09:04:33
※ 編輯: TonyQ (61.231.21.72 臺灣), 07/24/2019 09:07:14
→ pttworld: sales拿到PM預估的工時是要換算後報價給客戶的1F 07/24 09:12
→ MOONY135: 三本柱2F 07/24 09:13
→ pttworld: 正規的專案公司還有養PM Team, 怎麼可能只有協助3F 07/24 09:15
→ benqm300: 人柱力4F 07/24 09:20
→ pttworld: 這篇一看就知道沒當過專案經理，你說的時程就是5F 07/24 09:24
→ pttworld: 你的頭銜不是專案經理是因為不是專案公司
看不懂你在講什麼，先組織組織再回吧。
推 jack0204: 是不是要先抓一隻神獸封印在身上才能當柱子?7F 07/24 09:29
那個叫祭品，不是柱子喔。QQ
推 xam: 這篇就技術base的PM+PL啊, 我支持..8F 07/24 09:46
→ ckp4131025: 第三根柱子是user?9F 07/24 10:21
這裡我講的 user 比較算是企劃或是負責需提供求的角色，有所節制的 user 是很重要的。
推 ime5566: 原來是Tonyq10F 07/24 10:39
→ fgh81113: 架構規劃已經倒了  還有沒有救...11F 07/24 10:41
理論上其實要把架構做倒但公司不倒，還滿難得，通常的情況是人倒了而不是架構倒了。
推 massrelay: 蠻認同，不過還是需要PM幫忙盯不然容易漏東西。12F 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
→ Feis: 不認同，預估工時跟品質當然有關13F 07/24 12:15
廣義來說，所有事情都跟結果有關，員工家庭生活是否和諧都會跟品質有關。

但實際上還是有些更核心的事情要探討。舉例，如果沒有人釘時程，那時程就會形同虛設。

這種情況下他對專案影響就不會太大。

又舉例，老闆是個 asshole 整天叫你用一天做一個月的事情，你就會覺得預估時間真是問題的根源。


但真正的問題並不是預估時間本身，而是權力怎麼被揮舞跟決策怎麼形成。


你越認為預估時間重要，他對你來說的傷害就越重要。

我的風格比較算是價值管理，每個東西的時間是分級的，有些時間重要，有些時間不重要。

會覺得預估時間對品質重要的，實質上是因為環境把權力寄生在無辜的預估時間上而已。

另外預估時間對改善品質，我還是要強調，我認為沒有幫助。

→ lnmlee: 預估工時就是預計時間成本 講那麼多平行世界要尬嘛？14F 07/24 12:40
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/24/2019 12:54:52
推 banana13: pm就是為了給老闆交代產出產品，pg就是被要求使命必達15F 07/24 12:57
→ banana13: 達不到就加班
→ Feis: 如果連明天能不能上架都無法預估，真不知道怎麼做專案…17F 07/24 13:12
假設是正常的專案流程，到上架之前至少有六次的預估跟檢核要做。

如果你跳過所有的檢核，直接到上架前一天才來倚賴預估，我想是真的不知道要怎麼做專案沒錯。

沒有準確的預估，不代表你放棄 QA 放棄 review ，放棄所有確認專案目前狀態的手段好嗎？



→ Feis: 見識太少，尊重你的看法18F 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
推 ian90911: 中肯推19F 07/24 14:49
推 hakama99: 推20F 07/24 15:28
推 mathrew: 理想總是美好的21F 07/24 16:26
推 menesn:  感謝分享22F 07/24 17:31
推 SuperCry: 一直想到陳綺貞的歌23F 07/24 19:10
推 gmoz: 扳手 不是板手QQ24F 07/24 22:22
→ gmoz: 最近靠北樂團才在吵這個(X
推 Feis: 「預估時間對品質，我認為沒有幫助」這中文理解有障礙26F 07/24 22:27
→ Feis: 我有說要放棄其他方法嗎
→ Feis: 我只是不認同沒幫助這件事，沒幫助還是要做，所以就是有幫助
→ Feis: 呀
→ Feis: 這邏輯……
→ Feis: 軟體專案以人為本，預估時間也是個工具，政治手段也是個工
→ Feis: 具，不要以偏概全
→ Feis: 抱歉，一開始就不應該回應…
你每天過馬路要看紅綠燈，這是個要做的事情。
他對你的幫助叫做保護你的安全。而不是讓你賺大錢。

當然你可以說你被撞死了就不能賺大錢，定義上不會有錯，但他畢竟不是直接相關。

同理，預估工時只是個概估的基準，他讓你的團隊心裡有個底。

但這個底跟品質沒關係。

要說的話，頂多只跟這件事情能不能被完成有關，但能不能被完成跟品質好不好是兩碼子事。
→ thund: 沒幫助還是要做=有幫助 這等式不成立吧34F 07/25 00:32
→ Feis: 是的，我們都在做沒幫助的事。我猜原作者的論點不是這方向35F 07/25 00:36
→ Feis: 我原本的認知是要透過測試稽核之類的去決定狀態
→ Feis: 而測試稽核不是建立在預估工時上是我原本以為的論點
→ Feis: 我自己的論點是，短期的預估工時是無可避免的
→ Feis: 而預估工時是個工具，工具有好有壞，有用對有用錯
我不太理解為什麼對品質沒幫助等於不需要做的事情。

專案中多的是對品質沒幫助，但需要做的事情。

比方說砍功能或在功能未完成時，提早上線，就是個犧牲品質來成就市場的手段。

品質不是一切啊。

→ thund: 本篇也沒說要放棄預估工時啊 只是說對品質沒有幫助40F 07/25 00:42
→ thund: 重點是在更上層的問題 而不是預估工時這件事的好壞
→ Feis: 了解，所以現在主題變成為什麼要做沒幫助的事 ?42F 07/25 00:43
→ thund: 沒啥毛病啊43F 07/25 00:43
→ Feis: 是嗎？如果完全沒辦法預估工時，你怎麼決定什麼時候稽核?44F 07/25 00:44
不管我我預估多久，我還是可以每週稽核啊。
→ thund: 喔 我的天 我看是你理解有問題.......45F 07/25 00:46
→ Feis: 我能理解有更上層的問題，但是這篇的意思就是『預估時間對46F 07/25 00:46
→ Feis: 品質沒有幫助』
→ Feis: 可以指教一下嗎？
→ Feis: 我只是對這點表達不認同
→ Feis: 『估不準不會死』我也認同，要估六次十次我也認同
→ Feis: 那結論不就是要嘛做這些事與品質無關要嘛有關
→ Feis: 原作者論點是『無關』，但我無法認同而已
→ Feis: 抱歉糾正，是有沒有幫助
→ Feis: 如果『沒有幫助』卻又要『做』的邏輯是什麼，需要有人指導我
→ Feis: 我想表達的是工具本身是中性的，使用工具的人才是問題
→ Feis: 不要因為人的問題就去說工具沒有用
我沒說他沒用，只是他的用途不是提高品質。
→ Feis: 而工具有學習成本有使用風險，這些都是專案管理要考量的57F 07/25 01:08
→ Feis: 挑適合的工具給適合的團隊創造適合的文化
→ Feis: 才是專案管理者該走的路跟價值 (當然是我自以為
推 bakedgrass: 不太明白User不能把責任都丟給開發端是甚麼意思？60F 07/25 02:16
→ bakedgrass: 是指User必須試著適應開發出來的軟體？
→ bakedgrass: 一般說來User不會是開發團隊可以掌握的因素吧
這裡的 user 基本上是企劃或是自認為自己是 user 代表的人。

舉例，明明就是個 toto list ， user 要求系統要能看客戶的行事曆猜到他要幹嘛幫他寫 todo 就是個 over kill 的要求。

很多時候他們會跳入提供更多功能，而不是解決問題的陷阱裡面。


推 zombiesky: To Feis, 人活著需要氧氣和食物,氧氣和飽足無關,但沒有63F 07/25 08:14
→ zombiesky: 氧氣會死, 所以還是要氧氣
→ zombiesky: 專案管理要顧的不是只有品質,預估時程的目的不是提升品
→ zombiesky: 質,但有其他作用,本文有提到
推 zombiesky: To Bakedgrass,前面TonyQ有回應,這裡的User指的是代表
→ zombiesky: User的人,ex. Product Owner
推 ku399999: ...開宗明義不是就講估工時的功能了嗎69F 07/25 08:36
推 jjwei: push70F 07/25 08:37
推 bakedgrass: 看到了，謝謝zombiesky71F 07/25 08:46
→ Feis: 了解，可能是大家對品質的定義不同。可能是我誤解，謝謝72F 07/25 09:08
→ Feis: 沒有氧氣會死，所以飽足跟氧氣無關。可能是這邏輯我誤會了
→ Feis: 我原本以為是不需要預估時程也可以確保品質。
的確是不需要準確的預估工時也能確保品質，準確的預估工時實際上是跨團隊合作才需要的東西。你跨的團隊越多他準確性越重要。

但他實際上是個政治工具，而不是品質工具。

就算你能把時間都估到神準，還是不會讓產品變厲害，要讓品質變好需要的是別的東西，例如正確的規劃跟品管。

時間是品質的劣化指標，加入對時間的要求都很難避免對品質的負面影響。

(但我的意思並不是因為這樣就不要求時間，而是要留意到趕工跟品質的取捨。)
→ Feis: 每個人對專案品質的定義不同，打擾大家了 QQ75F 07/25 09:11
→ DrTech: 這根公司產品性質強相關吧。有些工時估不準，或隨意延後。76F 07/25 09:16
→ DrTech: 公司會被罰鉅額的。
→ DrTech: 某些產業或環境，亂估工時真的是會沒工作的。要看環境。
但那是環境給他的限制，而不是預估工時本身的需求。
※ 編輯: 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
→ Feis: 所以規劃不需要預估時間的意思嗎，我越來越混亂XD 當然不用79F 07/25 09:50
→ Feis: 神準

我從來沒說不需要預估時間, 這應該是我第三次強調了,
我說的是預估時間不會提升品質.

是你要加上[不會提升品質的就不用做]的前提才會解讀成這樣.

→ Jockey66666: 上述的規劃應該是指產品設計面上的規劃, 不包含時間81F 07/25 10:03
→ Feis: 照這意思是產品設計時不考慮做不做得完，那我就完全理解了82F 07/25 10:05
→ Feis: 感恩

你只做做得完的事情跟品質提升有什麼關係?

通常就是因為你只做做得完的事情品質才會下降啊.

[品質]不是專案的唯一指標, 更多的時候我們是不考慮品質的再進行專案,
我是覺得你把[品質]跟[完成專案]這兩個詞弄混了.

※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:10:17
推 bakedgrass: 謝謝解釋84F 07/25 10:12
→ Feis: 我沒誤會，我以為品質是建立在有做完產品的前提85F 07/25 10:14

我認為完成產品是完成產品, 品質是品質.


不然在你這定義底下的 [完成產品], 會很容易變成被情緒勒索的基礎,
任何人只要試著透過政治力加需求讓你無法完成, 就可以靠北你品質很爛了.

在這樣基礎上你在技術上的攻防會花非常多的時間, 在處理需求的進出.


品質跟完成還是獨立線, 才是比較適合的評估工具.


通常我都會說, 你想要改善專案品質我明白,
但你改善品質的手段過頭專案就會無法完成.

所以我說, 預估時間是個政治問題, 不是品質工具.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:17:50
→ Feis: 是我誤解品質，抱歉86F 07/25 10:14
→ Feis: 這產品品質很好只是沒做完，我以為這不是前提的

所以現實上才會有砍產品品質要素, 來加速上線的手段啊.


完成專案也是重要的, 只是完成專案本身也不是一個品質指標,
為了讓專案完成本身並不會提高體驗, 也不會讓產品更好.

沒人說你要只顧品質而不讓專案完成.

只是講清楚專案完成跟品質一點屁關係也沒有.

※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:20:49
→ Feis: 我不覺得獨立比較好，不過尊重你論點88F 07/25 10:20
→ Feis: 加速上市不一定要犧牲品質


我說有 (犧牲品質(P) -> 加速上市(Q) 的手段) 是基於這樣的目的.
你要跟我說有 加速上市 Q -> 非P (不用犧牲品質),

這兩個不是衝突的好嗎......


我說的是在某些時候我們會選擇犧牲品質來加速上市,
並不等於我說所有的加速上市都是犧牲品質.....

如果你連這麼基本的理則學都沒辦法想清楚再回,
我會建議你, 先再想一想.......

不然你會一直搞不懂別人再回什麼.

※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:23:13
→ Feis: 不過還是回到品質的定義問題，是我誤會。90F 07/25 10:21
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:23:58
→ Feis: 了解，我那句並不是要否定。抱歉91F 07/25 10:24
→ pttworld: 預估工時的時候就要把品質預估進去92F 07/25 10:24

那你預估工時的時候,
要不要把明天會發生七級大地震的風險也估進去.
※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 10:25:31
→ pttworld: 估出來的工時就是品質預測後所定的時程93F 07/25 10:26
→ pttworld: 你所謂的品質也是你預測做出來會是怎樣的
→ pttworld: 時程3個人月和6個人月，做出來的品質本來心裡就要有底
→ pttworld: 開發中期review後發現要tune, 要看有沒buffer可以用
→ pttworld: 這個buffer也是當初預估工時就要留的

這串在討論的就是預估過程中產生的變化, 導致原本的估計是異常的,
在這樣的前提下在探討預估的價值.

不會變動的或可預測的, 自然不會有這種問題.

※ 編輯: TonyQ (61.231.35.153 臺灣), 07/25/2019 11:06:07
推 yahuichang: 一般要做一年案子，前家公司總經理要求三個月上線，理98F 07/25 11:32
→ yahuichang: 由是要讓業務員早點使用，這也是我有有史以加班破表，
→ yahuichang: 當然上線品質不佳，假日被on call。
推 Arctica: 認同估工時就只是個政治工具，通常就是為估而估，搞到最101F 07/25 11:37
→ Arctica: 後還是會有對內對外兩套工時....
推 yahuichang: 我那是完全沒估，PM應當手上有多少資源，排出工期工時103F 07/25 11:42
→ yahuichang: ，只會壓時程。
推 strlen: 沒錯！一堆方法 人不配合 還是搞不出什麼毛 人才是最大的105F 07/25 13:54
→ strlen: 變因 其實也差不多什唯一嚴重的變因
推 vencil: 推這篇107F 07/25 16:11
→ umum29: 我在國外看到的PM是真的可以主導產品走向的要角108F 07/26 03:00
其實職稱是假的，重點是他被賦予的職責才是真的。我在美國也待了一年，國外沒比較厲害，重點還是在不同角色之間的彼此妥協。
※ 編輯: TonyQ (223.137.92.174 臺灣), 07/26/2019 08:10:11

--
※ 看板: layzer　文章推薦值: 0 目前人氣: 0 累積人氣: 263　
※ 文章分類: 程式設計 創業
作者 TonyQ 的最新發文:
點此顯示更多發文記錄
分享網址: 複製 已複製
r)回覆 e)編輯 d)刪除 M)收藏 ^x)轉錄 同主題: =)首篇 [)上篇 ])下篇