主動積極擁抱變化

江湖傳言：「要殺一個程式設計師不需要刀，改三次規格就好」，由此可見，對於軟體開發規格出現變動的狀況，是多麼受到程式設計者的痛恨。

的確，我們所認知的，程式設計者往往視規格變動為罪大惡極，是他們最不喜歡在開發生活中發生的事情。

開發人員厭惡規格變動的兩大理由

為什麼程式設計者那麼不喜歡規格變動？事實上，可能不是只有這一行的人，才討厭自己的工作規格被改掉，對大多數的行業從業人員而言，可能都不喜歡這樣。

就像蓋房子的工程團隊，也不會希望房子蓋到一半時，結果被要求更改房子的建築規格吧？

為什麼更改規格那麼令人討厭，最大的原因之一，是因為你在前期所做的一些「布局」和「鋪陳」都是基於已知的規格來做的。

例如，你已經先設計好一組API，是為了滿足所知規格而做的，但是，當規格發生變動時，你所打算拿來用的API很有可能就變成不適用了，就造成了你要從底層開始改起。

改一個已經成型的東西，是滿麻煩的事，因為，即使要改的只有一個點，也可能影響到好幾個點需要跟著一起改。甚至，最差的情況，還可能得「砍掉重練」。

除了被改掉的部份算是白費工之外，還衍生出額外的修改工作，這當然令程式設計者覺得不開心。同時，那種「和預期不同」的心理因素，也會讓人情緒不佳，甚至感到失落。

但是，在軟體的開發實務中，愈來愈少遇到沒有規格變動的情況了。

之所以軟體規格會變動，有很多種可能性，首先是思考需求和規格的時候不夠周嚴、甚至是沒想清楚，以致於在開發過程中，才想到規格中所遺漏、所欠缺的。

還有一種原因也很常見，那就是「三心二意」。也就是可以主導規格的人，今天覺得某個功能應該如何如何，但明天可能又突然改變心意，改成另一種模樣。

這樣還不是最慘的，最慘的是，當開發者改成他想要的樣子之後，他又想改回原狀。

在上述的兩種變更規格的原因裡，若要解決第一個狀況，只要制定規格的人提升本身的能力，以及所使用的方法，可以盡量避免。

當然，沒有人的腦袋是無懈可擊的，但是應該盡可能在制定規格時，運用所知的知識及技巧，讓規格盡可能完備，就可以降低日後變動規格的幅度及機會。

只要能做到這件事，就可以節省不少成本，以及……來自程式設計者的怨氣。

而第二個原因發生時，則突顯更嚴重的問題，為什麼有權利主導規格的人，可以不在深思熟慮之後就變動規格？為什麼他可以任意挑選時間點來變更規格？而這樣變更了規格，又改回了原狀，是否需要有人因此而負責呢？

因為規格的變動絕對隱含著額外開發成本的支出，而不單只是影響到程式設計者的心情而已。只要有規格的變動，就會增加人力成本，而且也會讓時程受到影響。

所以，規格的制定和變更都應該謹慎，換言之，由於懷著「反正先這樣，日後再見招拆招」的心情，就會造成規格變動，也就會導致成本提高，甚至時程延遲。

盡量避免造成無所謂、沒意義的規格變動，是一個基本的原則，但是另一個原則就是要認清：規格總是會變動的。

規格變動無法避免的真正原因

並不是所有的規格變動，都是沒有意義的。我明白程式設計者知道規格要變動時的心情，但是很多時候，規格的變動並不是基於上述的原因，而是有它不得不的理由。

舉例來說，公司的營運會有一些商業目標需要達成，而商業目標有時、甚至是時常得因應時空環境一直調整。

例如，看到了競爭對手所推出的新產品，有著必須要追趕或是擊敗的功能，而競爭對手的功能，對於你們的產品規畫者來說，帶了新的啟示，使得他打算修改你們的產品功能。

規格能不能不改？當然可以，但是，倘若在這個時候不變動規格，直到軟體上市之後，才開始規畫下一階段的新功能，市場上，你很可能在這個時間點被競爭者的產品在打敗。

現階段軟體的釋出週期愈來愈短，尤其像網站服務或是手持裝置上的App，更新功能的頻率尤其高。這意謂著市場的變化更迅速，如果你想要獲勝，就得隨著市場的趨勢及競爭者的對向，持續調整自己的產品。

身為開發團隊的一員，我覺得沒有必要對於所有的規格變更，都抱持著負面的態度，規格變更會造成額外成本是沒錯，但是很多時候考量到商業上的策略及目標，是必須選擇去變更規格的。

倘若不調整規格，就可能變成一個不能用，或沒有競爭力的產品時，規格的變更就是一個不得不的選擇。

這也是近幾年來敏捷開發的方法大行其道的原因之一，為了因應更頻繁的軟體需求變動，開發團隊必須用更輕量化、更敏捷的開發方法來因應，而除了這些方法之外，更重要的，便是面對規格變動的心態和文化的轉變。

因為，如果你只是仇視所有的規格變更，貶低它們的價值，這樣是沒有太多的實質意義。

培養隨機應變的能力

我們一方面，應該審慎管理需求及規格的變動，另一方面，也應該要積極轉換成為具有適合變化、能夠因應變化的體質。

從開發方法及流程來說，需求必須被管理，需求的變化也是。

需求的開發、規格的制定，都應該有對應的方法，而不是任意為之。同樣的，規格的變更也是。

對於誰能變更規格、能在什麼時間點變更規格、以及變更規格之後有什麼配套工作需要進行、 ……等等問題，都需要透過管理來規範及回答。

只有產品經理才能變更規格，這是回答誰能變更的例子；將軟體開發畫分為一個個「iteration 」的團隊，可以在提出規格變更之後，於下一個「iteration 」實施，這是時間點的例子；變更規格之後，檢查追溯表來了解會受到影響的項目，並且重新評估時間、調整時程，這是變更規格後配套工作的例子。總之，進行這些相關的項目時，都必須有明確的定義及管理。

除此之外，將團隊的文化調整成「認知變化是不可或缺的本質」，將心態從「消極抵抗變化」轉換成為「積極適應變化」也很重要。從開發方法及流程上，就把頻率更高的規格變化納入考量，在架構設計上，也朝向「能因應變化的架構」及「能因應變化的設計」。

對開發者而言，在從事設計時就直接將變化納入考慮，這就是一種主動的心態，表示已經在為未來的變化做準備，建立之後逐步演化的基礎。這麼一來，當變化發生時，所產生的衝擊和影響，就會比較小。

整體來說，變化多半勢不可免，與其消極等待變化傷害你，不如積極擁抱變化。