不想捂著臉求人改需求？來看工程師怎么說！前段時間，在交互設計階段如何發現思維盲區，減少開發與視覺的返工。今天讓騰訊前端@姬小光 從開發角度聊聊如何在需求確立和需求評審階段洞悉隱性需求，無論是開發人員還是產品，都能用上！

減少改稿同款教程：《減少返工！如何發現交互設計中的思維盲區？》

俗話說，計劃趕不上變化快，無論需求文檔做得如何細致，考慮得如何周全，總會有些難以預料的需求變更在每天困擾著我們。開發人員苦惱，產品運營人員更苦惱，畢竟誰也不愿意捂著臉一遍一遍地求人改需求。

但是，雖然世界充滿未知的變化，但是有一些大的方向還是可以把握的，無論是產品運營還是開發人員，都可以在需求確立以及需求評審時多多考慮一下小雞君說的這些方面，相信一定可以減少一些后期的變更成本。

下面這些內容主要是從開發人員的視角考慮的，多數基于小雞君的個人經驗，難免有失偏頗，不當之處還望指正。當然，如不嫌棄，感興趣的產品和運營人員也可以稍作參考。

在項目初期，如果產品人員沒有想清楚需求的細節，那么細節的變更可以說是無法避免的。那么作為開發人員唯一能做的就是，在設計程序結構和邏輯的時候，盡量預留出可擴展的能力。比如模塊的增刪，字段的增減，頁面樣式的微調等，除此之外也沒什么好辦法了。別灰心，這都不是事兒。

跨平臺需求有時候來的非常隱蔽，往往最初規劃的時候感覺可以先在一個平臺嘗試一下，比如先規劃了 PC 端，但是 PC 端的某些功能又會忽然很急促的想移植到移動端。

而需求人員往往會想當然的認為，功能差不多，只要挪一下就可以了（平移過去/拼過去）?；蛘呤?，頁面長的差不多，就改成移動端的大小就可以了（縮一下）。殊不知各個平臺無論在架構部署，還是操作體驗上都有著天壤之別，如果不提前規劃好，那必然是個大坑。

無論是什么樣的業務，隨著業務量的增長，以及產品運營人員欲望的膨脹，都會催生出各種擴展需求。任何固定數量的，都會增加。任何單一需要的，都會變成多個。

比如頁面上設計了三個商品推薦位，就要預留出變成六個、九個，甚至分頁的能力。一個接口是給某個業務專用的，某天就可能變成通用的。一個簡單的靜態頁面，某天就可能變成附帶管理后臺的復雜系統。對于擴展性需求，要反復確認，不必過度優化，但也要留出合理的擴展空間。

異常流需求往往容易被忽略，或者多有疏漏。常見的異常流有圖片數據加載不出，圖片不存在，接口掛掉，網速慢，未登錄，登錄態丟失，查詢出錯，查詢無數據，內容溢出，用戶輸入溢出，用戶輸入非法，視覺遮擋不可用等等等等。

那么，對應這些異常流情況，就要有配套的前端提示給用戶，引導用戶進行其他操作。這些異常流往往會在設計稿和文檔中遺漏掉，比如各種異常提示浮層，需要登錄態的操作，結果登錄態丟失等等，都需要有對應的引導。

所有靜態的內容，都可能變成運營需求。靜態廣告位可能變成輪播廣告位，輪播廣告位可能變成需要運營后臺填寫數據，而不是直接寫死在頁面里?；蛘吣骋惶炜赡茏兂蓮牧硗庖粋€自動數據源拉取數據。

關于內容運營需求，評審初期可以確認好運營頻次，如果是個把月才改一次的，幾乎不耗人力的，那也沒必要都搞工具。但是如果每天改一次，或者感覺運營內容的時間已經影響到正常的工作，或者遠遠大于寫個工具的時間，那還是老老實實開發個運營工具吧。

上面既然說到運營工具了，那么作為運營工具一定是由運營人員自己來填寫。既然是非技術人員填寫，操作就難免要傻瓜一點，或者說非技術一點，盡量操作簡潔，并且可以校驗輸入。如果因為運營人員多打了個空格，活著多寫了個英文逗號系統就掛了，那應該算誰不盡責呢？

還有，能分別運營的字段要分別運營，因為有的時候雖然內容看上去是合在一起的，但是經常會有部分修改的需求，不如分開兩個字段。比如廣告位鏈接和埋點 tag，鏈接可能經常換，但固定位置的 tag 值就不會換，所以分開運營會好一些。

運營同學的工作是很辛苦的，設想一下每天一邊開著 excel ，一邊開著你的運營系統一個字段一個字段填寫的時候，就知道畫面有多美了。所以，運營填寫的數據一定是有復用需求的。比如 h5 頁面上運營的數據，有可能還需要給原生 app 使用，甚至給 pc 端也用一套數據。一個廣告圖片和鏈接，可能被插入到多個頁面的頂部或底部，一起更新。多多溝通復用需求，可以隨手拯救一大波運營妹子。

