沒有人是一座孤島，可以自全。每個人都是大陸的一片，整體的一部分 —— 約翰.多恩(John Donne)
作為一個前端開發工程師，我們不是孤軍奮戰，也同樣需要和其他崗位相互協作。在協作的過程中，肯定會遇到一些影響效率的問題，針對這些問題，你們有沒有制定出一系列的提效方案？這就是今天我要給大家分享的內容，我會通過在實際工作中遇到的一些具體問題，闡述下我們的提效方案，我相信這會給你們帶來一些啟發的，特別是初入職場的同學。這點很重要，正所謂工欲善其事，必先利其器。接下來我會按照下面的提綱分別給大家闡述。
- 設計師篇
- 後端研發篇
- 多方合作篇
- 高效協作的意義
設計師篇
設計師是和前端合作最多的崗位之一，分為互動設計師和視覺設計師，也可以稱為前端的“上游”，從下面這張圖也可以看出來。簡單介紹下合作模式，首先互動設計師和視覺設計師按照需求把互動稿和設計圖製作好，和產品確認無誤後再交給前端，最後前端同學拿到互動稿和設計圖後將它們轉換成程式碼。看著合作流程不復雜，但是如果處理不當，很容易暴露一些問題。
前期溝通的重要性
前端同學在開發之前一定要和設計師進行一定的溝通工作，否則很可能會造成後期返工，特別是對於那些比較常見並且涉及面比較廣的影響因素，更要提前去考慮，這點千萬不要指望產品和設計師幫你們想好。這裡我大概列舉了幾點，可以參考下：
- 螢幕解析度
- 相容性
- Windows 系統沒有蘋果字型，可以用
"Microsoft YaHei"也就是“微軟雅黑”替代 - 404 或者 Error 頁面（很多設計師都會忘記這兩個頁面，不知道為啥）
- 針對產品文件裡要製作的動畫，互動設計師能不能提供一些可供參考的 demo 等等
下面我再通過一個螢幕解析度的例子來說明下前期溝通的重要性。記得身邊有個小夥伴接了一個包含切圖的需求，頁面不復雜，小夥子拿到頁面後，二話沒說就開森的開始切頁面了，而且切的很快，三下五除二，沒多長時間設計圖就被轉換成了 HTML 程式碼，活生生的展示到了他的螢幕上。小夥子一臉成就感，非常滿意的把作品拿給產品走查，心想產品絕不會挑出任何毛病的，因為自己是嚴格按照設計圖切的，除非設計圖有問題。小夥子很自信（這一點很值得大家學習），當他正要繼續下面的工作時，產品突然來電說頁面底部咋有個橫向滾動條呢？小夥子迅速地排查了一下，最後定位到是頁面尺寸，也就是螢幕解析度不對，再對比下設計圖，發現設計圖也是這樣子的。和產品解釋了一番，最後產品還是有點兒不滿意，想要改，但是小夥子大概評估了下，說改動量很大。當然最後協商還是沒有改，試想如果產品很強勢非讓改呢，那這個鍋誰來背？又要搞一遍，造成了重複勞動，事倍功半，非常低效。
這個事情，我總結了下，可能是設計師忘記考慮螢幕解析度這個因素，就習慣性地做了個大螢幕解析度的設計圖，而前端同學拿到設計圖後，也沒有去想，上來就直接開始切圖，當然這可能和經驗有關係。不管怎樣，如果他們在前期溝通好，我想完全可以避免這個問題的，所以前期和設計師的溝通非常重要，大家一定要重視起來。
並行協作和減少“請求”次數
在你的工作中，不可避免會遇到一些緊急需求，這裡說的緊急需求指的是有視覺設計師參與的，也就是需要出頁面的，比如電商公司的大促活動、年貨節或者年度賬單，再比如因為最近比較猖狂的新冠肺炎而新增的緊急需求，他們的共性特點就是緊急，倒排，很大可能還需要加班趕工。
對於這類需求或專案，前端該如何和設計師高效協作呢？首先緊急需求最怕阻塞了，試想如果在某個環節一直阻塞下去，那需求肯定不能正常上線，因為上線時間是固定不變的。對於出設計圖也是這樣，前端不可能一直等設計圖全部出完再參與，那該怎麼辦呢？我想大家已經猜到了，就是分批出圖，這樣有兩個好處，首先是保證了出圖的質量，畢竟設計圖出的快很有可能讓質量打折，其次也不耽誤前端的切圖，設計師出一批，前端切一批，並行協作，等前端切完第一批時，設計師已經把第二批出完了，照這樣下去，肯定不會造成前端等設計師的局面，也就是不會出現阻塞的局面，最起碼在設計師和前端這兩個環節中是不會出現阻塞的。
講完了緊急需求需要並行協作，再說下如何尋找設計師，減少“請求”設計師的次數。現實工作中我見過很多同學一有問題就給設計師發訊息，換位思考下，如果你是設計師，你會不會不耐煩？你會不會這樣？
可能設計師當時在忙別的專案，你這樣做也許會打斷他的思路或者排期。這裡面也講究方式方法的，你可以積攢問題到一定的數量之後，再統一找設計師，非常緊急或者影響比較大的例外。這樣當設計師忙完手頭工作之後，會統一處理，節省了大家的時間，何樂而不為？如果怕設計師忘記，可以發郵件做下備忘，總之不要一遇到問題就找人家，特別是初入職場的人，最容易出現這樣的問題了。
元件化
一提到元件化，大家可能會習慣性的想到前端領域裡的元件化，就像下面這張圖。但是這裡我要講的是設計圖的元件化，顧名思義，其實意思都差不多，就是把一些公共模組提取出來，對一些小元件做到心中有數。這樣不僅能讓前端合理劃分樣式，寫出後期好維護的程式碼，也會對設計師自身有很大幫助，比如方便他們更快地組裝一個新頁面，節省他們的時間等等。
接下來我講兩個對立的需求場景，來幫助大家更深入地理解視覺元件化的意義，當然，這兩個需求場景肯定都是帶有切圖工作的。
場景一
記得我剛進廠子不久跟進的一個需求，那個需求共需要設計 6 個頁面，設計師也按時並如數給到了前端。我當時拿到設計圖後，首先做的就是挨個檢視這幾個頁面，然後列舉出來一些公共的內容，比如有多少種按鈕，有多少種可複用的模組等等，目的就是方面編碼時好組織樣式。這些非編碼工作很是耗費時間，但是也不得不做，因為樣式組織不好，開發和後期維護的工作都不會很順利，並且給人的感覺是相當不專業。
場景二
再看看第二個需求場景，頁面個數也差不多，但是設計師給的圖裡不僅有幾個完整的頁面，還新建了一個頁面來放置很多小的元件，比如按鈕有幾類，有多少種尺寸，有多少種顏色，井然有序，一目瞭然，並且還提取了很多可複用的模組，當時看到這些很是開心，於是就給了我們那個設計師一個大大的贊，因為這正是自己想要的，以前都是自己去梳理。從那以後，每次需要出設計圖，我們都會這麼做，因為我們覺得這是一個很好的實踐，既節省了前端的時間，又提高了設計師出頁面的速度。
從這兩個案例可以看出，元件化不僅為自己提效，也會為其他人提效，也就是整個協作團隊效率潛移默化地都得到了提升！
後端研發篇
說完了如何與設計師高效協作，接下來談談與後端研發（後面簡稱“研發”）高效協作的那些事兒。研發也是和前端協作最多的崗位，可以理解為前端的“下游”，主要為前端提供動態資料，也就是介面，涉及到介面，不可避免會有聯調的工作。下面我會分別從不同的階段介紹下我們是怎樣與研發高效協作的。
未雨綢繆，充分準備
正常的，需求評審完，大家聽完產品經理的宣講，就解散回到自己的工位上，各自開始開發了，相信大家都是這個流程。但是這可能還不夠，因為在需求評審階段，畢竟會議時間有限，講的最多的是需求，說的最多的是產品，技術層面比如介面都還沒有討論，這時候如果大家開始開發的話，方向對了還好，如果錯了咋弄，不就造成時間的浪費了嗎？所以建議，在研發和前端聽完需求評審後，或者過個一兩天，再次約會坐在一起討論下技術層面的實現，比如某個需求可能前端實現起來比較方便，也可能讓研發去實現更容易；再比如一些介面的定義等等。
這樣在前期把能確定的技術方案確定下來，能明確分工的提前分好，一些基礎的 API 提前定好，做好充分的準備，避免開發中遇到這樣那樣的問題，期間如果大家對某個需求理解的都不透徹還可以拉上產品童鞋來幫忙。總之需求評審後最好再來次技術評審，這樣大家在開發前做到未雨綢繆，開發過程中就會少走很多不必要的彎路，減少很多不必要的溝通時間！
及時溝通，避免阻塞
當前端完成頁面重構和基本互動後，要進入資料互動開發了，也就是大家所說的調取介面獲取動態資料的環節，此時研發那邊可能還沒有真實的資料，那麼可以讓研發幫忙造些 mock 資料。前端同學要及時找研發溝通，並且主動推動研發造資料，可能他們會忘，也可能他們忙於其他邏輯的開發，最好在排期中體現下什麼時間能把資料造好，前端同學好進入資料互動的開發。記得有一次，在做一個售後申請的需求，售後嘛，只能等下完單才能有記錄，因為預發和生產環境使用的是同一個資料庫，假如要等真實的單子，那非要等上幾天不可，如果是京東物流肯定會快點兒。我們沒有測試伺服器，只能提醒研發造些 mock 資料來開發。當然如果有條件還是希望有個測試伺服器的，資料庫和線上資料庫分開，這樣可以讓研發隨意幫忙新增測試資料，風險也低。
上面這個估計大家都沒有問題，或者說都是按照這個流程走的。再講一個，那就是發版的問題。
大家在開發過程中，不可避免會呼叫研發的服務，這裡大多指的是介面。這些介面可能會有問題，可能還會調整，假如研發要調整介面，肯定需要重啟伺服器，重新發版。由於前端的環境依賴這個伺服器，所以當研發發版時，前端就無法正常開發。我接觸的專案大多都是這樣，可能你們有好的解決方案，如果有可以在底部留言。對於這種研發發版影響前端的場景不可避免，但是儘量還是讓大家有序協作，我們採用的方案是，發版前和發版後在聊天工具中及時通知大家一聲，像這樣。
這樣做的好處是可以讓大家統籌安排自己的時間，避免阻塞，假如伺服器需要半個小時以上才能恢復，就需要郵件告知，其他崗位的同學好靈活安排自己的工作。
巧用工具，事半功倍
測試階段產生的問題原因很多，有的很好定位，比如簡單的前端問題，直接看下控制檯有沒有報錯即可。如果是移動端可以安裝 vConsole 等工具協助，使用方法和 PC 瀏覽器裡的控制檯一模一樣，研發很容易上手，也比較方便幫助前端排查一些問題。下面是 vConsole 的官方 demo 截圖，如果感興趣可以戳連結。
但有時候感覺不是前端的問題，控制檯沒報錯，但是為了提高解決問題的效率，也想排查下是否是介面的問題。很多公司應該都有獨立的介面日誌平臺，當然可能有許可權的控制，如果方便可以讓研發為前端開個許可權，這樣的話前端就可以幫助一起檢視基本的介面問題，比如介面入參錯誤，或者缺少入參等等。
善用 README 檔案
再說一點，很多同學做完需求，上完線就感覺已經萬事大吉，這是不對的。可能下次需求不是你來支援，但是不管是誰來支援，都要做好後期的維護工作。這裡講的維護工作指的是充分利用好 README 檔案，不管是前端還是研發，因為通常大家接手一個專案時，首先看的是這個檔案，最起碼前端是，如果專案中重要的資料（比如介面地址等）沒有在這裡備份，就會造成後面維護人員再花費很多時間去找其他崗位溝通或者是看程式碼，長此以往，就會浪費很多人的時間，這些時間完全是可以避免的，長痛不如短痛，請大家開始重視！這個我是遇到過的，記得當時研發換了新人，但是由於前面的研發沒有做好維護工作，導致新的研發不斷的來找我要各種資料，還好我已在前端專案裡的 README 檔案裡提前做好了備註，將一些資料的詳細地址記錄了下來！
這個很重要，因為據我瞭解，很多公司，特別是大一點兒的公司，開發人員更新很快，根本都沒有沉澱一些東西，導致後來負責維護的同事無從下手。
多方合作篇
這裡講下多方之間的相互協作，不止是設計師和研發。畢竟作為一個前端，不可能只和設計師還有研發協作，前端肯定會看 PRD 的，肯定會參加需求評審的，如果對 PRD 有疑問或者對某個需求理解的不透徹肯定會麻煩產品姐姐來幫忙的；測試更不用說了，現在都是測試驅動上線，測試大拿會給前端提 bug，只有前後端把 bug 都修復完了，測試大拿們才會拍板上線，畢竟他們是最後一道守護神嘛，當然，你可能還會想到這個。
言歸正傳，說下我們在多方協作的過程中遇到的幾個問題和解決方案。
需求要統一，細節要注意
這裡講的需求是指產品的 PRD，試想，如果大家開發或測試時拿到的不是同一份文件，肯定會出現各種問題：
- 研發會返工
- 測試提無效 bug
- 影響整個協作鏈的效率
- 導致非必要的口舌之爭
所以統一大家時時刻刻看到的 PRD 是相當的重要。
記得在做某個需求的時候，已經到了測試的環節，測試大拿給提了幾個 bug，這很正常，但是我在解決的過程中發現，自己寫的邏輯是完全和 PRD 一樣的，也就是說測試大拿提的是無效 bug。當時很開心，就喜歡這樣的，不用改，直接關了就行，而且還光明正大的選擇成無效 bug。等到第二天，收到了幾封郵件，是關於 bug 的，因為我們的 bug 系統已經關聯到了郵箱（通常大家都會這樣做），剛開始以為測試又提了新 bug，但是不經意間發現竟然還是昨天的那幾個，很是疑惑，就去找測試大拿 PK，結果發現我們兩個的 PRD 是不一樣的，有點兒撓頭了...
無奈之下只能去找產品經理，這不找不要緊，一找竟然發現產品的 PRD 和我倆的都不一樣，也就是說這次需求至少有三份不一樣的 PRD，產品經理的是最新的。當時我和測試大拿都快氣瘋了，問了問產品經理，才知道產品經理後來進行了些微調，修改了一些細節，沒有及時同步給大家。
這種情況我想大家都遇到過，畢竟大家都各忙各的，難免會丟三落四。那咋辦呀？想轍唄，首先三方再拉上研發一起核對下最終的 PRD，研發和前端根據最終的 PRD 分別調整下程式碼。然後也是最重要的，如何防微杜漸？最終大家找到了一個解決方案，就是隻維護一份 PRD，可以採用線上的形式，當產品經理改動時，各個崗位可以收到改動的推送通知，像這樣。
如果你們公司有那就最好了，如果沒有的話可以找個開源的，比如語雀，再不行就把 PRD 儲存到某個地方，產品改哪些地方就郵件給大家，並且以不同顏色標註下。總之要讓大家時時刻刻看到的都是同一份 PRD，這樣就不會出現上述問題了，也提高了各方的效率。
精準定位 bug 負責人
測試大拿提 bug，大部分是提給前端和研發，當然也有產品，不過很少。在這些 bug 中，有的是提對了，也有些是提錯了，處理不好那些錯提的 bug 也會影響大家的效率！
記得我們有幾次做需求，前端同事收到了很多 bug，這些 bug，一看就不是前端的問題，比如下面這個報錯資訊。
但是測試同事不知道是該提給誰，他們一致認為，瀏覽器上的報錯都應該提給前端，所以就導致前端同學的 bug 量增加，這不要緊，關鍵是有的還需要前端去排查，去溝通研發修改，這對於前端來說是浪費了時間，幹嘛不直接提給研發呢？特別是新來的測試同學，沒有這方面的經驗。
我們採取的措施是，對於確實不知道該提給前端還是後端的 bug，測試提給產品，讓產品統一去協調和分配，當然有的問題產品憑自己的經驗就知道該分配給誰。這對於比較有經驗的測試大拿來說，可能不算是個事兒，直接知道該提給誰了，但是避免不了有新血液的加入，如果有新人的加入，我們商量的對策是老帶新，讓有經驗的測試大拿為他們培訓一下，這樣大家在協作的時候就不會找錯人，就會很高效。
妙用專案覆盤會
覆盤，原本是一個圍棋術語，也稱“復局”，指對局完畢後，復演該盤棋的記錄，以檢查對局中招法的優劣與得失關鍵。通過覆盤，棋手可以有效地加深對這盤對弈的印象，是提高自身水平的好方法。至於專案覆盤，直白的講，其實就是回顧過去完成的專案，並對一些關鍵事件進行分析，從而從過去的經歷中總結經驗教訓，提煉出規律方法論，為接下來的專案和工作提供有價值的參考。
很多人都感覺開會浪費時間，但是我想說的是，這個會議很有必要，表面上給人的感覺是開會佔用了一些時間，但是它是為了更好的讓大家協作，為了更好的提效，為了節省更多的時間。因為你在開發的過程中不可能一帆風順的，一些小問題可以私下處理，但是總有一些流程中的問題，或者說需要跨部門溝通交流的問題，對於這些問題如果不及時解決，肯定會影響專案或需求的進度，所以說開會是有必要的。
我們會定期進行復盤會，因為會上確實暴露了很多問題，面對這些問題，我們也制定了適合我們的合作規範，在平時的合作過程中，大家都遵守著這些規範，合作起來很順暢。假如沒有這些會議和規範，我想我們每天都是在一盤散沙的工作，正所謂無規矩不成方圓。
當然這還要求大家都有執行力，都去按照這些規範去做事情，不能脫離規範，不能紙上談兵。再者對於剛入職的同事或者說新進入的業務線條來說，規範讓他們很快適應我們的節奏，避免不知道如何下手！
高效協作的意義
高效協作並不意味著每天都緊緊張張的，反而是為了讓每天的工作有條不紊。你可以把它制定成協作的一套規範，有了這套規範，任何專案或需求都可以很高效的被完成。高效協作的方式也不是一成不變的，需要不斷的更新和迭代，但是外變不離其宗，它就是為了提高你的協作效率，讓你有更多的時間去研究自己的專業知識，從而更好的用於生產；同時也能讓你和你的協作夥伴有機會去探索更多更高效的協作方式。現在的社會節奏很快，特別是網際網路，再細點兒是前端，讓我們以不變應萬變，去擁抱這個世界，為自己、為企業、為社會創造更多的價值！
尾聲
到這裡，文章已接近尾聲，但是探索無止境。前端不僅僅要學習很多新知識，工作中的協作也很重要，讓我們引起重視，工作裡多積累，線下多分享！讓我們一起尋找一套通用的高效協作規範，一起攜起手來推進前端行業的發展！我們要與其他崗位深入打成一片，合作的力量是偉大的，正所謂一滴水飄不起紙片，大海上能航行輪船和軍艦；一顆孤樹不頂用，一片樹林擋狂風！我們要與其他崗位高效協作起來，化規範為行動，爭分奪秒，持續創新，只因為我們是一支敢追求高效的團隊，不畏荊棘，勇攀高峰，讓專案和需求來的更猛烈些吧！