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