虛假的項目進度該緩行了

發布日期:
2017-04-14

瀏覽次數:

作為漢捷咨詢顧問,我在研發咨詢工作中遇到一些企業,有的會說:“在我們公司,軟件項目的進度不是問題,比如要求兩個月交付,開發人員全力以赴,最后總是準時交付。”這是真的嗎?我當然不會幼稚地信以為真。再進一步交流會發現,雖然項目準時交付了軟件,然而需求文檔、設計文檔一概沒有,并且交付后,因為質量問題,用戶無法使用,還需要四個月的時間不停地修補,之后用戶才真正地使用上。那么項目實際進度到底是四個月,還是六個月呢?

我們再來看一下被普遍接受的軟件的定義: 軟件(software)是計算機系統中與硬件(hardware)相互依存的另一部分,它包括程序(program)、相關數據(data)及其說明文檔(document)。

很多人都有體會,在大學實驗室寫出的代碼和在企業做出的軟件絕對是兩回事:在實驗室的代碼根本無法稱為軟件產品,沒有文檔,沒有大量的用戶,代碼的非功能特性也很少考慮,如可靠性,開發過程也不會按照軟件工程方法進行的。與《人件》齊名的另一本軟件工程經典之作《人月神話》這樣描述什么是真正有用的軟件產品:

報紙上經常會出現這樣的新聞,講述兩個程序員如何在經改造的簡陋車庫中,編出了超過大型團隊工作量的重要程序。接著,每個編程人員準備相信這樣的神話,因為他知道自能以超過產業化團隊的1000代碼行/年的生產率來開發任何程序。

為什么不是所有的產業化隊伍都會被這種專注的二人組合所替代?我們必須看一下產出的是什么。

虛假的項目進度該緩行了

圖1.1:編程系統產品的演進

在圖1.1的左上部分是程序(Program)。它本身是完整的,可以由作者在所開發的系統平臺上運行。它通常是車庫中產出的產品,以及作為單個程序員生產率的評估標準。

有兩種途徑可以使程序轉變成更有用的,但是成本更高的東西,它們表現為圖中的邊界。

水平邊界以下,程序變成編程產品(Programming Product)。這是可以被任何人運行、測試、修復和擴展的程序。它可以運行在多種操作系統平臺上,供多套數據使用。要成為通用的編程產品,程序必須按照普遍認可的風格來編寫,特別是輸入的范圍和形式必須擴展,以適用于所有可以合理使用的基本算法。接著,對程序進行徹底測試,確保它的穩定性和可靠性,使其值得信賴。這就意味著必須準備、運行和記錄詳盡的測試用例庫,用來檢查輸入的邊界和范圍。此外,要將程序提升為程序產品,還需要有完備的文檔,每個人都可以加以使用、修復和擴展。經驗數據表明,相同功能的編程產品的成本,至少是已經過測試的程序的三倍。?

回到圖中,垂直邊界的右邊,程序變成編程系統(Programming System)中的一個構件單元。它是在功能上能相互協作的程序集合,具有規范的格式,可以進行交互,并可以用來組裝和搭建整個系統。要成為系統構件,程序必須按照一定的要求編制,使輸入和輸出在語法和語義上與精確定義的接口一致。同時程序還要符合預先定義的資源限制——內存空間、輸入輸出設備、計算機時間。最后,程序必須同其它系統構件單元一道,以任何能想象到的組合進行測試。由于測試用例會隨著組合不斷增加,所以測試的范圍非常廣。因為一些意想不到的交互會產生許多不易察覺的bug,測試工作將會非常耗時,因此相同功能的編程系統構件的成本至少是獨立程序的三倍。如果系統有大量的組成單元,成本還會更高。

圖1.1的右下部分代表編程系統產品(Programming Systems Product)。和以上的所有的情況都不同的是,它的成本高達九倍。然而,只有它才是真正有用的產品,是大多數系統開發的目標。

因此,在很多企業,號稱以多高的效率完成了某軟件產品開發,其實,完成的是更像上面所描述的程序(program),或者類似于大學實驗室開發出產品,如果把程序再變成有用的變成系統產品,則要花費數倍的時間。如果以生產出“程序”作為項目結束的標志,那么這樣這個看起來很讓人滿意項目進度只不過是個虛假的進度,它與項目真正的完成所需要的時間還有非常大差距。

虛假的進度,在很多情況是因為倒排進度計劃導致,客戶或者管理層要求四個月完成項目,那么項目要做出一個四月完成的進度計劃;如果客戶或者管理層要求兩個月完成項目,那么項目就要做出一個兩月完成的進度計劃。接下來,項目會想方設法按時“結束”這樣項目。當然這些項目“結束”的標志是代碼已經寫完了,至于代碼是否滿足客戶的需求以及并要的文檔工作都是被挪到項目范圍之外去考慮了。

虛假的項目進度掩藏了項目的開發問題,特別是項目開發效率問題。被虛假的進度所迷惑,大家看不清項目的實際進度和實際成本。我遇到一個企業,有個五萬元的小項目,他們宣稱兩個人兩個月完成了,但實質上后續投入了至少一人年的工作量在不斷地完善那兩個月完成的那個半成品。如果以總的實際的工作量來算,這個項目不知倒貼了多少錢!

虛假的項目進度最大的危害是它變成了混亂的借口,如果要進行研發管理變革,進行規范化開發,一些常常會說:“有流程是好,可是流程會降低我們的開發效率,而我們項目進度要求又非常高!”只有揭穿在混亂中開發的項目進度的虛假性,研發變革才成為可能。

最后,在到處充斥著虛假項目進度的企業,不會孕育出“第一次把事情做好”的文化,質量和效率都不會在這樣的企業中生根發芽;相反,會滋生隱瞞、欺騙、浮夸,蒙蔽了管理層的雙眼,讓團隊斗志,讓優秀員工心灰意冷。

虛假的項目進度該緩行了!

相關推薦