相信很多人在職場有過這樣的經驗：

你明明很努力，老闆交代的任務也有完成；但升遷輪不到你、機會輪不到你、好的案子也輪不到你。

有時遇到這些問題，不是你不夠強，而是你還沒有被信任。

就像如果你還沒有追蹤我的部落格；可能是因為我，還沒有給你提供足夠的價值。

如果想用「聽」的，可以觀看 YT 喔 👉

對自我成長、職涯發展、AI 工具感興趣的朋友，歡迎按下訂閱按鈕。

【打破職涯框架 EP1】機會只給被信任的人，而個人品牌決定你會不會被選中 #自媒體 #ai #溝通

至於如何累積信任，就要聊到一個很容易讓人誤會、甚至有點抗拒的議題：個人品牌。

先問你一個問題，聽到「個人品牌」，腦中第一個畫面是什麼？是不是：

要分享觀點、要經營社群、要面對鏡頭。

然後光想就覺得壓力超大，甚至開始陷入自我懷疑：

我又不是什麼大咖、也沒有什麼厲害的本事、主動分享會不會被笑？

但我想講一句很現實、也可能有點刺耳的話：

除了家人跟朋友以外，根本沒人在意你是誰

大家只在乎一件事：「你能不能幫他解決問題？」這道理不管在職場、還是自媒體，都是一樣的。

個人品牌的本質不是包裝，也不是講自己有多厲害；而是市場願不願意相信你，願不願意把機會交給你。

今天這篇文章，我會從「職場」跟「自媒體」兩個視角；把我一路上遇到的困難、挑戰，以及如何跨過去的經驗分享給你。

並說明 AI 可以在哪些環節，幫我們加速並優化品質。

個人品牌不是包裝，是你長期行為的總和

很多人一提到個人品牌，第一個想到的是「自媒體」，但我認為自媒體，只是個人品牌的槓桿。

你可以不做自媒體，但你不可能不做個人品牌。

因為只要你還在職場上班、在社會上做人，就會一直在被評價、被貼標籤。

而個人品牌我最喜歡用四個字定義：「信任資產」。

什麼叫信任資產？

你可以閉上眼睛想一下，當你工作或職涯遇到問題時，腦中會不會浮現一些名字？

然後想想看，你最信任的那幾個人，是不是都有點像？

信得過、好溝通、有實力，出事也不會消失。

而這種信任，不是短時間，或一兩次合作就能建立的。

所以我一直覺得，個人品牌不是包裝，而是長期行為的總和。

你在職場怎麼回覆別人、怎麼交付成果、怎麼面對錯誤、怎麼承擔責任、怎麼溝通協調，這些都在定義你是怎樣的人。

把表達當成技術來訓練

而想要建立「信任資產」，第一步，是讓對方了解你想傳遞的資訊。

但談到溝通表達，很多人會直接雙手一攤，説：「可是我天生就不太會講話啊。」

這點我完全理解，同時相信這也是很多工程師的痛點。我們有專業，但不知道如何用對方懂的方式來表達。

面對問題時，我們不是不懂，而是「講不清楚」；但職場很殘酷：你講不清楚，別人就會覺得你不懂。

但幸好，表達是一種可以被訓練的技術。

我的方式是把「說不清楚」的東西，先嘗試用文字「寫得清楚」。

比如執行專案的時候，我會把「答不出來的問題、做出決策的原因、會議最終的結論」用文字記錄下來。

這麼做有兩個好處：

1. 訓練大腦彙整混亂的資訊
2. 執行的每項任務都有明確依據

而且把想法整理成文字的過程，會刺激大腦二次思考。

很多原本想不明白的問題，可能在記錄成文件的時候就想通了；而有些一開始覺得沒問題的設計，也可能在這時越想越不對勁。

如果你有能力在出事前把問題拿出來討論，並給予調整的方向建議，相信同事也會對你的細心與專業給予肯定。

而你所撰寫的這些文件，也是在幫助團隊對齊彼此的認知，增加合作過程的信任感。

我在維持「紀錄」的習慣一年後，也從原本跟客戶討論會結巴，到後來可以自信從容的表達觀點。

因為紀錄這件事，除了幫我瞭解如何表達自己的想法外，

也讓我對專案有更深入的瞭解，因此討論的過程會更有自信，不會總是給出模稜兩可的答案。

很多時候不是我們做不到，只是練習的次數跟時間不夠。

用 AI 提升效率，而不是取代思考

前面提到的紀錄與表達，在 AI 時代變得更容易了。

以這篇文章來說，我就是開啟 ChatGPT 的聽寫功能；分幾段說出自己初步的想法，然後請他幫我重新組織語言。

但提醒一下大家，雖然 AI 很方便，但你需要靠自己把資訊內化；如果不了解背後的知識體系，你講出來的話是沒有底氣的。

另外如果公司允許，我非常推薦 NotebookLM 這款工具。

只要匯入文件，你就可以用白話文的方式搜尋、彙整自己想查的資料，甚至可以把筆記本共享給同事使用。

有時工作效率低，不是不努力，而是大家都在靠記憶找資料；但把專案文件、會議紀錄、產品規格匯入 NotebookLM 後，找資料這件事就不是靠記憶，而是靠「查詢」。

甚至查詢到的資料還有來源參考，可以讓你再次核實資訊的正確性。

雖然 NotebookLM 功能很強大，但它不會把垃圾變黃金。

他的回應品質取決於你提供的來源品質，如果你給他一堆沒結論、沒日期、沒有結構的文件；那他也只能回傳看起來很像解答，但沒有參考價值的廢話。

我們都知道 AI 很強大，但並不是每個人都有使用 AI 的意願；因為很多工作，即使不用 AI 也可以做下去。

甚至剛開始使用 AI 的時候，你還會發現工作效率下降了。

因此，如果你能找到適合團隊導入 AI 的方式。並透過內部分享，減少大家摸索的時間、解決現有工作流程上的痛點，你也可以快速得到大家信任。

我們在職場遇到的問題，都是強化個人品牌的機會。

被看見才有機會，用成績證明自己

「被看見才有機會」這句話不僅適用於職場，在自媒體更是如此。

這裡的「被看見」不是要你迎合上司或追逐流量，而是把自己的價值，包裝成別人看得懂、用得上的形式。

以職場來說，我的做法是把原本只寫給自己看的筆記，整理成給大家看的文件。

而這件事所造成的後果，就是我手上的工作變多：

• 因為開發文件是我訂的，所以跨部門協作要對齊資訊時，大家都會找我。
• 因為專案的文件是我寫的，所以我要上台 Demo 產品，報告給長官與其他部門的同仁聽。
• 因為技術文件是我寫的，所以新進同仁的教育訓練，自然也落到了我的頭上。

剛好印證了一句話：

只要你肯吃苦，未來就會有吃不完的苦。

但我也因為跨部門溝通、建立文件制度、Demo 產品、新人教育訓練這些任務，獲得大量被看見的機會：

• 這才讓我在部門重組時，有機會歷練到專案經理與技術主管的職位。
• 並讓我有足夠的籌碼，能透過談判獲得超過 40% 的內部調薪。

而自媒體的本質也一樣，但執行難度比職場更高。

很多人說自己懷才不遇，如果你想要證明自己的價值，最快的方法就是把自己丟到市場接受考驗。

有沒有料自己說了不算，要由市場來判斷。

我是從 2020 年開始經營自媒體，當時挑選 Medium 這個平台來分享技術文章。

剛開始的時候我還很天真，想說：「我寫得這麼用心，應該很多人會看吧。」

但很抱歉，我當年寫的十幾篇文章，沒有流量、沒有留言。

我也不怕丟臉，直接把當年的慘狀貼給大家看：

很多人不敢經營自媒體，是害怕講錯話、或遇到酸民。

但我跟你說件更殘酷的事：「其實你的作品，連被看見的機會都沒有。」

所以我開始思考：「要怎麼讓對的人看見我？」

於是我選擇去參加 iThome 鐵人賽，這是一個要連續 30 天發表技術文章的比賽。

會做出這個決策是，是因為：

1. 平台自帶流量，而且受眾以工程師為主，與我的文章屬性契合。
2. 得獎就出書，畢竟江湖在走，頭銜要有。

我也很幸運第一次參賽就得獎、出書。

這個經驗讓我第一次感受到：「工作不等於職涯」

如果只待在公司，你的價值是由主管、同事決定。

但如果有作品、經過市場考驗，你的談判籌碼會完全不一樣。

有了作家的頭銜後，我在面試求職可以談到比以往更高的薪水；甚至收到多家平台的合作邀約，進而讓我多了講師與專欄作家的身份。

講到這邊，你會發現：「職場跟自媒體的底層邏輯是一樣的」

被看見，才有機會。

觀眾注意力轉移，自媒體也要轉型

這是我經營自媒體的第五年，拍 YouTube 的第一年。

會踏出這一步，不是我想改變；而是因為觀眾的注意力轉移了。

以前遇到問題、想學新東西，你會用 Google 搜尋。

但現在不一樣了，我們遇到問題第一件事不是打開 Google，而是打開 ChatGPT、Gemini。

以前要東拼西湊才能獲得的解答，現在用 AI 透過簡單的對話，不到 10 秒就能獲得客製化的建議。

從部落格的後台來看，瀏覽量相比於過去已經少了 70%：

會有這樣的結果我並不意外，因為我現在遇到問題、執行任務，大部分也都是先問 AI。

既然自己的行為改變了，那就代表過去寫部落格經營自媒體的方式，正在被時代淘汰。

所以我開始反思，我把任務交給 AI，也很少使用搜尋引擎；那我多出來的時間跑去幹嘛了？

喔～原來我跑去看 YouTube 了 XD

所以我這才開了「工程師下班有約」的頻道，嘗試用影音的方式分享觀點

一開始也不知道怎麼拍影片，所以我選擇模仿平常會看的一些頻道風格；其中我最喜歡的是郝旭烈，郝哥的風格

雖然他的影片很樸素，但因為有深度見解，而且聲音的節奏舒服，所以我可以無壓力的一直看下去。

有了參考的榜樣後，我的起步非常簡單。只有為了收音買一個麥克風，目前發表的影片是直接用手機拍攝的。

會做出這個決策，是因為我很清楚觀眾如果來看我的影片；並不是因為我的外表，而是因為我分享了他們期待的知識、觀點。

既然如此，那我不如把化妝、場地佈置這些前置作業的時間，拿去優化我想分享的知識。

這樣做，反而更有機會吸引到與我有相同理念的觀眾。

平庸的內容不會有任何回報

在 AI 時代來臨後，寫文章與拍影片已經沒有門檻了。

這代表如果你只能做出 60 分的內容，那什麼都得不到；但如果有本事做出 90 分的品質，反而能得到贏家通吃的結果。

因為 AI 時代，市場不缺內容，所以：

• 60 分：直接被滑掉
• 70 分：勉強看個開頭
• 80 分：開始有人願意停下來
• 90 分：才可能被收藏、分享

有個名詞叫做 Superlinear Returns，中文翻譯為超線性回報。你的品質一但越過那條線，回報會瞬間暴增。

有時我們會在社群上看到一些創作者鼓勵大家日更；但老實講，對普通人來說日更只會讓你很忙，但不一定會讓你變強。

AI 只是讓產出變簡單，但好的內容，從過去到現在都不容易

它是需要底蘊的，而底蘊不是你看了幾篇文章就能擁有；你需要親自去執行、了解裡面的痛點、解決過實際的問題，你才有辦法把一個複雜的議題，在有限的時間講清楚。

我鼓勵大家每天學習新知、練習表達；但如果沒有足夠的底蘊，也許周更或是雙周更會更合適。

另外，追蹤的成長與更新頻率關係不大。

會按下追蹤，是因為你的內容給他帶來價值；但如果持續更新低品質的的內容，對方也可能因為不符期望而取消追蹤。

自媒體是槓桿，而槓桿會放大一切

自媒體本質上是一種槓桿，它可以把你有限的時間放大。

像我上一隻影片累積到現在的觀看時數，已經超過 7000 小時；以一天工作 8 小時來算，他已經幫我工作了八百多天。

但你也要記得：

槓桿除了放大優勢，也會放大缺點。

觸及的人越多，你一定會聽到一些批評的聲音。只要不是纯粹的惡意批評，我是很樂意回覆的，因為它讓我認知到自己的不足。

但有些留言毫無建設，只有存粹的惡意；像是批評你的外表、對你人身攻擊。

一開始我收到惡意留言時也很生氣，但收多了之後，我反而覺得遇到酸民，從某種角度來看也是種好事，因為代表你被更多人看見了。

最後我想聊聊本職工作，對經營自媒體的重要性

如果你有穩定的本職收入，那你的內容會有較高的道德底線。可以不靠恐懼行銷、不靠誇大標題、不靠騙人來吸引流量，你可以在自己認同的道路上慢慢成長。

但如果你的本業就是自媒體，那就代表收入來源不穩定

人一旦缺錢，什麼事都做得出來。

很多人會走歪，就是因為他們需要流量、需要變現、需要立刻看到成果，最後變成自己當初討厭的那個人。

如果你真的打算專職做自媒體，我的建議是：

自媒體收入要穩定超過本業的 1.5 倍，連續一年以上。

不然不要急著辭職。

自媒體是槓桿，你可以用槓桿放大自己；但不要把自己逼到「只能靠槓桿活下去」。

沒有白走的路，每一步都有意義

在影片的最後，我想把「個人品牌」的價值濃縮成三句話：

1. 品牌不是包裝，是長期行為的總和
2. 被看見不是運氣，是別人願意為內容停下腳步
3. 信任不是嘴上說說，而是看你怎麼做

