2023年即將過去，回顧總結專案的時候，發現日常工作中一些值得我們思考的地方，這次選了印象比較深刻的京東雲專案，希望本文能對讀者有所幫助，文多圖少，一目百行的客官請輕虐。
由於專案的緊迫性，專案進度基本處於多線並行追趕的狀態，產品、視覺、前端三個線邊輸出邊交接，產品和視覺會把重要的框架性的頁面先輸出給到前端，這樣一來，前端得到的互動文件、視覺稿基本是階段性的，並沒有完整的專案邏輯和專案頁面可以參考來評估專案的構建方案，專案的公用模組、公用元件、元件管理方式等全域性性的內容難以確定，類似這些專案中各種不能確定的資訊，我稱之為『變數』。『變數』會給構建頁面過程帶來很多不可**的問題，這些問題可能會令一部分工作推倒或翻工。
面對這種時間線短、各線並行、存在『變數』的專案，主動獲取專案資訊尤其重要，個人覺得比較重要的有以下幾個：專案整體資訊結構、整體的時間線規劃、視覺稿的具體輸出日期、視覺交接 deadline、前端開發的週期、前端交接 deadline、專案各線對接負責人。
這次專案屬於改版類，從舊版大概了解到站點頻道劃分、頻道之間邏輯關係、業務模組的引用情況等資訊，這次改版產品的邏輯變化不大，主要是視覺的優化。雖然前期視覺給到我們的視覺稿只有站點首頁，頻道的首頁和頻道的內頁都還在並行進行中，但從舊版站點邏輯和產品互動側得到的資訊以及已出的視覺稿可以確定站點哪些部分可以作為公用元件去製作，也可以大致確定專案的資源目錄分布。
對於舊站點常見的元件而在已出視覺稿未體現到的，如側導航彈浮層，找到產品和互動進一步了解後，得知會在頻道首頁和內頁會用到，亦可以確認作為公用元件製作，並可以提前為這些元件製作評估工作量並選擇最佳的實現方案。
整體的時間線規劃、視覺稿的具體輸出日期、視覺交接 deadline、前端開發的週期以及前端交接 deadline，這些資訊都是專案時間維度上的資訊，這類資訊的確認，可以讓我們更準確評估工作量（在時間線內是否可以完成所有工作），從而在專案緊急性方面做好更合理的人力投入。
我們接到新專案，一般都會考慮以上的因素，主動去獲取專案的資訊，這些資訊都是顯而易見的，但有些資訊略顯隱蔽。
拿到設計稿的時候，發現視覺設計師只提供了乙份 1280 解析度的寬屏版，國內解析度使用佔比名列前 5 的 1024 解析度並沒有相容，帶著疑問找到視覺確認，得知首頁會有 1280 解析度和 1024 解析度兩個版本，適配 1024 解析度版本會遲一點給到。
對於這種看似不是問題的問題而前期又可以確認的問題，我是一定要去確認的！這種問題在前期看上去並不會成為專案推進的阻力，但是說不定會在專案後期爆發，對專案造成噸暴擊傷害。
記得剛入行的時候就親身經歷過聯調階段調整解析度相容問題，產品說『我的膝上型電腦首頁出現橫向滾動條了』，然後去排查了一下，發現產品用了 1024 解析度，而視覺給到前端的視覺稿只相容到 1280 解析度，當時缺少實際專案經驗，就默默按照 1280 去做了。當產品找到視覺，視覺回答『立項的時候文件沒有寫到解析度相容情況呀，所以當時只做了寬屏1280了』，最後產品『還是相容一下吧，做乙個窄版適配吧』，再然後視覺和前端就只能『……』。
這種問題兩條線人員很容易懵b『o嘴』，而且最終還是需要重新調整適配 1024 解析度，視覺和前端兩條線都需要額外的工時，而這些工時並不在前期規劃內，所以最有可能會令到視覺或前端或兩者都加班，如果加班在可控的時間內完成的話還算是亡羊補牢，但如果加班後還是影響到專案進展造成專案 delay 的話，那就不是影響視覺和前端兩條工作線工作效率這麼簡單了，這是一種潛在的『變數』，應該如何避免這種『變數』的出現，非常值得我們去思考。
如果前端可以從立項就開始參與和產品、互動、視覺、開發各線大前期溝通的話，每個崗位的同事都可以就各自的專業去衡量評估專案，是不是能更早地去發現一些潛在的『變數』呢？而去執行實現的話是否需要在流程上做出改動？如果因為團隊的合作模式不能實現，作為前端，我們是不是應該更主動去找到各線的同事進行溝通？
當然，這僅僅是針對此情況而去考慮的東西，其實我想提出的是，面對『專案變數』我們需要做的就是盡可能及時掌握更多關於專案的任何資訊去深入了解專案，對專案未來發展作出預見性的判斷從而掌握主動權，而不是靜靜地等待進入前端流程。專案可見度越高，準備越充分，專案主動性越強，只有 100% 的專案資訊確認，才能 kill the 『潛變數』tens of thousands times
。首頁的設計稿包含了很多單色圖示，圖示復用性很強，同乙個圖示出現在不同的模組，而且大小又不一樣，又需要多型並且相容 retina 高清屏。
站在前端角度考慮，pc平台的解決方案，第一時間肯定會想到 iconfont 圖示。iconfont 圖示已不是什麼新鮮的技術，不少同事都在不少專案中都有應用到，可是大家在遇到同一問題使用相同技術的時候，處理方法亦有不同。有的同事可能會自己製作 iconfont 圖示；有的同事可能會讓設計師提供圖示 svg 檔案，利用線上的工具自動生成 iconfont 圖示；有的同事可能會把 iconfont 的生成工具介紹給視覺設計師，讓視覺設計師生成 iconfont 圖示。
站在視覺角度考慮，當然想圖示在所以裝置都可以高畫質呈現。不同的設計師經驗不一樣，有些可能會提供 svg 檔案，有些可能會提供一套1x，2x圖，有些甚至會把 3x 圖也一起給到前端
當專案同時由多人維護的時候，就可能會出現同乙個專案同樣的的技術方案出現不一樣的協作方式，一旦人員交叉交接的時候，就有意思了。從協作效率上來看是存在一定問題的，因此很有必要讓前端和視覺設計師統一一套解決 iconfont 圖示的方案。
首先需要站在視覺方角度讓他們知道問題痛點，再提出解決方案並希望得到他們的協作，下面我以對話的形式將當時我和視覺溝通的對話內容簡單敘述一下（前端：fe，視覺：vd）：
fe：啊巨集，這些單色圖示數量挺多的呀，復用率又高，很多還有雙態，同乙個圖示還有不一樣的尺寸，全部做成的話數量很多哇，即使全部合併成 sprite 圖，的 k 數也會很大呢。最要命的是圖示後續不知道還會有多少種色態會擴充套件，首頁還要求適配高清屏呢，這工作量不是一般的小呀。vd：確實啊，高清屏適配每乙個圖示我都要給乙個 2x 圖你，10個圖示我就得給你 20 個，如果有雙態的話，就得給你40個,這次首頁純色圖示就有50個。。。
fe：嗯，會出人命的，主要這些圖示都是純色圖示，都做成不值得，用 iconfont 圖示可以解決，全向量，還可以用樣式控制尺寸大小和顏色，高清屏、尺寸、配色都不是問題呀，省力省時間呢！
vd：666，那這個 iconfont 圖示要怎麼個搞法啊？我需要做些什麼呢？
fe：只需要把圖示做成 svg 檔案提供給我就 ok 了呀，網上有 svg 轉 iconfont 圖示的服務哈
vd：沒問題呀，如果能解決剛才說的問題
fe：是啊是啊！主要是這樣處理的話可以節省大家的時間，效率成倍提高的啊，不過生成 iconfont 圖示後有些圖示會在 windows 顯示出問題，有問題的圖示需要你用 ai 再處理一下喲，沒問題吧？
vd：沒問題啊，總比切一堆圖好吧，哈哈~~
fe：好的，那麼我們約定好，以後這一類純色圖示我們都統一用 iconfont 圖示處理，由視覺這邊提供圖示的 svg 檔案，然後前端負責生成 iconfont 圖示，我會在組內推一下這個處理 iconfont 的流程，麻煩你在視覺組內也推一下這個方法哈，都統一這麼處理，看ok麼？
vd：好的沒問題~~ 6666 ~~~
痛點定位和效率收益是這次協作成功推動的關鍵點，個人覺得要成功推動乙個方案實施，『痛點』及『收益點』必定是核心點。以上僅僅是乙個簡單的方案推動例子，真正操作起來也不會太困難，但關鍵是我們需要從每次的工作收益中沉澱點『好西』出來就很好了。
好了，以上就是我在京東雲改版專案中對工作流程以及上下線協作中感受比較深的一些思考和總結。其實問題都很常見，也有很多更好的解決方案，但是要將這些問題和解決方案存在的價值轉化出來，還是需要我們做完每一次的專案後認真去總結沉澱，最後，做好業務無非幾個字，想得周全，助得快樂，踩得深入，跳得出來。
專案總結
上次更新：2019-04-20 19:28:31
360影視改版專案總結
在拿到設計需求之後,作為一名設計師,前期的思考是非常重要的,遠比後續的在表現形式上面的思考要重要的多.正確的思路和梳理決定了產品的方向.所以在前期和需求方進行深入的溝通顯得尤為重要,在了解了產品的使用者群體 產品目的 設計所要表達的意義，後續的商業推廣之後,我們針對原型圖進行深入的分析和思考,從專業...
京東專案總結
這週做了京東 的專案。組長分配了我的任務是製作購物車連同搭建購物車的介面。我先搭建了購物車的介面，重新學習了一下搭建頁面時所需要注意的事項，比如在頁面中設定盒子模型，利用div 來實現頁面布局的巢狀，利用css來實現頁碼 的一些必要的格式與樣式設定。還有一些超連線的a標記，可以將超連線的內容超連線到...
官網改版專案問題總結
最近官網改版的任務交給了我，開發使用的是jq操作dom，後台php渲染的方式，如今已經開發完成，現在把一些問題記錄下來，已備忘。2 移動端瀏覽器對video標籤相容不好 這裡有個細節，由於頁面是後台渲染，所以使用者在頁面間跳轉的時候實際是重新整理了頁面，這時候為了利用快取，我們要區分使用者首次載入頁...