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

看板Soft_Job作者menesn (迷思)時間4年前 (2019/07/22 10:11)推噓8(8推 0噓 15→)

留言23則, 11人參與討論串3/9 (看更多)

跟大家分享一下我的理解也請大神們不吝分享與討論我認爲工時預估或者所謂的甘特圖其實對於一個軟體專案的開發非常重要理想狀況是：公司要做一個專案 PM召集軟體部門的技術主管一起把一些要實現的功能做大方向的規劃然後主管們根據自己的經驗以及對手下開發者(Developer, Dev)能力的理解把工時預估出來 PM根據開出來的人力配置做財務規劃有需要的時候跟大老闆提出增加人力的需求然後各部門的主管在根據這個大架構下去實做敏捷開發的做法，可能如下：主管把把大功能切成小功能，以兩個星期爲一個週期然後開會分配工作給Dev 跟每個小功能所需要的時間預估然後每天早上開30分鐘的會把每個組員遇到的問題或瓶頸拿出來討論，並解決每兩週Release一組版本給測試人員(QA)測試，並且發Bug Report 回饋給Dev，並且把修Bug的時間排進去下一個週期的項目幾個週期穩定了之後再開始部署給客戶使用 DevOps的做法很類似但是對於成員的自動化與團隊合作能力相對提高差別是，在分配工作的時候， QA跟部署人員(Operation, Ops)也納進來 Dev在實做的時候，跟QA緊密的討論然後每出一個小功能，馬上讓QA接手，然後Ops接手並且讓流程儘可能的自動化，把重複性的動作都用程式取代 Ops讓客戶直接開始使用，並即時回饋然後在下一個週期規劃的時候，把修Bug的時間排進去不管是敏捷還是DevOps每個月或者每季個部門主管跟PM就會開會修正本來的大架構做出對未來更精準的預測實際狀況是：因爲公司的口袋不夠深？或者包袱太重？或者老闆不尊重專業？眼光短淺？大架構討論的時候，老闆就明說，目前就這些人力，我要什麼時候完成，你們看着辦然後PM完全就被廢了武功，變成客戶跟技術主管的傳聲筒主管們因爲人力不足，紛紛跳下去寫Code，做測試主管本來應該是技術力最強，幫助組員解決開發上的難題並且還要Review組員寫的程式碼，負責把關有問題有危險的程式碼於是所有的程式碼都變成不需要Review了，有些公司甚至還沒有使用版本追蹤因爲主管要寫Code，所以有些主管也不去預估時間了，全部交給PM用想象力去壓時間然後PM就變成追蹤開發進度的機器人，開會的時候就準備很漂亮的PTT，跟老闆報告進度老板如果發現進度不如預期，就把工程師叫進來罵一罵說我以前怎樣怎樣，然後對於現在要開發的東西根本風馬牛不相及用懶叫比雞腿有些老闆甚至還會說，這我來開發一定幾天就搞定（這個老闆我看104現在還在找資訊部門的主管，一間跟法律有關的公司如果有人被找去面試，可以站內信）我甚至還有遇過有些公司根本沒有PM 做功能就是客戶透過聯絡人或者業務把需求傳進來然後主管交代事情分工下去做，組員負責把東西幹出來主管自己要做開發，所以組員遇到問題，主管可能也沒很多時間幫忙於是就叫你自己想辦法，於是就開始出現可怕的程式碼有些公司號稱DevOps 結果只是技術長整天也沒在帶團隊，偶爾會在通訊羣組上跟大家聊一下天，討論一下一些新的資訊每天各個團隊的小組長把要做的東西貼在通訊羣組上但是基本上沒人在管羣組裏面貼了什麼，都是按照自己的意思去開發然後後QA的人就很慘，PM給出的需求，東漏西漏，整天幫Dev擦屁股 QA沒擦乾淨的，變成Ops的人幫忙擦，結果Ops的變成全公司最賽的工作有些公司，主管叫組員把自己要開發的項目條列出來，自己預估工時然後需要叫組員做事的時候，就直接交代下去，也沒在管本來開發的進度最後Review的時候就說，啊你自己估計的工時怎麼沒辦到這樣我所理解的工時預估其實是要增進團隊跟領導人對於預估項目完成準確度的能力結果因爲種種原因，變成沒有用的報表，流於形式浪費時間的開會或者質疑組員有沒有在偷懶的數據實在無言 ※ 引述《yukimatoi (纏)》之銘言： : 我們公司的流程是 : 評估市場需求→PM提案→設計師開規格→RD實作→QA→發布 : 實際上是什麼開發流程我是不知道 : 網路上有看過離職的前輩說這是瀑布式 : 公司這幾年又把一些敏捷的思想帶進來... : 說因為沒有一個人神到可以設計出最終規格 : 所以產品要不斷迭代 RD可以先做出一個成品給設計師看跟設計師互相討論 : 但矛盾的是我們的產品上線時間很早就被敲定 : 所以大部分的專案下場就是沒有得到足夠的迭代 : 最後不是砍規格就是RD跟設計師一起加班趕進度 : 甚至還有上線兩個月前規格才完成的狀況 : 我也問過主管這樣迭代真的足夠嗎？主管只說：恩，公司要賺錢 : PM最喜歡的就是預估時程畫滿甘特圖預期最後有幾個功能會完成 : 但最常見的狀況就是規格大改(因為我們會迭代) : 不然就是RD為了進度hard code才勉強滿足進度 : 反正有問題就看誰倒楣誰修誰接手 : RD大老雖然說要推行test 但是跟PM根本沒有共識專案進度也沒有排入test撰寫的閒暇 : 所以RD要不就是自願加班寫test 要不就是乾脆不寫或是寫一些無關緊要的test : 我不知道是不是只有我們公司才這樣 : 還是這是業界常態只是我太菜了 : 我是真的不太懂預估工時的意義到底在哪 : 工時預估準確 ─┬→ 可喜可賀 : └→ 規格變更 ─→ 完成時間延長(然後叫你再估一次工時) : 工時預估不準 ─┬→ RD遜砲，請重估 : 　　　　　　　 ├→ RD報喜不報憂留下技術債 : └→ 規格變更 ─→ 完成時間延長(再估一次) : 工時不管預估準不準確，都不能影響專案目前的進度以及實際上需要的時間 : (實際需要的時間大概只有神知道) : 但預估工時反而會給PM「一切都在我的掌握之中專案都在軌道上」的錯覺 : 還是說我誤解了預估工時的目的有沒有人可以指點一下？謝謝 -- 大道之行也，天下為公，選賢與能，講信修睦，故人不獨親其親，不獨子其子，使老有所終，壯有所用，幼有所長，鰥寡孤獨廢疾者皆有所養；男有分，女有歸，貨惡其棄於地也不必藏於己，力惡其不出於身也不必為己，是故謀閉而不興，盜竊亂賊而不作，故外戶而不閉，是謂大同。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.136.156.208 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1563761479.A.D2B.html

推

lukatw

07/22 12:50, 4年前 , 1^F

07/22 12:50, 1^F

我講的是正常情況啊如果主管只是出一張嘴，那真的是悲劇

→

lukatw

07/22 12:55, 4年前 , 2^F

07/22 12:55, 2^F

→

lukatw

07/22 12:55, 4年前 , 3^F