另外如果你有經營自媒體的打算，可以先尋找幾個 Role Model，也就是榜樣。

相信大家社群媒體都有追蹤一些 KOL，你可以先從裡面挑出幾個喜歡的風格，然後請 AI 分析內容架構，然後嘗試把架構套用到自己打算分享的資訊上。

這會比自己像是無頭蒼蠅，不知道如何開始有更好的起點。

但 AI 生成出來的結果，你一定要自己檢查過一遍，是否有錯誤的地方。

我建議大家可以從頭到尾念一遍，如果唸起來卡卡的，那通常就是有問題需要優化。

透過這樣的流程，你很快就能發表自己的第一個作品。

至於個人風格這塊，他會在你持續經營的過程中，自然而然的產生。

輕鬆的路，人人都能走；困難的路，才有挑戰的價值。

今天的故事就分享到這邊，如果有給你啟發與幫助，可以順手按個讚，把文章分享給需要的朋友。

未來我會持續分享自我成長、職涯發展、AI 工具的主題文章。

如果今天的分享有給你啟發與幫助

別忘了按讚、訂閱，並把影片分享給需要的朋友。

剛好這次聚餐的話題跟職涯規劃有關，內容適合對目前工作感到迷茫的人（也許），所以就把他寫成一篇部落格跟大家分享。

小提醒：世界有很多面向，沒見過不代表不存在。

不是所有工程師都在爆肝

這次聚餐中，有幾位朋友的職業為「工程師」，許多人對工程師的既定印象為天天加班爆肝。

但第一位開啟工作話題的工程師表示：「我一個月平均的上班時數不超過 40 小時。」

請大家注意，是一個「月」不是一「週」！

是他能力出眾嗎？不！單純就是公司沒啥事要做！

你以為這是特例？不！一起聚餐的工程師中，有幾個也是這樣！

PS. 大部分的工程師還是很忙碌的，只是有些公司、產業真的是這樣；我甚至聽過知名公司的 App 團隊 1 年沒更新過功能。

上班很閒不代表會自我精進

大部分的人可能覺得如果上班很閒，肯定會自我精進吧？

聚餐的朋友有幾個一開始也是這樣想的，但大家只有 3 分鐘熱度；LeetCode 刷個幾題、英文讀個幾天就懶了。

你以為偷懶是少數嗎？不！據不完整統計，比例可能有 8 成之多！

大部分的人即使有閒也不會選擇自我精進，這才是現實。

因為沒事做所以內鬥、焦慮

目前聊下來，越閒的公司內鬥越嚴重，因為大家沒事幹，只好幹掉彼此了。

而且沒事做會引發焦慮，因為你不知道日後轉職時履歷要怎麼寫，而且感受到自己的能力逐漸與市場脫鉤。

所以在這麼爽的環境中，許多人都在考慮離職換一份工作，用環境給自己壓力與動力（Dcard 上的幹話文都源自現實生活）。

環境的影響比你想像的更嚴重

絕大多數人都會被環境影響，如果公司的風氣頹靡，你想一個人振作是幾乎不可能的。

如果大家工作都在裝忙、開會，你想在工作中獲得成長那更是天方夜譚。

只有極少數的人能不受環境影響，反過來利用環境給自己帶來優勢，但…你是不是這種人基本上一個月就會知道了。

結語：快逃啊！

不好的環境只會腐蝕你的身心靈，尤其在很爽的公司更容易待到腳麻走不動。

如果你的公司剛好符合本文情境，請先想想：「這間公司能待一輩子嗎？他不會倒嗎？幾年後我會被取代嗎？到時我能找到其他工作嗎？」

如果這些問題讓你感到焦慮，也許該好好思考一下自己的職涯了。

筆者的忠告：人生是自己的，無論做出哪種選擇，只有你能為自己負責。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

什麼是 Pair Programming？

通俗的定義就是雙方看同一個電腦（或是螢幕分享），一個人寫程式（駕駛員），另一個人審查他寫的每一行程式（觀察員）。

觀察員提供戰略方向，駕駛員專注執行戰術，透過即時的交流解決問題，並寫出更好的程式。

一個人寫程式容易有「盲區」，多一個人在旁邊可以有更廣闊的視野。

用 Pair Programming 讓新人成為即戰力

我們希望新人可以在入職後可以快速掌握專案，並對團隊做出貢獻；為了這個目標，每份專案的技術文件都非常重要，它可以大幅減少新人熟悉專案的時間。

但無論文件寫得多麼詳細，新人在開發時總是會遇到一些狀況，比如：

1. 因為對專案不熟悉，導致開發時有「重工」的現象（ex：沒使用既有函式，而是自己撰寫新的函式）。
2. 對功能的運算邏輯不夠瞭解，在「重構」的過程中，把原本的演算法改壞了。
3. 不熟悉專案現在使用的框架，導致「用很複雜的方式」去完成框架已經內建的功能。

上面所提到的這些問題，其實透過 Pair Programming 都能有效改善；在新人剛入職時，可以安排一個資深工程師透過 Pair Programming 了解新人寫程式時的想法，並對完成的部分做 Code Review，盡可能把問題扼殺的萌芽，並加速新人對環境的熟悉。

用 Pair Programming 培養全端

我有個朋友曾提出一個很棒的理念，他說：「在職位上區分前、後端，但在能力上希望每個人都是全端。」

其實不管前後端，在程式上面的邏輯都是通用的，只是應用的地方不同。

Pair Programming 亦可用於培養全端人才，在實際執行上，前端與後端為一組，輪流寫對方要完成的功能；因為遇到問題隨時有人可以詢問，因此可以快速了解新領域該注意的種種要點。

這麼做的目的並不是要讓你成為該領域的專家，而是培養工程師的「視野」，讓你更了解系統的整體架構。

按照上面的方法就能培養全端嗎？

團隊中每個成員的人格特質不同、工作目標不同，在推行前一定要先評估每個人的意願，否則強制推行只會造成反效果；建議先讓一部分有意願的人先執行看看，觀察成效。

即使團隊成員樂於參與，但每個人的資質與領悟力不同，對原本領域的鑽研深度也不一樣，因此推行的人要注意：「不要用統一的標準來衡量每個人的進步。」

文章僅是提出不同的觀點以及作法，是否適合自己的團隊、具體如何導入，筆者建議要謹慎評估。

想跟大家聊聊

不知道大家在工作中是否有用過 Pair Programming？在使用的過程中有遇過哪些阻礙與問題？可以在底下留言分享自己的感想喔！

如果你是第一次接觸 Pair Programing，在看完這篇文章後會想要在自己的團隊嘗試看看，或是推薦給主管嗎？

如果有自己的想法或不同的見解，歡迎留言一起討論喔！

擁有 6 年的全端開發經驗，目前擔任團隊的 Tech Lead。

職涯中培育過多名工程師， 了解從 Fresh 到 Junior，以及 Junior 到 Senior 過程會遇到的各種痛點。

這段經歷讓我發現許多人都會遇到相同的問題，因此在協助別人解決問題時，也會將其做成筆記發表到部落格上，希望可以幫助更多人少走彎路。

很榮幸受到科技島邀約來擔任平台的「駐站專家」，在之後的日子中還請大家多多指教。

分享的內容雖力求完善，但學識與經驗不足，謬誤難免，尚祈讀者不吝指正與提供補充。

今天這篇文章，我會先透過自身經驗來和大家分享「全端工程師」該具備哪些技能！

全端工程師該具備哪些技能呢？

每個人對「全端」的定義都不太一樣，筆者先列出自己認為「必備」的技能。

前端(Frontend)：處理「網頁上看到的一切事務」，要熟悉 HTML、CSS 的語法，並至少掌握一種主流的 JavaScript 框架(ex：Vue、React、Angular)；在公司沒有 UI/UX 設計師時，還得具備一定的美術能力。

後端(Backend)：負責處理「網頁背後的業務邏輯」，目前後端的程式語言選擇很多(ex：PHP、Python、Go…)，大部分公司都會選用對應的框架來做開發(ex：程式語言選 PHP，框架選 Laravel )；在公司沒有 DBA 資料庫管理師時，需要具備一定的資料庫規劃能力。

除了上述的必備技能外，要對「伺服器維運、CI/CD、系統設計、專案管理、需求溝通」有基礎的認知與實務經驗。

實際上根據公司規模大小、產業的不同，全端工程師所需要的技能樹與實質工作項目也會改變，大家如果對這個議題感興趣，之後筆者再專門寫一篇文章來分享。

想跟大家聊聊

過去有沒有跟全端工程師合作的經驗？合作過程有遇到什麼問題或是收穫呢？

又或者你本身就是獨當一面的全端工程師，在工作中你有用到筆者沒列出來的技能嗎？歡迎在底下留言分享喔！

文章大綱
一、在寫簡報前，請先思考為什麼要寫
  ➤ 每份簡報都有背後的「目的性」
  ➤ 如果沒有簡報，你要如何達成目的？
  ➤ 這份簡報是寫給誰看的？
  ➤ 誰有決定權？
二、撰寫時基礎注意事項
  ➤ 不要把 PPT 當成 Word 在寫
  ➤ 字體大小
  ➤ 顏色
  ➤ 內容排版
  ➤ 標題放結論 or 個人觀點
  ➤ 內容只留關鍵字
  ➤ 不要過度依賴備註
  ➤ 動畫使用時機
  ➤ 第一頁很重要
三、總結
  ➤ 好的簡報跟漂亮的簡報是兩件事
  ➤ 一切以「目的」為導向，減少達成目的上的阻礙

一小时写30页PPT？还吊打全场？｜有「目的性」的PPT才值得写

以下內容為對影片的心得筆記

一、在寫簡報前，請先思考為什麼要寫

每份簡報都有背後的「目的性」

你今天可能要代表個人或是團隊向某一群人做解釋，讓他們理解你要表達的「內容、訴求、跟他的利害關係…」；最終的目的可能是要「獲得認可、解決問題、達成共識…」

如果沒有簡報，你要如何達成目的？

簡報並不是解決問題的唯一方案，他只是一個工具而已；回想你小時候如果想要買一個玩具，在你父母不答應的情況下，你要如何說服他們購買？

會寫出上面這段，是因為筆者發現有很多想要達成的目的，並不一定要用簡報去達成；你可能只要找到關鍵的 Key man 對話就能夠解決問題，不要被制式的規則限制住自己做事的方式。

這份簡報是寫給誰看的？

是給團隊成員、其他部門，還是給自己直屬長官看的呢？

當「受眾」不同的時候，你的用字遣詞以及大綱規劃都會不一樣；你需要考慮到對方的：

• 專業知識：請使用對方可以理解的文字與術語，不然對方無法理解你的表達，這個簡報就沒有任何意義。
• 立場：利害關係要弄清楚，是「合作、競爭、協商、宣傳…」哪一種情境？
• 給你多少時間：有些長官時間有限，你要在最短的時間內讓他掌握可以做出決定的內容。

誰有決定權？

既然簡報是為了達成某個目的，那你就要清楚哪個與會者有拍板定案的權利，你的簡報主要就是為了他服務的。

二、撰寫時基礎注意事項

不要把 PPT 當成 Word 在寫

我發現很多人的 PPT 只是把 Word 文件上的內容直接複製貼上，完全沒有經過整理；這就造成了他的 PPT 文字超級多，甚至講 PPT 時幾乎是照著上面的文字在念，這對台下的觀眾而言是一個相當不良的體驗。

Word 著重在記錄個人思路，PPT 著重在展現影響力。

字體大小

做 PPT 的時候因為人就在電腦螢幕面前，所以你會覺得看起來很清楚；但如果換到大會議室，將簡報投影到大螢幕上時，不同座位的觀看體驗就會有很大的差異。

以下是幾個小建議：

• 最小的字請在 16 以上
• 標題 26 以上
• 重要內容 40 以上
• 統一使用「微軟正黑體」系列字體

建議讀者可以在簡報前可以先到會議室試講，確認每個位置的體驗後再對 PPT 做調整優化。

顏色

簡報內有許多色塊，請避免使用「淺色塊配白色字、深色塊配黑色字、飽和度類似的顏色」，這樣的搭配方案如果放到投影幕上很可能糊成一團。

同時也請考慮到「色盲、色弱」的觀眾，盡可能挑選合適的顏色。

內容排版

• 一頁就講一個內容：切忌將多個概念擠到一頁，會容易讓人抓不到重點。
• 上下頁要有關聯性：如果每一頁並沒有邏輯正相關，這容易讓觀眾思緒混亂。
• 不要省轉折頁：如果要切到新的話題，請安插轉折頁，這能讓觀眾對接下來的內容有心理預期。

標題放結論 or 個人觀點

考慮到人類的注意力有限，每個人的工作又都很忙碌；即使你在台上簡報，台下的觀眾也可能分心滑手機回訊息，他們未必有辦法全程專注在你的簡報上面。

所以在一張簡報中，我會選擇將結論放在標題；下面的內容只是作為輔助來說明，這樣即使觀眾恍神，那透過標題也能很快進入情境。

內容只留關鍵字

PPT 的內容請不要用說話的句子來做呈現：

• 因為是由「人」來做簡報的，字都打出來了，人還要說什麼？
• 字越多就會越小，觀眾越看不到重點
• 用「講」的簡報比較生動，用「念」的會讓觀眾想睡

盡量控制每頁文字不超過 20 字，多拆成幾頁也是可以的

不要過度依賴備註

其實筆者以前都會把想講的話都打在備註上面，但講過幾次就會發現；有時現場簡報時，你的內容會被「備註」牽制，導致整場簡報有種說不出的卡。

