在需求確認之前產品一般會找研發專案負責人來評估需求的可行性，最後來確認需求，一般ui，產品，技術都會參與。

需求確認之後，就會進行開發了，前端需要等到ui設計圖出來之後進行開發，後端也會根據約定好的 資料格式先返回假資料。

如遇到不一致的情況，最終要依據需求文件來進行溝通！

前端開發根據公司與型別規模不同，各有不同的溝通機制與流程。

但前端開發需要在幾個環節需要重點參與才可能最大化減少衝突。

專案策劃階段

一般公司的需求往往是產品經理提出的，或者也是產品經理整合所有需求提出方案。（當然這裡的軟體外包公司有所區別，我這裡的案例主要講的是品牌公司）。這個環節基本是確定方案及互動思路的，對於任何一個專案，最初的設想非常重要的。

所以這個時候，往往是和產品經理的溝通，需要充分理解產品經理的思路。換句話說，即便是將來有衝突，也有可以對證的說法。

原型過審

產品經理一般把原型做出來之後，會召開原型過審會。（也有人說這個之前會有產品需求文件PRD，但實際上很多公司是沒有這個環節，因為現在每個公司都在講究速度，一般公司基本省了撰寫產品需求文件這個環節，都是直接出原型。）

這個環節裡，非常重要，一旦你有任何疑問需要及時提出來。

搭建架構

一般透過原型之後，技術團隊會開內部會議，這個時候是解決技術內部矛盾非常重要的時刻，先聽後端的想法，遇到問題要把自己的想法表達出來。我們在面對衝突的是，會遇到兩種情況：

1、自己太過於發表自己的看法及想法，忽略別人的想法；2、太過於重視別人的想法，忽略自己的疑問。這兩種情況都會導致後續的衝突產生。

UI稽核

原型確定之後，產品經理會和UI設計師溝通互動關係。UI設計師會開始設計介面，一般設計完成之後提交到藍湖中給大家稽核。這個時候，前端也需要認真看作品的，遇到疑問需要及時和ui設計師及時溝通。

測試階段

這個環節不用說了，一般測試工程師會把問題反饋出來。

總結這麼多，想說的是：

我們在面對衝突時，更重要的思考是怎麼避免衝突。然後才是有了衝突，怎麼權衡。一般來說，在職場中解決問題是首當其衝的事情，所以即便是有衝突也是解決問題。如果是別人的問題，拿出問題點告訴別人。如果是自己的問題，就不要存在衝突，自己認個錯尋求協助完成解決。