小白兔蹦蹦跳跳到面包房，問：“老板，你們有沒有一百個小面包啊？”
老板：“啊，真抱歉，沒有那么多”
“這樣啊。。?！毙“淄么诡^喪氣地走了。
第二天，小白兔蹦蹦跳跳到面包房,“老板，有沒有一百個小面包啊？”
老板：“對不起，還是沒有啊”
“這樣啊。。?！毙“淄糜执诡^喪氣地走了。
第三天，小白兔蹦蹦跳跳到面包房,“老板，有沒有一百個小面包?。俊?
老板高興的說：“有了，有了，今天我們有一百個小面包了??！”
小白兔掏出錢：“太好了，我買兩個！”
    在昨天需求的陷阱的文中，我們先不考慮這個淘氣的小學生該去什么樣的學校，不過對于需求調(diào)研的重要性已經(jīng)引起大伙的主意。不過在我們到底該如何做好需求調(diào)研的工作，避免掉入需求的這個陷阱之后，要做好需求不是一句話或則一篇文章可以解釋清楚的，畢竟這個課題有太多人在研究在考慮。今天我們還是從方法上去考慮，如何才能夠讓我們的需求盡可能能夠達到開發(fā)的要求和滿足客戶的真正需要。用小白兔買面包的故事來說明簡單與不簡單的問題有點牽強，但是實際開發(fā)中如果沒有處理好問題的話，使簡單的問題復雜化，復雜的問題片面化，客戶方與開發(fā)方何嘗不會出現(xiàn)小白兔的現(xiàn)象。
    1：簡單
    什么是簡單？該如何簡單？或許有不少人說小學生不適合作需求調(diào)研，因為他把簡單的問題復雜化了，如果team中有這樣的人做需求，對于項目組來說是一個惡夢。其實我們做項目的時候，都希望能夠?qū)碗s的問題簡單化，多于同樣能夠解決客戶的多種方法中，我相信簡單的方法都會成為首選。所以問題的簡單化不是一個過錯，而是一個良好的方法，但是對于這種簡單的做法必須有一個前提，那就是必須滿足客戶的功能和使用上的要求，這一點可能非常容易出現(xiàn)差錯。很多人在做需求定義的時候，會有類似的問題存在：
    1） 對于客戶的業(yè)不理解，想當然的簡單化
    2） 客戶提出的功能，用偷工的方式簡單化
    3） 客戶提出的問題比較弱智，不需要考慮的簡單化
    4） 細節(jié)問題的簡單化
    對于這些方面的簡單我想直接給項目的開發(fā)種下一個惡根，后續(xù)的開發(fā)反復追問吵鬧是在所難免。
    那么我們該如何選用簡單的方式呢？還是那些老調(diào)的方法，就是問題的確認方式要簡單，要讓客戶能夠比較直觀的看到你要做的東西，不論采用那種方法，比如界面演說，敏捷開發(fā)中的Demo推進的方法都可以。客戶的優(yōu)勢在于他們對于本身的工作內(nèi)容非常清楚，但是不要指望他們能夠?qū)⑦@些問題用很專業(yè)的計算技術(shù)語的方法來描述清楚。也不要避免讓客戶想象系統(tǒng)是如何如何？這一切都不實際，兩個人的理解很難是一樣的，對于同一個月亮，可能一個想象的是光色多美，一個想象的是有月餅吃多好。所以如果用直觀的方式來描述問題，拋開那么多深奧的建模工具，多于客戶來說可能更容易理解。當然，如果客戶的能力能夠和你旗鼓相當，那么那些工具可能是最好的選擇，所以的一切都需要緊記一點，交流的雙方應(yīng)該確定在同一層次上用相應(yīng)的方式進行交流。
    2：手段
    簡單的交流要有手段和技巧，如何避免客戶反感然后得到客戶的最大配合，這需要很強的EQ,但是在這些交流中，一些比較常用的方式倒可以大大提高你的交流效果。
    1）選擇性的問題永比敘述性的問題奏效
在做需求調(diào)研的時候，如果用“為什么。。。，該怎么。。。？”這種方式去詢問客戶比“是不是這樣：1）….2)….”的這種方式要差很多，而且客戶的回復速度上也有很大的差別，讓客戶選擇其中的一點，客戶一方面感覺你已經(jīng)做了大量的工作和思考，另一方面替客戶節(jié)約了不少的時間。
    2）圖比文描述直觀
寫文檔可能對于做開發(fā)的人來說比較困難，對于客戶來說，長篇巨幅的文章去起來也非常吃力，很多時候問題還很難描述清楚，再加上中國文字的精辟特點，描述的

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html