軟件項目最常見(jiàn)的失敗原因分析
發(fā)布時(shí)間：2015/9/11 9:58:00
在啟動(dòng)一個(gè)新的軟件項目時(shí)，尋求一名在軟件開(kāi)發(fā)領(lǐng)域具有豐富經(jīng)驗并且可以在項目計劃的早期階段提供協(xié)助的主題專(zhuān)家的幫助。這一策略已經(jīng)被證實(shí)可以極大提升項目的成果，然而在項目結束時(shí)你還是只能眼睜睜的看著(zhù)失敗發(fā)生。為什么會(huì )這樣呢?
項目失敗可分為成本超支、交付延期、質(zhì)量不合格和/或產(chǎn)品未被應用等一種或幾種情況。無(wú)論是否曾經(jīng)參與到項目計劃階段，通常情況下，軟件開(kāi)發(fā)人員都會(huì )首當其沖承擔失敗的責任;無(wú)論怎樣，他們是真正構建這個(gè)應用的人。然而，對項目更進(jìn)一步的審查表明并非所有失敗的項目都應歸咎于開(kāi)發(fā)人員能力不足。
當對這些失敗的項目進(jìn)行評估時(shí)，其中一些項目與行業(yè)趨勢相比完成的“還算不錯”，然而卻被其所在組織認定為失敗項目。其原因在于絕大多數的問(wèn)題都與項目之初有缺陷的評估或錯誤的商務(wù)決策聯(lián)系緊密。為了避免這種情況發(fā)生，整個(gè)組織首先必須要使用標準的評估術(shù)語(yǔ)集合。我們經(jīng)常會(huì )發(fā)現個(gè)人和組織大量地互換使用關(guān)鍵術(shù)語(yǔ)，而實(shí)際上他們各自都有獨特的含義。
目標 - 我們想要完成或達成的目標 約束 - 在我們所能完成的工作上的一些內部或外部的限制 估算 - 在范圍、成本、日程、人員和可能性確定的情況下，對我們所能完成的工作的技術(shù)性計算。 承諾 – 通過(guò)選擇一個(gè)評估場(chǎng)景并分配合適的資源，在一系列的限制條件下達成目標的商務(wù)決策。 計劃 – 一系列項目任務(wù)和活動(dòng)的集合，讓我們可以在確定的范圍、預算、日程以及人員的情況下，有一定的概率可以履行某一承諾。
這些概念的清晰定義可以確保項目擁有一個(gè)良好的開(kāi)端——實(shí)際的目標和對項目所受限制的理解。若非如此，下面這些因素很有可能導致項目在一開(kāi)始就踏上死亡的征程。
1. 在沒(méi)有實(shí)質(zhì)的數據和分析的情況下，就接受一個(gè)強制的日程安排或完成日期/里程碑日期。
組織中的某個(gè)人公開(kāi)推測項目將在某一特定日期完成，這樣在無(wú)意中整個(gè)團隊都會(huì )致力于這一期限。也許你的預算周期顯示分配給這一項目的資金必須花費到今年年底或者下一個(gè)版本不會(huì )得到資金支持。也許項目的利益相干人希望項目能在圣誕節前完成，知道項目已經(jīng)結束他/她就可以安靜地享受假期�；蛘吒纱嗑褪且驗槔嫦喔扇颂貏e喜歡整數，希望項目能夠在該月一號發(fā)布。為什么一個(gè)開(kāi)發(fā)團隊會(huì )被設定一個(gè)主觀(guān)的項目完成日期的原因五花八門(mén)。過(guò)于狂熱的計劃經(jīng)常導致項目人員配備過(guò)度的不幸現實(shí)是為什么軟件項目失敗的另一原因。
2. 添加過(guò)多的人員以實(shí)現不切實(shí)際的日程壓縮。
項目經(jīng)理如何處理過(guò)度樂(lè )觀(guān)的項目計劃?一個(gè)常見(jiàn)的反應就是增加項目組成員，增加的成員經(jīng)常會(huì )比完成項目所需的成員更多。這樣不僅會(huì )大幅增加項目的成本，還會(huì )降低項目質(zhì)量。讓更多的人參與到項目中會(huì )增加錯誤傳達的可能性，也會(huì )讓不同部分的代碼整合更具挑戰。此外，Frederick Brooks (1975) 的主張“在延期項目中增加人手只會(huì )讓項目更加滯后”是有一些道理的。這些人員通常是從其他項目中調派而來(lái)。這會(huì )讓其他項目的項目計劃更加滯后并且還要求新的成員能夠趕上資深成員，這樣整體來(lái)說(shuō)生產(chǎn)力是下降的。
3. 未能考慮和調整需求的增長(cháng)或變化并據此對計劃和預算預期進(jìn)行必要的調整。
“如果……不是更好么?”這種話(huà)有時(shí)候是最可怕的，特別是在項目組建的過(guò)程中道聽(tīng)途說(shuō)而來(lái)時(shí)。當然，確實(shí)需要時(shí)間和場(chǎng)所進(jìn)行頭腦風(fēng)暴，這些活動(dòng)應該在第一階段和第二階段開(kāi)展。實(shí)際上，這兩個(gè)階段的目的就是要決定一個(gè)項目是否可行，以及應用應該具備哪些功能特性。你可以如此考慮這個(gè)問(wèn)題，第二階段幫助你確定所要構建的內容，第三階段則開(kāi)始構建在第二階段所確定的內容。在這兩個(gè)高級階段之間存在一定的重疊，當處于階段三時(shí)，對于一個(gè)產(chǎn)品發(fā)布版本來(lái)說(shuō)，應該已經(jīng)有了一個(gè)清晰的必要功能列表。如果在沒(méi)有增加開(kāi)發(fā)時(shí)間和預算的前提下就增加功能，需求的增長(cháng)就會(huì )成為問(wèn)題。實(shí)際上，這是在要求在更短的時(shí)間內完成更多的工作，這種手段早已被證明無(wú)效。取決于其特性和時(shí)點(diǎn)，已有需求的變更也有可能成為問(wèn)題。只要變更發(fā)生在某一特定迭代的構建之前，使用敏捷開(kāi)發(fā)方法的項目就可以處理這些明細需求的變更。不過(guò)，對于任何會(huì )導致代碼返工的軟件架構方面的需求變更幾乎必然會(huì )對項目的計劃和預算產(chǎn)生影響。
4. 忽略事實(shí)和統計數據的情緒化或”全憑直覺(jué)的“利益干系人談判。
或早或晚，我們都會(huì )與某個(gè)我們參與的具體項目緊密聯(lián)系并在該項目的產(chǎn)出之上投入情感。對于許多人來(lái)說(shuō)，該項目可能關(guān)乎自己的聲望;項目太大經(jīng)不起失敗，而這經(jīng)常會(huì )讓我們被我們的情感所控制。當軟件項目的成功或失敗懸而未決導致個(gè)人的事業(yè)處于危險之中時(shí)，任何相關(guān)的業(yè)務(wù)決策很有可能都會(huì )受到影響。壓力可以讓人思維混亂，特別是在賭注巨大之時(shí)。為了給客戶(hù)留下深刻的印象，某個(gè)利益相干人可能會(huì )要求一個(gè)12個(gè)月的項目計劃安排，而完全不顧之前類(lèi)似規模的項目報告均顯示了15個(gè)月的生命周期。利益相干人很可能會(huì )忽略項目成員的建議，并聲稱(chēng)他“感覺(jué)”項目團隊可以渡過(guò)難關(guān)。在這種情況下，憑直覺(jué)可能是相當不利的并且有可能直接導致項目的失敗。
5. 錯誤，但普遍認為眾所周知的銀彈可以獨自解決項目吞吐量或過(guò)程問(wèn)題。
當其他嘗試都已失敗時(shí)，一個(gè)常見(jiàn)的方法就是改變策略。這時(shí)比較常見(jiàn)的想法就是“我們現在的所作所為一定是錯誤的”以及“我們的競爭對手在做些什么?”也就在這時(shí)，“IT銀彈”的思慮可能就會(huì )開(kāi)始在辦公室中蔓延。例如，某人可能會(huì )建議組織，需要采用最新的流行開(kāi)發(fā)方法。雖然這可能會(huì )將組織引領(lǐng)至一個(gè)偉大的方向，但像這樣的決策決不應該草草定論。無(wú)論你的組織決定采用哪種開(kāi)發(fā)方法，這也只是實(shí)現層面的變化。僅僅是開(kāi)發(fā)方法的轉變并不足以完成開(kāi)發(fā)操作的轉換。 無(wú)論做出什么決策，為了能夠成功實(shí)施，就需要各方均能接受并支持這一決策，并且需要為項目成員提供培訓，而且所有人都需要為同樣的標準負責。否則，每次啟動(dòng)新的項目時(shí)，你的開(kāi)發(fā)策略就基本相當于等待天空的星辰排列整齊，期盼奇跡發(fā)生一樣。如果沒(méi)有經(jīng)過(guò)深思熟慮，實(shí)現這種策略不僅存在令人難以置信的風(fēng)險，同時(shí)也會(huì )減少團隊成員在項目中期提供反饋的機會(huì )。
簡(jiǎn)而言之，造成軟件項目失敗的原因林林總總�；c(diǎn)時(shí)間認真反思一下上述原因是否曾經(jīng)也是導致你的組織中項目失敗的元兇。那么現在是否有了應對它的措施?作為一個(gè)執行領(lǐng)導人，可以做的工作有很多，不過(guò)對開(kāi)發(fā)操作提供支持仍需很大的勇氣。他們需要在合理的預期內運行。顯然，他們仍需要對自己的行為負責，因此就需要歷史績(jì)效數據作為證明他們能力的證據。你需要從多個(gè)不同的維度搜集數據，包括項目的計劃持續時(shí)間、所花費的精力、工作的范圍、項目的整體質(zhì)量以及所達到的生產(chǎn)力水平。
這種情況下，生產(chǎn)率指數(PI)以指數點(diǎn)數作為計量單位，這是一個(gè)有專(zhuān)利的QSM計算單位，范圍從0.1到40。它讓項目之間的比較更有實(shí)際意義并且對軟件開(kāi)發(fā)因子作出了解釋?zhuān)渲邪ㄈ缦伦兞浚汗芾碛绊�、開(kāi)發(fā)方法、工具、經(jīng)驗水平和應用程序類(lèi)型的復雜度。一旦某個(gè)組織建立了已完成項目的倉庫，就可以計算定制化趨勢線(xiàn)，用于基線(xiàn)創(chuàng )建。這些趨勢線(xiàn)作為參考點(diǎn)可用于組織內的項目比較。項目相對于趨勢線(xiàn)所處的位置表明了項目與平均水平的相比孰優(yōu)孰劣。這會(huì )讓你對組織的當前能力有清晰的洞察。(項目管理者聯(lián)盟)
更多內容詳細咨詢(xún)：http://www.firg8.com/