同時如果你是跟者備註在念，你也容易忽略台下觀眾的表情；搞不好你講到這段的時候台下老闆眉頭深鎖，但卻因為你專心的在念而忽略了。

動畫使用時機

基本上只會使用到「淡入、淡出」這兩個動畫，而且是為了「邏輯推理」才使用的。

過度使用動畫轉場會浪費很多時間，台下觀眾看著也累。

第一頁很重要

這裡的第一頁，是用來讓大家對這場簡報擁有「相同認知」的頁面；用來直接破題，告訴所有與會者，今天我們在這裡就是要處理、討論這件事，讓大家搞清楚狀況。

破題還有一個好處就是讓討論的內容限縮在一個範圍，避免簡報途中一直擴展話題模糊焦點。

有些與會者其實在現場一臉疑惑，他們可能是臨時被抓過來旁聽的；又甚至決策者參與的會議過多，導致他忘記了這場會議的重要性、急迫性…這種情狀況下，第一頁可以讓他們快速融入簡報。

三、總結

好的簡報跟漂亮的簡報是兩件事

• 內部溝通：簡報的重點會在於能不能把最終的「目的」達成，如果花費過多的時間在美化上可能不符合成本效益。
• 外部展示：漂亮的簡報還是有其必要性的，畢竟別人花了錢，總會想讓自己這筆錢花得有價值。

一切以「目的」為導向，減少達成目的上的阻礙

上面所提到的「注意事項」就是幫你排除觀眾可能會遇到的障礙，簡報最基本的就是要把一件事情簡單的說明白，確認彼此的認知相同；在這樣的前提下你才能提高達成「目的」的成功率。

如果你是一個有野心且不安於現狀的人，薪水談判是你一定要去做的事情。

在閱讀這篇文章前，你可以先思考幾個問題：

• 你入職多久了？
• 入職後的薪水有調整過嗎？
• 你滿意現在的薪水嗎？
• 你想跳槽是因為工作環境問題，還是薪水不夠？
• 你對公司有什麼具體貢獻？
• 如果公司願意給你應得的待遇，你想要多少？

本篇文章想跟讀者探討內部加薪這個議題，如果有辦法在熟悉的環境中持續成長，應該沒有多少人想在陌生的環境中從零開始吧？

大綱

1. 薪水談判前的準備
   • 1.1 準備自己的成果
   • 1.2 撰寫有說服力的證據
   • 1.3 安排談判時間
2. 薪水談判時的注意事項
   • 2.1 千萬不要使用紙本或是 Email 要求加薪
   • 2.2 引導談判流程
   • 2.3 不要讓對方覺得是你有求於他
   • 2.4 被拒絕時的應對進退
3. 完賽感言
   • 3.1 趨吉避凶真的很重要
   • 3.2 致謝

1. 薪水談判前的準備

不打沒把握的仗，你為了這一天已經努力了這麼久，千萬不要因為一時的情緒，就在毫無準備的狀態下去敲長官的門。

1.1 準備自己的成果

只有初階的工作才會因為你花了更多時間使公司賺更多錢，高階的工作只關心你有多少產出、為公司帶來什麼利益。

• 最容易被無視的加薪理由
  如果你加薪的理由是：「我感覺自己很努力」、「我已經在這間公司待很久了」、「我覺得自己很認真工作」。
  相信大部分公司不會因為上面的理由給你加薪，且通常會給你一些罐頭回覆：「繼續努力，公司不會虧待你的！」
• 準備實際證據
  筆者在 Day 2 的文章中有提到履歷要定時整理，因為許多證據是有時效性的，時間過了你就很難取得，如果你要公司為你加薪，要有實際的證據他才會買單。
  而且這些證據的重點要放在你做的事為公司帶來多少利益，而不是你做了多少事，比如幫公司賺了多少錢或省了多少錢。公司的人很多，如果沒有主動說出來，上級根本不知道你有這些貢獻。

1.2 撰寫有說服力的證據

筆者在這邊提供幾個不同面向的範例，內容的結構為：「過去遇到的問題 → 我用了什麼方法解決 → 具體有什麼成效。」

• 減少部署難度、提升系統穩定性、節省公司開銷
  過去專案在新版本部署時都需要小心翼翼，害怕有什麼參數遺漏導致部署失敗；但在導入 k8s 後，我們就能確保專案在測試區跟跟正式區的環境都一樣；並且透過它自動擴展的特性，我們就不用給伺服器預留太高的硬體配置，從近幾期 GCP 的帳單來看，這個工具的導入平均為公司省下了 30% 的費用。
• 推廣工具、強化跨部門溝通、提升公司整體工作效率
  過去各部門在專案溝通上都以郵件為主，如果郵件數量一多就容易有資訊上的遺漏；為了讓部門之間溝通更為順利，我導入了專案管理系統，並負責向各部門做系統的教育訓練、請 Key man 協助推廣；有了它之後，執行專案時可以更有效地掌握任務時程、歷史紀錄、負責人員，從 Issue Ticket 完成的數量來看，公司整體工作效率提升了 40%。
• 學習新技術、解決公司問題、取得良好的數據回饋
  過去系統首頁的載入速度太慢、且導航功能不夠明確，導致使用者的跳出率一直很高；針對這個部分我把首頁改成 SSR 渲染提升載入速度，並且與 UI/UX 設計師一起討論系統流程，透過審視系統的 SiteMap 來重新規劃導航功能的權重；透過這些更新，從 Google Analytics 的報表我們可以得知使用者平均在系統的停留時間上升了 200%，且瀏覽的頁數增加了 320%。
• 讓公司業務理解產品，提升部門產品的銷售業績
  我們部門完成了很多產品，但幾個月前的銷售業績並不理想；在跟業務聊天的過程中發現他們並不了解我們的產品。所以我便舉辦了一場產品說明會，向業務說明我們的產品能幫客戶解決哪些痛點，讓他們了解並對產品有信心；以這個月來說，我們部門產品的銷售業績提升了 300%。

如果你的上級是個有遠見的人，當你說出自己具體貢獻時，他會毫不猶豫地為你加薪，內部調薪 30% 甚至 50% 以上都是有可能的，因為好的人才真的很難找。

1.3 安排談判時間

就算你已經做好了事前準備，也千萬不要臨時起意找上級談加薪，因為你無法確認他晚點是否有會議要開；而且這種做法也不夠正式，會給對方一種我只是提提看，如果不行就算了的感覺。

談判的時間很重要，相同的要求在不同的時間點提出，可能會有完全不一樣的結果。

• 要避免的談判時間點
  • 禮拜一
    通常休假後的隔天大家的心情都不太好，如果在此時進行談判，上級很可能會帶有較多個人情緒。
  • 禮拜五
    薪水談判未必可以在一天之內結束，因為有些公司有複雜的簽核流程要跑；如果選在禮拜五，你的上級可能會因為要跑的流程太多無法當下給你保證，而你還要捱過一個得不到結果的假日。
  • 下班前
    你喜歡在下班前開會嗎？如果你不喜歡，就不要在這個時機點說，因為上級的臉絕對很臭。
• 最佳的談判時間點
  儘管避開上面的時段都可以談判，但下面的時機更為恰當。
  • 專案獲得成功的時候
    此時你已經證明了自己的能耐，這是上級是無法忽視的實際證據。
  • 上級心情好的時候
    只要你給的證據足夠、加薪幅度合理，挑對方心情好的時候談判，成功率會大幅上升。
  • 知道公司營收成長的時候
    如果公司沒賺錢，或是你待的產業走下坡；即便你在努力也很難加薪。
    相反的，如果公司的營收很好，薪水談判的空間就會很大。

2. 薪水談判時的注意事項

2.1 千萬不要使用紙本或是 Email 要求加薪

• 為什麼不要用文字溝通？
  很多人會因為害怕和公司高層或是上級面對面談判而使用文字溝通，但這個方式真的非常愚蠢。
  因為每個人對文字的理解是非常主觀的；所以請你面對面（或至少讓對方聽得到你聲音）的狀態下去談判，這樣對方才能從你的情緒、語調、肢體語言、眼神的溝通中感受到你的自信。
• 如果你感到害怕，那請準備好劇本，並練習到滾瓜爛熟
  有些人口才很好，只要準備好實際證據，就能信心十足地與上級談判。
  如果你沒有這個天賦，那請你為這場談判準備好劇本；在談判前先跟你的朋友、家人、合作伙伴們多練習幾次，模擬一切可能發生的狀況。儘管實際談判時，恐懼不會消失，劇本也不會完全按造你的想像發展，但你的表現肯定比沒準備時從容許多。

2.2 引導談判流程

• 講清楚這次談判目的，直球對決！
  談判需要有明確的目標以及結果，否則就只是一場毫無意義的面談。
  筆者建議一開始就正大光明地說出此時此刻就是要討論薪水的議題；如果你只是暗示，有些上級會假裝聽不懂或是轉移話題。
• 讓對方認同自己的貢獻
  你可以先說說自己過去在公司的貢獻，並在陳述到一個段落時向上級詢問這些貢獻是否對公司有幫助，透過這樣一來一往的過程，對方更能吸收並認同你所提供的訊息。
• 主動提問題，不要只顧著講自己的豐功偉業
  除了表明自己的貢獻外，你同時也要提出問題，請記住提出問題的人才是主導這個會議的人。
  提問是為了獲取更多情報，並試探對方的底線；但請以合作者的角度去做詢問，讓他知道我們是在同一個陣營的，我們要一起讓公司變得更好。

2.3 不要讓對方覺得是你有求於他

不要在對話中出現：「我想要…」、「我需要…」這類的開頭，一但出現有求於人的詞彙，那談判的主動權就可能轉移。

你可以嘗試改用：「這份薪水有彈性嗎？如果我的年薪有 XX 會更合適，你覺得呢？」這類中性的語句，不要參雜多餘的事情來做詢問。

2.4 被拒絕時的應對進退

並不是每次提加薪都會被接受，但如果被婉拒就直接離場，那你在這次的談判中毫無收穫；筆者在這邊提出另一條思路，讓你確定是否要繼續留在公司打拼。

• 如果現在不符資格，那我要怎麼做？
  在提出加薪需求時，上級可能會跟你說：「現在還不是時候」、「你知道現在公司營運狀況」、「共體時艱」…
  遇到這些問題時你可以考慮這樣回答：「我來這間公司的目標是為了成為一個最有價值的成員，而不是成為公司的負擔；我想要為公司創造收入，並讓您理解當公司支付這個薪水時，我會 10 倍、20 倍的回饋給公司，我是為了讓公司成長而進來的，我不是把這裡當成一份工作而是把它當成我的事業。」先說讓上級聽起來舒服的場面話，然後在最後詢問他：「現在我的年薪是 XX，而我的目標是 YY，我知道不可能馬上調整成這個數字，但是可以請您告訴我，要怎麼做才能賺到這個薪水嗎？」
• 直接向上級確認，完成目標後是否就會調整成期待薪資
  相信上面這些話會讓上級對你印象深刻，至少他會知道公司有你這名充滿野心的員工，此時他就會去思考要如何幫助你成為有資格賺到這個薪水的人，並提出他期望你能夠完成的 KPI、milestones…
  接下來就到最後一步了，你直接向上級確認：「如果我真的完成了您所說的這些目標，公司是否願意支付我所提出的年薪？」在得到肯定的答覆後，可以直接跟上級約下一次會面的時間（ex：3 個月後）。
• 完成目標後，向更高的目標發起挑戰！
  等到下一次的會議，再重複一次你今天所做的事情，挑戰更高的目標。
  如果你是待在一間高速成長的公司，那麼你的機會是無限的，能成長多快完全取決於你的意願、野心、能力。

如果在你達成目標後，公司願意給你該有的報酬，那其實留在原本的公司也不錯；假設公司沒有履行承諾，那你也能非常果決的離職，尋找下一間適合自己的公司。

3. 完賽感言

每個人的人生，都是自己選擇而來的。

3.1 趨吉避凶真的很重要

有些話年輕的時候聽不進去，直到經歷了某些事，才會了解它的道理。

• 做人要圓融
  以前覺得圓融就像是示弱，但社會化越深，越能體會圓融的重要性；如果讓對方講話大聲一點就能取得雙贏，為何一定要鬥到其中一方慘勝？
• 做好本分，不要意氣用事
  如果今天領著公司的薪水，就做好自己的本分；筆者看過太多因為對公司制度不爽或是被 PIP 的同事，在離職前努力的給同事製造麻煩，甚至遇過離職當天把公司電腦給格式化的。
  公司對不起你，你有情緒完全合理；但請注意，如果你損壞公司財產，你可能會背上法律責任，真的不要意氣用事。
  如果公司沒犯法，盡可能不要把事情做絕；至少保留檯面上雙方的面子；圈子說小不小、說大也不大，誰知道有沒有再次相會，也不知道是以什麼方式相遇。
• 給人留一條活路
  以前，在局面對自己有利的時候，我會想要獲得全面性的勝利；但現在，我會選擇給對方一個台階下。
  一無所有的人才是最可怕的，人生中有勁敵會讓自己成長；但如果周圍都是仇敵，你連睡覺都不安穩。

3.2 致謝

• 令人感動的朋友群
  這個系列文能完成，首先要感謝我身邊受苦受難的朋友們；沒有你們，我真的沒有這麼多題材可以寫，希望你們早日脫離苦海。
• 給工程師表演舞台的比賽
  感謝 iT 邦幫忙舉辦鐵人賽，讓我趁這個比賽逼自己去完成一件有意義的事情；並且很幸運的認識一群對技術充滿熱誠的自虐狂戰友們，並成功在各自的主題中完成了連續 30 天發表技術文章的里程碑。
