從ERP整合到銀行協同再到高校數位化系統，鴻蒙適配的決策邏輯正在經歷深刻轉變。本文透過三段真實項目經歷，揭示技術適配背後更關鍵的產品價值判斷、用戶場景匹配與長期維護成本考量，幫助產品經理跳脫單純的技術視角，建構更系統的決策框架。
2018 年，我在深圳做大型企業內部的 ERP 整合系統。那時候，如果有人認真問我：「這個系統要不要為一個新終端生態專門做適配？」我大概率會覺得，這個問題問早了。
因為那幾年，真正壓在項目頭上的，根本不是終端問題。
系統和系統之間能不能打通，流程能不能真正在線上跑起來，權限怎麼設計才不把業務卡死，異常節點誰來兜底，數據口徑怎麼統一，線下習慣遷到線上以後哪些步驟必須保留、哪些必須砍掉，這些才是每天都在反覆拉扯的現實問題。那時做產品，更多像在一堆業務關係和系統關係裡找秩序。你沒有太多精力去談「哪個端看起來更先進」，因為系統本身還在回答一個更基礎的問題：到底能不能穩定支撐業務。
兩年後，我去了銀行體系做內部協同系統。鴻蒙也正是在那個階段，第一次真正進入我的產品判斷裡。
但它不是在我剛接項目的那一刻就闖進來的。
2020 年 9 月，我開始接手這個項目。那時團隊更關心的是流程怎麼梳理、權限怎麼劃、跨角色協同怎麼跑順。產品還處在持續設計和建設階段，很多基礎問題都比「要不要適配新終端」更靠前。到了 2021 年中，產品已經有一定規模，也開始逐步上線、開放使用。也正是在這個節點，鴻蒙這個話題，第一次從「行業動態」變成「組織內部會認真追問的現實問題」。
2021 年 6 月 2 日，HarmonyOS 2 面向手機、手錶、平板等終端正式發布，並啟動「百」款設備升級。那之後，我明顯感覺到，鴻蒙不再只是一個技術發布會上的新詞，而是開始變成產品團隊必須回應的問題。
我還記得那段時間，我專門看了發佈會，也順手做過一個簡短總結，發在微信對話框裡。當時沒有明確任務，只是隱約覺得，這件事後面大概率會被問到。後來有一天早上，領導在群裡看到一篇關於適配鴻蒙的推文，隨口問了一句：「我們有沒有這方面能力？」因為前面做過準備，我能比較快地給出回應：從能力上看，我們是可以做適配的。後面這件事也確實被往前推了。現在回頭看，那次經歷給我的觸動並不只是「我們做了適配」，而是我第一次清楚地意識到：一個平台趨勢，完全可能在某個很普通的工作日上午，突然變成產品團隊必須接住的問題。
再往後，到 2025 年，我開始做高校體系裡的數位化協同系統。同樣的問題又一次擺在面前，但這次我很清楚，它已經不是「有沒有能力做」的問題了，而是「這個系統到底值不值得做」的問題。
因為高校體系和前面兩類項目都不一樣。
它既不是單純的內部流程工具，也不是只服務單一角角色的系統。它往往同時面對學生、老師、輔導員、院系管理員、職能部門和管理人員；既有服務屬性，也有管理屬性；既要考慮流程正確，也要考慮觸達效率、角色協同和終端體驗。迎新、消息觸達、校內業務流轉、節點提醒、資訊確認，看起來都和移動端有關，但真正推進時，你會發現每個判斷背後都連著投入、協同和長期維護成本。
也正是在這三段不同經歷之間，我慢慢想明白一件事：
鴻蒙適配真正該算的，從來不只是技術帳。
技術當然要算，但它只是最表層、也最容易被看見的那一層。真正決定一個系統值不值得做鴻蒙適配的，往往是產品價值、用戶場景、組織階段、資源承受力，以及後續維護這筆更長的帳。
這篇文章，我想從這三段經歷出發，聊聊為什麼我越來越不主張把「鴻蒙適配」簡單理解成一個技術動作，也聊聊產品經理到底該怎麼判斷：一個系統，到底該不該做鴻蒙適配。
先說 2018 年那段經歷。
很多沒做過大型企業系統的人，會天然覺得這類項目最大的難點在功能複雜、頁面複雜。真正做進去以後才知道，不是。大型企業內部系統真正難的，往往是流程深、系統多、依賴重、組織鏈路長。你做的不是一個頁面，也不是一個單獨模組，而是一堆部門、一串流程、幾套系統之間的關係重組。
那時候我做 ERP 整合，最常見的工作狀態不是「設計一個新入口」，而是反覆確認幾個更底層的問題：
說得再直白一點，那幾年最真實的感受是：系統先活下來，比什麼都重要。
在這樣的項目階段裡，終端適配不是不重要，而是不構成第一順位。因為主鏈路還沒跑順，業務規則還在磨，組織協作還在磨合。你如果這個時候單獨拿出一輪資源，去談一個新終端生態要不要適配，產品上其實很難站得住。
這段經歷對後來的影響很大。它讓我第一次形成了一個很樸素、但後來反覆被驗證的判斷：
一個系統值不值得做新端適配，首先取決於它當前最主要的問題是不是「端的問題」。
如果系統眼下最缺的，是流程穩定、規則清晰、系統打通，那你優先談適配，通常就是判斷順序錯了。
很多產品討論之所以後來越做越亂，不是因為大家不努力，而是因為一開始把問題抓錯了。大型企業項目給我的第一課，就是別把「看上去先進」的事，放在「真正影響系統成敗」的事前面。
到銀行體系做內部協同系統時，我對這類問題的感受開始明顯變化。
銀行體系裡的產品，比大型企業項目更強調規範性、穩定性和組織協同，同時也更容易受到外部趨勢和內部判斷的雙重影響。尤其是 2021 年那個節點，鴻蒙不再只是一個技術圈的話題，它開始進入更廣泛的產品語境裡。你會發現，原來那些看似離項目還很遠的行業變化，突然會在組織內部被問出來。
我對那次經歷印象很深，不是因為當時的討論有多宏大，而是因為它發生得非常日常。
前面提到，我從 2020 年 9 月開始接這個項目，前期主要精力放在產品設計和協同鏈路梳理上。等到 2021 年中，產品已經逐步上線、開始開放使用，團隊對「下一階段怎麼繼續擴展能力」會更敏感，也更容易受到外部平台變化的影響。也正是在這個階段，我專門看了 HarmonyOS 2 的發佈會，順手做過一段簡短總結。那不是正式彙報，更像是我給自己留的一個判斷備忘：這個平台到底在釋放什麼信號，產品經理後面大概率會碰到什麼問題，團隊如果被問到，至少應該先從哪些角度回答。
後來某天早上，領導在群裡刷到一篇關於適配鴻蒙的推文，突然問了一句：我們有沒有這方面能力？
就是這麼一句看似隨口的話，讓我第一次非常明確地意識到一件事：
趨勢不會等你慢慢準備好，它會直接變成現實問題。
如果那天我完全沒關注過這件事，最可能的反應不是「我們不能做」，而是「我現在也說不清楚」。而在組織裡，很多時候最怕的不是結論保守，而是判斷缺位。
也正是因為前面做過一點準備，我當時至少能快速給出一個有邊界的回答：從能力上看，我們可以適配。這個回答看似簡單，其實很重要。因為它不是衝動表態，也不是草率承諾，而是在告訴組織：這件事我們不是完全被動的，我們知道它是什麼，也知道接下來該怎麼評估。
後面適配相關工作確實被推動起來了。現在回頭看，我覺得那段經歷真正有價值的，不是「我們做過適配」，而是它讓我意識到：從某個階段開始，產品經理不能只做系統內的判斷，還得能接住系統外的變化。
但這裡也有一個容易被誤解的地方。很多人會把這段經歷理解成「既然趨勢來了，那就應該盡快適配」。我後來越來越不這麼看。那次經歷真正教會我的，其實不是「跟上趨勢」，而是「先有能力理解趨勢」。因為只有先理解，你後面才有資格判斷到底值不值得做、應該怎麼做、做到什麼程度。
真正讓我把這個問題想透的，是後來在高校體系裡做數位化協同系統的經歷。
高校體系的複雜，很容易被外部低估。很多人會覺得，學校裡的系統不過是把一些校內流程搬到線上，做幾個入口、幾個表單、幾套權限。但真正做過的人都知道，高校數位化項目的難點，從來不只是功能，而是業務關係。
也就是說，高校體系裡的很多系統，既有服務側的訴求，也有管理側的訴求；既有移動端需求，也有流程治理需求。你在這裡談鴻蒙適配，已經不能像在大型企業項目裡那樣直接排到後面，也不能像在銀行體系裡那樣主要回答「有沒有能力」。它更像是一道完整的判斷題：
到了這一步，我越來越清楚，鴻蒙適配在高校體系裡最難的，從來不是開發做不做得出來，而是產品經理能不能先把這筆帳算明白。
這筆帳一旦算錯，代價很實在。因為多做一個端，增加的不是一個頁面，而是一整套產品方案調整、設計適配、研發實現、測試回歸、業務確認、版本維護。更麻煩的是，高校項目很多規則還在持續調整，時間節點會變，角色權限會變，業務邊界也會隨著實際運行不斷細化。你如果在流程還沒穩的時候過早鋪開新端，後面返工幾乎是一定的。
所以我後來對高校項目裡的鴻蒙適配，會天然多一層克制。不是因為不重要，而是因為它必須經得起更細的產品判斷。
真正進入項目後，我發現圍繞鴻蒙適配的很多討論，偏差往往不出在技術層，而出在一開始的問題定義上。
最常見的第一個偏差，是先問「怎麼做」，而不是先問「值不值」。
只要外部趨勢夠熱，或者內部有人提起，團隊很容易快速進入執行模式。要不要原生、哪些模組先做、排期怎麼拆、現有能力怎麼復用，討論起來都很順。問題是，這一切默認了一個前提：這件事已經值得做，現在只是研究如何更高效地做。
但產品經理最該先確認的，恰恰是這個前提本身。
第二個偏差，是把平台熱度直接當成立項理由。
鴻蒙當然是趨勢，這沒有問題。問題在於，趨勢只能說明你應該關注，不能直接說明你這個系統現在必須投入。尤其在高校體系裡，外部環境、政策方向、行業討論很容易反過來影響內部預期，大家天然會有一種「既然都在談，那我們是不是也該做」的急迫感。
這種急迫感可以理解，但它不能代替判斷。因為專案不是輿論場，最後為結果負責的，是業務落地，不是表態速度。
第三個偏差，是低估後續維護。
很多適配討論，立項時只算到上線為止。開發多久、測試多久、設計改多少，看起來一清二楚。可真實專案不是做完就封存，特別是高校體系的流程型系統，後面規則會繼續變，角色會繼續調，訊息方式會繼續換。你今天新做一個端，意味著以後很多變動都得再多維護一層。這不是一次性工時，而是一項長期承諾。
我後來越來越覺得，產品經理在這種問題上的價值，不是站出來說「做」或者「不做」，而是更早把這些隱性成本擺到檯面上。只有這一步做到了，團隊後面的動作才不會變成一種被趨勢裹挾的慣性推進。
如果一定要說，判斷鴻蒙適配的第一步看什麼，我的答案始終不是技術，而是用戶場景。
因為沒有用戶場景，適配價值就沒有落點。
很多討論裡最容易偷換的，是把「鴻蒙用戶在增長」直接等同於「我的用戶會在核心業務裡使用鴻蒙設備」。這兩件事不是一個層面的問題。前者是市場變化，後者是產品判斷。
產品經理真正該問的，不是「有沒有鴻蒙用戶」，而是「你的核心用戶會不會在最關鍵的業務動作裡依賴這個端」。
在高校體系裡，這個問題尤其不能泛泛而談。因為不同角色的終端習慣差異非常大。
學生端天然更偏行動化，但學生端內部也分輕重緩急。有些動作高頻、短鏈路、即時觸發，比如查看提醒、確認狀態、補充一個簡短資訊；有些動作則低頻但重要，可能集中在某個階段窗口，比如資料填寫、流程確認、關鍵節點提交。它們對終端體驗的敏感度並不完全一樣。
老師、輔導員、管理人員又是另一種情況。有些事情適合在手機上快速處理，比如查看提醒、確認節點、處理簡單異常；有些事情則天然更適合在電腦上完成，比如複雜資訊核對、批量操作、數據彙總分析。你如果不把角色和動作拆開看，很容易誤判「行動端重要」這件事本身。
所以真正有價值的判斷，往往要落到很具體的層面：
很多適配討論，一旦把問題問到這個程度，原來那些聽上去很籠統的「應該做」，往往就會自動收縮成更真實的判斷範圍。
這是高校體系裡很容易被忽略的一層。
很多系統不是沒有入口，相反，入口常常很多。統一入口、H5、公眾號、校內App、消息跳轉、PC管理後台，路徑並不單一。這個時候，產品經理必須先問一句：現有入口，到底有沒有構成真實障礙？
如果大部分關鍵用戶已經能透過現有路徑完成大部分關鍵動作，那鴻蒙適配在很大程度上就屬於優化項，而不是補缺項。優化項當然也有價值，但它的優先級判斷，不能和那些「沒有它就明顯影響業務」的事情混在一起。
我在高校項目裡見過一種很典型的錯位：團隊覺得用戶體驗不好，於是直覺上認為是不是端不夠好；但往裡追以後發現，用戶真正卡住的地方，不是入口形態，而是流程本身。步驟太繞、文案不清、狀態反饋模糊、異常提醒不及時，甚至是角色責任邊界不清。這些問題不解決，換一個端也未必會有根本變化。
所以我後來會特別在意一點：
鴻蒙適配到底是在補入口短板，還是在掩蓋流程問題？
這兩件事如果分不清，項目判斷通常就會偏。
我後來判斷一輪適配值不值得做，最常用的一種方式，就是逼自己回答一句：它到底新增了什麼？
這裡說的「新增」，不是平台列表裡多一項支援，不是彙報裡多一句話，而是業務上是否真的多出一層實在的價值。
這種價值，通常體現在幾個方向上。
一種是效率提升。某些關鍵動作在這個端上更順手，路徑更短，用戶完成起來更快、更不容易中斷。
一種是觸達改善。有些業務並不是做不了，而是總「看不到」「忘了處理」「過了時間點才想起來」。如果新端能力能讓提醒更及時、動作更自然，這種提升就不是表面文章。
還有一種，是更適合承接輕量服務。尤其高校體系裡，很多業務其實不需要用戶進入一整套完整系統，而是希望他在某個具體時刻快速完成某個動作。誰能把這個動作接得更順，誰的終端價值就更大。
再往後一點，如果你的業務本身就有 AI、服務分發、輕量入口等方向上的規劃，那鴻蒙適配的討論會更成立，因為這時候你不是單純為了「多一個端」而做，而是在為新的服務承接方式做準備。
但我一直很克制的一點是：這些方向再新，也不能自動等同於業務價值。
產品經理最怕的，不是不懂趨勢，而是把趨勢詞彙當成價值本身。最終能成立的，永遠是那些落回到真實用戶和真實業務上的東西。
做高教體系專案以後，我有一個越來越明確的體會：很多業務都很重要，但真正決定適配優先級的，往往不是重要性，而是頻次。
迎新系統是很典型的例子。它當然重要，學校也一定重視。但它的業務窗口往往非常集中，峰值明顯，很多關鍵動作都發生在某個階段。對於這種系統，最優先解決的，通常是關鍵時段的穩定性、流程清晰度、節點成功率，而不一定是率先做一輪完整的新端擴展。
反過來，有些業務沒有迎新那麼「顯眼」，但更高頻。比如消息觸達、狀態確認、輕量查詢、短鏈路辦理，這些動作單次分量不重，但因為長期發生、對時效敏感，反而更適合優先考慮終端優化。
這也是為什麼我現在越來越不接受一種很籠統的說法：「這個系統很重要，所以什麼都應該配齊。」
重要性，是對業務意義的描述；優先級，是對資源投入順序的判斷。兩者有關聯，但絕非同一回事。
從大型企業項目，到銀行體系，再到高校體系，我最大的變化之一，就是越來越相信：頻次、路徑長度、觸發時機和真實收益，往往比會議上的「重要」更能決定一項适配到底值不值得優先做。
如果說銀行體系那段經歷讓我意識到「趨勢必須提前理解」，那麼高校體系的項目經歷反過來讓我更確定另一件事：趨勢再重要，也不能替代產品判斷。
產品經理當然要對行業變化敏感，因為很多問題確實會突然落到你面前。但敏感不等於跟風，關注也不等於立刻投入。真正成熟的判斷，是能把趨勢翻譯成你自己的業務問題，而不是把趨勢本身直接當答案。
這些問題一個都不能省。
尤其在高教體系裡，很多判斷不是看「方向對不對」，而是看「時機對不對」。主流程還沒穩、角色邊界還沒清、現有入口還沒理順，這時候就算方向沒問題，推進時機也可能不成熟。反過來，如果關鍵場景已經明確、現有方式又確實有明顯短板，那趨勢只會進一步增強適配的必要性。
所以我現在更願意把趨勢看成一個「加權項」，而不是「決定項」。它很重要，但真正決定做不做的，還是業務現實。
很多適配項目在立項時，看起來都像一段有限的工程：評估、設計、開發、測試、上線，似乎做完這一輪就可以算階段性完成。
但我越來越覺得，真正難的從來不是這一段，而是上線以後怎麼持續維護。
系統只要還在迭代，規則就還會變。時間節點會改，訊息觸達方式會調，角色權限也會繼續細化。你今天在一個新端上把能力建起來，不代表明天它還能低成本地跟著主系統一起走。每次需求變化要不要同步？同步到什麼程度？如果兩個入口出現體驗差異，優先修哪邊？如果這個端只是某些時間窗口裡高頻，平時又沒人持續盯，品質誰來守？
這些都不是上線當天才會出現的問題，而是立項那天就該一起算進去的事。
很多專案之所以後面越來越重，不是因為一開始做錯了方向，而是一開始把「後面怎麼養」想得太輕了。
而產品經理在這裡最該補的一刀，恰恰是把「長期維護能力」拉進最初的判斷模型裡。
如果經過判斷，我認為某個系統確實值得做鴻蒙適配，我也不會建議一上來就全量鋪開。
更穩的推進方式，通常是先把事情拆小。
第一步，先把問題定義清楚。
不是「我們要不要做鴻蒙」，而是「我們要解決哪個具體問題」。是學生側的觸達問題，是某類高頻輕量場景的問題，還是某個關鍵角色的行動處理效率問題。問題越具體，後面的適配越不容易失焦。
第二步，選一個最適合驗證價值的場景。
不是選功能最多的，也不是選看起來最完整的，而是選那個最能證明「做這件事到底值不值」的場景。它最好價值明確、路徑清晰、風險可控。
第三步，把範圍限定在可驗證層級。
試點不是為了證明「我們什麼都能做」，而是為了判斷「這件事是不是值得繼續投」。如果一上來就想一步到位，試點往往會變成重投入項目，反而失去判斷空間。
第四步，做階段復盤。
不是只看功能有沒有上線，而是看用戶是不是真的用了、問題是不是真的緩解了、協同和維護成本是不是還在可接受範圍內。只有這一步做紮實，下一步是擴大、收縮還是暫停，才有依據。
我越來越認同一種推進方式：
不是先做全，再看值不值；而是先驗證值不值，再決定做多大。
放在高校體系裡，這種節奏尤其重要。因為這裡的複雜度決定了，任何看似順理成章的擴展，後面都可能變成一筆很重的維護帳。
如果把這幾段經歷放在一起看，我會發現自己其實給過同一個問題三次不同答案。
在大型企業項目裡，我的答案更接近於：先把系統建起來，先把流程跑順，終端適配不是當前最該投入的地方。
在銀行體系裡，我的答案變成：趨勢已經不是新聞，產品團隊必須有能力理解它、回應它，必要時也要有推動适配的準備。
到了高校體系，我的答案又更進一步：光有能力還不夠，真正重要的是判斷這個系統到底值不值得做、什麼時候做、做到什麼程度最划算。
所以現在如果再有人問我，一個系統到底要不要做鴻蒙適配，我大概不會直接回答「要」或者「不要」。
我會先問：
如果這些問題都能回答清楚，那鴻蒙適配就不是跟風，而是一項有依據的產品決策。
如果這些問題還停留在「感覺應該」「行業都在談」「別人已經做了」，那它大概率還不是一個足夠成熟的立項理由。
說到底，產品經理不是替平台表態，也不是替技術站隊。
產品經理真正該做的，是在趨勢、業務、資源和組織現實之間，算清楚那筆最難算、但也最關鍵的帳。
而這筆帳，從來都不只是技術帳。
本文由 @Wendell·H 原創發布於人人都是產品經理，未經授權，禁止轉載
題圖來自 Unsplash，基於 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平台僅提供信息存儲空間服務。
此內容由慣性聚合(RSS閱讀器)自動聚合整理，僅供閱讀參考。 原文來自 — 版權歸原作者所有。