中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

下面這篇文章是筆者整理分享的關于自身的產品和項目及面試經歷，其中內容包含了愛企查/輿情/情報分析/風險預警等系統所解決的業務問題、各系統的共通之處及差異分析以及關于“架構”的一些思考的相關內容，對此感興趣的同學接著往下看看了解更多叭！

個人從事2B/G產品工作3年半，期間個人直接或間接負責建設的系統包括：【智慧城管系統】、【政務熱線分析系統】、【人體/車輛異常行為告警系統】、【輿情分析系統】、【開源情報分析及偵察系統】、【公共安全防控與預警系統】、【自訓練平臺】、【OA系統】等。

• 產品形態上，這里面以中屏居多，也有小屏和大屏；
• 產品服務模式上，有端到端的SaaS系統、客戶端系統（需下載部署安裝）、還有直接提供API服務的；
• 產品使用的AI技術上，有NLP的，有CV的，有ASR+NLP的，有知識圖譜的，還有跨模態的；
• 產品使用的數據上，有僅開源的，有僅閉源的，也有開源+閉源相結合的。

今天就來聊一聊，這些系統以及諸如“愛企查”、“企查查”、“千里馬招投標”，還有面向KOLMCN提供運營/營銷服務工具的如“飛瓜數據”、“蟬媽媽”系統，有什么共通之處？又有什么差異？

一、愛企查/輿情/情報分析/風險預警等系統所解決的業務問題

二、上述各系統的共通之處及差異分析

1. 共通之處分析

做了這么多產品/系統，我發現，這些系統（城管系統、政務熱線分析系統、公共安全防控與預警系統、輿情系統、情報分析系統…，包括愛企查、企查查、還有飛瓜數據、蟬媽媽、七麥數據等），它們本質上就是一類東西：【（大）數據處理與分析系統】。

即，都是對采集或獲取到的各種數據（有僅開源的，有僅閉源的，有開源+閉環的），利用各類AI算法（有只用CV的，有只用NLP的，有多種技術結合的）進行治理和分析，最終給到業務側去應用，而且業務應用功能多為：預警、分析。作為為業務發現風險的一個“上報源”。

——這是從數據流轉層面來看的，上述各個系統的【共通之處】（即產品架構基本類似）。抽象來看，上述各個系統的業務流程都如下，且與OA系統的關系如下：

OA系統，可以負責上述【數據處理與分析系統】提供的風險數據的后續業務操作與處置，使得業務能夠流轉（如生成告警工單，案件處置表單等，進行多部門的協同）。

——從對外提供的產品服務模式來看，廠商一般也會優先提供基于互聯網的PaaS服務或SaaS形式。

這是因為服務升級、運維均在廠商自己側，維護和管理成本低。而私有化部署交付這種服務形式，對廠商側的運維成本很高。

2. 差異點分析

（1）從產品面向的客戶類型來看，這些系統（城管系統、政務熱線分析系統、公共安全防控與預警系統、輿情系統、情報分析系統…，包括愛企查、企查查、還有飛瓜數據、蟬媽媽、七麥數據等），其是有差異的。

A. 客戶類型不同，導致的交付模式差異

• 2G產品，客戶一般都會要求私有化（不論是端到端的系統，還是AI能力）；
• 2B產品，如OA系統，在產品形態上，廠商會優先給客戶推薦SaaS方式，但同時為兼顧一些大企業客戶，也會支持私有化部署服務形式。
• 2C產品，如七麥數據、今日熱榜等，一般會提供SaaS服務（H5），比較少有支持PC客戶端或App客戶端下載的。

B. 客戶業務場景不同，導致的業務功能差異

由于這些系統（本文開頭提到的系統）面向的行業、客戶有所不同，這就導致具體的業務場景不同，業務場景不同，就會衍生出差異化的產品功能，也會根據業務需求，確定選擇用哪些技術實現。

（2）若產品是專門提供數據服務的，從數據的開、閉源角度來看，這些系統（城管系統、政務熱線分析系統、公共安全防控與預警系統、輿情系統、情報分析系統…，包括愛企查、企查查、還有飛瓜數據、蟬媽媽、七麥數據等）的對外服務模式也是有差異的。

• 若數據是開源的。廠商一般會選取SaaS形式交付（如輿情系統、為MCN/KOL提供營銷工具箱的產品：蟬媽媽、愛企查等、為C端用戶提供數據分析服務的產品：七麥數據等），數據治理分析的成果供客戶/業務側付費查詢、使用。
• 若數據是客戶提供的，即閉源的?？蛻粢话阈枰接谢渴鸢惭b（Based LAW）。如本文中的【城管系統】、【安防監控分析系統】、大企業使用的【OA系統】等。
• 若數據既有開源，又有閉源的。那么產品服務模式，就會變成：半SaaS（PaaS）+半私有化?？蛻粼试S廠商數據進入客戶內網，但客戶絕對不會允許客戶數據（關于人、車、公司強相關的業務數據，這些隱私、機密數據）出來到互聯網環境。