• 使我有勇氣繼續奮戰的後盾
  家人與女友在比賽期間一直給我加油打氣，有你們當我的後盾真的很安心。

後記

這是一系列個人風格強烈的筆記，筆者將自己這些年累積的技術與經驗用最短的篇幅呈現出來；但每個人都有自己的人生要走，文中的應對進退未必適合每一個人。

即便你覺得哪句話說得再有道理，也要經過自己的思考再去實踐。

如果這個系列文對你們有幫助，那是我最大的榮幸。

最後想跟讀者們分享「熔爐」這部電影中，一句讓我印象深刻的台詞：「我們一路奮戰，不是為了改變世界，而是為了不讓世界改變我們。」

雖然鐵人賽在這裡告一段落，但對我來說：「技術分享的旅途才剛開始呢！」

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力～

參考資源

1. 薪水談判-Salary Negotiation(筆者部落格)
2. Salary Negotiation: 7 Tips On How To Negotiate A Higher Salary

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

如果在過往的工作中只遇過 1、2 次不愉快的經驗，那應該是主管偏心、公司制度有問題；但如果你過去的每間公司都遇到類似的狀況，那問題可能出在自己身上。

如果你覺得現在過得不好，不妨參考文章中的方法，也許裡面有些觀點能給你的職涯帶來不一樣的啟發。

1. 做好份內的事
   • 1.1 勇敢拒絕非本職工作，持續加強自己的專業
   • 1.2 不要什麼事情都攬下來，學習當溝通的橋樑
   • 1.3 拒絕承擔與職位不符的責任
2. 讓自己獲得好的工作狀態
   • 2.1 提升工作品質的小技巧
   • 2.2 下班後好好休息
3. 職場禮儀
   • 3.1 避免當個讓人討厭的主管
   • 3.2 詢問別人問題時不要犯的禁忌
   • 3.3 詢問別人問題時該有的禮儀
   • 3.4 給出具體時間，避免使用模糊用語
4. 建立友善的溝通環境
   • 4.1 面對想法意見不同的人，不要先入為主
   • 4.2 不是所有人都跟你有相同的知識背景

1. 做好份內的事

筆者過去非常認真工作，面對主管交代的事從不拒絕，同事需要幫忙時也傾力協助；就算下班時間同事都走光了，我還是獨自加班完成工作。

當時我覺得應該是自己的能力受到肯定，才會被分配到這麼多工作；但過了一段時間後，身體漸漸無法承受這麼高強度的工作，對公司不滿的情緒也越來越多：「為什麼主管只把困難的任務丟給我做？為什麼其他同事都能準時下班？為什麼我要一個人處理這麼多的事情？」然後不久後我就離職了。

直到現在回頭看當年的這段故事，才了解原來「能者過勞」最大的元兇是自己。

1.1 勇敢拒絕非本職工作，持續加強自己的專業

如果你是後端工程師，那就請把自己後端的能力鑽研到頂尖的水準；如果指派給你非本職工作的任務時，盡可能地拒絕。

如果你不懂得拒絕，你就會變成「全包」工程師，同事有事情第一個都先想到你；這容易導致你原本的專業技能停止成長，甚至每天都有做不完的事。

就算你擔任的是全端工程師的職位，我相信一定還是有偏重前端或是後端；筆者建議要認真鑽研偏重的部分，因為絕大多數人都做不到全能，謹記主武器負責殺敵，副武器用來輔助；如果你的主武器已經生鏽，那副武器再多也沒有任何意義。

從高手變成庸才的故事

筆者有個朋友曾經是業界非常優秀的後端工程師，但他在入職新公司兩年後卻變得很平庸；因為除了後端開發外，他還要負責前端網頁開發、公司內部 Server 管理、專案管理系統架設、程式碼版控系統架設、雲端 Server 部署、專案管理、內部教育訓練、Android APP 撰寫…；這些瑣事不僅填滿了上班時間，也讓他下班後沒有體力繼續提升自己，導致技術停留在兩年前毫無進步，而當年落後的人已經可以跟他並駕齊驅，甚至比他更優秀了。

備註：如果在自己手上有事情忙的狀態下，還被強制分配非本職工作的任務；可以趁這個時候跟上級交易，畢竟大家上班都是來賺錢的，如果要我多負擔一份壓力，那也要付出相應的代價。

1.2 不要什麼事情都攬下來，學習當溝通的橋樑

• 將對話窗口轉移
  在非純軟的公司裡面，大部分的部門都搞不清楚前端、後端的差別，因此遇到問題他們不是找主管就是找「全端」工程師；就算你真的能幫他們解決問題，但只要你當了一次的窗口，他們之後遇到問題都會來找你；為了避免日後工作時被其他部門頻繁打擾，筆者的處理方式為：

  • 如果不是本職工作，我會用 Email 告訴其他部門的同事，遇到問題時可以找哪些對應的窗口（ex：如果要提需求可以跟產品經理討論、想知道專案進度請去找專案經理）。
  • 如果是本職工作，但手上工作滿檔；我會將 Email 轉發給其他工程師並描述事情經過，請他協助處理。

  如果你接到問題就處理，那只會是「能者過勞」；你要學習將任務分給同事。

• 不要把別人的問題變成自己的問題
  能力越強，責任越大；當你擔任 Senior Engineer 或是 Tech Lead 時，時常會有同事請你幫忙解決 Bug；如果時間允許，忙當然是要幫的，但請謹記你是幫人，不是攬過來做。
  有些工程師問完問題看到有人幫忙後，就會回到座位一副事不關己的樣子；所以幫忙時請注意界線，以引導為主，不然最後出包，對方可能會把責任直接推到你的頭上。

1.3 拒絕承擔與職位不符的責任

• 背高價、沒看過的資產
  個人資產應該是公司配給你的電腦、螢幕；但有些爛主管會把一些自己不敢背的高價資產掛到下屬身上，如果主管要你在資產轉移單上面簽名，一定要堅定的拒絕。
  大部分的高價資產，只有該領域的工程師才知道如何檢測；所以資產轉移這件事通常有鬼，如果你沒搞清楚就簽下去，很可能成為主管的替死鬼。

• 要你幫忙做不符職權的重要決策
  有些爛主管會將做決策的任務推給下屬，如果你發現這個決策的影響範圍已經超過了你的職權，甚至涉及到多個部門、公司預算；筆者強烈建議你要裝傻推掉。
  他把決策的任務交給你，通常不是為了重用你；只是單純的想要逃避責任跟栽贓嫁禍而已。

  小提醒：假設 1 個決策的失敗率是 20%，你幫忙做了 5 次決策；主管會獲得那 4 次決策正確的獎勵，而你則會承受那 1 次決策失敗的後果。

當然也是有善良的主管，但社會上陰險的人太多，遇到不合理的事你要想辦法拒絕才能保護自己；有的時候不是你比較倒霉，而是因為你沒有拒絕不該由你承擔的責任。

2. 讓自己獲得好的工作狀態

讓我們還回想一下，同樣是工作一整天；有時你回到家時感到沮喪，而有時卻覺得非常充實。

如果你仔細觀察，會發現會造成這兩者差異的主要原因，是因為前者做了太多的雜事，而後者則是去完成有挑戰性的事。

在上個小節已經分享了許多避免雜事的技巧，這個小節就讓我們來了解，如何讓自己有能量去完成有挑戰性的事情。

2.1 提升工作品質的小技巧

你是否曾經工作到一半突然覺得所有事情做起來都非常流暢，在這個狀態下遇到的難題都能迎刃而解、而且能在短時間完成非常多的事，更神奇的是這段時間你的注意力完全不會渙散，甚至會忘記時間的流逝。

筆者周圍有蠻多朋友都體會過這個狀態，它有一個專有名詞 ──「心流」；雖然可遇不可求，但能透過一些小技巧增加它出現的頻率，這些技巧就算無法讓你進入心流，也能提升不少工作品質：

• 給自己一個完整的工作區間，在這個區間內拒絕一切外界聲音；這樣做可以避免你的注意力被打來的電話、訊息的提示音所干擾。

• 給任務設定一個期限，必須在時間內完成某件事；讓大腦把所有精力只投入到一件事情上面。

• 在開始前用一個儀式，暗示自己就要進入無敵模式；透過這個儀式把自己從混亂的思緒中抽離，切斷大腦之前的思緒。

  筆者的儀式是在開始做事前，聽 Victory 這個激昂的音樂。

2.2 下班後好好休息

很多人的下班不是下班，讀者可以回想一下，自己是不是下班後大腦還在思考著剛剛會議的事項，今天尚未完成的工作？

這樣的過度努力，有時會導致你隔天早上到公司的時候昏昏沈沈，做事沒有動力；過去筆者一直以為會這樣是因為工作倦怠、前一晚沒睡好；但後來發現主要是因為在下班後並未將大腦抽離工作環境。

筆者建議在下班前把尚未完成的工作記錄下來，現在有許多筆記軟體都可以幫助你完成這件事，完成後就讓大腦關機，給它喘息的時間；如果讀者願意嘗試看看這個方法，在幾天後你會發現這個細微的調整，竟然能讓隔天上班的時候更有精神、做事效率更高。

3. 職場禮儀

與其說是禮儀，不如說是同事間的互相尊重；如果你有給長官、同事、下屬該有的尊重，彼此的合作會輕鬆許多。

這個小節筆者主要分享不要去踩的地雷，讀者可以從範例中看看自己是否有需要調整的地方；很多時候我們一直在犯錯卻又毫不自覺。

3.1 避免當個讓人討厭的主管

朋友的故事很經典，又符合這個主題，所以就直接拿他來當範例了。

朋友公司的 MIS 部門離職率很高，有多高呢？10 個人的 MIS 部門，一個月可以走 2 個！招募的速度都趕不上離職的速度，部門內除了主管外，最資深的員工還沒待滿一年。

所以時常會找其他 IT 部門來支援業務，而我朋友很不幸的被抓去支援，進去後他瞬間理解為何會有如此高的離職率，簡單幾個例子：

• 在錯誤的時間點發布任務
  除了上班時間會指派任務外，他在禮拜五下午、下班前一小時、下班後還會指派任務給下屬；讓部門每個人的工時超長。

• 光說不練
  一直說自己超級強，但從來沒有看過他自己動手操作，連機房都不太敢走進去；讓下屬對他的能力充滿質疑。

• 推卸責任，陷害同仁
  朋友進去支援，在做交接時身上還要背一堆公司資產；但交接時間只有半小時，資產根本不可能在這麼短的時間內盤點完（當時朋友菜逼巴，不知道一個人背這麼多資產根本不合理），當時他就非常不安；果然隔天就出事了，公司在做資產盤點時發現有些東西不見了，這個主管立馬把鍋甩到我朋友身上要他賠償；一台伺服器就要 20 萬，我朋友現場崩潰大哭。

  如果你只是支援，千萬不要在身上掛賬；就算對方階級比你高，直接請主管幫你擋掉，這是上司應該對下屬的保護。

• 分不清輕重緩急
  凌晨 12 點突然打電話給我朋友，我朋友當時還以為發生了什麼重大事故；結果只是要我朋友幫忙把防火牆重新啟動。因為主管怕自己做出事，所以連小事都要在凌晨打擾下屬。

• 用考績來威脅做事
  在打考績的時期，這名主管在下班時間是這麼交代事情的：「XXX 你幫忙處理一下這個問題，我現在要打考績沒時間處理。」

• 不管團隊承受能力狂接需求，甚至未經討論直接壓任務死線
  這位主管好大喜功，為了討好各個部門，只要有需求就先接再說，完全不考慮團隊的承受能力；為了達成自己的績效，他甚至直接壓死線，要求做不完就全部留下來加班。

看完上面的敘述後，有沒有覺得這個部門根本是地獄？每個人在未來都有可能擔任主管，當你覺得這個故事荒謬的同時，請謹記：「不要變成自己曾經討厭的樣子。」

3.2 詢問別人問題時不要犯的禁忌

如果你問問題的方式讓同事感到不舒服，他們可能之後就不想再幫你了。

• 訊息太過零散
  現在普遍是用通訊軟體來問問題的，如果你沒有把問題整理好再發送，會導致對方電腦一直跳彈窗，非常干擾工作。筆者建議詢問別人問題前，要先整理好訊息且內容要包含：

  • 在哪個地方遇到問題
  • 我搜尋了哪些相關資源
  • 過去有沒有可以參考的範例

• 對方沒馬上回，就一直發訊息
  有些人認為在上班時，同事的訊息應該要秒回，如果超過 5 分鐘沒回就一直敲他。
  我相信會這樣做是因為事情很緊急，但這個做法非常討人厭；對方沒有立刻回訊息，可能是手上也有緊急的事情在處理，如果真的有時間壓力，筆者會建議直接打電話。

• 在下班時間或假日打擾對方
  如果是你個人在專案遇到的問題，建議上班時間處理。

• 訊息只有：「請問你現在有時間嗎？」
  很多人的訊息只有：「請問你現在有時間嗎？」這樣的詢問方式讓收到問題的人沒有辦法預估這個問題將會佔用他多少時間，所以有些人就當成沒看到這則訊息。

• 在開頭說打擾 3 分鐘，結果打擾了 30 分鐘
  如果你的問題其實不小，千萬不要騙對方說只打擾 3 分鐘；這樣很容易打亂他這一天的計畫。

  很多業務開頭的話術就是：「請問可以打擾您 3 分鐘的時間嗎？」如果你有停下來聽他們講解過，就會知道 3 分鐘都是騙人的。

