別只會追進度！PM 與工程師高效協作的 5 個思維
在產品部門中，產品經理可說是工程師最密切合作的對象，對於新手產品經理來說，可能會因為有沒有技術知識背景，而在溝通上感到困難。但即便是對於有一定經驗的產品經理來說，還是經常會在協作上碰到一些衝突。常見的衝突包括以下狀況：
- 開發功能的優先序：如何說服為什麼要優先開發此功能，而非另一個其實是重要用戶更需要的功能？
- 功能改動的優先序：原先的優先序為何要被降級，被質疑背景研究是不是做不足夠？
- 交付時間：太多想做的事情，工程師無法短時間完成。
- 在開發中的改動需求：產品需求與規格（spec）是否從客戶需求驗證過？突然改動被質疑沒有仔細檢視過規格文件的問題。
- 需求細節：產品經理對需求列的細節不夠詳盡，對於工程師對需求的規格詮釋有限。
- 文件管理：只有產品經理需要提供產品開發文件？工程師只需負責產出？
究竟在兩邊角色溝通模式上出了什麼問題？我們先比較兩種溝通情境。
同樣是工程師發現遇到難以解決的問題時，產品經理如果選擇直接幫忙解決時，可能造成長期下來，工程師認為潛在責任歸於產品經理，依賴由產品經理來解決工程師遇到的問題，結果產品經理一直把力氣在解決突發狀況，無法專注在更策略性的規劃。
相反地，如果產品經理在接到問題時，能夠先協助界定問題起因、何謂理想狀況的條件，並與工程師釐清在商業策略、用戶需求與工程下較好的交集，有助兩人從脈絡出發共同思考長期的解決方案。
如何更有效率地和彼此協作？身為產品經理，無論有沒有技術背景你都要掌握以下思維，遇到溝通衝突時更能找對解法。
- 尊重時程安排：
突然的會議會擾亂工程需要連續投入的時間，產品經理應主動了解工程期望的時間安排，並尊重適合的溝通方式。 - 了解開發中自身的角色：
每間公司習慣或是適用的開發方式不同，無論是敏捷或瀑布式開發，都要了解產品經理與工程師在協作流程上有哪些主要負責的項目，因為有時兩邊對流程定義的看法不同，就需要預先協調文件適合呈現的方式。 - 了解系統架構：
即便不必直接參與技術上的決策，產品經理也應該熟悉在產品架構中最核心的部分是什麼？我們最主要採取的技術與框架是什麼？目前有哪些技術上的阻礙？主動了解這類問題有助於直接用工程師的語言進行溝通。 - 了解「技術債」：
技術債通常是指為了趕時間開發時走捷徑，結果導致後來要花更多時間解決程式漏洞。儘管產品經理不可能完全避開技術債的問題，但還是要充分了解產品開發階段可能涉及到的技術問題、權衡工程師如何為解決技術債投入的時間，以免債務積累愈來愈大而嚴重影響日常運作。 - 將工程師視為夥伴溝通：
將工程師視為夥伴而非只是期待對方技術產出的人，就要在早期階段邀請工程師加入討論，實際了解商業與用戶需求，也能讓工程師更清楚產品規格是在服務何種需求。好的產品經理集結了對用戶、設計師與工程師等不同視角的理解，這也意味著緊密的協作溝通才能讓解決方案涵蓋多元、較完整的觀點。
（作者／Vanessa）
瀏覽 1,247 次
