104學習精靈

下班後的產品工程師

下班後的產品工程師
共學教室關注者 26 人共學者 6 人
關注教室
加入共學
置頂公告 ◼ 方格子：https://vocus.cc/user/@larry ◼ Medium：https://larrychien.medium.com/
Larry

產品工程師

2023/06/17

讀書會不只可以看書，還可以挖坑給人跳 👍
👉 #為什麼要參加讀書會
起心動念是想知道講者是怎麼詮釋書中傳達的資訊、想知道其他參加的同學（還是讀友？）們又有什麼樣的看法，藉此刺激自己的思考，激盪出不一樣的觀點和火花。
👉 #為什麼想要寫 #30天寫作挑戰？
我相信有輸出才是最好的輸入，會想要挑戰 30 天寫作，除了宣示文所說以外，還包含了：
1️⃣ 練習針對主題給出有架構的回覆跟內容
2️⃣ 幫助自己整理擅長領域的想法
3️⃣ 觀察自己在寫作時會遇到的困難及心得
4️⃣ 把自己遇到的狀況帶到讀書會裡，尋求講者的回饋
5️⃣ 養成寫作習慣
至於有沒有達到，可以等我心得文寫出來之後再跟大家分享。
👉 #一個人挑戰很累，所以把其他人 #拉下水 😉
這就是為什麼我會建議講者朱騏要試著給參加讀書會的人一個個不同難度的挑戰，從寫完 1 篇文、5 篇文、10 篇文……將遊戲化融入挑戰之中，獲得的獎勵除了是自己寫出的文章，還有挑戰成功的獎勵，試著透過內部趨力跟外部驅力雙管齊下，讓大家循序漸進，減少動手寫作的阻力。
此外也鼓勵他要成立讀書會的群組，讓大家在寫作之餘，也能夠互相討拍（？）、鼓舞打氣，增加外部激勵的效果，幫助彼此繼續把挑戰完成。
而我自己的內在驅力則是除了寫作本身外，在把大家拖下水時自己也要以身作則跳下去泡在水裡，這樣才會有第一手的經驗，知道持續寫作的難處在哪，也不會站著說話不腰疼。
如果對於讀書會、想嘗試持續寫作有興趣的話《【2023 朱騏線上讀書會】邀請你一起讀 4 本書，學習透過線上寫作建立個人品牌、發揮個人影響力》從 06/25 起至 10/29 有四場讀書分享會，除了講者朱騏會分享讀書心得以外，還有讀書會專屬的群組，在裡面可以跟其他對於寫作有興趣的同學一起完成一個個的寫作挑戰，讓自己真正的開始寫作，知道自己的寫作習慣，了解在寫作上碰到的瓶頸，甚是還能第一線地跟講者討論怎麼解決，讓自己有實質的產出，也有內在的收穫。
0 1 527 0
Larry

產品工程師

2023/06/16

