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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容