「公司之所以優秀，只不過是那個當下，所有成員都適得其所而已。」
好啦，以上都是廢話，不過與萊德較熟識的朋友都已經知曉，我已經在近期離開了去年進入的 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 ，為何一定要應用在公司的專案呢？
反正只要拿到錢就好，績效就是看這個結果而已，誰管你過程怎麼進行或是怎麼研發的。
這種模式長期下去，對工程師的傷害是非常嚴重的，特別是年輕的工程師。
你把人生中最精華的歲月都花在這上面了，結果自己的專業在市場上競爭還是差強人意，這樣下去真的可以嗎？
我覺得不行。
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 為例）