有時候
提出需求的人
可能并不知道
自己真正想要的是什么
提出需求的人
通常只是將自己能看到的東西
結合上自己想要的東西
用自己的邏輯演繹之后
得出的所謂需求
不同領域
不同層次的人
對需求的描述方式都是不同的
僅僅通過別人對需求的描述
實際上很難了解對方真正的意圖
比如加鏈接這個需求
實際提出這個需求的人想要的可能是：
1、統計每次點擊的用戶
2、可以自己修改這個鏈接的文字和地址
3、對不同地區的用戶顯示不同的鏈接
4、…
需求只是一種主觀的描述方式
直接參考價值并不高
我們應該和需求方聊聊背景
聊聊為什么會提出這樣的需求？
有沒有想過或嘗試過別的方案？
1:你的需求其實并不需要開發
很多需求只不過是現有資源沒被充分利用造成的。滿足這樣的需求可能只是做一些資源的調配，不需要投入額外的開發。
如果只是鏈接到活動頁面，可以通過后臺配置出來，不需要投入開發。
這個鏈接固定到當前用戶個人中心頁，我們有現成的組件可以直接用。
不寫代碼就能滿足需求才是最優雅的實現方式。
2:你的需求這么做會更好
提出需求的人可能會缺少某些方面的意識，我們可以在了解需求背景的階段給出一些建議。
把鏈接放在另一個位置轉化率會更高，而且不會讓用戶覺得惡心。
這里可能需要限制一下字數，這塊空間只能容納 15 個字，否則就換行了。
這樣的建議也是因人而異的，如果提需求的人比我們的產品感官更高，這時候我們再去給對方建議就有點班門弄斧了。但是這并不妨礙我們了解需求時問到「為什么把鏈接放在這里？」，可以抱著學習、提高自己的心態問。
3:現階段你不能這么做
某些需求可能就是現階段不能做的，但是這些不能做的原因可能在需求方的認知范圍之外。
鏈接的文案和文字的控制權交給外部，這樣無法通過安全評估。
這個頁面不能大量引流，我們需要先優化性能，否則服務器會扛不住。
這種時候好好解釋清楚，該拒絕的就拒絕。有些原則問題是不能容忍的，強行去滿足這種需求遲早會出事。
當然有時候會遇到一些溝通不到一個點上的需求方，這時候可以考慮聊聊情懷、聊聊價值觀。
4:找個 ROI 較高的平衡點
提出需求的人可能并不知道實現成本有多高，討價還價很有必要。
這個地方加鏈接可能需要下個月才能上線，用按鈕的形式明天就可以上線。
做到可以實時修改可能需要投入一周的工作量，容忍 1 小時延遲的話馬上就可以搞定。
如果我們了解過背景，可以發現需求方的描述中有些部分根本就和背景沒關系，只是拍腦袋決定的。
如果只是加一個入口，未必非要用鏈接的形式，用按鈕同樣可以做到。如果使用按鈕的方案不需要做任何開發，而改成鏈接可能需要跨團隊協作，還需要 App 發版本，那么為何要執著于用按鈕的形式呢？
5:最后
把所有事情考慮清楚之后，我選擇了在 html 文件里面加個 A 標簽。需求真的只是想加個鏈接而已，根本就沒我想的這么一大堆破事。
但是這并不是什么令人后悔的事，在一件事沒有進入終態之前，它存在的概率足以讓我們去思考這一堆問題。僥幸的心態終究會敗給墨菲定律。
