一句話重點
好的衛星產品需求，不是寫「支援衛星通訊」，而是寫清楚場景、環境、服務等級、限制條件與驗證方法。
PM 為什麼需要知道
衛星產品最怕模糊承諾。因為衛星訊號會受到軌道、頻段、天線、地形、天氣、遮蔽、容量、地面站與法規影響，如果需求寫得太籠統，最後很容易變成：
- 客戶以為任何地方都能用
- 業務以為覆蓋等於可用
- 工程以為只要實驗室測通就好
- 客服沒有指標可以判斷問題
- 合約承諾超過系統能力
PM 的工作，是把不確定的物理世界，整理成可驗證、可溝通、可營運的產品規格。
不好的需求長什麼樣？
以下需求看起來簡單，但其實風險很高：
「設備需支援衛星通訊。」
問題是它沒有說清楚：
- 支援哪種衛星系統？
- 用哪個頻段？
- 上行與下行資料率是多少？
- 在固定或移動場景使用？
- 天線要如何安裝？
- 在雨天、山區、城市、船上是否成立？
- 可接受多少延遲？
- 斷線多久需要恢復？
- 如何驗收？
這種需求在早期討論可以當方向，但不能當產品規格。
好的需求要包含六個元素
第一，使用場景。
需求要寫明產品在哪裡使用。固定站、船載、車載、空載、手持、偏鄉、災區、遠洋、山區，條件都不同。衛星產品不能脫離場景談規格。
範例：
「設備需支援固定戶外安裝場景，安裝位置需具備南向開闊視野，避免高樓與山壁遮蔽。」
第二，服務能力。
要拆成上行、下行、延遲、可用性、資料回傳頻率、封包大小或任務成功率。
範例：
「在指定服務覆蓋區內，終端需每 15 分鐘完成一次感測資料上傳，每筆資料小於 2 KB，平台端需於 5 分鐘內接收並產生時間戳記。」
第三，環境條件。
要寫明規格在什麼環境下成立。衛星訊號很受天氣、遮蔽、移動與安裝品質影響，因此環境條件不能省略。
範例：
「上述資料回傳能力適用於終端天線無遮蔽、設備供電正常、服務區域具備衛星覆蓋，且天候未達極端降雨條件。」
第四，終端與安裝要求。
很多衛星服務失敗不是衛星壞了，而是天線角度、線材、固定方式、供電、防水或韌體設定有問題。
範例：
「終端安裝需依照安裝指南完成天線指向與固定，線材長度不得超過指定規格，設備需回報安裝後初始訊號品質。」
第五，監控與告警。
如果產品需要營運，就要能知道服務狀態。PM 應要求終端或平台回報關鍵指標，例如連線狀態、RSSI、SNR、封包成功率、電源狀態、GPS 狀態、韌體版本。
範例：
「平台需顯示終端最近一次上線時間、最近一次資料回傳時間、連線狀態、訊號品質指標與錯誤碼。」
第六，驗收方法。
需求一定要有驗證方式。一次測通不等於可商轉。PM 要定義測試時間、地點、樣本數、成功率與例外條件。
範例：
「PoC 期間需在三個目標場域連續測試 14 天，每台終端每日資料回傳成功率需達成約定門檻，並記錄失敗原因分類。」
把技術限制轉成客戶語言
工程限制不能原封不動丟給客戶。PM 要翻譯成可理解的產品說明。
工程語言：
「Ka-band 在強降雨下 link margin 會不足。」
產品語言：
「在強降雨期間，服務可能自動降速或短暫中斷；若客戶場景需要高可用性，建議搭配備援鏈路或調整 SLA。」
工程語言：
「終端需要 clear sky view。」
產品語言：
「終端天線需安裝於開闊位置，避免被建築、山壁、金屬結構或樹蔭遮蔽；若安裝於遮蔽環境，服務品質不在標準承諾範圍內。」
工程語言：
「LEO handover 可能造成短暫 session disruption。」
產品語言：
「在衛星切換期間，部分連線可能出現短暫延遲上升或重連；需確認客戶應用是否能容忍短暫中斷。」
PoC 需求不要只測「能不能連上」
衛星產品的 PoC 常見陷阱是只做單點展示。現場測一天，成功傳了一次資料，就宣稱產品可用。但正式商轉後，問題會出現在長時間營運。
好的 PoC 應該至少驗證：
- 不同天候下的服務表現
- 不同安裝位置的訊號差異
- 長時間資料回傳成功率
- 終端重啟與斷線恢復
- 平台監控與告警是否有效
- 客戶實際工作流程是否被改善
- 失敗案例是否能分類與追蹤
PM 要把 PoC 設計成縮小版商轉，而不是一次性展示。
SLA 要分清楚可控與不可控
SLA 是衛星產品最容易踩雷的地方。PM 要分清楚哪些是公司可控，哪些受外部條件影響。
相對可控：
- 平台 API 可用性
- 客服回應時間
- 終端韌體更新機制
- 監控告警時間
- 地面網路與雲端服務架構
較受外部條件影響：
- 極端天候
- 客戶錯誤安裝
- 遮蔽環境
- 頻譜干擾
- 合作衛星容量
- 法規或跨境連線限制
這不代表不可控就不用管，而是要在合約、產品說明、安裝指南與客戶教育中清楚界定。
常見誤解
誤解一：需求越簡短越好。
早期探索可以簡短，但正式規格必須清楚。衛星產品的環境變因太多，模糊需求會把風險留到測試、交付或客訴階段爆發。
誤解二：工程測通就能對客戶承諾。
工程測通通常只證明某條件下可行。客戶承諾需要看長時間、目標場景、邊界條件、失敗處理與營運能力。
誤解三：限制條件寫出來會降低銷售力。
相反，清楚限制能建立信任，也能避免不適合的客戶場景拖垮交付。衛星產品需要誠實的服務邊界。
可以問工程師的問題
- 這個需求在哪些環境條件下成立？
- 哪些條件超出標準服務承諾？
- 我們能從終端回收哪些診斷指標？
- 現場安裝品質如何驗證？
- 失敗時能否區分遮蔽、天候、設備、容量、地面站與平台問題？
- PoC 要測多久才有意義？
- SLA 的數字是否有實測資料支撐？
- 客戶應用是否能容忍短暫延遲或斷線？
小結
衛星 PM 的需求文件，必須比一般網路產品更重視場景與條件。因為衛星訊號不是只受軟體控制，它會被天空、地形、天氣、頻段、天線、法規與合作網路共同影響。
把限制寫清楚，不是示弱，而是產品成熟。好的 PM 會把工程限制轉成可驗證的需求、可管理的 SLA、可溝通的客戶說明，讓衛星服務真的能落地。
延伸閱讀
