tom_lt:?
遇到的失敗項目比較多！讓人郁悶！！?
仔細分析原因，主要在于：?
1.項目開始需求不明確。領導決定動手，就開始啟動項目，造成和客戶需要差距太大，導致失敗；?
2.需求變更沒有控制。客戶提出新的需求，或者改變原來的需求，沒有一個好的控制流程，沒有人把關，程序員也可以接受客戶的要求，導致功能越來越復雜，進度和質量嚴重失控，被客戶趕走！?
3.自己太隨意。開發人員自作聰明，認為客戶會需要某個功能，未和客戶協商，就增加了一些額外的功能，導致進度拖延，客戶不滿意。?
4.用戶原因。用戶提出了需求，功能很多，要求你在不可能的時間內完成，我們只能加班加點，最初還能堅持，時間一長，工作效率和精神狀態都低了下來，進度拖延得更多。?
Jinq0123:?
如果說超時是失敗，那我就沒成功過，除了一些一個月之內的超小型項目。?
主要是計劃太雄心勃勃。?
我的一個朋友說計劃應該有點挑戰性。?
但我現在的體會是需要歷史項目的統計數據才能訂出合理的計劃。?
sythree:?
和大家差不多。?
有一個是市場部對客戶承諾太多，需求變更太厲害了。?
還有一個內部轉包的項目比較可惜，開始不太重視，后來技術高層屈服于管理高層，對設計做了較大的更改，沒有驗證，結果出了幾個大的性能錯誤。當是就感到很窩囊，一氣之下換了個部門。?
komantian:?
失敗的定義：用戶拒絕接受?
成功的定義：按時交貨，客戶接受?
我的第一個日本項目，狀態編程可以，不懂日語，程序員身份，當時這個團隊都很厲害，美譽為夢之隊，最后項目重做，投入了5倍于原定計劃的人月數，也就是作了25個人月，項目無法聯合調試，可以運行了，毛病百出，別說客戶，我自己都不想要；事后總結：公司因為其它項目的原因，我們更換了3個項目負責人，導致指揮和仕樣理解都有偏差，公司為了造成沒有更換項目負責人假象，要后來的項目負責人一直使用前任的郵件帳號，造成客戶不知情，對后來人的提出問題很生氣，認為已經講過了，造成溝通效果越來越差；程序員因為語言問題，只能了解自己的問題，不清楚全局的要求，因為項目負責人的更換，內部要重新磨合交流了解，最后每個人都完成了，卻無法聯合調試。公司的負責人應當負責。我作為程序員也因為其它項目原因，在這個項目組3進3出，當然我的責任現在想起來也不好受，我沒有堅持自己的要求，盲目服從上級，在第二次更換項目負責人的時候，我應該挺身而出，但我沒有。?
至少在半年時間里，我的情緒都沒有恢復。?
?
失敗會給你很多經驗，從此我做項目都非常謹慎，反復推演各種情況，避免重蹈覆轍。我對項目中的BAD SMELL現在很敏感，發現一點不對頭，立刻行動起來，堅決的解決它再前進。?
?
值得慶幸的是這是我的目前唯一的一個失敗的項目，我后來做到項目經理，大小也作了7、8個項目，有的也很大，在全國部署的項目，從失敗中我獲益匪淺。?
ntchengl:?
歐當作程序員參與的項目，就算是輸了，關系也不大。?
歐主持的兩個項目，最后都算是成功了，但是都很坎坷。?
這兩個項目是這樣的：?
第一個項目是半道接手的，前任已經做過了需求分析。說實在的，只是去調研過了，需求分析的成果，我基本沒有看到。但是時間倉促，最后扭轉乾坤了。雖然這個項目托了3-4個月，但是責任不在我。第一我不熟悉業務，有個熟悉的過程；第二原先的需求調研不充分，錯誤地估計了工期。說實在的，我只算是延誤了2個月。?
第二個項目是香港的，做了10個月。這個項目算是輸了，但是不算我輸了。項目初期調研的時候，歐去不了香港，去了一個不懂業務的人調研，調的還不如半吊子。我沒看到合同條款，公司就簽合同了。只是從香港的客戶那里看到了合同，而且不是最終合同。這個合同的附件只有兩頁：我們寫的是廣告宣傳上面的牛B話，客戶的要求也是模棱兩可。我真不想做這個項目，可是沒辦法。這個項目我也是重新調研，質量完成得還算可以吧，客戶的要求太高了，我們的合同簽的我啞口無言。最后完成了，原計劃3個月，實際做了10個月。最重要的原因，是市場部不調研就錯誤地認為3個月才能完成。?
這兩個項目都是差在需求分析上面，都不是我做的。說實在的，最終能做出來，還多虧了我呢。?
我做的需求分析，自己主持的項目，都是比較小的，基本沒問題。?
clamp_chen:?
成功和失敗只是簡單的二分法，很多時候都是介于兩者之間的，既不是完全?
的成功也不是完全的失敗。?
影響的因素不單是技術層面的，還有管理層面的，市場層面的。?
說不定一個開發的很差的系統卻賺了不少錢，而一個開發的很好的系統卻?
利潤很薄。哪個項目比較成功呢？?
?
我最近有這樣一個想法，就是軟件系統要引入質量等級的概念，就象傳統?
制造業一樣，有一級品、二級品、三級品等等。?
?
我曾經做過兩個項目，第一個項目的時候經驗不是很足，一開始需求就做?
的很不仔細，也不知道如何控制客戶需求，人手也只有兩個技術人員，但?
是還有一個市場人員支持，不過那時很有熱情，緊趕慢趕了兩個月就交付?
了，然后就是根據客戶需求不斷地調整，調整了大半年才基本穩定了。?
從技術層面評估這個系統很差，無論是可重用性還是易用性都很差，如果?
換個人接手肯定氣死了，我們后來也一直有把它重新架構的考慮，但由于?
種種原因一直沒有實現。?
但是如果換個角度評判，這個項目其實很不錯。?
第一：客戶滿意度很高。（支持的市場人員很會拉關系，而且客戶原來的?
操作確實很煩瑣，我們的系統雖然不太好用，但是還是為他節省了大量的?
時間，另外，我們的響應很及時，經常是一個電話就到現場，直接改掉。?
因此無論是客戶的領導還是實際的操作者都比較滿意，后來還給了我們公?
司一個更大的項目）?
第二：公司利潤很好。（因為只有兩個人，成本很低……而且拉來了后?
面的項目，好處很多）?
?
后來有一個項目，經驗比以前增加了很多，對軟件工程也知道了不少。?
客戶方面也比較嚴謹，有專門的懂技術的用戶代表配合。整個開發團隊?
也很齊整，設計、開發、測試都有，應該說人力還是很充分的。?
任務是將原來的一個系統升級，并附加一些新的功能（原來的系統其實?
很類似于我上面提到的項目，架構很差，在不斷的往里面塞功能以后現?
在再也塞不進去了，因此必須重做）。?
從技術層面上來說這個項目還是完成的不錯，基本上按質按量完成了，?
但是總體上來說做的很辛苦，客戶層面的滿意度也比較一般，因為主要?
是改善了內部架構，對于用戶看到的是只增加了部分擴展功能，而且由?
于架構的差別，原先用戶熟悉的界面和操作習慣難免有改變，雖然我們?
已經充分考慮了這一點，但是不改是不可能的。?
所以，結果如下：?
第一：客戶滿意度一般。（對于領導來說，只是一個系統的升級，增加?
了一些功能而已，對于操作者來說，需要花費時間來重新熟悉新的系統，?
而且由于我們的質量控制比較嚴格，用戶變更都需要討論通過，簽字確?
認，然后再開發，發布新的版本，導致周期比較長。所以給實際操作人?
員的印象是我們還不如原來的開發者：（（（）?
第二：公司利潤很薄。（客戶方的用戶代表比較懂技術，因此對于一些?
細節的地方把關很嚴，而這些地方耗的人力往往比主要功能還要多。而?
整個系統的報價對于升級的功能模塊報的比較低，對于新開發的模塊報?
的稍高一些。但是由于原有系統數據導入等問題，實際上是對原有功能?
模塊的重新開發更花費時間。雖然用戶代表比較了解，但是他也只能幫?
我們說說好話，不可能多發錢給我們。）?
?
做軟件做到這個份上，實在是很郁悶啊?
ezlz:?
一個數據倉庫的項目?
集成方、客戶方、合作伙伴方，?
整個團隊二百多號人呢，?
去年四月份做需求分析，?
三方人員做事都很賣力，?
十月份項目啟動，?
一切步驟都有條不紊的進行著，?
但十二月底項目被宣布無限期終止，?
致使集成方和合作方共有NN多人失業，?
這是一個很很特殊的原因，?
因為客戶高高高層的人事變動，?
這個上幾億的要持續五年的案子就此不了了之了。?
?
有意思嗎？?
w102272:?
我說一個失敗的項目吧，不同的是我們是作為甲方的面目出現的，?
去年10月份該項目啟動，共投資300萬，計劃在3個月完成產品雛形，5個月穩定化，6-7月產品化。我負責技術。?
?
但高層實際投入不足150萬RMB.總經理被迫在各方面嚴格控制成本。在開發部門，我們采用了自己設計，開發外包，不建立大規模團隊的方式來壓縮成本。?
需求和設計都很成功，但不幸的是，外包方是由總經理直接指定的，而總經理本人對技術并不了解多少。?
?
大約出于利益，面子？合作方屏蔽了我們一切對項目監控的努力。拒絕提供開發人員名單，拒絕我們和任何開發人員直接溝通設計和需求。拒絕我們參與程序測試和模塊設計過程。甚至拒絕了我們愿意保持原合同費用不變，由我們這方付費派開發人員參與他們開發過程的請求。只是不斷對我們說，我們一直在努力，靠！！！?
而我們制訂的計劃，需求，設計，進度控制等就在不知不覺中變成了廢紙。?
在開發到1.5月，3個月的時候，我們向公司兩次提議更換合作方，但這個提議和計劃無人理睬。最終隨著時間流逝，無人再有興趣和膽敢提出這樣的建議了。作為開發方的軟件公司固然有自己的困難，但甲方是孫子，乙方變成了爺，這種事情大家沒怎么遇到過吧？呵呵。?
?
在歷時10個月的的漫長談判和拉鋸戰后，對方終于提交了一個很不穩定，bug成批的產品。將原來的3－5個月開發時間拉長到了10個月，并在這個過程中不斷提出追加開發費用的要求，極度延誤的開發周期最終影響了產品第一季度的銷售。?
?
在11個月后，我終于得到了這個產品的源程序，并開始著手組織人重新改寫。按目前的進展看，事實上合理組織下，2.5×3人月足以開發出這個產品來。?
?
項目本身目前還不算失敗，但帶來的潛在損失無疑是極其慘重的。我們失去了市場先機，浪費了大量的精力和時間，沒有得到一個理想中滿意的產品。?
?
最終沒有人是滿意的！！！?
?
市場部門不斷反饋產品的錯誤，并開始在客戶服務方面不斷花費成本?
投資者開始少花錢的得意洋洋，慢慢轉變為更多對經營的參與，控制和不滿?
總經理的經營能力被置疑，并蒙受了資方巨大的壓力（盡管目前情況在好轉）?
外包方在10個月漫長開發中也最終沒有得到他們滿意的開發費用，而且顯而易見，本來3-5個月的開發有很多的贏利，并可以進一步談判分享市場的事情，變成了漫長的開發過程中，耗盡了開發費用，虧損，和開發團隊的分崩離析（據我后期的了解）?
公司負責項目進度，策劃和質量保證的MBA在種種不規范的打擊下辭職而去?
技術部門則在慢慢收拾這個爛攤子，并在承受各方合理不合理的置疑：軟件設計肯定有問題，寫得肯定有問題(事實上是外包方)，開發計劃肯定有問題，管理肯定有問題(事實上老板和總經理直接操縱了整個事情)。若不是為了整個經營團隊的利益（也包含我個人在內）不至于喪失殆盡，以及認為事情還可以補救，恐怕我這里的技術團隊能保留多少還很難說。?
?
高層的無知30% 項目經理的無能50% 程序員20%，需求及詳細分析不夠，缺乏時間和人才等等，我認為均不是導致該項目失敗的關鍵因素。你果真以為高層無知嗎？而作為投資者或管理者而不是專業人員，要求他們事事都象你那樣明白也沒有道理。?
?
失敗的原因是我們不懂軟件工程？個人不夠優秀？計劃和產品不合理？?
利益不均衡，決策不規范，組織和權力架構混亂，各方缺乏足夠的誠信等才是導致問題的根源。?
?
回首這些事情，唯一能作的只是嘆嘆氣而已，作過這么多項目，對這些風險早都不陌生了。只是又想起了英國首相丘吉爾說過一句名言，"沒有永恒的朋友，沒有永恒的敵人，只有永恒的利益"。這不是倫理，而是規律。任何公司的態度和行動，都是從自身利益最大化的角度出發的，而不是從良心、利他、合作、雙贏、誠信角度出發的。?
?
軟件工程？哎，真是無能而脆弱的軟件工程呀。?
或許還有一種可能性，就是軟件產品只是項目總投資的一小部分，大約只占300萬投資的30%左右，換算實際投資150萬RMB的(50萬左右，按最終7個月得到最終產品的周期看，最小開發開支應該是3人*7月*每開發人員平均1萬RMB=21萬)，加上我方和對方的設計成本＋管理成本＋不可預測費用，應該是剛剛好。但開發方錯誤估計了這里的含金量，也不相信未來的合作能帶來更大的收益，因此把所有的精力都用在和我們討價還價，寧愿項目失敗也要拼命先撈一把？?
又或許外包方開發公司只是一個無能之輩或皮包公司，并沒有動用有效的開發力量來開發產品。?
又或許項目背后充滿了我所不了解的暗箱操縱？?
?
這恐怕是我很難再搞明白的事情了。哎...?
ziwuxian:?
一、不能產品化。大多數軟件公司都是小作坊，很難針對某一方面形成強勢產品，只能由客戶擺布，提取需求不專業。上一個項目積累的知識往往很少能用到下一個項目。?
二、一個人擔任太多角色。讓編代碼的做系統分析，做編碼，做測試；讓測試人員編代碼，做系統分析，做測試；讓系統分析員做分析，做市場，做編碼；讓市場人員寫需求等等。即是讓一方面的專家做多方面的工作，而其他方面他是一知半解或者根本不會。?
三、時間問題。估計80％或者更高的項目不能按時完成，在我們公司估計是99.99％不能按時完成，甚至很多是原定的2倍。原因有很多方面。?
四、公司管理太差。沒有形成上下共享資源，溝通的作用。高層毫無計劃地不斷往下扔任務，總經理接到就往項目經理上扔，項目經理往程序員上扔，造成?
下級不斷的接任務，毫無喘氣的時候，很快一棟樓的根基壓斷了，接著后果可想而知。?
五、沒形成規范。過了CMM又如何，只是撐撐門面。項目根本沒按著CMM走。高層說，現在競爭激烈，管不了那么多。軟件工程也只是掛在嘴邊而已。?
....?
實在太多，沒空說了，說了好像起的用處也不大。反正提了意見，領導也不見?
得就聽取，說不定擺你一刀，說我管理不行，不怕我炒了你....#$%#@?
mis98ZB:?
感覺就像是在說我們現在這個項目一樣。?
當然，有一點不同是我這個部分的人員基礎比較差。?
我們這個項目是一個對日軟件外包項目，?
規模比較大，?
就我負責的這一部分的手寫代碼量就達到了87,000行。?
而我負責這個部分不到總體的十分之一。?
就這么大一個項目，?
小日本居然使用瀑布模型進行開發，?
大開形式化的軟件評審會，?
并且充分的向我們展示文檔過度的一切特征……?
?
由于不是構架優先，?
重要的基礎性代碼不能及早的提交給我們，?
我們提交的局部的構架也不受日方的重視；?
而由于工期的要求，?
我們就在空中樓閣中做出一大堆無根草一樣的程序。?
?
直到UT開始，?
早期埋下的火藥開始被接二連三的點著了……?
?
一個月之內，?
我負責這部分的共通函數的仕樣書從1.0版狂飆至2.9版，?
每個0.1的增長都是影響著87,000行代碼的大地震……?
三十多個至關重要的輸入record也是改的天翻地覆……?
而大量的附屬文檔也是瘋狂地修改……?
地獄啊！！！?
?
想想兩個月之前，?
我還在開玩笑說項目失敗的五大特征已經有三個浮現了，我們的項目快要及格了，?
沒想到今天馬上就要成為現實了。?
redguardtoo:?
我也來說說我的經歷，也是給小日本開發的。?
首先樓上的原文引用?
"由于不是構架優先，?
重要的基礎性代碼不能及早的提交給我們，?
我們提交的局部的構架也不受日方的重視；?
而由于工期的要求，?
我們就在空中樓閣中做出一大堆無根草一樣的程序。"?
?
同樣的毛病，我就不多說了。?
不過由于我能力比較強，和我聯系的那個日本人比較弱，而且從一開始的設計都是我做的，所以這還不是個問題。?
?
至于代碼質量，由于我一開始就堅持了人盯人戰術，每個人都要白盒測試，測試要給我review并記錄的原則。所以代碼的質量還是可靠的，也按時完成了編碼。?
?
麻煩的是小日本要我自己把這個庫集成到那個系統中，但是不給我系統的文檔，只有一大堆系統源代碼，而且那堆系統代碼竟然編譯失敗了，而小日本也不清楚為什么失敗，而且也說不準集成在哪里！天哪！?
?
然后是日本人要結婚，我要度一個假期，電話聯系聽不清對方講什么。email聯系也在搗漿糊。?
?
最后日本人在我的反復勸說下裝上了MSN messenger，每天實時遙控我，我去鉆研那堆該死的代碼。總算集成進去了，工作也算完成了。?
?
當日本人通過Msn Messenger告訴我，“xx，我現在才明白communication是很重要的....(因為在開始項目前我給他大講了一通communication的重要，他很不以為然，事實上我當然不是空穴來風）”?
?
我聽著那個小日本的長篇大論，心里明白我在這家公司肯定是呆不長了，我心里想，你是明白了這個道理，但是我可付出了巨大的代價。?
gu_gth:?
:不明確的需求分析，項目經理為了討好客戶，對客戶提出的需求言聽必從，但對這改動將要對哪禧模塊將會產生影響，那系模塊將要發生變動，客戶的需求是否合理不重視，對需求變動的控制太少，力度不夠！客戶的需求是否合理不重視，隨軟件過程中需求的不斷變更，構架越來越脆弱。?
2：分析設計工作的欠缺，不說分析設計的方法，很少有公司對公用函數，專用函數，清晰的函數接口，各模塊，各函數件的調用關系，模塊間的依賴關系做出明確的劃分，對于小的項目，如果程序員還能記得，會從通用函數庫里調用，如果不記得，或程序員是個新人，不辛發生了，他又重寫了另外一個函數，出現了2個副本！?
漫漫的，但代碼重的邏輯錯誤是很難看的，為性能、編碼質量、可維護性打下隱患！?
3：項目的風險，不可否認，每個項目都有一些未使用過的技術，對新技術沒做過原形測試，等到了那個階段是，發生了瓶緊，整個項目都停了，或是先做出一些垃圾，等有經驗后再推倒重干！?
4：管理上的問題，向莫過程中以來程序員間的交流，但程序員間的交流往往造成信息的損失，導致產品質量問題！編碼的風格統一！?
ylg007:?
經歷過兩個項目.?
1、半途接手一個項目，項目已有一年有余，可是卻沒有一份像樣的需求分析，甚至連業務流程圖也不見蹤影。拿著一套不能并不成熟的產品到客戶哪里實施。可想而知在沒有進行調研的情況下，修修補補最終不了了知。經歷的第一個項目失敗告終。經驗：開發模式的項目沒有精確完整正確的需求是沒法完成一個項目的。?
?
?
2、第二個項目已完成。按照上樓的說法，我做為客戶方認為項目是三等品.基本滿足我們的要求。開發方對供應鏈系統有成熟的產品，并對企業做了一次管理思想的培訓，叫業務重組（bpr）吧。開發方不是調研我們在正做什么，而是以老師的身份告訴我們如何管理一個像我們這樣的企業。可想而知開發方對業務的熟悉程度。項目實施過程中程序的問題很少，但是為項目卻是三等品。因我公司高層在開發費用方面的原因，不合理的縮短了項目時間。致使一些模塊沒有得到使用。本應完美的項目卻只能評及格。影響項目品質的原因還有關鍵業務部門的人員素質，公司本身的企業管理現狀。因關鍵業務部門不積極配合，基礎資料的準備就占了項目三分之二的時間。