生活随笔
收集整理的這篇文章主要介紹了
中台建设方案
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
中臺產品經理寶典 【劉天】 讀書筆記
| 1.互聯網顛覆變革的出現 | 互聯網上半場和下半場 | 消費互聯網 | 消費者個人 | |
| 產業互聯網 | 企業 | |
| 產業發展規律 | 技術時代 | 生產工藝門檻、核心技術、壟斷 | 引入期 |
| 宣傳：技術參數：16核、折疊屏幕、后置四攝 |
| 產品時代 | 技術攻關掌握了技術打破壟斷 | 成長期 |
| 用戶體驗、滿意度、口碑 |
| 差異化、用戶痛點 |
| 產品人的黃金時代 |
| 宣傳：差異化功能，Opp品牌前置攝像頭、錘子手機發短信確認等 |
| 市場時代 | 產品差異化縮小、同質化嚴重 | 成熟期 |
| 市場運作和產品分發能力 |
| 更多的渠道、品牌運作 |
| 上下游議價能力 |
| 產業升級 | 重回市場時代 | |
| 最近的一次產業升級：4G、視頻產業 | |
| 目前的互聯網從產品時代進入了市場時代將迎來變革 | |
| 目前是一個市場相對飽和又缺乏創新的互聯網環境 | |
| 業務模式特征 | 互聯網上半場：前后臺模式 | 增量市場 | |
| 互聯網下半場 | 特征1：以企業服務為業務核心對象 | 存量客戶，企業主體 |
| 成本管理、優化供應鏈體系等 |
| 子主題 |
| 特征2：渠道中間商新價值 | 賦能渠道商與代理 |
| 互聯網企業不強調去中間化 |
| 特征3：千人千面的業務 | B端業務的現狀 |
| 非標準化互聯網時代 |
| 3.中臺化浪潮 | 中臺≠微服務≠Saas | | | |
| 產品微服務 | 解決代碼量指數上升帶來的高維護成本 | | |
| 避免單個模塊故障導致系統整體崩潰（單點故障） | | |
| “大代碼庫”劃分為多個“小代碼庫” | | |
| 業務拆分模塊化 | 每個子模塊自成體系，獨立運行完整流程 | |
| 每個服務有通用的標準、輸入、輸出有清晰的邊界 | |
| Saas | 軟件服務 | 釘釘... | |
| 中臺目的是提高企業自身研發效率，不給客戶直接提供服務 | | |
| 什么樣的企業需要中臺 | 公司的發展階段 | 是否支持騰出手來支持基礎服務的建設？ | |
| 如果是努力搶市場階段則不適合，生存第一 | |
| 兩類企業適合 | 初創企業 |
| 業務線復雜企業 |
| 公司戰略目標 | 是否聚焦本行業 | |
| 公司業務線 | 是否業務發展到一定程度？ | |
| 是否沉淀了一定量的IT資產（數據、業務流程、運營模式） | |
| 是否已驗證符合市場需求的最優解？ | |
| 評價指標 | | |
| 總結 | 多條產品線? | 提取成功經驗 |
| 有功能成熟 盈利的產品 已被市場驗證 |
| 中臺發展趨勢 | 芬蘭Supercell游戲公司（阿里巴巴201） | 9名員工開發了多個爆款游戲產品 | 統一支付網關、算法引擎 |
| 統一SDK、素材、模型 |
| 搭積木方式開發 |
| 國內中臺先驅：阿里巴巴 | 小前臺+大中臺 | 一處研發、多處使用 |
| 2008年共享平臺事業部 |
| 大中臺：統一提供服務的部門做大做強 |
| 小前臺：讓業務部門少研發，技術團隊變小 |
| 案例：阿里一年立項近百款產品、上線十幾款 |
| 騰訊 | 2018成立技術委員會 | |
| 七大事業群+技術委員會 | |
| 中臺產品的發展與演進 | 三個階段 | 共享代碼平臺 |
| 共享服務平臺 |
| 共享能力平臺 |
| 中臺產品分類 | 技術中臺 |
| 業務中臺 |
| 數據中臺 |
| 5.中臺建設路徑 | 中臺是企業信息化建設綱領 | | | |
| 市場宏觀認知 | 企業外部調研（行業研究） | 行業高度進行業務規劃 | |
| 對下一步業務的預判 | |
| 企業內部調研 | 商業模式、用戶調研 | 避免成為業務線的外援開發團隊 |
| 企業標準化 | 企業管理流程標準化（各業務執行環節程序化改造） | | |
| 各業務線執行環節有可量化的指標（透明化） | 案例：客戶拜訪 | |
| 中臺建設是互聯網企業內部的一次管理升級 | | |
| 梳理業務需求與數據需求 | | |
| 解決方案設計 | 業務建模 | 核心場景剝離 | |
| 核心業務拆解 | |
| 模塊組合打包（功能合并、合集） | |
| 基礎服務確定 | |
| 中臺能力輸出 | |
| 特征列表 | 建立特征列表 | |
| 分析共性部分 | |
| 7.業務標準化 | 組織結構中臺化改造 | 獨立中臺研發團隊 | | |
| 反例：矩陣組織架構 | 人員靈活調配，頻繁切換業務組 | |
| 大大提升人員重新認知的時間成本 | |
| 中臺團隊 | 定位：公共事務研發 | |
| 中間件、自動化腳本、數據庫查詢等工具研發 | |
| 撇開繁瑣的業務需求，專心研究技術平臺、如何提高性能等 | |
| 前臺團隊 | 負責一線客戶需求 | |
| 目標：實現業務目標 | |
| 較少考慮性能 | |
| 業務流程的中臺化改造 | 產品經理 | 應站在公司角度對各條業務線進行一個標準化梳理 | |
| 做到對公司各項目心中有數 | |
| 業務抽象歸類 | 泛產品架構分類（整改公司視為一個產品） | |
| 產品=產品主體+產品推廣標準流程+運營后臺 | |
| 運營后臺=產品運營反饋循環+推廣運營反饋循環 | |
| 業務量化 | 整個業務進行考核指標的設計 | |
| 實現數字化運營 | |
| 找到企業數據中臺的監控目標 | |
| 9.現有業務能力抽象 | 各產品在產品線中的定位 | 流量獲取 | | |
| 流量留存 | | |
| 流量變現 | | |
| 各產品用戶群情況 | | | |
| 5W1H分析法 | 對象（What） | 6個問題梳理公司各產品功能矩陣 | |
| 目的（Why） | |
| 場景（Where） | |
| 時間（When） | |
| 用戶（Who） | |
| 方法（How） | |
| 業務中臺化抽象 | 拆解模塊 | 拆解公司所有產品功能模塊 | 提取共性 |
| 避免漫無邊際地將各個應用任意需求加入中臺 | |
| 站在全公司視角思考解決方案 | |
| 動作分析法 | 事件 | |
| 動作 | |
| 案例1：登錄 | 事件 | 本人校驗事件 |
| 個性化配置載入 |
| 進入頁信息灌裝 |
| 角色行為 | 登錄用戶 |
| 業務系統 |
| 動作 | 每一次操作 |
| 輸入信息 |
| 點擊按鈕 |
| 案例2：地圖應用 | 用戶中心 | 高頻模塊剝離 |
| 位置管理 |
| 中臺方案架構 | 中臺立項 | | |
| 產品畫像 | 最忌諱：成為業務線的外部中心 | |
| 排除大而全的設計 | |
| 通道設計 | 如何判斷共性節點 | |
| 管道理論 | 統一各模塊不同的輸入、輸出 |
| 建立起統一的向外通道 |
| 11.數據中臺設計實戰 | 閉環產品體系設計 | | | |
| 建立數據運營中心 | 公司級用戶畫像 | | |
| 整個公司的交易量變化 | | |
| 公司核心指標發展情況 | | |
| 橫向緯度分析指標 | | |
| 數據采集埋點 | 粒度太細（資源消耗過大） | | |
| 粒度太大（無法具體定位問題） | | |
| 階段目標 | 層級1：戰略指標 | GMV、用戶數、總利潤 | |
| 層級2：戰術指標 | 業務進展 | |
| 層級3：行動指標 | | |
| 指標體系 | OneData | 指標類名詞規范 | |
| OneID | 打通用戶體系 | 建立用戶畫像 |
| 數據監控 |
| 后記：優秀的產品經理是什么樣的一群人 | M-P能力模型 | M（Market）部分：市場運作能力 | A.需求翻譯 | 需求變為設計 |
| B.項目管理 | 按期交付 |
| P（Product）部分：需求生產能力 | C.市場推廣 | 觸達用戶，占領市場 |
| D.商業變現 | 實現商業目標 |
| 能力層次 | 戰略型 | ABCD | |
| 籌劃型 | ABC | |
| 高級執行 | AB | |
| 低級執行 | A | |
| 優秀的產品經理 | 掌握了M-P模型偏市場能力 | | |
| 能以大局觀看待整個產品 | | |
| 2.為創新而生：中臺戰略 | 2019中臺規?；?#xff1a;騰訊、美團、字節跳動 | | | |
| 基于“前后臺”架構演化而來 | 項目初期是較為省時、省事的一種架構 | | |
| 建設中不需要考慮系統的擴展性，有很大的自由度 | | |
| 反而節省研發人力 | | |
| 前后臺模式的根本弊病 | 現有產品模式由：標準化產品變為以用戶為單位的定制化產品 | | |
| 快速迭代、落地終端，軟件生命周期變短 | | |
| 案例：電商APP版本迭代周期為6個月。而某AO系統每2個月一次大迭代 | | |
| 這樣就暴露了前后臺模式的根本弊病：響應速度太慢 | | |
| 生產流程:煙囪式架構 | 資源和信息孤島 | |
| 大量底層支撐部分建設與等待時間：對用戶而言為無效工作 | | |
| 用戶能感知的在于前臺，不為系統底層架構建設而買單 | | |
| 舉例：新項目建設 | 前端重新設計界面 | |
| 后端重新設計服務接口與數據表 | |
| 新業務從底層工作開始，底層重復建設 | |
| 新的解決方案 | 最少改動底層或只開發上層從而滿足絕大部分的需求 | |
| 前后臺模式向下發展的瓶頸 | 公司內外發展沖突 | 公司外部需要快速迭代 | |
| 內部每次迭代都需要傷筋動骨 | |
| 前臺+后臺的齒輪速度匹配失衡 | 匹配新業務不斷增加新模塊，系統越來越龐大 | |
| 無法滿足前臺業務所帶來的改版，無法按時上線 | |
| 公司內部的二次統一 | 管理性名言（戰斗力、二次統一） | 組織架構統一 |
| 思考角度上統一 |
| 反例 | 每個產品線圈地為王 |
| 每個部門決策只從本部門利益出發 |
| 每個團隊互相隔離、不同事業部重復建設 |
| 需要時跨部門多次對接 |
| 中臺的出現可以說是互聯網企業在管理學方面的集體提升 | | |
| 揭開中臺神秘的面紗 | 做菜案例 | 對接簡化作用 | |
| 前后臺模式架構 | | |
| 中臺業務架構 | | |
| 核心本質 | 前臺業務提供服務共享 | |
| 目標 | 前臺業務規?；瘎撔?/span> |
| 或大規模試錯 |
| 高速增長的企業值得借鑒中臺的思路 | |
| 中臺解決方案的定義 | 能力輸出 | 核心競爭力？戰略目標 |
| 提煉共性模塊 |
| 歸到中臺統一建設 |
| 為不同的前臺業務提供可以重復使用的能力，形成一次建設、多次使用 |
| 將功能抽象為能力 |
| 避免過度建設 |
| 標準化中間件 | 定義統一化的輸入與輸出 |
| 統一通用屬性 |
| 中臺方案的威力 | 大幅降低邊際成本 | 量產攤薄前期投入成本 |
| 提升內部服務的復用能力 | 公司核心力量聚集，覆蓋全公司 |
| 進階開發由公司技術帶頭人負責 |
| 最優解通過中臺同步給全公司基礎員工（技術中臺） |
| 舉例：數據庫訪問 |
| 統一管理 |
| 提供全局化視野和全量數據模式 | 公共數據池 |
| 提升應用的TTM | 統一各項目共有部分 |
| 統一用戶感知 | 不同項目發展長短不一，品質不一 |
| 案例：不同項目的登錄界面 |
| 不良現象 |
| 使用中臺登錄組件 |
| 4.C端和B端各需要什么樣的中臺 | C端業務 | 流量紅利衰退 | | |
| 精細化運營 | | |
| 建設目標 | 滿足細分用戶的偏好 | |
| 快速創新、高頻試錯提供支持 | |
| B端業務 | 幫助企業更好地經營自己 | | |
| B端產品的兩個誤區 | 唯日活論 | 追求高凈值客戶，不是用戶數量 |
| 虛榮指標 | 指標不能指導產品達成商業目的 |
| B端唯一評價指標 | 營業收入、利潤 | |
| ROI（投資回報率） | |
| 個性化需求控制以ROI為導向 | |
| 功能可配置 | |
| MVP：低成本快速試錯 | |
| 6.宏觀市場探查 | 宏觀市場分析 | 產品經理角色的轉變 | | |
| 分析通用框架 | 宏觀經濟趨勢（定性） | |
| 產業發展趨勢（定性） | |
| 行業發展現狀（定量） | |
| 中臺用戶研究（業務線人員） | 用戶研究方法 | 用戶訪談 | 和業務線產品、運營長時間深入交流 |
| 情景訪談 | 模擬真實用戶某個場景 |
| 問卷調查 | 終端用戶 |
| 研究行動點 | 圈定研究人員 | 產品經理、運營、項目經理、公司高層 |
| 設計研究問題的大綱 | 設計與未來中臺使用者的對話 |
| 中臺訪談計劃表 | 第一輪：業務熟悉訪談 | 輸出 |
| 第二輪：公司IT資源方法 |
| 第三輪：高層目標訪談 |
| 8.設計成果中臺產品的核心原則 | 原則1：獨立的中臺研發團隊 | 兼任的弊端 | 抽象層次和深度不夠的問題 | |
| 無意識按照該產品線的業務進行設計，讓中臺失去意義 | |
| 高管的介入 | 協調各業務線放棄自己的部分利益 | |
| 打破原有的利益格局 | |
| 與業務線建立溝通機制 | 發現高頻需求 | |
| 各業務線周報機制 | 當周的版本計劃 |
| 版本中重要功能 |
| 下一階段規劃 |
| 原則2：中臺建設需求邊界管理 | 模塊改造 | 復用化 | 剝離特殊部分 |
| 標準化 | 業務線統一操作對象 |
| 能力化 | 接口化 |
| 需求的邊界 | 業務需求 | 輸入、輸出 |
| 數據需求 | 描述數據、評價指標 |
| 兩種建設模式 | 自上而下 | 拆分中臺 |
| 覆蓋匹配各業務模塊 |
| A系統的功能B系統可用 |
| 得出全量功能 |
| 改造B系統模塊 |
| 自下而上 | 歸類現有各業務系統的模塊 |
| 向上統一抽象出中臺架構 |
| 10.業務中臺從0到1建設路徑（解決方案） | 企業架構 | 管理業務生產各個要素之間的關系集合 | | |
| 分類 | 業務架構 | 運營模式 |
| 組織結構 |
| 生產流程 |
| IT架構 | 內部管理運營系統 |
| 數據架構 |
| 應用架構（產品） |
| 技術架構（代碼） |
| 作用 | 部門配合統一協調 | |
| 決策依據 | |
| 創新 | |
| 提效 | |
| 降本 | |
| 企業架構與中臺 | 屬于IT架構層面的產物 | |
| 業務中臺建設的啟動 | 建設模式 | 分布替換式建設 | 對業務系統模塊一個個改造 |
| 優點：逐步抽象 |
| 缺點：建設周期長 |
| 完整式建設 | 獨立建設中臺 |
| 啟動新項目沉淀原有業務 |
| 業務系統前臺保持不變 |
| 前后臺接口調用替換為中臺 |
| 優點：獨立項目快速迭代 |
| 缺點：用一套系統翻新所有項目，建設成本高 |
| 中臺用戶優先級 | 第一層級 | 利潤、市場占有率“雙高” |
| 第二層級 | 利潤低、市場占有率高 |
| 第三層級 | “雙低”創新型業務 |
| 業務中臺建設路徑 | 公司全景功能地圖 | 業務線+產品+功能 | |
| 功能相似度確定 | 通道數：模塊的輸入輸出信息 | |
| 相似度=（相同的輸入通道數+相同的輸出通道數）/總通道數 | |
| 評價復用次數 | 復用次數高則中臺化優先級高 |
| 核心業務能力抽象 | 通用流程而非業務線中的公共需求堆砌 | |
| 從企業的業務出發設計一個大體的模塊架構 | |
| 提取公司級核心業務流程 | 電商平臺案例 |
| 企業級數據模型搭建 | 業務線反饋：格式不一致問題.. |
| 抽象方法 |
| 去重 |
| 企業級數據模型案例 179 |
| 業務中間件研發 181 | 解決數據內容不一致無法統一存儲的問題 |
| 字段剝離 |
| 對接后臺業務系統 | |
| 最終架構 184 | |
| 中臺需求管理 | 原始需求 |
| 關鍵要素 |
| 管理技巧 |
| 業務中臺路線圖 | 開發流程 |
| 對接流程 |
| 業務中臺建設KPI | 指標1：模塊復用率 | 復用率高的留在中臺 |
| 復用率低的放回業務線（中臺不再維護） |
| 指標2： 業務開發TTM | 軟件從立項研發到上線的時間（成本） |
| 節省的開發人天=原模塊研發所用人天-中臺化研發該模塊人天 |
| 被使用的產品越多，則節省的成本越多 |
| 總成本節省 = （業務1節省成本 + 業務2節省成本+...） - 業務中臺開發成本 - 業務方遷移中臺成本 - 中臺系統運維成本 |
| 12.技術中臺實戰設計 | 技術中臺體系架構 | 技術前臺 | 核心價值體系在對業務邏輯的理解與實現上 | |
| 技術開發能力標準要求低 | |
| 技術中臺 | 承上啟下的中間層 | |
| 對下封裝復雜的實現邏輯 | |
| 對上提供統一化工具 | |
| 技術能力標準要求高 | 性能調優 |
| 打磨技術工具 |
| 將技術能力和業務能力分離 | | |
| 技術中臺原理 | 一個獨立單元只完成一件事情 | | |
| 業務線切割后的事件已封裝為服務單元 | | |
| 中臺拓展、能力增多 | 業務線需要自主研發的就越少 | |
| 如何搭建技術中臺 | SOA | 微服務 | 將業務拆分成獨立的模塊，每個模塊獨立上線運行 |
| 注冊中心 | 統一管理微服務，向各業務線提供微服務模塊運行信息與地址，動態獲知服務的更新 |
| 部署運維 | K8S | |
| Docker | |
| 技術實現定義：中臺實際就是將每一個復用的模塊作為一個獨立的應用進行開發與上線，再通過服務調度來實現復用 | | |
總結
以上是生活随笔為你收集整理的中台建设方案的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。