既然運營妹子這么不容易，那么工作量 KPI 如何衡量呢？這么辛苦再沒人知道不是太慘了？所以，運營的數據一般是要有歷史的。

如果就一個坑位，每次都改掉內容來更新，上一次的就沒了，那么鬼知道我一天改了多少次？一周做了多少次更新？當然，這里更偏向工具類的需求了，不過我重點要說的是，有運營需求，就可能有運營的歷史記錄需求。

排序需求其實也是內容運營需求的一種，無論是運營填寫的還是自動拉取的內容，永遠都會有調整順序的需求。不同的坑位對應不同的關注度，不同的視覺焦點，瀏覽路徑。運營往往需要通過調整位置或者加些標記來突出某些內容。

比如商品列表，可能近期有幾個商品比較好賣，就挪到前面，打上 hot 或者 new 的標記，從而促成更多的銷量。對于排序和打標需求，往往從后臺開始就要預留可擴展字段，到前端也要可以方便的調整位置和加 icon 標記才行。

對應于排序和打標，篩選也是經常用到的。比如我搜集了一坨數據，又只想挑一部分來展示，這時候往往需要一個可以方便操作的地方，類似帖子加精，評論置頂等等。商品類的數據篩選需求就更多啦，不過一般可以集成在搜索功能中，作為通用接口提供。但是，運營同學手動填寫的數據再進行篩選，那功能就只能業務側自己設計了，可以根據需要增加不同的篩選字段供運營同學填寫。

數據統計需求是很容易失控的一種需求，產品運營最初往往覺得我要個 PV UV 啥的就夠用了，過幾天可能說能不能統計下這個按鈕的點擊量，再過幾天可能恨不得把所有的操作都埋點，再加上訪問路徑、購買路徑、轉化率、蹦失率、頁面停留時間、點擊熱圖、鼠標軌跡。。。再給我出個月度季度報表，趨勢圖等等。

這里，對于數據統計需求一定要評審時梳理好，甚至我覺得可以獨立于正常的需求，作為單獨的數據統計需求整體梳理后提出。

我實在找不到更貼切的詞匯了。翻舊帳的意思就是，凡事進到我系統里的數據，都希望有個方便的形式可以看到。比如用戶創建的 UGC，一定要有個唯一的地址可以看到這個資源。用戶錄入的信息，要有個方便的地方可以導出，或者下載 excel。即使當前的需求不需要你展示歷史記錄或者以前的任何內容，也要預留出方便的查詢接口備用。

這個有點詭異，報銷關我鳥事？當然關。許多大公司的報銷流程都很嚴格，畢竟是涉及到錢的問題。那么對于涉及到錢的活動來說，唯一的憑據可能就是你數據庫里的數據了。所以有關錢的需求，最好開始就確認好報銷需要哪些內容，比如用戶的真實手機等等（確認是真人參與活動，沒有造假），以此來作為最終報銷的憑據，否則就只能運營同學自己出血了。

當業務量穩步上升時就會伴隨著擴容的需求，尤其當訪問量驟增的時候，快速擴容就迫在眉睫了。擴容包含很多方面，一些性能方面的問題會在高并發史迅速凸顯，比如查詢低效，PHP慢速，無靜態化 web，并發壓力大等等。

此時關于性能優化的一切知識都可以派上用場了，靜態化、緩存、查詢優化、鎖表等等。而機器擴容也沒那么簡單，除了機器內容的復制還有相應服務的批量啟動，定時任務的執行，日志的歸集等等。所以，如果評估時預計業務會有爆發性增長（如微信活動），在資金允許的情況下不妨多準備些機器，總比一發布就掛了強。

這一點放到了最后，同樣也是最重要的。安全問題包含的范圍非常廣泛，雖然有專業的同事負責安全以及運維相關的工作，但是在需求初期如果能稍微做些防范就會避免很多問題。一般的公司都會有個基礎的安全規范，比如如何防止 XSS, CSRF 攻擊，如何防止 SQL 注入，如何屏蔽腳本攻擊等。

還有一些外部接口需要鑒權的，有時可能做了基本的鑒權，確沒有更高級的防護。比如一個人雖然登錄了，可以看到自己的某些資料，但是如果這個登錄的用戶還可以通過相同的接口查看其他人的某些信息，那就是安全問題了。有可能這個信息是存儲在相對獨立的表中，并沒有嚴格掛在這個用戶id下，那么查詢的時候就一定要再檢查一下數據和用戶的對應關系。

對于安全需求，普通前后臺開發人員能做的其實并不多，能按部就班做好這些基礎防護就不容易了。加上公司公共的安全掃描平臺，基本上可以杜絕絕大部分安全問題了。之所以寫到這里單獨列一條，還是希望大家要對安全足夠重視。

綜上所述，絕大部分的隱形需求都是有跡可尋的。然并卵，即便溝通再明確，郵件再確認，改來改去啪啪啪打臉，該做的需求還是要做，所以，節哀吧。

以上就是從開發角度聊聊如何在需求確立和需求評審階段洞悉隱性需求介紹，希望這篇教程能對大家有所幫助！