在前文〈失控的專案就從失控的需求開始〉中,提到了專案之所以失控有許多種可能的原因,而在眾多的原因中,失控的需求是很常見到的一種,未妥善的對需求進行管理,或者是低估了需求變更造成的影響,都容易造成需求失控,進一步使得整個專案失控。

需求的失控也可以視為是開發範圍的失控,面對一個持續在變化、持續在擴大的目標,又要如何才能夠評估開發工作何時才能結束呢?這道理很簡單,還是有一些人會期待允許開發範圍變化及成長,卻又不影響到開發的時程及投入的成本。

專案計畫的內容,通常會包括許多面向上的規畫,其中有一個部份,便是主要的工作項目、施行的順序及時程、人員及資源的運用方式等等。

若是規畫本身就有問題,意謂著即使百分之百依照著計畫按表操課,也很有可能無法順利完工,到了專案進行到一半或近尾聲時,才發現計畫有根本的問題,此時,一方面若是回頭重來,又擔心前功盡棄,另一方面,若是在中途嘗試修正偏差的計畫,卻又有可能需要投注大量心血,甚至還不確定是否能重新導正計畫。在不斷嘗試導正的努力中,這才發現專案已經失控。

不適合的專案負責人,以及低估新技術風險
對於一個專案計畫來說,負責做計畫的人當然扮演一個靈魂人物的角色,一旦計畫出了嚴重的問題,即使是執行過程沒有誤差,也是很難將專案完成。有些時候,我們會看到沒有太多開發實務經驗的人被賦予專案計畫的工作,他們便有可能做出無法落實的計畫,進而造成專案的失控。

除此之外,開發團隊所選用的技術造成專案的失控,也是時有所聞。

怎麼說呢?有時候,開發團隊會選擇使用較新或是較受歡迎、主流的技術。很多開發者通常對於新的技術(例如新的應用程式框架,或是新的程式庫、甚至是新的開發方法)都有很多的期待,期待它能解決自己之前長久所受的痛苦,以及遭遇到的問題,而新的技術通常也是瞄準這樣的目標而發展。不過,新的技術通常不那麼成熟,也還有不少問題等著被發掘、被解決。太早開始使用新的技術,時常會低估新技術所帶來的這些潛在風險。

而且,開發團隊對新技術也不熟悉。新技術的熟悉有時在學習曲線過了之後,就可以克服,但若學習曲線過長超過了專案本身的時程,或是新技術本身各種難以預測的問題,不斷在開發過程中浮現,那麼,對於專案中要解決、和該技術相關的工作項目,就很難確切預測它究竟何時才能完成。

即使程式碼的編寫完成,到了測試階段所面對的品質問題,也有可能成為失控的隱憂。因為專案所開發的系統其品質和所採用的技術是息息相關,若所使用的核心技術本身有難解的品質問題,那麼所開發的系統自然也會承襲。這種情況下,除非所採用的新技術開發團隊能解決問題,否則,要倚靠自身處理,難度將會提高許多。

此外,若是邊學習新技術邊在開發中實際運用,還有另一個風險,也就是在專案初期的開發成果可能是較不成熟的產物,通常等到熟悉新技術之後,才察覺初期所開發的內容需要做調整,這時候再回頭修改,又會製造出諸多不穩定的因素,也有可能因此造成失控的局面。

影響專案管理的因素中,「人」很重要

軟體開發是人的產業,除了所制定的計畫有問題、所選用的技術有問題之外,若是所選用的人有問題,一樣有可能造成專案的失控。在前文中提到的專案計畫的問題,很多時候便是來自於選錯了制定專案計畫的人,才造成之後一連串的失控。除了制定專案計畫的人之外,開發團隊中的每個角色,都有可能影響到專案的成敗。

從人的觀點來看,第一個影響的因素是團隊的組成。舉例來說,一個團隊中若是缺乏經驗較為豐富的成員,而多是才剛上路的新手,那麼,在人的因素上就有比較多的變因。人的問題也有可能不是出在經驗的多寡與否,而是出在人的能力或態度。

當團隊中有了不正確的人,而且在專案的進行過程中始終沒有找出問題,或者即使知道了問題卻又未加以矯正時,讓人所產生的問題繼續累積、擴大,也會成為專案中不穩定的因素。只要專案中有不穩定的因素,你很難預計專案會有穩定進展。

例如,專案中有個負責開發重要項目的程式設計者,但他本身能力或是經驗就有問題,無法做出你希望他做出來的東西,或者是即使做出來,也只是徒具表面,事實上,其中還隱藏很多未爆的地雷。等到開始進入測試階段之後,才發現他的東西像是個黑洞,無法預測還有多少問題於其中。這種情況下,程式碼本身具備了嚴重的品質問題,最後有可能因為品質無法快速收斂,也造成了專案的失控。

專案在溝通上的不良,也有可能引發專案的失控,而溝通不良的問題,也有可能是來自於人的問題。例如,專案中有位負責重要項目的程式設計者,他所預估出來的工作時程總是很樂觀,而在專案中即使遇到了困難及障礙,他也不會主動提出,等到預計的期限到了之後,他才將遇到困難的事情道出,但已經錯過了期限。因為他所負責的是重要的項目,如果在專案過程中不斷的發生這樣的情況,就會很難衡量專案的進程,當然也就有可能引發專案的失控。

不論是能力有問題的人,或者溝通有障礙的人,在團隊成員中難免會出現,尤其是新加入的成員,大家對他可能還不甚熟悉。但最終會讓這樣的人引發專案的失控,其實又是管理面的問題。

在管理流程及制度上,沒法子察覺人的問題,進而利用矯正措施來解決人的問題,才會造成之後更嚴重的失控。

很多時候,團隊成員人多,不一定比人少好。因為即使是表面上看似較多的成員數目,但其中有些成員具備了不穩定的特性,就會使得整個專案也變得不穩定起來。不穩定就難以估計和預測,當不穩定到了一定的程度,就會變成失控。

相反的,人數較少的團隊,即使因為人力稍微不足,使得進度會較慢。但進度慢並不是最嚴重的是。進度慢但是可以被準確的估計,我們還是可以得到一個受控制的開發專案。但是進度時快時慢,無法被穩定的估計,會造成管理上的困難。可以預測和穩定,是我們想要妥善管理專案開發過程的兩個重要的元素。

還有一些因素,尤其到了專案後期,也會引發專案失控致使難以管理。像是因為專案前中期太多、太大的需求變更,即使需求變更已被管理,但因為程式架構不具備足夠的彈性來因應變化,導致程式碼不斷的疊床架屋,最後就會使得程式碼本身失去控制。到了後期,任何一點修改,無論是基於修正臭蟲或是滿足需求變動,都很容易引發一連串不可預期的效應,導致每次的修改都引發品質的問題,需要花費一段不易預測的時間才能修正。如果到了後期,修改的動作還不能收斂,那麼程式碼的失控就會造成專案的失控了。

談到目前為止,提到了一些會造成專案失控的原因。大多時候專案失控前會有一定的問題先行浮現,管理機制能預先處理,避免問題惡化造成失控的局面。專案最終會演變成為失控的情況,管理上無法妥善的監督及控制是最大的主因。此外,人是軟體開發最重要的因素,人對了,即使管理上有所問題,正確的人也能將即將錯誤的情況拉回正軌;相反的,人錯了,要花費更多管理的額外負擔,才能維持專案在正常的道路上前進。

作者簡介


熱門新聞

Advertisement