Re: [請益] PG要如何衡量工作量?

[kimkao (魂縈夢牽)]

※ 引述《hegemon (hegemon)》之銘言：
: 最近因為發生了一些事情, 讓我開始思考:
: 到底要如何衡量一個PG的工作量?
: 過去很多人都會用啥工時來衡量..後來發現工時可能只是效率差.
: 後來有些人用code行數來看, 但是行數這碗糕很容易受寫法跟排版影響.
: 那到底要如何正確的衡量一個PG的工作量?
: 我自己是覺得可以用每個人負責的UseCase(功能)個數與複雜度來衡量.
: 但是似乎有很難量化.....
: 請問各位有什麼好方法可供參考? 感謝

  看到你的發文 讓我想起我最近有個同事也是因為這種狀況最後離職了

  有點感慨.. 不專責的PM果然所在多有

  你的問題真的不是你的問題!!

  在你的主管(以下皆以pm稱呼) 交辦你工作事項之時 就該跟你先討論過交付期限

  以及難度、複雜度、使用元件套件熟悉度 諸如此類的問題

  如果這些都沒有談，那就便是你必須自己寬估一個

  萬一出事還可以透過任何補救機會來完成的時間點!!

  否則就真的變成是你的責任了~


  前文提到用UC評估工時，這裡還要考慮到你整體團隊對UC切割的粒度到哪種程度

  有的UC是切出成為Business UC ，有的則是以functional goal的程度在切割

  對於這樣的區別，會造成你若單以UC來估算工時是一點都行不通的...

  如果真要以UC來估算工時，個人覺得至少得符合以下幾種條件才能有效估算

  1. 已能克服新技術所帶來的瓶頸與不安定感

  2. RA & SA  所獲取的UC切割粒度一致性很高，且有專人統一管理掌握進度

  3. 不同UC之間若存在著所謂的共用method / lib 的開發 必須是早已完成或者

     推遲至初版交付後才進行重構

  4. 說是以UC估算，不如說是每個UC 所對應的Control Class設計提供的

     public method數量，因為這些提供出來的public API是必須滿足需求的必要條件


  以上也許還缺漏很多，也很可能就算有這些條件都符合也很難精確估算，

  因為你還得考量你個人程度與團隊程度的差異，還有其他狗屁倒灶亂安插的鳥事..

  總之，估算工時並非PG的責任，但若真要你自己評估，那就抓大放小就對了!!!

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 59.104.133.96
推 hegemon:這次用的是全新的前端工具+AP Server..所以表定三個月
→ hegemon:但是前期光初步熟悉AP Server, 前端工具, 前後端串聯就花
→ hegemon:了半個月..又拉了一個月給測試,所以實際開發只有1.5個月
→ hegemon:但是老闆在打考績時還是"以為"我們花了三個月開發.所以GG
→ hegemon:雖然會叫我們估時間,但是dead line是不會變的....
推 NDark:在PM眼中 deadline都馬不會變.
→ NDark:下次多給自己一些時間,再把工作切細點,這就是經驗.
→ iincho:這個基本上是你估錯的問題吧...不過難免, 下次抓大點buffer
推 hegemon:不..時間長度是不能動的.根本沒有辦法多"給"自己時間
→ hegemon:估是你在估..時間還是這麼多
→ kimkao:如果是總時程是已經被綁死的，那你就要更早的向pm表示
→ kimkao:你的狀況是無法在這時間內完成的,然後盡可能快速更新進度
→ kimkao:讓pm能隨時知道你在幹嘛,讓你合理的產出即使是在不合理時程
→ kimkao:下,也能讓人知道你仍盡了最大努力在進行,其他的真的就看pm
→ kimkao:是不是能做些其他斡旋了~ 要資源,抓人情,重談時程等等