平台介紹

碳係數報告分析平台(Life Cycle Analysis Platform，以下簡稱 LCA 平台)，提供發展有形產品及無形服務的企業，能夠透過SaaS 平台取得組織溫室氣體盤查所需的足跡係數，以及計算產品或服務專案環境碳足跡。目前提供中、英、越三種語言。

平台於2024 年7 月開始設計，並於同年10月上線，現已有20+企業使用平台服務。 

組織架構及負責領域

開發LCA平台的相關人員組織圖

身為產品部門的Associate Product Manager，在本產品中負責範疇如下：

1. 共同與合作夥伴、業務蒐集使用回饋及溝通需求 ，並與團隊評估需求優先序及技術可行性
2. 共同設計客戶、管理員及合作夥伴使用流程及 UI flow，繪製流程圖、PRD、FAQ等產品相關文件
3. 共同負責與內部開發部門以及越南外包開發團隊溝通功能設計及規格，追蹤外包專案進度
4. 主導規劃 Test Case 並執行 UAT 測試，並向越南開發團隊追蹤與監控功能調整狀態
5. 主導功能迭代專案，規劃Sprint Goal& Backlogs，領導5 人跨部門團隊(開發及產品) 執行

平台目標用戶(使用者故事)

1. 需要取得組織溫室氣體盤查所需的足跡係數的企業客戶
   (如：永續顧問公司、具永續部門的中大型企業)
   
   JTBD(Jobs to be done)
   採購符合自身需求(依據原料、製程、研究國家、研究年份、數據來源等判斷)的足跡係數。
   Needs
   快速的取得流程，並且能夠正確選擇所需的環境係數。
   Barrier
   取得困難：現有多個係數庫，企業用戶若需要取用不同係數庫中的足跡係數，則須購買多個係數庫，造成採購係數的取得方式不易且成本ut高昂，且擁有許多不適用的係數。
   
   >> HMW：我們怎麼幫助客戶從不同來源找到所需足跡係數，並以單點形式購買係數?
   
   
2. 需要計算公司內產品/服務環境足跡係數的企業客戶
   (如：被大型製造廠商要求提供物料/服務足跡係數的供應商)
   
   JTBD(Jobs to be done)
   提供自身製造的物料/服務的足跡係數給製造或組裝廠商，以計算最終產品的環境足跡。
   Needs
   需要憑證以供製造或組裝廠商證明來源。
   Barrier
   學習門檻高：現有工具（詳細請參照:競品分析）皆須具備專業知識的人員進行足跡計算，如：透過永續顧問協助進行計算，導致顧問成本增加，並成為固定支出。
   
   競品分析（針對平台目標用戶２）

從平台目標用戶2 可以發現，學習門檻高成為目前無法獨立提供自身製造的物料/服務的足跡係數給製造或組裝廠商的核心痛點。透過競品分析(上圖)，得知現有能夠協助客戶達成任務的產品，除了學習門檻高以外，並且並需要定期付出訂閱及購買係數庫的費用，取得許多非需求外的功能服務。

>> HMW：我們怎麼幫助客戶用自身能力計算製造或組裝廠商認可的產品/服務環境足跡係數 ?

平台路線圖

平台功能地圖

需求來源及管理方式

1. 需求蒐集與釐清

1. 產品部門：最了解產品藍圖與未來發展方向，提出新功能或優化需求。

2. 業務部門：與客戶最直接接觸，蒐集終端用戶的痛點與反饋，提供市場實際需求。

3. 合作夥伴：包含計算平台供應商、永續顧問或其他合作單位，可能帶來整合或技術方面的新需求。

2. 需求評估

1. 公司策略：需求是否與公司近期及長期策略目標一致，能否支持核心業務發展。
2. PLC 目標（Product Life Cycle）：考量產品的生命週期，確定需求是否能推動產品進入下一階段。
3. 影響力：衡量需求對目標客群、收益、市場競爭力等影響程度，並評估投入資源和回報間的權衡。

>>評估完成後，將需求分為 「Must-Have、Should-Have、Could-Have、Won't-Have」，協助快速判斷資源分配優先順序。

