需求分析中的用戶識別與調查

需求來自于用戶，不論是用什么方法，首先應是找到我們需要訪問的對象，然后對對象進行分類，再逐步對對象進行訪問。具體訪問過程中可以針對不同的訪問對象采用不同的方法，根據訪問的內容進行確定。本文要討論的是，如何確定我們的訪問對象，以及如何對確定用戶對象進行調查。

    討論的前提條件是針對用戶的需要進行的系統開發，或針對用戶的需要進行的定置，而不是僅僅將我們已經成型的產品推銷給用戶。

    這樣就會面臨兩種情況，一種是我們可能對這個系統有一定的背景，有一定的開發經驗，有不少相關的成功案例，但面對的用戶實際上卻是一個全新的用戶，該用戶的要求可能是全新，僅管從管理上講，該系統的管理實質是一致的，但卻許多細微的區別，讓我們不能照搬以前的需求與設計，這就要求我們重新訪問用戶；第二種情況是我們根本對所需開發的系統的行業知識一點也不了解，需要從頭認識與理解。無論是哪種情況，我們都要按照以下步驟來慢慢的完成我們的用戶需求分析工作。

    第一步是找出系統的未來推進者。通過與用戶開發任務的提出者進行初步確認，由用戶任務提出者指出我們所要開發的系統的最直接用戶，或者說是系統的職能管理者，該用戶也是未來的系統推進者。只有得到該用戶的認可，未來的系統的推行，才能得到他的積極支持與推進。

    第二步是把握系統的整體流程。通過對系統的推進者的訪問，我們將能知道他的前面用戶將向他提供什么信息，并完成哪些處理，信息到了他這里之后，他要做哪些處理，還要提交給另外哪些用戶進行處理或訪問，他所處理的這些內容，目的是什么，在管理中起什么作用，應該產生什么的管理績效，有哪些量化的東西加以評價。通過這些問題的確認，我們會基本上形成系統的總體認識，整個系統經過了多少步驟，每個步驟都由誰來完成，應做哪些操作，形成哪些報表，通過整理，形成初步的系統模型。

    第三步找出真正的用戶。這里所講的真正用戶也要分開談，一種是指系統的直接用戶，另一種指系統的最終用戶，即服務對象。我們這里首先要找直接用戶，通過直接用戶找到最終用戶。需要注意的是，因為所站的角度不一樣，可能最終的用戶也不一樣。如開發物資管理系統，直接用戶是指參與物資管理系統使用的所有用戶；但最終用戶可能是財務人員，也可能是計劃人員，甚至可能是公司經營老總。正因為如此，我們在確定需求分析的對象時，就要站在不同的角度對系統進行分析，以確定各種對象的需求。當然需求提出來以后，并不一定都要實現，可以根據用戶的需要進行取舍，但這種全面的對系統進行認識與理解，有助于我們整體把握所要開發的系統在企業各項工作中的地位與相互之間的關系，從而為系統的接口與升級留有余地。

    第四步掌握一手資料。在經過與管理者的交流，建立初步印象以后，再與各個用戶進行交流，我們所記錄與整理的內容是否真實反映了用戶所說的內容或意思，以及他們對系統實現過程中所期望能帶來的改進，這一點很重要，因為只有他們最在意一些操作的可行性與實用性要求，而領導者與管理者更重視總體的功能需求。要盡可能的訪問到每一個用戶，如果不允許，也要保證所訪問的用戶具有權威性性與典型性。

    第五步協助用戶進行流程重組。收集好用戶的各種需求與意見后，接下來，我們再與該項業務的主管人員進行交流，對我們在訪問過程中，各級用戶對系統提出的改進，或者說是感到不順的地方加以澄清，并提出我們以往針對類似情況的處理案例以供決策。某種程度上講，這是一個協助用戶進行管理流程標準化或說是管理流程重組的過程（BPR）。這樣的過程，看起來是增加了開發商的工作量，而且對開發商而言似乎未增加任何價值。但這個過程是值得的。用戶希望利用信息系統的目的，有些用戶是明確的，有些用戶不明確，無論是什么情況，內心里都有這樣一個想法，利用信息系統提高企業的管理效率，通過信息共享、提高效率等手段，來降低成本，實現企業競爭力提高的目的。因此，既然他們存在需要改進的地方，而且表達過了，如果此時不加以改進，未來也會進行改進，這種過程如果發生在我們系統開發的過程中，勢必還會需要我們對系統的開發進行調整，以便能實現他們所提出來的新功能，也許我們可以說時間不允許加以推托，或通過價格來阻止這種情況的發生，但都會引起用戶的不滿意，這對開發者來說就是利益的損失。從這種意義上講，盡可能的避免損失就是盡可能的創造效益。

    第六步正確理解需求列表。通過需求分析，最終我們會形成需求文檔，文檔最重要的內容就是需求列表，這表示我們未來所開發的系統應該實現的功能。不過我們對此要有正確的理解，雖然在系統開發中不提倡開發人員自作主張對系統增加功能，但因為見識的面不同，可以用戶一時未看到過的東西，在我們其他的項目早就實現過了，這一類情況我們要注意合理的取舍，以通過與用戶交流即時的確定是否需要。另外，不能認為用戶在需求文檔上簽過字了，以后有一點改動，都需要再行簽字。要知道，有些企業的管理人員，當時認識上確實有不足的地方，后來發現了，如果你現在不讓他改，對他要求這么嚴，他為了顧全面子，不作修改，將來使用以后，盡說你的系統的壞話，或專挑毛病，非搞死你不可?？傊?，在不影響到系統的根基的情況下，或者說對系統的開發成本沒有太大的影響的情況下，應該盡可能的讓用戶在開發完成之前提出任何功能的變更需求，這是沒辦法的辦法，這顯然與開發的理論文章的說法不一致，但卻是非常實在的一種做法。

    需求分析是一門學問，不僅要掌握需求分析的相關工具應用，還要掌握人際交往的技巧，還要善于演講，懂得管理的藝術，并且能綜合運用這些知識。因此一個系統分析員，一個好的系統分析員真的很難做，至少比系分考試的東西要難得多。

    這里講了一些實際工作中碰到的問題，以及我們的經驗之談，當然實際工作，可能因為面對的人不一樣，所要處理的問題也不一樣，但有一點沒變，即需求面對的人，而不僅僅是事，只有明白這一點，才能成為用戶的朋友，做好我們的需求分析工作。

原文轉自：http://www.anti-gravitydesign.com