關於專案失敗經驗的教訓總結大家瞭解過多少呢？可能很多人都不是很清楚，下面就是小編分享的專案失敗經驗教訓總結範文，一起來看一下吧。
專案失敗經驗教訓總結篇一
先介紹下背景，專案型別是集換式卡牌遊戲，平臺是SNS。接手的時候，已經是一個成品了，大約在產品上線一個星期左右venjet作為一名產品策劃加入，負責後續部分系統與數值。
遊戲的核心玩法不錯，作為一個卡牌遊戲在SNS平臺上也不會顯得很重度，所以產品剛上線的時候勢頭很猛，然而經過一段時間之後，日漸滑落的DAU說明產品本身和後續的工作都出現了一些問題。以下幾點是venjet認為今後工作中需要注意的地方。
經驗教訓1.時間-遊戲首日
venjet做過最重度的客戶端，相對輕度的WebGame，然而SNS還是頭一遭。SNS遊戲比起客戶端及WebGame更輕度，進入門檻更低。使用者可以在SNS平臺的幾十幾百個遊戲應用中隨意挑選，幾次點選即可進入一個遊戲，連帳號註冊這個步驟都不需要。同時，因為沒有較高的進入成品，意味著更低的忠誠度。在開始的幾分鐘內，玩家立即就會因為畫風不喜歡，玩過或正在玩同類的遊戲，不喜愛的遊戲型別，不明確的操作等等原因離開遊戲。與花了幾個小時下載的客戶端遊戲相比，SNS教低的推廣成本與次日留存是成正比的。
所以，第一個時間就是遊戲首日了，在有限的幾分鐘內吸引住玩家，將嚐鮮的玩家留住，嘗試過適量的遊戲內容後保持足夠的興趣，次日繼續進入遊戲，這將為接下來的工作打下堅實的使用者數量基礎。前期的努力增加1%的使用者，可能可以為後期帶來10%的使用者增長。這項內容需要在遊戲初期做好，隨著遊戲的運營，使用者的質量會逐漸的下降，此時做這項工作，多少有點事倍功半，這也是教訓之一。
之前遊戲首日內容不足的幾點：
畫面精細度不夠；
使用者體驗細節上需提高；
新手引導略顯生硬，內容過多且說明不足；
新內容的節奏把握不佳；
初期遊戲難度過高，有過高挫折的關卡；
興奮點缺乏引導。
經驗教訓2.時間-遊戲七日
除了純對戰類的網遊，一般而言網遊前期總是會提供玩家一定時間的“單機”遊戲內容（PVE）。這段時間主要的作用是讓玩家熟知遊戲內各個系統與遊戲世界，提升自身實力，為將來的互動內容（PVP）打下基礎。當然，也存在只注重PVE內容的設計，玩家互動的內容只是點綴。通常來說，越輕度的遊戲，PVE的比重越大。我將這部分內容定義為第二個時間：PVE的七日。一旦過了這個時間，這名玩家就轉化成了一名忠實玩家，進而轉化為付費玩家。在這段時間裡，既需要給予玩家新鮮感，興奮點，讓其不斷的進行遊戲；又不能給予玩家太多門檻，打斷玩家的成長。如何取捨，需要結合專案具體的設計來看。
就之前的專案而言，不足的幾點：
內容單調，關卡卡牌佈置缺乏新意，僅僅是難度的提高。
缺乏指導性的成長內容，玩家不知道如何成長。
關卡難度過高，部分關卡挫折感極強。
設計的漏洞導致玩家無法進行遊戲。
經驗教訓3.還是時間-更新時間
以上兩個時間的遊戲內容雖然重要，但是在專案已上線的情況下，如果僅花一些時間做調整，所獲得的成效不會太大。而之前一個最大的教訓，就是沒能把握住第三個時間：更新時間。venjet以往的概念裡，遊戲的內容更新最快也得一個星期吧，往往大版本的更新，那直接奔兩三個月而去啊…但是SNS平臺不同，前面已經說過，SNS平臺的使用者忠誠度相對較低，一旦失去新鮮內容的刺激，單純依靠PVE內容，玩家很快就會流失。因此，SNS一個理想的更新頻率是一週2～3次，哪怕更新的內容再小，也能明顯的看到提升。而這個更新速度，不僅需要整個開發團隊銜接的很緊密，效率很高，就產品策劃本身而言，需要有將設計內容儘量拆分，模組化，並且儘量簡單，易於開發和玩家理解。venjet在這個方面沒能適應這個節奏，給予了開發的同學們很多較大，較難的系統，導致功能開發週期較長，DAU流失嚴重，在這裡向他們說一聲抱歉。這方面的經驗教訓，銘記於心。
經驗教訓4.擺脫玩家心態
一般而言產品策劃本身就是遊戲玩家，也有自己喜愛的遊戲型別甚至鍾情的幾款遊戲。在遊戲設計過程中，玩家心態將是非常可怕的一件事，將自己認為好玩的'，喜歡的系統加入到遊戲中，很可能會與某些遊戲系統，甚至整體遊戲設計衝突。“看起來很美“的系統，往往結果十分慘烈。之前因為較為喜歡某遊戲的好友攻防系統，因此在設計好友互動的時候，引入了這個系統，而忽視了遊戲本身的型別及受眾。所幸及時剎車，不然會給開發的同學們及玩家帶來巨大的麻煩…今後設計每個系統，默唸並回顧設計目的一百遍=。=
經驗教訓5.小額消耗品Vs高價固定資產
之前遊戲上線時，所有的消費內容幾乎只有卡片，高價固定的消費內容帶來的是較高的ARPPU及不那麼高的PR，之後對遊戲的商城進行了一次改造，細分了卡片型別，使玩家購買時更具有目的性，取得了一定的效果。然而在這一個多月的過程中，消費內容讓venjet感覺最佳的調整來自於增加了小額的消耗品（不是我想的…消耗品名字就不透露了…），雖然ARPPU降低了許多，然而PR取得了成倍的增長。玩家從付費0元到付費1元比玩家從付費1元到付費10元的意義要高出很多。這不僅提高了營收，更重要的是使遊戲朝著更健康的方向發展：不依賴少數高付費的使用者，而是有著大量的中小額付費使用者，簡而言之，細水長流。因此，如何合理佈置消費點和消費區間也是遊戲設計的一個重要課題。
另外，消耗品遠比固定資產來的實惠，玩家購買固定資產後，消費的動力將明顯降低，只能通過推出更高性價比或更強的固定資產來拉動消費，這將壓榨遊戲的生命週期，並拉大付費玩家與免費玩家間的差距，這在之前的專案中表現的十分明顯，而消耗品則可以避免這個問題。固定資產不可少，玩家的成長感及沉沒成本主要依賴於它，可以考慮通過分段消費，將消耗品與固定資產的成長結合，比如，裝備強化= =當然，這也是卡牌遊戲的軟肋.
專案失敗經驗教訓總結篇二
一個總成本花費100W的失敗專案的小小反省 這個專案開始到幾個月前基本暫停，總共差不多花費100人月，總成本應該也差不多是100W吧。
在幾個月收穫的產品只有一堆中間程式碼。當然，參與成員對某些技術還是有進步的。我稍微對專案作一些總結吧。要想不好了傷疤忘了疼，需要總結經驗，不管是成功還是失敗的經驗，成功是一個模式，（失敗就是反模式）。
沒有開始的開始,一個噩夢的開始
前期沒有任何固定的嚴格專案可行性分析
老闆指哪兒打哪兒，就算是老闆一種模糊的感覺，下屬只能全力以赴了。這在我們這類企業裡面應該算是很普遍的。當一次回頭看，這100W算是做了一個可行性的探討。風險管理，尤其當你使用一個有新的/先進/陌生的技術，使用一個陌生技術，風險是很多的，不管宣稱它有多先進。
如果在專案初期沒有進行風險的管理探討，最後，這些風險不會憑空消失，一部分會出來，Block你的專案，毀了你前面做的工作，最後毀了你的專案。
需求，沒有遠景，沒有邊界
當專案走了很遠的時候，當需求好像無窮無盡的時候。經驗豐富的領導總算想起要做一個邊界定義了。
如果沒有一個邊界，需求是做不完的，滿天的麻雀，都想要抓，團隊的人力物力是非常有限的，對於一個產品來說，市場也是不會等人的，必須要在規定的時間內出來的軟體，才有可能成為一個成功的軟體。
需求，脫離使用者的需求
當需求只是憑空猜測的需求，自然會讓人覺得無窮盡，因為人類想象力總還是比我們能做到的要多的。但是，這帶來的可能不僅僅是沒有盡頭，脫離使用者的需求，彷彿就是在修煉屠龍絕技。修煉出來是沒有市場的。
需求，隔靴搔癢的需求
如果軟體的終端使用者是經過培訓、積極配合軟體開發過程的，這個軟體的成功機率大概可以提高好幾成。可惜的是，我所看到的很多一部分都不是這樣的。（專案自己尚且對過程沒有什麼控制，談何對使用者代表做出要求呢）。我所見到的是，使用者代表往往彷彿一開始就是等著驗收軟體，不想參與詳細需求的制定，大部分都是靠需求採集人員的猜想，猜想往往和實際有差距，往往只能像擠牙膏那樣從使用者那裡得到一些提示，或者片言隻語的判斷。往往是經過無數次的往返交流，需求還是霧裡看花。需求採集人員在繁瑣中失去耐心，索性天馬行空猜測一番了事，不再去麻煩使用者。
走到一個陌生的行業/領域，需要勇氣和資源
走到一個陌生的行業/領域，有時候是必須的，就像眾多企業的多元化之路。非常不巧的是，也是眾多企業的多元化之路一樣，軟體要想進入一個陌生的行業領域，也是一條艱辛之路。需要的不僅僅是勇氣，還需要機遇，所謂東風是也。但是還需要資源作為支援。如果低估了艱辛程度，可能就低估裡所需的資源。沒有必要的資源，也許你走了90%的路了，你要走不完剩下的路，也許你從沙漠中央走到了離沙漠邊界只有數裡之遙的邊界，沒有了那最後的補給，你還是出不了沙漠。任何風吹草動都可能成為壓垮你的最後稻草。
沒有結束的結束
沒有人會承認失敗，尤其當沒有人要求你這麼多的時候。我們的專案也是，我們幾乎聽不到有人出來說專案失敗了，我們聽到的是延期、暫停、取消等等形容詞，但是其實，我們其實應該承認，我們有做了一個失敗的專案。
過程，沒有過程，沒有積累
從開始到結束，沒有開始的開始到沒有結束的結束，整個過程一切都在我們腦海中，剩下幾個殘缺的需求文件和無法投入使用的中間程式碼。
或許過不了多久，一切的記憶都會從我們腦海消失，尤其像這種失敗的記憶，我們會自然選擇一種選擇性失憶。只不過，我們並沒有得到該有教訓，花了錢，還是沒有買到教訓。如果我們有過程記錄，也許我們可以知道，哪一條路徑是走不通的。我們不需要走一條失敗的老路。
專案的成敗是變數多多，既有技術的，也有管理的，也有關係的，既有自身的，也有客戶的，但是隻要我們把我們可以控制的做好了，至少這個專案成功了一半。
專案的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，儘可能的替使用者考慮，達到功能質量滿足最大化。需求調研前期的《目標與範圍》和需求調研末期的《功能規格說明書》都要跟客戶簽字確認，這樣既能保證我們所理解的需求就是客戶所要的，也使得專案末期跟客戶驗收時有據可依。根據我自己做專案的經驗，由於客戶一般對計算機不是很瞭解，和他們交流用我們行業的話，他們根本就不懂，如果用文件也很難把需求寫的那麼明白，而且文件很多的話，客戶都看煩了，很不直觀。如果讓客戶一看就可以看出這個就是他們想要的，我個人認為最好的方式就是做系統原形。系統原形應該在需求分析的時候開發人員在分析師
的指導下完成真實環境中的開發，當然開發只是介面的功能模擬，沒有底層程式碼的實現。這樣做的目的有三個好處，一是客戶很直觀的看到他們的系統是什麼樣子的以及怎麼操作，二是這些開發的成果是可以二次利用的，三是可以更好的激發客戶的需求。
在專案中期是發生需求變更是很常見的，這時要做好需求變更管理流程。需求變更表，小的變更自己掌握，客戶要求的變更有開發人員和設計人員共同商討後提交專案經理，專案經理預估變更損耗工程時間，在一定階段一起提交給客戶，大的變更直接提交客戶，並且要把需求變更對專案產生的影響讓客戶知道，把球儘可能的踢給客戶，讓客戶在進度、功能、資源三者中取捨出一個平衡來。對需求進行分類評級，關鍵部分不能改動的做特別確認（如系統架構等，如果改變等於從頭再來）。同時完成客戶簽字確認，當然如果能將這部分寫成合同細節中去是最好，但國內的合同好像都是在打單時是基本上都承諾，也不會到細節，在合同簽訂後啟動後才發現問題。但合同中可以寫明如果需求變更什麼級別的怎麼樣，多少錢等;簽訂合同也是一個很高的技巧，建議把系統的邊界及功能範圍和解決方案與合同一起簽署，這樣客戶提出的新功能就可以暫且擱置。當然這就需要專案經理很高的經驗和技巧了，不是光通過學習就能掌握的。
下面我結合我的專案開發經驗說下在專案開發中的失敗原因：
一、需求調研階段我們做的不夠細，調研的時候幾乎是一個單位半天的時間，收集一些報表，根本就沒有了解使用者的需求。
二、對客戶現有系統分析和研究重視不夠，我們開發的系統是客戶已有的系統，他們已經用了多年，在使用的過程中他們已形成了自己的習慣。而且他們的老系統也有他存在的優點，也是在使用的過程中逐步完善的，可是我們在開發過程中完全忽略了老系統的存在。
三、簽訂合同也是非常重要的，具體內容我在上面已說過了。
四、沒有《功能規格說明書》，這個是我們專案中最大的失誤，致使後來客戶的改動讓我們很被動。 《功能規格說明書》反映了客戶提出的所有需求功能，我們也是按照《功能規格說明書》來開發的。後期客戶的變化都可以和《功能規格說明書》對比，具體怎麼變更按照我們的變更流程來做。經驗教訓：《功 能規格說明書》作為產品需求的最終成果必須具有綜合性：必須包括所有的需求。開發者和客戶不能作任 何假設。如果任何所期望的功能或非功能需求未寫入軟體需求規格說明那麼它將不能作為協議的一部分並 且不能在產品中出現。並且注意以下幾點：完整性、正確性、 可行性、必要性、劃分優先順序、無二義性、 可驗證性、一致性、可修改性和可跟蹤性
五、前期專案開發人員投入過少，專案週期越長，對我方越是不利。主要有以下幾點：
1、時間越長，客戶的需求越多，變化也越多，我們的風險就越大。
2、在長週期中往往會有政局的變動，例如客戶領到的變動等。
3、專案週期太長容易造成人員流動的擴大以及工作效率的降低。
經驗教訓：前期多投入人力，儘早完工，降低我方的風險。
六、專案管理人員是專案成敗的關鍵人員，尤其是我們的這樣的公司，對專案經理的要求更高，對這個職位的人員的綜合素質要求非常高。為什麼這麼說呢，首先從我們公司專案經理所做的工作說起，在我們公司中專案經理要承擔專案的前期調研、需求分析、架構設計、質量的保證、計劃的安排執行和跟蹤、掌握行業知識、人員的管理、技術支援、風險的預測以及資料庫的設計等等工作。而在大型軟體公司中這些工作至少是有3年以上本專業經驗的2人來做，一個專案經理和一個軟體架構設計師。一個專案在前期的這些工作就是一個錯誤的話，後面有再強大的開發團隊也是白搭。我們還是一個年輕的團隊，很需要這樣的人才，需要公司來培養，如果遇到專案，再招人員來擔當這樣的工作，風險是可想而知的。
