軟件項目失敗經(jīng)驗總結(jié)

時間：2024-09-13 03:00:45

軟件項目失敗經(jīng)驗總結(jié)

軟件項目失敗經(jīng)驗總結(jié)

　　1、在項目初期沒有進行風(fēng)險的管理探討，項目遠(yuǎn)景定義和功能集合的詳細(xì)定義。

　　當(dāng)項目走了很遠(yuǎn)，出現(xiàn)很多問題的時候，領(lǐng)導(dǎo)總算想起要做一個邊界定義，但這個時候已經(jīng)遲了，項目已經(jīng)變得不可控制。

　　經(jīng)驗總結(jié)：

　　由于客戶一般對計算機不是很了解，和他們交流是用軟件行業(yè)的專業(yè)俗術(shù)語，他們根本就不懂，如果用文檔也很難把需求寫得那么明白，而且文檔很多的話，客戶都看煩了，很不直觀。

　　如果讓客戶一看就可以看出這個就是他們想要的，我認(rèn)為最好的方式就是做系統(tǒng)原形（界面的功能模擬）。

　　系統(tǒng)原形應(yīng)該在需求分析師的指導(dǎo)下完成，當(dāng)然開發(fā)只是界面的功能模擬，沒有底層代碼的實現(xiàn)。這樣做的目的有三個好處，一是客戶很直觀的看到他們的系統(tǒng)是什么樣子的以及怎么操作，二是這些開發(fā)的成果是可以二次利用的，三是可以更好的激發(fā)客戶的需求。

　　2、不注重用戶參與。

　　沒有一開始就讓用戶參與詳細(xì)需求的制定的做法，大部分都是靠需求采集人員的猜想，猜想往往和實際有差距，造成系統(tǒng)功能不切合實際，與項目實際需求差距大，運行效果差。

　　經(jīng)驗總結(jié)：

　　項目的開始和結(jié)束用戶是需要一直參與進來的，我們每做個可以運行的功能等就需要和用戶交流，這樣可以避免很多風(fēng)險也可以盡早發(fā)現(xiàn)需求的誤解的等等。

　　需求調(diào)研前期的《信息化規(guī)劃》、《目標(biāo)與范圍》和需求調(diào)研末期的《軟件開發(fā)需求規(guī)格說明書》都要跟客戶簽字確認(rèn)，這樣既能保證我們所理解的需求就是客戶所要的，也使得項目末期跟客戶驗收時有據(jù)可依。

　　3、集團化以后，項目經(jīng)理沒有意識到信息化核心問題是管理變革問題，還跟著原來的思路開發(fā)軟件。

　　在組織架構(gòu)、權(quán)限、供應(yīng)商等方面與力和集團理解不一致，沒有分別按組織進行區(qū)分。

　　經(jīng)驗總結(jié)：

　　要根據(jù)企業(yè)業(yè)務(wù)需求制訂策略,調(diào)整軟件組織結(jié)構(gòu), 詳細(xì)設(shè)計軟件各組織架構(gòu)之間的邏輯關(guān)系，做好這些最基礎(chǔ)的功課，避免信息化項目成為無本之木。

　　4、軟件開發(fā)人員、設(shè)計人員能力的低下、項目經(jīng)理的管理能力不足。

　　低素質(zhì)開發(fā)人員由于沒有接觸過實際業(yè)務(wù)，無法跟客戶溝通，甚至害怕客戶提出需求，總是擔(dān)心客戶

　　的需求會增加自己的工作量，不愿配合。導(dǎo)致無法理解真正的需求，也無法改進系統(tǒng)功能。

　　設(shè)計人員能力的低下，設(shè)計系統(tǒng)結(jié)構(gòu)時過于定制，系統(tǒng)的可擴展性較弱，給后期維護帶來巨大的負(fù)擔(dān)和維護成本的激增。

　　當(dāng)出現(xiàn)嚴(yán)重問題時，項目經(jīng)理沒有根據(jù)現(xiàn)階段狀況重新評價需求分析結(jié)果、開發(fā)人工數(shù)估算、設(shè)計結(jié)果等就匆忙采取頭痛醫(yī)頭、腳痛醫(yī)腳的措施，致使問題更嚴(yán)重。

　　經(jīng)驗總結(jié)：

　　實行雙項目經(jīng)理制度：為開發(fā)項目設(shè)定兩個項目經(jīng)理崗位，一個負(fù)責(zé)技術(shù)崗位，另一個負(fù)責(zé)管理崗位。目前，國內(nèi)的軟件開發(fā)企業(yè)的項目經(jīng)理一般都是一名，而且是技術(shù)出身的占絕對多數(shù)，他們主要擅長的是技術(shù)研發(fā)，在管理方面先天不足，這不利于項目風(fēng)險管理和控制。通過增加專門的管理經(jīng)理崗位，可以彌補技術(shù)出身的項目經(jīng)理的不足，提升軟件開發(fā)項目的管理水平。而且這樣的經(jīng)驗也已得到了國外業(yè)界大多企業(yè)的認(rèn)可。

