雖然這個選擇能獲取更豐厚的報酬，但也伴隨著許多風險，最基礎的就是法律問題。

儘管大部分灰色產業都說自己的公司不違法，但有時違不違法，就是拼運氣；如果你運氣不好，上班上到一半被警察抓走也是有可能發生的。

有興趣的朋友可以自行上網搜尋，真的不要不信邪。

就算你福大命大，平安順利地離開，等未來想跳槽到其他產業時也會遇到諸多問題：

1. 薪水差距太大：爭議性高的產業通常會提供高出正常產業 30% ~ 150% 不等的薪水。當你想要轉行到其他產業時，可能會難以接受薪水上的巨大差距。
2. 履歷真的會髒掉：曾經有朋友離開這類產業後（當時他年薪 200W up），接下來想換一份「正常」的工作都屢屢被拒；最後花了近一年，把自己打折出售才成功入職（儘管他的能力已經算是業界前段班，但職涯依舊受到嚴重影響）。
3. 跳槽選擇被限制：一旦投身爭議性高的產業，未來想要跳槽時，往往只能在同類型的灰色產業間選擇。除非你想一路走到黑，否則建議避開這些產業。

上面談的只是「履歷與職涯」上的問題，古人有言：「與惡人居，如入鮑魚之肆，久而不聞其臭，亦與之化矣。」這意味著你的價值觀也會受到影響：

1. 環境的潛移默化：進入爭議性高的產業後，你的同事和上司可能背景較為複雜。而你與他們相處的時間又遠遠超過跟家人、朋友的相處時間，因此他們的行為、思考、決策都會對你的價值觀造成嚴重影響。
2. 金錢真的會左右自己：很多人在入行之初都覺得自己肯定是例外，不會被這些環境影響。但當價值觀慢慢崩壞，公司又拋出金錢的誘餌時，很多事情都不好說。

錢錢很香，但未必真的都能進到你的口袋；就算真的進到你的口袋，也難保不會在未來的哪天出事。

結語

當然每個人都有自己的職涯規劃與經濟上的考量，但站在筆者的角度來看，如果選擇工程師這條路，其實未來的發展性很高。

只要持續加強自己的專業，保持對產業的敏感度，擠身高薪並非遙不可及；但如果為了一時利益進入爭議性高的產業，除了可能觸法與影響履歷外，最嚴重的是「價值觀偏差」。

在有問題的環境待久了，就容易把錯誤的事情視為理所當然；一個人的道德感下降後，容易做出讓自己在未來後悔的事情。

心態上的差異

我們通常是 18 歲上大學，此時的我們還沒有遭受過社會的毒打，並不知道畢業後將要面臨什麼樣的挑戰。

所以大部分的人都是用輕鬆愉快的心情去讀大學，儘管表面上讀了 4 年，但實際上有多少時間在讀書，就真的只有自己才知道了。

而選擇靠補習班轉職的人，大多有一定的社會歷練，他們是認知到目前的職涯並不是自己想要的，所以下定決心轉換跑道。

跟大學生比起來，他們通常是抱持著「改變命運」的想法去上課，因此這兩者的學習積極度是完全不同的。

有些大學生會翹課，或是在上課滑手機；但報名補習班的人通常都會準時出席，上課認真做筆記，下課找老師問問題，假日繼續研究。

補習班報名費是自己的血汗錢，沒理由打混摸魚浪費掉。

面試的表現

許多本科系畢業的學生並沒有認真準備面試，很多都是憑本能在回答問題的；而補習班出來的人，通常都有經歷過模擬面試，知道不同問題該如何應對。

師父領進門，修行在個人；畢業證書只不過是一張入場卷，讓你有機會被更多人看見。

在人才市場上，「人」就是商品，包裝精美的容易溢價，賣相較差的容易折價；不要期待公司主動理解你的內涵，在職場上要懂得「包裝」才有更多機會！

並不是每個人都適合當工程師

筆者是資工系畢業，但身旁有些同學儘管畢業了，但還是不太會寫程式。

也許會有人好奇這樣是要怎麼畢業？不是都有「上機考」測驗嗎？

恩…他們為了畢業，硬生生把幾百行、上千行的程式碼給背下來了。

對！你沒看錯！是「背下來」而不是靠自己對程式的理解寫出來的；其實這也側面說明，就算是本科系畢業，他的天賦也未必適合當一名工程師。

很多人大學選擇科系是憑「直覺」，或是看哪個科系未來比較「賺錢」；但如果發現自己不適合又堅持不轉系，就會白白浪費 4 年光陰。

相比下來，如果你對一個領域一無所知，補習班 3~6 個月的長度是更為合適的，他能讓你先體驗看看自己到底適不適合這個領域

未來發展

人生很長，在長達 30~50 年的職涯面前，是不是本科系就沒有那麼重要了。

也許在職涯初期，本科系出身的人表現更好、知識更全面；但隨著時間推移，如果沒有持續精進自己，那這些領先的優勢將會慢慢消失。

學歷在前兩份工作有參考的作用，但越往後走，越看重你在實務方面的表現，以及與團隊溝通協調的能力。

如果一個人都 40、50 歲了，還只能拿自己的學歷來炫耀，那代表他出社會後混得很差。

😈 錯誤 1：沒有下載桌面版軟體、不熟悉操作

遠端面試常用的軟體有 Zoom、Google Meet、Teams，其中 Zoom 跟 Teams 儘管可以使用「網頁版」，但有時會遇到一些特殊的狀況（ex：螢幕分享一片黑），因此建議下載桌面版會比較穩定。

另外記得在面試前要先熟悉軟體的基礎操作（ex：螢幕分享、開啟攝像頭），並設定好相關權限（ex：允許螢幕分享、允許使用喇叭＆攝像頭），否則在面試過程你可能會需要多次重開軟體，給面試官留下「不專業」的印象。

😈 錯誤 2：直接穿家居服面試（ex：睡衣）

筆者真的遇過穿吊嘎的面試官與穿睡衣的求職者，我尊重每個人的穿衣風格，但印象分數照扣。

除非你真的強到逆天，對方也非你不可，否則印象分數還是相當重要的。

不要因為遠端面試就隨便穿，建議比照現場面試的服裝儀容；當你穿著正裝時，也會給自己一個這是重要會議的心理暗示。

😈 錯誤 3：忘記關閉會干擾面試的軟體、網頁

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

下面筆者列出常見的通訊軟體、網頁：

• 通訊軟體：LINE、Messenger、WeChat
• 社群網頁：Facebook、LinkedIn、Twitter
• 電子郵件（這個超容易忘記）

💪 小技巧 1：在開始時確認雙方的聲音、畫面都是清楚的

如果面試官的聲音模糊或太小聲，一定要即時反應不要怕；如果你聽不清楚題目，怎麼可能有辦法回答得好？

如果你有分享螢幕，一定要先確認對方有看到再繼續說；避免自己分享錯螢幕，或是對方沒看到的窘境。

💪 小技巧 2：盡量找有乾淨背景、合適光源的場地

如果在家進行遠端面試，請盡量找乾淨的背景，或使用軟體內建的虛擬背景（也可以上傳自己喜歡的背景）。

同時注意光源，背光會導致你的臉黑掉。

小提醒：在網路環境不佳的環境下使用糊化背景，你的人也會被糊化。

💪 小技巧 3：盡量找安靜的環境

如果周圍環境音太多會嚴重影響面試品質；如果在家面試，要提醒家人不要在面試時打擾自己。

同時建議不要在咖啡廳面試，因為大多數的咖啡廳都會播放背景音樂，附近的人如果講話太大聲也會影響收聽。

💪 小技巧 4：最好有雙螢幕

這樣你在分享螢幕時較不容易錯亂，同時也方便即時做筆記、看小抄。

如果只有一個螢幕，那在簡報時就只能自己把講稿背下來了；但如果有雙螢幕，你就可以透過備忘錄提醒自己該講什麼。

結語

面試過程發生的意外，對面試官來說是一種必然，因為他們只會聽一次而已。

