讓協做「飛」起來

沒有人是一座孤島，能夠自全。每一個人都是大陸的一片，總體的一部分 —— 約翰.多恩(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，測試提給產品，讓產品統一去協調和分配，固然有的問題產品憑本身的經驗就知道該分配給誰。這對於比較有經驗的測試大拿來講，可能不算是個事兒，直接知道該提給誰了，可是避免不了有新血液的加入，若是有新人的加入，咱們商量的對策是老帶新，讓有經驗的測試大拿爲他們培訓一下，這樣你們在協做的時候就不會找錯人，就會很高效。

妙用項目覆盤會

覆盤，本來是一個圍棋術語，也稱「復局」，指對局完畢後，復演該盤棋的記錄，以檢查對局中招法的優劣與得失關鍵。經過覆盤，棋手能夠有效地加深對這盤對弈的印象，是提升自身水平的好方法。至於項目覆盤，直白的講，其實就是回顧過去完成的項目，並對一些關鍵事件進行分析，從而從過去的經歷中總結經驗教訓，提煉出規律方法論，爲接下來的項目和工做提供有價值的參考。

不少人都感受開會浪費時間，可是我想說的是，這個會議頗有必要，表面上給人的感受是開會佔用了一些時間，可是它是爲了更好的讓你們協做，爲了更好的提效，爲了節省更多的時間。由於你在開發的過程當中不可能一路順風的，一些小問題能夠私下處理，可是總有一些流程中的問題，或者說須要跨部門溝通交流的問題，對於這些問題若是不及時解決，確定會影響項目或需求的進度，因此說開會是有必要的。

咱們會按期進行復盤會，由於會上確實暴露了不少問題，面對這些問題，咱們也制定了適合咱們的合做規範，在平時的合做過程當中，你們都遵照着這些規範，合做起來很順暢。假如沒有這些會議和規範，我想咱們天天都是在人心渙散的工做，正所謂無規矩不成方圓。

固然這還要求你們都有執行力，都去按照這些規範去作事情，不能脫離規範，不能紙上談兵。再者對於剛入職的同事或者說新進入的業務線條來講，規範讓他們很快適應咱們的節奏，避免不知道如何下手！

高效協做的意義

高效協做並不意味着天天都牢牢張張的，反而是爲了讓天天的工做有條不紊。你能夠把它制定成協做的一套規範，有了這套規範，任何項目或需求均可以很高效的被完成。高效協做的方式也不是一成不變的，須要不斷的更新和迭代，可是外變不離其宗，它就是爲了提升你的協做效率，讓你有更多的時間去研究本身的專業知識，從而更好的用於生產；同時也能讓你和你的協做夥伴有機會去探索更多更高效的協做方式。如今的社會節奏很快，特別是互聯網，再細點兒是前端，讓咱們以不變應萬變，去擁抱這個世界，爲本身、爲企業、爲社會創造更多的價值！

尾聲

到這裏，文章已接近尾聲，可是探索無止境。前端不只僅要學習不少新知識，工做中的協做也很重要，讓咱們引發重視，工做裏多積累，線下多分享！讓咱們一塊兒尋找一套通用的高效協做規範，一塊兒攜起手來推動前端行業的發展！咱們要與其餘崗位深刻打成一片，合做的力量是偉大的，正所謂一滴水飄不起紙片，大海上能航行輪船和軍艦；一顆孤樹不頂用，一片樹林擋狂風！咱們要與其餘崗位高效協做起來，化規範爲行動，爭分奪秒，持續創新，只由於咱們是一支敢追求高效的團隊，不畏荊棘，勇攀高峯，讓項目和需求來的更猛烈些吧！