　　技術(shù)崗位：負(fù)責(zé)技術(shù)框架的穩(wěn)定性和可擴充性、質(zhì)量的保證、風(fēng)險的預(yù)測以及數(shù)據(jù)庫的設(shè)計，模塊測試、接口測試、白盒測試等；

　　對于該項目具體需要多少人員、時間；到底需要什么層次技能的程序組組長和具體開發(fā)人員給出詳細(xì)的計劃；

　　對程序組每周具體的開發(fā)目標(biāo)的進行檢測驗收，保證開發(fā)進度。以及其它需要考慮的問題等，如網(wǎng)絡(luò)速度，服務(wù)器訪問量，數(shù)據(jù)庫查詢優(yōu)化，都需要整體考慮。

　　管理崗位：掌握行業(yè)知識、項目的前期調(diào)研、需求分析、功能模塊架構(gòu)設(shè)計、人員的管理、實施計劃的安排執(zhí)行和跟蹤。提交《目標(biāo)與范圍》和需求調(diào)研末期的《軟件開發(fā)需求規(guī)格說明書》。

　　一個項目在前期的工作非常重要，就算是一個錯誤的話，后面有再強大的開發(fā)團隊也是白搭。我們還是一個年輕的團隊，很需要公司來培養(yǎng)這樣的人才，如果是遇到項目，再招外來人員來擔(dān)當(dāng)這樣的工作，風(fēng)險是可想而知的。

　　而且這樣的人員肯定是從項目實戰(zhàn)中成長起來的，不是有其他軟件項目管理經(jīng)驗的人員或者技術(shù)開發(fā)人員轉(zhuǎn)過來就可以做好的，更不是從書本或者參加某些培訓(xùn)就可以學(xué)到的。

　　5、一味的追求快速開發(fā)，時間進度。

　　每天都加班加點地工作，造成人員流動的擴大以及工作效率的降低。最后無論客戶，還是開發(fā)人員，都想早點結(jié)束項目。

　　經(jīng)驗總結(jié)：

　　項目中有個不變的金三角法則，即時間、功能和資源。我個人的意見是用我們的實際能力按照一個正常的進度去做，一個項目在功能、時間和資源一定的情況下，沒有捷徑可以走的，必須一步一個腳印。

　　6、胡子眉毛一把抓，不分主次。

　　整個項目沒有指定里程碑或規(guī)定設(shè)計評審期，沒有計劃什么時間節(jié)點完成某一個組織或部門的信息化評審后，再進行下一個階段的開發(fā)計劃與實施。攤子鋪得太大，軟件人員和準(zhǔn)備嚴(yán)重不足。

　　經(jīng)驗總結(jié)：

　　根據(jù)企業(yè)不同的發(fā)展階段，按照規(guī)劃逐步深入，這樣一方面可以避免投資的盲目性，另外一方面在前期的投入收到效果后，再進行下一階段投入的同時，員工和企業(yè)領(lǐng)導(dǎo)也容易接受，軟件人員的壓力也會相對減少。

　　7、開發(fā)結(jié)果不驗收測試，開發(fā)技術(shù)水平低下。

　　開發(fā)結(jié)果沒經(jīng)過測試就給客戶上線使用，造成報表的數(shù)據(jù)很多對不上賬目，已經(jīng)打印出來的報表，過幾天再打印數(shù)據(jù)就不一樣了。

　　由于項目經(jīng)理沒有明確要求技術(shù)水平，寄希望于員工自己努力，造成打印的單據(jù)上，‘毛重’減去‘皮重’ 不等于‘凈重’的情況。

　　經(jīng)驗總結(jié)：

　　必須做好充分準(zhǔn)備的開發(fā)計劃，對于該項目具體需要多少人員、時間；到底需要什么層次技能的程序組組長和具體開發(fā)人員給出詳細(xì)的計劃。

　　8、沒有項目總結(jié)會議，不重視項目質(zhì)量。

　　軟件從實施開始就產(chǎn)生了很多問題，但遺憾的是從開始到結(jié)束沒有組織過一個項目總結(jié)會議，問題日積月累，最后導(dǎo)致項目失敗。

　　不重視項目質(zhì)量。在代碼和數(shù)據(jù)庫設(shè)計中時間投入很少，這些工作本來就是比較抽象的，需要不斷的研究和推敲才能設(shè)計好的，但是我們?yōu)榱藭r間進度，很快就趕出來了。

　　經(jīng)驗總結(jié)：

　　每日必須召開項目總結(jié)會議，隨時捕獲風(fēng)險，當(dāng)日事當(dāng)日畢。

　　軟件開發(fā)初期的時候，就開始猛抓質(zhì)量，而不是走“先上線、后優(yōu)化”的項目常規(guī)實施方法。若發(fā)現(xiàn)質(zhì)量不合格的地方，就讓開發(fā)人員重新返工。

