對一項專案,成功關鍵在於你是否真的瞭解:該專案的「專案目標」是啥?為啥出錢的老闆要花銀子做這個案子?你訪談的對象是否真瞭解老闆的整體目標是啥,還是只想解決個人問題?用戶所堅持的特殊功能是為了解決哪個層面的問題?是否真的非靠該功能才能解決?
聽懂對方的話
可是要如何『瞭解』對方這可就是個學問了。尤其長久習慣與電腦為伍的IT人,慣於讓電腦瞭解自己的程式,但卻生疏於讓人類瞭解自己的想法。對電腦只要選擇了正確的編譯器(JAVA JDK、C++、VB、C#...etc),編譯器就會負責把所撰寫的程式轉化為電腦所能瞭解的語言。而且除了運算結果外,編譯器還能顯示出log記錄來讓程式員確認與除錯。
可是人與人的溝通可就沒那單純了。首先,你不會知道對方用的是哪一種獨家的編譯器,也不會有即時的output來顯示對方是怎麼惡搞你的輸入,更不會有error message與log來供你確認。
即便對方很細心的,主動作回應確認的動作,可是若是你很主觀地解讀,而沒有認真去瞭解對方回應的內容是否真的與你的預期相符也是白搭。
一種常見狀況是太強調自我表達,即便在對方作回應的期間,滿腦袋思考的也是待會自己要說啥(是待會要說啥喔,而不是待會如何回應對方【目前】的陳述。善於表達的人還挺常見這毛病),或是回去程式要怎寫(不用說,這是技術背景出身者常見的毛病),而非把心思花在用心瞭解對方目前回應的內容。
若是口才不好無法勸服對方,但是都還能瞭解對方的意思,那至少還能在早期就警覺到雙方期望落差之所在,還能及早補救或是請求協助,最差也能行諸文字記錄作好自保。但如果你自己都沒有用心試圖瞭解對方了,又怎能奢望對方能單方面用心瞭解你呢?如此一次次的『60塊炸雞』及「60元炸雞」的認知差異都沒能及早發覺,日積月累下來雙方的期望落差只可能不斷累積加深惡化。
最後等拖到了一翻兩瞪眼的成品驗收測試階段,那雙方就真的只能互相吹鬍子瞪眼甚至拍桌子翻凳子了,更遑論啥QBQ了。
繼續閱讀: >>