要像管理諮詢同樣去作軟件需求調研

轉：http://www.cnblogs.com/tyonly/archive/2011/05/23/2054141.html

有感於作軟件的辛苦，特撰一文。

      通常軟件公司接到了軟件實施案子，第一步是急吼吼的去作需求調研。首先集中要使用軟件的一幫人在一塊兒開座談會，有使用部門的，有間接使用的部門，有計算機管理部門，有大老闆，有二老闆，甚至有的時候連前臺也來了。好幾個部門的人集中在一塊兒，每一個人角度不一樣、層次不一樣，關注的重點不一樣。你們從本身的角度唧唧喳喳的說了一通，而後需求調研人員將這些都記錄下來，造成需求文檔，拿回去開發軟件。通過一段時間的努力，終於能夠給相關使用人員演示了。一演示，問題來了：某某部門的說剛纔我忽然發現我這裏有個東西你這軟件沒作，某某部門說我這裏還有個流程你還沒作進去，某某又說有個關鍵的報表你作的跟咱們實際要的不一樣。。。。軟件公司的人傻了，趕忙又從新記下來，繼續修改軟件。好容易都修改完了，拿給客戶看。客戶一看，又提出一堆問題。接下來，又繼續修改。往來反覆，幾輪以後，好容易你們都知足了，進入試用了。運氣好的話，皆大歡喜，部門使用的很順暢，軟件公司也不用在返工修改，客戶也滿意，最終結賬，你們都好。可是不少時候，這個時候還會有事情發生，好比：某個之前沒關注的部門忽然又提出需求，我也要用這個軟件，新軟件上我不能使用。軟件公司項目開發人員把這個部門人員請來一聊，最終發現這個部門確實有使用這個軟件的理由，再一翻之前的調研，這個部門給漏掉了。沒辦法，把這個部門的需求在加上，繼續進入開發中。。。  過程如此反覆。到最後，項目實施期越拉越長。軟件開發公司一評估，認爲沒什麼利潤可賺，而客戶的需求彷佛永遠不少，利益衝突糾葛在一塊兒，就放棄該項目了。

      最終的緣由是什麼吶？

     軟件公司需求調研沒作好嗎？調研確實作了，並且相關人員都請到了，作的需求報告各部門都確認過了。

     客戶不配合嗎？也不對，客戶至關的配合，每一個相關部門都說出了需求，所須要的報表他們都很熱情的給你。

     客戶領導不重視嗎？那怎麼會，不重視的話，還請你作軟件幹什麼？

     那爲何是這個結果呢？兩方都挺受傷的。

     表面看，沒有任何一個單獨的問題會致使困難，每一個問題都能被解決，可是當他們糾結在一塊兒的時候，事情就變得難以被解決。面對這種問題，咱們很難看到問題本質所在。不過，若是咱們要解決問題，必須試圖先去了解問題。

    那麼問題是什麼？

    回到本源，咱們要思考一個問題：客戶爲何要實施軟件？客戶實施軟件，顯然是要解決問題的。要解決問題，須要軟件。因此他們要開發軟件。可是僅僅憑藉客戶所提出的願望去幫他們實施軟件，通常很難一次性的知道客戶真正的需求是什麼。咱們必須本身去把握這個需求，瞭解客戶越多，咱們做出來的軟件越是客戶想要的。

   OK，那咱們開始瞭解。

   第1、咱們須要瞭解項目相關方。好比有誰在用，誰起主導做用，爲何要實施軟件，實施軟件的背景是什麼。

   第2、理流程。一個部門一個部門去了解，現場去看，去研究，和實際使用者一塊兒去工做，瞭解業務流程，弄懂相關業務報表，對產生的報表的重要度進行分析，理順與其餘報表的勾結關係等。

   第3、理思路。瞭解了流程之後，咱們須要這對調研資料，畫出流程圖、整理業務報表，列出哪些是關鍵業務流程、哪些是次要業務流程、哪些流程之間有矛盾、哪些能夠優化的、哪些有空白、哪些有漏洞等信息，作出一份報告。

  第4、確認數據流之間的關係。好比數據是從哪裏進入、到哪裏出來。輸入是怎麼個要求、輸出是什麼樣的。

  第5、確認特殊流程和特殊需求，如：每一個崗位每一個人須要解決什麼、特殊事件是如何發生的，怎麼解決。

  第6、補充建議。到這一步，基本客戶整個業務流程咱們很是清晰了，針對某些流程咱們可寫出本身的優化建議，以利於軟件更好的實施。

  最後，咱們整理報告，告訴客戶，咱們瞭解了什麼。將來軟件會解決什麼。我相信，當你把這些詳細的報告丟到客戶面前的時候，客戶還有什麼理由不承認你所作的軟件呢。

    有人說：天啦，你這不是在作軟件管理諮詢麼？我說：對的，你不這樣作，你就無法瞭解客戶，不瞭解客戶，你就無法作出合適的軟件。要作軟件，就要專業些，只有專業了，你才能作出合適的軟件。