3. 需求排序

緊迫性 & 明確性：以需求的時效性及定義清晰度為主，同時檢視需求內容是否足夠明確，以避免不必要的返工。

>>評估完成後，將需求排序為 「High, Medium, Low 」，以便後續功能設計分配，並作為後續Sprint Bcaklogs的排程參考。 

Product Backlogs ＆ Bug Report 設計

為了讓部門內以及與工程師溝通功能能夠確保無基本遺漏，並統一功能設計的溝通方式。我透過蒐集人人都是產品經理 資料，以及與部門內討論後，我規劃了部門內撰寫功能需求的 Product Backlogs ＆ Bug Report 格式，並經過與開發部門及產品部門協調及迭代修正後，產出如下的內容：

Product Backlogs舉例：

【新增功能】顧問上傳報告書時，提供可以回填報告書專案模型的功能

使用情境

在顧問/管理者上傳報告書或數據截圖後，系統需要紀錄該筆專案的詳細內容，以做為後續其他客戶可選擇以及可引用的依據。

功能設計

當顧問選擇檔案上傳後，並點擊「確認」後，跳轉至「該專案」的資料確認及輸入畫面

進入模型填寫畫面後，系統將會把該筆訂單的專案資訊、清單資訊、專案總覽資料帶入，數據選擇資料不帶入。

1. 顧問進入專案詳情頁面，可透過直接確認已從該專案中帶入的資訊。

2. 跳轉至清單資訊中，顧問確認現有專案的清單資訊中每項物料或服務流程是否正確，或有需新增的物料或服務流程，若有誤則直接修改及新增，確認無誤或修改完成後點選儲存 (若先前有匯入模型結構，亦須確認各物料內容是否匯入正確)

3. 跳轉至數據選擇中，系統顯示在清單資訊的物料或服務流程（所有物料及服務流程皆未連結任一係數），讓顧問將每個物料及服務流程配對至正確的數據(係數)，所有的物料皆選擇完成係數後，點選「確認，進入專案資訊」。

請注意：顧問在此僅能為每項物料選擇一個係數 

4. 進入專案總覽，進行最終確認

前置條件

1. 顧問進入訂單後台，並上傳一份符合檔案格式以及大小的檔案，點擊「確認」

後置條件

系統顯示「文件已成功上傳」Pop-up，訂單後台頁面跳轉至已完成頁面

ZH-TW「文件已成功上傳」

EN-US「The File is Uploaded Sucessfully」

例外處理

1. 顧問若未一次輸入完資訊而離開系統，系統儲存至上次顧問點及儲存的頁面內容，當顧問下次點擊進入待上傳頁面後，會出現筆型工具icon，點擊後即可進入上次點擊儲存的頁面

Bug Report 舉例：

【問題回報】加入購物車的產品會因為該產品更動，購物車內的產品內容被覆寫

所屬環境及使用者（在哪個地方發生的）

全部環境/客戶端

問題描述（甚麼狀況導致錯誤）

目前建立的產品加入至購物車後，如果在產品列表中更改產品資料，會導致購物車內的產品一同更改。若在產品列表中使該產品不符合加入購物車的條件，加入到購物車的產品也會不符合條件，最終送出訂單會造成錯誤。

發生情境（說明如何Reproduce 此 Bug）

新增一個產品，並建立物料，將物料關聯至1-3個數據，以達到符合加入購物車的條件將該產品加入至購物車後，若回到產品列表中取消物料所關聯的數據，由於現有產品列表與購物車公用同一資料表，修改的資料會影響購物車內的產品內容，導致在下載兩份Excel資料時會出現錯誤，或出現Excel資料內空白的狀況。

預期功能修正（Expected vs. Actual ）

在資料庫設計時，需要將產品列表的資料表以及購物車的資料表分開，不可透過新增欄位來判斷產品是否加入購物車以獨立儲存購物車內產品的資訊，並且在增加後續應用其他功能上的可擴充性

附錄：設計截圖

附錄：平台迭代衝刺計畫