• 拖到最後一刻才問人
  如果最後一刻才求救，不但你緊張，被你求救的人也很緊張；在雙方壓力都很大的狀態下，工作效率實際上是更低的。

• 問重複的問題
  如果詢問重複的問題，除了造成同事的困擾外，還會被質疑你的能力是不是有問題。

• 對方不知道你什麼時候會過來詢問
  如果問問題時對方正好在忙，千萬別說：「我晚點來問你。」因為不明確的時間會給對方帶來更多壓力，應該問：「我什麼時候方便來請教？或是等您有空的時候跟我說一聲？我再過來這邊。」這樣會讓對方比較舒服。

3.3 詢問別人問題時該有的禮儀

有時同事會說：「你幹嘛這麼客氣，直接問就好了啊！」筆者建議你就算聽到這段話，還是要保持該有禮貌，畢竟禮多人不怪。

• 無論是否得到你想要的解答，記得感謝對方
  對方願意幫你，是他人很好而不是義務，就算沒有得到解答也要記得感謝對方，有禮貌對方下一次才會幫你。
• 在打電話給對方前，請先用文字簡述要討論的問題，並確認方便詢問的時間
  如果你直接打電話過去，對方可能在洗手間、會議中…無法及時接電話，並且也不知道接了這通電話要處理什麼事情，而且未經詢問直接打電話有點沒禮貌。
  筆者建議先用文字說明問題，讓對方有思考的時間，這樣可以有效提升討論品質。
• 如果真的有緊急事件需要用通話
  有時會開到一半發現需要某個成員的參與，所以臨時把他拉到會議室。
  若有這種突發狀況，請記得開頭要先說一聲抱歉，並說明要找他討論的主旨，讓他知道突然被加入的會議要討論哪些內容。
• 不要問：「這個要怎麼做？」而是詢問：「這樣做的方向對嗎？」
  第一種詢問方式就像是自己沒有做過功課，第二種詢問方式則是讓對方做修正；大家都很討厭沒做功課就來問問題的人。

3.4 給出具體時間，避免使用模糊用語

當同事問你：「什麼時候東西才會完成？」請不要回答：「等一下就好！」而是說再等 30 分鐘這類具體的時間，因為每個人對「一下」是多少時間的認定是不同的；如果回答的人認為是 1 小時，而發問的人認為是 5 分鐘，就會造成不必要的摩擦。

有些主管在找下屬討論問題時會說：「下午幫我空出一個時間，要找你討論前端設計的問題。」此時千萬不要回答：「好！」你應該要直接提出一個具體時間詢問主管是否方便，如果沒有明確的時間，會導致你無法安排需要高度專注力或是長時間作業的任務。

4. 建立友善的溝通環境

不要說新手，就算是職場上的老鳥，在與同事溝通這塊也經常碰壁；這種情形在跨團隊溝通時遇到的頻率更高，總覺得其他團隊的人在針對我們。

這邊先排除辦公室政治那種拒絕溝通的情境，而是去思考：「如果我們的共同目標是希望讓公司更好，有什麼方法能創造出共贏的局面呢？」

4.1 面對想法意見不同的人，不要先入為主

如果想透過說服對方達成共識，那很容易就把彼此拉到了對立面；即使你成功說服對方，他也未必會真心一起共事。

很多時候在談判前，我們會很自以為是的覺得自己已經了解對方在想什麼了，然後很急迫地把自己的想法加諸到對方身上，不給對方開口的機會。

也許你曾經透過這個方法獲得談判的勝利，但你勝利的原因可能只是因為你的口才比較好；過去的經驗告訴我，這個方法是在封閉彼此溝通的橋樑。

與其一直表達自己的想法，不如嘗試另一條路，詢問對方為何會這麼想，讓對方描述更多想法的細節；在了解對方完整的想法後，用討論的方式詢問對方是否有思考到完整的情境；也許深入探討後你會發現自己的想法是有漏洞的，討論的目的是做出更好的決定，在討論後選擇對方的意見不是認輸，而是達成彼此的共識。

4.2 不是所有人都跟你有相同的知識背景

有時你會在心裡 OS：「這東西這麼簡單，為什麼跟其他部門解釋了好幾次他們還是聽不懂？」會這樣是因為你認為簡單的東西，對其他領域的人而言可能是天書。

每個行業都有自己的專業術語、不同的部門對同一個名詞也會有不同的解釋；如果你今天擔任的角色需要協調各部門的資源，你就要像是個翻譯員，把資訊轉換成他們可以迅速理解與吸收的語言；有時不是其他部門不想配合，而是因為他們真的聽不懂，所以無從配合，資訊轉換也絕對不是一門簡單的功夫，因為你需要對合作部門的業務有一定程度的理解。

備註：筆者認為資深員工最大的價值並不是他擁有的技術，而是他在這間公司的影響力、人脈，以及對各部門業務的熟悉與理解，有能力串連各部門共同完成任務的員工，是公司寶貴的資產。

後記

不會永遠都會有人給你合適的職場建議。

工程師剛進入職場時，能夠在帶你的前輩身上學到很多的技術與經驗。

在你成為老鳥後，你可能要獨自負責一個專案，此時主管能給你一些戰略上面的建議。

但當你成為主管後，你需要同時處理多個專案；到了這個階段，比你更高階的長官因為不了解這些專案的細節，所以很難給出有效的建議。

職涯的前期你會獲得解決問題的標準答案；但隨著你的成長，在未來無論是專案的決策、還是做事的方法，都不會有一個標準答案。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

我一定要把你帶好，如果我不把你拉上來，那誰把我推上去。

每間公司在新人教育訓練上，願意投資的資源落差很大；有些有完整的制度與流程，讓新人一步步走上軌道；而有些則是放牛吃草，讓他自行摸索。

筆者這幾年觀察下來，除非新人天賦異稟、經驗豐富，不然讓他自行摸索其實是跟自生自滅一樣的。作為公司的前輩，也許我們可以換位思考：「如果今天到了一個新的工作環境，我希望可以得到哪些幫助？」

大綱

1. 新人報到前的準備工作
   • 1.1 申請 VPN 連線
   • 1.2 註冊公司內部協作平台
   • 1.3 設定內部 Server 登入權限
   • 1.4 整理技術相關文件
   • 1.5 整理工作相關文件
2. 新人入職後的協助
   • 2.1 讓新人對公司有好感
   • 2.2 了解新人的能力，用合適的方式做教育訓練
   • 2.3 最終目標是讓新人有獨立作業的能力

1. 新人報到前的準備工作

隨著公司的擴張，會有越來越多人加入團隊來分擔你的工作，此時你需要準備交接文件，以保證他們會成為團隊中的神隊友；而不是增加你工作份量的豬隊友，這篇文章我會列出自己在交接時準備的東西。

1.1 申請 VPN 連線

因為疫情關係，越來越多公司的 IT 部門採取遠端工作，但許多工作上的資料以及開發環境都在公司內網。

所以在新人報到前，你要先幫忙申請 VPN 帳號，常見的 VPN 連線方式有 PPTP、L2TP。

這邊筆者要特別提醒一下，因為安全性問題，Mac 從 Catalina 這個版本開始就不支援 PPTP 的連線；建議還在使用 PPTP 來做 VPN 連線的公司，可以考慮換一個更安全的連線方式。

1.2 註冊公司內部協作平台

如果公司內部有專案管理系統（ex：Jira、Zentao、Redmine）或是軟體開發平台（ex：GitLab），請先幫新人註冊好帳號，並列成清單讓他們知道不同協作平台的功能。

1.3 設定內部 Server 登入權限

通常會根據專案的測試進度部署到不同環境：

• DEV 開發環境
  工程師內部開發與測試使用，功能穩定性不高，但版本都是最新。
• QA 測試環境
  工程師開發完成，並通過自己 Unit Test 的驗證後，會交給公司的測試團隊在這個環境做各式各樣的測試。
• PROD 正式環境
  測試部門確認功能穩定且通過壓力測試後，就能部署到正式環境。

這三個情境會對應到不同的 Server，筆者建議一開始只給新人登入 DEV Server 的權限，等到熟悉環境後再慢慢把 QA、PROD 的操作權限給他；避免新人在不熟悉環境的狀態下操作，導致不可挽回的後果。

備註 1：建議設定 alias name 來登入 Server，用 ip 登入只要一時眼花手滑就可能導致悲劇。

備註 2：如果公司有導入 CI/CD來做部署，或是由專人負責部署作業，就能大幅降低錯誤操作的可能性（通常 QA、PROD 除了環境變數外，其他設定都是一樣的，以此保證部署的穩定性）。

1.4 整理技術相關文件

• Coding Style（程式碼風格）
  一樣米養百樣人，工程師來自五湖四海自然風格迥異，公司可以使用 ESLint 這類工具來約束風格，但程式碼的效能、長度、分類…很多事情還是需要有前輩跟新人說明。

• Deploy 的方式
  如果團隊有導入 CI/CD，你就要跟對方解釋清楚哪些 branch 在 merge 時會自動 Deploy 到對應的 Server。

  警告：如果有設計這種依照 branch 更新做自動部署的功能，建議將新人的權限設定為 Developer；避免他推送更新到受保護的 branch。

• 專案文件
  大概可以分成：專案架構文件、API 功能說明文件、過去開發的需求規格這 3 種；基本上這些文件是為了讓對方快速了解專案的結構，而不是讓他了解每一行程式碼的意義。

• 會用到的相關技能
  假設公司今天來了一個後端工程師，他過去的工作經驗是用 PHP 開發，但現在公司的專案是用 Node.js 開發；儘管都是後端工程師，但兩者的技能樹存在一定的差距。
  如果知道新人有這種狀況，除了「相關技能」外，我還會準備「基礎知識」的學習連結，讓他可以快速上手，舉例來說：

  • 基礎知識

    • Node.js 的 iT 邦幫忙鐵人賽系列文。

      由有經驗的人來挑選學習素材，較能分辨誰寫的文章更適合新手入門。

  • 相關技能
    • 如何用 POSTMAN 測試 API、切換執行環境、建立 Mock Server，連結。
    • API 文件的撰寫格式，以及產生的方式。
    • 團隊 Git Flow 規則。

• Debug 的基礎知識
  筆者發現有些新人缺乏 Debug 的基礎能力，講解了好幾次他還是跑來問你類似的問題；我相信這個問題不只發生在筆者身上，所以建議大家可以寫了一份文件說明 Debug 的基礎知識，內容包含：

  • 如何印出錯誤訊息。
  • 設計程式斷點，縮小錯誤範圍。
  • 理解錯誤訊息。
  • 判斷是因為程式邏輯造成的錯誤，還是運行環境導致的問題。
  • 解決問題的方向，可以參考的資源。

1.5 整理工作相關文件

• 列出例行公事清單
  列出團隊、部門、公司的例會時間點，並簡述參與人員、討論內容；讓新人日後參與會議時能搞清楚狀況。
  如果有要繳交週報、月報，會說明繳交的時間點並提供撰寫格式。
• 列出待辦事項
  新人會協助或接替你的工作，因此你可以先將手中待完成的任務做一個難易度排序，先將簡單的任務交給新人，觀察他的完成度及適應性。
• 提點行政庶務
  新人剛入職時誰都不認識，印表機不知道怎麼操作、專案管理系統不會用、電腦不會設定開發環境；你可以撰寫「秘笈」讓他了解遇到問題時可以向哪個窗口提問。
• 了解團隊中每個人的職權
  以一個雲端開發團隊來說，你需要讓新人知道遇到前端、後端、資料庫、伺服器…的問題時要找誰，讓他了解團隊每個人的職權，才能讓新人更快的融入團隊。
• 保密協議
  如果公司開發的專案有其機密性，記得提醒新進人員不可洩露專案內容。

2. 新人入職後的協助

如果沒辦法讓新人成為戰力，那當初根本沒有招募的必要。

很多人會以手上工作太多為藉口，不幫忙帶新人以及做教育訓練，但新人來公司就是為了分擔你過多的工作，如果不教他怎麼做事，你不是活該自己做到死？

2.1 讓新人對公司有好感

• 不要讓新人一入職，就感受到沈重的壓力
  有些公司會準備好一系列的新人教育課程，期待他可以快速上工；但如果這些課程排得太過密集、要記住的事項太多，坐在台下的新人可能聽到一半就魂遊太虛了，不要期待新人可以在短短的一天、一週就學會所有事情。

• 與新人建立連結，帶他熟悉周圍還境
  最輕鬆簡單的方式就是中午帶新人一起吃飯，在前往餐廳的路上，可以向新人介紹周圍的環境，像是餐廳、停車場、大眾交通工具等。
  到了餐廳坐下來後，大家可以在較為輕鬆的環境下再次自我介紹，可以多聊聊興趣、休閒活動，如果有共同興趣愛好可以更快建立連結。

  備註：有些人會自己帶便當，或是有午休的習慣；千萬不要把帶新人吃午餐當成 SOP，請先詢問對方的意願，搞不好新人更想自己一個人靜靜的午休，一起吃飯反而給他帶來更大的壓力。

• 安排資深員工協助新人
  無論有在完善的教育訓練、交接文件；新人總是會遇到一些「基礎、非專業」的問題，比如：「看不懂群組的特殊用詞、不知道適合向主管匯報的時間、不清楚辦公室的特殊禮節…」與其讓新人與公司的文化碰撞，不如安排一個資深員工在初期帶領他。

2.2 了解新人的能力，用合適的方式做教育訓練

