談談前端人員在項目中的正確溝通方式

　　做爲一個有點想法的web前端從業人員，是從業人員，在項目中不免會跟不一樣的角色打交道。有讓本身舒服的，也有讓本身難受的；有讓別人舒服的，固然，也有讓別人難受的。咱們固然但願最好的結果是你們都很舒舒服服地把事情作完作好。這便就是本文要探討的地方。 　　

項目中的角色

　　我根據本身經歷的項目，大體分了以下幾個角色。而後站在一個web前端的角度來吐槽一下與其餘角色的種種「軼事」。同時也描繪一下我認爲比較不錯的處理方法。

產品經理

　　我所理解的產品經理是一個爲其餘全部角色服務的「奶媽」。全部問題，均可以找他。不過首先，他是項目之因此開展的起始。我認爲產品經理的職責是：

1. 競品分析。這個很重要。知己知彼，百戰不殆。
2. 需求管理。從各類途徑蒐集需求，而後概括，整理，推敲，合併，刪減。最終轉化成功能。需求管理過程能夠有其餘人一塊兒參與。最好是有一套需求管理系統對需求進行管理，方便你們同步信息。只要能實現需求錄入，需求評論便可。
3. 用戶行爲統計分析。這是產品經理惟一能拿來講服其餘角色的客觀數據。咱們的產品是最終給用戶用的。用戶的使用頻率，使用反饋是最好的論據。好比：產品經理要求web前端把已作好的左側的圖標導航改爲圖標加文字導航，通常狀況下，web前端確定會認爲產品經理又在瞎搞。若是產品經理拿出用戶反饋數據「70%的用戶不清楚這個導航是什麼含義」，那他的要求就更具備說服力了。
4. 巧妙設計。 有時候一些NB的功能不是非要靠技術的。若是能巧妙利用一些被常人忽視的現有特性，而後設計出眼前一亮的功能，會讓產品更富有活力。好比，以前看到一個APP，利用手機通信錄能夠保存大量聯繫人及電話，對一些已經被標識的騷擾電話進行本地標識，從而巧妙的實現未越獄IPHONE手機的黑名單提示功能。
5. 產品設計。這個歸納有點大。其實包含了許多功能，諸如：
   1. 產品流程設計；
   2. 產品具體功能設計；
   3. 產品角色設計；
   4. 原型設計；

設計師

　　設計師這個沒什麼說的，就是在理解產品經理的原型的基礎上，將它美化。固然，說的高大上一些，就是：

1. 用戶體驗設計；
2. 產品風格設計；
3. 視覺風格設計；
4. 導航設計；
5. 品牌包裝設計；
   　
   　　這裏面，和前端有關的，主要就是產品的界面（咱們講的主要仍是web項目，雖然目前互聯網項目還必需要有一個APP，此處略過，之後有機會再聊）。

前端

　　這裏指web前端，若是有APP，也主要指的是H5。前端的產出最終將直接面向用戶。你們可能會認爲，設計師的設計稿也是最終面向用戶啊？可是有誰見過頁面出問題了後，無論是用戶，仍是產品經理，後臺，測試，老闆，有誰去找過設計師？都是第一反應找前端，找前端。做爲一個前端狗，本人深有體會。

後臺

　　給前端提供數據，以及實現產品核心業務的開發人員。前端全部數據都是從後臺而來。 　　

測試

　　測試也分好幾種，

1. 功能測試。以產品經理的PRD和原型爲依據，編寫功能測試用例，逐項測試；
2. 接口測試。我這裏已經假定項目的架構是先後端分離的模式，所以，通常測試也會單獨對後臺提測的接口進行接口測試。
3. 界面測試。不多有項目須要此測試，若是要進行此測試，那恭喜你，大家的產品成熟度已經很高了。作界面自動化測試，最費時，費力，且不必定有效果。目前各大廠有一些方案，無外乎使用phantomjs相似的無界面瀏覽器腳本框架，搭配測試腳本寫的測試用例，進行測試。若是界面頻繁變更，那測試就會累成狗。我以前所經歷的一個項目（或產品？），爲了解決界面頻繁變更對測試腳本的影響。我提出一個方案：讓編寫自動化測試腳本的難度下降，即採用相似DSL（domain specific language 領域描述語言），實現簡單的命令和邏輯，替換掉測試人員用相似excel或測試用例管理系統的人類文本語句。和測試人員一塊兒配合，後來也只是用在了版本發版後的冒煙測試上。　

老闆

　　這個不用說啦，老闆最大，老闆就是最大的用戶。【捂嘴不笑】 　　

如何與產品經理溝通？

1. 前端人員與產品經理溝通的依據就是 原型設計。
2. 老是會遇到一些數據輸入規則不清的狀況，記住，這個時候，在和產品經理溝通清楚之後，必定要求產品經理更新原型設計。不然，過一段時間後，測試拿着原型設計給你的界面測出一堆bug，你就哭吧哭吧不是罪。
3. 在動手前，必定要與產品經理肯定好哪些是不會變的，哪些部分可能後續版本會擴展。固然，產品經理給你打的包票你也最好不要全信，仍是要結合本身對業務的理解，作好未雨綢繆，不然到時候，產品經理哪天跟你說要改動某個徹底沒想到的功能的時候，你再說改動會影響全局，也是沒用的，苦的仍是你本身。

