在開發的過程中，變動是無可避免的，但這些變動該怎麼被監控？對工程師來說，我們使用像是 Subversion、Git、Perforce 等等的版本控制系統；另外針對設計師，則有專屬的 Adobe Version Cue 和 PixelNovel Timeline 軟體。那 Product Managers 該何去何從？
在過去經驗中，我看過無數次 PM 改變產品規格，這代表產品被設計師重新設計且變更，也讓工程師實做完成。一切看起來很美好，然而並非如此。兩個月過去了，產品規格在許多次更新中早就和最初版本相差甚遠，到了此時，你會慢慢忘記在一次又一次的更新中，為什麼要更新或更新了什麼；反之大家只希望開發能儘速完成讓產品上線。
這個問題絕對不是只有在新創公司才會發生，過去我在 Yahoo 和 Trend Micro 工作時遇過同樣的問題，從其他公司來的同事們也同樣經歷過。
最精采（最恐怖）的情況，發生在產品上到正式環境前的測試階段。在某一個神奇的日子，PM 開始測試時，赫然發現這個產品沒有包含他們要求的所有功能，或者根據「規格」，功能根本就不能運作！
什麼？PM 立即產出一個 bug ticket 分配給 RD team，並且表示「規格」中的這項功能不如預期。接著，PM 認為只需回頭找出更多因「規格」產生的偏差和問題即可。
然後，事情沒有這麼美好。當工程師收到一封標題可能為「Bug 9999 : Missing feature X」的 email 通知信，他的眼睛注視著這個 bug ticket，脫口而出無數次的「WTF」，毫無保留地表達他們痛苦的情緒和沈重地心情，「這不是 bug，這是需求變更！」
- 是怎麼得出這個結論的？實際走一趟工程師的思考迴路：
工程師：有規格提到這個功能嗎？
工程師：我來檢查一下規格
工程師：咦！沒有看到。我再去看看其他規格，應該是我漏看了。
工程師：還是沒看到，這一定是個變更需求，最好跟 PM 說明一下
PM：它當然有在規格裡，看看規格 Z
工程師：我檢查過規格 Z，並沒有看到它
PM：噢等等，是規格 Y
工程師：不對，還是找不到
PM：我找到它了！一直都在規格 X 裡面
工程師：規格 X？它為什麼會在規格 X 裡？我負責的是規格 Z 的功能
PM：是哦，我不覺得改變那個規格會影響到這個規格
工程師：我的規格 X 中沒有它，你是不是剛才才把它加進 X 規格裡？
PM：沒有，它從頭到尾都在規格 X 中
工程師：那為什麼我的沒有它？
工程師：我們來檢查版本的歷史紀錄
PM：什麼叫做版本的歷史紀錄？這個就是啊！一個版本，我修改過後的版本
工程師：……
OK，雖然這個舉例可能有點誇張，但你我都經歷過或有類似的情境。在這個行業裡，我們一定有更好的工具可以在處理需求變更的同時，讓工程師、設計師和產品經理們都愉快的工作。到底有沒有一種方法能同時適用於新創公司和大企業呢？我非常希望答案真的存在，但目前還是沒有找到能確實解決的辦法，所以先從頭做起吧！
本文作者 David Shariff ，Richi 技術顧問。他曾擔任 Yahoo! 前端工程師及網頁技術傳教士，也曾任職於趨勢科技擔任 UI 工程師；擁有豐富網路技術開發經驗，包含 HTML5, CSS3, JavaScript 以及 PHP 等。本篇轉摘自他的部落格《David Shariff》。
如果你也是有理想有才能的 RD，我們正在尋找你的加入：https://richi.com/marketing/careers
（圖片來源：Jason Michael, CC Licensed）
Programmer 改變了我們的世界。Programming 精進之路，是條漫長的修煉過程。你的 Programming Style 是什麼？歡迎投稿《TechOrange》 Programming Style 專欄，和大家分享你的軟體開發經驗，不管是程式開發的實作分享，或是軟體專案管理的真實案例，亦或是產品發展的心路歷程。 歡迎來信 [email protected]，讓世界知道，你如何埋首努力寫出準備改變世界的 Code。