建議每次面試前，都參考這篇文章檢核一次，不要讓這些可控管的風險，毀掉自己努力的成果！

過去很多人對獵頭的第一印象是「專業」，認為透過他們就能找到一份高薪的工作。

但筆者與多位獵頭溝通合作後，發現並不是每個獵頭都具備「專業」，有些獵頭更像是用碰運氣的方式大量私訊工程師；但這種亂槍打鳥的結果，就是在與工程師溝通時，連他擅長的領域都搞不清楚…

會發生這種亂象，筆者認為是有些獵頭並沒什麼工作經驗，甚至少部分獵頭的第一份工作就是獵頭（聽起來有點荒謬對吧？）

給獵頭的良心建議：

每個人都有自己的專業，如果你今天要幫工程師媒合，至少要對他們的專業有基礎認知；像是媒合網頁工程師，你至少要理解前端、後端的差異，並且對常見的框架有基礎認知（起碼名字跟對應的程式語言要知道）。

筆者遇過最扯的獵頭，是傳送錯誤的面試時間…直接讓那場面試報銷（當天還有請特休…）。

不知道讀者看到這裡會不會覺得有點荒誕？但現在獵頭的專業水平真的落差極大，筆者也是有遇過幾個優秀的獵頭，現在這份工作也是在獵頭的幫助下才找到的。

以筆者與周圍朋友的經驗來說，與獵頭培養好的關係是有必要的，但絕對要「謹慎」選擇合作的對象，我會用以下幾點評估：

1. 他了解你的背景與專業嗎？
   我不想吐槽，但真的有些獵頭連你的履歷都沒看過，就直接打電話聯繫…這簡直在敗壞獵頭名聲；如果不幸遇到這種的，筆者建議直接列入黑名單。
2. 他了解你現在從事的產業嗎？
   同樣是網頁工程師，在硬體廠、金融業、新創公司、政府單位…所擁有的專業技能其實有一定程度的差異，如果推薦不適合的工作機會，可能會讓求職者無法發揮所長（當然有些人是考量到職涯發展，特別選擇自己沒接觸過的產業）。
3. 獵頭過去的工作經驗，在這一行待多久了？
   誰都有是菜鳥的時候，但筆者相信絕大多數人都不太願意把攸關自己人生走向的任務交給經驗不豐富的人。
4. 過去主要推薦哪些產業的人才？
   人無全才，每個獵頭都有自己擅長的產業，你也可以先了解自己感興趣的產業對方是否熟悉，再思考後續的合作可行性。

專業的獵頭能快速找出符合你需求的公司，就算他擅長的產業與你的需求不符，也會介紹其他同事幫你找，這就是我說與獵頭建立合作關係的好處。

一般來說我們不會沒事到處搜集公司資訊，但獵頭每天的工作就是搜集這些資料，把槓桿用在對的地方就能獲得更大的效益。

個人經驗：

獵頭相較於人資，更能帶給求職者公司內部的實際情況；畢竟大部分的人資不會透露自己公司的問題，但獵頭因為手上公司多，相對來說可以更客觀的分享這些資訊。

良心建議：「不要等到要轉職的時候才開始面試。」

筆者知道準備面試很煩很累，在有工作的狀態下面試還要請假很違反人性；但我認為這麼做是值得的，在舒適圈待久了，我們容易忘記外面世界的空氣，相信每場面試都有你能學到的東西。

看見自己的盲點

習慣現在的工作模式後，我們通常會選擇自己最有把握的方式來解決問題。

久而久之，我們成長的只有年資，擁有的只有這間公司所需要的技能、以及公司裡面的人脈；如果沒有足夠的外力刺激，我們是看不到自己問題的。

而面試是一個非常棒的機會，因為對方不認識你，所以沒有預設立場；為了確保你是合適的人選，他們問的問題可不會那麼客氣。

在這一來一往的過程中，你更容易看見自己的盲點。

提升自己的表達能力

有些技術儘管我們每天使用，但並不代表我們了解它，有辦法用對方能夠理解的語言表達它。

下面列幾個常見的問題，螢幕面前的你，有辦法清楚明瞭的回答嗎？

• 可以說明一下最近專案的系統架構嗎？
• 在資料庫設計上，你會注重哪些細節？
• 過去工作上有遇過哪些挫折，你是如何面對與解決的？

也許你知道每個題目的解答，但如果要用嘴巴說出來卻很容易卡住。

因為表達能力是需要訓練的，否則你陳述的內容會斷斷續續缺乏邏輯體系。

保持危機感

了解自己在其他公司眼中的「市場價值」。

很多人認為自己值得更好的薪水，但在離職後才發現是自己「高估」了。

現在市場的輪動速度相當快，技術也是日新月異；也許你現在能領到高薪，是因為「過去」的市場真的需要這門技術，但這並不代表「現在」的市場依舊需要。

當然公司能給多少薪水也會跟「大環境」有關，如果在景氣不好的時候離職，即使有能力也未必能找到更好的工作。

增加自己的談判籌碼

有些公司在明知你有卓越貢獻的狀態下也不願意加薪，如果對這間公司還有留戀；我的建議絕對不是什麼加強向上管理能力，或繼續努力總有一天會被發現的廢話，因為這些做法是否有效完全取決於上級的良心。

與其長期投資一個不確定的未來，又將最終決定權交到對方手上，還不如自己主動獲得談判權；如果你成功在其他公司拿到不錯的 Offer，不僅可以做為跟公司談判的籌碼，也保留了談判破局的後路。

不過在談判時，筆者建議用比較委婉的方式跟上級溝通，比如：「我不是很在意錢，只是最近剛好遇到了 XXX 的機會，他開了 YYY 的薪水讓我了解到自己的市場價值；但比起那些，我更想要留在這間公司跟大家繼續打拼，想了解有沒有調整的空間。」

這是殺手鐧，一間公司用一次就是極限了，即使是暗示也沒有人喜歡被威脅；部分公司會因為這些話給你貼上「不忠」的標籤，絕對要經過謹慎分析與思慮後再使用這招。

結語

有些人認為「面試」是一種對公司不忠的表現，但我認為面試是一種「提醒」自己與市場差距的行為。

如果等到「受夠了」才醒悟，那很多時候一切都已經晚了…

在結尾 QA 時間時，有一個問題讓我印象深刻：「學長，請問你出社會這幾年來，覺得當初學校教的哪個”科目”對你而言幫助最大？」

收到這個問題的時候，我大腦轉了一圈，最終給出了一個連我自己都嚇一跳的答案：「我覺得是”國文”。」

當我說出這個答案時，底下的學生全部都笑翻了，我完全沒想到這個回答比演講中的任何一個笑話還更有效果；等大家稍微冷靜下來後，我再跟他們分析為什麼我覺得「國文」給我的幫助最大。

以筆者的從業經驗來說，大多數的工程師在工作 4~7 年後都具備相當的專業素養，獨立完成工作已經是基本能力，但如果想要在職場上更近一步，「國文」的重要性就變高了。

良好的國文能力，在以下幾個面向對工程師的職業生涯很有幫助：

• 溝通能力：在工作中我們不免要與同事、主管、客戶打交道。好的國文有助於清晰、有效地表達自己的觀點，促進團隊間的合作，並達到更好的工作成果。
• 撰寫技術文件：工程師並不是把功能開發完就沒事了，他還要撰寫技術文件（ex：API 文件、測試報告）。一份優秀的技術文件，除了能同步技術資訊，還能幫助開發人員日後回憶。
• 提案和報告：如果你負責主持一項專案，那勢必要撰寫提案，並定期向高層報告。如果能在提案與報告時清晰表達自己的思路，那高層會對你印象深刻，增加未來升職與加薪的籌碼。
• 學習能力：在日新月異的科技領域，好的文字理解能力可以使你更快掌握新知識，提高學習效率。
• 跨領域合作：隨著職涯發展，你的合作對象將不限於工程師，你可能要與其他領域的專家，或是沒有技術背景的人溝通。此時，如何用白話的方式讓其他人理解自己的專業，就是一個非常重要的能力。

