謝謝邀請。這問題從合同意義上講應是合同變更，並不違反相關法律法規。從商業意義上講，為使用者提供滿意產品是我們的義務，也是應該的。問題在於兩點，一是頻繁的設計修改可能延誤交貨期;二是修改後的產品價格要發生變化，而這也是雙方合同約定的重要內容。因此在對方改變產品交求時一定不要忘記對合同中上述內容進行修改，並雙方簽證。我個人認為這事如此處理就可以了，僅供參考。

如果你的需求採集不是按照你設計的結構來採集的，甲方需求的改變對你來說就是很麻煩的。

解決這個問題唯一的辦法，就是在產品經理設計的產品結構下采集需求，這樣即使甲方修改需求，產品經理也會知道在哪個節點做相應的改變，不會全部推倒重來。

產品經理的任務就是把抽象變成具體，把想法辦成可以實現。所以產品設計一定要有固定的結構，不然就會很混亂。

這部分主要是甲方要把產品背景、產品形式、市場定位、競爭對手、核心競爭力、目標客戶等等，清晰的提出來，如果自己都不知道做什麼或者由於做不做，就不要先開始產品設計，否則是個坑。

這部分最關鍵的設計使用者的場景，使用者在各個場景的動作和反應預測，已經得到的確認等等，然後，設計產品在各個場景中的功能，列出功能清單，在這個環節中，充分考慮使用者的時間成本、操作成本和選擇成本。

這個部分就是產品經理經常使用的，原型圖、服務藍圖、網站地圖、網頁元素設計等，這部分出來，網站基本就可以進入技術實現的過程了。

這個部分是最表層的設計，也是甲方最關注的部分，可以允許客戶有反覆，這要前面四個層級不變化，這裡的變化都是表面的，不影響大局和專案進度的。

遇到這樣的甲方確實有點頭疼，若你只是乙方的一個執行者，那你的處境就非常尷尬了，首先研發人員是根據你的需求進行開發，頻繁變更需求，降低了團隊的信任度，嚴重影響研發人員的積極性和效率，導致產品規劃混亂、開發週期延長、整體專案不能如期上線。

因此，做甲方需求時要注意一下幾點。

首先，在專案開始之前就必須和甲方確定好需求，並嚴格要求在開發中不進行需求的變更。

若是以上的約定已達成還是如此情況出現，必須請示領導層，並確認產品的短期規劃和長期規劃。

當專案主體框架已經完成或進行到中下旬階段時，在不影響整體產品的長期規劃的前提下，分析變更的需求對當前版本的整體設計框架是否有產生影響，若是設計框架內的需求可以優先開發，框架外的需求可以提前說明作為下個版本最佳化的重點。

若甲方執意要修改，做好與甲方客戶溝通，詳細瞭解他們變更需求的緣由，是否有其他可替代方案來執行，避免實現出來的產品不滿足客戶的預期，並實時與客戶進行溝通確認後，快速出一版原型讓他們體驗，進行階段性驗證，以保證需求不跑偏。

對於甲方客戶，我們在需求評審有必要製作出可互動的高保真原型，若只是流程圖或是單頁面沒有任何互動的原型，視覺上不夠直觀，在評審的時候無法進一步想象更無法暴露出問題來。因此高保真的原型對與甲方客戶來說是也很有必要的。

當然，因需求頻繁變更導致的團隊協調的問題是不可避免的，我們需要跟團隊明確若是不做變更與甲方的合作將會受到影響，甚至影響公司的信譽。只要整個團隊團結一致共同協調解決問題，經得住時間的考驗，才能走得更長久。

總之，在遇到甲方需求變更時，一定要冷靜應對，多溝通避免與甲方客戶產生直接衝突，瞭解他們變更的理由，做好溝通，解決問題才是第一原則。