項目管理中,一些問題如何去解決?
問題有如下
1。如何真正的理解客戶的需求
2。需求總是在變化，用戶今天看到你的需求說明書及演示界面認(rèn)為不錯，過了幾天卻提出要加入新需求，再過幾天又加點東西，到最后這個軟件與開始的那個版本相差很大，成了垃圾系統(tǒng)？？
3。每次的需求變更都是口頭描述，沒有形成文檔，即使形成文檔客戶也不愿意在文檔上簽字？
4。由于甲方對軟件不熟悉，所以某些需求并不是他們真正想要的，而公司由于不熟悉客戶的業(yè)務(wù)，所以也無法對此做出正確的理解
5。甲方很多潛在的需求在項目進(jìn)行初期不會提出來，但在中后期會提出來，如何處理？
6。需求說明書得不到及時的更新，導(dǎo)致理解的誤差和工期的延誤
7。需求說明書的具體需求描述不準(zhǔn)確，怎么辦？
8。項目初期公司提出的需求到中后期又作廢，導(dǎo)致大量的無用功，而且需求也不能管理到位，怎么辦？
9。如何有效的標(biāo)識一個需求？
10。用戶總是抱怨需求說明書看不懂，只看演示界面，最后驗收對需求說明書不予認(rèn)同？
11。需求調(diào)研過程中，客戶不配合怎么辦？
12。在什么時候建立需求基線比較合適？
13。需求穩(wěn)定到什么程度可以開始后續(xù)階段的開發(fā)？
14。在關(guān)于需求的溝通中，非面對面溝通導(dǎo)致需求失真，如何做？
15?？蛻魧浖_發(fā)不熟悉，不能提供詳細(xì)需求，怎么辦？
16。需求頻繁的變更，需求管理難度很大。。。
17?？蛻羰怯脩舻纳霞?，用戶對開發(fā)本項目有抵觸情緒，在需求調(diào)研時不提任何需求，項目如何進(jìn)行？
18。迭代式開發(fā)如何來控制需求變更，如何用面向?qū)ο蠓椒▉磉m應(yīng)需求的變更（不要出現(xiàn)因為需求變更導(dǎo)致設(shè)計框架的變更）？
19。怎樣對待需求變化后，項目計劃、成本和產(chǎn)品競爭力、客戶滿意度之間的平衡？
20。軟件項目的需求穩(wěn)定度到底怎樣？
21。對需求進(jìn)行跟蹤管理，管理的粒度到何種程度比較合適？控制到用例就夠了嗎？
22。需求變更來自公司高層，出爾反爾，無所適從？
23。新產(chǎn)品軟件開發(fā)需求獲得更加困難，怎樣在不確定客戶的情況下獲取需求？
24。如何應(yīng)對瑣碎的、細(xì)節(jié)性的（比如不超過1個工作日，但是又頻繁發(fā)生的客戶變更要求）需求變更？
25。需求變更的審批流程很長，影響工期了，怎么辦？
26。用戶管理層角色與操作層角色的角度不同，對同一個功能的需求可能是沖突的，如果照顧了管理角色，這個系統(tǒng)就不適用，如果照顧了操作層，管理人員又可能不在驗收上簽字，怎么辦？
結(jié)果:
1。如何真正的理解客戶的需求?（一個很開放性的問題～：））
a.需要有行業(yè)專家的支持，不然不容易理解客戶的真實需求
b.對需求調(diào)研人員需要很強(qiáng)的溝通、學(xué)習(xí)能力，特別是要會聽，能夠識別各種需求描述中的真實內(nèi)容
c.不斷的確認(rèn)需求記錄
d.要認(rèn)真、準(zhǔn)確、結(jié)構(gòu)化的記錄客戶的需求
e.第一次進(jìn)入一個行業(yè)，沒有行業(yè)知識和背景，做行業(yè)項目的風(fēng)險是很大的，很可能抓不住客戶真正的需求
f.使用圖形化的文檔進(jìn)行和客戶交互，可以增加和客戶的共識
g.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2。需求總是在變化，用戶今天看到你的需求說明書及演示界面認(rèn)為不錯，過了幾天卻提出要加入新需求，再過幾天又加點東西，到最后這個軟件與開始的那個版本相差很大，成了垃圾系統(tǒng)（不知道這么維護(hù)這個系統(tǒng)了～）？？
a.需要建立需求基線，雙方都要簽字認(rèn)可，并尊重這個基線
b.如果做一個新的行業(yè)系統(tǒng)項目，出現(xiàn)這種情況的可能性很大（這叫交學(xué)費～）。
c.在發(fā)生這種情況的時候，應(yīng)該適當(dāng)?shù)囊龑?dǎo)客戶，有專業(yè)軟件公司的判斷，不能說加需求就很快的答應(yīng)下來，即使答應(yīng)下來，也不要輕易承諾實現(xiàn)的時間點，需要認(rèn)真評估后，再答應(yīng)具體的提交時間
d.如果在做需求過程中，需求能穩(wěn)定到80％，發(fā)生以上情形的可能性會下降
e.需求的有效性非常重要：很可能第一次定義需求就已經(jīng)出錯了，要重視第一次需求的定義，講究清晰、準(zhǔn)確、無二義。
f.使用用例加圖片的方式來編寫需求說明書，可以提高需求確認(rèn)的可能性，也會減少這種情況的發(fā)生
g......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
3.每次的需求變更都是口頭描述，沒有形成文檔，即使形成文檔客戶也不愿意在文檔上簽字？
a.這個方面需要由一個正式部門提出,并記錄下來,并且通過一定的上級部門了解需求變更的資料,而不是有變更馬上就去完成.
而是通過一次確認(rèn)的過程.
b.加強(qiáng)需求變更流程管理,提高項目管理人員的水平.
18。迭代式開發(fā)如何來控制需求變更，如何用面向?qū)ο蠓椒▉磉m應(yīng)需求的變更（不要出現(xiàn)因為需求變更導(dǎo)致設(shè)計框架的變更）？
a.要控制軟件架構(gòu)的穩(wěn)定性，軟件架構(gòu)應(yīng)該靈活的適應(yīng)多數(shù)的變更,做這個架構(gòu)要能夠預(yù)見到大多數(shù)的變更
b.首先實現(xiàn)最底層，關(guān)聯(lián)性大的功能和特性，建立基本的穩(wěn)定架構(gòu)
c.面向?qū)ο蟮脑O(shè)計的松耦合，強(qiáng)內(nèi)聚的特性可以降低軟件組件變更的可能性
d.迭代式開發(fā)是應(yīng)對需求變更的一種好的方式，特別是XP開發(fā)方法（擁抱變化）
e.架構(gòu)不穩(wěn)定的情況下，需求變更導(dǎo)致的開發(fā)工作量、測試工作量是很難預(yù)期的
f.有不少穩(wěn)定的軟件架構(gòu)模式（比如：MVC）可以相當(dāng)程度的適應(yīng)需求變更，有效使用設(shè)計模式，可以提高軟件架構(gòu)的穩(wěn)定性，相當(dāng)程度的適應(yīng)軟件需求的變更
g.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
19。怎樣對待需求變化后，項目計劃、成本和產(chǎn)品競爭力、客戶滿意度之間的平衡？
a.可以通過專家估計來評估成本，工期，滿意度之間的關(guān)聯(lián)關(guān)系
b.如果有歷史度量數(shù)據(jù)庫，將更好的量化需求變更和成本、進(jìn)度、工作量之間的關(guān)系
c.不可能100％的答應(yīng)客戶需求變更請求，即使這樣客戶滿意度也不一定高，老板也不答應(yīng) ：）
d.要分析變更的需求會影響哪些角色的利益，平衡各種涉眾之間的沖突，不同方式的應(yīng)對需求的變更，盡可能提高關(guān)鍵客戶的滿意度。
e.軟件實現(xiàn)要適應(yīng)客戶企業(yè)的文化，才可以融入客戶的環(huán)境，也可以提高客戶滿意度
f.在軟件行業(yè)還沒有像建筑行業(yè)那樣為每個需求變更買單的行業(yè)慣例。
g.使用項目管理工具來計算需求變更導(dǎo)致的工期、成本、進(jìn)度的影響
h.對于瑣碎的需求變更，比如界面上的細(xì)微調(diào)整，在開發(fā)過程中需要適當(dāng)?shù)臐M足，否則會影響客戶的配合度和滿意度的
i........
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
20。軟件項目的需求穩(wěn)定度到底怎樣？
a.需求在整個開發(fā)過程中都是在變化的，需求變更肯定會發(fā)生的
b.在開發(fā)初期，需求的穩(wěn)定度大約在60～80％之間
c.客戶在項目過程中也在逐步理解這個系統(tǒng)，所以需求也會演化
d.軟件項目的需求穩(wěn)定度低于傳統(tǒng)建筑工程行業(yè)的需求穩(wěn)定度
e.應(yīng)該和客戶達(dá)成這樣的共識，在需求穩(wěn)定到60～80％的程度，就可以進(jìn)行下一步的開發(fā)工作，后續(xù)的按照變更管理流程來有效的管理變更。
f.在需求開發(fā)過程中，用完美主義的方式做是不行的，至少在中國多數(shù)的軟件企業(yè)的項目開發(fā)（非產(chǎn)品開發(fā)）中是這樣的
g.軟件需求中的不同內(nèi)容，變化頻率是不同的，業(yè)務(wù)模型是最穩(wěn)定的，業(yè)務(wù)流程相對穩(wěn)定，業(yè)務(wù)表現(xiàn)（報表。。）是最容易變化的。
h.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
21。對需求進(jìn)行跟蹤管理，管理的粒度（單位）到何種程度比較合適？控制到用例就夠了嗎？
a.不要把需求的非常細(xì)節(jié)的內(nèi)容作為需求項來管理，否則工作量非常大
b.對于細(xì)節(jié)的需求（比如界面上的按鈕表現(xiàn)）可以用圖形方式來表現(xiàn)。
c.如果用例分解的粒度適當(dāng)，可以把用例作為需求項進(jìn)行管理。
d......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
25。需求變更的審批流程很長(比如一個月)，導(dǎo)致了工期的風(fēng)險，怎么辦？
a.如果對于大的項目，其中的變更審批流程長是很正常的，比如銀行系統(tǒng)。應(yīng)該適應(yīng)客戶的工作方式
b.如果有行業(yè)專家，可以很大程度的規(guī)避這種變更，沒有行業(yè)專家，需求變更就會比較頻繁，花在變更審批上的時間會很多。
c.在合同階段建立約定，在一定程度上加快客戶的變更審批流程
d.變更一定要在審批通過后才可以進(jìn)行，否則就很可能返工
e.......
2005年11月14日 10:51