相信文章看到這裡，大家都能體會「國文」的重要性了；我們過去被交代撰寫技術文件、提案報告的時候可能不情不願。

但該完成的任務還是要完成，反正時間都要花下去，與其寫出一份大家都不滿意的文件，還不如多花點心思，嘗試寫出能幫助大家的文件，很多時候這些文件是在幫助未來的自己。

小提醒：

這篇文章不是在說技術不重要，若工程師沒有持續精進技術，就像是少了利爪和尖牙的老虎，是很容易被市場淘汰的。

即便當上主管，還是要保持對技術的敏感度，對這個話題有興趣的朋友，可以參考筆者先前寫的文章：「技術部門主管不熟悉技術，就跟騎兵隊長不會騎馬一樣！」。

有一定規模的公司，會將離職人員手上的工作平均分攤到不同人身上；但如果是小公司或是小部門，那可能交接對象就只有一個人。

大家都知道不能惹準備要離職的人，因為離職的人只要瘋起來，對公司、部門的危害性還是挺大的（筆者曾遇過直接格式化公司電腦的狂人）。

但有些公司會給負責交接的人極大壓力，可能是怕工作交接的不完整，又或是擔心他無法繼承對方的功力。

公司會這樣做也能理解，畢竟已經少了一名戰力，如果沒人把原先的業務承接下來，那未來的工作還真不好展開（專案的地雷如果沒有講清楚，那踩到的時候很可怕）。

可如果從交接人的角度來思考，他原本的工作量也許已經滿載了，如果此時還要承接其他人的業務，那真的是超負荷運轉；要是現在有個白目同事、主管還整天在問他交接狀況，萬一他哪天心情不好，是真的有可能來一趟說走就走的旅程。

交接人離職對公司來說是非常傷的，如果團隊規模在 10~20 人，那有可能這兩個就是唯一熟悉這塊業務的人。

如果是專門接案的外包公司，千萬不要把人逼太緊；把人逼走了，誰來幫你完成案子？違約的罰金是很可怕的！

在過往的職涯中，筆者已經不是第一次看到這種離職連環效應了，也許我們能用一些方法來減輕他們的負擔，並讓整個交接過程更加順利，比如：

• 交接對象要對業務本身有一定的熟悉度：像是網頁開發有分前端、後端，如果讓一個前端工程師去接手後端工程師的業務，我只能說做出這個決策的人心臟很大。
• 建立一個交接檢核表：這個檢核表不僅可以讓交接對象更好地掌握業務內容，還可以讓相關同事和主管了解交接進度，減少對交接對象的詢問。
• 訂定交接日程：需要有明確地日程，以確保交接進度符合預期，否則拖到最後幾天才交接往往會開天窗。
• 盡可能降低交接人的工作負荷：交接絕對會佔用到工作時間，為了避免交接人不堪負荷一起走，盡可能排除他手中沒有必要性、即時性的任務（ex：各種參與意義不大的例會可以優先排除）。

公司的人來來去去實屬正常，凡事留一線，日後好相見。

業界說大不大，說小不小，誰說得準日後還有沒有見面的機會，也不確定是以哪種形式見面。

當有人離開崗位時，我們應該要更加珍惜留下來的夥伴，切記：「準備離職的人不能惹，正在交接的人更不能惹！」

只有讓整個交接過程順利完成，才能為公司和團隊帶來正面影響。

如果你擔任公司的 PM 或主管，在下次專案出現 Bug 時，不妨參考文章的方式來溝通；如果你是工程師，也能採用文章的建議，減少自己修 Bug 時被打擾的次數。

釐清問題前，盡量不要強壓時間

有些主管在 Bug 出現後，根本不管問題複雜度，直接命令工程師：「給我在 15 分鐘內修復完成！」

如果是問題明確的小 Bug，那壓個時間倒也還好；但如果問題複雜度高，強壓一個不合理的時間，那對解決問題並沒有幫助。

說實話，遇到 Bug 的時候工程師就已經很緊張了，如果再加一個很短的時間限制；在腦袋一團亂的狀態下，就算解決了表面上的 Bug，可能背後又同時埋下了更多的 Bug。

筆者比較建議的詢問方式為：「大概需要多少時間釐清問題？」

這裡想表達的是，讓有專業能力的人來估時間；而不是由搞不清楚狀況的人，隨意定一個時間。

工程師要「主動」給出回報時間

要給的是「回報時間」，而不是「解決時間」。

面對完全摸不著頭緒的問題，如果直接說自己可以在 xxx 時間內解決，那會給主管一個錯誤的期待。

如果你真的順利在時間內解決那是皆大歡喜，但萬一還是無法解決那怎麼辦？

就算之前都運氣好順利解決，但只要你失敗過一次，許多主管就只會記得失敗的那次。

因此筆者建議用這種方式回覆：「這邊我們先釐清問題，半小時後向您回報 Bug 處理狀況，如果有順利提前解決也會即時回報。」

這樣做有以下好處：

1. 主管知道什麼「時間點」會收到回報。
2. 如果提前解決，你會被認為是效率高。
3. 我們說的是「回報時間」並非「解決時間」，給自己一點緩衝空間。

工程師千萬別說自己會「盡快」解決

如果說自己會盡快解決，那有高機率每 3~5 分鐘就被打擾一次。

因為每個人對「盡快」的時間定義不同，人一但急了就會催促，而對工程師來說，如果在釐清邏輯時被打斷，那可能會需要再重新順一遍；所以筆者建議要說出「具體時間」，避免在解決問題的過程被頻繁打擾。

總結

遇到 Bug 時，無論主管、PM 還是工程師都很緊張；但有時越急犯的錯越多，下次不妨嘗試看看：

1. 讓工程師自己定下回報時間：建議將回報時間設定在 30 ~ 60 分鐘。
2. 回報時間內不要打擾工程師：大家都很急，如果耐不住性子打斷工程師的思緒，就可能導致需要更多的時間來解決 Bug。
3. 要求工程師定時回報處理進度：如果判定問題無法短時間解決，工程師就需要「定時」回報處理進度（若沒有定時回報的機制，有些人就算卡住了也不會主動說）；這個「定時」會給人增加一些安全感，並減少工程師被打擾的次數。

希望這篇文章的建議，能讓大家日後遇到 Bug 時合作更為和諧；如果您有不一樣的觀點，也歡迎留言討論。

舉個簡單的例子，如果你有在玩電腦遊戲，一定會先看簡介裡的「系統需求」，避免買了跑起來卡頓，甚至開不了的遊戲。

以 STEAM 遊戲舉例，在「作業系統」的部分，可能會建議電腦要有「Windows 7 64 位元 （不支援 32 位元）」以上的配備，如果你的電腦還是 Windows XP 32 位元，那基本上是無法運行的。

當然人不會像程式一樣那麼死板，但也只能做出自己認知範圍內的決策。

沒有相同權力，就很難擁有相同視野

因為筆者曾擔任過 Developer、Project Manager、Tech Lead 等角色，所以很清楚如果沒有真的站在那個位置，就很難理解對方為何會做出這樣的決策；畢竟不同角色面對的人、事、物差異極大，彼此的情報也有很大的落差。

當然市面上有非常多管理學、人際學、溝通學的書籍可以參考，業界也有很多優秀的講師分享、傳授自己的經驗；但說真的…無論讀多少本書、上多少堂課，都遠遠比不上自己實戰得到的經驗。

這不是在說學習沒有用，如果你有深厚的理論知識，在未來面臨突發狀況時，你的應對進退一定會比那些完全沒有準備的人更加完善（這裡我們排除那些天賦異稟的領導者）。

擴增自己的認知範圍

儘管職位不到，但我們還是有其他方法獲得實戰經驗。

就如同標題所述，大部分的主管都希望下屬站在他們的角度去思考，畢竟這樣他們交代任務會更為輕鬆。

向上兼容是跳出舒適圈的過程，需要勇氣與毅力。

