不切實際的時程規劃表開發時程的預估（1）開發時程的預估（2）當時程延遲之後基本上這幾篇文章講的, 都已經是老生常談了.
但再怎麼老生常談也會有這個產業的新人未曾聽聞, 所以還是值得推廣.
再說, 老生常談竟然還持續在流傳, 就證明了問題一直沒有被解決, 同樣的事情還是同樣地在發生... orz
作者在
不切實際的時程規劃表 中提到 delay 時程式員通常會變成眾矢之的, 這讓我忍不住猜想他所服務的單位是不是都沒有 QA.
當然, 在
開發時程的預估 中就可以看到作者有不少和 QA 共事的經驗, 證明了我的瞎猜是錯誤的.
我曾經在幾家公司擔任 QA, 其中有一家 T 會社的情形, 我覺得是比較典型的, 也就是我心目中的
通常.
那兒有一句話很流行,
schedule 就是用來 delay 的.
delay 了, 當然要找個代罪羔羊.
但扮演這個角色的不是 R&D, 而是 QA.
道理也很簡單, release 前的最後一個階段是 QA 在做事的, delay 了, 當然就會直接看到最後這個階段還沒完工, 當然批 QA.
既然後文都說要 R&D 扛責任不公平了, 我也能借來說要 QA 扛責任不公平.
但大多數人就是直接以結果論狗熊, 所以會有這種評價也是蠻正常的.
我要說明的只是, 在有 QA 的地方, 供應鏈不同, 代罪羔羊也會換人做. (淚奔)
但, 基本上, 這還算是一個不錯的狀況.
事實上很有些公司是蠻慘烈的, delay 不是只有 delay 到送測的 schedule, 不是只壓縮到 code freeze 的時間, 根本是到要 release 了都還在改程式.
在這種場合, 就算是 QA 要跳出來擔責任, 大概也沒人會信了.
自然, 眾矢一定是指向 R&D 的了.
也有比較奇怪的.
release 的 schedule 改了又改, 還是有幾個使用者介面還在重新設計, 甚至有關鍵元件還沒開發出來.
奇怪是怪在哪兒呢? 無視開發流程堅持改規格的掌權者, 以及 R&D 的主管, 竟然會問 QA 何以 delay?! ooxx...
原因? 不就是程式還沒寫好嗎?
更諷刺的是, 就是那位主管覺得別人沒空做那個關鍵元件, 所以拍胸脯說這個我來... 也就是說, delay 的原因之一就是他答應的事情 delay 了...
其實作者提到了一件事, PM 通常是用倒推法排出整個 schedule 的.
這方面他比較沒有提出什麼具體的建議.
這也合理, PM 的事情, 沒道理要 R&D 開藥方啊!
時間不夠, 人手不夠, 正解法就是開源和節流這兩條路.
PM 沒辦法創造時間, 但至少可以找更多的人力資源投入.
節流則是不要包一些亂七八糟的工程, 不要外行領導內行過度干涉專業人員的工作, 不要自己該做的沒做好讓有限的人力做白工...
說起來簡單, 做起來也是又麻煩又困難, 我這邊就不詳細討論了.
還是要抱怨一下... 不覺得這 blog 每個網頁的 title 都很怪嗎? 都是
程式者的胡言亂語 : 程式者的胡言亂語 咧!
害我不能使用我慣用的張貼連結的格式... :(
我沒辦法認同這是 feature, 只能判定成是 bug, 把它當成是一個 quality 的問題...
Login
Register
RSS 
FAQ
