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

看板Soft_Job (軟體人)作者kimkao (魂縈夢牽)時間13年前 (2012/09/20 00:24)推噓3(3推 0噓 12→)

留言15則, 4人參與討論串2/2 (看更多)

※ 引述《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