工程師要怎麼和 PM 解釋技術？
前幾天寫了一篇《如何在沒有技術背景下怎麼和 RD 討論技術可行性？》，這篇主要是想從 PM 的角度來思考，要怎麼跟工程師溝通討論，今天我們立場互換，來說說工程師要怎麼樣跟不懂技術的 PM 解釋技術。
👉 #明知是蠢問題還問的，#不會是你同事。
會問蠢問題的人，絕大多數都是他／她並不知道這是個蠢問題，如果知道還問，要馬故意要馬瞧不起你／妳。但我想以工程師的聰明才智來說，一定能夠分辨是不是故意的，對吧？
不管是抱持著做善事、幫助他人的心態，還是為了讓自己可以更好把任務完成，請務必試著用對方聽得懂的語言來解釋。
也許你／妳會想：憑什麼是我花心力來解釋，而不是 PM 自己花時間理解技術。這是因為你／妳已經花了求學階段加上工作時間的投入在鑽研，PM 不可能像你／妳這麼了解技術的極限和瓶頸在哪，因此為了讓後續兩邊都好做事，由工程師釋出善意總是好事的。而且市面上這麼多難溝通的工程師，只有你／妳最能溝通，馬上就拉出不一樣的格調了。
👉 #細節不用講，#但能解決什麼問題一定要說
我們能夠區分 http 跟 https 的差別、5xx 跟 4xx 的 status code 該找前端還後端、什麼是元件內的 state 什麼是同步到資料庫的 state……。但是 PM 不見得能夠理解這些實作細節，甚至並不知道怎麼將這些資訊識別出來，而強者工程師如你／妳，就是能夠知道怎麼做到這些事。
儘管細部要怎麼做到這些事情，其他工程師會很有興趣想知道，但可惜 PM 的職責並不在此，因此他們最在意的不是實作的細節，而是在意這些技術的差異是要解決什麼樣的問題：是要解決資訊安全的問題、是要分辨是網路還是伺服器出了問題、還是使用者的資料在重新整理頁面後該不該保留……。這些技術的應用解決了什麼問題，才是 PM 最為在意的。
好啦，如果真的要講細節，至少要先把結論講出來，不然 PM 也不知道細節可以有什麼幫助。
👉 #給建議的時候，#至少想想兩種方案
第一種是理想情況下，可以解決問題又能夠具備可擴充性的方案；第二種是現實情況下最土炮最無腦的處理方法。但切記這兩個解法不是拿出來給 PM 選的，是來幫助自己思考「有沒有第三選項」。
我們已經很習慣用自己的系統一，不假思索就能想到前兩種方案，但系統二沒進場的話，就不見得能夠找到最適合當下的處理方式，因此要讓自己的系統二醒來開始運作，就會需要逼自己思考第三選項的可能性。
👉 如果你／妳 #真的不想做……
需要先辨別一下不想做的原因是因為對產品有害、沒有挑戰性、對於技術太過陌生、不想花時間做……。
需要內部歸因一下，知道自己之所以不想做的原因為何，如果是對公司或產品有害，或是有什麼潛在的風險需要辨明（例如不熟技術），那就大方地說出來，PM 不懂技術都願意開口問了，工程師不懂全部的技術有什麼好羞恥的？
但如果是自己任性地不想做……請長大好嗎？大家都是出來工作的，不是你／妳的保姆或僕人，需要事事都順著你／妳的意思做。
希望各位工程師能夠看完今天的文章之後，不要覺得我在講幹話，而是能夠理解善待 PM 也是善待自己的一種解法。
2 1 2881 0
Larry

產品工程師

2023/06/15

頭銜／職稱重不重要？
進入職場工作後，就開始有了各式各樣的頭銜和職稱，工程師、PM、設計師、業務、行銷……。也隨著在職場的打滾，逐漸開始看到有些不一樣的頭銜：資深工程師、產品總監、首席設計師、業務經理、行銷副總……。這些頭銜看起來光鮮亮麗，似乎每個人都應該以爭取到頭銜為目標，作為職場的努力方向，但真的是這樣嗎？究竟頭銜和職稱到底重不重要？
👉 #頭銜很重要
有些公司在看到廠商派來的業務只是專員時，會透露出一股不屑和輕蔑的態度，甚至覺得這家廠商不尊重自己，派來的層級居然是「專員」，因此會有業務經理滿街跑的說法，為的就是避免被不知道哪來的客戶用不平等的心態看待。
這時，頭銜就很重要，因為它可以讓公司不會因為莫名其妙的原因而掉單。
有些需要建立名聲和品牌印象的工作者，不管是在建立個人品牌，還是在擔任顧問，如果能夠端出知名企業工作過的頭銜，就能夠很快速地建立對工作者的信任感，也會較為相信他／她說的話可能有其道理，不論我們是否聽不懂參不透。
這時，頭銜就很重要，因為它證明了這個人通過了現代社會的篩選機制，跨過了一道甚至數道不容易跨過的門檻。
👉 #頭銜不重要
在第一印象過後，透過彼此的交談，可以得知眼前的這個人是否了解自家的商品，是否知道客戶真正的需求和痛點是什麼，是否透露出一味想要成交這筆訂單的急躁。
這時，頭銜就不重要，因為談判技巧、商業分析、對產業的洞察、對商品跟客戶的了解才能讓生意成交。
在讀者點開文章後、聽完講師介紹後，發現這位工作者的文字語焉不詳、詞不達意、文件邏輯不通、東拼西湊，或者程式結構紊亂、專有名詞亂用，根本沒辦法讓人信任這位工作者的專業。
這時，頭銜就不重要，因為專業能力的累積、充分完整的表達，才能讓人持續地相信你／妳的產出。
👉 #那到底頭銜重要還是不重要？
頭銜就是最容易最快速的篩選判斷機制，讓不認識的人能夠在茫茫人海中，可以迅速建立印象的鉤子。頭銜就是在這個社會機制底下，證明自己佔有一席之地的證據。而頭銜帶來的關注、期待、信任，能不能夠持續地維持、增強，完全仰賴工作者在自己的工作領域、賽道上是否有底蘊、是否有持續進步，這就跟頭銜沒有任何關係了。
如果想要追求頭銜，那就去追吧，但頭銜不應該是目的，而是讓自己累積更多實力時，伴隨而來的好處。也許追求頭銜時失敗了，但過程中自己為此而做的努力跟收穫都不會是白費的。
0 1 901 0
Larry

