需求作為用戶獲得產品的最重要動機，是每一個開發者都應該關注和重視的問題。一些開發人員在工作過程中往往在碰到不合理的需求，這些不合理需求不僅會嚴重阻礙開發人員正常工作的開展，也將影響產品或者項目的價值。那么，當我們遇到不合理的需求時，應該如何應對呢？中培課堂《需求分析與管理最佳實踐》王教授在這里給出了自己的意見。

討論需求本身

接到需求的時候，不要討論設計解決方案，而應該討論需求本身。設計解決方案是設計師需要考慮的專業問題，和PM爭論并不會產生實質性作用，所以之前產品經理無論拿來多么精密的原型和文檔的時候我都會忽視掉解決方案的那部分，有時候會出現以下定位出問題：

1、這個需求根本是達成什么目的？

2、這個需求需要的優先程度是怎樣的？

3、這個需求需要的衡量標準是什么？

很顯然這里的需求就是提供一個幫助入口，并且希望可以盡量幫助有問題的用戶”。

　　要追問需求背后的目標和背景

在這場溝通案例中設計師一直都在說沒必要做的這么強，但是他沒有向 PM 了解為什么要做的這么強，忽略了挖掘需求背后的背景和原因：

比如是產品最近有出現重大問題需要緊急修復并且告知用戶嗎？如果這樣的話可以直接針對這個問題給用戶彈出問題卡片，并且告知事故現象和解決方案，而不是模糊的幫助入口；

如果是產品業務流程比較復雜，用戶的完成度低所以需要幫助？那幫助的入口是否可以直接引入到場景中，比如在輸入密碼錯誤的時候彈出找回密碼方式，在首次進行某項操作的時候進行新手引導？

需求的背景和目標是一個完整的整體，只有全面了解了之后設計師才可能給出ABCD等不同的解決方案，并且在這些解決方案中分析出優劣找出最優解。

設計效果不能只看單一的某個維度

衡量指標有三個維度：誰的功能量級大，誰的功能質量好，誰的功能對產品整體帶來的收益高。所以雖然這個幫助入口點擊率高，可能用戶進去了之后轉化率和留存會很低（沒需求的用戶好奇點進去就走了），另外也許功能上線后用戶的負面反饋會增多，其他功能的流量也會受到此影響，而這個功能的根本目標（幫助用戶解決問題 – 看問題的修復率）并不會改善很多。

所以，設計師衡量效果不能只看點擊率這么一個指標，轉化率、留存和用戶反饋等都很重要。

設計師要更主動的去獲取信息

案例里的設計師還有一個很大的毛病就是完全被PM牽著鼻子走，通過有限的信息去判斷需求和方案的好壞，其實設計師可以自己主動做到對信息的全面掌握：

設計師有機會應該多去參加產品經理的周會、需求評審會、需求討論會，多觀察老大們對產品戰略的宣講，盡量做到設計師本身就可以掂量哪些是重要的哪些是不重要的。

設計師可以盡量去開通數據管理后臺學會自己查數據，或者直接進反饋平臺、AppStore、微博、貼吧去看用戶反饋。如果實在不行大公司套路深，可以讓產品和運營把相關的周報抄送給你。

設計師要經常學會向上溝通而不是點對點溝通，遇到這個問題的時候可以拉很多人來討論，拉領導來討論，拉牽扯到相關的產品經理來討論，由大家一起發表看法。比如案例中如果設計師拉來負責首頁的產品經理說”他要搶你流量”，你看他們不得先PK一遍？或者如果這個產品經理的需求真的不靠譜的話，適當的和老大提一提那個產品經理很可能就被噴。不必要怕溝通，作為設計師愿意去認真對待一個需求一定是會收到刮目相看的。