這是 30 天寫作挑戰的第 25 天。今天要來回答臉書留言的提問:
30 天寫作挑戰:連續 30 天,每天都會從 ChatGPT 、生活中的靈感或是網友提問中,選出一個可以用 200–500 字的文章來回答的題目。說明可以參考宣示文。如果讀者想要我回答你/妳的問題,可以問我一個跟工程師、技術產品經理、產品經理有關的問題。
什麼叫「有效溝通」
我認為的有效溝通是:讓溝通雙方都能夠了解現在的問題是什麼,並且都對於要解決問題的方式、手段、取捨有相同的共識。
撇除透過職權的溝通方式,常見需要跟工程師溝通的情境有:
- 尋求工程師的建議
- 詢問工程師問題可能的解法
尋求工程師的建議
在功能真的進入到設計開發階段前,有時會不確定功能的可行性有多少,此時可以詢問工程師對於想要達到的商業目的有沒有什麼建議。
「我們現在想要做到XXX,但不確定是不是可以做到,可以請問你/妳覺得有什麼潛在的風險/可能的做法需要注意嗎?」
但要記得,工程師不見得會對商業場景有了解,更多的是專注在鑽研技術的工程師,因此也要觀察工程師是不是對於功能規劃早期的可行性評估有興趣,不然也只是增加雙方的痛苦。
詢問工程師問題可能的解法
這比較聚焦在已經明確定義好要做的功能,但可能有容易但會有技術債、全面但較花時間的多種做法;此時有點主見的工程師就會提出自己覺得應該要怎麼選擇解法。
但我猜工程師選擇較花時間的做法時,通常不會被接受🤣。所以就需要再討論:如果以專案金三角「時間、範疇、成本」來看,時間是不可變動的前提下,其他兩角可以怎麼樣調整,讓專案/功能可以如期地上線?
這時候就會需要詢問解法跟尋求建議兩者輪流使用。
小結
其實要跟工程師溝通,就跟要和不同職能的人溝通沒有差別:了解對方的職責是什麼、工作上在意的事情是什麼、公司是怎麼定義對方的職能叫做合格的?如果工程師仗著能寫程式、或是 PM 仗著能決定做什麼事/比較懂使用者,說話就比較大聲,那這種團隊還是早點離開比較好。理想的團隊應該是互相幫助又各司其職,沒有人特別強勢也沒有人的聲音該被無視。
最後,送給大家一段話:跟工程師溝通時,千萬不要說「你的程式有 BUG」,因為這時候他/她只會想:「X!你才有 BUG。」要跟他/她說:「我不知道是不是我操作不正確,這個功能跟我預想的情況不太一樣」,這時候工程師就會想:「X!該不會是 BUG。」
祝想和工程師溝通的讀者們都能掌握自家工程師的溝通說明書。
今日寫作觀察
今天的主題很難回答,主要是因為我沒辦法代表全體 RD 來發聲,只能透過我和身邊人的經驗,來給予也許可行的做法。如果你/妳覺得這篇文章有幫助,或者覺得這篇文章建議的方式沒有用,歡迎留言與我分享討論。