請依據每個新人的狀況去調整教育訓練的內容，就像應屆畢業生跟有 5 年經驗的工程師；就算同為新人，但你肯定對這兩個人的能力期待有所不同，下面是筆者公司過去安排教育訓練的步驟：

• 應屆畢業生
  • SETP 1：熟悉工作會用到的技術
    應屆畢業生的技術通常跟工作會用到的技術有一定的差距，因此在入職後的 1~2 個禮拜，我會先讓他熟悉工作會用到的技術。
  • SETP 2：能使用工作的技術做出簡單的 Side Project
    在掌握基礎技術後，我會請他們花 2 週的時間寫一個 Side Project，主題不限。
    主要是藉由這個機會了解他們程式的撰寫風格，對技術理解的深度，這樣比較方便評估日後要安排的工作。
  • SETP 3：實作 Senior 工程師分配的小 Feature
    大約入職一個月後，才會請 Senior 工程師分配小 Feature 給新人，讓他們真正參與開發。
• 5 年工作經驗的工程師
  • SETP 1：有專人一對一帶他了解專案架構
    我們期待有經驗的工程師可以快速上手成為團隊即戰力，所以會帶他了解整個專案的架構；並期許他可以在 2 週的時間內對專案有基礎的認知，到達可以開發的地步。（熟悉的時間會依照專案大小而有所不同）
  • SETP 2：指派一些簡單的 Feature 觀察實作能力
    在對專案有基礎的掌握後，就會開始指派一些不影響系統主功能的簡單 Feature （ex：開發新功能、維護舊程式）。
    以此觀察新人對開發時程的掌控度、程式碼的自我要求、團隊的溝通能力，確認他的能力是否符合職位要求。

2.3 最終目標是讓新人有獨立作業的能力

• 用 Code Review 讓新人的程式能力提升
  在新人完成 Feature 發出 merge request 後，由團隊的資深工程師做 Code Review，告訴新人哪裡可以再做改善；這個步驟的好處有：
  • 新人日後寫程式時會特別注意這些問題。
  • 維護專案程式碼的水平。
• 透過 Scrum 機制讓新人融入團隊
  儘管新人主要是做被指派的任務，但透過 Scrum 的機制他可以：
  • 更清楚專案全貌，知道自己負責的 Feature 能幫上什麼忙。
  • 了解同事各自負責的領域、實作進度。
  • 透過報告工作進度，讓其他同事對自己的能力有更清晰的認知。
• 讓新人能自己解決問題，不要養成依賴的習慣
  在前期，有人協助新人可以讓他更快的適應環境；但這個幫助是有限度的，過度的幫助只會讓人養成依賴的壞習慣。
  如果遇到問題找前輩就能解決，那長期下來他就會放棄思考；因此在新人結束適應期後（大約 2~3 個月），筆者會有意識的讓新人知道：
  • 每個人的工作都很忙，遇到問題要先想辦法靠自己解決。
  • 在我有空的時候，你還是可以問我問題；但我只會給你解題的方向，不會直接告訴你答案。

後記

有些人喜歡在新人面前留一手，在教育訓練時故意漏講一些技術重點，害怕新人成長太快超越自己。

如果在 20 年前，這樣做或許能保留身為前輩的尊嚴；但現在時代不同了，即便你不教，網路上也有一堆免費資源供他學習；所以筆者建議不如做個順水人情，在教育訓練時盡心盡力，我相信新人也會對你更加尊敬。

幫企業培養人才，幫自己培養人脈；筆者認為這才是職場的正向循環。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

參考資源

1. 新工程師報到，我該準備哪些東西來加快交接進度呢？(筆者部落格)

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

但如果在 Demo 時發生意外，不但會影響發表的成效，嚴重點甚至會影響到整個團隊的考績與年終。

為了避免憾事發生，筆者將在這篇文章講解專案 Demo 時的種種細節與技巧，並分享過往遇到的問題及解決方案，希望大家日後在 Demo 時都可以展現專案最好的一面。

大綱

1. 保證現場 Demo 穩定度，不打沒把握的仗
   • 1.1 Demo 前要盡可能的測試
   • 1.2 同事間的預演
   • 1.3 只用一台電腦做 Demo
   • 1.4 穿著得體、統一
2. 邀請「對」的人，不是「多」的人
3. 選擇合適的會議室
   • 3.1 會議室的座位只能多不能少
   • 3.2 將觀看 Demo 的最佳座位安排給 Key man
   • 3.3 測試現場投影機，並確認網路環境
   • 3.4 讓每個要上台 Demo 的人在講台試講一小段
   • 3.5 預定會議室
4. 在 Demo 過程中要注意的事項
   • 4.1 記得關閉會干擾 Demo 的軟體、網頁
   • 4.2 現場燈光控制
   • 4.3 讓每段 Demo 的時間都在掌控之內
   • 4.4 記得帶筆記本上台
   • 4.5 安排中場休息時間
5. 遠端 Demo 前要確認的清單
   • 5.1 確認雙方的畫面與聲音穩定性
   • 5.2 確認自己的網速是否足夠

1. 保證現場 Demo 穩定度，不打沒把握的仗

穩定比表現的突出更重要。

1.1 Demo 前要盡可能的測試

如果在 Demo 現場專案出包，你講的內容再好都無力回天了。

• 尋找可能存在的錯誤
  就算專案已經通過測試部門的審核，我還是強烈建議正式 Demo 前要窮盡各種可能來測試專案；萬一你真的發現錯誤，就算無法及時修正，至少可以避免 Demo 時操作到這個部分。
• 只 Demo 絕對不會出錯的內容
  重點：全部都要按造 SOP，絕對不要即興發揮！
  功能越多的專案，在 Demo 時就越要謹慎；如果你每次操作的路線都不一樣，萬一你在 Demo 現場把 Bug 測出來就真的完蛋了。
  不要認為自己沒有這麼衰，筆者已經親眼見證過好幾次地獄倒霉鬼的誕生了；所以建議：「乖乖的按照 SOP 來做 Demo，並且至少跑 3 輪，確認專案在這個流程絕對不會發生意外。」

1.2 同事間的預演

有時專案 Demo 會讓同事輪流上台演示自己負責的 Feature；這邊說一下預演的重要性：

• 預估每個人 Demo 所需的時間
  Demo 都是有時間限制的，如果某個人 Demo 的時間太長，會壓縮到其他人的時間。

  在大約了解每個人 Demo 需要的時間後，也比較好制定議程。

• 知道彼此會講的內容
  預演能讓其他同事知道你 Demo 時要講的內容，如果當天不幸發生了什麼變故還能協助支援。

• 微調內容
  基本上第一次預演會發現很多問題（ex：口條不流暢、內容不連貫…），需要彼此互相提醒才能在當天有好的表現。

1.3 只用一台電腦做 Demo

如果需要輪流上台請將資料都存到一台電腦上面，下面列舉在 Demo 過程中換電腦的缺點：

• 壓縮 Demo 的時間長度
  換一次電腦在快也要 30 秒，如果有 5 個人要上台就浪費了 2 分 30 秒。
• 打斷會議流暢程度
  每換一次電腦，投影幕畫面就會跳掉一次，這容易導致台下觀眾思緒抽離。
• 未知的風險
  換電腦可能導致投影幕有色偏、斷訊、閃爍的問題，雖然這不是專案本身的問題；但也容易遭到台下觀眾質疑團隊的專業能力。

1.4 穿著得體、統一

• 第一印象很重要
  建議男生襯衫西褲、女生職業套裝；千萬不要因為邋遢的打扮讓自己的專業被扣分。

• 穿著盡量統一
  如果每個人上台的穿著差異太大，可能導致觀眾把焦點轉移到人，而非在 Demo 的專案；所以這塊請事先溝通，最常見的是黑白搭配。

• 不要有異味
  有些人的汗腺較為發達，在夏天及緊張的環境更容易出汗；筆者建議隨身攜帶香水，讓觀眾在舒服的狀態下參與專案 Demo。

  在空氣不流通的會議室，這個問題更加明顯。

2. 邀請「對」的人，不是「多」的人

事半功倍 VS 事倍功半

• 重要的長官一定要出席
  Demo 的日期以 Key man 能參與的時間為主，如果最關鍵的 Key man 無法出席，你這次的 Demo 可以說有一半以上的意義都沒有了；因為就算有代理人出席，他也只能做到轉述，而轉述的效果就跟你分享電影情節給朋友的感覺差不多。
• 不要邀請一堆無關的閒雜人等
  有些會議為了要做排場給長官看，就邀請了一堆跟專案無關的人參與；這樣的做法除了會引起他人的反感外，甚至會造成台下一堆人在滑手機、做自己的事。

3. 選擇合適的會議室

如果可以絕對要提前場勘，不然很容易死得不明不白。

3.1 會議室的座位只能多不能少

• 確認參與會議的實際人數
  確認 Key man 可以參與的日期與時間後，再邀請與專案相關的人員一起參與會議；切記會議通知並不是發出去就沒事了，在會議開始的前 2 天，你要再次確認實際參與人數。
• 到現場確認有效座位
  有些會議室的結構比較特殊，部分的位置是看不到講台的，這塊在場勘的時候要特別注意。
• 保留 20% 的座位
  除了收到會議通知的人會來參加外，有時會有不在你邀請名單的長官或是同事出席；因此建議預留 20% 的空位給臨時參與的人。

3.2 將觀看 Demo 的最佳座位安排給 Key man

• 了解哪些座位擁有黃金視角
  因為大部分的會議室都是平面的，基本上只有前幾排可以看得清楚投影幕與 Demo 成員；你需要在場勘時就掌握會議室的座位圖，並了解哪些座位擁有黃金視角。

• 在入口處有專人引導
  為了保證 Key man 是坐在觀看 Demo 的黃金視角，筆者會建議安排專人負責引導 Key man 到座位上。

  也可以放座位名牌避免同仁誤坐。

3.3 測試現場投影機，並確認網路環境

• 測試投影機注意事項
  • 一定要用當天 Demo 的電腦測試，確認是否可以順利投影，以及投影的畫面是否有模糊、字體太小、色偏…等問題。
  • 同時記得確認投影機轉接頭是 HDMI 還是 RS232，現場是否有提供轉接頭還是要自己準備。
• 網路環境注意事項

  • 是否有穩定的 Wi-Fi 或是網路線連接口，建議拿當天會用的電腦直接測速會比較安全。

    有些公司的網路只能連接內網，如果你 Demo 會用到外網也須特別注意。

  • 有些會議室的收訊不佳，建議也要測試自己手機熱點的網速是否穩定。

3.4 讓每個要上台 Demo 的人在講台試講一小段

• 確認聲音大小
  每個人說話的聲音大小不同，同一個場地有人需要麥克風有人不需要，所以可以藉由試講來確認。
  另外如果場地較大，就算你的音量足夠也建議使用麥克風，因為很多場地有回音的問題。
• 熟悉講台的視角與站位
  如果有機會，建議要先上去熟悉講台的視角，這個動作可以消除部分恐慌的情緒。
  有些 Demo 會需要多人站在講台上，這部分一定要在現場走位過，不然很容易擋到投影幕以及要 Demo 的產品。

3.5 預定會議室

這邊筆者分享一些定會議室的注意事項：

• 一定要提早訂
  這種重要會議筆者一般會提前兩個禮拜預定會議室，因為公司通常沒有太多合適的大會議室。
• 確認會議時間沒有與公司例會衝突
  如果你專案的 Demo 時間與公司例會衝突，有可能導致部分原本會來的長官缺席，所以記得把時間排開。
• 保留緩衝時間
  除了 Demo 的時間外，前後都至少要留 1 小時來做緩衝。
  • 如果會議室上一批人剛使用完，可能需要進行場復作業。
  • 提早到可以再次確認與熟悉場地環境。
  • 後面多留一小時，是因為通常專案 Demo 都會 Delay 一點；並且讓會後交流的時間更充裕。

4. 在 Demo 過程中要注意的事項

這塊 PM 需要適時的去協助

4.1 記得關閉會干擾 Demo 的軟體、網頁

如果在 Demo 過程中跳出奇怪的訊息是非常尷尬的，而且訊息不斷跳出的提示音也很吵；Demo 時千萬不要犯下如此低級的錯誤。

下面列出幾個常用的的軟體、網頁：

• 通訊軟體
  LINE、Messager、WeChat…
  只要你的好朋友剛好在這個時間點傳送奇怪的訊息，你的個人隱私就會直接顯示在大螢幕上。
• 郵件
  我發現很多人都會忘記關閉郵件，筆者之前就曾看過同事 Demo 到一半，螢幕右上角跳出信件通知，主旨是：「XXX 公司錄取通知」；當時台下還有總經理，畫面有多尷尬我就不說了。
• 社群網頁
  Facebook、LinkedIn、Twitter…
  千萬不要忘記關閉社群網頁，他們的提示音也是很吵的。

4.2 現場燈光控制

在 Demo 過程中，你可以透過燈控引導觀眾的注意力，筆者大概分成 3 種：

• 只開講台燈（舞台燈）
  需要觀眾將注意力放在講者或是產品身上的時候，通常是講者剛上台做自我介紹，或是要展示產品的時候。
• 只開最後一排的燈
  希望觀眾仔細聆聽簡報的時候，在這樣的燈光下，有需要做筆記的人還是可以記錄。
  筆者不選擇將燈全關是因為：
  • 有些人的眼睛在全暗的狀態下看發光物體會有不適感。
  • 如果講者的表達能力不佳，在全暗的環境中台下會睡成一片。
• 全亮
  簡報結束與觀眾互動的環節，這樣講者與觀眾的互動比較友善。

