Re: [請益] 主管工時都估太短

[chatmonkey (打屁猴)]

※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: 唉，但工時估太短，就造成我不停的加班追進度，沒有六日、沒有晚上
: 請問我該怎麼辦？
: 還有更好的solution嗎？

提供我自己的一點觀感，

其實估工時都是屁，工時基本上不可能估的準。

國外有流行一套不估工時的作法，你可以去google "no estimates agile"


如果你工時估的準，表示你做過類似的功能。


如果這個功能有些地方是有不確定性，一定是估不準的。

因為你無法得知這些不確定性的地方需要花多少時間，

有些時候一些乍看之下很簡單的問題，真正下去看才發現裡面其實大有文章。


比方說，我要你解一個老鼠走迷宮的問題，

附加條件是老鼠要走過特定的check point，並且要走最短路境。

先看到這邊，如果你從沒解過老鼠走迷宮的問題，你覺得要花多久時間？






假設你沒解過，但是你應該有聽過，或是以前上課有看過類似的問題。

其實最基本的老鼠走迷宮就是很暴力的遞迴下去，答案就出來了。

只要你聽過老鼠走迷宮，也許你會覺得這個問題只不過是老鼠走迷宮的變形，

上網查個資料就知道答案了。

所以你可能會估2-3個小時就可以完成，

不過就是上網查個資料加上自己local測試一下的時間。





但是你實際下去實作就會發現，它不是一個簡單的遞迴問題，

如果要走最短路徑，那就是shortest path的問題，

如果是走最短路徑再加上走過所有check point，那就是travelling salesman的問題，

整個演算法都和當初預想的不一樣了，

而你當初卻沒有估到這一塊。



就是因為軟體開發時，對於"技術的掌握"以及"客戶需求的掌握"有不確定性。

所以總是讓你估的工時像屁一樣。

而且你的工時又是主管估的，估工時的人和實作的人不是同一個人，

那估出來的時間更是不準。

(反過來說，如果客戶要的功能很簡單，需求很明確，而且你又做過類似的功能，

那就你的工時就會估得很準。)




那你該怎麼辦呢？


不知道你們有沒有跑scrum，

基本上工時不應該是由來主管估，也不應該是由你自己一個人來估，

應該是開個會，整個team一起來估。(當然你也會去估其他team members的工時)

這樣估出來的時間會相對比較準一些。(但還是有可能會不準)

然後應該把大的task breakdown，才知道那些地方是可掌握，那些地方不能掌握。

估出來會更準一些。

重要的是大家心裡應該要有共識，有不確定性存在的話，工時一定估不準的。




其實估工時的目的不外乎就是

1. 想要知道有沒有risk，會不會做不完，甚至做不出來

2. 有跟客戶壓deadline

3. 方便主管分配resources



如果有risk，一定要趁早說出來，尋求team member的幫助。

就算被罵也要說出來。然後看是要加人力，還是project要postpone。


risk其實是越早發現越好，而不是到deadline最後幾天才發現作不到。


所以主管如果有sense的話，應該要去鼓勵那些提出問題，主動尋求協助的人。

然後要去懲罰那些隱瞞問題的人。

而不是用言語去酸去罵那些提出問題的人，責怪他們能力不足，這樣只會造成反效果。

因為這樣會造成team member發現問題不敢講，

然後自己加班埋頭苦幹，最後自己做不出來，deadline前幾天爆發，

大家開始互批、互相推卸責任。




以上是我自己的一些看法，當然在某些senarios之下可能是不適用的。

有問題也可以來信討論。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.228.126.53
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1463798791.A.4F0.html
推 ian90911: 推
推 Masakiad: 我們也運行scrum，附帶解釋一下提早發現risk這問題, 其
→ Masakiad: 實應該是縮短每個開發週期，這樣會更好處理。
推 maxqq: open mind and discuss
推 typepeter: 推
推 puritys: 推
→ manaup: 還蠻理想的 A級團隊可遇不可求
→ manaup: 有時能點出問題也解不了問題 畢竟天才是少數
→ manaup: 要直面自己和團隊都很平庸這個事實 對平庸的人是很苛求的
→ manaup: 團隊士氣有時就像九二共識一樣 一戳破就沒了
→ Masakiad: 其實跟現實差最遠的是，工程師天才與否之前有個問題，即
→ Masakiad: 是在融入這種開發流程，我指的是真心認同。
推 Masakiad: 這還得讓老闆認同；光是認清自家團隊開發某專案必定要
→ Masakiad: 花既定以上的時間（因為產能固定），這件事就很困難。
→ Masakiad: 說穿了軟體開發中很多人的問題，跟資安根本一樣。
→ manaup: 私以為這是一體兩面互為因果的。
→ manaup: C咖團的問題在A咖團裡連個問題都算不上。
→ manaup: 老闆有問題時，下面的團隊都不會太正常。
→ manaup: 反過來也是一樣。相當於老闆也是團隊的一員。
→ manaup: 長久來看團隊的整體實力一定趨於相近。
→ manaup: 如果不是一起成長 那必定向下沈淪 因為會成長的都很會跑
→ manaup: 因此我從來都覺得方法論是nice to have
→ manaup: A咖團不用強調方法都會組織的很好 結果不會差
推 LenaPark: 然後造成團隊死亡.建議主管看天才當家/人月神話
→ GoalBased: 方法不是萬靈丹 硬吃通常有害無益
→ manaup: 不斷強調"我學佛喔~"的人 入魔者眾而開悟者稀 這樣 (笑
噓 jones86723: 有時估完,PM才跟你公佈deadline，像被試
→ jones86723: 水溫
→ Masakiad: 沒錯，scrum這種方法論要滿足很多條件才會有效。雖然一
→ Masakiad: 起向下沈淪的團隊看過，一起成長的團隊也看了不少。其
→ Masakiad: 實leader的群眾魅力也很影響這些運作。
→ htury: 推這篇討論，但是同事很重要，有些經不起scrum考驗
→ htury: 有些人會以為都在互酸，也不討論解法，到最後就GG了
→ prag222: 我公司花了兩天估時間,明明會爆估出來不會爆
→ prag222: 那估時間是估心安的?
推 Masakiad: 你明明就知道會爆 為什麼不提出疑問？
→ prag222: 提出來能解決問題就好了,時程還不是依樣照樣排
→ Masakiad: 排時程的人不認同估時這樣無解
推 typepeter: 工時當然要估，而且就是要估來作風險管理
→ typepeter: 如果估出來的不能變動或砍功能，可想而知產品一定爛
推 oneheat: 多找點有經驗的來帶團隊不就好了
推 siriusu: 推
→ dlikeayu: Prag222說的根本是消極團隊意識了..."說了也沒用"
→ dlikeayu: 這點，我想任何強力有些的專案管理方式都解不了
→ angusyu: 超討厭scrum, bj4
推 ECMA: 台灣的主管就是明知道會爆 也會推給工程師不給力 繼續擺爛
推 lucky1lk: 推你這篇 就算做過類似的 時間一樣會有估不準的
推 Luos: 推 估時是屁
→ bndan: scrum 的做法是可遇不可求 因為最基本視員工為人這點都做不
→ bndan: 到的話 再多的方法論都不會比工頭帶工人直接...
→ bndan: 而能做到視員工為人 能理解人成長需要時間 同時團隊使人成
→ bndan: 長 而後再方法論會更有意義..不然只是實行效果有限 由其是
→ bndan: 在討論這些過成還在講"COST DOWN"(含薪水)的團隊 還是別浪
→ bndan: 費時間想太多 直接工頭帶工人 然後花更多錢硬操過關就好了