隨着前端越來越多的被提上日程，用戶對產品的體驗度要求越來越高，產品除了實用的特性還必須滿足方便用，美觀，交互好，人性化等一系列的操作，誰的產品先做到這些，就能獲取用戶的青睞。那麼這樣一來，前端無形當中追加了很多工作量，所以前後端分離是趨勢，不可能要求後臺去很多精力花費在幫我們吧數據和前端的靜態效果以及相關的資源整合上。讓大家分別去做各自擅長的事情。
那麼問題就暴露出來了，當對前後端能力要求、測試要求不一樣多不一樣難得時候，前端就會團隊中處於短板，這在中小公司很常見。因爲優質的前端是稀缺資源。
突出問題一 前端能力不足
問題列表
某些特性化的，有難度的需求做不來代碼的模塊化，可維護性不強
修改ｂｕｇ的能力以及效率有限
分不清楚優化、需求、缺陷、bug不同等級
開發時過於粗糙，不能綜合考慮各種數據情況、操作的容錯性不好
貌似其他職能沒毛病
解決方案
需求走前端部門統一評審，按照難度等級、可實現等級、替代方案處理，不計入基本的開發中普及模塊化開發的基本方式，增強寫註釋、團隊協作的培養
學會自己的妥善分類，對於需求、缺陷等明確分類，參照前端整體分類
基本的培訓，案例分享，在產品不做相關處理的時候，希望前端應該有的基本處理
請問各個其他職能有做好自己的事情麼，是否夠專業，現在只是因爲前端的問題是暴露出來的而已，我們的後臺、設計、產品、測試都無可挑剔嗎。如果真這樣，爲什麼不把前段淘汰或者這些人去更好的公司謀求更好的待遇和發展空間。
突出問題二 需求不明確，測試提需求加優化
首先不可否認，測試可以提一些優化或者特殊的需求，但是如果這個比例遠遠超過了bug本身的比例，那麼這部分就是不合理的，應該從以下幾個角度避免。
產品原型最大程度的明確應該有的產品細節，包括各種數據，數據可能情況，意外情況，用戶交互，交互效果，數據驗證，插件，等等。舉例說明：產品不能說這個地方需要輪播圖，而應該說是這個頁面什麼位置出現多大規格的幾張輪播圖，最多幾張，最少幾張，播放效果如何，有沒有默認圖，跳轉的鏈接是什麼，圖片來源是什麼，什麼格式等。
測試應該有自己基本的測試準則，不要每次都沒有準則，沒有原則的去測試全部的需求，個性化的測試我們要儘量規避，儘量約定統一的規則，儘量參照原型以及需求來進行相關的測試，默認認爲如果符合產品設計的90以上的要求，那麼這輪測試纔是符合產品和開發預期的，而不是直接70以上的測試提的問題都是產品從沒提過的、沒說要做的。
項目經理控制好整個的測試聯調過程，保證基本的缺陷都解決的情況下，儘量在開發週期內完成具體功能模塊完整的上線，對於不能很好的實現的，被砍掉的需求要做到下一版本的迭代，而不是全部列入bug修改中。
測試以及聯調修改過程中沒有周期版本性概念，一直是不間斷的斷續的提問題，而對於所有問題沒有任何規律性，等同於過篩子，期望是整體過一遍功能後，模塊仔細測，保證模塊可用，而不是每個模塊都測點，最後每個都有問題，都不能上。
突出問題三 線上版本bug多，發現就及時改
問題１：爲什麼之前bug的有那麼多，還能上線
問題２：爲什麼那麼多的bug都必須是當天提，當天改的，有這樣嚴重麼
問題３：我們提的bug有沒有規律性，是無意發現的還是必然的，我們是否經常進行大規模的一次產品優化，吧這些納入到開發狀態，而不是一味的不斷續的改問題
問題４：當天問題當天改，能改完麼，改的這些bug誰會記錄，屬於哪個產品版本
突出問題四 前端暴露出來很多分支提交問題
１首要責任在前端２前端做不好，爲什麼不讓有能力的人去做，或者交給他怎麼做
３是不是很多源代碼不是前端寫的也讓前端背鍋
４項目架構不明顯，增加了前端開發修改的難度，建議儘早前後端分離，而不是四不像的結構和合作方式
突出問題五 團隊協作
團隊協作需要有基本的協作常識，互相幫助，怎樣才能讓對方更方便高效的協作，建立基本的規則，如果不能保證各種個性化的要求的，就要給其他職能提供最基本的原則性的支持。
人員角度的互相幫助，責任是要追究的，但是團隊需要互相體諒，共同承擔壓力和責任的，遇到問題要溝通問他，幫他解決問題。只有最上面的人才是boss，可以只關心任務和結果，每個團隊的具體成員都關心的是自己如何去實現，有什麼難度，如果做不到，誰可以幫我；如果做得好，怎麼分享給其他人；如果自己有能力有經驗去幫別人做點事情。
每個職能對於專業能力認識不夠，專業能力不足導致很多後續問題。所以職能主管或者職能培訓是必須的。