4.3 讓每段 Demo 的時間都在掌控之內

有些與會者會不停拋出問題或意見來打斷 Demo 的過程，如果沒有阻止，會導致 Demo 時間脫離掌控。

這邊筆者建議引導他們等 Demo 結束後再發問，比如：「不好意思，我這邊先完成專案的 Demo，讓大家對專案有一個整體的概念；也許接下來的操作就能解釋您心中的疑惑，如果沒有，在 Demo 結束後我再回答您的問題。」

4.4 記得帶筆記本上台

通常在 Demo 的過程都是使用鏡像螢幕，因此在遇到發問時，你不方便使用電腦來記錄問題。

如果你在講台上用手機來紀錄問題，畫面也不太好看；所以筆者建議帶一本筆記本上台，好處有：

• 快速筆記
  有些人一次會拋出 4、5 個問題，如果沒有筆記本輔助，容易有問題遺漏沒回答到。

• 記錄需求
  Demo 結束後通常會得到很多反饋，如果沒有筆記本，光憑記憶是很難把這些全部記下來的。

  通常會安排一個同事來做會議記錄，雙重保險。

• 忘詞提示
  如果你對今天 Demo 的內容不夠熟悉，或是擔心自己緊張忘詞，你可以在上台前將重點記錄在筆記本上。

4.5 安排中場休息時間

如果議程超過 1.5 小時，絕對要安排休息時間！

無論在精彩的 Demo，觀眾的注意力還是有限的；建議 40~50 分鐘就需要休息一下，先讓大家喝杯水，5~10 分鐘後繼續。

這樣可以讓觀眾整理大腦新接收到的資訊，而會議主辦方也能利用這個空檔討論下面的議程是否需要調整。

如果主辦方沒有安排休息時間，一口氣給他講 2 個小時；相信我，這絕對是一場失敗的專案 Demo，因為幾乎沒有人可以維持長時間的注意力，通常這麼做的後果就是觀眾後半段的記憶接近空白。

5. 遠端 Demo 前要確認的清單

如果要向國外的客戶 Demo，又或是因為疫情影響需要在家 Demo。

5.1 確認雙方的畫面與聲音穩定性

因為是遠端，所以非常吃雙方的網路速度；有時畫面及聲音的延遲會造成溝通上的問題，筆者在正式 Demo 前會用以下方法維護會議品質。

• 主講者自我介紹
  讓每位主講者先簡單自我介紹，確認聲音的大小，避免有些人超大聲有些人超小聲。
• 只有主講者開麥克風
  遠端開會時除了主講者外其他人都要靜音，不然很容易會有雜訊。
• 建議購買麥克風，不要靠電腦收音
  如果有遠端 Demo 的需求，建議購買專業的麥克風收音，這樣可以大幅降低周遭環境音（ex：咖啡廳背景音樂、小孩哭鬧聲、鄰居吵架聲…）的干擾。

5.2 確認自己的網速是否足夠

• 使用 Wi-Fi 時注意不要互搶流量
  在家中通常是連接 Wi-Fi，但如果很多人共用這個 Wi-Fi 可能會導致Demo 品質不穩定；如果可以，建議大家在 Demo 時請其他人暫停使用 Wi-Fi。
• 確認自己的頻寬能否 Demo 需要高網速的頁面
  在載入圖片、影片資源時，會消耗很多的網路流量，這很可能造成你畫面卡頓甚至靜止，因此建議你先找朋友測試看看，以保證當天勤務萬全。

筆者碎碎念

Demo 過程發生的意外，對台下的觀眾而言是一種必然，因為他們只會聽一次而已；請不要讓這些可以控管的風險毀掉團隊努力的成果，每次 Demo 前都按照這份清單檢核一次吧！

如果大家還有遇到什麼狀況想補充的，請在底下留言告訴我，你無私的分享可以減少 Demo 時悲劇的發生～

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

參考資源

1. 專案 Demo 前的準備、細節、技巧(筆者部落格)

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

如果不會表達，那麼你的功勞不是你的功勞。

我想很多人跟筆者一樣，從小就被教導謙虛是美德、不要去邀功；相信皇天不負苦心人，默默地做總有一天會被看見的。

我們在電影中看到反派搶功勞會被主角教訓；但在現實生活中，搶走你功勞的人只會活得更好。

當然這篇文章不是教你搶功勞，而是分享幾個，讓你的努力效益最大化的方法。

大綱

1. 做重要的事
   • 1.1 了解公司目標
   • 1.2 你完成的 Feature 重要嗎？
   • 1.3 主管分配任務給你，跟你主動去要任務是不同的
   • 1.4 如果公司願意把一個高難度的專案交給你
2. 讓自己的努力被看到
   • 2.1 即時匯報進度
   • 2.2 不只完成專案，還要宣傳專案
   • 2.3 專案結束後，要主動去拿獎勵
3. 提升在團隊內的影響力
   • 3.1 主動幫助同事
   • 3.2 讓團隊成員有更好的獨立作業能力
   • 3.3 不要只想著表現自己，分功勞未必是個零和遊戲
4. 增加在公司的影響力
   • 4.1 開會時，你代表的是部門
   • 4.2 如何在沒有權力的狀態下創造影響力
   • 4.3 把握上台機會

1. 做重要的事

花一樣的力氣做事，當然選效益最高的。

很多人天天加班，覺得自己為公司賣命應該要獲得對應的報酬；但這一切往往事與願違。

很多人都會把矛頭指向「個人能力」或是「慣老闆」身上；儘管這兩點也是原因之一，但筆者想從「做事」的角度跟讀者分享，也許我們過去所認為的努力，對公司來說毫無意義。

1.1 了解公司目標

有些人埋頭苦幹做了一堆專案，認為自己績效斐然值得嘉獎；但是否值得嘉獎是由專案帶來的效益所決定的。

你的專案要跟公司的商業目標一致，不然你做的專案再多、再好，公司裡面沒有業務幫你推，你再怎麼加班也是白忙。

相反的，如果你做的專案可以讓業務更輕鬆的銷售產品，提升公司業績；就算你只做一個專案，也能讓你在公司有更高的地位。

1.2 你完成的 Feature 重要嗎？

也許你的技術很頂尖，特別喜歡攻克專案裡面困難的 Feature；但幾年之後卻發現周圍技術能力普普的同事都升官加薪，而自己卻還在原地打轉。

此時請不要抱怨職場不公平，你應該要先審視自己完成的 Feature 為公司或是團隊帶來多少利益；無論你攻克的 Feature 有多難，如果它只有 1% 的使用者會用到，從公司的角度而言你是沒有多少影響力的。

反觀你周圍技術普普的同事，他們用框架快速完成系統的主功能，又用簡單的技術完成了很多實用的 Feature；即便難度不高，但從公司的角度來看，是這些人撐起了系統的運轉。

如果你是老闆，在升職加薪的時候，你會選擇誰？這是一個資本主義的社會，並不是你選擇困難的道路就會獲得更多回報。

1.3 主管分配任務給你，跟你主動要到任務是不同的

如果你不主動爭取，通常最後被分到的都是低價值任務；要嘛難度很高，要嘛毫無價值。

• 為什麼要主動爭取任務？
  每個人的時間都是有限的，如果你長期接手低價值任務，你與周圍同事的差距會越來越大；大部分的人上班都是為了錢，為什麼不去主動爭取高價值任務？
  就算任務的內容完全一樣，但你完成被分配任務只能說是合格；而你完成主動要到任務卻是達成目標，被動跟主動給人完全不同的觀感。
• 如果始終無法獲得高價值任務
  如果主管明顯特別照顧某個同事，即使你主動要求也無法獲得高價值任務；筆者建議直接跟主管敞開了聊，不要在那邊用猜測的方式揣摩上意。
  假使聊完後你還是被分配低價值任務，那你也可以心無罣礙的離開；人生很短，不需要堅持在不合適的環境中成長。

1.4 如果公司把一個高難度的專案交給你

先判斷這個高難度的專案能否給你帶來成長，再去思考這個專案對公司而言的重要程度。

如果評估後是有價值的，請勇敢的接下來；有價值的任務，你不接還是會有人接的。

也不要過度擔心自己做不來失敗的後果，老實說就算真的失敗了，損失最大的是公司，你最慘就是換一間公司；既然公司願意冒這個風險把任務交給你，那就放手一搏吧。

如果你不打算庸庸碌碌過一生，機會來的時候就必須冒險；如果你把握住了，它們是升職加薪非常重要的談判籌碼。

突破舒適圈未必會獲得物質上的獎勵，但肯定能讓你的視野上升一個台階。

2. 讓自己的努力被看到

大部分工程師的思考都是線性的，就像是遊戲關卡一樣，我們覺得完成了手上的專案就會獲得回報；但現實生活不是遊戲，絕大多數的時候你完成專案只會被當作理所當然；你不說，沒人會知道你付出了多少心血。

2.1 即時匯報進度

每做到一個里程碑，你一定要即時匯報進度，不要總是等別人來問你。

• 為什麼要匯報進度？
  • 讓主管方便評估時程
    職場與學校不同，學校有交功課就完事了；但職場會有 30% 進度、70％ 進度，你要讓主管掌握你的進度，他才能評估要安排多少任務給你做。
  • 讓同事掌握進度
    有些合作的任務是有順序性的，你完成了如果不吭聲，很可能壓縮到後面接手同事的工作時間。
    像是做網頁時，如果後端完成後拖到最後一刻才跟前端說，就會壓縮到前端串接後端 API 及確認功能穩定性的時間。
• 匯報的內容要有哪些？
  • 目前進度
    說明你的進度是按照預想的、超前的，還是落後的。
  • 這次你做了什麼
    要強調最終的結果，而不是努力的過程；大家時間有限，不要模糊焦點。
  • 接下來的任務
    說明接下來任務的時程規劃。
• 主動匯報進度的好處

  • 讓你擁有安排進度的主控權
    如果你每次都能按時完成任務，那主管在問你需要多少時間完成任務時，你報出來的工作天數通常都會被接受。

    假使你常常無法準時完成，或是浮報太多工作天數；這些破壞合作信用的行為，會換來主管每天緊迫盯人。

  • 讓自己的存在感強烈
    公司人太多，就算是直屬主管也未必知道你所做的事情；不要等到加薪前才刷存在感，只要有成果便要匯報，讓主管覺得你持續有產出。

2.2 不只完成專案，還要宣傳專案

筆者身旁有朋友明明是專案的主力開發工程師，但在專案取得成功後升官拿獎金的都不是他；一開始他在跟我抱怨的時候，我覺得這應該是公司制度的問題，但每隔幾個月他就會約我出來借酒消愁痛罵公司。

幾次之後我也感到很納悶，以我對朋友的了解，他的技術能力肯定沒問題，不然不會每次都擔任專案的主力開發工程師；但為什麼他都沒有得到應得的報酬？

後來跟朋友細聊專案流程才發現，儘管程式大部分都是他寫的；但在專案完成後都是由主管或同事向高層匯報，向業務做 Demo 的時候他也只是坐在台下讓同事講，因為他認為自己負責開發已經夠辛苦了，這些雜事交給其他同事處理就好。

原本這種各司其職的想法也沒錯，但是有些公司只看得到在做宣傳的人，看不到在做事的人；如果你主管匯報時沒有向高層提及你的功勞、同事在 Demo 時沒有放上你的名字，那你所有的努力都是在做白工。

寫專案固然辛苦，但這個專案是否能帶來收益，要看公司是否採納，業務是否願意推廣；公司的專案那麼多，如果不主動宣傳自己的專案，就算做得再好也沒有意義，因此下次完成專案後，請爭取宣傳專案的機會。

2.3 專案結束後，要主動去拿獎勵

不管你的程式寫得再好、功能多麼穩定；你在主管眼中只是一個合格的工程師而已，況且主管未必會去看你寫的 Code。

• 把自己跟專案的成功綁在一起
  一個人的成功，是需要其他同事的肯定、主管的提拔；如果你沒有適時向他們展示你的成果，那你的努力也會隨著專案結束一起消失；至於要如何表現自己，可以參考以下方案：
  • 技術分享會
    如果你在這個專案中用了新的技術，你可以舉辦一個技術分享會向同事以及長官分享。
    • 這個技術的優點
    • 它解決了哪些問題
    • 你遇到問題有多難，如何克服
    • 它幫公司賺了/節省多少錢
  • 提醒主管不要忘記你的好處
    跟主管聊天時，主動提起自己自己的貢獻與影響力；千萬不要怕邀功，你不說，就算別人都看在眼裡也不會給你應得的獎勵。
  • 爭取向高層匯報、向業務簡報的機會
    如同上個小節所說，專案做完後是需要宣傳的，如果你獲得宣傳者的角色，並成功讓高層與業務採納，你將是這個專案最大的受益者。

3. 提升在團隊內的影響力

你有可能因為工作績效而獲得加薪；但如果想要升官，跟同事打好關係、提升團隊績效也是重要的條件之一。

拍馬屁、玩政治、當聽話的狗也是有效的升官的方式；但這些實際操作起來非常依賴個人特質，並不適用於每個人，因此本文不討論這塊。

3.1 主動幫助同事

公司要提拔一個人，除了專業能力的評估外，也會看他跟同事相處如何；你總不會想提拔一個經常跟周圍同事鬧不合的獨行俠吧？

如果你所處的組織比較龐大，主管並不會知道你每天在做什麼，但周圍跟你合作的同事都很清楚；當有合適的缺空出來，而主管無法準確判斷要將誰升官時，就會詢問同事日常跟誰合作較為愉快；所以是否能被提拔，周圍同事的評分也是重要的參考意見。