產品工程師

2023/06/14

工程師看 PM 之應該具備的特質
秉持著一樣米養百樣人的原則，每個職位都不應該只有某一種特質，但的確會有些特質特別容易在特定職位中被凸顯出來。今天我們就稍微刻板印象和主觀一點，講講我身為工程師，看到 PM 具備哪些特質時，會對跟 PM 的合作上有加分。
👉 #需求論述清楚
論述清楚是指：不管是文字還是表達上，能夠將「為什麼要做這件事」解釋完整，包含為什麼要做、做什麼、有沒有其他戰略目的……可以回去看看《思考 #產品功能 時，能 #提升思考品質 的 #Checklist》系列文章，當 PM 能夠解釋清楚這些問題給工程師的時候，就已經是很專業的 PM 了。
至於需求要「怎麼做」，那可以是 SA、技術主管、工程師等技術職位的人討論的範圍，PM 沒辦法回答並不會有扣分。如果有工程師覺得 PM 回答不出怎麼做就覺得這個 PM 不行，那是工程師太嬌生慣養了。
👉 #有自己的原則
立場，可以是一個工作者的工作觀。需求變更、隕石砸下來是在所難免的事，但在變更的需求面前，PM 是否有自己的立場和規劃，知道怎麼判別哪些需求是真的有承接的必要、哪些是需求單位的任性妄為、而哪些又是對產品或團隊有害的。當面對四面八方的需求，當面對到與自己價值觀或原則相牴觸的事情時，能不能夠保有自己的原則，又是考驗每個人的智慧了。
有時也需要辨別，自己堅持的原則是不是必要的。為了一個英文單字要不要加上 s，而延遲了報紙送印的時間，只因為公司的報紙代表著這個國家的標準英文；為了讓整體的設計風格一致、程式碼簡潔，讓客戶多等一個月……坦白說我也沒有比較好的判斷方式可以辨別哪些原則是必須要堅持的，畢竟這也是每個人的特色嘛。
👉 #資訊整理和紀錄
各位有沒有遇過一個情境：曾經跟同事有過一段對話，是在解釋某個功能為什麼做某邏輯、不做某邏輯，但相關的資訊不是散落在對話工具中，就是根本沒有紀錄。
不管是 PRD（Product Requirement Document，產品需求規劃書）的撰寫、在會議中整理各方提出的意見和需求、甚至是在 Slack/Teams/Discord 裡將大家的資訊利用語言、文字、超連結的方式，讓接收訊息的人不管是在現在還是在三個月後，都能夠迅速地掌握到資訊的脈絡，我覺得這是非常不容易也值得敬佩的事。
我相信人是健忘的，人腦也不是拿來記事情，而是拿來下判斷的。過了一段時間後會忘記曾經有過的討論、忘記曾經做過的決定，都是很正常的事情。但若能夠在決定發生的當下就記錄下來，幫未來的自己跟同事一把，除了節省掉回想枝微末節的時間，也可以讓過去的決策保持著足夠的連貫性。
3 1 535 0
Larry

產品工程師

2023/06/13

