2020国产成人精品视频,性做久久久久久久久,亚洲国产成人久久综合一区,亚洲影院天堂中文av色

分享

項目管理中的問題及對策!

 悟靜 2011-06-22

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

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


結(jié)果:

1。如何真正的理解客戶的需求?(一個很開放性的問題~:))
a.需要有行業(yè)專家的支持,不然不容易理解客戶的真實需求
b.對需求調(diào)研人員需要很強的溝通、學(xué)習(xí)能力,特別是要會聽,能夠識別各種需求描述中的真實內(nèi)容
c.不斷的確認需求記錄
d.要認真、準確、結(jié)構(gòu)化的記錄客戶的需求
e.第一次進入一個行業(yè),沒有行業(yè)知識和背景,做行業(yè)項目的風(fēng)險是很大的,很可能抓不住客戶真正的需求
f.使用圖形化的文檔進行和客戶交互,可以增加和客戶的共識
g.......
-------------------------------------

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


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

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è)計的松耦合,強內(nèi)聚的特性可以降低軟件組件變更的可能性
d.迭代式開發(fā)是應(yīng)對需求變更的一種好的方式,特別是XP開發(fā)方法(擁抱變化)
e.架構(gòu)不穩(wěn)定的情況下,需求變更導(dǎo)致的開發(fā)工作量、測試工作量是很難預(yù)期的
f.有不少穩(wěn)定的軟件架構(gòu)模式(比如:MVC)可以相當程度的適應(yīng)需求變更,有效使用設(shè)計模式,可以提高軟件架構(gòu)的穩(wěn)定性,相當程度的適應(yīng)軟件需求的變更
g.......
-------------------------------------


19。怎樣對待需求變化后,項目計劃、成本和產(chǎn)品競爭力、客戶滿意度之間的平衡?
a.可以通過專家估計來評估成本,工期,滿意度之間的關(guān)聯(lián)關(guān)系
b.如果有歷史度量數(shù)據(jù)庫,將更好的量化需求變更和成本、進度、工作量之間的關(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)致的工期、成本、進度的影響
h.對于瑣碎的需求變更,比如界面上的細微調(diào)整,在開發(fā)過程中需要適當?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)該和客戶達成這樣的共識,在需求穩(wěn)定到60~80%的程度,就可以進行下一步的開發(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。對需求進行跟蹤管理,管理的粒度(單位)到何種程度比較合適?控制到用例就夠了嗎?
a.不要把需求的非常細節(jié)的內(nèi)容作為需求項來管理,否則工作量非常大
b.對于細節(jié)的需求(比如界面上的按鈕表現(xiàn))可以用圖形方式來表現(xiàn)。
c.如果用例分解的粒度適當,可以把用例作為需求項進行管理。
d......
-------------------------------------


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

2005年11月14日 10:51

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多