在科技業，如果只站在工程師的角度，你可能會覺得沒必要幫主管想這麼多；但如果想在職涯上更進一步（ex：資深技術職、晉升管理職），懂主管在想什麼是非常重要的。

筆者建議要多與主管溝通，並適時表達自己的想法，在規劃任務時，可以看看自己與主管的想法是否一致；如果有分歧，可以與主管討論，了解他為何會做出這個決策（主管的決策也並非萬無一失，彼此的交流能讓規劃更為完整）。

這些交流是非常寶貴的，因為它讓你在取得權力前，能借用對方的視野去看問題，以此擴增自己的認知範圍；當然這一切的前提是，你有優秀的主管，並且他願意與你交流。

警告：

這邊特別提醒大家，如果主管要你幫忙做出「不符職權的重要決策」，筆者建議要裝傻推掉；因為有些主管將做決策的任務交給下屬，不是為了重用他，而是在找人背黑鍋。

結語

如果一直做相同的事，在職場只會獲得年資，待在久也不會提升自己的認知範圍。

而本文提出的方法，儘管無法擁有與主管相同的權力，但我們能借用主管的視野，透過一次次反饋去優化我們的思維。

但工作幾年後，卻發現這個理論未必全然正確；有時工作效率高、產出多的人，未必會獲得公司認可、主管提拔，甚至在某些環境中還會遭到同事的排擠。

究竟是道德的淪喪，還是人性的扭曲？就讓我們透過這篇文章來分析原因。

快速完成工作的同時，品質有兼顧嗎？

有些新人在入職後，想儘快證明自己的價值，或是做出比同期更出色的成績。

這樣的出發點可以理解，但以程式開發來說，如果只在意速度而忽略品質，那產出的成果可能會有許多漏洞，比如：

• 考慮不夠周全：未將各種可能性考慮進去，像是對使用者輸入的參數缺乏限制及驗證。
• 沒有撰寫測試程式：如果只透過簡單的人工測試就交付功能，那這樣在未來遇到 Bug 或改版時，就有可能動到原有的程式邏輯，但在上線出包後才發覺（ex：解決 Bug 上線後，發現這個改動造成其他功能出現新的 Bug）。
• 開發重複功能：在多人合作的專案中，有些新需求在過去已經有人寫好了基礎函式，開發人員只要在這個基礎上擴充即可；但有些人開發憑直覺，常常寫了功能近乎一樣的函式而不自知。
• 沒有考慮到程式碼的可重用性：如果程式在設計之初，沒考慮到現在開發的功能在未來可能會被重複使用，那就容易寫出高耦合性的程式，導致後續維護、擴充上的問題。

有時太快完成工作，會造成其他人壓力

這其實是看每間公司的氛圍，如果加入一間步調快的公司，那你會因為高效率獲得其他人的認可；但假使進入一間步調慢的公司，你就會因為高效率遭到其他人的排擠。

除了氛圍外，還有公司淡旺季的考量，有時淡季的任務做完就是做完了；就算你一直吵著要任務，主管手上也沒有合適的任務能指派給你，甚至會覺得你一直要任務讓他有點困擾。

小提醒：

儘管不是每間公司都這樣，但如果你做完手上的任務後，還自告奮勇幫同事完成他們的任務；長久下來，可能會變成你一個人要完成其他人的任務，並且被視為理所當然。

結語

透過這篇文章，相信大家能理解工作並不是求快就好。

但如果你工作效率高又能兼顧品質，那不妨好好利用剩餘的時間來提升自己，這邊筆者提出幾個方向給大家參考：

• 看過去的程式是否有改善空間：有些程式寫完當下覺得很棒，但過一段時間再去看，常常會發現有可以改善的地方，或是有更好的 Pattern 可以套用。
• 觀摩高手的程式架構：模仿是成長最快的捷徑之一，有時看高手寫的程式，會產生：「喔！原來這個問題還能這樣解！」的想法。
• 研究自己不夠了解的技術：有些專案是趕鴨子上架，我們對用到的技術並不是那麼了解；為了減少未來的隱患，建議利用這個空檔好好研究一下。
• 研究自己感興趣的知識：這裡的知識並不限於技術，如果職涯想朝管理職的方向發展，也能多吸收這個領域的資訊。

同樣的道理其實也適用於各行各業，希望這篇文章對大家有所幫助，也歡迎留言分享自己的想法。

最近身旁有位工程師朋友，他與筆者分享了部門主管在團隊 Tech Lead 離職後遇到的諸多問題，因為談話內容值得警惕，所以特別寫了這篇文章與大家分享。

有些工程師在升上管理職後，因為忙於專案管理，所以會慢慢把技術放掉，都交給底下的人去學習、操作；但只要一放掉，隨著年齡的增長，技術會越來越難重拾回來。

接下來就讓我們來看看，如果技術部門主管不熟悉技術，那在團隊的 Tech Lead 離職後，他會遇到哪些困境。

因為太久沒碰技術，各項判斷能力大幅下降

如果過去都靠 Tech Lead 協助判斷、整理報告，那現在只靠自己就會遇到許多問題：

• 用舊時代的技術評斷新時代的需求：科技日新月異，現在跟過去的技術也是天差地別，要一個只用過 HTML、CSS、JavaScript 的人，去判斷哪個前端框架更適合專案，說實話有點強人所難。
• 無法判斷各項功能的合理估時：因為脫離技術太久，如果別人說這個功能會用到 xxx 技術所以會花很多時間，自己也很難判斷是否所言屬實。
• 技術的可行性由別人說了算：有些 Feature 會需要用到新技術，但因為自己連開發環境都架不太起來，所以當別人說新技術不可行時也無從判斷。
• 面試只能碰運氣找人才：因為現在專案用的技術自己都不太熟悉，所以在面試時很難提出適當的技術問題，只能從對方的從業經驗來判斷。

這邊筆者補充一下，如果團隊氣氛和諧，每個人都有自己的專業，那上面所提出的問題是有機會避免的（前提是大家估時都很有良心、評估技術時都拿出專業態度，面試時主管也願意讓團隊成員一起參與）。

想要重拾技術，但是…

朋友說他的部門主管是想重拾技術的，但這個想法有點力不從心（部門主管年紀約 40 出頭，脫離技術近 8 年），主要原因為：

• 上班沒時間，下班沒體力：當初會放掉技術，就是因為上班忙於專案管理、談判溝通，還有一些行政上的雜事；而下班後精疲力盡，能學習的時間太少。
• 太久沒碰技術，挫折感太大：好不容易擠出時間學習了，卻發覺現在的技術都看不太懂，連跑範例程式都要搞一段時間，學習與理解能力跟年輕時相比衰退了不少。
• 快要學不動了：過去的技術相對單純，而近幾年技術則是爆炸性的成長，框架、套件、雲端服務如雨後春筍般出現，要學的東西越來越多。

30 歲跟 40 歲的學習能力、身體素質還是有一定差別的，隨著年齡增長、職務上升，技術要跟上潮流確實有其困難性，我們只能盡可能地保持對技術的敏銳度，至少要理解現在專案用了哪些技術。

結語

相信上面的案例已經充分地讓大家體會到，如果技術部門主管不熟悉技術，又沒人能給出合適的建議時，他將會面臨的種種痛點。

最後再統整一下筆者與朋友聊完後的心得：

1. 不要因為當上「管理職」就完全把技術放掉。
2. 技術不要完全倚賴副手（ex：Tech Lead），你要隨時做好自己面對的準備。
3. 不要讓自己落入重拾技術的窘境，要盡可能保持對技術的敏銳度。

只要還待在科技業，就不要輕易放棄技術；因為你很難保證自己永遠都是「管理職」，或是只需要做管理職的事。

寫這篇文章前，我訪談了周圍擔任工程師的朋友們（年齡介於 28~35），結果發現大部分的人對晉升管理職都興趣缺缺，如果把大家的想法整合一下，可以用一句話概括：「我們想擔最少的責任，然後盡可能領到更多的錢。」

其實這個結論有點顛覆筆者過去的認知，但在個別深聊後，覺得從他們的角度來說的確如此；因此這篇文章想跟大家聊聊「升管理職是為了什麼？」以及「為什麼不想升管理職？」這兩個議題。

