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