一直以來,我想希望通過自己的分享,能讓更多的同行有所收獲,特別是有一定基礎,已經到瓶頸的同學,找到一個突破口。當然,我本身的閱歷還太少,這個希望純屬YY,但有目標至少有做事的方向,我也就自顧自的做下去吧。
說回《頁面重構工程師修練功略》,之所以會以這個為題,主要是團隊裡的新同學給我帶來了很多不一樣的想法,開始關注到了“專業化”的話題。
先看看整體的內容:
分為三個大部分:
首先,來看看在工作流程中的“上游”和“下游”。做為一個頁面重構工程師,我們自身的工作之前在 你是一個職業的頁面重構工作者嗎? 和 再讀《你是一個職業的頁面重構工作者嗎?》 中已經有較多的討論,但在整個流程中,頁面重構工程師又可以做些什麼呢?
時常會聽到某某在抱怨“上游“如何如何,的確很多看來“額外”的工作量,是由於“上游“產生的,會產生抱怨很正常,人之常情。但靜下心來,別忘了我們也有“下游”。做為“上游”,你的輸出直接影響了“下游“的工作效率。因此,我們在輸出的時候需要更多的為“下游“的工作提供方便。
記得在一個培訓課上老師講到一個例子,當然當時的主題跟我們今天所講的不同,但例子我覺得蠻有啟發的:“在一個電子商務站點中,為了讓用戶得到更好的體驗,交互設計師在用戶下單後,設計了一個跟蹤發貨情況的區域,將貨單的各個時間結點顯示在上面,包括當前狀態等等,很好的體驗。結果負責開發的同事看了後就說了,這個功能實現的成本太高了,而且這個物流公司是第三方的,我們拿不到相關的數據…… 最後大家討論的結果是,改成一個鏈接,跳到第三方物流公司的訂單查詢系統上,用戶自己去查,頁面只提供一個入口。”又比如模擬下拉菜單的效果跟使用系統下拉菜單所需要的工作量是差很多的,可能上游一個很小的改變,就會給下游帶來很大的修改量——流程中的“蝴蝶效應”。
從重構的這一環來說,能為“下游”提供的方便主要就是代碼方面的內容了,像在代碼中添加合理、充分的注釋,引導下游更快的找到需要的部件、代碼等等;還可以多接觸、了解下游的工作,像學習Javascript等的實現方法,以提高我們輸出的頁面能更容易被實現。
“技術限制”這個詞,對於產品和設計的同學,應該是再熟悉不過了,也是很討厭的一個詞,因為總是因為“技術限制”,需要把原本自己很滿意的作品進行修改,為下游做妥協。甚至有一段時間團隊裡還出現“技術限制產品發展”的一場風波,細節不用展開大家也能想像得到。換個角度來看呢?我很喜歡換個角度來看,常聽學程序的同學說“只有想不到的,沒有實現不了的。”,讓我想起阿基米德的“給我一個支點,我將撬起整個地球。”,那麼,現實中真能找到這個支點嗎?。如果產品一開始就設定得很概念化、理想化,忽略了現實中的環境、條件限制,那麼這個產品必定會實現不了或延長期限的。
在要求“上游“的同學學習了解“下游“的工作外,做為“下游”,我們也很應該為“上游”提供一定的培訓,讓“上游”更加了解我們的工作以及完成工作所需要的幫助。即可減少“上游”輸出實際價值不大的內容,做無用功,也能提供更完整的內容。甚至能從我們的角度提供給“上游”提高效率的方法等。
一樣,從重構的環節來看,能為“上游”提供的幫助,《網頁制作基礎》、《網頁制作流程》、《Photoshop動作制作》等等內容培訓,也許會奇怪為什麼PS的動作會在其中,大部分的設計師對程序並不太感冒,雖然我們對設計不在行,但對於程序化的PS動作,掌握起來還是很快的。那麼,可以幫助設計師完成某一類動作的制作,幫助提高工作效率,也是不錯的方式。
上面是流程中“上、下游”角度的內容,可以概括為一句話: “ 得到下游的信任,信任你的上游! ”。除了上面的內容外,還有一些可以很快提高效率的小Tips:像“發長篇代碼、文本時先保存為txt文件”、“確認問題時給肯定的回復”、“提供對方需要的文本時,給可復制的文本”等等。這些場景中,發送方就是“上游”,接收方就是“下游”。能做的還有很多,需要我們多思考。
做技術工作的同學都很清楚或將會清楚:技術本身並沒有什麼樂趣,真正的樂趣來且使用技術解決某一問題或實現某種功能、效果。換個設計師能懂的話就是:“Photoshop本身並沒有什麼樂趣,真正的樂趣在於使用Photoshop可以實現想要的效果。”從中我明白了一個道理,工作的樂趣是可以自己創造的。樂趣何在?
為你的團隊提供更高效的解決方案,在工作中積累、思考,探索更好的規范、流程、工具、方法等等。分享你的解決方案,最好能在團隊內形成一定的正向競爭,讓你的團隊保持活力。
可能很多同學會“沒自信”,覺得就算團隊裡有這樣的人,也不會是自己。有什麼關系呢?這只是一種方法,讓你工作有樂趣的方法。每個人的興趣點不同,只要是積極向上的,必定會找到樂趣所在。