先把項目背景簡單說一下，項目A可以認為是在原有業(yè)務系統(tǒng)的基礎(chǔ)上衍生出來的新需求（派生的新業(yè)務），原有業(yè)務系統(tǒng)是一個比較大的系統(tǒng)，在公司也是一個拳頭產(chǎn)品，賣了幾十套，目前也有好幾個人在上面維護+二次開發(fā)+缺陷修復等（人力資源緊張）。早期公司高層只是說肯定要做這個項目，但由于人力資源的問題遲遲沒有決定要開工（還有一個重要原因是領(lǐng)導希望能夠簽下1-2個典型客戶再啟動項目A的開發(fā)），而僅僅是上銷售去那幾十家客戶那里兜售新業(yè)務，吹的天花亂墜的，比較市場有些競爭，需要先拉單子。這些事情是年中的事情。
等到下半年的時候，市場對這個新的業(yè)務反應比較強烈，已經(jīng)有客戶說要看原型再簽合同，原因是競爭對手已經(jīng)出原型了。而此刻，公司以為高層決定要即刻啟動項目開發(fā)，說先把原型做出來，限期一個月。而中層領(lǐng)導還是由于人手緊張，就隨便抽調(diào)了4個開發(fā)人員，一半是1年工作經(jīng)驗以內(nèi)的新手，就這樣匆忙上陣。由于人手有限、時間緊迫、業(yè)務需求雖然已經(jīng)明確，但很多業(yè)務細節(jié)這4個開發(fā)人員都不清楚，只有一個懂業(yè)務的但也談不上精通。
項目計劃就定了一個月，基本上按天把計劃排好了，1個月后系統(tǒng)原型出來了。但比較粗糙，缺陷也比較多，設計基本沒有做，代碼質(zhì)量也比較差。拿去客戶那里安裝后，客戶認為這個系統(tǒng)太粗糙了，【到客戶那里，客戶就不會認為這是個原型系統(tǒng)了】
至此，按常規(guī)項目管理的做法，應該重新梳理真實的客戶需求、業(yè)務流程和功能設計、架構(gòu)設計、概要設計。。。。
但事情的發(fā)展卻不是這樣進行的。由于客戶迫切系統(tǒng)以周為單位看到項目的進展，于是領(lǐng)導決定就在原型系統(tǒng)上擴展和修改，其結(jié)果就是計劃制定后很難執(zhí)行，變成了按周來排計劃，主要就是按客戶的需求來改。
好不容易在年底前把版本基本上穩(wěn)定了，但只是業(yè)務流程和功能比較溫度，缺陷開始收斂了。
但元旦后到客戶現(xiàn)場安裝測試版本，客戶對此版本又提了很多需求變更和新模塊。此刻麻煩就比較大了，因為系統(tǒng)的架構(gòu)靈活性比較差，改起來對原有代碼影響比較大，改動范圍大。于是又是時間緊張，又是工作量，剛把功能實現(xiàn)，客戶就開始催啥時候測試。缺陷一直居高不小，于是決定花2周時間專門修改缺陷。
到現(xiàn)在為止，開發(fā)基本完成了。但問題也比較突出：
系統(tǒng)的性能存在問題（有些模塊客戶的意見很大，但這個從技術(shù)上講，改動會比較大，不是1周能解決的）
系統(tǒng)的穩(wěn)定性（與1相關(guān)）
功能的可用性（有些功能早期按照開發(fā)人員的思維來設計的，到客戶那里客戶提出新的想法，開發(fā)時把這種體驗需求壓住了，但在后續(xù)還是要改）
馬上要啟動二期的需求開發(fā)，這個更麻煩
---------------------
至此，整個項目風險還是比較大的，我總結(jié)有以下幾個原因：
1. 項目的目標、業(yè)務流程、大體需求是很明確的，但細節(jié)需求在項目中前期，整個項目組都是一知半解的，造成后續(xù)返工較大，客戶和開發(fā)人員包括公司領(lǐng)導對質(zhì)量的意見都較大；
2. 項目從開始到現(xiàn)在領(lǐng)導和項目經(jīng)理的分工不明確；由于人是湊起來的，大家之前沒有合作過不了解；
3. 原型系統(tǒng)出來后，項目經(jīng)理大部分時間都去解決客戶的需求溝通和售前支持了，少部分時間在真正項目開發(fā)上；
4. 一直對項目的總體計劃和推進情況估計不足，造成項目計劃形同虛設，完全是開發(fā)人員做到哪算哪；
5. 中前期領(lǐng)導對這個項目不重視，等到元旦后發(fā)現(xiàn)問題比較嚴重，就臨時抽調(diào)人手進來協(xié)助，而剛進來的人一方面不是項目經(jīng)理想要的人（仍然是新手），另外一方面由于系統(tǒng)的業(yè)務性比較強，新手加進來后1-2周內(nèi)根本不起作用；
6. 測試工程師，派過來的2名測試工程師是后期加進來的，業(yè)務都不熟悉，培養(yǎng)的2周后才慢慢熟悉，而且在客戶現(xiàn)場，測試工程師根本應付不了客戶的問題，即客戶講的需求測試工程師根本不懂或不熟悉；
大致就這些吧。