開發規模增加的因應之道

前些日子，有一位同樣從事軟體開發工作的朋友，向我提及了他們最近的一個開發案子的情況。

這個案子在一開始確認需求後，已經押了一個頗為緊迫的時程。也就是說，在理想的情況下全力以赴，應該可以趕得上。但是，就像我們大家在大多數的開發案中所經歷的，總是難免會有需求的增加以及需求的變動。而在這個緊迫的開發案中，很不巧地，也遇上了不少的需求增加及變動，令開發人員感到壓迫的是，即使有新增或修改的需求，專案所訂定的時程仍然是紋風不動，仍然維持在針對一開始所制定的需求範圍時所估算的時程。

加入的需求或許都不大，所以，代表使用者端加入需求的代表者，總會提到「這個需求應該不大，所以時程應該不需要變動吧？」。這或許是滿多人心目中的想法，但是，一個小需求要若是花半天的時間開發，意謂著起碼需要半天的測試時間，十個需求就需要增加十天，而這還不包括之後除錯，以及修正錯誤所需花費的時間，更別提若是已經完成的部份要進行更動，所需要克服的連動修改部份。

上述的這個例子，其實說明了許多人對於開發時程的迷思。首先，所有需求的增加及變動，都是需要付出代價的。即使一個增加的需求看似多麼的微不足道，它都需要付出人力及時間做為代價。常言道，積少成多，即使需求的增加再怎麼小，仍然有所代價，而且累積起來，最後還是相當可觀。

另一方面，我們時常認為一個需求的規模是「小」的，這是因為著眼在「撰寫程式」的部份，但是，就像前一段中所提到的，只要你寫了一段程式，就會帶來起碼同樣份量、而且實際上往往更多的測試時間，再加上更多的反覆除錯、修改、驗正修正的時間。也就是說，在撰寫程式端估算的時間，會被放大好幾倍到後端的各個階段去。所以，一個新增需求的代價，往往被遠遠的低估。

但是，很有趣的是，在專案的進行過程中，我們時常看到即使中間加入了新的需求或是做了變更，最終的完成時程卻沒有因此而調整。

這樣的想法合理嗎？其實很明顯的，增加了工作，就應該拉長時間的道理，是再明顯不過了，卻還是有為數不少的人，沒辦法正視這件事。

控制住那些會影響專案進行的因素
大家都知道，專案中有四個重要變數，彼此之間相互交錯影響，即：成本、品質、時間和規模。這四個變數之間存在著連帶的關係，倘若你想要調整其中的一個變數，一定會有其他的變數受到影響。這同時也讓你可以透過控制其中的一個或是若干個變數，來達到控制其他變數的效果。

例如，你希望增加規模，套用在軟體開發專案上，這通常意謂著增加你想要達到的功能，那麼其他的幾個因素就勢必要有所變化。你可以選擇增加成本，像是投入更多的人力，雖然會讓成本增加，但是有機會在時間和品質都不更動的情況下，來達到更多規模。

倘若你的人力固定，不能再增加，但又不希望品質受到影響，那麼就只有增加時間才有明顯效果。

當然，若成本、時間都希望保持固定，唯一能控制的就是犧牲品質。當然，有些時候犧牲品質也可以是選項，當成本和時間都不能調整時，降低品質、欠下控制範圍內的技術債，未嘗不可以考慮。這四個變數之間交互影響，其實不難想像和理解，但就我的觀察，真正困難的卻是要一些人去認清、並正視它們之間必然存在連動關係。你很難調整了任一因素，而不使得其他變數受到連動影響。

以軟體開發來說，生產力受到很多因素影響著，例如，開發本身的能力、工具的優劣、架構的好壞、甚至工作環境的好或不好，都會影響到生產力。但是，一個團隊的生產力在專案的開發過程中，很少會有具體的變化，一般來說，會保持得差不多。那麼，在這種情況下，這四個變數之間的連動是一定會發生的。

當你增加一些需求，形同增加了專案的規模，那麼這個決定就勢必造成其他三個因素的變動。如果你不增加人力、也不想犧牲品質，那麼最後的結果就是，時間一定會拉長。時間會拉長的結果，不是做專案管理的人維持期限不動，它就不會發生，因為它必然要發生，因此，即使專案管理上不去更動期限，但最後呈現的結果，就是交付時間延遲。

加班只能暫時解決問題
當然，有可能最後是在期限內完成，但時間還是增加了，只不過是反映在每日的工時之上，也就是說，透過增加每日工時來使得最後期限維持不變，但還是投入更多的總時間，使得規模增加之後，仍然在原本的期限內完成。而這麼做是什麼？每日工時的增加就是加班。所以說，規模想增加、品質不想犧牲、人力又不想擴增，時程又想保持不變，最後的結果就是實施加班了。

我從來都不認為軟體開發可以像「全民大煉鋼」那樣，只要有充足的熱血、眾志成城，就可以讓生產力突發猛進，我相信這種模式在短期的衝刺情境下有可能，但是只要開發的時程拉的夠長，終究還是會回歸到平均的行為上，展現真正的生產力。

如何增加生產力是另一個議題，在這一回裡關心的是，這四個因素之間的變化幾乎是一定會產生連動的。有些人不願面對現實，還是覺得即使增加了需求，時程仍然可以維持不變，這反而不能提前理性、冷靜的採取對策，而是眼睜睜的看著延遲發生。

對於規模的增加，加班的手段能不能用？當然可以用，但是就跟跑馬拉松一樣，你沒辦法從頭到尾憑藉著衝刺來獲得冠軍，你必須有一個好的平均速度才行。加班就是一種短期衝刺，它可以讓你達成短期的里程碑，但它不是萬靈丹。它就像跑步時的短程衝刺一樣，但衝刺完你會更累，需要時間才能恢復到正常的生產力。

長期加班的結果，就是讓單位時間的生產力降低，最後即使你投入更多的時間，你也沒辦法得到更多的生產力。一段時間的加班之後，要記得讓你的團隊成員休息一陣子，以便回復活力及生產力。

增加人力的效果有限
對於規模的增加，增加人力的方式能不能用？當然也可以用，但是效果不見得好。

在專案初期增加人力的效果，會好過於專案後期增加人力的效果，這是因為愈到後期，專案的產出也愈來愈複雜，新加入的人會需要花更多的時間，才能了解專案已完成的產出，因此，新加入的人不但沒辦法帶來顯著的生產力，甚至會因為需要舊成員的引導及協助，反而影響到了舊成員的生產力了。此外，增加人力也會增加管理的複雜度，而且增加的速度比線性成長還快。這都是增加人力可能會有的潛在性問題。

當規模增加時，降低品質是調整其他三個變數中最不好的選擇，但有時可以接受。當其餘的兩個變數顯然沒有機會調整，但是略為降低品質，像是借一點可控制範圍下的技術債，再找合適的時間償還、或是不修正確定不會踩到的臭蟲、……等等，降低品質這個選項就變得可以接受。例如，一定要在某個不可以錯過的記者會上發表產品，因為展示情境是固定的，所以即使明知有些臭蟲存在，只要展示情境不會涉及，那麼不去修正，還可以接受。

規模增加是開發專案中很常見到的情況，程式設計者通常不愛，但這很難避免。但是對專案管理者來說，還是得認清這個現實，也就是規模增加，幾乎必然造成其他三個因素必須改變。即使你不主動控制它，它也會自我展現該有的調整。只有認清這一點，才能夠提前做因應及決策，也就是主動將這些變數控制成你想要的樣子，而非等待它們自我展現，像是不受控制的交付延遲或是品質低落。