升管理職是為了什麼？

這個問題每個人都有不同的解答，但大體上圍繞以下幾點：

• 薪水提升：管理職通常會有「主管加給」，職稱的提升也讓薪水有更高的上升空間。
• 職涯發展：有管理經驗後，在找工作時有更多的談判籌碼；即使下份工作沒有直接擔任管理職，也會成為未來主管的儲備人選。
• 掌握權力：擔任基層時只能聽命行事，完成自己範圍內的任務；而升上管理職後可以分配任務，組織大家共同完成更大的目標。
• 自我實現：因為看不慣過去主管的所作所為，所以想透過升官掌權來改變組織風氣，帶領團隊做出自豪的產品。

為什麼不想升管理職？

筆者再次強調，因為周圍的朋友多為「工程師」，所以他們不想升管理職的原因，可能與其他產業不盡相同：

• 薪水提升不如預期：如果公司的主管加給大約落在「5000 元」上下，這對有些工程師來說並不划算，因為管理職要負擔的責任大幅增加；對某些工程師來說，他們更傾向透過提升專業技能來獲取加薪。
• 管理職薪水未必更高：在科技業有個神奇的現象，那就是有些工程師的薪水比主管更高；因為實際產出成果的是工程師，擁有高度專業的工程師，有時比主管更難取代。
• 想喘口氣都難：當工程師時，在完成任務後可以稍微喘口氣；但當上主管後，不僅要確認每個人都在進度上，還要不時應對來自高層的壓力，如果團隊有人出包就等於自己出包，除此之外還要出席大小會議，幾乎不會有任何喘息空間（當然也是存在少數悠哉過日子的主管）。
• 不想管理人：很多人只是想在專業領域不斷提升，他們真的沒有權力慾，也不想一直與人溝通。
• 不想升官後與同事關係變尷尬：過去跟你聊天打屁的同事，在你成為他們的主管後，因為彼此立場的改變，談話內容與關係一定會受到影響。

場外小故事：

筆者身旁有位朋友對升管理職感到後悔，他原本以為升職後會獲得團隊的主控權，可以改善許多冗贅流程；結果把計畫上呈給高階主管時，直接被約去喝茶，聊天的主體內容是：「不要試圖改變既有流程！」

不久後這位高階主管提出一個普通人看到都會覺得不可行的計畫，朋友在看到後委婉的提出自己的看法，但高階主管卻對他說：「我只是告訴你我的計畫，反正到會議上挺我就對了！」

如果高階主管只是想找個聽話的人來當傀儡，那夾在中間的主管就算有抱負也很難實踐。

想跟大家聊聊

是否「升管理職」與是否「轉職」，這兩件事都要抱持「謹慎」的態度來思考、分析。

如果升管理職只是為了加薪，那筆者勸你三思；因為加薪的方式有很多種，而升管理職可能是 CP 值相對較低的一種。

不過讀者也不要因為這篇文章，而打消升管理職的念頭；畢竟不管是人生還是職涯，在實際進入那個角色前，都很難確定自己是否合適，我們能做到的只有冷靜分析。

這篇文章所提出的，也僅是「升管理職」所需要考慮的冰山一角，大家如果有不一樣的觀點，也歡迎留言討論。

過去同甘共苦，一起熬夜加班罵主管的同事，如今搖身一變，成了自己的直屬主管。

在升官後，他變得越來越陌生，不只講話的態度不一樣，還做出許多自己曾經唾棄的決策，他這樣跟之前的主管有什麼差別？

在職場上，除非升官的人德高望重，或比自己強大太多；否則很多人的腦中都會浮現：「為什麼升官的人不是我？」

如果你腦中出現這個想法，那日後與新主管合作時，就可能產生一些主觀意識造成的偏見；為了盡可能減少偏見帶來的衝突，今天這篇文章會與大家討論：

1. 心理因素造成的偏見有哪些？
2. 如何調適自己的心態？
3. 站在對方的角度去思考，爭取下次升官機會。

備註：本文不討論同事升官後性情大變、整組壞掉的情境。

心理因素造成的偏見

如果你也想升官，但最後升的不是你；那在心理不平衡的時候，容易帶著有色眼鏡去看對方的所有行動，比如：

• 討論解決方案時對方講話比較大聲 ➝ 你會覺得：「有官威喔！升官後講話口氣都不一樣了。」
• 指派只有你能解決的困難任務 ➝ 你會想：「怎麼難搞的任務都丟給我？是故意的吧！」

也許你們的溝通方式沒有改變，而你也比較擅長解決某些問題；但在對方升官後，偏見會導致你覺得對方無論做什麼都是錯的，就算他沒這個意思也容易被曲解。

升官是綜合因素考量，沒升上去不代表你比較差，只是對方的某些條件比你更為合適（ex：更懂主管的心、具備群眾基礎、過去展現過領導力）。

調整自己的心態

很多時候我們覺得換個位置就換個腦袋，假使對方是工程師升管理職，那你可能還會對他升官後的許多決策感到不解，比如：

• 這個需求一定要加班才有辦法完成，不久前你也是工程師，應該很清楚啊！？
• 過去我們不是都在吐槽前主管亂接需求，怎麼換了你還是一樣什麼都接？
• 這個時程估的太緊繃了，之前專案怎麼爆掉的你都忘了嗎？

我們感到困惑的同時，可以思考一個問題：「是不是之前的主管也是這樣？」

公司不會因為換一個主管就減輕部門壓力（沒增加就很好了），因此除非新主管有能力優化工作流程，或是擁有極強的職場社交能力；否則對基層來說，換誰上去都差不多。

在理解對方的無奈後，如果沒有離職的打算，就要調整自己的心態，無論感性還是理性都要把對方當成自己的主管，以後說的話、做的動作也要注意界線，像是：

• 以前你們一起罵主管，如果現在你還敢直接批評就可能要倒霉了。
• 過去如果會勾肩搭背，現在建議避免這類肢體動作。

每間公司的文化不同，請依實際狀況酌情參考。

但這不是指主管說什麼都要附和，如果公司只剩下一種聲音，那也不是健康的狀況。

站在對方的立場，成為副手

很多人在升官後是恐慌的，如果這時有人可以跟他站在同一陣線，他會特別有印象。

這邊提醒一點，你要成為的是「副手」而不是「奴隸」；幫主管最好的方式並不是替他把事情做完，而是讓其他人也願意服從新主管的命令。

「雪中送炭」才會被人記住，跟主管關係良好，與同事合作順利；如果之後有合適的主管缺，或主管再次升官時，你會比其他人有更高的機率升官。

對工程師來說，做事的能力很重要；但如果想在一間工作待得舒服，無論你想不想升官，做人都是很重要的（至少不要跟主管起衝突，跟同事吵架）。

以筆者的角度來看，錄取一個不合適的人是主管的問題，但這又牽扯到公司願意在這個職位撥多少預算；如果預算有限，主管通常會選一個「感覺」有潛力的新人，先找進公司再做培養。

但被錄取的菜鳥 PM 真的很可憐；在缺乏專業能力的狀態下，他很容易變成主管、客戶、合作部門的傳聲筒，運氣差點還會成為 RD 的受氣包。

當傳聲筒除了無法獲得成就感外，也容易厭倦工作環境待不久。

如何脫離傳聲筒？

PM 是部門對外的聯繫窗口，每天會收到來自各方的訊息。

但在剛到職的時候，菜鳥 PM 會有一種無力感，因為在對專案、部門、文化都不熟悉的狀態下，他只能扮演「傳聲筒」的角色，沒有處理訊息的能力，只能單純的轉發。

如果想脫離傳聲筒，首先要對收到的訊息有自己的看法，並有能力給出合適的處理方案；但想跨出這一步並不容易，因為看懂訊息本身就是一個門檻，如果看不懂訊息還亂回，只會把事情弄得更糟。

了解大家的專業

傳聲筒人人能當，所以沒有人會重視傳聲筒。

