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