編者按：不想捂著臉求人改需求？來看工程師怎麼說！前段時間，在互動設計階段如何發現思維盲區，減少開發與視覺的返工。今天讓騰訊前端@姬小光 從開發角度聊聊如何在需求確立和需求評審階段洞悉隱性需求，無論是開發人員還是產品，都能用上！
俗話說，計劃趕不上變化快，無論需求文件做得如何細緻，考慮得如何周全，總會有些難以預料的需求變更在每天困擾著我們。開發人員苦惱，產品運營人員更苦惱，畢竟誰也不願意捂著臉一遍一遍地求人改需求。
但是，雖然世界充滿未知的變化，但是有一些大的方向還是可以把握的，無論是產品運營還是開發人員，都可以在需求確立以及需求評審時多多考慮一下小雞君說的這些方面，相信一定可以減少一些後期的變更成本。
下面這些內容主要是從開發人員的視角考慮的，多數基於小雞君的個人經驗，難免有失偏頗，不當之處還望指正。當然，如不嫌棄，感興趣的產品和運營人員也可以稍作參考。
1. 細節變更需求
在專案初期，如果產品人員沒有想清楚需求的細節，那麼細節的變更可以說是無法避免的。那麼作為開發人員唯一能做的就是，在設計程式結構和邏輯的時候，儘量預留出可擴充套件的能力。比如模組的增刪，欄位的增減，頁面樣式的微調等，除此之外也沒什麼好辦法了。別灰心，這都不是事兒。
2. 跨平臺需求
跨平臺需求有時候來的非常隱蔽，往往最初規劃的時候感覺可以先在一個平臺嘗試一下，比如先規劃了 PC 端，但是 PC 端的某些功能又會忽然很急促的想移植到移動端。
而需求人員往往會想當然的認為，功能差不多，只要挪一下就可以了（平移過去/拼過去）。或者是，頁面長的差不多，就改成移動端的大小就可以了（縮一下）。殊不知各個平臺無論在架構部署，還是操作體驗上都有著天壤之別，如果不提前規劃好，那必然是個大坑。
3. 擴充套件需求
無論是什麼樣的業務，隨著業務量的增長，以及產品運營人員慾望的膨脹，都會催生出各種擴充套件需求。任何固定數量的，都會增加。任何單一需要的，都會變成多個。
比如頁面上設計了三個商品推薦位，就要預留出變成六個、九個，甚至分頁的能力。一個介面是給某個業務專用的，某天就可能變成通用的。一個簡單的靜態頁面，某天就可能變成附帶管理後臺的複雜系統。對於擴充套件性需求，要反覆確認，不必過度優化，但也要留出合理的擴充套件空間。
4. 異常流需求
異常流需求往往容易被忽略，或者多有疏漏。常見的異常流有圖片資料載入不出，圖片不存在，介面掛掉，網速慢，未登入，登入態丟失，查詢出錯，查詢無資料，內容溢位，使用者輸入溢位，使用者輸入非法，視覺遮擋不可用等等等等。
那麼，對應這些異常流情況，就要有配套的前端提示給使用者，引導使用者進行其他操作。這些異常流往往會在設計稿和文件中遺漏掉，比如各種異常提示浮層，需要登入態的操作，結果登入態丟失等等，都需要有對應的引導。
5. 內容運營需求
所有靜態的內容，都可能變成運營需求。靜態廣告位可能變成輪播廣告位，輪播廣告位可能變成需要運營後臺填寫資料，而不是直接寫死在頁面裡。或者某一天可能變成從另外一個自動資料來源拉取資料。
關於內容運營需求，評審初期可以確認好運營頻次，如果是個把月才改一次的，幾乎不耗人力的，那也沒必要都搞工具。但是如果每天改一次，或者感覺運營內容的時間已經影響到正常的工作，或者遠遠大於寫個工具的時間，那還是老老實實開發個運營工具吧。
6. 內容校驗需求
上面既然說到運營工具了，那麼作為運營工具一定是由運營人員自己來填寫。既然是非技術人員填寫，操作就難免要傻瓜一點，或者說非技術一點，儘量操作簡潔，並且可以校驗輸入。如果因為運營人員多打了個空格，活著多寫了個英文逗號系統就掛了，那應該算誰不盡責呢？
還有，能分別運營的欄位要分別運營，因為有的時候雖然內容看上去是合在一起的，但是經常會有部分修改的需求，不如分開兩個欄位。比如廣告位連結和埋點 tag，連結可能經常換，但固定位置的 tag 值就不會換，所以分開運營會好一些。
7. 內容複用需求
運營同學的工作是很辛苦的，設想一下每天一邊開著 excel ，一邊開著你的運營系統一個欄位一個欄位填寫的時候，就知道畫面有多美了。所以，運營填寫的資料一定是有複用需求的。比如 h5 頁面上運營的資料，有可能還需要給原生 app 使用，甚至給 pc 端也用一套資料。一個廣告圖片和連結，可能被插入到多個頁面的頂部或底部，一起更新。多多溝通複用需求，可以隨手拯救一大波運營妹子。
8. 內容歷史需求
既然運營妹子這麼不容易，那麼工作量 KPI 如何衡量呢？這麼辛苦再沒人知道不是太慘了？所以，運營的資料一般是要有歷史的。
如果就一個坑位，每次都改掉內容來更新，上一次的就沒了，那麼鬼知道我一天改了多少次？一週做了多少次更新？當然，這裡更偏向工具類的需求了，不過我重點要說的是，有運營需求，就可能有運營的歷史記錄需求。
9. 排序&打標需求
排序需求其實也是內容運營需求的一種，無論是運營填寫的還是自動拉取的內容，永遠都會有調整順序的需求。不同的坑位對應不同的關注度，不同的視覺焦點，瀏覽路徑。運營往往需要通過調整位置或者加些標記來突出某些內容。
比如商品列表，可能近期有幾個商品比較好賣，就挪到前面，打上 hot 或者 new 的標記，從而促成更多的銷量。對於排序和打標需求，往往從後臺開始就要預留可擴充套件欄位，到前端也要可以方便的調整位置和加 icon 標記才行。
10. 篩選需求
對應於排序和打標，篩選也是經常用到的。比如我搜集了一坨資料，又只想挑一部分來展示，這時候往往需要一個可以方便操作的地方，類似帖子加精，評論置頂等等。商品類的資料篩選需求就更多啦，不過一般可以整合在搜尋功能中，作為通用介面提供。但是，運營同學手動填寫的資料再進行篩選，那功能就只能業務側自己設計了，可以根據需要增加不同的篩選欄位供運營同學填寫。
11. 資料統計需求
資料統計需求是很容易失控的一種需求，產品運營最初往往覺得我要個 PV UV 啥的就夠用了，過幾天可能說能不能統計下這個按鈕的點選量，再過幾天可能恨不得把所有的操作都埋點，再加上訪問路徑、購買路徑、轉化率、蹦失率、頁面停留時間、點選熱圖、滑鼠軌跡。。。再給我出個月度季度報表，趨勢圖等等。
這裡，對於資料統計需求一定要評審時梳理好，甚至我覺得可以獨立於正常的需求，作為單獨的資料統計需求整體梳理後提出。
12. 翻舊賬需求
我實在找不到更貼切的詞彙了。翻舊帳的意思就是，凡事進到我係統裡的資料，都希望有個方便的形式可以看到。比如使用者建立的 UGC，一定要有個唯一的地址可以看到這個資源。使用者錄入的資訊，要有個方便的地方可以匯出，或者下載 excel。即使當前的需求不需要你展示歷史記錄或者以前的任何內容，也要預留出方便的查詢介面備用。
13. 報銷需求
這個有點詭異，報銷關我鳥事？當然關。許多大公司的報銷流程都很嚴格，畢竟是涉及到錢的問題。那麼對於涉及到錢的活動來說，唯一的憑據可能就是你資料庫裡的資料了。所以有關錢的需求，最好開始就確認好報銷需要哪些內容，比如使用者的真實手機等等（確認是真人蔘與活動，沒有造假），以此來作為最終報銷的憑據，否則就只能運營同學自己出血了。
14. 擴容需求
當業務量穩步上升時就會伴隨著擴容的需求，尤其當訪問量驟增的時候，快速擴容就迫在眉睫了。擴容包含很多方面，一些效能方面的問題會在高併發史迅速凸顯，比如查詢低效，PHP慢速，無靜態化 web，併發壓力大等等。
此時關於效能優化的一切知識都可以派上用場了，靜態化、快取、查詢優化、鎖表等等。而機器擴容也沒那麼簡單，除了機器內容的複製還有相應服務的批量啟動，定時任務的執行，日誌的歸集等等。所以，如果評估時預計業務會有爆發性增長（如微信活動），在資金允許的情況下不妨多準備些機器，總比一發布就掛了強。
15. 安全需求
這一點放到了最後，同樣也是最重要的。安全問題包含的範圍非常廣泛，雖然有專業的同事負責安全以及運維相關的工作，但是在需求初期如果能稍微做些防範就會避免很多問題。一般的公司都會有個基礎的安全規範，比如如何防止 XSS, CSRF 攻擊，如何防止 SQL 注入，如何遮蔽指令碼攻擊等。
還有一些外部介面需要鑑權的，有時可能做了基本的鑑權，確沒有更高階的防護。比如一個人雖然登入了，可以看到自己的某些資料，但是如果這個登入的使用者還可以通過相同的介面檢視其他人的某些資訊，那就是安全問題了。有可能這個資訊是儲存在相對獨立的表中，並沒有嚴格掛在這個使用者id下，那麼查詢的時候就一定要再檢查一下資料和使用者的對應關係。
對於安全需求，普通前後臺開發人員能做的其實並不多，能按部就班做好這些基礎防護就不容易了。加上公司公共的安全掃描平臺，基本上可以杜絕絕大部分安全問題了。之所以寫到這裡單獨列一條，還是希望大家要對安全足夠重視。
綜上所述，絕大部分的隱形需求都是有跡可尋的。然並卵，即便溝通再明確，郵件再確認，改來改去啪啪啪打臉，該做的需求還是要做，所以，節哀吧。