平臺型產品功能設計的需求抽象與升維適配|專訪宜信郭建偉

摘要：平臺型產品經理須要具有「對業務的結構化理解」，「先抽象提煉」再「反向適配具體業務需求」。

---

前言：宜信技術人物專訪是宜信技術學院推出的系列性專題，咱們邀請軟件研發行業的優秀技術人，分享本身在軟件研發領域的實踐經驗和前瞻性觀點。

第五期專訪咱們邀請到宜信科技中心普惠金融需求管理部負責人郭建偉，以「平臺型產品的功能與體驗設計」爲主題，圍繞宜信的產品開發實踐，分享平臺型產品經理的工做經驗和能力要求。

嘉賓 | 宜信郭建偉

記者 | 宜信成芳

本文爲採訪實錄。原創內容，轉載請留言獲取受權。

記者：郭建偉老師您好，今天咱們的採訪將圍繞「平臺型產品的功能與體驗設計」展開。業務模式的變化會對產品產生升級改造的需求。請您結合宜信的具體實踐，介紹在業務模式發生顛覆性創新的狀況下，平臺型產品團隊該如何處理跨多平臺融合、多團隊溝通的複雜問題，從而順利推動和實現平臺產品升級？

郭建偉：正好在宜信的這段工做經歷中，參與過一次公司戰略級的業務模式創新項目——火鳳凰項目，將網貸業務中間人模式升級爲直接借貸模式。有一些經驗體會能夠分享給你們：

首先，要明確自身在項目中的定位，目標清晰。 一般業務模式升級類項目都是公司級項目，參與部門比較多，產品團隊和技術部門雖然是落地過程當中最重要的一環，但通常還會涉及公司內一系列系統外的工做推進，甚至外部合做方、監管機構的協調，每每不會由產品團隊或技術部門來主導，因此要明確自身在項目中的角色，充分理解項目的業務目標，轉化成具體的系統建設目標，並以此在項目前期和需求方達成一致，這是明確項目範圍、管理預期的關鍵，也是系統建設的基礎；

其次，是對舊業務模式、歷史數據的兼容問題。 在重大業務模式升級的項目中，對於平臺型系統而言這是關鍵問題之一。這個方面我有兩個體會：

• 要進一步細分兼容問題的類別，縮小範圍、制定差別化解決方案，來下降兼容問題的複雜度、工做量。 參與過相似項目的同事應該都會有這樣的體會，對舊模式兼容、歷史數據處理的工做量，徹底不亞於投入在新模式建設上的工做量，因此做爲負責人，優先考慮的不是「硬剛正面」，而是「戰略性迴避」，適當拉長新舊過渡期，在項目既定週期內，讓團隊聚焦新模式建設，爲後續存量處理留出工做空間便可；
• 與業務團隊溝通討論，充分挖掘業務方在存量處理上的做用。 技術團隊每每第一時間考慮的都是技術解決方案，但在存量處理的問題上，處在更上游的業務方的一些小變通，每每能給咱們提供很是有效的支持，不要一味只在下游、本身熟悉的範圍內尋找解決方案，最優方案每每須要上下游協同。

最後，是試點支持的重要性。 不論業務方是否要求試點，不論對自身研發、測試團隊的能力多有信心，個人建議是面對大型業務模式升級，對試點功能的支持都是必不可少的。在IT層面，是對系統功能升級的驗證，控制影響範圍、監控性能問題等；在運營層面，新模式一方面平滑推廣，一方面在逐步推廣過程當中，會持續調整，推廣的過程也是一個收集反饋再升級的過程。

記者：有一種分類方式是將產品經理分爲平臺型產品經理和業務型產品經理：平臺型產品經理主要對接開發、測試、設計團隊，知足to B的需求；業務型產品經理主要對接市場、銷售、運營團隊，知足to C的需求。您認爲在具體的產品工做上，這2類產品經理的區別是什麼？

郭建偉：我認爲面向C端的業務產品經理最重要的是「對客羣理解」，核心工做內容是經過產品的調整，增長「客羣」與「產品」的匹配度。 客羣的特色與痛點是C端產品經理工做圍繞的中心，並以此調整本身的產品；相反固守本身產品，而去不斷教育用戶、創造需求，成功的例子並很少。另外每每咱們的產品經理並非本身產品的目標客羣，跳出本身的認知習慣，去精準把握另外一個羣體，是C端產品經理的重要能力。

B端平臺型產品經理最重要的是「對業務的結構化理解」。 這是我我的的一個說法，從這裏能看到兩個層面的含義。一個是要對某「業務」領域知識足夠熟悉， 這是平臺型產品經理的工做前提；另外一個是 「結構化理解」，也就是抽象能力，須要咱們具有基於對業務流程的認識，抽象爲對業務模式的結構化理解，這是平臺適配性、擴展性的關鍵所在，是平臺型產品經理的關鍵能力。

記者：宜信科技中心堅持以「科技賦能業務」爲核心理念，做爲平臺型產品經理，該如何將業務需求轉變爲產品功能需求？

郭建偉：我認爲 「科技賦能」要根據不一樣業務所處的不一樣階段，採起不一樣的「賦能」方式， 你們常看到因爲技術落後業務發展進程而產生的問題，而容易忽略技術過於超前一樣會引起問題。

通常狀況下，我把「賦能」分爲多個階段：