3.2 讓團隊成員有更好的獨立作業能力

應該很多由技術轉管理職的新手 Leader 都面臨過以下問題：

• 把任務指派下去後，成員不停再追問細節。
• 成員把任務做到一半就停下來了，他們不知道接下來要做什麼。

遇到這類狀況時，有時不禁會想：「這些問題這麼簡單，為什麼這點小事都要我來做決定？你們沒有基礎的判斷能力嗎？」

除了成員經驗不足容易有這些問題外，也有可能是你在分配任務時只說有哪些任務要做，而沒說明為什麼這麼做、這個任務的目標是什麼；如果願意花多一點的時間說明與撰寫完善的需求規格，成員在了解來龍去脈後，很多細節與流程他們就能夠自己決定了。

3.3 不要只想著表現自己，分功勞未必是個零和遊戲

從短期來看，在團隊中搶功勞的人可以快速升職加薪；但同事也不是傻子，有誰願意跟愛搶功勞的人合作？

如果你願意在彰顯自己功勞的同時也把其他同事帶上，你在同事裡面會獲得更多的聲望；功勞就像是一塊蛋糕，但分功勞也未必只是一個零和遊戲，把蛋糕做大，所有人都能獲得回報。

每個人的性格都不同，有些人在做事上面是一把手，但如果你要他上台跟要了他的命一樣；因此這類有生產力的人容易被組織所忽略，假使你願意在專案宣傳的時候，於簡報的最後一頁放上團隊名單，並說出感謝的話，也許你會獲得意想不到的回報。

筆者感謝結語範例：「很榮幸今天可以跟各位長官分享我們團隊完成的專案，在這裡要先感謝 XXX 經理在這段時間四處奔波，在他的領導下專案才能進行的如此順利；在開發的過程中，XXX 資深工程師也花了很多心力在攻克幾項技術難題，以保證我們系統的穩定性…謝謝大家，我是 XXX，再次感謝各位長官的蒞臨。」

• 感謝結語建議結構
  • 先感謝主管，稱讚領導有方。
  • 接著提到專案中的靈魂人物。
  • 最後再說一次自己的名字，增加長官們對你的印象。

4. 增加在公司的影響力

讓公司更多人記住你的名字、知道你在做的專案；之後在跨團隊合作的時候會輕鬆許多。

4.1 開會時，你代表的是部門

組織一大，辦公室政治幾乎無法避免；每個部門都想要爭取話語權與資源。

如果你只需要面對工程師團隊，大部分的時候還可以就事論事；但如果你的位置會需要接觸業務單位，面對這群非常擅長嘴砲溝通的人，工程師在開會的時候非常容易處於被動狀態。畢竟業務單位每天的工作就是溝通與談判，雙方的經驗值差距太大。

但請不要忘記，出來開會你代表的是部門；假設今天這場會議其中一個環節是由你來做專案的 Demo，你就要有被業務單位 Challenge 的心理預期，對方可能在你 Demo 到一半的時候就直接打斷你、對專案指手畫腳。此時筆者建議你要掌握會議的主導權，如果你在 Demo 時頻繁回答對方的提問，會造成其他與會者無法連貫吸收專案內容。因此筆者會說：「不好意思，我這邊先完成專案的 Demo，讓大家對專案有一個整體的概念；也許接下來的操作就能解釋您心中的疑惑，如果沒有，在 Demo 結束後我再回答您的問題。」

在 Demo 結束時，往往會收到很多的回饋；你可以記錄需求，但千萬不要隨便承諾，你在開會所說的話都是代表部門，如果沒有經過內部的討論就亂給承諾，你在團隊內部會被排擠，在其他團隊也會失去信任。

話語的主導權並非看一兩本書就能夠學會，需要經過多場實戰才能有所提升；筆者認為開會時的心態最為重要，不要一被質疑氣勢就落入下風，謹記出來開會，自己是代表部門！你希望別人怎麼看待自己的部門，你就要表現出什麼態度。

備註：你要搞清楚自己代表的角色，是公司、部門、團隊還是自己；代表不同角色時，說話的份量差異會很大，因為對方還需要顧及你身後的人。

4.2 如何在沒有權力的狀態下創造影響力

• 每個人都曾在沒有權力的狀態下影響過別人的決定
  回想進入公司前的面試，你要在短短 1 小時的時間內取得陌生人的肯定，最終獲得 Offer；此時你在這間公司是毫無權力的，卻能夠影響長官的決定。

• 你成為了主管，但並沒有對其他部門發布命令的權力
  在成為主管後，你能夠組織團隊成員做事；但很多時候一個專案需要跟多個部門合作，你可能會接觸到：「市場部門、行銷部門、品管部門…」而這些部門你都是沒有權力下達命令的。
  對你來說是主任務，但對其他部門可能而言可能只是次要任務；你需要創造一個讓對方獲利的理由，他才有可能配合你，共贏的完成這個專案。

• 有影響力的是人，不是強而有力的數據
  假設你收到公司指令，要負責推行一個專案管理系統，通常情況下，除了自己的部門外，其他部門在推的時候會遇到非常大的阻礙。

  很多人會覺得這是公司高層下的指令，各部門應該會配合；但以筆者的經驗來說，願意在初期配合的幾乎不存在…

  • 不要用產品說服對方
    為了要增加使用人數，筆者曾像推銷員一樣到各個部門說這個產品有多好用、幫自己部門提升了多少工作效率；但成效很差，因為大家現在事情都做得好好的，根本沒理由去學一個要重新熟悉的產品。

  • 由對方創造需求
    後來筆者在推這個專案管理系統前，改成先用聊天的方式跟其他的部門的 Leader 了解：

    • 部門現在面對的挑戰是什麼？
    • 未來 1~3 年的戰略目標

    先用同理心去傾聽對方的回答，適時地引導對方來詢問你有什麼好的建議；此時你再說出自己部門目前有在用這套專案管理系統，且透過它提升了不少工作效率，如果對方想更近一步了解再跟他做介紹；談話重點就是先用問題引導對方去思考，而不是直接告訴對方你覺得這樣做更有效。

4.3 爭取上台機會

害怕上台是人性，但當你走上台從聽眾變成講者時，你所擁有的是更多的機會。

• 增加自己在公司的存在感
  很多工程師對上台報告很抗拒，害怕自己報告的不好會拖團隊的後腿；但這樣長久下來，你在組織中會變成一個隱形人，幾乎沒有影響力；不過如果你願意上台報告，就算你表現得不夠好，至少也讓公司更多的人記住你。

  很多時候，你比自己想像的還要更厲害。

• 從觀眾的角度出發，準備對方感興趣的內容
  有些人站到台上後，會瘋狂的向台下輸出自己的專案有多好、產品的功能有多強；台上講的激情四射，但台下睡眼朦朧，會發生這種狀況是因為你一直在講你想講的，而不是台下觀眾想聽的。
  以筆者要跟業務單位宣傳團隊的專案來做舉例，我會重點描述下面 3 點：

  • 專案能幫客戶解決哪些問題
  • 這個專案預計的定價與目標市場
  • 業務要如何向客戶介紹我們的專案

  想要讓業務願意推銷團隊的專案，筆者認為重點是產品有用、利潤足夠、介紹輕鬆；把一條龍的服務做好，他們要做的事越少，專案推得越好。

後記

你想要當參賽者還是觀眾？

如果你想要在一間公司往上爬，無論人際關係處理得多好，都肯定會受到其他人的嫉妒；公司中想升官的絕對不只你一個，如果決定進入這場鬥爭，你就要有受傷的心理準備。

當參賽者還是觀眾都是自己的選擇，每個人在不同人生階段所能承受的壓力不同、職涯規劃也不同；並不存在選擇哪一個一定比較好，筆者只是建議你選一個 10 年之後自己不會後悔的選擇。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

等到「受夠了」才開始進步，一切都已經晚了…

前言：小明的故事

剛踏入職場時，小明對工作懷抱著憧憬，接手的專案總是格外珍惜且戰戰兢兢，生怕自己哪個地方做不好連試用期都過不了；因此入職的第一年像海綿般瘋狂吸收新的知識，並在錯誤中學習成長。

幾年後，小明成為公司的老鳥；當年需要熬夜才能完成的專案，現在只需要半天就能完成了；剩下的上班時間，他選擇泡杯咖啡犒勞辛苦的自己，一邊跟同事打屁聊天消磨空閒的時光，當然他也養成了躲在廁所滑手機當薪水小偷的習慣。

又過了幾年，小明兩眼無神地看著眼前的電腦，他覺得自己受夠了現在的生活，也不滿意公司給的薪水；於是他打開人力銀行，信心滿滿地認為：「憑藉自己多年的經驗，肯定一堆公司來搶自己！」

一個月過後、兩個月過後…

小明取得了非常多公司的面試機會，但卻始終沒有獲得理想的 Offer；此時的他才驚覺，除了第一年外，剩下這些年自己都在原地踏步。

為什麼寫這個主題？

我相信上面「小明的故事」，大家都不是第一次看到了；但卻很難保證自己不成為故事中的小明，畢竟離開舒適圈是一件很痛苦的事情；所以很多人就算「知道」自己不能再這樣下去，但看到舒適圈外的荊棘之路還是馬上打消了這個念頭。

所以我這個主題並不是想要讓讀者立刻做出重大改變，而是在熟悉的環境中多做一點事來認識、調整自己。

• 了解自己現在工作所使用的技術
  • 很多工程師擅長解決問題；但卻無法說明為什麼選用這門技術，以及為何這樣做能解決問題。
  • 有時我們根本不知為何選用某個技術，只是因為公司裡的前輩選擇了，所以就跟著用了。
• 定期整理自己的履歷
  • 整理履歷是一個很好的習慣，可以審視自己這些日子到底做了些什麼。
  • 很多實力很強的人反而不懂如何表現自己，也不理解自己的價值，導致他在市場被低估。
  • 有些資料都是有時效性的，如果沒有定期整理你可能就會忘記或是找不到。
• 每年定期面試
  • 在面試時，很多人會發現自己其實不太了解每天在使用的工具。
  • 了解自己在不同產業的價碼，以及自己最在意的點（距離、氛圍、產業、薪水）。
  • 透過面試知道自己的盲點。
• 做高價值的任務
  • 選擇影響力大的任務，你做的事被大家看到才算是有在做事。
  • 嘗試主動承擔報告與 Demo 的任務，讓公司更多人對你有印象。

適合哪些人看？

1. 工作遇到瓶頸，想要跳槽的人
2. 覺得自己很有實力，但因為不知道如何表現自己，而沒有得到合適 Offer 的人
3. 想了解面試官是以什麼邏輯出題的人
4. 不知怎麼提問題衡量求職者的新手面試官
5. 想找到自己盲點，在職場不斷進步的人

這個系列文我能學到什麼？

快速檢視自己在職場上所缺少的東西，並教你如何用「技術」及「經歷」來包裝履歷，讓自己在市場上取得應有的價值。

文章大綱

• PART 1 履歷（Day2~Day4）
  • 重新認識履歷對職涯的重要性，以此整理有效履歷
  • 將履歷精華提煉成面試用的簡報，用簡報引導面試官提問的方向
• PART 2 面試（Day5~Day25）
  • 了解通過面試可以獲得的好處，並檢核自己是否做好面試的準備
  • 面試是雙向的，你可以透過詢問公司問題；並透過種種細節判斷適合自己的公司
  • 從履歷分析面試官可能詢問的問題
    • 讓求職者了解為什麼面試官會問這個問題、他想要了解什麼
    • 每個問題會附上簡答範例，同時提供回答問題前所需具備的知識
    • 問題面向包含前端、後端、資料庫、設計模式、系統設計、白板題、職場相關
• PART 3 職場（Day26~Day30）
  • 有哪些方法可以擴增自己在公司的影響力
    • 讓新人成為有效戰力
    • 讓部門在 Demo 專案成果時一切順利
    • 爭取 Presentation 機會表現自己
  • 職場上與同事合作的注意事項
    • 問別人問題時要注意的禮節
    • 你是全端工程師，不是全包工程師
    • 建立友善的溝通環境
  • 與公司薪水談判的秘訣
    • 了解談判前要做哪些準備、如何選擇合適的談判時間
    • 注意談判過程要表達的重點與忌諱
    • 被拒絕時的應對進退

文章的篇幅有限，答案僅是提供讀者一個思路；請依自身情境去思考問題，沒有經過思索就接受的答案是經不起考驗的，你要依據自己的經歷寫出合適的腳本。

筆者碎碎念

儘管這個系列文花了很大的篇幅在「PART 2 面試」上，但我不希望讀者只把答案背下來，而是去思考面試官為什麼會這樣問。

說來諷刺，這些面試題並不應該是特別為了面試而準備的，而是你在掌握這個技能時，本就應該理解的；只是許多工程師誤以為完成任務就等於掌握技術，沒發生意外就不去深入研究。

筆者會寫出這些話，就是因為自己曾經是一個注重開發速度而不深入理解技術的人；當時甚至沾沾自喜覺得自己好棒棒，完成了別人好幾倍的任務；但經歷了幾次專案的更迭後明白，欠下的技術債遲早要還的，時間早晚罷了。

在這個系列文，我會盡其所能把自己知道的都分享出來，讓有緣分看到的人少走一些坑，如果讀者有自己的想法歡迎留言，你的留言或許可以幫助到其他人，希望每個工程師都能夠取得自己應有的價值！

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

參考資源

1. 「沒有人該為你的成長負責」 寫一封信給工作疲憊的你
2. 工作想有「突破性成長」的關鍵：懂得切換執行與學習

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571