相信大家在做產(chǎn)品需求時，會出現(xiàn)需求和自己預(yù)想不一樣的情況。為什么會出現(xiàn)這種情況呢？又該如何處理？本篇文章將從前端和后端兩個層面，提出對應(yīng)的解決措施，希望能對你有所幫助。
在工作過程中，我們常常會遇到一種情況：當(dāng)開發(fā)完成開發(fā)任務(wù)，將功能交付測試時，總會發(fā)現(xiàn)有些功能與我們所預(yù)想的不一樣。
或者說提需求的人描述需求的方式與開發(fā)理解需求的方式不一樣，導(dǎo)致需求最終出現(xiàn)偏差。這種情況主要還是由于缺少溝通，對需求評審也不到位。
第二個原因則是需求存在隱藏需求。需求設(shè)計者默認(rèn)很多功能就應(yīng)該存在，所以就沒有在需求文檔上進(jìn)行說明。
如果是有經(jīng)驗的開發(fā)者或者是合作很長時間有默契的開發(fā)者會將你以為的、該有的功能主動加上或者開發(fā)到相關(guān)功能會與產(chǎn)品進(jìn)行確認(rèn)，但是很多開發(fā)者是完全按照需求文檔進(jìn)行開發(fā)。
默認(rèn)是不額外開發(fā)其他功能，到了交付測試的時候才發(fā)現(xiàn)很多你以為該有的功能都沒有。這個責(zé)任肯定在于產(chǎn)品經(jīng)理，但是最大的損失還是在于會打破原有的項目計劃，嚴(yán)重者導(dǎo)致項目交付延期。
本文針對上述第二種，結(jié)合實際工作將常見遺漏的功能點進(jìn)行列舉說明，整篇文章主要從兩個方面進(jìn)行說明，前端、后端。
當(dāng)項目達(dá)到一定的范圍時，產(chǎn)品人員與開發(fā)人員相應(yīng)就會配備很多，人多時很容易造成風(fēng)格不統(tǒng)一的情況。
產(chǎn)品畫原型時在沒有約定的情況下就會完全自己的想法和習(xí)慣進(jìn)行繪制，需求評審時大家又主要關(guān)心功能邏輯，而沒有太在意界面呈現(xiàn)形式。
結(jié)果交付測試時，發(fā)現(xiàn)很多界面風(fēng)格不統(tǒng)一，按鈕放置位置不統(tǒng)一，界面字體與每行字段數(shù)量不一樣等，單個界面看沒有什么問題，但是當(dāng)全局使用整個產(chǎn)品時，會因為這些細(xì)節(jié)導(dǎo)致用戶體驗感非常不好。
當(dāng)界面為非看板界面，或者是數(shù)據(jù)量很大需要分頁的界面，又或者是需要要做各種處理事項的界面。進(jìn)入界面時默認(rèn)不執(zhí)行查詢，而且由用戶設(shè)置查詢條件進(jìn)行查詢。
針對存在大批量數(shù)據(jù)且需要用戶做各種處理事項的界面，如果打開界面就執(zhí)行查詢，就會讓用戶被迫等待幾秒鐘，而這個時間完全是沒有必要的。
所以針對有多個功能的處理界面，在不明確用戶需要做什么操作時，一定不要做默認(rèn)查詢，而是由用戶設(shè)置條件查詢，減少用戶的等待時間，從而提高用戶的辦公效率。
關(guān)于查詢條件一定要說清楚是不是需要模糊查詢和批量查詢，這個看似一個不起眼的功能，其實很多產(chǎn)品和開發(fā)者都會忽略，大多數(shù)時間畫原型寫需求不寫清楚的情況下，都是在測試的界面提出來進(jìn)行優(yōu)化。
所以最好是在繪制原型時就標(biāo)注清楚哪些條件需要模糊，哪些條件需要批量。減少后期的修改成本。
界面增加顯示字段，看似一個簡單的需求，其實也包含了其他隱藏需求，很多時候增加顯示字段是和增加查詢條件、導(dǎo)出字段是綁定到一起的。
業(yè)務(wù)提出的增加顯示字段，你在接收這個需求時，就需要確認(rèn)清楚是否需要增加對應(yīng)字段的查詢條件，以及導(dǎo)出時是否需要增加該字段，大多數(shù)時候增加顯示字段與查詢、導(dǎo)出是一起的，接收需求時就需要確認(rèn)清楚，避免后期多次進(jìn)行修改與系統(tǒng)更新。
設(shè)計某個功能點的時候，一定要綜合考慮業(yè)務(wù)場景，評估對應(yīng)的業(yè)務(wù)量是否到達(dá)一定的量級，是否存在需要系統(tǒng)處理大批量數(shù)據(jù)的情況，如果有則需要考慮系統(tǒng)的處理效率，就需要給開發(fā)提相關(guān)的需求，是否需要使用多線程的方式進(jìn)行處理從而達(dá)到業(yè)務(wù)要求。
千萬不要等到開發(fā)完成后再提此類需求，這種多線程的處理方式不同的開發(fā)模式后續(xù)改造的代價各不相同，在開始開發(fā)時提出，開發(fā)在做整個結(jié)構(gòu)設(shè)計時就會考慮。這樣從頭開始就考慮此種業(yè)務(wù)場景一是比后期在原來的基礎(chǔ)上進(jìn)行修改要更可靠一些，評估開發(fā)時間時也會更準(zhǔn)確。
導(dǎo)入/導(dǎo)出同樣也需要考慮一定量級的操作，如果有，則需要考慮用異步的方式進(jìn)行處理，實時導(dǎo)入/導(dǎo)出會存在前端超時用戶側(cè)無法知曉導(dǎo)入導(dǎo)出的執(zhí)行情況，采用異步的方式進(jìn)行處理；然后提供相應(yīng)的界面進(jìn)行結(jié)果的查詢，異步導(dǎo)入需要查看導(dǎo)入數(shù)據(jù)的校驗結(jié)果，同時也能對數(shù)據(jù)進(jìn)行修改進(jìn)行重新校驗導(dǎo)入；異步導(dǎo)出需要提供一個界面對導(dǎo)出的結(jié)果進(jìn)行下載。
全局考慮哪些功能是核實功能或者說哪些功能后續(xù)可能會引起爭議，梳理出來。然后在開發(fā)時，同步開發(fā)相關(guān)的操作日志，且日志一定要詳細(xì)。
避免后續(xù)功能投入使用后，產(chǎn)生一些非必要的爭議。特別是涉及到金額方面的尤其重要，切記切記。
特別是大的項目，不同的模塊由不同的開發(fā)負(fù)責(zé)，對單據(jù)進(jìn)行更新時由于對全局業(yè)務(wù)不了解，就不會對訂單進(jìn)行加鎖。當(dāng)各模塊業(yè)務(wù)同時發(fā)生時，都對其修改，最后修改提交有先后，就會導(dǎo)致數(shù)據(jù)被覆蓋的問題。
例如線同時修改單據(jù)A，同時修改，修改提交有差異，但修改獲取時間為同一時間，就可能會存在線的最后提交，將線修改的數(shù)據(jù)進(jìn)行還原。
所以當(dāng)業(yè)務(wù)存在同一單據(jù)會存在不同業(yè)務(wù)同時修改時，需要向開發(fā)提出，然后開發(fā)在開發(fā)時無論是加鎖還是將各自的業(yè)務(wù)分開處理，不管哪個方式都需要避免數(shù)據(jù)被修改后覆蓋的情況。以免后續(xù)生產(chǎn)環(huán)境出現(xiàn)問題。
發(fā)現(xiàn)問題就一定要及時處理，開發(fā)的【后續(xù)處理】一般就是后續(xù)遇到了之后再處理，但是后續(xù)遇到了的情況，就是生產(chǎn)上已經(jīng)有了臟數(shù)據(jù)。
極端情況下，會產(chǎn)生一大批的臟數(shù)據(jù)且如果有后續(xù)流程時，會嚴(yán)重影響后續(xù)流程。
所以發(fā)現(xiàn)問題就一定要及時處理，千萬不能隨便忽略，否則就像一顆定時炸彈一下，不知道哪天會爆炸，得不償失。
2）因為工期原因，某些功能就不寫前端界面，只做后臺功能，數(shù)據(jù)由數(shù)據(jù)庫直接導(dǎo)入
這種情況除非工期非常緊張，否則一般情況千萬不能答應(yīng)，本身開發(fā)前端界面，然后前后端聯(lián)調(diào)如果不是太復(fù)雜的界面是不會花費太多時間的。如果答應(yīng)了，則很大程度上，后續(xù)上線后很長一段時間該功能都排不上隊。
因為上線后會優(yōu)先處理線上已產(chǎn)生的的問題，以及用戶提出的重要需求，這種有后端功能無前端的小需求就會無限期的往后延，需要使用時每次都需要找開發(fā)人員后臺導(dǎo)入數(shù)據(jù)，非常麻煩。
原則性的功能千萬不能因為開發(fā)層面說實現(xiàn)復(fù)雜，或者說和開發(fā)溝通比較困難而妥協(xié)，如果妥協(xié)，你就只是解放一時，反而給自己后面留了一個隱患。
除非找到可替代的方案，否則必須要堅持自己的原則，該要的需求一個都不能落。如果相關(guān)的開發(fā)溝通執(zhí)意不做，溝通層面太難交流，那就找相關(guān)的領(lǐng)導(dǎo)協(xié)調(diào)溝通，切勿妥協(xié)。