如何與設計師溝通？

1. 前端和設計師溝通的最好方式是樣式規範。這裏的樣式規範不必定是css，只要是設計師能理解的描述標識就行。好比：能夠和設計師約定好，目前按鈕有3種，分別是：btn1，btn2，btn3。設計師每次出設計稿的時候，給按鈕標註：btn1，btn2，btn3。而後到前端這裏，可能就是對應的某個class：btn-main,btn-sub,btn-third.爲了方便設計師設計，在設計師完成了一些基礎控件風格後，能夠整理一套模板控件庫，方便設計師後續套用頁面。
2. 有了前面說的約定。作皮膚，那就是水到渠成的事。
3. 對於一些設計師天馬行空的設計，切記要從技術上進行權衡。若是某個效果的實現難度大於最終體驗效果，最好溝通後，降級處理。若是有明確證據（這裏就是來自前面提到的用戶統計）要求必須實現，那web前端就只能迎難而上。
4. 設計師在設計界面的時候，每每喜歡找最好的界面狀態，而後畫出效果。好比：數據恰好滿一屏，某個側邊欄的寬度恰好夠放一個彈出層。這個時候，當設計稿交到你手上的時候，必定要問一下設計師：沒有數據怎麼辦？寬度不夠怎麼辦？數據太多怎麼辦？這些都是由於設計稿只能展現某一個界面狀態。而實際的產品界面，狀態實在太多，各類條件的組合，最終仍是得由前端來負責梳理清楚。

如何與後臺溝通？

1. 前端與後臺的溝通依據必須是接口設計文檔。之前是用文檔，如今最好的方式，是後臺在設計接口的時候，直接錄入接口管理系統，明確代表某個接口的入參，入參類型，出參，返回錯誤碼。只要發現問題，以接口設計文檔爲準，根本不用和後臺扯皮。
2. 另外，有了接口管理系統，後臺也很方便的對接口進行修改。測試還能夠根據後臺的接口設計定義，對接上接口自動化測試程序。好比：後臺修改了某個入參類型，接口管理系統發出更改事件，測試人員根據類型，決定是否修改測試用例，或補充測試用例，實現高效的自動測試。
3. 有時候前端與後臺常常在爲某個數據處理該有誰來實現而扯皮。好比：前端想要A格式數據，後臺爲了統一，恰恰輸出的是另外一種B格式，這樣每次前端都得再轉一遍。個人見解是：
   1. 若是是數據的格式化，則有後臺給一個數據，由前端負責格式化處理並顯示。好比：時間，後臺統一給一個毫秒值，前端自行決定如何顯示；
   2. 若是是要多種數據，最好後臺統一處理好後，封裝一個新的接口提供。這主要是考慮到前端請求太多，會有性能影響。我以前有一個關於這個問題的解決方案，不必定最好，也算是一種探討吧。github.com/houyhea/blo…
   3. 若是有一些數據處理，邏輯處理是除了web前端，APP也會須要的時候，那麼最好由後臺來統一處理。前端永遠只是一個可視化終端。因此，最好不要把不少核心的邏輯和業務放到前端來作。檢驗是否核心業務的方法其實也很簡單，就是，設想一下，若是把前端拿掉（好比我換一個控制檯做爲終端），整個產品或系統還可否穩定運轉？

如何與測試溝通？

1. 爲了不測試提出一些無效的bug，最好提早參與測試的用例評審（若是有的話）；
2. 在某個功能的實際深刻開發中，全部的修改最後都要要求產品經理更新到PRD以及原型設計裏，不然，測試若是不知道的話，會認爲是bug；
3. 最好不要怕測試的刁難，多想一想，若是測試放水，等上線的時候，用戶半夜再來刁難的時候，你就只有老實拍起來改bug；
4. 有些測試提出的不太靠譜的bug，最好一笑置之。我曾經碰到過一個測試mm提了一個bug，因爲她輸入大量重複字符，且有交替重複，總體產生某一個行傾斜的錯覺。她居然認爲是bug。我只能無語。

如何與老闆溝通？

1. 等一切都作好了，正準備上線的時候，老闆事必躬親的看了一眼：這個版面不對，必須改！此時的你的正確作法是：是的老闆，我也總感受哪裏不對，您一說我就明白了，立馬就改！
2. 老闆纔是你的衣食父母，老闆的話就是聖旨。別笑，由於等你哪天坐上老闆的位置，也會站在前端後面指點江山的。

寫在最後

　　以上都是本身的一些思考和想法，若是你們以爲有不對或更好的想法，均可以一塊兒探討一下。畢竟你們好，纔是真的好嘛。