當然這不是說傳聲筒完全沒有意義，當 A 不想跟 B 直接聯繫時，就可以透過傳聲筒來轉達消息；又或者有些主管不想親自安排工作，就會列出清單讓傳聲筒來指派任務。

不過比起 PM，筆者覺得上面的工作內容更像是助理在做的。

想讓自己從「傳聲筒」進化為溝通的「橋樑」，關鍵點在於你了解大家的「專業」；每個行業都有自己的專業術語、不同的部門對同一個名詞也會有不同的解釋；如果想協調各部門的資源，PM 就需要像個翻譯員，把資訊轉換成大家都能迅速理解與吸收的語言。

資訊落差、認知不同是許多衝突的起點，如果能讓彼此都了解對方想表達的意涵，合作會更為順暢。

對專案有更高的掌握度

擁有專業後，就能理解每個「訊息、命令」背後的意義，這對專案是非常有幫助的，比如：

1. 能分辨對方提出的需求是否合理
2. 收到 Bug 時，有辦法初步判斷問題點與負責人
3. 遇到緊急狀況時，知道哪位 Key man 能處理
4. 對任務估時更有概念
5. 溝通較不容易被唬爛

如果擔任 PM 時能做到以上事項，會發現專案越跑越順，原本跟你作對的人，也會認同你的工作能力。

結語

PM 這個職位並不會熟能生巧，因為筆者看過有些人，一當傳聲筒就是好幾年。

但我相信絕大多數人選擇 PM 這個職位，並不是為了當傳聲筒；而是想在公司與大家齊心協力，一起做出讓眾人感到驕傲的產品。

筆者認為對 PM 來說，進入新領域並不算突破舒適圈，有能力在新領域彙整資源，使部門效益最大化才稱得上突破舒適圈。

我想上面這個情境，應該在許多公司不斷上演；規格變更的原因很多，比如：

1. 客戶突然想要增加／修改／刪除某個功能，而 PM 無力阻擋、談判。
2. 規格打從一開始就有問題，但開發到一半才發現。
3. 規格本身很模糊，每個人對規格的見解都不一樣，導致做出來的成品不符預期。

問題千千萬萬，但總歸都跟「人」有關係。

在文章開始前，筆者先跟大家取得一個共識：「PM 不是萬能的存在，客戶也沒那麼好溝通，規格一次到位的可能性趨近於零。」

在認知到規格變更是必須要面對的狀況後，我們接著來討論：「如何減少非必要的規格變更，盡可能降低自己的 Loading。」

準備相關證據

因為規格變更導致工程師加班的狀況並不罕見，但有些工程師的抱怨，會被不明事理的主管認為是能力不足。

為了避免上述狀況發生，我們需要準備「具體可量化」的證據，筆者建議從幾個面向來準備：

1. 記錄每次規格變更：有些規格變更並不是在會議上提出，而是透過私訊、電話或口頭告知，這些紀錄全部都要保存；如果團隊有使用專案管理系統，就能更好的記錄這些變更是由誰提出的（別忘記 tag 提出的人）。
2. 紀錄每次規格變更所增加的工時：絕大多數的規格變更，都需要花更多的時間來處理，這些時數都要記錄下來。
3. 哪些規格變更是可以避免的： 有些規格變更，是因為一開始根本沒想清楚，只是單純把客戶的需求寫上規格，這類問題有機會透過內部溝通協調來改善。

與主管溝通

建議一開始先跟 PM 溝通，如果溝通多次無果（請留存證據）再去找主管。

與主管溝通時記得拿出先前準備的「證據」，並強調以下幾點：

1. 頻繁的更動規格，會影響到專案穩定性（ex：測試程式都需要改寫）。
2. 建議先與客戶在規格上取得共識後，再進行開發（ex：先用 Wireframe 讓客戶確認流程），避免重工浪費時間。
3. 自己不是不能接受規格變更，但 A、B、C… 這幾項規格變更應該是可以避免的。
4. 現在的 Loading 實在太重（提出因規格變更導致的加班時數），假使規格變更無法避免，是否有補充人力或延長專案交期的可能性。

有些問題應該是主管要自己發現並去解決的，但主管日理萬機，偶有遺漏在所難免；我們能做到的就是透過「證據」把問題攤在陽光下，並說出建議的改善方向。

筆者過去曾寫過一篇文章，分享主管面對問題時會考慮的點。

結語

如果問題是長時間累積下來的，那想在短時間，或透過一套方案解決並不現實。

假使提出證據，並且充分溝通後還是沒有改善的跡象；而你也無法忍受這樣的工作環境，也許是時候考慮自己職涯了。

人，不是只有在痛苦的環境中才能成長；在合適的環境中，成長才會更加快速。

轉職一定要經過謹慎評估，筆者僅是提出個人觀點。

如果處理過程情緒管理不當，或是方法錯誤，就可能衍生出更多問題，甚至讓類似的問題一再發生。

恢復理智，整理思緒

專案出包後，有些高層會先把主管找過去痛罵一頓。

只要是人都會有情緒，沒人在被罵完後還能保持好心情；但如果把情緒帶到接下來的緊急會議上，就可能把問題擴散的更廣。

試想，如果會議開場你直接把脾氣發洩到成員身上，他們會是怎樣的心情？搞不好罵完後，有些人直接辭職不幹了（這個狀況如今並不罕見）。

因此筆者建議：「無論多想罵人，先讓自己恢復理智，確保自己能心平氣和的處理問題後，再召開緊急會議。」

召集相關人員開緊急會議

主管，尤其是技術部門主管，他們在收到回報後，往往能很快判斷出問題是誰造成的；但很多時候：「出包的人，未必有解決問題的能力，抓戰犯，對解決問題也沒有幫助。」

筆者不建議在會議中把矛頭指向特定人士，比較好的做法應該是先讓與會人了解以下幾點：

1. 問題的嚴重性、影響範圍。
2. 問題有多緊急，需要在 XXX 時間內解決。
3. 我判斷問題可能源自於 XXX…
4. 我會跟你們一起面對問題！

待大家了解問題後，詢問是否有人熟悉這塊功能，並儘可能安排兩個人一起解決問題（Pair programming）。

在高壓的狀態下，一個人獨自面對問題容易鑽牛角尖，甚至情緒不穩崩潰；但多一個人在身邊，除了能給予不同的想法外，還能起到彼此鼓勵的效果（當然這也是看人）。

問題解決後

向高層回報問題已經解決後，如果還在上班時間，建議趁大家記憶猶新的時候，立刻開會討論：

1. 問題發生的原因？
2. 現有工作流程是否需要調整？
3. 這類問題是否有可能避免，如果有，我們該如何制訂標準？
4. 如果再次發生類似的問題，是否有更好的處理方式？

於會議結尾，記得再次感謝大家的辛勞；就算是出包的人解決問題，也不要吝嗇對他的感謝。

如果是加班解決問題，建議隔天再開會討論；要是硬在大家都很疲憊的狀態下開會，得出的結論通常沒有什麼參考價值。

等出包的人冷靜後

除非出包的人不想幹了，不然在出包當下，最緊張的應該是導致問題發生的人。

但如果第一時間找他問罪，他有很大的機率會把精力放在推諉卸責，而不是解決問題身上；所以建議等問題解決且出包的人冷靜後，再單獨找他約談。

談話過程中，除了讓對方認知到自己的錯誤，還要使他明白再犯可能要面臨的懲處。

有些主管在問題解決後就想說算了，但如果沒有適當的警告，可能讓出包的人認為犯錯也沒什麼大不了的。

想跟讀者聊聊

每個主管都有自己的領導風格，因此想詢問讀者，當專案出包的時候，你們的主管都是如何處理的呢？你認同主管的處理方式嗎？

又或者你本身就是主管，面對這種突發狀況，你是如何應對進退的呢？有沒有可以分享的小撇步？

歡迎大家分享自身經驗，或許你的留言可以幫助到有需要的人。

今天就讓我們來聊聊「專案執行」時，如何讓合作的過程更加順利。