如何在沒有技術背景下怎麼和 RD 討論技術可行性？
👉 #為什麼想跟工程師討論技術可行性？
會起心動念想跟工程師討論技術可行性，不外乎是因為：
1️⃣ 有個功能想要實作在產品中，但不確定要花多少時間。
2️⃣ 在時間壓力下想要完成某件事情，不確定有沒有辦法做到。
3️⃣ 看到可能的市場機會，想發展公司的第二曲線，但不知道要投入多少資源。
4️⃣ 純粹很好奇某項技術，想跟工程師交流討論。
我覺得不管是哪一種，作為開啟討論的動機都是可以的，但千萬要記得在《#怎麼和團隊中的 #RD #有效溝通？》有稍微提到的：「如果只是單純要讓工程師聽你／妳的，那並不叫溝通」。
👉 #要怎麼開啟技術可行性的討論？
先說，我不能算是「沒有技術背景」的人，我能夠分享的經驗是：當我不熟悉某項技術時，是怎麼跟熟悉技術的工程師溝通的。
最好用的方式，當然就是開誠布公地說想要討論技術（或可行性），並且表明原因為何。可以參考《金字塔原理》的表達方式，讓對話可以在一開始就聚焦在想解決的問題（也就是技術可行性）上。
討論過程中，工程師如果講出專業術語，可以看情況發問，或是先記錄下來，等對話告一段落再詢問或是自己查找研究（當然看不懂的話還是要問啦）。
要記得，這段對話的目的是想要透過技術解決某項問題，因此在討論的過程中，確認每個技術它扮演的角色、解決什麼樣的問題、為什麼我們需要它、有沒有替代方案……等等的問題，都可以視討論時間判斷能不能夠釐清。
👉 #要怎麼判斷是工程師不想做，#還是真的做不了？
倘若是霹哩啪拉抱怨式的回應，那顯然就是不想做。破解法就是追問原因、了解困難點在於哪裡，如果工程師避重就輕地回答，就抱著打破沙鍋問到底，想幫工程師找資源解決困難點的精神來了解，並且在能夠幫助的時候，真的提供適時的幫助。
如果是真的做不了，那也應該請工程師解釋原因，並且最好在工程師解釋完畢後，用自己的話覆述一次，確保雙方對於目前遇到的困難點的認知是一致的。
👉 #小心誤區
跟工程師討論會感覺受挫的工作者中，常有的想法是：
「是不是只要我學會技術，就可以跟工程師溝通了？」🤔
答案是肯定也是否定。肯定的是：越了解技術，就越不容易被工程師唬弄，也會對於目前產品可行性邊界有更明確的意識，自然就不容易有受挫感；否定的是：那你／妳原本的工作職能要用什麼時間來精進？你／妳是想要轉職成工程師嗎？
對於技術的了解越深當然越好，但是要了解多深，應該是以「了解該項技術能夠解決什麼問題」作為標準，如果真的有興趣再往下鑽研，最起碼知道可以怎麼使用這項技術，那就已經足夠了。
👉 #小結
每個技術都是為了解決特定問題而存在的，可能是解決執行效率、可能是串連起兩個不同的產品、可能是加快開發速度……。如同前面所提，對技術較不熟悉的工作者，如果不是想要以工程師為職志，那了解某項技術可以怎麼使用、某項技術可以和不可以做到什麼事情，就已經可以應付大多數需要跟工程師討論的情況了。
希望各位讀者在看完這篇文章之後，能夠對於和工程師討論技術可行性，有多了一點自信和把握。
1 0 1663 0
Larry

產品工程師

2023/06/12

怎麼和團隊中的 RD 有效溝通？
👉 什麼叫「#有效溝通」
我認為的有效溝通是：讓溝通雙方都能夠了解現在的問題是什麼，並且都對於要解決問題的方式、手段、取捨有相同的共識。
撇除透過職權的溝通方式，常見需要跟工程師溝通的情境有：
1️⃣ 尋求工程師的建議
2️⃣ 詢問工程師問題可能的解法
👉 #尋求工程師的建議
在功能真的進入到設計開發階段前，有時會不確定功能的可行性有多少，此時可以詢問工程師對於想要達到的商業目的有沒有什麼建議。
「我們現在想要做到ＸＸＸ，但不確定是不是可以做到，可以請問你／妳覺得有什麼潛在的風險／可能的做法需要注意嗎？」
但要記得，工程師不見得會對商業場景有了解，更多的是專注在鑽研技術的工程師，因此也要觀察工程師是不是對於功能規劃早期的可行性評估有興趣，不然也只是增加雙方的痛苦。
👉 #詢問工程師問題可能的解法
這比較聚焦在已經明確定義好要做的功能，但可能有容易但會有技術債、全面但較花時間的多種做法；此時有點主見的工程師就會提出自己覺得應該要怎麼選擇解法。
但我猜工程師選擇較花時間的做法時，通常不會被接受🤣。所以就需要再討論：如果以專案金三角「時間、範疇、成本」來看，時間是不可變動的前提下，其他兩角可以怎麼樣調整，讓專案／功能可以如期地上線？
這時候就會需要詢問解法跟尋求建議兩者輪流使用。
👉 #小結
其實要跟工程師溝通，就跟要和不同職能的人溝通沒有差別：了解對方的職責是什麼、工作上在意的事情是什麼、公司是怎麼定義對方的職能叫做合格的？如果工程師仗著能寫程式、或是 PM 仗著能決定做什麼事／比較懂使用者，說話就比較大聲，那這種團隊還是早點離開比較好。理想的團隊應該是互相幫助又各司其職，沒有人特別強勢也沒有人的聲音該被無視。
最後，送給大家一段話：跟工程師溝通時，千萬不要說「你的程式有 BUG」，因為這時候他／她只會想：「Ｘ！你才有 BUG。」要跟他／她說：「我不知道是不是我操作不正確，這個功能跟我預想的情況不太一樣」，這時候工程師就會想：「Ｘ！該不會是 BUG。」
祝想和工程師溝通的讀者們都能掌握自家工程師的溝通說明書。
2 0 1398 0
Larry

