終於有時間靜心想了一下W3CTech的交流話題，覺得還是寫一點好，之前裕波同學發來話題的時候，一直覺得這是一個太泛泛的話題，但是後來又思考了一下，這的確是一個值得去討論的話題：前端工程師究竟如何去與其他崗位協同作業？
首先，這個話題應該從高中低三個層次去切入，因為所謂的協同作業在不同的公司不同的環境，甚至不同的部門都是有差異的，並不是說公司或者部門有高下之分就要分三個層次去探討，而是我覺得它們之間實在有很大的差異。
低級協作我認為在小型的團隊較多，它的角色劃分很簡單客戶（OR 老板）、設計、前端、後台開發，在這個流水線裡，前端需要與三方的接觸，需要清楚客戶提過來的頁面互動需求，需要知道設計師的設計意圖，需要考慮後台開發的實現接口，這是比較傳統的協作方式，或者也有人叫線性的協作，而其實即便是這種古老的流水線式作業裡，前端仍舊無法高效的工作，具體表現為與客戶的溝通不暢，前端工程師切入的是專業的代碼級的點，而客戶往往關注的最終的效果，與設計師的分離或者脫節，諸如前端抱怨設計對浏覽器的無知，或者設計埋怨前端無法完美還原他們的作品，以及不了解後台架構忽略了頁面在動態狀況下的實現，或者後台開發直接插手前台代碼，等等。在這種協作模式裡，前端是一個處於弱勢的職業角色，而也正因為如此，許多小型公司都基本忽視了這個職位，甚至是設計和前端一人擔當，我覺得要在這種模式裡，協作效率的提升完全取決與前端的個人能力，如你能用深入簡出的話語跟客戶去溝通，你能在設計師抱怨的時候跟他講清楚為何不能實現，你能預留出動態代碼的實現DEMO等等，甚至是你涉獵廣泛可以跟設計師談設計構成可以跟後台開發談後台架構，但是總之，我覺得在這種模式裡效率很難得到保證。
中級協作，相應的這種模式下角色劃分更為細致，如有產品經理介入，有交互設計以及UE參與等等，最關鍵的是前端參與進項目流程，他從項目初始就跟進，從專業的角度來協同各個崗位做好這件事。許多的專業web team大體都會這麼去配置，在這種模式下前端需要的是比較強的專業影響力，從項目開始時就有一個比較清晰的路線圖，在跟進過程中跟每個環節的涉及的人去打交道，把能夠促進這件事完美完成的東西加入到環節中去，如去跟產品經理一起討論最理想的產品架構，跟設計師討論設計中的細節和交互的實現，跟後台開發討論代碼層級的優化等，在這種模式下效率的提升應該來自比較完善的參與機制，如前端在什麼節點介入，介入的深度等等，我認為前端在開始就要介入項目，但不一定要很深入，這樣可以充分了解項目背景，前期應該是與相關崗位的人員一起，共同制訂一個大綱，當枝節理順時就可以進入設計環節，在設計環節裡跟設計一起確定細節的東西，在產出頁面前應該與後台開發就接口做一個提前接入，如給定接口模式之類，最後才是產出頁面，當然這還沒有完，後面還有測試評估以及不斷的版本迭代。
中級協作看似挺完美，但是還是有些遺憾，如這種協作依舊是需要前端工程師的較強的個人能力，無法模式化，我覺得更高級的協作應該是引入前端架構師的角色，關於前端架構師的職能，我覺得簡而言之，他就是一個專門去做這些協作工作的人，以下是引用kejun對前端架構師的職業描述：
1. 他需要制訂一套跟上下游環節更高效配合的技術方案。具體說有改進模板（視圖層）的開發方式，團隊內部開發方式，維護和測試方式等。
2. 他要把關各種技術的實施方案。哪種好，哪種有風險，哪種還不成熟，哪種成本高。需要“把握問題的關鍵，平衡設計”的能力。
3. 他要主動聯合相關部門，從性能、易用性、安全性等方面提升產品的價值和競爭力。
4. 他要正確選擇適合產品的框架和庫（或設計這樣的框架和庫），建立建全規范體系。保證代碼風格的一致性（解決開發效率的問題）。
5. 他要有前瞻性。引入先進的前端技術落地到具體的產品中。
6. 他要負責團隊成員的甄選。
7. 他要能做PPT，向高層布道。
說的比較具體，如果一個團隊存在這麼一個角色，那麼與其他崗位的協作將會是統一和模式化的，前端工程師在架構師的框架裡可以更好的發揮自己的專業技能，當然這是比較理想的狀態，我覺得在現在的狀況下，在團隊中可以培養一些前端工程師的架構思想，嘗試制訂一些協作框架，好的制度永遠勝過個體的強大，只有建立高效的協作機制，才能保證在各種良莠不齊的團隊中協作的高效。