2019年4月23日 星期二

[ 教學 ] [ 經驗分享 ] 職場斷捨離的藝術-看到公司有哪些徵兆時,你應該考慮離職?(以 RD 為例)

標籤: ,
Sponsors



「公司之所以優秀,只不過是那個當下,所有成員都適得其所而已。」


根據國師唐綺陽的星象分析,水星已經停止逆行,一切不如意的事情會開始慢慢好轉, 4 月正是脫胎換骨邁向嶄新未來的好時機,而這就是我近期離職的原因(x

好啦,以上都是廢話,不過與萊德較熟識的朋友都已經知曉,我已經在近期離開了去年進入的 App/網站設計接案公司,我也都條理分明的跟他們分享我在業界遇到的情況與問題。

趁著還記憶猶新,留下一些簡單的紀錄,也提供給想離職但卻猶豫不決的讀者一個指標,如果以下的情境大多都有講到你的心坎,那就只欠東風了,拿出你的勇氣邁向全新的生活吧!



此系列文章共有 3 個篇幅,撰寫的主要目的就是幫助社會新鮮人做一個求職上的引導,以萊德自身的經驗與想法做一個鋪陳,期待讀者在面對困難時能不忘初衷,見招拆招,順利找到自己的天職,有任何想法的讀者都歡迎留言交流喔!



【新鮮人求職必讀系列】

1. 給社會新鮮人的面試指南 & 心理建設

2. HR 母湯喔~ 「知道你很優秀,但就是不錄取你」 之 HR 經典語錄大全

3. IT 業面試大補帖 - 工程師的 CV 編排原則與面試考題集錦


【番外篇】

職場斷捨離的藝術-看到公司有哪些徵兆時,你應該考慮離職?(以 RD 為例)





Q1: 你還年輕嗎?

這時候一定要來放一下老王樂隊的「我還年輕 我還年輕」XD



這是我在離職面談中提出最有力的一個理由,同時也能讓面談你的主管幾乎無法慰留你,因為他們大多比你年長,也不年輕了lol

萊德認為,在 30 歲之前不斷的跳槽都是很正常的事情,甚至我會非常鼓勵跟我一樣年輕的朋友這樣做。

年輕,是非常靠譜的本錢,你有相當多時間可以去做各種嘗試,而且大部分都還沒有養育兒女的壓力,可以大膽的追尋自己理想中的工作。

年輕,也同時是一種拉力,企業非常喜歡年輕的新血加入行列,為團隊注入一股新的能量,良好的升遷制度、無拘束的工作環境等等,都可能因為你很年輕而享有,尤其大多新創公司都會拒絕太過資深的應徵者,公司平均年齡在 20 ~ 30 歲的情況下,你會更顯得更有優勢。




再者,現今社會最不缺工作的非「跨領域人才」莫屬,因為他們學習能量與應變能力都很強,能夠及時分析問題並提出相當有創意的解決方案。

你有想過這些跨領域人才從何處來嗎?他們為何能提出這麼多有趣的解決方案?

答案就是「經驗」


當你待過越多公司,你就越容易發現問題所在,當你有機會去處理這個項目時,豐富的「經驗」便是你最大的靠山。

就如同程式設計師應該把共用的方法寫在一起,不要每個 Class 要用同樣的方法都還要重寫一次,或者是盡量避免魔術數字的命名方式,方便日後維護解讀,這些精神與原則也是透過長久以來的「經驗」才慢慢建立起來的。


至於你顧慮太常跳槽會不會導致名聲不好,其實不然,因為年輕只是其中一個理由而已,既然要離職,勢必有精彩的來龍去脈,才會有這個念頭產生。

把你精彩的故事分享給面試官知道,並提出如果是你的話,會端出什麼樣的解決方案,印象分數絕對超乎你想像!

想要年輕人不跳槽,又要他們學會跨領域的技能與思維,我只能說這幾乎不可能,畢竟魚與熊掌不可兼得啊XD



Q2: 現在每天做的事情是你心裡真正想做的?換句話說,你享受這個過程嗎?

最近萊德非常喜歡看 GaryVee 的影片,我覺得他的想法與觀念都是非常值得學習的。



其實要追尋自我很簡單,先從檢視自我開始,像是看看自己有沒有享受在每天的工作就能知一二了。

如果沒有,那為什麼你還允許自己繼續陷在這個泥沼裡?

你待的每一間公司、做的每一份工作、解決的每一個問題,你都應該當作一個跳板,以追求到你當下一直夢寐以求的工作與未來。

或許有一天,你也開始厭倦了當初夢寐以求的工作,那要恭喜你,你是步步高升、蒸蒸日上的,而且是現在進行式,這非常難得。

享受進步的過程、享受當下做事的過程,當你無法從中獲得樂趣時,那可能只代表一件事,該啟程到下一個目標了。

人一生就這麼短,了不起 1 年換 1 間公司好了,世界上公司這麼多,你又能待幾間呢?(笑)

如果你每天工作都過得不開心,那就必須做一點不同的事、改變現有的環境,而不是一直抱怨,抱怨並不能解決你的困境。



Q3: 專案上線後,結果評價很差,責任在誰?

這裡就要談到我離職最主要的原因了,針對這個問題,我認為 RD 也會連帶受到影響,不僅是公司地位,甚至影響到未來職涯的發展。

一般較有規模的客製化設計公司都會有以下職位:

PM / UX / UI/ RD / SA ...等等。


因為不同公司可能會有不一樣的編制,因此以下情境的 PM/UX 都泛指負責定義規格、Function Map、流程規劃、操作行為等等事務的企劃人員。

這邊先不提外部需求的情況,我知道初期不注重使用者體驗的客戶還是大有人在,常常會有不尊重 PM/UX/UI 專業的情況發生,所以僅討論 RD 是按照規格文件完成專案的情況。

舉個情境當例子,假設有一位神人級的 RD 把專案開發完成上線了,也確保迭代版本都沒有發生資料錯誤、閃退或是效能的問題,結果上線後使用體驗差到一個極致,你想會是誰的問題呢?

不用說絕對是 PM/UX 的問題嘛!

因為最初定義規格、頁面、功能、流程、操作的就是他們, UI/RD 只是依照文件設計與開發。

而且身為 RD ,能夠做到完全沒有問題,我認為那已經是不可能的任務了,如果這樣使用體驗還這麼差,照理來說是可以撇得乾乾淨淨才對。

但你要知道,事情絕對不會這麼單純。

首先,公司內部非常有可能不會再把重要的案子交給這位 RD 開發,也就是所謂的「冷凍」,因為他有之前失敗的「前科紀錄」。

但就算公司地位降低,只要有豐富的經驗和優秀的作品,把自己放到市場上應該是相當有競爭力才對。

很遺憾,並不是這麼一回事。

以 App 工程師來說,在公開的商店頁面都有評價,當他把這個「前科」作品放進自己的履歷丟上網路,面試官審閱的時候,難道不會進去商店頁面下載,順便看看評價嗎?

沒錯,面試官並不清楚這位 RD 公司內部的責任歸屬與發生的種種事情,他也不需要知道,他只要曉得這個作品是這位 RD 開發完成並且上架的,而現在評價如何就可以了。

話說到這邊萊德就點到為止就好,我只想問一個問題,這個「前科紀錄」, RD 他會想放在履歷嗎?他敢放嗎?

或者說,他願意放嗎?

我是不願意啦。


不過要知道一件事,無論 PM/UX 的處事態度與方法好壞,組織遇到狀況需要重新編制時,他們永遠是優先被公司考慮留下來的一群人,除非他們的錯誤已經造成公司嚴重損失,否則...你知道的XD

這也是某些公司會不斷流失優秀 UI/RD 等人才的最大主因, UI/RD 這些職位的替代性其實很高,懂得自我要求的美術與程式人員不可能會在同一個地方原地踏步,尤其是那些想要成為 Senior 人才的同事,更是無法在這種有問題的團隊中久留。



Q4: 專案上線後,評價很好,功勞在誰?

說漂亮話,是全體的功勞。

而事實真的是如此嗎?


「一個專案裡面,每個成員所承擔的工作量與付出的心力絕對完全不同。」

但對接案公司的 RD 來說,我認為只會增不會減,除了應付公司 PM/UX/UI 有的沒的要求,還要對外付出龐大的溝通成本,例如與客戶外包的後端溝通等等。

溝通很重要,但統一對外窗口更重要。

然而我在前公司卻被無理要求直接與客戶或內部團隊成員討論,變相是只提交討論結果給 PM , PM 淪為會議紀錄人員,嚴重喪失 PM 這個職位的功用。

Source: 網路梗圖


另一方面,若 PM/UX/UI 的能力等級嚴重不足,受牽連的永遠是 RD 。

個人認為,針對使用者體驗與操作行為這個部分,如果連 RD 這種外行的都看得出來初期規劃一堆問題的話,建議趕快款款欸準備走人。

為什麼呢?

第一,幫助這種團隊對於 RD 完全沒好處,反之,團隊有心人士還會利用 RD 的專業佔盡便宜,也就是所謂的「搶功勞」

將來專案上線後, PM/UX/UI 可以說這個專案是他們規劃/設計的,如果運氣很好,商店頁面評價優良,放在履歷上是多麼耀眼啊。

但有想過這其中 RD 在這專案貢獻的心力嗎?

尤其是 PM/UX 能力等級明顯是嚴重不足,變相要 RD 把文件有問題的地方提出來,才能做出好的設計這種情況,個人實在是不能苟同。

然而,當 RD 在這整個市場的競爭中,在規劃/設計這部分, RD 可是一點功勞都分不到,除非你是兼具 UX 職位的 Senior 工程師,並且自豪自己擁有操控專案走向的權力,否則在面試官眼裡,絕對不會認為你有任何特別的地方,或是知曉這個專案是仰賴你強大的 UX 思維才得以成功。

具備 UX 思維的工程師人才照目前業界來看,真的是稀有動物,企業總是可遇不可求。

這類人才的優勢在於,只要這位工程師的 UX 能力或是商業邏輯夠強大,或許在組織編制上就不需要另外開一個「可能根本沒有實務經驗」的 UX 職位當薪水小偷了。

Source: 愛之味廣告



Q5: 自己犯的錯誤不承擔責任,還怪同事沒有在發現的第一時間就提醒他?

如題,如果你發現團隊成員的心態已經爛成這樣了,真的要趕快逃。

承 Q4 , PM/UX/UI 如果需要一直仰賴 RD 的能力才能做好規劃/設計,甚至搶走 RD 貢獻的功勞,我覺得是一種恥辱,試問這種 PM/UX/UI 的專業度到底在哪裡?

我想是都沒有嚴謹定義規範文件與作業流程 SOP ,如果都有,東缺西缺、甚至喪失系統核心功能的情況也不至於發生。

我遇過更惡劣的情形是,團隊成員自己文件疏漏不承擔責任就算了,還反過來怪發現問題的 RD 怎麼不一開始就提出問題,還提出「 RD 以後應該要在發現問題的第一時間提醒他們」這種無理的要求,WTF?

自己產出的文件品質低落,還怪別人提醒不夠即時?

我完全不能接受這種對待。


但如果和你共事的 PM/UX/UI 依然故我,完全無所謂的樣子,事實上 RD 也無可奈何,要不就是忍氣吞聲、摸摸鼻子繼續做下去,如果要對自己的職涯增添精彩的話,那就找個適當的時機跳槽吧!

Source: https://youtu.be/gwxdh4JX9e4




Q6: 接案公司到底適不適合跑 Scrum ?

如題,依照我過去的經驗來看,我的答案是「非常不適合」


◆ 【敏捷開發的先決條件】

1. 【團隊成員的能力等級皆為高水準】
成員們必須不斷的精進自己的能力, PM/UX 尤其重要,一但這個職位的同事洞察力不足、又欠缺實務經驗,建議最好不要跑敏捷開發,否則會造成共事夥伴的困擾。

2. 【詳盡的文件】
PM/UX/UI 為初期產出文件的人,正式進入開發階段 RD 才會依據這些文件設計 API 與編寫專案技術文件。

3. 【內部規格不能變更】
這是大部分跑 Scrum 流程的團隊時常忽略的點。這裡的規格並非客戶提出的需求,而是 PM/UX/UI 依據需求產出的文件定義「不能變更」


客戶的需求絕對會變,而且可能會很多次,但只要已經簽約,之後的外部規格變更就是 CR ,公司會向客戶收取額外的費用,有錢賺當然修越多次越好啊XD

所謂的內部規格即公司對於產出品質的要求,例如 PM/UX 的規格定義、時程控管、流程規劃、操作行為、頁面資料流向、 Function Map 、空值情況、元件挑選、系統即時性、使用者體驗等等,皆須在文件詳列。

UI 接收 PM/UX 定義好的文件,再進階定義整體視覺、動畫、效果、間距、 RWD 、版面適配、文字大小/顏色/內容、閱讀舒適性、按鈕回饋、元件呈現,此時的文件變成一張張的圖片,在 Sketch 設計之後,可上傳至 Zeplin 等平台,便於 RD 瀏覽與理解。

這些文件/圖片都完成後,就是所謂的內部規格,而「不能變更」的定義就是包括但不限於以上所列的項目。

只要文件沒寫的, RD 就不用做,內部測試也不會出現文件沒定義過的 Bug 」給 RD 修改,更不會有「任意修改文件卻不通知 RD 」等惡劣行為發生。


如果進入開發階段之後, PM/UX/UI 還任意回頭修改文件,代表 PM/UX/UI 其中一方有疏漏,條件 1 和條件 2 明顯不符合,所以才導致內部規格需要變動,當下 Scrum 即宣告失敗。

因為後果用膝蓋想也知道,所有文件又要再修正一次, RD 也可能因為要滿足新的內部規格,做了修正後產生更多 Bug ,尤其是動了流程的部分。

敏捷開發的精神需要能力非常強的團隊支撐,能力等級不足的團隊建議都從瀑布流開始練功,硬跑敏捷開發只是一場災難而已。


至於【理想中敏捷開發的情境】,我想是這樣的:

PM/UX/UI 應該擁有自己部門的文件品質規範與製作 SOP ,就像 RD 通常也有專案命名規則(駝峰式/底線命名、不能用魔術數字等等)、 API 設計格式、 MVC/MVVM 架構、自動化測試、上架 SOP 等規範文件,當所有部門都依照規範與 SOP 運作,品質自然不在話下。

敏捷開發的會議很多,但時間都很短,你有想過為什麼嗎?

代表要「節省內部溝通成本」

外部溝通成本通常難以估計,畢竟服務業都有奧客,接案公司自然也有難搞的客戶,但溝通盡量統一窗口,例如 PM 負責,才不會每位成員都要下去跟客戶溝通消磨太多時間。

外部溝通成本無法全面掌控的情況下,節省內部溝通成本就絕對有其必要性。



◆ 【理想的敏捷開發流程】(以前端設計接案公司為例)

【開發前期】
開會與團隊成員確認客戶需求 => PM/UX/UI 依序產出詳盡的文件定義規格,期間可以詢問 RD 技術上的建議以取得共識 => RD 設計 API 文件 => 根據此專案的功能結構制定內部測試計畫、標準

【開發中期】
開會與 RD 確認 => 確定無誤後即進入開發階段 => RD 依據時程與測試計畫釋出對應的功能/版本提供測試人員進行內部測試,比如現在要開發 A 功能 => A 功能完成後,內部測試皆無誤就可以開發 B 功能,若有產生與文件不符的 Bug 或問題,需立即修正,修正後測試無誤才可以開發 B 功能

在進入 B 功能之前,PM/UX/UI 依序產出詳盡的文件定義規格,期間可以詢問 RD 技術上的建議以取得共識 => B 功能完成後,內部測試皆無誤就可以開發 C 功能,若有產生與文件不符的 Bug 或問題,需立即修正,修正後測試無誤才可以開發 C 功能

反覆上面的循環直到功能與頁面幾乎完成,即進入開發後期。

【開發後期】
若後端許可, RD 可於中後期進行 API 串接工作,因為所有功能與頁面都已經開發得差不多了,只要 API 串接完成即可進行測試 => 依據測試計畫進行最終內部測試 => 因為每一個功能都有內部測試過,理論上最終內部測試不應該發生預料中的 Bug ,可以很快結束測試 => 客戶驗收 => 結案賺錢(灑花)


上面講得如此美好,但現實總是殘酷的。

至於到底會發生哪些不可思議的情境導致 Scrum 失敗呢?你可以參考 Q7 與 Q8 ,就知道為什麼接案公司不適合跑敏捷開發了。



Q7: 以 RD 的角度看敏捷開發流程,如果開發中後期發現使用體驗或是操作流程非常差勁,應該提醒 PM/UX ,甚至客戶?

敏捷開發的精神其實近似於「迭代開發」 PM/UX/UI 的文件固然需要詳細,但不需要一下子把專案整體的細節都詳列得非常清楚。

如果有注意到 Q6 【理想中的開發流程】,應該會發現開發中期 PM/UX/UI 還在編寫文件,甚至可以詢問 RD 的意見,這是為什麼呢?

因為在 RD 開發 A 功能之前, B 功能的文件 PM/UX/UI 根本都還沒定義喔!

也就是說, RD 在開發 A 功能的時候, PM/UX/UI 應該才正要詳列 B 功能的文件,並且可以跟 RD 討論 B 功能的技術建議,很吃驚吧XD

但只要細想,便會發現這其中的奧妙,因為整個專案都拆成「功能面向」的規劃、開發、測試,當 RD 做 A 功能的時候,其實很樂意跟 PM/UX/UI 討論 B 功能的問題,製作期間只要不斷的重複這個流程,案子很快就完成了,而且因為每項功能都有周詳的測試計畫進行內測,品質也同時擁有了。

所以首先,接案公司的簽約都必須提供完整的專案規格書、 Wireframe流程圖、視覺設計稿等等文件給客戶審閱,如果 PM/UX/UI 能力等級不夠高、缺乏洞察力,整體規劃就會產生東缺西缺的情況,事後發現疏漏還要不斷調整,連帶 RD 的開發作業與時程也受到影響。

光這一點就可以知道,如果硬要跑敏捷開發,這要 RD 怎麼做事啊?

當 RD 完成 A 功能, PM/UX/UI 因為自己的疏漏導致文件規格要變動,所以內測時列了 A 功能的 Bug 清單給 RD 修改,這完全違反敏捷開發的流程與原則,還大大增加了內部溝通成本。

這就是所謂的趕鴨子上架,勉強能力不足的人去做能力不及的事,甚至還有時程壓力,你說產能在哪裡?效率又在哪裡呢?



Q8: 以 RD 的角度看敏捷開發流程,是不是時常發生 A 功能或 B 流程已經完成很久、也內部測試過了,但開發中後期卻還在回頭修改的情況?

承 Q7 ,這邊不談論外部客戶需求更改所產生的規格變動,僅討論內部「自己人壓自己人」任意更改需求的情況。

什麼是「自己人壓自己人」

舉些例子便會懂了,包括但不限於:

1. 變動頁面流程

2. 操作行為更改,或是 Android / iOS 要求一致
(如果文件沒定義清楚,使用原生元件大多是不同的行為)

3. 更改文字大小/顏色/內容

4. 更改卡片/按鈕點擊反饋
(變換特定顏色or半透明or內建波紋效果)

5. 更改樣式

6. 更換元件

7. 加入斷線/空值狀態的文案/圖片
(如文件沒有定義清楚,斷線/空值就是呈現空白)

8. Scroll 時 Tab 是否固定在上方

9. Scroll 時元件收合呈現

10. 頁面/元件狀態修改,頁面/元件須依照不同條件有所變化
(例如操作失敗/成功).
.
.
......等等。

阿哩阿雜的隨便列就一堆,而且是在 RD 完成一個頁面/功能後,就有可能產生的修改清單,試問你還願意做嗎?(笑)

Source: 網路梗圖



Q9: 你覺得公司在業界優秀嗎?有沒有未來?

其實這些都可以從公司年度會議中發現端倪,當你發現同事每人平均產值與同業相比落差很大的時候,就要當心了。

以接案公司來說,案源穩定可以減少一半的經營問題,但消化專案的效率奇差無比是絕對要警惕的,代表這個團隊存在著一些弊端或是作業方法不對,才導致專案不斷的 Delay ,應收款項遲遲無法入袋,公司營運狀況陷入危機。

如果方法或是制度可以越改越好,當然是最好,最怕的是團隊中某些成員的思維與能力停滯不前、無法變通、依然故我,特別是主管等級的職位。

公司要留主管絕對可以,但出走的就是那些優秀的 UI/RD 人才,這是必然發生的事情。

至於未來發展性嘛,我老實說,待過一次接案公司就不會想待第二次了,特別是以設計師為主的公司。

因為年輕的工程師待在這種公司,完成的作品並不能代表什麼,甚至你會不敢說這些作品是你開發的,為何會這麼說?

首先影響這些作品的核心人物並不是你,也就是說,這無法成為你的「代表作」

不同的年齡對自我的職涯願景都會不一樣,萊德在這個年齡階段非常看重累積作品的重要性,不論是公司專案或是自己的 Side Project ,這個「代表作」對於工程師來說就非常重要。

對工程師來說,接案公司的性質其實並不適合「代表作」的產生。

有時程壓力先不說,因為自主研發的公司也可能會有這個問題,但先看看接案公司完成的專案,裡面是「工程師自己研發」的技術有哪些?

以我自己接手的專案來看,幾乎沒有。

不是用開源套件,就是一些很簡單的技術應用,哪裡有所謂「自己研發的技術」,但為什麼不做?

沒時間做、也不想在公司專案裡做。

其實你會發現,為了趕時程所做出來的東西價值並不高,更不用說把這個人才丟到市場上會獲得多好的讚譽與機會了。

不想在公司專案做也是必然的,因為接案公司的專案要求都不高,只要沒出什麼嚴重的 Bug ,客戶驗收通過即可,那用什麼技術在專案裡面有差嗎?

再者,工程師絕對可以把專業技術應用在自己的 Side Project ,為何一定要應用在公司的專案呢?

反正只要拿到錢就好,績效就是看這個結果而已,誰管你過程怎麼進行或是怎麼研發的。

這種模式長期下去,對工程師的傷害是非常嚴重的,特別是年輕的工程師。

你把人生中最精華的歲月都花在這上面了,結果自己的專業在市場上競爭還是差強人意,這樣下去真的可以嗎?

我覺得不行。
萊德真的很嚴格(x



Q10: 你比主管優秀,覺得有志難伸?

真心奉勸找個適當的時機 Say Goobye 。

年輕人學習需要有榜樣,而主管就是一個最好的借鏡。

「見賢思齊焉,見不賢而內自省也。」

當你發現主管的好與不好自己都已經吸收差不多,而你的能力又遠超過於他的時候,為了避免日後爭權奪利的問題,甚至升遷在他之上傷了和氣,真的要盡快走為上策。



Q11: 入職到現在,你完成了多少專案,公司有重用你嗎?

如果到目前為止你完成的專案很少,公司給予你的工作項目又都是小案子,你就要衡量你所花費的時間與完成的成果是否符合期待,這邊指的並非公司對你的期望,而是你自我要求的目標

切記,人生只有一次, 20 ~ 30 歲之間所流逝的時間成本,是你一生中最精華的歲月時光,也是可塑性最高的階段。

萊德是這樣想,重不重用有時要看公司領導者的態度,若原本就有較資深的人才擔任重要職務,自然不會希望下屬太過耀眼,此時,個人的心態可能就要調整。

個人得失心如果比較不重的話,在公司安穩待個 2~3 年應該是不會有問題。反之,若是得失心較重,很關切公司營運狀況與個人價值提升速度的話,建議從公司人事物身上學到該有的東西後,便可兩袖清風、不帶走一片雲彩離開。

萊德的個人特質屬於後者,我會時常注意公司的人事物,包括做事態度、任務完成速度與品質,若營運或責任歸屬稍有不對勁,我就會試著找出問題源頭,當我發現無法藉由自身力量改變現況時,就有可能考慮走人。

因為待在一間營運狀況有問題、員工工作效率/產值低落、不賺錢甚至虧損的公司,其實只要設定好自己成長的標準,學會你想學的技能之後,想換到哪裡都可以,運氣好的話,還有機會進入更優秀的公司,年終還能一同共享利潤。

但如果你覺得只要公司有給予保障年薪就很滿足了(例如13個月),那就穩妥地待著吧!

所以這題來說,應該會是見仁見智喔!



Q12: 各部門做事有自己的 SOP 與規範嗎?或是公司的工作模式是屬於隨心所欲的?

以 App 來說,兩大龍頭 Google 與 Apple 都有出「設計規範」,不只是 RD 需要學習, UX/UI 在規劃流程與視覺呈現時,也應該把「設計規範」視為圭臬,所有的頁面都應該遵循「設計規範」以達到良好的使用者體驗。


設計規範要點
https://blog.akanelee.me/posts/235829-design-specifications-points/

Android (Material Design) 設計規範
https://material.io/design/introduction/

Apple 設計規範
https://developer.apple.com/design/tips/

iOS Human Interface Guidelines
https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/


若你待的公司主要開發項目為 App ,但是 UX/UI 成員完全不關心 Google 與 Apple 出的「設計規範」、不知道裡面所傳遞的精神是什麼,設計頁面都是自我感覺良好、單純覺得這樣排版很好看的話,真的要多留意公司交付/發表後所獲得的客戶/用戶回饋。

我敢說,大部分都是負面的評論居多,搞不好根本沒有人會想去使用這種不依照規範開發出來的東西。

「設計規範」之所以可以稱作是「設計規範」,代表大廠都是從大量的統計資料中分析、討論、而且找出了對使用者最友善的介面環境為何。

例如:
1. 一個頁面中,不應該含有 3 種以上的字體大小

2. 字體大小不應小於 12sp/pt

3. UI 配置應盡量對稱(並列項目應為偶數)

4. 並列的按鈕/文字應統一字數

5. Card 並列最多 2 個
.
.
.......等等。

有對使用者友善的項目,當然也有對 RD 友善的項目,例如應有「共用頁面」的設計,其頁面 UI 只是根據 API 或是不同的管道進入而變化,才不會讓工程師浪費時間做一堆類似的頁面功能。

設計規範有很多項目沒錯,但細看會發現,追求「閱讀舒適度」的規範佔大宗,目的只有一個,若使用者看一個頁面看得很辛苦(字體過小)、完全抓不到重點(字體大小過多且錯綜排列,模糊了焦點),何來良好的使用者體驗呢?

一個 UX/UI 如果不去學習設計規範,與其共事真的是一場災難,就算 RD 再精通「設計規範」,也是徒勞無功。

若公司的工作模式又是屬於隨心所欲型的,各部門都無法互相影響做事的方法與品質,甚至高層也沒意識到工作規範的重要性,那我可以很肯定的對你說:

「這種情況只會惡化,塊陶啊~~~」



Q13: 溝通成本過大?每天都在溝通?

「如果溝通過於頻繁,代表團隊成員幾乎沒有流程控管的 SOP 與責任歸屬。」

這個問題不用萊德說,有 30% 左右的開發者也認為這種無效溝通是在浪費時間lol

Stack overflow釋出2019開發者調查結果,3成多開發者認為會議降低生產力https://www.ithome.com.tw/news/129902


解決方法其實也很單純,「定義詳盡的流程就能取代無效率的會議」,換句話說,會議必須要取得成員的共識才有意義,不然幹嘛開會?

假設公司有一套流程規範工作流程、品質,每個成員各司其職,必要時才開會取得共識,就能省下大半的溝通時間啦。

開會前也應該把所有議題與成員遭遇的問題詳列,逐項討論並作出決定,同時所有成員都應該要有個認知,會議中決定好的事項不能隨意更動,否則會破壞作業秩序,也一點都不尊重所有與會同事的時間。

當然,團隊成員都會有磨合期,一開始做事流程卡卡的很正常,但如果超過半年還是老樣子,且公司營運狀況也不是很好的時候,那就趁早打包吧XD



Q14: 如果設計公司回歸只有 PM/UX/UI 職位,程式部分完全外包的工作模式會不會比較好?

就我擔任過設計公司 In-house 的工程師的經驗來看,我覺得 Out-sourcing 的模式對設計師為主的公司更有利,同時公司也應該會對自家設計師的能力素質問題更為重視。

當沒有 In-house 工程師的 Carry , PM/UX/UI 的能力就會被放大檢視,專案成功與否的責任歸屬就相當明確。

因為外包出去都會簽約,好的程式廠商為了賺錢與獲得良好商譽,大多都會產出水準之上的程式專案回來,如果設計公司這邊測試都沒有 Bug ,提供給客戶驗收後上線,使用者體驗的問題就會清楚呈現,設計師想賴也賴不掉。

當然,外包也有遇到雷包廠商的時候啦XD

不過就算外包廠商很雷,責任歸屬還是劃分得非常清楚,究竟是誰的問題一目瞭然,然而, In-house 的工程師卻完全不是這麼一回事。

假如回歸只有 PM/UX/UI 的職位配置,沒有鄉愿、不會搶功勞、設計師對自己的設計好壞負起全部的責任、責任歸屬透明清楚、也同時避免了內部溝通成本的增加(但反過來對程式廠商的外部溝通成本會增加),個人認為這些好處跟 In-house 工程師所產生的問題相比,絕對是利大於弊。


Q15: 如果離職期間,碰巧打聽到來應徵你職位的人是你朋友,該怎麼辦?

BJ4 。

Source: 網路梗圖



◆ 結論:

其實 RD 做了一段時間之後,就會發現下面這兩張截圖是經典中的經典,絕對超過 100 分啊!

Source: 網路梗圖


Source: 網路梗圖


一個團隊裡面什麼樣的人都會有,有的人成長速度快,甚至超越公司,離開公司時跳槽高升。

有的人成長速度一般般,跟著公司穩定成長,待得很快樂。

更有少部分的人停滯不前,變成其他成員的拖油瓶,下場就是成為優先裁員名單中的其中一位。

呼應本文的第一句話:

「公司之所以優秀,只不過是那個當下,所有成員都適得其所而已。」


萊德的自我目標是成為一位具有 UX 思維的 IT 工程師,對自我成長的要求非常高,我尤其會去觀察一個 App 流程上的盲點與疏漏,並試著讓團隊成員們知道我的想法。

但在我目前這個階段來說,我覺得「效率、方法與產出」遠遠比「技術細節」更為重要,程式專案只要學會基本原則,基本上專案都可兼具效能與可讀性,但若沒有好的效率與方法做出產能,我覺得會是徒勞無功。

當你發現過了幾年,自己的薪水行情還是上不去,永遠在那個區間徘徊,就代表你根本沒有核心價值,畢竟現階段程式設計的門檻已經大幅降低,後浪推前浪,後輩的程式功力搞不好還遠遠超過前輩,自己就更應該思考往後要如何發展了。

接著我想平反一下,本篇文章的角度為 RD ,但有沒有可能情況反過來,變成「 PM/UX 遇到了很雷的 UI 或 RD 」呢?

絕對會的。


不過這種情況就沒有像本篇文章有這麼複雜的分析,大多純粹是 UI 或 RD 專業能力不足而已,特別是職業基礎認知的部分, UI/RD 比其他職位更需要時常學習新的事物,提升自己的專業價值,讓自己不落人後才行。


最後,不同的時期,不同的歲數,看待事情的角度、觀點都會有所不同,萊德認為,只要不後悔自己所做的決定,所有選擇都是正確的,因為只有你自己最清楚未來應前往何處。

萊德並不覺得我遇到這些事情對自己有害,相反的,因為我有這些經歷,讓我找到可以解決這些疑難雜症的方法,在往後的職場江湖無往不利,應該是一件好事啊XD

就像我在

HR 母湯喔~ 「知道你很優秀,但就是不錄取你」 之 HR 經典語錄大全

這篇結尾提到的一句話:

「這就是人生嘛,如果一切都一帆風順,豈不是太無趣了呢XD」

萊德如果沒有遇到這些雜七雜八的經歷,這篇「職場斷捨離的藝術」也不會誕生了:P


同樣的概念,我把這些經歷分享給讀者們,希望對你也是一件好事,若當中有哪一個部分講到你的心坎裡,並獲得心靈上的舒壓,那個部分就是我寫這篇長文的價值所在了。



敬祝 工作順利 步步高升



【新鮮人求職必讀系列】

1. 給社會新鮮人的面試指南 & 心理建設

2. HR 母湯喔~ 「知道你很優秀,但就是不錄取你」 之 HR 經典語錄大全

3. IT 業面試大補帖 - 工程師的 CV 編排原則與面試考題集錦


【番外篇】

職場斷捨離的藝術-看到公司有哪些徵兆時,你應該考慮離職?(以 RD 為例)