相信大家在做產品需求時，會出現需求和自己預想不一樣的情況。為什么會出現這種情況呢？又該如何處理？本篇文章將從前端和后端兩個層面，提出對應的解決措施，希望能對你有所幫助。

在工作過程中，我們常常會遇到一種情況：當開發完成開發任務，將功能交付測試時，總會發現有些功能與我們所預想的不一樣。

這種主要有兩種原因：

一是開發理解的需求與我們所提的需求不一樣。

或者說提需求的人描述需求的方式與開發理解需求的方式不一樣，導致需求最終出現偏差。這種情況主要還是由于缺少溝通，對需求評審也不到位。

第二個原因則是需求存在隱藏需求。需求設計者默認很多功能就應該存在，所以就沒有在需求文檔上進行說明。

如果是有經驗的開發者或者是合作很長時間有默契的開發者會將你以為的、該有的功能主動加上或者開發到相關功能會與產品進行確認，但是很多開發者是完全按照需求文檔進行開發。

默認是不額外開發其他功能，到了交付測試的時候才發現很多你以為該有的功能都沒有。這個責任肯定在于產品經理，但是最大的損失還是在于會打破原有的項目計劃，嚴重者導致項目交付延期。

本文針對上述第二種，結合實際工作將常見遺漏的功能點進行列舉說明，整篇文章主要從兩個方面進行說明，前端、后端。

一、前端

1）界面風格統一

當項目達到一定的范圍時，產品人員與開發人員相應就會配備很多，人多時很容易造成風格不統一的情況。

產品畫原型時在沒有約定的情況下就會完全自己的想法和習慣進行繪制，需求評審時大家又主要關心功能邏輯，而沒有太在意界面呈現形式。

結果交付測試時，發現很多界面風格不統一，按鈕放置位置不統一，界面字體與每行字段數量不一樣等，單個界面看沒有什么問題，但是當全局使用整個產品時，會因為這些細節導致用戶體驗感非常不好。

所以在我們做產品設計時：

• 第一從繪制原型開始時就需要進行風格統一，各個產品通知到位，按照統一風格進行繪制。
• 第二從技術層面規范，技術針對全局的界面做統一要求，從兩個方面杜絕出現界面風格不統一的情況。

2）查詢

① 界面的默認查詢

當界面為非看板界面，或者是數據量很大需要分頁的界面，又或者是需要要做各種處理事項的界面。進入界面時默認不執行查詢，而且由用戶設置查詢條件進行查詢。

針對存在大批量數據且需要用戶做各種處理事項的界面，如果打開界面就執行查詢，就會讓用戶被迫等待幾秒鐘，而這個時間完全是沒有必要的。

所以針對有多個功能的處理界面，在不明確用戶需要做什么操作時，一定不要做默認查詢，而是由用戶設置條件查詢，減少用戶的等待時間，從而提高用戶的辦公效率。

② 查詢條件的說明

關于查詢條件一定要說清楚是不是需要模糊查詢和批量查詢，這個看似一個不起眼的功能，其實很多產品和開發者都會忽略，大多數時間畫原型寫需求不寫清楚的情況下，都是在測試的界面提出來進行優化。

所以最好是在繪制原型時就標注清楚哪些條件需要模糊，哪些條件需要批量。減少后期的修改成本。

③ 優化需求時增加字段

界面增加顯示字段，看似一個簡單的需求，其實也包含了其他隱藏需求，很多時候增加顯示字段是和增加查詢條件、導出字段是綁定到一起的。

業務提出的增加顯示字段，你在接收這個需求時，就需要確認清楚是否需要增加對應字段的查詢條件，以及導出時是否需要增加該字段，大多數時候增加顯示字段與查詢、導出是一起的，接收需求時就需要確認清楚，避免后期多次進行修改與系統更新。

二、后端

1）業務場景是否涉及到一定量級的數據操作

