在啟動一個新的軟體項目時，尋求一名在軟體開發領域具有豐富經驗并且可以在項目計劃的早期階段提供協助的專家幫助。這一政策已經被證明可以極大提升項目的成果，然而在項目結束時你還是隻能眼睜睜的看着失敗發生。為什麼會這樣呢？
我們先來學習幾個概念：
目标- 我們想要完成或達成的目标
限制- 在我們所能完成的工作上的内部或外部限制
估算- 在範圍、成本、日程、人員和可能性确定的情況下，對我們所能完成的工作的技術性計算
承諾– 通過選擇一個評估場景并配置設定合适的資源，在一系列的限制條件下達成目标的商務決策
計劃– 一系列項目任務和活動的集合，讓我們可以在确定的範圍、預算、日程以及人員的情況下，有一定的機率可以履行某一承諾
這些概念的清晰定義可以確定項目擁有一個良好的開端——實際的目标和對項目所受限制的了解。若非如此，下面這些因素很有可能導緻項目在一開始就踏上死亡的征程。
01
失敗原因1：在沒有實質的資料和分析的情況下，就接受一個強制的日程安排或完成日期/裡程碑日期
組織中有人推測項目将在某一特定日期完成，無意中整個團隊都會緻力于這一期限。
也許你的預算周期顯示配置設定給這一項目的資金必須花費到今年年底或者下一個版本不會得到資金支援；
也許項目的利益幹系人希望項目能在聖誕節前完成，知道項目已經結束他/她就可以安靜地享受假期。
或者幹脆就是因為利益相幹人特别喜歡整數，希望項目能夠在該月一号釋出。
為什麼一個開發團隊會被設定一個主觀的項目完成日期的原因五花八門。過于狂熱的計劃經常導緻項目人員配備過度的不幸。
02
失敗原因2：添加過多的人員以實作不切實際的日程壓縮
項目經理如何處理過度樂觀的項目計劃？
一個常見的反應就是增加項目組成員，增加的成員經常會比完成項目所需的成員更多。
這樣不僅會大幅增加項目的成本，還會降低項目品質。
讓更多的人參與到項目中會增加錯誤傳達的可能性，也會讓不同部分的代碼整合更具挑戰。此外，“在延期項目中增加人手隻會讓項目更加滞後”是有一些道理的。這些人員通常是從其他項目中調派而來。這會讓其他項目的項目計劃更加滞後并且還要求新的成員能夠趕上資深成員，這樣整體來說生産力是下降的。
03
失敗原因3：未能考慮和調整需求的增長或變化并據此對計劃和預算預期進行必要的調整
“如果……不是更好麼？”這種話有時候是最可怕的，特别是在項目組建的過程中道聽途說而來時。
當然，确實需要時間和場所進行頭腦風暴，這些活動應該在第一階段和第二階段開展。實際上，這兩個階段的目的就是要決定一個項目是否可行，以及應用應該具備哪些功能特性。你可以如此考慮這個問題，第二階段幫助你确定所要建構的内容，第三階段則開始建構在第二階段所确定的内容。在這兩個進階階段之間存在一定的重疊，當處于階段三時，對于一個産品釋出版本來說，應該已經有了一個清晰的必要功能清單。
如果在沒有增加開發時間和預算的前提下就增加功能，需求的增長就會成為問題。實際上，這是在要求在更短的時間内完成更多的工作，這種手段早已被證明無效。取決于其特性和時點，已有需求的變更也有可能成為問題。
隻要變更發生在某一特定疊代的建構之前，使用靈活開發方法的項目就可以處理這些明細需求的變更。不過，對于任何會導緻代碼返工的軟體架構方面的需求變更幾乎必然會對項目的計劃和預算産生影響。
04
失敗原因4：忽略事實和統計資料的情緒化或”全憑直覺的“利益幹系人談判
或早或晚，我們都會與某個我們參與的具體項目緊密聯系并在該項目的産出之上投入情感。對于許多人來說，該項目可能關乎自己的聲望；項目太大經不起失敗，而這經常會讓我們被我們的情感所控制。
當軟體項目的成功或失敗懸而未決導緻個人的事業處于危險之中時，任何相關的業務決策很有可能都會受到影響。壓力可以讓人思維混亂，特别是在賭注巨大之時。為了給客戶留下深刻的印象，某個利益幹系人可能會要求一個12個月的項目計劃安排，而完全不顧之前類似規模的項目報告均顯示了15個月的生命周期。
利益相幹人很可能會忽略項目成員的建議，并聲稱他“感覺”項目團隊可以渡過難關。在這種情況下，憑直覺可能是相當不利的并且有可能直接導緻項目的失敗。
在軟體項目中，無論你是項目經理還是研發或者是測試産品，一定都有這樣的遭遇，希望通過我們的分享，幫助軟體項目管理更加高效！