　　9、軟件版本發(fā)布周期頻繁。

　　幾乎每天都需要進行一次版本更新，有時候1天更新幾次。更新完成后，客戶無法登陸，軟件功能無法使用，以前錄入的數(shù)據(jù)看不見等情況。讓客戶怨聲載道，罵聲一片。

　　經(jīng)驗總結(jié)：

　　發(fā)布周期為1周1次或2周1次，在版本更新前，必須做好充分的測試，方可交給客戶使用。

　　10、不重視客戶體驗，缺少抵御風(fēng)險的獎勵機制。

　　系統(tǒng)不以客戶為中心,不能提高業(yè)務(wù)部門的工作效率,忽視了客戶體驗；通常10分鐘能完成的工作，工作人員操作軟件1小時才能完成。

　　很多時候加班是沒有加班費的，并且在實施過程中又沒有任何獎勵。所以，員工認(rèn)為是這套系統(tǒng)拖累了他。雖然項目對公司有益，對他個人就沒有多少好處了。

　　經(jīng)驗總結(jié)：

　　公司應(yīng)該拿出一部分預(yù)算，有計劃有規(guī)模地組織用戶進行測試，對操作員給出的體驗意見做好詳細(xì)的記錄，并給予充分的重視，對其中有用的軟件改進意見給出相應(yīng)的獎勵。做好足夠的風(fēng)險應(yīng)對計劃，抵御這種影響所帶來的對系統(tǒng)本身的順利實施以及實施人員的信心和工作激情的沖擊。

　　11、缺少數(shù)據(jù)風(fēng)險意識。

　　在系統(tǒng)的并行階段，沒有統(tǒng)一的基礎(chǔ)數(shù)據(jù)，如材料編碼、單據(jù)標(biāo)準(zhǔn)等。數(shù)據(jù)錄入的缺少合理安排，缺少數(shù)據(jù)風(fēng)險意識。

　　用戶總是反映報表數(shù)據(jù)與小票單據(jù)帳目對不上，錄入的小票數(shù)據(jù)丟失了。

　　軟件系統(tǒng)是一個高度集成的系統(tǒng)，一個環(huán)節(jié)的出錯將可能導(dǎo)致一系列的錯誤，所以，對數(shù)據(jù)的準(zhǔn)確性提出了很高的要求。

　　經(jīng)驗總結(jié)：

　　必須制定《公司基礎(chǔ)信息編碼》，搭建了整個信息化制度。在項目實施過程中，針對類似的問題也不能光靠人工對賬減少錯誤，而應(yīng)該采取一定的控制措施，利用系統(tǒng)設(shè)置，做好問題的預(yù)防措施。比如我們可以建立每日審賬制度，在系統(tǒng)中進行設(shè)置，每天錄入完成的票據(jù)都進行核對，核對完成后進行鎖賬。出臺《操作規(guī)程》，《操作員獎懲辦法》等等，規(guī)避風(fēng)險。

　　12、不注重細(xì)節(jié)。

　　天下大事，必做于細(xì)。1%的錯誤往往會導(dǎo)致100%的失敗。力和項目在開發(fā)的時候，僅僅是滿足于“軟件可以使用”或“功能能夠?qū)崿F(xiàn)”的情況，并沒有關(guān)注到每個設(shè)計、每次改動、每天的操作。

　　經(jīng)驗總結(jié)：

　　在此對之前開發(fā)過程中一些可以改進的細(xì)節(jié)列出，進行總結(jié)，在今后的開發(fā)中將進行改進。

　　（1）軟件每一個打開的窗體都應(yīng)該寫上標(biāo)題，而不能是默認(rèn)的標(biāo)題。

　　（2）操作按鈕位置、操作順序必須一目了然。

　�。�3）軟件的功能都加上快捷鍵，使它適應(yīng)不同操作習(xí)慣的用戶。

　�。�4）每一個窗體都加上“關(guān)閉”快捷鍵，當(dāng)用戶需要關(guān)閉窗體時，只需要點“ESC” 鍵就可以退出，方便用戶的操作。

　�。�5）所有輸入文本框都必須按照用戶的業(yè)務(wù)要求進行排列，使用戶可以更快更好地輸入數(shù)據(jù)。

　　（6）進入系統(tǒng)以及退出系統(tǒng)時，如果程序執(zhí)行比較耗時的代碼，應(yīng)該給出個提醒，而不能讓用戶傻等，最好放到線程中處理，不能讓主線程出現(xiàn)假死狀態(tài)。

　　（7）用戶登陸的窗口，應(yīng)該自動幫用戶記住用戶名，用戶可以自己確定是否要記住密碼。

　�。�8）復(fù)雜的查詢條件，錯誤提示之后，原來的輸入是否都還保存？如果都沒有了，用戶要再輸入一遍會很煩。