項目管理中,一些問題如何去解決??

問題有如下?
1。如何真正的理解客戶的需求?
2。需求總是在變化，用戶今天看到你的需求說明書及演示界面認為不錯，過了幾天卻提出要加入新需求，再過幾天又加點東西，到最后這個軟件與開始的那個版本相差很大，成了垃圾系統？？?
3。每次的需求變更都是口頭描述，沒有形成文檔，即使形成文檔客戶也不愿意在文檔上簽字？?
4。由于甲方對軟件不熟悉，所以某些需求并不是他們真正想要的，而公司由于不熟悉客戶的業務，所以也無法對此做出正確的理解?
5。甲方很多潛在的需求在項目進行初期不會提出來，但在中后期會提出來，如何處理？?
6。需求說明書得不到及時的更新，導致理解的誤差和工期的延誤?
7。需求說明書的具體需求描述不準確，怎么辦？?
8。項目初期公司提出的需求到中后期又作廢，導致大量的無用功，而且需求也不能管理到位，怎么辦？?
9。如何有效的標識一個需求？?
10。用戶總是抱怨需求說明書看不懂，只看演示界面，最后驗收對需求說明書不予認同？?
11。需求調研過程中，客戶不配合怎么辦？?
12。在什么時候建立需求基線比較合適？?
13。需求穩定到什么程度可以開始后續階段的開發？?
14。在關于需求的溝通中，非面對面溝通導致需求失真，如何做？?
15。客戶對軟件開發不熟悉，不能提供詳細需求，怎么辦？?
16。需求頻繁的變更，需求管理難度很大。。。?
17。客戶是用戶的上級，用戶對開發本項目有抵觸情緒，在需求調研時不提任何需求，項目如何進行？?
18。迭代式開發如何來控制需求變更，如何用面向對象方法來適應需求的變更（不要出現因為需求變更導致設計框架的變更）？?
19。怎樣對待需求變化后，項目計劃、成本和產品競爭力、客戶滿意度之間的平衡？?
20。軟件項目的需求穩定度到底怎樣？?
21。對需求進行跟蹤管理，管理的粒度到何種程度比較合適？控制到用例就夠了嗎？?
22。需求變更來自公司高層，出爾反爾，無所適從？?
23。新產品軟件開發需求獲得更加困難，怎樣在不確定客戶的情況下獲取需求？?
24。如何應對瑣碎的、細節性的（比如不超過1個工作日，但是又頻繁發生的客戶變更要求）需求變更？?
25。需求變更的審批流程很長，影響工期了，怎么辦？?
26。用戶管理層角色與操作層角色的角度不同，對同一個功能的需求可能是沖突的，如果照顧了管理角色，這個系統就不適用，如果照顧了操作層，管理人員又可能不在驗收上簽字，怎么辦？?


結果:?

1。如何真正的理解客戶的需求?（一個很開放性的問題～：））?
a.需要有行業專家的支持，不然不容易理解客戶的真實需求?
b.對需求調研人員需要很強的溝通、學習能力，特別是要會聽，能夠識別各種需求描述中的真實內容?
c.不斷的確認需求記錄?
d.要認真、準確、結構化的記錄客戶的需求?
e.第一次進入一個行業，沒有行業知識和背景，做行業項目的風險是很大的，很可能抓不住客戶真正的需求?
f.使用圖形化的文檔進行和客戶交互，可以增加和客戶的共識?
g.......?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－?

2。需求總是在變化，用戶今天看到你的需求說明書及演示界面認為不錯，過了幾天卻提出要加入新需求，再過幾天又加點東西，到最后這個軟件與開始的那個版本相差很大，成了垃圾系統（不知道這么維護這個系統了～）？？?
a.需要建立需求基線，雙方都要簽字認可，并尊重這個基線?
b.如果做一個新的行業系統項目，出現這種情況的可能性很大（這叫交學費～）。?
c.在發生這種情況的時候，應該適當的引導客戶，有專業軟件公司的判斷，不能說加需求就很快的答應下來，即使答應下來，也不要輕易承諾實現的時間點，需要認真評估后，再答應具體的提交時間?
d.如果在做需求過程中，需求能穩定到80％，發生以上情形的可能性會下降?
e.需求的有效性非常重要：很可能第一次定義需求就已經出錯了，要重視第一次需求的定義，講究清晰、準確、無二義。?
f.使用用例加圖片的方式來編寫需求說明書，可以提高需求確認的可能性，也會減少這種情況的發生?
g......?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