設計某個功能點的時候，一定要綜合考慮業務場景，評估對應的業務量是否到達一定的量級，是否存在需要系統處理大批量數據的情況，如果有則需要考慮系統的處理效率，就需要給開發提相關的需求，是否需要使用多線程的方式進行處理從而達到業務要求。

千萬不要等到開發完成后再提此類需求，這種多線程的處理方式不同的開發模式后續改造的代價各不相同，在開始開發時提出，開發在做整個結構設計時就會考慮。這樣從頭開始就考慮此種業務場景一是比后期在原來的基礎上進行修改要更可靠一些，評估開發時間時也會更準確。

導入/導出同樣也需要考慮一定量級的操作，如果有，則需要考慮用異步的方式進行處理，實時導入/導出會存在前端超時用戶側無法知曉導入導出的執行情況，采用異步的方式進行處理；然后提供相應的界面進行結果的查詢，異步導入需要查看導入數據的校驗結果，同時也能對數據進行修改進行重新校驗導入；異步導出需要提供一個界面對導出的結果進行下載。

2）核心功能的日志記錄

全局考慮哪些功能是核實功能或者說哪些功能后續可能會引起爭議，梳理出來。然后在開發時，同步開發相關的操作日志，且日志一定要詳細。

避免后續功能投入使用后，產生一些非必要的爭議。特別是涉及到金額方面的尤其重要，切記切記。

3）不同功能對相同同一單據進行更新

當存在不同的業務場景需要對同一單據進行更新時，產品設計時一定要提出來。

特別是大的項目，不同的模塊由不同的開發負責，對單據進行更新時由于對全局業務不了解，就不會對訂單進行加鎖。當各模塊業務同時發生時，都對其修改，最后修改提交有先后，就會導致數據被覆蓋的問題。

例如線程1、2、3同時修改單據A，同時修改，修改提交有差異，但修改獲取時間為同一時間，就可能會存在線程2的最后提交，將線程1修改的數據進行還原。

所以當業務存在同一單據會存在不同業務同時修改時，需要向開發提出，然后開發在開發時無論是加鎖還是將各自的業務分開處理，不管哪個方式都需要避免數據被修改后覆蓋的情況。以免后續生產環境出現問題。

三、另外開發過程中某些情況盡量進行規避

1）發現問題，認為問題出現概率較小，后續處理

發現問題就一定要及時處理，開發的【后續處理】一般就是后續遇到了之后再處理，但是后續遇到了的情況，就是生產上已經有了臟數據。

極端情況下，會產生一大批的臟數據且如果有后續流程時，會嚴重影響后續流程。

所以發現問題就一定要及時處理，千萬不能隨便忽略，否則就像一顆定時炸彈一下，不知道哪天會爆炸，得不償失。

2）因為工期原因，某些功能就不寫前端界面，只做后臺功能，數據由數據庫直接導入

這種情況除非工期非常緊張，否則一般情況千萬不能答應，本身開發前端界面，然后前后端聯調如果不是太復雜的界面是不會花費太多時間的。如果答應了，則很大程度上，后續上線后很長一段時間該功能都排不上隊。

因為上線后會優先處理線上已產生的的問題，以及用戶提出的重要需求，這種有后端功能無前端的小需求就會無限期的往后延，需要使用時每次都需要找開發人員后臺導入數據，非常麻煩。

所以非緊急壓縮項目時間，此種情況不能同意。

3）某些功能因為實現層面的復雜性，或者和開發溝通上比較費勁就選擇妥協

原則性的功能千萬不能因為開發層面說實現復雜，或者說和開發溝通比較困難而妥協，如果妥協，你就只是解放一時，反而給自己后面留了一個隱患。

除非找到可替代的方案，否則必須要堅持自己的原則，該要的需求一個都不能落。如果相關的開發溝通執意不做，溝通層面太難交流，那就找相關的領導協調溝通，切勿妥協。

以上就是工作中的一些小總結，希望對大家有幫助。