三、關于“架構”的一些思考

為什么會寫到這個內容，之前在面試過程中，幾次被問到了產品架構相關的問題，遂有了下述思考，小伙伴們可有自己的見解哈~

1. 什么是架構？

我們經常會在什么短語中聽到這個詞？組織架構，對吧？每行每業都會有架構師。建筑行業的架構師：建筑設計師，再細分開來：有土木結構設計師、鋼結構設計師、住宅建筑設計師、室內家裝設計…

我們互聯網這行，提到架構，經常會聽到：解決方案架構、業務架構、技術架構、產品架構、功能架構、信息架構…對吧？

那到底什么是架構呢？先放幾張圖感受一下：

圖來自網絡（如有侵權，聯系刪除）

圖來自于百度云官網-智能客服產品架構（僅作交流學習使用，如有侵權，聯系刪除）

圖來自于網絡-標簽體系架構（僅作交流學習使用，如有侵權，聯系刪除）

圖來某項目-個人設計的產品架構

圖來自于阿里云官網-某數據需求場景解決方案架構圖（僅作交流學習使用，如有侵權，聯系刪除）

我理解架構的本質，就是一個東西的內核，是其核心框架/骨架，并按一定的邏輯順序，將支撐這個系統的核心骨架串起來，并給出各個模塊間的交互關系，在每個骨架層同時加以“血肉”使其稍微“具象化”。至于最終的呈現形式可以是上面那些常見的規規整整的架構圖，也可以是流程圖，也可以是腦圖、表格…等多種展現形式。

那業務架構、產品架構、技術架構、信息架構之間的關系是怎樣的？

• 業務架構，一般來自于業務需求調研、業務流程梳理后，進行設計的，一般由企業的組織架構決定；
• 產品架構，一般來自于業務架構。
• 技術架構，來自于產品架構。
• 信息架構（在軟件領域），來自于產品架構，等于最終呈現給用戶的信息結構，如導航欄、菜單欄等。

2. 如何設計產品架構？

根據我相關產品/項目工作實踐經驗，我總結了幾個有效的設計產品架構的方法：

（1）從數據流向來設計。即從數據怎么來的->怎么加工處理的->到怎么給到業務去應用的這樣的順序去設計。

（2）參照OSI框架來設計。

（3）按Iaas、PaaS、SaaS，從底到頂逐層來設計。

其實，上面這幾種方法的本質是一樣的，我認為都是根據數據流向來設計的。那什么是好的產品架構設計？

——類比于房子等建筑的架構，其好與壞，可以用一些實際應用情況來評估，比如抗風程度、抗地震程度…軟件產品架構（軟硬件結合產品的架構），一般要求：其穩定性、健壯性、魯棒性均較強。

——但軟件產品與房子建筑架構（結構）又不太相似的地方在于：軟件產品一般更新迭代速度較快，而實體房子不會推倒重建（除非地震坍塌、建筑主體損壞，需要翻修等等），這就要求軟件產品架構還需具備很重要的復用性和可擴展性。

3. 產品經理的架構能力要求

產品經理，一般從產品助理做起，從一開始接觸簡單的功能需求（如設計一個簡單的功能模塊：這里面可能會包含業務流程的調研/梳理/設計、功能輸入輸出的制定、原型界面設計等內容）、到負責一個產品核心模塊的建設、到負責一整個產品線的建設，并為產品商業化負責。

在整個產品經理打怪升級過程中，不論是功能型的產品經理，還是策略型的產品經理，還是軟硬（硬件產品經理）結合的產品經理，其架構能力要求，肯定是逐漸升高的。

• 工作1-3年的產品經理，其JD中，基本上不會有架構設計能力要求
• 工作3-5年的產品經理，其JD中，大部分開始要求具備產品規劃、架構設計能力；
• 工作5-10年的產品經理（本質上，應該是高級產品經理或產品架構師了），其產品架構設計能力要求不言而喻，肯定是極高的。

圖來自Boss直聘（如有侵權，聯系刪除~）

圖來自我的某個offer

圖來自Boss直聘（如有侵權，聯系刪除~）

所以，我們1-3年或3-5年的產品經理平時在進行產品工作時，要多去了解公司的組織結構以及業務情況，以及市場上的其它優秀產品，才能據此設計出適合于部門或團隊的產品架構。架構能力的提升，我認為本質在于模塊化、抽象化思維的不斷鍛煉。

四、全文總結

本文主要基于個人此前的產品和項目及面試經歷，首先梳理了每個產品所解決的業務問題，然后介紹了這些產品在架構層面、在對外服務形態等層面的共通之處和差異點。最后介紹了關于“架構思考”的內容。文章中，如有不正確之處，歡迎小伙伴們指出，我們一同探討，共同成長~