要像管理諮詢一樣去做軟體需求調研

作者:wangrongguo **:wangrongguo 發布時間:2011-6-3

**，共勉！！

有感於做軟體的辛苦，特撰一文。

一般軟體公司接到了軟體實施案子，第一步是急吼吼的去做需求調研。首先集中要使用軟體的一幫人在一起開座談會，有使用部門的，有間接使用的部門，有計算機管理部門，有大老闆，有二老闆，甚至有的時候連前台也來了。好幾個部門的人集中在一起，每個人角度不同、層次不同，關注的重點不同。

大家從自己的角度唧唧喳喳的說了一通，然後需求調研人員將這些都記錄下來，形成需求文件，拿回去開發軟體。經過一段時間的努力，終於可以給相關使用人員演示了。一演示，問題來了：

某某部門的說剛才我突然發現我這裡有個東西你這軟體沒做，某某部門說我這裡還有個流程你還沒做進去，某某又說有個關鍵的報表你做的跟我們實際要的不同。。。。軟體公司的人傻了，趕緊又重新記下來，繼續修改軟體。好容易都修改完了，拿給客戶看。

客戶一看，又提出一堆問題。接下來，又繼續修改。往來反覆，幾輪之後，好容易大家都滿足了，進入試用了。

運氣好的話，皆大歡喜，部門使用的很順暢，軟體公司也不用在返工修改，客戶也滿意，最終結帳，大家都好。但是很多時候，這個時候還會有事情發生，比如：某個以前沒關注的部門突然又提出需求，我也要用這個軟體，新軟體上我不能使用。

軟體公司專案開發人員把這個部門人員請來一聊，最終發現這個部門確實有使用這個軟體的理由，再一翻以前的調研，這個部門給漏掉了。沒辦法，把這個部門的需求在加上，繼續進入開發中。。。過程如此反覆。

到最後，專案實施期越拉越長。軟體開發公司一評估，認為沒什麼利潤可賺，而客戶的需求似乎永遠很多，利益衝突糾葛在一起，就放棄該專案了。

最終的原因是什麼吶？

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

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

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

那為什麼是這個結果呢？兩方都挺受傷的。

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

那麼問題是什麼？

回到本源，我們要思考乙個問題：客戶為什麼要實施軟體？客戶實施軟體，顯然是要解決問題的。

要解決問題，需要軟體。所以他們要開發軟體。但是僅僅憑藉客戶所提出的願望去幫他們實施軟體，一般很難一次性的知道客戶真正的需求是什麼。

我們必須自己去把握這個需求，了解客戶越多，我們作出來的軟體越是客戶想要的。

ok，那我們開始了解。

第一、我們需要了解專案相關方。比如有誰在用，誰起主導作用，為什麼要實施軟體，實施軟體的背景是什麼。

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

第三、理思路。了解了流程以後，我們需要這對調研資料，畫出流程圖、整理業務報表，列出哪些是關鍵業務流程、哪些是次要業務流程、哪些流程之間有矛盾、哪些可以優化的、哪些有空白、哪些有漏洞等資訊，做出乙份報告。

第四、確認資料流之間的關係。比如資料是從**進入、到**出來。輸入是怎麼個要求、輸出是什麼樣的。

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

第六、補充建議。到這一步，基本客戶整個業務流程我們非常清晰了，針對某些流程我們可寫出自己的優化建議，以利於軟體更好的實施。

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

有人說：天啦，你這不是在做軟體管理諮詢麼？我說：

對的，你不這樣做，你就沒法了解客戶，不了解客戶，你就沒法做出合適的軟體。要做軟體，就要專業些，只有專業了，你才能做出合適的軟體。