以筆者過去的經驗來說，團隊合作免不了要「溝通」，但每個人的溝通能力落差極大，有些人總覺得對方是自己肚子裡的蛔蟲，因此詢問問題、交付任務都沒說明細節，時常需要你來我往的多次確認。

為了減少彼此的衝突，我們可以針對常見的合作情境設計「格式」與「規範」。

工作記錄（Work Log）

如果團隊有使用專案管理系統，為了日後方便追溯與釐清狀況，建議填寫的內容如下：

• 如果實作的方向是討論出來的，請紀錄「與會人員」與「決議結果」。
• 如果使用到特別的演算法、技術、套件，請特別附註。
• 如果該 Ticket 完成後要由其他人接手處理（ex：後端完成 API 後交付給前端），請說明要執行哪些指令（ex：DB Migration、Seeder…），並提供相關文件。
• 如果發現 Ticket 完成的時間與估計的不同，請與 PM 討論並調整。

工程師之間的合作

律定格式，讓溝通有一定的品質。

• 明定 Ticket 執行順序：一個 Sprint 中，每個工程師手上有很多的 Ticket，但有些 Ticket 會有所謂的「前置條件」，為了減少等待的空窗期，工程師要在「 Sprint Planning 時溝通好」。
• 回報 API Bug：請說明是在「哪個系統」、「哪隻 API」、「什麼參數下」會發生。
• 回報 Web Bug：請說明是在「哪個系統」、「哪個畫面（截圖）」、「如何操作」會發生。
• 遇到自己無法解決的問題：請說明是在「哪個系統」、「哪個 Ticket」、「你做過哪些嘗試」、「你認為可能的解決方案」。

工程師與 PM 的合作

工程師與 PM 合作時，千萬不要惜字如金，大家都要把話講清楚；工程師要求 PM 做到的事，自己也要做到。

• 如果 PM 請工程師完成 Sprint 以外的需求：請說明「任務優先度」、「為什麼會有這個需求」、「可以將哪個 Ticket 排後面一點」。
• 如果工程師在開發過程中收到其他團隊的需求：請將對話窗口轉移到「PM」，由他來統一處理。
• 如果工程師請 PM 開 Ticket：需描述「哪個系統」、「為什麼會有這個需求」、「需求描述」、「估計時數」。
• 若 Loading 太重無法負荷：請說明「原因」，如：掛的 Ticket 數量太多、任務分配不均、某個 Ticket 實作遇到困難。
• 若多個專案同時發起高優先度的任務：有些工程師身上會掛多個專案，若不幸有兩個以上的專案同時發起高優先度的任務，就需要請「PM」協助排出優先順序。

為什麼都要由 PM 來開 Ticket？

有些工程師覺得自己開 Ticket 比較快，資訊多轉一手給 PM 根本是浪費時間，但這個制度是有原因的，如果不這樣做就可能導致：

• PM 對專案的掌握度下降：如果大家都自己開 Ticket，PM 會無法掌握每個人實際在做的任務，即使有 Tag 到 PM，PM 也未必有辦法看到每一則訊息。
• 專案進度偏離原定計畫：很多時候，工程師心中的任務優先順序跟 PM 是不一樣的，這導致最後在核對完成的任務時，會因為彼此的認知落差而產生爭執。
• 勞逸不均：有些工程師發現問題就想解，導致身上背了一堆 Ticket 天天加班，而其他工程師閒閒沒事做。
• 做了徒勞無功的任務：有些功能從專案的角度來看，可能不重要，甚至是不需要的。

為了避免上述的狀況發生，如果有任何想做的需求，請先與 PM 討論，讓 PM 從整體的角度來判斷（ex：如果你的 Loading 太重，PM 就可能將你提出的 Ticket 分配給其他人做）。

結語

筆者透過 3 個主題（專案啟動、初始任務、專案執行），與讀者分享制定工作流程的重要性。

制定工作流程是為了讓團隊運作更為順利，所以其中的規範、格式都要與成員充分討論；在彼此有共識的狀態下，工作流程才有存在的價值，否則會變成一種負擔。

最後再次提醒大家，文章的流程未必適用於每個團隊，但可以做為參考方向。

今天讓我們來了解，在正式開發前有哪些「初始任務」要做，以及每個步驟由誰負責。

STEP 1：規劃每個階段的時程

由「PM」將專案的需求拆分成不同的 Phase，這樣工程師比較能集中注意力在特定事物上，每個 Phase 都需要把如下的任務納入考量：

1. 要完成的功能（ex：前端、後端）。
2. 撰寫測試程式的時程（ex：單元測試、壓力測試）。
3. QA 團隊測試的時程。
4. 測試、正式環境部署的時程。

規劃時要保留「緩衝時間」，因為測試一次就過基本上是不可能發生的事情，往往需要預留 10~15% 的時間來修 Bug。

STEP 2：撰寫 Ticket 需求規格

由「PM」在專案管理系統上為每項任務建立 Ticket，建議需求規格的內容要包含：

1. Prototype 截圖：讓工程師了解功能具體的位置在哪。
2. 需求描述：說明這個功能是用來做什麼的，它跟哪些功能有相依性。
3. 相關計算規則：如果需求是「計算商品總價」，那就要列出「產品搭配、折價卷、信用卡優惠…」等多種排列組合的計算規則。
4. 使用的邏輯：搜尋欄位可以查詢的欄位有哪些？搜尋的邏輯是 And 還是 Or？
5. 關聯需求：像是後端做完 API 後交付給前端，就需要將兩個 Ticket 關聯。
6. 驗收標準：判斷這個 Ticket 是否可以 Close 的依據。

STEP 3：評估每個 Ticket 的時數

不同 Ticket 的難易度不同，這邊會由「Tech Lead」與「工程師團隊」一同評估，確認該 Ticket 由誰負責，並評估需要的時數。

筆者在這裡提醒大家，千萬不要勉強自己估出一個很難完成的時數，不然卡關時，會影響到後續一系列的時程規劃（但也不要估出不合理的時數）。

如果某個 Ticket 預估的時程超過 6 小時，建議要再做拆分，否則很難衡量每天實作的進度。

STEP 4：確認能否在截止日前完成

只要是專案就一定有截止日期，「PM、Tech Lead」需要在這個階段將 Ticket 的時數轉化為甘特圖來審視，若發現已經超過截止日期，那勢必要再做一些調整，比如：

1. 簡化部分功能（ex：原本要用 Auto-Complete，現在改用一般的搜尋）。
2. 規劃 MVP 讓客戶使用（ex：原本要經過一系列複雜流程才能建立的資料，先用 Seeder 代替，以此大幅減少工程師的開發時間）。

這邊不建議堅持原計劃完成所有功能，因為快速開發所累積的技術債，於未來要花更多的時間處理。

STEP 5：分配 Ticket

由「PM」規劃這個 Sprint 要完成哪些 Tickets，然後在 Sprint Planning 時進行細節分工；假設一個 Sprint 為 2 週，建議每個人身上掛的 Tickets 總時數不要超過 65 小時，因為：

1. 時常會有臨時的會議、需求、Bug…等意外事件，需要保留緩衝時間。
2. 在專案初始階段，我們無法保證是否有遺漏的規劃、邏輯的錯誤，若把時間塞滿就很難有轉圜的餘地。
3. 有時舊專案會有緊急狀況需要優先處理，這個也會吃掉不少時間。

小結

專案的「初始任務」非常重要，若忽略其中一個步驟，都等於埋下一顆未爆彈。

相信經過「專案啟動、初始任務」這兩個主題，大家都能體會專案前期規劃、評估的重要性；但如果開發時 PM 與 RD、RD 與 RD 間的溝通不良，專案在執行時也會困難重重。

因此在下一篇文章中，筆者會針對常見的合作情境，分享實用的「溝通格式」，讓專案執行時更為順利！

以筆者過去的工作經驗來說，如果工作流程只靠口頭制定、團隊默契，在沒有明確的文字規範下，大家真的無所適從，當新人加入時還需要更長的磨合期。

