|
項(xiàng)目又延期了,老板恨恨的批評了整個項(xiàng)目組,投入了那么多,產(chǎn)出在哪里?查原因,發(fā)現(xiàn)是由于項(xiàng)目的需求不斷變更導(dǎo)致,這恐怕是很多項(xiàng)目經(jīng)理、程序員都經(jīng)歷過的事。
我這里就談?wù)勴?xiàng)目延期的一個重要因素:需求問題
這張圖大家再熟悉不過了,我再炒一下冷飯,列一下主要可能的情況:
客戶提出的需求 | 項(xiàng)目組 | 客戶期望的結(jié)果 | 是否滿意 |
需求A | 系統(tǒng)A | 系統(tǒng)A | 是 |
需求A | 系統(tǒng)B | 系統(tǒng)A | 否 |
需求A | 系統(tǒng)A | 系統(tǒng)B | 否 |
客戶為何提不了真正的需求?
1、業(yè)務(wù)部門:業(yè)務(wù)人員基本是站在自身的角度看問題,從自身負(fù)責(zé)的業(yè)務(wù)出發(fā),沒有從本部門或更高層次來分析問題,導(dǎo)致需求的著眼點(diǎn)比較低。在此基礎(chǔ)上形成的最終需求也就是把各部門的需求進(jìn)行匯總,簡單處理罷了。而且,業(yè)務(wù)部門對技術(shù)知識的匱乏,也導(dǎo)致其提出需求時是沒有考慮技術(shù)上方面的。
2、技術(shù)人員:客戶方面的技術(shù)人員由于業(yè)務(wù)知識有限,無法挖掘更深層次的需求,只能是基于已有需求,或者輕度發(fā)掘部分需求,無法從根本上解決需求的問題。
按照以上提出的需求,可想而知,項(xiàng)目的結(jié)局如何。也有部分項(xiàng)目,在需求分析階段,生成了完整的需求規(guī)格說明書,并且用戶簽字畫押,最終的結(jié)果是如果不能真正解決客戶業(yè)務(wù)的問題,即使系統(tǒng)投產(chǎn)了,也必將引來用戶的各種抱怨,勢必對公司形象、后續(xù)項(xiàng)目產(chǎn)生各種不利影響。
我們在整天抱怨需求不斷變化的同時,能否換個角度來看待需求的變化,假設(shè)需求就是變化的,事實(shí)情況也是如此。從企業(yè)及業(yè)務(wù)自身的發(fā)展來看,企業(yè)是不斷發(fā)展的,而業(yè)務(wù)也是不斷發(fā)展的,為了滿足企業(yè)經(jīng)營需要及業(yè)務(wù)發(fā)展需要,需求本身就是應(yīng)該是不斷變化和發(fā)展的。
那么,真正的需求在哪里?
從企業(yè)運(yùn)營角度看,為什么要做系統(tǒng)?其目的都是滿足企業(yè)運(yùn)營的需要,只有站在企業(yè)運(yùn)營的高度來審視需求,才能真正幫助需求發(fā)起人,形成完整的需求。這就需要我們:
1、真正掌握做該系統(tǒng)的目的
2、程序員要深入了解業(yè)務(wù),多溝通,最好有領(lǐng)域?qū)<覅f(xié)助,從上而下梳理業(yè)務(wù)需求,糾正不合理的需求,挖掘潛在的需求
3、以技術(shù)的手段來解決需求變更的問題,做到以不變應(yīng)萬變,從而在最大程度上減少需求變更帶來程序的變化。這方面對程序員、項(xiàng)目設(shè)計(jì)者的要求比較高。
需求變化不可怕、需求變更也不可怕,可怕的是我們不知道變化及變更的本質(zhì),而是停留在表象;可怕的是我們不知道去擁抱這種變化,而是一味的排斥;可怕的是我們不知道用自己的長項(xiàng)(技術(shù)手段)最大化的去解決這種變化,而是把自己的弱項(xiàng)(業(yè)務(wù))暴露在客戶面前。
it知識庫:項(xiàng)目管理雜談-需求無止境,轉(zhuǎn)載需保留來源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請第一時間聯(lián)系我們修改或刪除,多謝。