網易嚴選交互團隊的管理方式進化史
管理團隊是一個艱鉅的任務，不僅需要管理者的智慧，也需要具備相關的管理知識。本文作者從具體的工作分工、文檔管理分發和人員培養這三個方面出發，分享了網易嚴選交互團隊管理方式的進化，與大家分享。
今早看到一篇大眾點評研發團隊項目管理優化的文章，腦海中一瞬閃現了這幾年帶嚴選交互團隊的工作方法漸變歷程，於是乎想趁熱寫一篇文章。
嚴選交互團隊從2015年至今，一直維持在4人規模，承接的工作包括：移動端/WAP/PC/小程序/部分後台/運營活動/交互規範制定。
2015年開始做嚴選項目，只我一人負責交互，當時帶着設計團隊（嚴選啓動時設計團隊只有5人，還包括1個實習生）。後來我開始專職負責交互工作，2016年才社招到麻譯天同學進入團隊，同年7月2個校招同學翟翼暢和柴蒙入職，從此4人團隊一直合作到現在。
由於工作責任、團隊規模、項目擴展、合作團隊工作方式等變化，我們交互團隊的工作方式也在不斷的調整。所以這篇短文就是簡要的講一下嚴選交互團隊的工作方式漸變過程。
嚴選剛起步時各方人力資源都很吃緊，產品也只有2人，我們先做了PC端，然後馬上出APP的策劃和交互。WAP端的交互按照慣例根據APP的基礎去拓展。無論從社招還是校招，都沒有辦法很快加入新的設計師，所以這個階段只能靠我一人完成所有交互。好在後台部分都是產品都承擔了，因為目的是保證功能如期上線，流程都走通，而且第一版的嚴選功能不算複雜，之前我在做秀品項目時也從0到1做了移動端的交互設計。
2016年2月份，Z同學到嚴選來實習，4月份回學校做畢業設計。嚴選的甄選家項目就是她實習期間完成的。甄選家一直是嚴選一個很有特色的功能，目前一直還在運營着。5月份，M同學通過社招加入。7月份，Z同學和C同學校招入職。此時4人團隊算完成。
為什麼按照4人搭建？當時的思路是傳統的以1人為主設計，圍繞APP，其他人來拓展 PC WAP的功能。所以那時我還是擔着大量的交互設計工作，M來負責拓展PC的功能，C和Z因為經驗較少，所以也通過拓展WAP和做一些相對較小的功能來提升能力。
按照這種方式一段時間後，我發現按照端來分配工作並不合適，原因有3：
所以， 16年Q3結束後，我這邊改變了工作分配方式。將一人一端改為按照業務需求分配，需求負責三端。也就是説一個設計師接到一個需求，如果是涉及多端的，那麼APP/PC/WAP/管理後台（後來還有小程序）都由這個設計師負責，通常還是優先做APP，然後再拓展其他端。
這樣的好處：
至於需求如何分配，我參照了嚴選產品組的分工方式：導購線、營銷線、售後服務、內容、用户等幾個大類。但設計師畢竟人數還是不足，所以一個設計師會有一塊 固定的業務跟進之外，還會分到其他的。比如M負責會員積分、C負責內容線、Z負責售後服務、我負責導購，但是實際上，每個人根據工作配比，我都會分配一些導購的或營銷的需求過去。
我個人投入在設計產出上的精力，從一開始的80%到50%，到現在的20%左右。讓設計師們跟進一塊業務，可以對這塊業務有越來越深的研究，也會從各個角度去思考如何提升業務效益，對比游擊戰式打一槍就換地方，要有意義的多。目前這三位設計師可以説都有獨擋一面的能力了。
下圖為目前嚴選交互組分工圖：
交互文檔的管理方式，這3年間我調整了很多次，也是因為項目和團隊的調整，為了提升效率做了對應的變化，所以這裏重點説一下。
一個人時比較簡單，交互稿完成後，導出HTML，打包上傳到QA平台（一開始還是用QA平台來管理需求和文檔，18年初全部轉為JIRA）。效率低的方面是每次修改要重新導出打包上傳，通知上下游去重新下載，容易出現信息不同步，有時候改幾個字還要再打包上傳也是很惱人的事。
16年初，移動端技術申請了FTP，讓我們一同使用，FTP解決了打包的問題，而且保證鏈接點進去的稿件是最新的。新稿子直接拖到FTP就行，隨時改完隨時更新，效率提升很高，特別感謝技術大大。
因為分工改為按業務線分配，那麼一個APP版本里最多會有4個設計師的稿件，而對下游（視覺、開發、測試）來説，他們希望一個版本的設計稿都在一起。最開始我們按照其他設計師完成後彙總給一個設計師，然後該設計師合併後上傳。
但這種方式效率極其低，造成一個設計師頻繁的去做合併上傳的事。我研究了下AXURE，發現它具有團隊協作（team project）的功能，也就是多人可以功能編輯一個源文件裏的不同頁面，這樣每個設計師只改自己的部分，提交即可，但這個功能和我們使用的FTP有一些協議問題，只支持MAC系統，所以我讓所有設計師申請了MAC。
團隊協作功能我們只針對APP交互稿使用，PC和WAP沒有嚴格的版本定義，所以是按照單個需求去管理分發文檔。
下圖是AXURE創建團隊協作文檔的菜單：
AXURE的團隊協作功能我們使用了僅2年，後期也發現一些問題：
於是，從18年Q4開始，我又讓大家放棄了團隊協作功能，APP的每個功能單獨導出為文件，放入一個版本文件夾，從而減少了很多文檔遷移消耗的時間，而對上下游查看文檔並沒有影響。
其他：
為什麼一直用FTP？杭研以及郵件也有一個文檔管理平台，我也嘗試過，但從文檔的層級和版本管理來説，都不能滿足我們的要求。而我們目前用FTP，管理分發效率最高，同時也做了一些加密處理，安全性也有保證。所以從工作效率角度，我還是繼續使用FTP。
交互文稿的兩個注意點：1 要有更新日誌，從交互評審定稿後，記錄後續增加的修改點 ，同時修改的地方要打時間戳 2 要有需求目的，並不是所有相關人都能去參加交互或更早的產品策劃評審，有些方案定稿後，可能要等很久才進入開發階段，所以要有地方讓相關人員去了解這個需求的價值。
關於人員培養，其實這三年我是精力放的最少的，當然主要原因也是需求太多，大部分時間放在完成需求上。我這邊大概從幾個方面去做人才培養：
新人加入到團隊，需要熟悉工作方式，這裏我指的是交互設計的方式方法。可能你之前用別的軟件做交互稿，但是我這邊使用AXURE，那你也要用這個；閲讀交互稿的規範，保證交互文檔內的樣式一致；閲讀已有的交互稿（不需要全部），去了解業務。這個階段大概1周到2周的時間。但一般來説第2周就要開始做一些需求了。
因為精力有限，關於專業能力的提升，我還是主要通過審核交互文檔時對設計師進行一定的指點，給出設計方法和理念，幾乎沒有去做專門討論設計的會議，除了週會和對外交流會。
這點是我強調和推動組內設計師做的最多的，希望的是大家不要只關注設計本身，也要從其他角度，比如產品、運營、市場、技術、數據等多方面去思考，做出提升業務效益的設計，所以有些需求我們交互也承擔了產品的角色。
通過數據平台、用户反饋，去挖掘需求。每個季度的績效也是要有一定比例根據業務的數據表現來考核。
寫文章和做分享，這兩個雖然是有一點功利性在裏面，因為多少會和每年的CPP評審有點關係。但對設計師個人來説，半強迫式的去花時間思考總結自己的工作和設計，去有機會鍛鍊演講能力，還是有實際意義的。所以組內所有人還是在2年內每人都做了至少實踐者論壇或者一級部門內的分享，都向UEDC月刊投了文章。
這篇文章確實是一時興起寫的，總共花了三四個小時，所以裏面內容比較幹，對我本人來説，是快速的反省了一下這幾年組內的一些管理方式的變化。之後可能根據項目的擴大，也會補充新人，可能從明年開始，我會拿出較多的精力在人才培養上了也説不定。
*以上文章2018年在網易內部論壇發表，今天才拿出來分享。
本文由 @re1937 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。