而制定團隊的工作流程，能夠讓成員了解自己在各階段要負責的任務；儘管一開始的工作流程可能很粗糙，但只要有了第一版，流程就能在日後的實踐中不斷優化與完善。

由於「為什麼軟體團隊需要制定工作流程」這個議題的涵蓋範圍較廣，所以筆者會拆分成「專案啟動、初始任務、專案執行」等幾個主題進行分享，今天這篇文章先介紹「專案啟動」時要做的事。

內文以「Web 開發」為範例，不同行業請酌情參考。

STEP 1：需求訪談＆初步規劃

這個階段的目標是「初步確認需求、討論需求可行性、讓客戶認可 Wireframe 流程」。

1. 由「PM」與客戶討論需求，在收集完需求後，將其以心智圖（Mind Map）的方式呈現。
2. 接著請「UI/UX」依造需求設計 Wireframe。
3. 待 Wireframe 完成後，「Tech Lead、PM、UI/UX」一起開個會，初步確認流程以及功能的可行性，並討論是否有需要調整的部分。

有些客戶會提出一些會異想天開 or 奇怪的需求，如果在初步規劃就發現這些問題，在反駁的同時請給予對應的建議，比如：

• 我想要一頁顯示 1000 筆資料方便搜尋：有些人還是習慣用「眼睛」來搜尋，但這樣的效率極差，當資料量大的時候還要翻頁；筆者建議與客戶進一步討論他實務上會搜尋的「欄位」有哪些，也許「篩選」功能更符合期待。
• 我想要把過去一年的出貨訂單匯出至 Excel 來統計數據：客戶過去可能習慣用 Excel 函數來分析數據，但這個功能實際上可以做成系統的「儀表板」。

STEP 2：確認具體需求＆完善規劃

這個階段要將「原本模糊的規格具體化、完成 Prototype 設計」。

1. 在客戶確認完需求及Wireframe 的內容都沒問題後，請「UI/UX」開始設計 Mockup。
2. 由「Tech Lead」確認 Mockup 上的細節是否都有考慮到（ex：哪些欄位適合拿來搜尋、不同權限看到的畫面、有哪些元件可以設計為共用模組）。
3. 待 Mockup 上的功能＆流程都確認沒問題後，請「UI/UX」開始設計 Prototype。

血淚史提醒：

專案初始的設計盡量從 Wireframe 開始，就算專案規模較小也不要直接畫 Mockup；因為在前期客戶的需求會時常變動，就算突然加大投資，小專案變成大專案也是很常見的，若使用 Mockup 會需要花更多的時間在調整上面。

STEP 3：向團隊成員說明

在需求與流程相對穩定後，接下來就要與「團隊成員同步資訊」。

1. 由「PM」向團隊成員說明系統的功能與流程，確保大家理解這個專案要完成的目標（這邊建議先用心智圖說明架構，再用 Prototype 模擬實際流程）。
2. 由「Tech Lead」向工程師團隊提醒各功能在設計上要注意的細節（ex：哪些欄位要設計 Auto-Complete、是否有特別的 Validation Rules、某些功能需要提前 Survey 避免卡關）。

這個階段主要是讓團隊成員對每個 Feature 都有具體認知，然後評估自己感興趣 or 擅長的 Feaure，若發現有沒碰過的技術也能提前研究。

小結

專案啟動時，「Tech Lead、PM、UI/UX」在各階段都要做好把關。

相信有實務經驗的讀者，都很清楚「明確的需求、具體的流程」對工程師來說有多麼重要；如果一切都非常模糊，那後續開發一定會遇到各式各樣的問題。

在團隊成員都了解專案的目標後，為了保證後續開發順利，我們還有一些「初始任務」要做，這部分筆者會在下一篇文章與大家分享。

PM 雖然被稱之為專案「經理」，但在大多數的公司並沒有管理實權；如果想讓 RD 跟你配合，至少要對技術要有一定程度的了解，並能聽懂對方想表達的內容。

本篇文章會分享一些實用技巧，讓 PM 獲得更精確的資訊來判斷 RD 的估時是否合理，並告訴你遇到不配合的 RD 該如何應對進退；話不多說，讓我們看下去！

了解對方的專業真的很重要嗎？

筆者很負責任的跟你說：「超級重要！」

當然這不是要你成為該領域的專家，但至少要具備「溝通、評估」的能力。

以 Web 開發舉例，如果你不具備前端、後端、資料庫的概念，你怎麼評估及分配任務？難道只靠感覺來判斷工程師的估時是否合理？

就拿筆者過去的經驗來說，儘管我有全端開發經驗，但在擔任公司 PM 時，因為缺乏與設計師合作的經驗，導致合作初期無法判斷設計師的估時是否合理。

了解專業是為了評估出「合理時間」，並在遇到不合理的狀況時，能適時提出自己有疑問的觀點。

在此特別強調「不要亂估時」！一但被發現會破壞彼此的信任，也是不尊重自己專業的表現。

如果 RD 的估時超出 PM 心中的時程

原則上，PM 都是秉持相信 RD 的態度請他估時的；但有時 RD 估出來的時數，會讓人懷疑自己是不是被糊弄了。

如果專案有時程壓力，PM 會需要更精確的資訊來協助判斷，比如：

1. 向 RD 詢問該 Task 的細節：就像標題所述，PM 需要了解這些時間花在哪裡，是否需要拆成多個 Subtask？因為有時一行字的需求，背後可能涉及到資料庫的遷移、後端 API 改寫、前端畫面調整。
2. 是否有擅長這個領域的人：有時會有這麼長的估時，是因為指派對象不擅長這部分的技術，或是缺乏相關經驗；如果時程寬鬆，那是一個很好的學習機會，但如果有時程壓力，還是看誰擅長就由誰負責（如果 PM 不清楚每位成員擅長的領域，在 Planning 階段可以請資深工程師 or Tech Lead 從旁建議）。
3. 如果是全新領域：RD 在面對陌生的技術時，也只能憑感覺亂估；因此建議開一個「研究新技術」的 Task，讓 RD 先對技術有基礎的認知，在這之後估出來的時間才有參考價值。
4. 是否有最小可行性方案：如果不是技術達不到，而是時程根本不夠，那就要考慮縮減非必要功能，或是採用替代方案。比如說有個需求是「使用者列表」，在 API 設計上，工程師會覺得除了「查詢」外，應該還要有「新增、修改、刪除」的功能，但如果客戶沒有這些需求，那或許先階段用 Seeder 把使用者寫入資料庫就可以了。

RD 估時較長，還有一個常見原因，那就是面對「需求變更」時的緩衝時間；理想上需求變更應該要延長專案時程，但實務上專案的截止日期很難調整，因此在估時上多少會預留一點空間來保護自己。

這個部分涉及到組織文化、公司面對客戶的話語權、主管態度等多個方面，如果讀者對這個話題感興趣，筆者會在獨立一篇與大家分享。

適當的借勢

如果 PM 初來乍到，而 RD 年資很深，那有可能遇到 PM 叫不動 RD、RD 明顯亂估時的狀況。

在職場上我們盡量與人為善，但假使對方就是很皮，你以禮相待他還是使勁搞破壞；那適時的請主管協調也是有必要的，不過這個方法偶爾為之還行，如果常常使用不但會被 RD 討厭，還會讓主管懷疑你的工作能力。

每間公司的文化不同，但拿人手短、吃人嘴短幾乎是共通的；有時請 RD 喝個下午茶，你會發現大家突然變得很好溝通（每個人的社交方式不同，也歡迎讀者分享自身經驗）。

結語

有些 RD 被詢問估時的細節時，會覺得 PM 不尊重專業；但 PM 真的是只是想了解細節，並尋求更好的方案。

筆者認為 PM 與 RD 是平等互助的關係，只是彼此的立場與看事情的角度有些許差異；如果總是刁難對方，其實是在損害自己的 Credit，並讓主管難做人。

「RD 與 PM 的攻防戰」這個議題就先講到這邊，希望有讓大家看到不同角度的思維模式，如果喜歡類似的內容也歡迎留言告訴我～