房地產(chǎn)項目管理軟件
當前位置：工程項目OA系統(tǒng) > 房地產(chǎn)OA系統(tǒng) > 相關系統(tǒng) > 房地產(chǎn)項目管理軟件
工程項目中需求獲取方法
在工程項目的建設過程中，我們通常感覺到最頭疼的就是項目需求的獲取，我們往往花費相當大的精力在需求獲取和需求確認上，然而效果還很不理想。經(jīng)過幾年項目實踐和鍛煉，逐步總結出針對不同項目情況所適合采用的需求獲取方法，這些方法能大大提高需求獲取的效率。希望與大家分享。
我們知道，一個項目，如果從建設方和使用方對需求的清楚程度來分，大致可以分為如下四種：建設方和使用方都清楚項目需求；建設方不清楚項目需求但使用方清楚；建設方和使用方都不清楚項目需求；建設方清楚項目需求但使用方不清楚。我們目前建設的項目基本都囊括了以上四種情況，但是我們項目大多數(shù)情況是使用方和建設方都是同一用戶，目前的項目建設中也出現(xiàn)了中國聯(lián)通的其他部門提相關需求，由網(wǎng)管中心來建設。
針對這四種類型的項目，總結出四種對應的需求獲取方法：問卷調(diào)查法、會議討論法、界面原型法和demo版系統(tǒng)法。
一、問卷調(diào)查法
所謂“問卷調(diào)查法”，是指我們方就用戶需求中的一些個性化的、需要進一步明確的需求（或問題），通過采用向用戶發(fā)問卷調(diào)查表的方式，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于我們和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進一步溝通的需求（或問題）就比較少，通過采用這種簡單的問卷調(diào)查方法就能使問題得到較好的解決。
這種方法的一般操作步驟是：
1. 我們先根據(jù)合同和以往類似項目的經(jīng)驗，整理出一份《用戶需求說明書》和相關業(yè)務層面的《問卷調(diào)查表》提交給用戶；
2. 用戶閱讀《用戶需求說明書》，并回答《問卷調(diào)查表》中提出的問題，如果《用戶需求說明書》中有描述不正確或未包括的需求，用戶可一并修改或補充；
3. 我們拿到用戶返回的《用戶需求說明書》和《問卷調(diào)查表》進行分析，如仍然有問題，則重復步驟2，否則執(zhí)行步驟4；
4. 經(jīng)過我方和承建方、使用方反復交流溝通，最后整理出《用戶需求說明書》，提交給用戶（此處的用戶可以是建設方、也可以是使用方）確認簽字。
由于這種方法比較簡單、側重點明確，因此能大大縮短需求獲取的時間、減少需求獲取的成本、提高工作效率。
二、會議討論法
所謂“會議討論法”，是指我方和用戶相關人員（包括建設方和使用方）方召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于我方不清楚用戶的詳細業(yè)務需求，但使用方清楚項目需求的情況（比如重慶的網(wǎng)優(yōu)項目）。因為使用方清楚項目的需求，他們能準確地表達出他們的需求，而我們有專業(yè)的軟件開發(fā)經(jīng)驗，經(jīng)過會議討論交流之后，能夠對用戶的需求進行準確描述和把握。
這種方法的一般操作步驟是：
1. 我方先制定《需求調(diào)研計劃》，然后和建設方以及使用方交流《需求調(diào)研計劃》，最后根據(jù)需求調(diào)研計劃召開相關需求主題溝通會；
2. 會后我方整理出《需求調(diào)研記錄》提交給用戶確認；
3. 如果此主題還有未明確的問題則再次溝通，否則開始下一主題；
4. 所有需求都溝通清楚后，我方根據(jù)歷次《需求調(diào)研記錄》整理出《用戶需求說明書》，提交給使用方確認簽字。
由于我方不清楚項目明確業(yè)務流程和相關需求，因此需要花較多的時間和精力進行需求調(diào)研和需求整理工作。
三、界面原型法
所謂“界面原型法”，是指我方根據(jù)自己所了解的用戶需求，描畫出應用系統(tǒng)的功能界面后與用戶進行交流和溝通，通過“界面原型”這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。
這種方法比較適合于我方和用戶都不是非常清楚項目需求、只是大概了解用戶需求的情況。因為我方和用戶方都不能非常準確的描述出客戶的需求，因此此時就更需要借助于一定的“載體”來加快對需求的挖掘和雙方對需求理解。這種情況下，采用“可視化”的界面原型法比較可取。
這種方法的一般操作步驟是：
1. 我方根據(jù)其所了解到的需求（如通過合同或與用戶交流），采用界面制作工作描畫出應用系統(tǒng)的功能界面；
2. 將應用系統(tǒng)的功能界面提交給用戶并與用戶溝通，挖掘出新需求或就需求達成理解上的一致；
3. 我方就不斷獲取的需求進行增量式整理，根據(jù)新的需求豐富和細化界面原型；
4. 雙方經(jīng)過多次界面原型的交互，建設方最終整理出《用戶需求說明書》，提交給使用方確認簽字。
由于我方和用戶都不清楚項目需求，因此此時需求獲取工作將會比較困難，可能導致的風險也比較大。采用這種“界面原型”的方式，能加速項目需求的“浮現(xiàn)”和雙方對需求的一致理解，從而減小由于需求問題可能給項目帶來的風險。
四、demo版系統(tǒng)法
所謂“demo版系統(tǒng)法”，是指我方根據(jù)合同中規(guī)定的基本需求，在以往類似項目應用系統(tǒng)的基礎上進行少量修改得出一可運行系統(tǒng)，通過“可運行原型系統(tǒng)”這一載體，達到徹底挖掘項目需求的一種需求獲取的方法。
這種方法比較適合于我方清楚項目需求但用戶不清楚項目需求的情況。這種類型的項目，我方一般都有類似項目的建設經(jīng)驗，因此可以在以往項目的基礎上，快速“構建”出一可運行系統(tǒng)，然后借助于這一“載體”來加快對需求的挖掘和雙方（特別是使用方）對需求的理解。這種情況下，采用demo版運行系統(tǒng)法比較可取。
這種方法的一般操作步驟是：
1. 我方根據(jù)其所了解到的需求（如通過合同或與用戶交流），在以往類似項目的基礎上，快速“構建”出一可運行系統(tǒng)；
2. 通過向用戶演示“可運行原型系統(tǒng)”，逐步挖掘并讓用戶確認項目需求；
3. 我方就不斷獲取的需求進行增量式整理，根據(jù)新的需求豐富可運行原型系統(tǒng)；
4. 雙方經(jīng)過多次可運行原型系統(tǒng)的交互，我方最終整理出《用戶需求說明書》，提交給用戶確認簽字。
由于我方清楚用戶的需求（以前有類似項目的開發(fā)經(jīng)驗和產(chǎn)品積累），但用戶自己描述不清楚，因此此時開發(fā)一個“deom系統(tǒng)”，我方的投入不會很大，但對于用戶理解和確認項目需求非常有利，因此針對這種類型的項目這是一種比較理想的需求獲取方式。
這種方法的另一個好處是：正式系統(tǒng)一般可以在該“可運行原型系統(tǒng)”的基礎上演化而成，為后續(xù)開發(fā)工作節(jié)省不少的工作量和成本。
值得注意的是，以上總結出的這四種需求獲取方法不是互斥的，我們可以根據(jù)項目的實際特點獨立應用或組合應用。
以上是我在以往的項目實施中總結的，希望我的方法能夠給我們的需求調(diào)研人員有一個良好的指引。有良好的方法，相信我們的項目開展達到了“事半功倍”的作用。
我們知道，一個項目，如果從建設方和使用方對需求的清楚程度來分，大致可以分為如下四種：建設方和使用方都清楚項目需求；建設方不清楚項目需求但使用方清楚；建設方和使用方都不清楚項目需求；建設方清楚項目需求但使用方不清楚。我們目前建設的項目基本都囊括了以上四種情況，但是我們項目大多數(shù)情況是使用方和建設方都是同一用戶，目前的項目建設中也出現(xiàn)了中國聯(lián)通的其他部門提相關需求，由網(wǎng)管中心來建設。
針對這四種類型的項目，總結出四種對應的需求獲取方法：問卷調(diào)查法、會議討論法、界面原型法和demo版系統(tǒng)法。
一、問卷調(diào)查法
所謂“問卷調(diào)查法”，是指我們方就用戶需求中的一些個性化的、需要進一步明確的需求（或問題），通過采用向用戶發(fā)問卷調(diào)查表的方式，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于我們和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進一步溝通的需求（或問題）就比較少，通過采用這種簡單的問卷調(diào)查方法就能使問題得到較好的解決。
這種方法的一般操作步驟是：
1. 我們先根據(jù)合同和以往類似項目的經(jīng)驗，整理出一份《用戶需求說明書》和相關業(yè)務層面的《問卷調(diào)查表》提交給用戶；
2. 用戶閱讀《用戶需求說明書》，并回答《問卷調(diào)查表》中提出的問題，如果《用戶需求說明書》中有描述不正確或未包括的需求，用戶可一并修改或補充；
3. 我們拿到用戶返回的《用戶需求說明書》和《問卷調(diào)查表》進行分析，如仍然有問題，則重復步驟2，否則執(zhí)行步驟4；
4. 經(jīng)過我方和承建方、使用方反復交流溝通，最后整理出《用戶需求說明書》，提交給用戶（此處的用戶可以是建設方、也可以是使用方）確認簽字。
由于這種方法比較簡單、側重點明確，因此能大大縮短需求獲取的時間、減少需求獲取的成本、提高工作效率。
二、會議討論法
所謂“會議討論法”，是指我方和用戶相關人員（包括建設方和使用方）方召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于我方不清楚用戶的詳細業(yè)務需求，但使用方清楚項目需求的情況（比如重慶的網(wǎng)優(yōu)項目）。因為使用方清楚項目的需求，他們能準確地表達出他們的需求，而我們有專業(yè)的軟件開發(fā)經(jīng)驗，經(jīng)過會議討論交流之后，能夠對用戶的需求進行準確描述和把握。
這種方法的一般操作步驟是：
1. 我方先制定《需求調(diào)研計劃》，然后和建設方以及使用方交流《需求調(diào)研計劃》，最后根據(jù)需求調(diào)研計劃召開相關需求主題溝通會；
2. 會后我方整理出《需求調(diào)研記錄》提交給用戶確認；
3. 如果此主題還有未明確的問題則再次溝通，否則開始下一主題；
4. 所有需求都溝通清楚后，我方根據(jù)歷次《需求調(diào)研記錄》整理出《用戶需求說明書》，提交給使用方確認簽字。
由于我方不清楚項目明確業(yè)務流程和相關需求，因此需要花較多的時間和精力進行需求調(diào)研和需求整理工作。
三、界面原型法
所謂“界面原型法”，是指我方根據(jù)自己所了解的用戶需求，描畫出應用系統(tǒng)的功能界面后與用戶進行交流和溝通，通過“界面原型”這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。
這種方法比較適合于我方和用戶都不是非常清楚項目需求、只是大概了解用戶需求的情況。因為我方和用戶方都不能非常準確的描述出客戶的需求，因此此時就更需要借助于一定的“載體”來加快對需求的挖掘和雙方對需求理解。這種情況下，采用“可視化”的界面原型法比較可取。
這種方法的一般操作步驟是：
1. 我方根據(jù)其所了解到的需求（如通過合同或與用戶交流），采用界面制作工作描畫出應用系統(tǒng)的功能界面；
2. 將應用系統(tǒng)的功能界面提交給用戶并與用戶溝通，挖掘出新需求或就需求達成理解上的一致；
3. 我方就不斷獲取的需求進行增量式整理，根據(jù)新的需求豐富和細化界面原型；
4. 雙方經(jīng)過多次界面原型的交互，建設方最終整理出《用戶需求說明書》，提交給使用方確認簽字。
由于我方和用戶都不清楚項目需求，因此此時需求獲取工作將會比較困難，可能導致的風險也比較大。采用這種“界面原型”的方式，能加速項目需求的“浮現(xiàn)”和雙方對需求的一致理解，從而減小由于需求問題可能給項目帶來的風險。
四、demo版系統(tǒng)法
所謂“demo版系統(tǒng)法”，是指我方根據(jù)合同中規(guī)定的基本需求，在以往類似項目應用系統(tǒng)的基礎上進行少量修改得出一可運行系統(tǒng)，通過“可運行原型系統(tǒng)”這一載體，達到徹底挖掘項目需求的一種需求獲取的方法。
這種方法比較適合于我方清楚項目需求但用戶不清楚項目需求的情況。這種類型的項目，我方一般都有類似項目的建設經(jīng)驗，因此可以在以往項目的基礎上，快速“構建”出一可運行系統(tǒng)，然后借助于這一“載體”來加快對需求的挖掘和雙方（特別是使用方）對需求的理解。這種情況下，采用demo版運行系統(tǒng)法比較可取。
這種方法的一般操作步驟是：
1. 我方根據(jù)其所了解到的需求（如通過合同或與用戶交流），在以往類似項目的基礎上，快速“構建”出一可運行系統(tǒng)；
2. 通過向用戶演示“可運行原型系統(tǒng)”，逐步挖掘并讓用戶確認項目需求；
3. 我方就不斷獲取的需求進行增量式整理，根據(jù)新的需求豐富可運行原型系統(tǒng)；
4. 雙方經(jīng)過多次可運行原型系統(tǒng)的交互，我方最終整理出《用戶需求說明書》，提交給用戶確認簽字。
由于我方清楚用戶的需求（以前有類似項目的開發(fā)經(jīng)驗和產(chǎn)品積累），但用戶自己描述不清楚，因此此時開發(fā)一個“deom系統(tǒng)”，我方的投入不會很大，但對于用戶理解和確認項目需求非常有利，因此針對這種類型的項目這是一種比較理想的需求獲取方式。
這種方法的另一個好處是：正式系統(tǒng)一般可以在該“可運行原型系統(tǒng)”的基礎上演化而成，為后續(xù)開發(fā)工作節(jié)省不少的工作量和成本。
值得注意的是，以上總結出的這四種需求獲取方法不是互斥的，我們可以根據(jù)項目的實際特點獨立應用或組合應用。
以上是我在以往的項目實施中總結的，希望我的方法能夠給我們的需求調(diào)研人員有一個良好的指引。有良好的方法，相信我們的項目開展達到了“事半功倍”的作用。