產品工程師

2023/06/11

在當工程師的這 10 年裡，讓我心累的 3 個經驗是…...
👉 #被當成用過即丟的工具
不是修電腦、送宵夜的工具人，而是被當成是免洗筷般的存在：被交代的任務就是完成它、把程式碼寫出來。合不合理？那不是工程師該煩惱的事情，是 PM 跟老闆要煩惱的；寫的不好／被客戶罵不好用……是誰背鍋應該不用多說吧？作為一雙免洗筷，筷子就應該做好筷子的角色，好好的把菜夾起來，不要問為什麼，閉嘴做就對了。
後來當然是趕快離開這樣的環境，任何人都不該助紂為虐。
👉 #做出來的東西沒人用
工程師不免會有匠人精神，會想要讓自己投入心力寫出來的程式碼能夠發揮最大的效益，為社會、公司或產品帶來價值，但市場是現實的，程式寫得再好、體驗做得再流暢，沒有打中使用者的需求、沒有人知道有這個功能，一切都沒有任何意義。
這也是為什麼後來我想要學習產品經理的職能，因為自己過往的經驗來說，不免在心裡會對做出的決策產生疑惑，但總會覺得也許是自己不夠了解市場，或是看事情的角度太過單一，因此就是乖乖做好執行者的角色。學了產品經理所需的能力之後，除了可以理解決策背後的理由、看得更全面以外，也在做出來的東西可能會變成沒人用的下場前，就先幫忙踩剎車。
👉 #每一個程式寫不出來的時候
在舒適圈跟成長圈的概念裡，超過自身難度 20% 左右的挑戰，最能讓自己成長。但倘若問題難度超過了這個範圍，這時就會陷入排查問題的地獄裡，如果網路上有資源、身邊有 mentor/senior 的同事可以諮詢幫忙倒還好，若一時之間找不到，又有時程壓力時，就會陷入更加焦慮、更加找不到解法的漩渦裡。這時候就會覺得自己很討厭寫程式。
處理方式當然有很多種：正面對決、繞道而行、延遲決鬥、打群架。
👉 👉 #正面對決
追查程式碼、翻文件，如果是開源專案就把 code 打開來看。如果評估時間允許，建議用這個方式，但如果查了兩個小時甚至半天以上，建議就先停下來（應該說查了一個小時就該反應給其他人了）。
👉 👉 #繞道而行
用其他方式解決，或是調整需求。逃避雖然可恥，但有用。
👉 👉 #延遲決鬥
他強由他強，bug 放一旁。也許這個問題不會影響到完成任務，就先不處理，待之後有時間再來處理。通常這就會變成技術債的一部分……。就要看團隊怎麼評估要不要再花時間處理了。
👉 👉 #打群架
試試看 pair programming, mob programming，三個臭皮匠都可以勝過一個諸葛亮了，多個工程師總會嘗試出可行的做法……吧？
1 1 523 1
關於教室
在這裡講產品、講開發，也講工程師的職涯成長。
教室標籤
  • JavaScript
  • Product Management
  • Agile development
  • Career counseling
  • Online learning
  • Web development
  • Product development
  • New product development
    • 學習發起人
    Larry
    產品工程師
    0 回答 29 分享 1 教室
    發起人簡介
    一個工程師，上班做產品，下班來這裡。 歡迎來我的方格子或Medium看更多分享！ ...更多