從事前端開發轉眼已有三個半年頭，個人技術能力提升的同時，業務經驗也逐漸豐富。
回想初入職場，剛拿到設計稿時一臉忐忑，預估排期也不知定多少合適。覺得產品設計的不合理，找產品經理 PK，卻被簡單說服，結果還是栽倒了坑裡。
隨著一個個專案的開發、上線、總結，曾經摔過的坑，化為了自己避坑的方式（雖然還是會掉進新坑），專案推進順暢了許多。在帶動個人開發效率提升的同時，也使專案及合作團隊的成員越發成熟，形成了共贏。
下面就先從前端開發與專案中各個角色成員的合作來談起。
產品經理
產品經理通常是一個專案中，最先接觸的角色。
產品經理一頭對接需求方，一頭對接實施方（設計/開發），將需求轉化為一個個功能點，交給實施方來實現。
作為開發，經常會吐槽產品經理的設計天馬行空、不明所以。出現這種情況的原因，很多時候確實是由於產品經理對於需求的理解不足或畫蛇添足。但大多數情況下，產品經理還是發揮了很重要的作用的。這點，如果經歷過沒有產品經理專案的同學應該會深有感觸：直接的需求方，商務/銷售/老闆等提來的需求，往往需要經過多次的“翻譯”和確認才能真正滿足需求。
印象比較深刻的一次，是公司人事提過來的需求：給員工論壇增加郵件推送的功能。當時 hr 的需求只有一句話：“想要能夠自動推送新帖和熱門帖子，還可以手動指定推薦的帖子，最好能帶圖片。”
從中，需要自己提煉出這樣 3 個需求：
1、自動推送新帖；
2、自動推送熱帖；
3、可選項為推送推薦帖，並且要附上插圖。
提煉了一遍之後，還需要再細化需求，比如熱帖的時間範圍，新帖和熱帖的數量，以及插圖來源和沒有圖的情況等等，這些都需要反覆再跟需求方確認清楚。
由此可見，跟產品經理的對接，其實就是間接對接客戶需求。如果不幸遇到了不靠譜的產品經理，要避免掉進坑裡，就必須自己來幫助產品經理把需求弄清楚。方法也很簡單，就是要多問：“想實現的功能是什麼？”“為什麼要這個功能？”“客戶的需求是什麼？”等等。最後，再把完善的結果落入產品文件裡，“互相留證”。
有時，產品經理還會承擔一部分互動設計師的工作，畫較為詳細的原型稿。這時候，除了確認清楚需求外，最好再梳理個優先順序。因為，一些比較精益求精的產品經理，會強調不少的細節功能，但往往不是來源於客戶真正的需求，或至少優先順序並不高。這時候，如果開發週期有限，可以考慮與產品經理協商，放在下一期迭代再做。
互動/視覺設計師
互動/視覺設計師根據產品經理設計的產品原型，設計並優化互動/細節，完善細節，極大提升了使用者體驗。
通常情況下，設計師對於互動和視覺本身是最專業的，除非你有足夠的事實理論依據，否則沒必要就某一個互動或視覺設計與設計師爭論不休，畢竟專業的人做專業的事。但是，在以下兩點上，作為開發是需要著重關注的：
1、標準的一致性：由於種種原因，如標準規範的缺失、文件的缺失、人員的水平差異、溝通不足等等，會造成同一專案不同頁面、甚至於同一頁面的同一類功能，出現多種互動或者視覺樣式。這不僅會影響開發的效率，本身也會降低使用者體驗。作為開發，尤其是在前端元件化流行的當下，往往會比設計師對互動或視覺規範更熟悉。這時候就需要善於分析，某些功能模組是否類似，是否可以使用同一種元件來實現。一旦判斷可以，就要積極溝通，通常設計師是會願意接受建議的。
2、通用性：這裡的通用性，更多在元件設計中體現。比如，設計師對於不同場景的佈局，可能給出多套尺寸，這時候可以建議，統一採用柵格佈局，並與設計師確定幾套柵格比。這樣一來，就不需要再為不同的場景，專門編寫幾種寬度數值了。
此外，在與設計師、包括產品經理討論某個設計或功能點時，應當先從合理性角度分析，比如對於原始需求是否必要？是否存在過度設計？是否存在功能點的重複？切忌一下子從技術實現角度出發，往往會造成不少的無謂爭論，比如那句經典口頭禪：“這個需求很簡單，怎麼實現我不管”。
只有當一個功能確定是需要的時候，才需要加入專案進度因素。這時候可以考慮或是技術實現困難需要延長開發週期，或是採用某些快捷實現方案，與設計師協商，略微調整設計。
當然，不是所有的專案都配備有互動/視覺設計師。對於沒有設計師的專案，一方面，藉助現有元件的拼裝，基本不需要太多的樣式設計；另一方面，作為前端工程師，理應具備一定審美能力的，尤其是設計並編寫一些互動動畫的能力。所以無論有沒有設計師，都可以在細節上做一些小的“自由發揮”，以提升終端使用者體驗。
後端開發
在目前採用較多的前後端分離模式下，專案有一個很重要的環節，即前後端聯調。
雖然同為開發，但因為關注點的不同，經常也會造成互相傷害的局面。對於前端來說，通常由於以下幾點：
1、介面前端不友好，比如返回值的資料結構巢狀很深，或者需要多次請求後前端組裝資料；
2、前端實現 vs 後端實現，比如分頁、過濾、數值的計算等；
3、規範問題，如介面欄位命名的一致性、是否符合同一命名標準、報錯格式等；
4、缺少詳細的 API 文件說明；
5、後端服務不穩定，或 BUG 太多。
對於這些問題，一方面，可以通過技術手段來解決。比如，構建一套 API 管理系統，按規範定義 API，並且約束 API 開發者必須按照固定格式編寫詳細的文件才能釋出 API；同時，提供測試環境，供後端自測；或是前端部署 BFF 層，合併 API 等等。
另一方面，在遇到分歧時，前端開發者需要堅持幾點原則：
1、後端 API 應儘可能不依賴於特定的前端介面。這不僅有利於 API 的複用性，也可避免前端過重的邏輯影響頁面效能；
2、單點維護原則：有時候，確實有些邏輯或功能，放在前後端來做皆可，比如錯誤提示的翻譯。這時候，秉持在一處維護的原則即可，而不是各自維護一套；
3、使用者優先原則：後端在定義 API 時，更多的會考慮原子性；而前端是直接面對使用者的，需要更多考慮使用者體驗。但不管前端還是後端，最終都是服務於使用者的。所以，對於一些可能會影響使用者體驗的 API，要堅持使用者優先，甚至可以拉上互動/設計同學，來推動問題的解決。
此外，很多時候，前端作為專案路徑的下游，往往比較的被動。這時候，需要學會去化被動為主動。比如，採取一些技術手段，如 mock 資料減少對後端開發進度的依賴。
除了技術手段外，溝通問題的過程中，應該抱著共同尋找解決方案的心態，與後端一起分析問題並找出最佳方案，這樣才有利於專案快速良好地推進。
測試
聯調完成後，通常需要提測，進入專案上線前的測試階段。
進入這一環節，可能會被搞得特別鬱悶：自己認為已經完善了的系統，還是被抓出了不少的 BUG。
如果僅此而已，那其實還好，畢竟是自己的問題。但有時候，依據測試人員的不同，還會遇到很多意外情況。
就我經歷過的測試而言，發現測試人員大致可分為兩類：
1、經驗豐富的測試，能快速定位問題，並且較為準確的指給責任方，此外還會提一些互動或功能優化建議；
2、新手測試，不清楚問題原因，基本都先提給前端，或者對產品設計理解不夠清楚，提一些無效 BUG；
前者還好，除了會提一些你認為是新 Feature 的 BUG 讓你來改；而後者，就需要有足夠的耐心了。
但是，我們可以換個角度來思考。第二種情況的測試，其實更接近真實使用者在使用系統時的場景。與其不耐煩地強調是不是 BUG，不如思考一下，是否這部分的功能設計還需要優化？是不是會給真實使用者帶來困擾？甚至可以主動拉上產品經理，看看是否需要調整產品設計，或是作為需求下期迭代實現。這樣一來，無形中，你就成為了專案優化的推動者。
此外，對於測試提過來的問題，如果發現不是自己的 BUG，也不要簡單地推掉。幫助測試拉相關方一道討論，可以更高效地解決問題。
對待變更
“變更”對於開發者來說是最頭疼不過的一件事了，往往一個看似很小的變更，可能牽扯出很多關聯問題，大大影響開發效率。
然而，現實情況是，無論是需求方、產品經理、互動/視覺設計師，甚至後端開發都可能提出變更。
有些變更“看似”不可避免，比如開發途中收到使用者反饋，希望增加某個功能；
有些變更看似不必要，卻又被強烈堅持，比如上線前，互動設計師覺得某個按鈕位置不合適，需要調整。
很多時候，看似不可避免的需求變更，往往可以在產品設計中來避免，或者採取更好的方式來解決，如放在下一期迭代。看似不必要的功能，也不是說一定不能增加。我認為，關鍵需要做好幾點；
第一，做好變更帶來的影響範圍的評估。對於一些大型的系統，產品設計上的一點小變更，可能會牽一髮而動全身，特別是一些公共模組，比如計費。一些小變更，如果不做好範圍評估，可能對其他模組產生影響，甚至是不可用；
第二，評估好所需時間。通常，一個專案的上線節點是確定的。或者，會嚴格制定提測的時間，測試也會有自己的排期。一旦某一需求點變更，沒有評估好時間，萬一造成了延期，將會對整個專案的進度帶來影響；
第三，要權衡收益與時間。我們不應該刻板堅持說，需求開始已經定好了，這版任何需求變更我都不接受。畢竟，多數的變更，還是從優化產品的角度出發的。如果評估一個變更對上線時間沒有什麼影響，完全可以順手改掉。但如果某個變更，可能是客戶直接要求的，看似非改不可，但修改起來需要大大延長專案週期，這時候就需要做個權衡了，或是調整人力資源，或是調整技術方案。
總之，對待變更，不是一味地拒絕，也不是輕易地接受，需要充分權衡利弊收益，做出合理判斷。
覆盤
“覆盤”一詞最初來源於圍棋比賽，指一局棋局結束後，復演該局，分析整盤的勝負所在。
對於一些大型專案，專案的結束做一下覆盤，可以總結一些問題或經驗，用來提升後續專案的效率。所以，進行復盤是很有必要的。
比如，我接手過一個專案，專案的前期，產品經理提供的文件非常簡潔（只有一頁），但專案邏輯遠比文件描述來的複雜。這導致，整個開發過程中，需要多次跟產品經理溝通確認需求。除此之外，在專案中途，視覺設計師還做了好幾處視覺上的調整，以至於整個專案時間遠比預估來得緊張。
對於這個專案，當時做了一個覆盤。覆盤前，專門統計了一些資料作為依據，比如產品文件變更次數，設計稿變動點的數目等等。在會議中，秉持對事不對人的態度，列舉事實依據指出影響專案效率的原因，並提出優化方案，如產品經理需要在專案開發前，準備好足夠完善的文件；視覺設計師的視覺稿完成後，需要組織評審，儘可能避免在開發後，再做調整。
通過優化方案的沉澱與推進實施，成功確保了後續專案，不再遇到相同的問題，從而提升了效率。
敵人 or 助手
我做的專案是誰的專案？
在我剛開始工作的一段時間，對於接手的專案，我的理解，它們純粹就是一個個任務。我需要考慮的，只是如何用程式碼去實現它們。
但在現在，我會意識到，我最先考慮的，不是如何實現，而是為什麼要做這個專案？具體來說，就是專案的需求本身為了解決什麼問題？能帶來什麼收益？進而思考，產品的設計方案是否滿足需求本身？是否是最佳的方案？是否會造成一些問題？
換言之，在專案中，應當把自己看待成一個專案 owner，而不再僅僅是一個執行者。我的合作方，包括產品經理、設計師、後端開發、測試都是我的助手，幫助我一起把這個專案做好並推動它成功上線。當然，前提是，你需要主動去充分理解並認可這個專案，使它真正成為“我的專案”。
這樣一來，合作中遇到問題時，我會以對於專案積極的方向去努力，而不僅僅滿足於完成自己部分的工作。比如，後端某個介面有問題，除了反饋給後端外，如果根據自己的經驗做個判斷，是不是 API GATEWAY 的問題，或者是不是某個欄位取值不對之類的，可以幫助後端更快解決問題。這不僅有利於專案的整體進度，也能降低一個溝通成本，畢竟如果自己不提供足夠的資訊和建議，可能反而增加了溝通的頻率，對自己的開發效率也會造成影響。
總之，記住一點，合作方不是敵人，是我的助手，我們是為了相同目標，通力合作的夥伴。
成熟業務 vs 初創業務
在我經歷過的所有專案中，既有比較成熟的產品業務，也有初創的產品業務，它們的整個開發過程，還是有比較大的不同的。
對於成熟的產品業務，整個專案流程和角色分工，基本是比較完備的。但是，這並不代表開發過程一定順風順水。因為，一些既定的流程未必得到嚴格執行，或者某個角色專業度不足。這種時候，就需要對照前面提到的，與各個角色合作的方式。
某些情況下，還會存在合作方自身存在一些問題，比如工作態度、負責程度等。這時候，可能就不是靠一己之力可以解決的了，而是需要記錄相關過程，並及時將問題反饋至上級來解決。
相比成熟業務，初創業務往往更關注“速度”。因為初創業務很可能處於市場探索期，需要快速完成產品推廣市場；同時又要及時迭代，滿足客戶各種需求。這種情況下，整個研發流程或是角色分工，不一定會很完備。比如，不一定有專職測試，可能會由產品經理兼職；又或者，不一定有設計師，可能需要我們前端利用現成元件加一點審美能力自由發揮。顯然，這種時候，想要事先制定一個嚴格完備的研發流程，往往不太現實。
那麼如何在這種條件下，確保開發效率呢？我認為，需要做到以下幾點：
第一、藉助技術手段。比如，最常用的 mock 資料，實現前後端開發時間上的解耦。
相比成熟業務，初創業務可能缺少很多基礎設施，這就需要多做一些工程化的工作優化工作流，降低溝通成本。
技術手段還體現在，藉助一些現成的腳手架工具或完善的框架來快速搭建專案，如dva。
第二、需要提高專案管理能力。最基本的一點，是要會評估需求優先順序。
對於前端開發來說，實現的功能中，除了呼叫後端 API 來實現的基本功能外，很大一部分是提升使用者友好度的工作。對於初創業務，這一部分的彈性其實是比較大的。相比成熟業務，初創業務、特別是技術型的初創業務，使用者對體驗上的問題，容忍度相對是比較高的。所以，在專案時間比較緊張的時候，合理評估需求優先順序，合理安排研發時間，對於確保專案如期上線至關重要。
第三、要少抱怨、多建議。
初創業務畢竟要同時面對專案週期緊、規範流程不完備、基礎設施缺乏等不利因素，自然會遇到很多問題。這時候，不能只做問題的發現者，而是儘可能成為問題的解決者，至少也是問題的推動解決者，才有利於整個團隊和專案。
總結
程式設計師經常用搬磚來自嘲，其實軟體工程和土木工程都作為工程，確實有一些可以類比的地方：
如果我只關注我被派到的活本身，比如搬磚、砌磚，一旦整個設計、或某個環節出了差錯，即便我的活做得再好，整個工期還是會受影響，甚至會推倒我砌的完美的牆重新蓋；
如果我把眼光放大，瞭解我砌的牆在整棟樓中起得作用，我可能會發現，這牆設計的不夠厚，我多砌一層，可能就避免了一次返工；
如果把眼光再放大，可能還會發現，磚擺放位置太遠，運磚上花了很多時間；設計圖紙不夠清晰，總是容易看錯...
對於專案開發過程中，或多或少存在流程、人員、規範等等各方面的問題，這時候需要主觀能動性，去打破這些問題，而非選擇無視和忍受。告訴自己，我是要把整個專案做好，而不是僅僅把自己的手頭任務做好，由此一來，遇到相應問題，自然會想辦法推動解決。這樣不僅有利於專案，就個人來說，不也是一種能力的提升嗎？