不論你現在所處的部門是行銷、業務開發、銷售、法務，總是會有和產品團隊（產品經理、產品設計師、軟體工程師）合作的機會，比如有特定的需求要在產品上實現，就需要產品團隊的協助。可以把這篇文章視為一個簡單的科普，初步了解產品團隊的生態及工作流程。
希望透過這篇文章，能夠讓非產品團隊的夥伴有初步/了解，所以整篇文章會盡可能白話、避免專有名詞、省略細節。
具體作法、狀況依公司狀況而定，以下內容依我待過的五間軟體公司為例，大致流程符合軟體業慣例，但不涵蓋急件等特殊狀況。
產品團隊的基礎生態
產品經理、產品設計師及軟體工程師共同關注產品的商業價值、使用體驗以及品質，但不同角色有各自側重、負責的範圍。
產品團隊有一個固定的工作週期，通常以兩週為單位，我們稱之為 Sprint （短跑衝刺），一個 Sprint 會接續著下一個。在 Sprint 的開頭，團隊會透過會議來安排本次 Sprint 目標要完成的工作優先項目，並以工程師可負擔的程度為限額，排不下的就會先留在待辦清單內，等待下一個 Sprint 再來討論屆時的任務優先序。
任務類型可以概略地分為三種：
- 功能開發：拆分成細項的產品發展規劃，例如開發新功能等等。
- 臭蟲修復：需要修復的產品問題
- 臨時需求：長期規劃之外的任務。各部門需要產品團隊支援的任務就歸屬在這個類型裡面。
正常狀況下，除非 2、3 很緊急或影響重大，否則產品團隊會以 1 的任務為主，接著視情況把2、3 消化完。合理的緊急例子：「這個任務不儘快處理，使用者沒辦法正常使用核心功能，會造成現有使用者大幅流失」。不合理的緊急例子：「行銷團隊內部定的時程是兩週，所以產品團隊需要在兩天內完成這個臨時需求。」
為什麼要有這樣的工作週期呢？
起初是因為過去產品開發流程以季、年為單位，不夠靈活和彈性，所以才發展出以雙週為單位的工作安排。但近來人們的工作節奏逐漸加快，需求可能每天都因為新資訊而有變動，對我而言，這樣的工作流程更像是「確保需求在兩週內不會持續變動」。如果想瞭解更多細節，可以搜尋「敏捷式開發」。
過於頻繁的變動會造成什麼問題呢？
想像一下過去讀書時，老師出分組報告的作業會說明相關細節，例如報告主題、需要包含的內容、簡報頁數等等，並要求你在兩週後要上台報告。如果當你收到作業指示，開始動工後幾天，老師突然說主題要更換，內容方向也有變動，但是要在同樣的時間點完成，會不會感到很厭世呢🫠？不僅是先前的功都白費了，需要用接近兩倍的速度來完成相同份量的工作。倍增的工作量會影響成果的品質，也難以顧及細節，可能會造成一些無意的差錯。
以上內容基於我過去在產品團隊的經驗和觀察，希望讓各位對大方向的工作流程有更明確的想像。由於本人是產品設計師，接下來更進一步跟大家分享產品設計師的工作內容！
那產品設計師都在做什麼？
產品設計師日常負責和產品經理共同釐清待解決的問題，例如使用者覺得產品哪裡不好用、遇到什麼狀況等等。接著找到解決方法，進一步訂定明確的產品畫面、互動邏輯，將其視覺化地實現在產品上，例如版面怎麼安排可以滿足專案目標，按鈕該長什麼樣子等等，讓工程師可以有明確的開發細節。
舉例來說，我們會發現「網路商城的商品下單次數低於預期」（問題），接著我們會去透過訪談、數據搜集等方法釐清問題的原因及全貌，可能是使用者找不到購買按鈕，可能是產品資訊難以閱讀，讓使用者不敢放心購買等等（問題背後的原因）。後續我們會嘗試各種方式來解決這些問題，例如改變按鈕的位置，讓使用者更好找到購買按鈕、將產品資訊分門別類地呈現，讓使用者更好消化跟理解等（解決方法）。接著做出超擬真的新版網頁，讓大家對新版本有一致的想像和期待，讓工程師有盡量明確的開發內容。
在面對臨時需求時，產品設計師尤其負責把關產品的使用體驗、代表使用者發聲。任何未經過詳實考慮的改動都可能造成問題，所以為了維護良好的使用體驗，產品設計師在收到需求後都傾向進行詳實的考慮，確認所有細節。
為什麼改一個小東西要這麼久？
設計師在交付設計稿之前，會需要很多時間來思考，似乎想很多、盡可能面面俱到就是我們的職責所在，因為我們要盡可能消除模糊空間，讓工程師的執行方向更明確。為什麼我們會需要很多時間思考呢？因為設計稿需要同時滿足許多條件，包含但不限於：
- 滿足商業需求及專案目標
- 具備良好的使用體驗、畫面美感及產品一致性
- 需要合理、適當的開發成本
- 顧及理想流程跟極端狀況
除了做到上述條件之外，我們也要和許多人一起達成共識，多半不是設計師自己一個人單方面下決定。對象包含但不限於；需求方、產品經理、工程師、設計主管、工程主管、使用者研究員、其他產品設計師、產品分析師等等。
即便看似只動了一些小東西，例如換張圖、改個位置等等，都可能會和設計師事先「想好」的面向有所衝突。
可以看看一個知名的案例，Slack （通訊軟體）在送出一個訊息通知之前，需要經過各種條件邏輯的判斷。「送出訊息通知」看似是一個很單純的行為，但其運作背後有相當多的細節。為了維護良好的使用體驗，而不是讓使用者被通知轟炸，需要設計師（還有工程師、產品經理）一起完成周全的考量。
有時產品的改動也會影響到公司的營運流程，例如廣告橫幅版位的改動，可能會影響負責該版位的營運、行銷部門的維護流程，需要產品經理協調。產品設計師也需要更新具體的圖片規格給視覺設計師以及其他相關單位，確保功能後續的應用不會出現問題，可以說是牽一髮而動全身。
提出需求時，怎麼讓產品團隊覺得你很讚？
產品團隊喜歡看到需求方做這些事：
產品團隊喜歡看到
- 提供充足的背景脈絡，讓大家知道為什麼有這個需求
- 說明任務完成後的商業價值、預期影響力。（預估的數字）
- 讓產品團隊了解任務的具體目標
- 需求方和產品團隊一同協作，提出想法的同時保持開放心態。
產品團隊不希望看到這些事情發生：
- 需求缺乏脈絡和背景資訊，會讓產品團隊難以找到根源痛點，並深入的解決核心問題。像是病人牙痛時，醫生需要找到那顆蛀牙，而不是用止痛藥來暫時壓制症狀。
- 提出一個解決方法，並強烈要求產品團隊照做。即便從你的角度來看，這個做法再小、再簡單，都最好不要這樣做。
- 任務內容沒有事先定義清楚，Sprint 開始之後突然大改。大改小改的具體界線依產品團隊評估的難度、所需時間而定。如同前一段所述，團隊成員會因為臨時的大變動而無法有足夠的時間完成基本品質的成果。
具體內容可能依據不同產品團隊而不同，還是要依照產品團隊具體的習慣為主，但大方向是共通的。
希望透過這些初步介紹的能夠讓各位捧油初步了解產品團隊的習性跟生態，未來都能有讚讚的合作關係！