3.每次的需求變更都是口頭描述，沒有形成文檔，即使形成文檔客戶也不愿意在文檔上簽字？?
a.這個方面需要由一個正式部門提出,并記錄下來,并且通過一定的上級部門了解需求變更的資料,而不是有變更馬上就去完成.?
?? 而是通過一次確認的過程.?
b.加強需求變更流程管理,提高項目管理人員的水平.?

18。迭代式開發如何來控制需求變更，如何用面向對象方法來適應需求的變更（不要出現因為需求變更導致設計框架的變更）？?
a.要控制軟件架構的穩定性，軟件架構應該靈活的適應多數的變更,做這個架構要能夠預見到大多數的變更?
b.首先實現最底層，關聯性大的功能和特性，建立基本的穩定架構?
c.面向對象的設計的松耦合，強內聚的特性可以降低軟件組件變更的可能性?
d.迭代式開發是應對需求變更的一種好的方式，特別是XP開發方法（擁抱變化）?
e.架構不穩定的情況下，需求變更導致的開發工作量、測試工作量是很難預期的?
f.有不少穩定的軟件架構模式（比如：MVC）可以相當程度的適應需求變更，有效使用設計模式，可以提高軟件架構的穩定性，相當程度的適應軟件需求的變更?
g.......?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

19。怎樣對待需求變化后，項目計劃、成本和產品競爭力、客戶滿意度之間的平衡？?
a.可以通過專家估計來評估成本，工期，滿意度之間的關聯關系?
b.如果有歷史度量數據庫，將更好的量化需求變更和成本、進度、工作量之間的關系?
c.不可能100％的答應客戶需求變更請求，即使這樣客戶滿意度也不一定高，老板也不答應 ：）?
d.要分析變更的需求會影響哪些角色的利益，平衡各種涉眾之間的沖突，不同方式的應對需求的變更，盡可能提高關鍵客戶的滿意度。?
e.軟件實現要適應客戶企業的文化，才可以融入客戶的環境，也可以提高客戶滿意度?
f.在軟件行業還沒有像建筑行業那樣為每個需求變更買單的行業慣例。?
g.使用項目管理工具來計算需求變更導致的工期、成本、進度的影響?
h.對于瑣碎的需求變更，比如界面上的細微調整，在開發過程中需要適當的滿足，否則會影響客戶的配合度和滿意度的?
i........?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

20。軟件項目的需求穩定度到底怎樣？?
a.需求在整個開發過程中都是在變化的，需求變更肯定會發生的?
b.在開發初期，需求的穩定度大約在60～80％之間?
c.客戶在項目過程中也在逐步理解這個系統，所以需求也會演化?
d.軟件項目的需求穩定度低于傳統建筑工程行業的需求穩定度?
e.應該和客戶達成這樣的共識，在需求穩定到60～80％的程度，就可以進行下一步的開發工作，后續的按照變更管理流程來有效的管理變更。?
f.在需求開發過程中，用完美主義的方式做是不行的，至少在中國多數的軟件企業的項目開發（非產品開發）中是這樣的?
g.軟件需求中的不同內容，變化頻率是不同的，業務模型是最穩定的，業務流程相對穩定，業務表現（報表。。）是最容易變化的。?
h.......?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

21。對需求進行跟蹤管理，管理的粒度（單位）到何種程度比較合適？控制到用例就夠了嗎？?
a.不要把需求的非常細節的內容作為需求項來管理，否則工作量非常大?
b.對于細節的需求（比如界面上的按鈕表現）可以用圖形方式來表現。?
c.如果用例分解的粒度適當，可以把用例作為需求項進行管理。?
d......?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

25。需求變更的審批流程很長(比如一個月)，導致了工期的風險，怎么辦？?
a.如果對于大的項目，其中的變更審批流程長是很正常的，比如銀行系統。應該適應客戶的工作方式?
b.如果有行業專家，可以很大程度的規避這種變更，沒有行業專家，需求變更就會比較頻繁，花在變更審批上的時間會很多。?
c.在合同階段建立約定，在一定程度上加快客戶的變更審批流程?
d.變更一定要在審批通過后才可以進行，否則就很可能返工?
e.......?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

分類:?項目有關
本文轉自左正博客園博客，原文鏈接：http://www.cnblogs.com/soundcode/archive/2011/06/02/2069989.html，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的项目管理中可能有的问题,以及如何去面对!的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。