【PM夥伴攻略】如何跟工程師合作？
工程師是產品經理最常合作的對象之一，他們就像魔術師一樣，將你（或老闆）頭腦中的想法實現，開發出使用者可以使用的產品。
這篇會以負責開發「功能型產品」的工程師為例，提出七個與工程師合作時的注意事項。
前端、後端、資淺、資深工程師的工作內容與合作方式可能是不同的，身為PM，主動詢問工程師希望如何合作、如何幫他省時間，絕對能讓你更快達成目標。
延伸閱讀《【PM夥伴攻略】番外篇：工程師雷區幹話大全》
▍溝通的工具：PRD
產品經理必須將美好的功能概念轉化為工程師能夠開始實作的細節，這中間使用的工具叫做 Spec 或 PRD（Product Requirements Document 產品需求規劃書），通常包含：
- 產品目標 (Objectives)
- 假設、指標、實驗方法 (Assumptions, Metrics, Experiment Planning)
- 使用情境 (Use Case)
- 使用者故事 (User Story — As a user, i want to …, so that …)
- 使用者流程 (User Flow / Wireframe / Mockup，通常由設計師負責)
- 功能細節 (Function Details / Components / Basic Rules)
- 功能範疇、未來擴充可能 (Scope & Future Features)
- 功能上線策略規劃 (Release Strategy)
- 其他 (Other References: Research Doc, Constraints, Dependencies)
關於撰寫文件的詳細方法與心得，請見：
▍如何跟工程師合作？
1. 用產品迭代的心態產出 PRD
在一般常見的瀑布式（waterfall）開發流程中，產品經理會先跟產品主管、其他相關單位討論後產出一份完整的 PRD，接下來就進入開發流程，等到整個產品都完全開發完後再統一交付客戶或需求單位。
而在敏捷式（agile）開發流程中，核心價值則是快速產出、測試/學習、迭代/修正，將這個過程不斷重複循環。除了產品本身的開發要敏捷外，提需求的過程也可以用敏捷的心來進行。
我剛開始犯的錯誤是，自己埋頭寫了一份很完整（美）的 PRD、也請設計師按照這份文件將 mockup 產出了，要進入開發時才發現執行上有困難、需要太多的資源才能完成，或甚至是功能邏輯不太合理，最後需要大改一番。
運用迭代的做法可以先將產品目標、假設、情境列出，找設計師、工程師、其他產品經理、其他部門先確認過，沒問題再進行下一步——提出幾個不同的解法來討論可行性與限制，溝通好了再進入下一步——確認解法與細節。
透過頻繁的溝通，一次推進一點，找出從使用者需求、商業價值、技術可行都有共識的解法。這種溝通方式在大型專案中尤其重要，可以避免太早投入大量資源卻全部浪費的狀況。每次討論也都要有會議紀錄，若未來有人對某部份有疑問、或要交接時，可以翻閱紀錄的資料確認為何當時有此決定。
另一方面，工程師通常也不想看太長的文件，若在開發前就頻繁溝通，讓他們腦中先植入對功能的熟悉度，開始開發時 PRD 對他們來說就像是字典的用途，有需要的時候再查找，大部份的時候當面溝通還是比較有效率。
2. 提供細節清晰的需求
既然是字典，就要夠清楚。
產品開發是非常細節導向的工作，工程師要將你的想法（使用者的需求）付諸實行，需要知道你期望功能如何運作、特殊情況如何處理。並不是請設計師畫一個畫面出來、用一句話解釋哪裡有 BUG，工程師就會通靈。
使用者故事 (User Stories) 中要將正常運作的理想情境都寫清楚，若有多種不同的使用者互動，也可以將互動流程仔細地每個步驟切開。接著跟設計師討論呈現方式，再把功能細節補上（欄位是否有上下限、特殊情況）。
我剛開始寫 PRD 最常發生的狀況就是沒考慮到錯誤情況（Error Status）而只有寫理想情況，以及空白/初始頁面（Blank Status — first time state / delete ALL state）要放哪些資訊，或是技術相關的注意事項，例如功能預估的流量、使用者數量也會引響到 code 如何設計以及需不需要做壓力測試。
如果不知道要寫到多細節，可以先找工程師、QA一起討論，讓他們主動提出他們需要看到的 PRD 內容。
3. 給予明確的產品目標、未來展望
工程師必須了解產品目標，才能設計出好的寫法來滿足現在或未來的需求。
工程師通常是邏輯暢通的聰明人，「這個功能為何可以達成這個目標」的假設與推論如果不合理，工程師也會擔心能不能滿足使用者需求，更重要的，會不會開發之後發現無法達成目標，要全部砍掉重練。
若這個功能只是 Phase 1、未來會擴充更多相關功能，提早讓工程師知道並讓他們設計出更乾淨的解法，避免未來可預見的技術債，不然等到想做新功能時，工程師跟你說要先花一個月重構（refactor）把之前的東西砍掉重練再開始，你就知道痛了！
4. 幫助工程師節省時間
換句話說，就是不要浪費工程師的時間。
當工程師有什麼需要你幫忙的（需求不清楚、設計缺一頁、想知道某個數據、想了解某個 stakeholder 的想法），產品經理要在最短時間內完成「工程師提出的需求」、解答工程師的疑問，讓產品開發順利進行。
另一方面，當有什麼需要工程師幫忙的事情，是在「流程外」的，我會整理好所有資料、想清楚再去問問題或提需求（講重點！），畢竟有插件、臨時更改的功能需求，容易造成工程師在開發原先功能的過程中思緒被打亂，context switch 是對腦力的浪費！這麼重要的資源絕對要妥善使用呀！
工程師：每個需求都很急，你要先做哪一個？
團隊的時間有限，當有插件進來、priority 的調整，產品經理需要了解到原本預定的功能上線時間會被排擠，別跟工程師說「我全都要」，事情絕對是有輕重緩急的！
・加分題：如何「擋需求」？
老闆、其他部門臨時提出新需求，應該是產品經理常遇到的問題。雖然俗稱「擋需求」，但我認為本質上比較像是充分討論後，重新定義優先級，並「延後需求的完成時間」。舉例來說，有時候是使用者回報issue給客服團隊，產品經理要先判斷到底真的是bug，還是邏輯或UX不清楚的feature，判斷輕重緩急後，嚴重的當然是立即hotfix修復，不嚴重的則可以在Sprint結束後再安排資源。有更多時候是老闆或其他部門臨時說要做新功能。這時候也只能掌握好產品團隊原先設定好的目標與priority，請他們說服你為何要臨時開這個新專案、跟目標的關聯為何，再下決定。通常產品目標與priority跟公司商業決策息息相關，因此若本質上是商業策略改變、突然有重要的合作夥伴加入等等，的確有可能直接影響到產品功能的重要性與優先級。而如果你本身身在從上到下所有決策（包含商業決策）都很隕石型的公司當中，公司又不願意賦權給各部門、各團隊，那原則上也沒什麼機會去思考如何擋需求、如何溝通，畢竟產品經理自己的工作內容可能都會被隕石打好幾發惹💩參考資料：隕石式開發（日文）
5. 給工程師足夠的空間/時間思考與規劃
提出一個新的需求時，給工程師足夠的時間「實作」外，也要給工程師足夠的時間思考他需要多少時間來實作（繞口令）。
也許這個區塊過去不是他寫的，他要先看別人的 code 怎麼寫，思考如何擴充來避免疊床架屋；也許這是他之前沒碰過的功能，需要時間研究寫法、跟資深工程師討論、上網查資料。
以瀑布式開發來說，工程師估好時間，開發就會按照時程來進行（當然也有可能是以老闆期望的時程來交付😂）。
以敏捷式開發來說，若是以兩週為單位的 Sprint，產品經理要跟工程師一起將大的功能切成不同 Phase，每個 Phase 又會有很多個小任務，按照前後端、頁面規劃、User Stories 切分階段，來估算下兩週的 Sprint 可以完成哪些任務，並規劃和調整上線時程與策略（Release Strategy）。
6. 以解決問題導向的心態扛下責任
功能出現 BUG、上線後整個網站掛掉，當然是因為工程師寫出了 BUG、忘記做壓力測試、QA 沒測到，但最大的責任還是在產品經理身上。
作為危機處理的負責人，第一時間該做的是跟其他部門（客服、業務）說明目前發生的狀況，盡快協調工程師修復並上線 hotfix，當下扛下責任並驅動團隊一起把問題解決，別把解 BUG 當成工程師一個人的事。
有好的成果時，記得給工程師 credit；發生問題時，一起捲起袖子處理，事後再來檢討下次如何避免。
7. 了解工程師的成就感來源，當個樂於讚美與分享的好夥伴
工程師的成就感來源各有不同，可能是用超猛的技術方法做了一個超複雜的事、自己做的功能有很多使用者在使用、替公司賺了錢或節省成本、想對產品的設計有影響力、或單純想累積更豐富的履歷內容。
了解跟你合作的工程師成就感來源為何，適時分享一些產品數據、使用者回饋、其他商業部門開會時浮誇的感謝，或是讓有想法的工程師加入產品設計的流程，都會讓整個產品團隊工作得更有衝勁！
▍身為產品經理，技術背景重要嗎？
我認為只要有持續學習的能力，就算沒有技術背景，依舊能成為一個好的產品經理。（聽起來好像廢話）
有技術背景的產品經理，跟工程師溝通當然少了一些阻礙，也可以很快理解技術複雜度、可行性，因此技術含量高的軟體產品的確會需要有技術背景的產品經理才能擔當大責。
另一個優勢，是有技術背景的產品經理能夠更精確的預估資源與時程。
但這個角色不一定都是由產品經理負責，在某些團隊中會由技術主管、專案經理、Release Manager、Delivery Manager 等不同類型的角色來做時程預估或資源分配。
而身為沒有技術背景的產品經理，當工程師請你自己回去做功課時，就上網查查資料再回去討論；當工程師對你的想法說「不」的時候，問他為什麼，並建立自己的「技術實作」資料庫，直接從工程師身上學習技術或系統架構的知識。
運用技術來實作產品，是工程師的工作，產品經理無法深入了解細節是正常的。而產品經理的工作，就是協助團隊在有限的資源內，推出滿足使用者需求的產品，同時達成商業目標。
產品團隊在各司其職的同時，也應該是一個互助互惠的社群，分享知識、共享目標，創造可持續 deliver 的工作環境！
謝謝你的閱讀！如果有任何疑問、建議的主題也歡迎留言給我 📒如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多團隊合作的文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我們知道 👏🏻未來也會分享跟團隊內其他角色的合作方式，敬請期待！
想要持續追蹤我們的最新文章，請追蹤產品三眼怪實驗室 (◉◉◉)
