讀到這篇「美國碼農加班少很多、卻能開發出厲害的產品？」，讓我想起了一件事：

某公司的主管，總喜歡在客戶或PM還沒提出需求，或是需求規格還沒共識前，就發動團隊依照他的想法開始作業 (應該是希望當規格出來後，就可以很快的遞交成果，向上級展現自己團隊的效率)

不過這作法產生了許多問題：

1. 規格最後如願被提出大概不到三成，他還常常要求PM把這功能補列入需求，讓團隊做出的功能可以計入credit，卻造成遞交的產品over spec，程式碼變得肥大了 (幸好公司不重視code coverage test)

2. 他的想法可能與客戶或PM的需求有出入，以致於開發團隊需要花更多時間在修改程式上

3. 有時實作必須修改架構，而修改架構會有意外的風險，需要花更多時間來測試與修改；若是為沒有需求的功能來增加這風險與成本，更是讓人懷疑這樣硬做的決策品質

4. 將開發團隊投入於完成又不被採用的功能，不僅時間沒花在刀口上，排擠了做其他事或進修的時間，每每做一些虛功更是打擊士氣

5. 公司PM常常spec.開得不清不楚、模擬兩可 (就所知，PM對專業知識了解不足，一些細節無法明確定義)，這就造成開發團隊與DQA對spec.解讀不同而常有爭執。而此公司的issue tracking process是紊亂的，常搞到最後，產品最後的長相連PM可能都無法掌握

謀定而後動！

在開始踏出第一步前，先定義好你的目標與目的吧！