本篇文章旨在探討如何改善專案經理與工程師之間的溝通，以提高專案的成功率和團隊合作效能。
PM 到底要如何與工程師溝通才不會激怒對方呢？這個問題是所有 PM 都會遇到的，經驗不夠或是反應不夠快的人可能剛開始就被討厭了。
打開搜尋引擎，輸入關鍵字 PM RD 溝通，出來的結果滿山滿谷都在教 PM 如何與工程師溝通。這就讓我好奇了，既然溝通技巧是 PM 基本配備，那麼溝通有問題時，是工程師問題還是 PM 的問題？似乎大部分文章都是在告訴 PM 如何不惹怒工程師，那真實問題出在 …
強調：本篇文章討論的是純軟體業。
在工程師為主的討論區或社群，「PM」兩個字彷彿是哈利波特中的那個人的名字，千萬不可被提及，一但有人提到了相關議題，肯定是千夫所指、嫌棄聲不斷。總結一下不外乎是沒有專業、只會出一張嘴、傳聲筒、只會改需求，這話題講下去肯定是上百則留言或訊息講不完，那真實的情況真的是如此嗎？
在探究之前，不如我們先來思考一下
工程師心中認為完美的 PM 是什麼樣子？
PM 心中認為完美的工程師是什麼樣子？
QA 是在軟體開發過程中，確保產品品質、穩定性和可靠性，從而提高使用者體驗、滿意度的職務。它涉及測試、撰寫測試案例、定義 BUG、追蹤 BUG、以及與開發團隊協調等，做為 QA，絕對是軟體開發過程中非常重要的一個環節。
手動測試
手動測試 QA，在台灣的軟體界，蠻大比例是屬於這部分職能(可能會寫程式的都被抓去當工程師!?)。手動測試通常是基於需求文件和設計文件，設計測試案例和測試方法，然後執行這些測試案例，檢查功能是否符合預期的要求和標準。手動測試QA 最大的價值與優點在於人力能夠發現自動測試無法發現的缺陷，而缺點自然是無法快速執行大規模、重複的測試需求，因此通常需要結合自動化測試進行綜合測試。
自動測試
自動測試通常使用自動化工具和腳本來執行測試案例。相比於手動測試，自動測試具有更快、更精確、更穩定的特點且能減少部分手動測試的人力成本。但是，自動測試也有一定的限制，例如無法測試新需求、圖像、影像和音樂等，且前期需要投入一定開發成本和資源。因此，實務上仍然需要結合手動測試和自動測試人員。
很多團隊都認為全面轉變為自動測試就不再需要手動測試QA了。
我認為這是一個非常嚴重的錯誤。首先，撰寫自動測試的前提是須要有完整的測試案例，這些測試案例都是需要人為優先撰寫的。
其次，一個新的功能開發出來，緊急狀態下絕對是手動先進行測試，絕對沒有時間撰寫自動測試，最後是是自動測試能夠測到的範圍絕對沒有手動來得廣泛與深入。
自動測試適用的範圍應該是確保每次佈署新內容時，沒有影響到既有的完整、主要功能，
然而這樣的測試是非常 routine 且不可能每次佈署都做一次，這就能交給自動化測試，也就是 Acceptance Test。
另一個主要情境是確保主要功能正常的測試，也可稱作On duty Test。假設你們的產品是 7*24 不停歇的服務，或是內容或穿插相依外部的服務，那會很適合這種測試模式。使用自動化腳本，定時走一輪主要功能，確保當下服務都正常。
因此，我們應該了解自動測試的優勢與優點在何處，而不是一昧的認為自動測試能夠取代手動。
ChatGPT 也許只是一項跨時代的產品，乘著智慧 AI，接受它，站在巨人的肩膀上才是未來之路。在這篇文章我將演示透過 ChatGPT 來輔助撰寫測試案例，進而大幅度提升 QA 的效能與產值。
面試是找工作的必經之路，但不是每個人都能一次就成功。
其實這本來就不是一件容易的事情，首先要在短短的幾分鐘之內濃縮、精煉你過去的所有經歷，自我介紹後就要接受各種意想不到的提問，如果是針對過去經歷或是開放式問答還好，技術層面就非常頭痛了，如果賭到了你學過的那就賺到，遇到不會的，就考驗你的臨場反應了。
這不算是本篇想講的內容，不過我覺得還蠻有幫助的，未來再仔細地討論這塊
當你面試失敗時，可能會感到沮喪和失落，但是不要放棄，這代表你擁有機會學習和成長，如何記取教訓並繼續改善自己是非常重要的。
得知面試結果後，放下一切，用力讓腦袋排空兩三天(工作還是得繼續做)。
除了你能控制的因素外，面試結果也很吃你和這間公司的緣分，例如：該職缺可能沒這麼缺，那公司會傾向找更符合的人才，難度無形中就提高很多; 當時面試官心情可能比較差，看到的都是你的缺點; 決策者可能能力經驗不足，無法發現你的優點等。當然還有各式各樣的狀況，這都不全是應徵者的問題，因此才會說，緣分真的很重要。對於那些不可控制的因素，就放寬心，專心注重在自己可控的事物上。
經理人之道：技術領袖航向成長與改變的參考指南
當我讀到這本書時有一種相見恨晚的感覺，不愧是眾多大師推薦的一本關於面向專案管理(Project Management) 的好書，對於一個軟體人來說這本書可以說是必讀的。從剛入門的軟體工程師新手給予很好的建議，再來是資深工程師、技術領導，到後來轉職為管理者的全方位教學。這樣的道路也可以說是常見的職涯規劃，當然，想要繼續鑽研、醉心於技術的人，仍然也能獲益良多。
軟體工程師
作為剛入門的職稱，會發現以前在學校學到的技術等級完全不敷使用在產品、服務上，需要不斷精進其中的技巧。剛進入職場，總有著資深的前輩、架構師罩著，除了跟隨他們的腳步走，漸漸得也要學習看待問題的思維，進而提升自己在專業上的能力。另外一點更重要的是找尋自我，了解自己想要的，維護自身的權益，如果沒有頭緒，本書前面章節提醒、舉例了很多相當重要的部分，讓讀者能夠得到相當大的助益。
資深軟體工程師 & 技術領導
就我的職涯經驗中，每間公司對於 Tech lead 的定義不太一樣，有的像是純技術負責人，有的則像是專案負責人，需要負責到專案的設計、開發、交付時程與品質等，這部分職責會與專案經理相重疊，如何共同合作是一門很大的學問而其中的細節與各間公司組織架構有非常大的關係，無法完全套用特定規則。
無論如何，Lead 這個字眼終究與管理、溝通有著極大的關係，勢必是需要學習開發程式以外的技能，這點非常吃重個人特質。有些人始終不想碰上管理，畢竟面對人與面對電腦差異慎大，有「人」的部分就是隨時在變化，需要隨時準備好改變與突發狀況，相較於純開發上，就顯得複雜非常多。
專案經理
專案管理其實是名詞上的誤解，該關注的絕對是「你的成員」，而非僅有專案或項目上的進度，能夠完成專案的是人，而非進度表上的數據。
從第四章開始進入本書的管理重點，內容繁多，讀第一遍時感到極其硬核，做了一些筆記後再度閱讀，發現這些細節與重點並不複雜，關鍵在於「養成習慣」，平常生活中多了解、觀察成員，定期給予正面讚賞與建議，千萬不要給予「驚喜」，這可是管理者的首要大忌！！
人家常說選擇好的老闆跟到底就對了，好的管理者除了足夠關心成員、培養他們的職涯也照顧到心理層面。
你是好的管理者嗎？或者你有跟到對的老闆嗎？
認真說來這邊的心得僅有包含大部分內容，書中後半段描述的是管理多個團隊、高階經理人，礙於本人還沒到那個層級，雖然閱讀完但仍有部分內容無法完全內化，就不在這裡獻醜了。
這個章節比較像是給新鮮人的建議。
哪一間店會免費贈與主打商品？會不會虧本虧大了啊？看似極度虧本的行銷手法，背後與潛在的商業利益不是一般人能想像得到的！
只要下載一蘭拉麵的APP，每天系統就會自動贈送兩張兒童拉麵券，12歲以下的小孩都能免費吃到一蘭拉麵喔！而且不用搶券沒有限量沒有期限，每天就是固定會有兩張自動配發給你！(我沒有業配，一蘭也不需要業配XD)
剛知道這個消息的時候頗為震驚，哇！兒童拉麵大概也是一般拉麵大小的一半，這樣不會虧本嗎？
仔細想了一下發現這個真是很強大的前瞻性市場行銷啊！
首先，一蘭拉麵的聲量在臺灣大到不可思議，完全不需要做這種行銷手法(我是這樣認為)，光是現有店舖非用餐時間的排隊數量就非常驚人，既然生意這麼好，大家都這麼買單，那還有需要送兒童拉麵嗎？
我們來思考送兒童拉麵的目的是什麼。會攜帶12歲以下的兒童，肯定是家庭為單位，不得不說，兒童基本上是大部分餐廳頭痛的對象，一來難以控制其他人用餐環境品質，二來用餐時間拉長，三是用餐後可能難以收拾。一蘭膽敢擁抱兒童用餐，主要原因是座位區隔，使得他人不太受影響，再來是餐點單一沒得選，就是給你一碗拉麵，你能吃多長時間呢？也許用餐會是一般成人的兩倍長，但這個成本是絕對值得的。
有聽過一個說法，餐飲店如果賣的東西越多、選項越多，其淨收入與餐點品質一定都是偏低的。仔細想想，市面上有些餐廳真的賣很多種類食物，還真的不太好吃！！我怕被告，就不說哪間了XD
回到一蘭身上，到底免費招待兒童拉麵有什麼好處？我能想到的大概有以下幾點：
Toby 是一個 Chrome 瀏覽器的擴充套件，可以幫助使用者更有效地管理個人或組織網頁連結。
Toby is a Chrome browser extension that can help users more efficiently manage personal or organizational web page links.
上述情境你是否時常聽到，抑或是某某連結很常使用，但是又沒有同步或是共同分享功能呢？
Do you often hear scenarios like the following, or encounter situations where certain links are frequently used but lacking synchronization via devices or shared functionality?
“Do you have a link to something? Can you share it to me?”
“Does anyone know the dev back-office link?”
“Who has a link to a certain webpage, can someone give it to me?”
Toby 是一套網址管理的 Chrome extension，對，它的最基本要求就是要使用 Chrome 瀏覽器。
Toby is a Chrome extension for managing URLs, and yes, its most basic requirement is to use the Chrome browser. Here is the official website of Toby.
30-60-90 日計畫(30-60-90 Days Plan) 用來指導新進員工並且有明確評估是否適用的依據。除了針對新進員工，在面試時提出此計畫來為自己的面試加分！
我們常聽到新進員工有適用期三個月，這三個月是哪裡來的呢？(如果是更高的職務可能也有六個月的)
這兩者其實可以說是一樣的，通過 30-60-90 日計畫，有計畫性與標準的訓練新進員工，使得雙方都能夠達到目的，減少彼此浪費，這就是目的與好處。還有像是確保每位 Mentor 帶出來的員工都能盡量俱備一致水平、減緩新進員工對環境、工作內容不熟悉的緊張感。
除了適用於剛到職的員工，其實 30-60-90 日計畫也非常適用於面試，當你選定要面試的公司與職位時，可以制度這樣的計畫給面試官，了解你入職後如何上手工作，替整體面試印象分數加分！
建立計畫就是設立目標，這個目標需要有這些特性：
當一個人對特定領域有專業知識時容易陷入知識的詛咒中。這種詛咒可能會對交流和溝通產生負面影響，因為他們可能會假設其他人有同樣的知識水平，特別是當專業術語難以被非專業人士理解時。
「知識詛咒」是一種心理學上的偏見，牽涉到人們對自己擁有的知識和技能的高估，以及對其他人的知識和技能的低估。這種現象可能會導致專業人士和非專業人士之間的溝通問題，並對專業人士在說服其他人方面造成挑戰。
知識詛咒是一個早已被廣泛研究的現象。當專業人士與非專業人士進行溝通時，專業人士往往會使用專業術語和特定的詞彙，這些詞彙對於非專業人士來說可能是陌生且困惑的，進而產生障礙並阻止溝通，最終導致專業人士在說服其他人方面面臨著極大的挑戰。
在 1990 年，伊麗莎白·牛頓(Elizabeth Newton)在史丹佛大學透過一個簡單的實驗來驗証這個現象，獲得了心理學博士學位。
在實驗中她將參與者分為”演奏者”與”聽眾”，由演奏者敲擊桌面來演奏耳熟能詳的歌曲，如生日快樂歌這種，聽眾則負責猜是甚麼歌。起初，演奏者預測猜對機率為 50%。
最後呢？120 首歌曲，只有 3 首歌被正確猜對。
軟體工程師面試一定會有測驗，程式相關的問題紙上沒測驗，面試過程也一定會問到，就不在這篇提了。
如果面試的公司屬於外商或者較大的企業，也有機會透過人格性向測驗來了解你是否符他們要的性格。另一種則是邏輯與文字推理能力的測驗，這是本篇要分享的。
這種測驗的名稱為：Apitutde assessment 或 Aptitude test，能力評估或測驗，請務必習慣這些單字。
邏輯推導類型的測試早期是使用紙本，提供一系列題目讓你填寫答案，現在是線上網頁應考居多。
例如：(Copy 自 IndiaBIX)
1 | All the trees in the park are flowering trees. |
等下！為什麼是英文!?
基本上外商或者線上服務的公司都是國外的，沒有中文讓你選擇，所以你的英語能力要有一定程度。
上述這個題目是其中一種類型，給你一段描述，要你推理哪些情況是正確的或者可能的。而且一道題目大約只有 50秒 的時間讓你作答，超過就等於壓縮後面作答時間。
對 Oplog 不熟的朋友，建議先閱讀之前的內容
四年一度的大型盛事終於結束，來回顧一下這個我們都知道，卻隱藏得很好的 MongoDB 殺手 - Oplog。
在流量真正進入之前，我們進行了多次的功能驗證、壓力測試，確保在各個環節都沒有問題，對於各個服務的狀態也甚是滿意。展開了 MongoDB Atlas 監控，正式迎接挑戰！
剛開始我們很明顯感受到流量帶來的壓力，各項數據都還是穩定、可預期的，這時候是第一個錯誤。
等到第二天、第三天，我們開始發現 Oplog 的 headroom 開始有降低趨勢，這部分根 Oplog GB/Per hour 是呈現相反的，畢竟量多了，自然餘裕就開始減少。
第一個錯誤是沒有仔細評估合理性，對於流量的增長，到底多少是合理的呢？這個在事情必須要充足的測試才有辦法進行推斷。
這個問題也衍伸出另一件事，就是全服務的壓力測試非常重要，在 pre-production 環境應該事先給予充足的壓力測試。