2015-10-12 周周
藍藍設(shè)計( m.sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供有效的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)
如果您想訂閱本博客內(nèi)容，每天自動發(fā)到您的郵箱中， 請點這里
編者按：不想捂著臉求人改需求？來看工程師怎么說！前段時間，在交互設(shè)計階段如何發(fā)現(xiàn)思維盲區(qū)，減少開發(fā)與視覺的返工。今天讓小光從開發(fā)角度聊聊如何在需求確立和需求評審階段洞悉隱性需求，無論是開發(fā)人員還是產(chǎn)品，都能用上！
俗話說，計劃趕不上變化快，無論需求文檔做得如何細致，考慮得如何周全，總會有些難以預料的需求變更在每天困擾著我們。開發(fā)人員苦惱，產(chǎn)品運營人員更苦惱，畢竟誰也不愿意捂著臉一遍一遍地求人改需求。
但是，雖然世界充滿未知的變化，但是有一些大的方向還是可以把握的，無論是產(chǎn)品運營還是開發(fā)人員，都可以在需求確立以及需求評審時多多考慮一下小光君說的這些方面，相信一定可以減少一些后期的變更成本。
下面這些內(nèi)容主要是從開發(fā)人員的視角考慮的，多數(shù)基于小雞君的個人經(jīng)驗，難免有失偏頗，不當之處還望指正。當然，如不嫌棄，感興趣的產(chǎn)品和運營人員也可以稍作參考。
在項目初期，如果產(chǎn)品人員沒有想清楚需求的細節(jié)，那么細節(jié)的變更可以說是無法避免的。那么作為開發(fā)人員唯一能做的就是，在設(shè)計程序結(jié)構(gòu)和邏輯的時候，盡量預留出可擴展的能力。比如模塊的增刪，字段的增減，頁面樣式的微調(diào)等，除此之外也沒什么好辦法了。別灰心，這都不是事兒。
跨平臺需求有時候來的非常隱蔽，往往最初規(guī)劃的時候感覺可以先在一個平臺嘗試一下，比如先規(guī)劃了 PC 端，但是 PC 端的某些功能又會忽然很急促的想移植到移動端。
而需求人員往往會想當然的認為，功能差不多，只要挪一下就可以了（平移過去/拼過去）?；蛘呤牵撁骈L的差不多，就改成移動端的大小就可以了（縮一下）。殊不知各個平臺無論在架構(gòu)部署，還是操作體驗上都有著天壤之別，如果不提前規(guī)劃好，那必然是個大坑。
無論是什么樣的業(yè)務(wù)，隨著業(yè)務(wù)量的增長，以及產(chǎn)品運營人員欲望的膨脹，都會催生出各種擴展需求。任何固定數(shù)量的，都會增加。任何單一需要的，都會變成多個。
比如頁面上設(shè)計了三個商品推薦位，就要預留出變成六個、九個，甚至分頁的能力。一個接口是給某個業(yè)務(wù)專用的，某天就可能變成通用的。一個簡單的靜態(tài)頁面，某天就可能變成附帶管理后臺的復雜系統(tǒng)。對于擴展性需求，要反復確認，不必過度優(yōu)化，但也要留出合理的擴展空間。
異常流需求往往容易被忽略，或者多有疏漏。常見的異常流有圖片數(shù)據(jù)加載不出，圖片不存在，接口掛掉，網(wǎng)速慢，未登錄，登錄態(tài)丟失，查詢出錯，查詢無數(shù)據(jù)，內(nèi)容溢出，用戶輸入溢出，用戶輸入非法，視覺遮擋不可用等等等等。
那么，對應(yīng)這些異常流情況，就要有配套的前端提示給用戶，引導用戶進行其他操作。這些異常流往往會在設(shè)計稿和文檔中遺漏掉，比如各種異常提示浮層，需要登錄態(tài)的操作，結(jié)果登錄態(tài)丟失等等，都需要有對應(yīng)的引導。
所有靜態(tài)的內(nèi)容，都可能變成運營需求。靜態(tài)廣告位可能變成輪播廣告位，輪播廣告位可能變成需要運營后臺填寫數(shù)據(jù)，而不是直接寫死在頁面里?；蛘吣骋惶炜赡茏兂蓮牧硗庖粋€自動數(shù)據(jù)源拉取數(shù)據(jù)。
關(guān)于內(nèi)容運營需求，評審初期可以確認好運營頻次，如果是個把月才改一次的，幾乎不耗人力的，那也沒必要都搞工具。但是如果每天改一次，或者感覺運營內(nèi)容的時間已經(jīng)影響到正常的工作，或者遠遠大于寫個工具的時間，那還是老老實實開發(fā)個運營工具吧。
上面既然說到運營工具了，那么作為運營工具一定是由運營人員自己來填寫。既然是非技術(shù)人員填寫，操作就難免要傻瓜一點，或者說非技術(shù)一點，盡量操作簡潔，并且可以校驗輸入。如果因為運營人員多打了個空格，活著多寫了個英文逗號系統(tǒng)就掛了，那應(yīng)該算誰不盡責呢？
還有，能分別運營的字段要分別運營，因為有的時候雖然內(nèi)容看上去是合在一起的，但是經(jīng)常會有部分修改的需求，不如分開兩個字段。比如廣告位鏈接和埋點 tag，鏈接可能經(jīng)常換，但固定位置的 tag 值就不會換，所以分開運營會好一些。
運營同學的工作是很辛苦的，設(shè)想一下每天一邊開著 excel ，一邊開著你的運營系統(tǒng)一個字段一個字段填寫的時候，就知道畫面有多美了。所以，運營填寫的數(shù)據(jù)一定是有復用需求的。比如 h5 頁面上運營的數(shù)據(jù)，有可能還需要給原生 app 使用，甚至給 pc 端也用一套數(shù)據(jù)。一個廣告圖片和鏈接，可能被插入到多個頁面的頂部或底部，一起更新。多多溝通復用需求，可以隨手拯救一大波運營妹子。
既然運營妹子這么不容易，那么工作量 KPI 如何衡量呢？這么辛苦再沒人知道不是太慘了？所以，運營的數(shù)據(jù)一般是要有歷史的。
如果就一個坑位，每次都改掉內(nèi)容來更新，上一次的就沒了，那么鬼知道我一天改了多少次？一周做了多少次更新？當然，這里更偏向工具類的需求了，不過我重點要說的是，有運營需求，就可能有運營的歷史記錄需求。
排序需求其實也是內(nèi)容運營需求的一種，無論是運營填寫的還是自動拉取的內(nèi)容，永遠都會有調(diào)整順序的需求。不同的坑位對應(yīng)不同的關(guān)注度，不同的視覺焦點，瀏覽路徑。運營往往需要通過調(diào)整位置或者加些標記來突出某些內(nèi)容。
比如商品列表，可能近期有幾個商品比較好賣，就挪到前面，打上 hot 或者 new 的標記，從而促成更多的銷量。對于排序和打標需求，往往從后臺開始就要預留可擴展字段，到前端也要可以方便的調(diào)整位置和加 icon 標記才行。
對應(yīng)于排序和打標，篩選也是經(jīng)常用到的。比如我搜集了一坨數(shù)據(jù)，又只想挑一部分來展示，這時候往往需要一個可以方便操作的地方，類似帖子加精，評論置頂?shù)鹊?。商品類的?shù)據(jù)篩選需求就更多啦，不過一般可以集成在搜索功能中，作為通用接口提供。但是，運營同學手動填寫的數(shù)據(jù)再進行篩選，那功能就只能業(yè)務(wù)側(cè)自己設(shè)計了，可以根據(jù)需要增加不同的篩選字段供運營同學填寫。
數(shù)據(jù)統(tǒng)計需求是很容易失控的一種需求，產(chǎn)品運營最初往往覺得我要個 PV UV 啥的就夠用了，過幾天可能說能不能統(tǒng)計下這個按鈕的點擊量，再過幾天可能恨不得把所有的操作都埋點，再加上訪問路徑、購買路徑、轉(zhuǎn)化率、蹦失率、頁面停留時間、點擊熱圖、鼠標軌跡。。。再給我出個月度季度報表，趨勢圖等等。
這里，對于數(shù)據(jù)統(tǒng)計需求一定要評審時梳理好，甚至我覺得可以獨立于正常的需求，作為單獨的數(shù)據(jù)統(tǒng)計需求整體梳理后提出。
我實在找不到更貼切的詞匯了。翻舊帳的意思就是，凡事進到我系統(tǒng)里的數(shù)據(jù)，都希望有個方便的形式可以看到。比如用戶創(chuàng)建的 UGC，一定要有個唯一的地址可以看到這個資源。用戶錄入的信息，要有個方便的地方可以導出，或者下載 excel。即使當前的需求不需要你展示歷史記錄或者以前的任何內(nèi)容，也要預留出方便的查詢接口備用。
這個有點詭異，報銷關(guān)我鳥事？當然關(guān)。許多大公司的報銷流程都很嚴格，畢竟是涉及到錢的問題。那么對于涉及到錢的活動來說，唯一的憑據(jù)可能就是你數(shù)據(jù)庫里的數(shù)據(jù)了。所以有關(guān)錢的需求，最好開始就確認好報銷需要哪些內(nèi)容，比如用戶的真實手機等等（確認是真人參與活動，沒有造假），以此來作為最終報銷的憑據(jù)，否則就只能運營同學自己出血了。
當業(yè)務(wù)量穩(wěn)步上升時就會伴隨著擴容的需求，尤其當訪問量驟增的時候，快速擴容就迫在眉睫了。擴容包含很多方面，一些性能方面的問題會在高并發(fā)史迅速凸顯，比如查詢低效，PHP慢速，無靜態(tài)化 web，并發(fā)壓力大等等。
此時關(guān)于性能優(yōu)化的一切知識都可以派上用場了，靜態(tài)化、緩存、查詢優(yōu)化、鎖表等等。而機器擴容也沒那么簡單，除了機器內(nèi)容的復制還有相應(yīng)服務(wù)的批量啟動，定時任務(wù)的執(zhí)行，日志的歸集等等。所以，如果評估時預計業(yè)務(wù)會有爆發(fā)性增長（如微信活動），在資金允許的情況下不妨多準備些機器，總比一發(fā)布就掛了強。
這一點放到了最后，同樣也是最重要的。安全問題包含的范圍非常廣泛，雖然有專業(yè)的同事負責安全以及運維相關(guān)的工作，但是在需求初期如果能稍微做些防范就會避免很多問題。一般的公司都會有個基礎(chǔ)的安全規(guī)范，比如如何防止 XSS, CSRF 攻擊，如何防止 SQL 注入，如何屏蔽腳本攻擊等。
還有一些外部接口需要鑒權(quán)的，有時可能做了基本的鑒權(quán)，確沒有更高級的防護。比如一個人雖然登錄了，可以看到自己的某些資料，但是如果這個登錄的用戶還可以通過相同的接口查看其他人的某些信息，那就是安全問題了。有可能這個信息是存儲在相對獨立的表中，并沒有嚴格掛在這個用戶id下，那么查詢的時候就一定要再檢查一下數(shù)據(jù)和用戶的對應(yīng)關(guān)系。
對于安全需求，普通前后臺開發(fā)人員能做的其實并不多，能按部就班做好這些基礎(chǔ)防護就不容易了。加上公司公共的安全掃描平臺，基本上可以杜絕絕大部分安全問題了。之所以寫到這里單獨列一條，還是希望大家要對安全足夠重視。
綜上所述，絕大部分的隱形需求都是有跡可尋的。然并卵，即便溝通再明確，郵件再確認，改來改去啪啪啪打臉，該做的需求還是要做，所以，節(jié)哀吧。
藍藍設(shè)計的小編 http://m.sillybuy.com