軟件項目失敗經驗總結
1、在項目初期沒有進行風險的管理探討，項目遠景定義和功能集合的詳細定義。
當項目走了很遠，出現很多問題的時候，領導總算想起要做一個邊界定義，但這個時候已經遲了，項目已經變得不可控制。
經驗總結：
由於客戶一般對計算機不是很瞭解，和他們交流是用軟件行業的專業俗術語，他們根本就不懂，如果用文檔也很難把需求寫得那麼明白，而且文檔很多的話，客戶都看煩了，很不直觀。
如果讓客戶一看就可以看出這個就是他們想要的，我認爲最好的方式就是做系統原形（界面的功能模擬）。
系統原形應該在需求分析師的指導下完成，當然開發只是界面的功能模擬，沒有底層代碼的實現。這樣做的目的有三個好處，一是客戶很直觀的看到他們的系統是什麼樣子的以及怎麼操作，二是這些開發的成果是可以二次利用的，三是可以更好的激發客戶的需求。
2、不注重用戶參與。
沒有一開始就讓用戶參與詳細需求的制定的做法，大部分都是靠需求採集人員的猜想，猜想往往和實際有差距，造成系統功能不切合實際，與項目實際需求差距大，運行效果差。
經驗總結：
項目的開始和結束用戶是需要一直參與進來的，我們每做個可以運行的功能等就需要和用戶交流，這樣可以避免很多風險也可以儘早發現需求的誤解的等等。
需求調研前期的《信息化規劃》、《目標與範圍》和需求調研末期的《軟件開發需求規格說明書》都要跟客戶簽字確認，這樣既能保證我們所理解的需求就是客戶所要的，也使得項目末期跟客戶驗收時有據可依。
3、集團化以後，項目經理沒有意識到信息化核心問題是管理變革問題，還跟着原來的思路開發軟件。
在組織架構、權限、供應商等方面與力和集團理解不一致，沒有分別按組織進行區分。
經驗總結：
要根據企業業務需求制訂策略,調整軟件組織結構, 詳細設計軟件各組織架構之間的邏輯關係，做好這些最基礎的功課，避免信息化項目成爲無本之木。
4、軟件開發人員、設計人員能力的低下、項目經理的管理能力不足。
低素質開發人員由於沒有接觸過實際業務，無法跟客戶溝通，甚至害怕客戶提出需求，總是擔心客戶
的需求會增加自己的工作量，不願配合。導致無法理解真正的需求，也無法改進系統功能。
設計人員能力的低下，設計系統結構時過於定製，系統的可擴展性較弱，給後期維護帶來巨大的負擔和維護成本的激增。
當出現嚴重問題時，項目經理沒有根據現階段狀況重新評價需求分析結果、開發人工數估算、設計結果等就匆忙採取頭痛醫頭、腳痛醫腳的措施，致使問題更嚴重。
經驗總結：
實行雙項目經理制度：爲開發項目設定兩個項目經理崗位，一個負責技術崗位，另一個負責管理崗位。 目前，國內的軟件開發企業的項目經理一般都是一名，而且是技術出身的佔絕對多數，他們主要擅長的是技術研發，在管理方面先天不足，這不利於項目風險管理和控制。通過增加專門的管理經理崗位，可以彌補技術出身的項目經理的不足，提升軟件開發項目的管理水平。而且這樣的經驗也已得到了國外業界大多企業的認可。
技術崗位：負責技術框架的穩定性和可擴充性、質量的保證、風險的預測以及數據庫的設計，模塊測試、接口測試、白盒測試等；
對於該項目具體需要多少人員、時間；到底需要什麼層次技能的程序組組長和具體開發人員給出詳細的計劃；
對程序組每週具體的開發目標的進行檢測驗收，保證開發進度。以及其它需要考慮的問題等，如網絡速度，服務器訪問量，數據庫查詢優化，都需要整體考慮。
管理崗位：掌握行業知識、項目的前期調研、需求分析、功能模塊架構設計、人員的管理、實施計劃的安排執行和跟蹤。提交《目標與範圍》和需求調研末期的《軟件開發需求規格說明書》。
一個項目在前期的工作非常重要，就算是一個錯誤的話，後面有再強大的開發團隊也是白搭。我們還是一個年輕的團隊，很需要公司來培養這樣的人才，如果是遇到項目，再招外來人員來擔當這樣的工作，風險是可想而知的。
而且這樣的人員肯定是從項目實戰中成長起來的，不是有其他軟件項目管理經驗的人員或者技術開發人員轉過來就可以做好的，更不是從書本或者參加某些培訓就可以學到的。
5、一味的追求快速開發，時間進度。
每天都加班加點地工作，造成人員流動的擴大以及工作效率的降低。最後無論客戶，還是開發人員，都想早點結束項目。
經驗總結：
項目中有個不變的金三角法則，即時間、功能和資源。我個人的意見是用我們的實際能力按照一個正常的進度去做，一個項目在功能、時間和資源一定的情況下，沒有捷徑可以走的，必須一步一個腳印。
6、鬍子眉毛一把抓，不分主次。
整個項目沒有指定里程碑或規定設計評審期，沒有計劃什麼時間節點完成某一個組織或部門的信息化評審後，再進行下一個階段的開發計劃與實施。攤子鋪得太大，軟件人員和準備嚴重不足。
經驗總結：
根據企業不同的發展階段，按照規劃逐步深入，這樣一方面可以避免投資的盲目性，另外一方面在前期的投入收到效果後，再進行下一階段投入的同時，員工和企業領導也容易接受，軟件人員的壓力也會相對減少。
7、開發結果不驗收測試，開發技術水平低下。
開發結果沒經過測試就給客戶上線使用，造成報表的數據很多對不上賬目，已經打印出來的報表，過幾天再打印數據就不一樣了。
由於項目經理沒有明確要求技術水平，寄希望於員工自己努力，造成打印的單據上，‘毛重’減去‘皮重’ 不等於‘淨重’的情況。
經驗總結：
必須做好充分準備的開發計劃，對於該項目具體需要多少人員、時間；到底需要什麼層次技能的程序組組長和具體開發人員給出詳細的計劃。
8、沒有項目總結會議，不重視項目質量。
軟件從實施開始就產生了很多問題，但遺憾的是從開始到結束沒有組織過一個項目總結會議，問題日積月累，最後導致項目失敗。
不重視項目質量。在代碼和數據庫設計中時間投入很少，這些工作本來就是比較抽象的，需要不斷的研究和推敲才能設計好的，但是我們爲了時間進度，很快就趕出來了。
經驗總結：
每日必須召開項目總結會議，隨時捕獲風險，當日事當日畢。
軟件開發初期的時候，就開始猛抓質量，而不是走“先上線、後優化”的項目常規實施方法。若發現質量不合格的地方，就讓開發人員重新返工。
9、軟件版本發佈週期頻繁。
幾乎每天都需要進行一次版本更新，有時候1天更新幾次。更新完成後，客戶無法登陸，軟件功能無法使用，以前錄入的`數據看不見等情況。讓客戶怨聲載道，罵聲一片。
經驗總結：
發佈週期爲1周1次或2周1次，在版本更新前，必須做好充分的測試，方可交給客戶使用。
10、不重視客戶體驗，缺少抵禦風險的獎勵機制。
系統不以客戶爲中心,不能提高業務部門的工作效率,忽視了客戶體驗；通常10分鐘能完成的工作，工作人員操作軟件1小時才能完成。
很多時候加班是沒有加班費的，並且在實施過程中又沒有任何獎勵。所以，員工認爲是這套系統拖累了他。雖然項目對公司有益，對他個人就沒有多少好處了。
經驗總結：
公司應該拿出一部分預算，有計劃有規模地組織用戶進行測試，對操作員給出的體驗意見做好詳細的記錄，並給予充分的重視，對其中有用的軟件改進意見給出相應的獎勵。做好足夠的風險應對計劃，抵禦這種影響所帶來的對系統本身的順利實施以及實施人員的信心和工作激情的衝擊。
11、缺少數據風險意識。
在系統的並行階段，沒有統一的基礎數據，如材料編碼、單據標準等。數據錄入的缺少合理安排，缺少數據風險意識。
用戶總是反映報表數據與小票單據帳目對不上，錄入的小票數據丟失了。
軟件系統是一個高度集成的系統，一個環節的出錯將可能導致一系列的錯誤，所以，對數據的準確性提出了很高的要求。
經驗總結：
必須制定《公司基礎信息編碼》，搭建了整個信息化制度。在項目實施過程中，針對類似的問題也不能光靠人工對賬減少錯誤，而應該採取一定的控制措施，利用系統設置，做好問題的預防措施。比如我們可以建立每日審賬制度，在系統中進行設置，每天錄入完成的票據都進行覈對，覈對完成後進行鎖賬。 出臺《操作規程》，《操作員獎懲辦法》等等，規避風險。
12、不注重細節。
天下大事，必做於細。1%的錯誤往往會導致100%的失敗。力和項目在開發的時候，僅僅是滿足於“軟件可以使用”或“功能能夠實現”的情況，並沒有關注到每個設計、每次改動、每天的操作。
經驗總結：
在此對之前開發過程中一些可以改進的細節列出，進行總結，在今後的開發中將進行改進。
（1）軟件每一個打開的窗體都應該寫上標題，而不能是默認的標題。
（2）操作按鈕位置、操作順序必須一目瞭然。
（3）軟件的功能都加上快捷鍵，使它適應不同操作習慣的用戶。
（4）每一個窗體都加上“關閉”快捷鍵，當用戶需要關閉窗體時，只需要點“ESC” 鍵就可以退出，方便用戶的操作。
（5）所有輸入文本框都必須按照用戶的業務要求進行排列，使用戶可以更快更好地輸入數據。
（6）進入系統以及退出系統時，如果程序執行比較耗時的代碼，應該給出個提醒，而不能讓用戶傻等，最好放到線程中處理，不能讓主線程出現假死狀態。
（7）用戶登陸的窗口，應該自動幫用戶記住用戶名，用戶可以自己確定是否要記住密碼。
（8）複雜的查詢條件，錯誤提示之後，原來的輸入是否都還保存？如果都沒有了，用戶要再輸入一遍會很煩。
（9）查詢錯誤或無結果，必須有提示。
（10）下拉框中的數據必須有排序。
（11）系統中的各種提示必須要合理，不能有誤導用戶的情況。
當然，還有許多需要注意的技術和非技術的細節問題，往往我們技術人員覺得不重要的東西偏偏是用戶覺得最重要的。我相信，在軟件開發的過程中，你只有琢磨你的用戶是怎麼想的，你才能使我們的軟件更加完美，付出得越多，得到的越多。
13、沒有結果的結束。
我們幾乎聽不到有人出來說項目失敗了，我們聽到的是延期、暫停、取消等等形容詞，但是其實，我們其實應該承認，我們有做了一個失敗的項目。
經驗總結：
我們花了錢，項目失敗了，但至少應該買到教訓。
項目的成敗是變數多多，既有技術的，也有管理的，也有關係的，既有自身的，也有客戶的，但是隻要我們把我們可以控制的做好了，至少這個項目成功了一半。
