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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

培養隨機應變的能力

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

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

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

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

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容