※ 引述《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 就是協助角色, 不是真正決定的角色.
這三個只要有一個不行, 基本上不用撐, 能閃多遠走多遠,
不然就自己站到這三隻腳的其中一隻腳去, 至少是自食惡果.
畢竟, 你面對生鏽報廢的引擎的時候,
不會去考慮你該拿螺絲起子還是六角板手吧?
換個新的引擎才是真的.
方法論只是方法論, 人才是執行方法論的主體,
錯誤的人的環境長不出什麼漂亮的花朵.