• 支持階段，這個階段通常在業務的起步期，業務流程不穩定，需求變動較多，系統的按時交付、保障業務開展是這個階段的關鍵。
• 提煉階段，這個階段通常業務進入發展期，業務流程逐漸穩定，平臺建設的技術團隊對業務造成必定理解，進入對業務抽象提煉的階段，這個階段的目標仍是經過對業務的理解、抽象，更好地建設系統，以適應業務的發展，着眼點還在系統提高自己。
• 賦能階段，這個階段業務已經持續發展，業務量穩定，業務自己促進增加方面出現瓶頸，須要技術不只僅是在效率、自動化方面支持業務，而是基於對業務的理解，直接着眼業務，結合技術手段作出改進提高；
• 引領階段，我認爲並非每一項業務都適合、或都可以進入到技術引領的階段，處在這個階段時，將打破「業務」與「技術」的邊界，技術變革作出的引領，自己就是業務的一部分。

記者：您在以前的分享中提到：產品經理不只要能知足當前業務需求，還要可以基於當前需求進行抽象提煉，要超前業務作面向將來需求的產品。要作到這一點，產品經理必須具有什麼樣的能力要求？如何作到抽象和洞察將來需求反向適配業務？

郭建偉：我一直反覆地和團隊的平臺產品經理強調一句話：系統建設不是照搬業務流程實現自動化的過程，而是先對業務流程作抽象提煉，再去反向適配具體業務需求的過程。 這個認識也一直指導我在宜信的每個系統建設工做。

抽象能力無疑是平臺產品經理最關鍵的一項通用能力，談抽象能力時，我常提的一個通俗例子就是 「客戶要一匹更快的馬，咱們應該給他一輛車」。這個例子中，一方面體現產品經理對客戶真實需求「更快到達」的挖掘；

另外一方面也體現了抽象做用，之因此從「要馬」到「給車」，中間實際上是有一個抽象升維的過程，就是抽象成「交通工具」，再從「交通工具」降維到「車」，這偏偏就是上面的 「先抽象提煉」再「反向適配具體業務需求」；

另外這裏我還強調咱們能順利完成抽象、適配，其實還得益於咱們對「交通工具」領域常識的瞭解，若是這個例子換到醫療領域「客戶要某藥品A，咱們應該給他另外一藥品B」，若是咱們不具有病理、藥理的領域知識，就沒法完成抽象、適配。因此 「業務領域知識」+「抽象能力」都是平臺產品經理的重要能力體現。

記者：關於to B與to C的產品功能設計，一直有一種說法是：to B重功能，to C重體驗，您是否定同這種說法？平臺型產品的用戶體驗設計主要體如今哪些方面？

郭建偉：前面說起了C端產品經理和B端產品經理的區別，這裏我簡單談一下我對用戶體驗的理解。

對於平臺型產品而言，談「用戶體驗」時，咱們談的並非界面美觀與交互流暢與否，而應該是「用戶是否能更便捷達成他的指望」，因此「用戶的指望」纔是用戶體驗的核心。

舉個簡單的例子：一個界面美觀、交互流暢、動效酷炫的純手工功能，和一個界面粗糙的自動化功能，對於B端用戶來講，會絕不猶豫選擇後者，由於那更貼近他的「指望」。在這個理解的基礎上，再去考慮提高界面美觀、交互流暢等，這是B端產品經理應該注意的。

記者：隨着「中臺」概念的興起，「產品中臺」也隨之被提出，該如何理解「產品中臺」這個概念？您認爲產品經理的工做是否適合於中臺化模式？

郭建偉：中臺建設我並不專業，宜信科技中心有團隊專一這個領域，我簡單說說我本身的一些認識。

首先，中臺概念的興起是和業務量級密不可分的，並非全部業務都須要中臺，爲了建設中臺而建設中臺是沒有意義的；

其次，中臺是和組織結構有關聯的，中臺建設自己也在促進「組織分層」，以便進一步在各層配置不一樣的能力模型和資源，各層或分散、或集中，達到提高組織總體運營效率的目的；

最後纔是系統建設方面，避免重複造車輪，增長系統共用，下降成本，加快業務需求交付速度等等。

記者：對於想要轉型或剛剛從事平臺型產品經理的同窗，您有什麼職業成長方面的建議想跟你們分享？

郭建偉：B端產品經理的工做相比C端產品經理工做，有些枯燥，因此

首先，你們要有耐心，不斷學習積累。

其次，要增強業務領域知識的學習，行業領域知識對B端產品經理的重要性，要高於C端產品經理，擇業時儘可能注意在某一大領域內選擇；

最後，不管是哪一種產品經理、哪一個行業，產品經理都應該是善於發現問題、解決問題的那類人，因此保持好奇心，勤于思考，提高商業敏感度是很是重要的。

但願你們除了在本身工做中是個合格的產品經理以外，動用產品經理賦予你的種種，讓本身在「職業道路」、「人生道路」這個產品上，也能成爲一名合格的產品經理，謝謝你們。

拓展閱讀：

專訪宜信CTO向江旭：技術應當服務於場景，AI天生適合金融業

迴歸架構本質，從新理解微服務|專訪宜信開發平臺（SIA）負責人梁鑫

智慧金融時代，大數據和AI如何爲業務賦能？|專訪宜信AI中臺團隊負責人王東

一切技術創新都要以賦能業務爲目標|專訪宜信數據智能研發部負責人張軍

市場變化驅動產品思惟升級|專訪宜信財富管理產品部負責人Bob