觀的信息,建立起良好的溝通渠道和方式。第二階段:誘導式。這一階段是在開發(fā)方已經(jīng)了解了具體用戶方的組織架構(gòu)、業(yè)務流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等具體實際、客觀的信息基礎上,結(jié)合現(xiàn)有的硬件、軟件實現(xiàn)方案,做出簡單的用戶流程頁面,同時結(jié)合以往的項目經(jīng)驗對用戶采用誘導式、啟發(fā)式的調(diào)研方法和手段,和用戶一起探討業(yè)務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO,來感受一下整個業(yè)務流程的設計合理性、準確性等問題,及時地提出改進意見和方法。第三階段:確認式。這一階段是在上述兩個階段成果的基礎上,進行具體的流程細化、數(shù)據(jù)確認。這個階段開發(fā)方必須提供原型系統(tǒng)和明確的業(yè)務流程報告、數(shù)據(jù)項表,并能清晰地向用戶描述系統(tǒng)的業(yè)務流設計目標。用戶方可以通過審查業(yè)務流程報告、數(shù)據(jù)項表以及承建方提供的DEMO系統(tǒng),來提出反饋意見,并對已經(jīng)可接受的報告、文檔簽字確認。三個階段或者說三步法的實施和采用,對用戶和承建方都同樣提供了項目成功的保證。
1.4 需求管理的策略
在需求管理上應遵循以下策略: (1)需求一定要與投入有必然的聯(lián)系,否則如果需求變更的成本由開發(fā)方來承擔,則項目需求的變更就成為了必然。在項目的開始無論是開發(fā)方還是出資方都要明確這點:需求發(fā)生變化,軟件開發(fā)的投入也要變。(2)需求的變更要經(jīng)過出資者的認可。需求的變更將引起投入的變化,所以要通過出資者的認可,這樣才會對需求的變更有成本的概念,能夠慎重地對待需求的變更。(3)小的需求變更也要經(jīng)過正規(guī)的需求管理流程。小的需求變更也要經(jīng)過正規(guī)的需求管理流程,否則會積少成多。在實踐中,人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程,認為降低了開發(fā)效率,浪費了時間。正是由于這種觀念才使需求的漸變不可控,最終導致項目的失敗。(4)精確的需求與范圍定義并不會阻止需求的變更。并非對需求定義的越細,越能避免需求的漸變,這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果,因為需求的變化是永恒的,并不會因為需求寫細了,它就不變化了。(5)注意溝通的技巧。實際情況是用戶、開發(fā)者都認識了到了上面的幾點問題,但是由于需求的變更可能來自客戶方、也可能來自開發(fā)方,作為客戶他們可能不愿意為需求的變更付出更多的投資,開發(fā)方有可能是主動的變更了需求,他們的目的可能是使軟件做的更精致,于是作為需求管理者、項目經(jīng)理需要采用各種溝通技巧來使項目的各方各得其所。基于上述的問題,必須對需求進行管理,使需求能夠真正成為軟件工程和管理的基線,使軟件計劃、活動和工作產(chǎn)品同軟件需求保持一致,使需求可以復用。
1.5 監(jiān)理方責任
為了保證項目的成功,作為第三方的監(jiān)理公司也必須加強項目管理和項目分析工作,要提醒開發(fā)方、客戶方重視需求分析的重要性,采用必要的手段和方法來進行需求調(diào)研。在原則上,需求階段監(jiān)理應尊重承建方的項目管理和項目分析能力;在具體的任務開展上,以不深入、不干擾承建方的自主權(quán)為主,除非在項目合作過程中發(fā)現(xiàn)承建方的項目管理以及項目分析能力存在很大的差距和不足;在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。只有這樣才能切切實實地把握用戶的需求和方向,才能在將來的功能界定、開發(fā)范圍上有發(fā)言權(quán)。
2 范圍管理
對于項目中哪些該做,哪些不該做,做到什么程度等問題,都是由范圍管理來決定的。與需求相關的一系列問題,都屬于項目范圍管理的問題。
2.1 產(chǎn)品范圍與項目范圍
項目中花費大量時間和精力用于需求調(diào)研分析,也是為了確定項目范圍。范圍的概念應包含兩個方面,一個是產(chǎn)