我在安全行業(yè)創(chuàng)業(yè)——產(chǎn)品篇
編輯導(dǎo)語:本文作者和大家分享了做創(chuàng)業(yè)團隊中的產(chǎn)品經(jīng)理的一些感悟和產(chǎn)品工作流程,包括市場調(diào)研、需求分析、產(chǎn)品規(guī)劃設(shè)計、需求評審、協(xié)調(diào)跟進、產(chǎn)品測試和上線后反饋改進,希望對大家有所幫助。
宇宙的盡頭是考編,那產(chǎn)品經(jīng)理的盡頭是什么?
本篇文章是創(chuàng)業(yè)記錄的產(chǎn)品篇,本來想要寫的內(nèi)容很多,最終還是決定聚焦在創(chuàng)業(yè)團隊產(chǎn)品經(jīng)理的一些事兒。
我大學(xué)畢業(yè)的第一份工作是程序員,但相較于需要遵循既定規(guī)則的編碼工作,我更喜歡做有創(chuàng)造屬性的產(chǎn)品工作。從程序員轉(zhuǎn)行產(chǎn)品經(jīng)理,是有加分項,但由于沒有系統(tǒng)性的學(xué)習(xí)產(chǎn)品相關(guān)知識,同時也面臨不具備產(chǎn)品技能、缺乏產(chǎn)品方法論、無項目經(jīng)驗等困境,所以經(jīng)歷了很長一段海投簡歷卻鮮有回復(fù)或面試一輪便不了了之的“至暗時刻”。
我沒有大廠的工作經(jīng)歷,所以我這里分享的也是基于自己在中小企業(yè)、創(chuàng)業(yè)團隊中的經(jīng)歷。
在正式進入產(chǎn)品工作之前,往往是從老板、業(yè)務(wù)團隊、競品、用戶處獲取新想法或者行業(yè)新的發(fā)展趨勢,從而形成新需求。
一個完整的產(chǎn)品工作流程包括:市場調(diào)研、需求分析、產(chǎn)品規(guī)劃設(shè)計、需求評審、協(xié)調(diào)跟進、產(chǎn)品測試、正式上線、產(chǎn)品培訓(xùn)、收集反饋、持續(xù)改進。這里面也包含了產(chǎn)品經(jīng)理的工作職責(zé)和基本能力,下面我結(jié)合自己的親身經(jīng)歷,和大家分享一下這些流程中的一些事兒。
一、市場調(diào)研
市場調(diào)研一般包括用戶調(diào)研和競品調(diào)研。
1. 用戶調(diào)研
用戶調(diào)研是指通過包括但不限于問卷、現(xiàn)場訪談等方式獲取受訪者的痛點、建議、意見等,并針對用戶調(diào)研獲取的信息進行統(tǒng)計分析,從而具象為用戶具體需求或解決方案。
我們的用戶以政府、公安、企事業(yè)單位為主,他們對于問卷調(diào)查這類調(diào)研方式往往不太關(guān)注,也不會認(rèn)真對待。經(jīng)過兩次問卷調(diào)查發(fā)現(xiàn)調(diào)研結(jié)果不太理想后,我們也減少了問卷調(diào)查。當(dāng)我們在產(chǎn)品方向上有新的想法或改動后,就通過即時通訊工具或者現(xiàn)場調(diào)研會的方式,與用戶中的特定人群進行正式或非正式的溝通。
不管是TO G還是TO B類型的產(chǎn)品,往往業(yè)務(wù)鏈路長、業(yè)務(wù)流程復(fù)雜、涉及角色多。每次調(diào)研之前我們都需要明確本次調(diào)研的目標(biāo),在調(diào)研過程中也要一直緊扣主題,嚴(yán)格控制討論的邊界,防止出現(xiàn)會議主題跑偏的情況。
不管是我們自身還是用戶的時間、精力都是非常有限的,如果我們每次的調(diào)研會沒有達到想要的效果,從而出現(xiàn)多次反復(fù)談?wù)摰那闆r,用戶也會表現(xiàn)出不耐煩、甚至質(zhì)疑能力的情況。
2. 競品分析
競品調(diào)研主要包括競品定位調(diào)研、功能分析、商業(yè)模式分析。
要知道在TO B或者TO G領(lǐng)域,一般來說沒有哪一款產(chǎn)品能夠解決某個業(yè)務(wù)場景的所有問題。
比如我們行業(yè)內(nèi)的一家競品公司的產(chǎn)品,更多地聚焦在業(yè)務(wù)前期的委托受理和特定業(yè)務(wù)進行中常規(guī)狀態(tài)下的業(yè)務(wù)過程處理,另一家則更多地聚焦在通用場景的標(biāo)準(zhǔn)化處理過程。兩家公司的產(chǎn)品定位有重合,也有不同之處。而我們希望在這條賽道上能殺出一條路來,產(chǎn)品就必須有其他的亮點,畢竟打敗微信的一定不是另外一個微信。
經(jīng)過與用戶溝通,我們得知由于近幾年司法行業(yè)的整頓,用戶對業(yè)務(wù)處理過程中的操作行為留痕、文書歸檔、問題規(guī)避有非常強烈的需求,所以我們產(chǎn)品的定位就聚焦在司法行業(yè)業(yè)務(wù)處理過程規(guī)范化以及司法文書線上歸檔,致力于為用戶規(guī)避業(yè)務(wù)操作中的問題,完善問責(zé)制度。
相信很多產(chǎn)品經(jīng)理都做過功能分析,特別是在產(chǎn)品功能設(shè)計的時候。畢竟友商之間“互相借鑒”都是司空見慣的事情。但我們借鑒的時候,要知其然也要知其所以然。
最開始我使用競品的產(chǎn)品時,發(fā)現(xiàn)有很多莫名其妙的操作,明明可以非常簡便的完成某個流程,但競品卻設(shè)計得異常復(fù)雜,但當(dāng)我認(rèn)真梳理業(yè)務(wù)流程、政策文件時,才發(fā)現(xiàn)是出于業(yè)務(wù)流程需要和政策要求。
作為產(chǎn)品經(jīng)理,我們在使用任何一款產(chǎn)品的時候,其實都可以養(yǎng)成有意識地去理解產(chǎn)品設(shè)計背后邏輯的習(xí)慣,這也有利于我們在后續(xù)的工作中明確思路和參考“復(fù)用”。
在我最開始做競品分析的時候,最容易忽略的就是商業(yè)模式的分析,上周在“人人都是產(chǎn)品經(jīng)理”上,看到一位作者詳細(xì)地講了講商業(yè)模式與盈利模式的區(qū)別,獲益匪淺。文章里面提到,“商業(yè)模式=推廣模式+用戶模式+產(chǎn)品模式+盈利模式”。
雖然我們做任何一款產(chǎn)品都是為了盈利,但應(yīng)該先梳理用戶群體,明確提供產(chǎn)品的方式,做好推廣,最終才能實現(xiàn)盈利。這些要素加起來形成了一個完整的商業(yè)模式。
我們對競品的商業(yè)模式的調(diào)研也會反向給我們提供思路。我還是以我們的競品為例,一家競品仍采取以傳統(tǒng)的項目建設(shè)收費、按年收費、按照使用數(shù)量收費等收費方式。
而另一家則免費建設(shè),按照用戶案件的涉案金額或催收還款金額比例提成收費。同時包括與其他各大司法機構(gòu)合作形成數(shù)據(jù)互通。各大司法機構(gòu)保證案件數(shù)量,他們通過系統(tǒng)建設(shè)和技術(shù)服務(wù)的方式,保證案件成功率,以此形成對賭框架。
兩家公司的商業(yè)模式各有利弊,第一家更為穩(wěn)定但利潤率較低,第二家風(fēng)險相對較高但利潤率也較高。分析競品商業(yè)模式也是為了自己產(chǎn)品在形成商業(yè)模式上提供思路,形成一套完善的商業(yè)模式,當(dāng)然具體怎么選擇商業(yè)模式也要看團隊所處階段和團隊成員的秉性。
3. 政策調(diào)研
由于我們的產(chǎn)品和項目主要聚焦在“網(wǎng)絡(luò)安全+司法”領(lǐng)域,產(chǎn)品的需求和改動有很大一部分來自于法律法規(guī)、政策、國家標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)的變動,所以我平時除了用戶調(diào)研和競品調(diào)研,還會關(guān)注相關(guān)法律法規(guī)、政策的變動,甚至在必要的時候也會邀請行業(yè)內(nèi)專家對政策進行解讀,以便我們更好地理解政策用意和明確我們的解決方案。
二、需求分析
我在《售前篇》里寫售前工程師的“聽說讀寫”,其實“讀”就是用戶需求分析,搞清楚用戶的顯性需求和隱性需求,讀懂用戶的真實想法。但產(chǎn)品經(jīng)理的工作粒度更細(xì),會涉及到每一個功能點的設(shè)計,也會影響研發(fā)同事的研發(fā)進度和排期,所以產(chǎn)品經(jīng)理的需求分析也需要更細(xì)化。
我一般會從三個維度來分析需求:
1. 真需求or偽需求?
首先說一說真需求還是偽需求,我們接受需求的來源可能是客戶、公司老板、銷售團隊、技術(shù)團隊等,每個角色可能都是站在自己的角度提出需求。但“屁股決定腦袋”,我們不能盲目聽從他人的建議,我們也沒有辦法滿足所有用戶。
比如有一次我們技術(shù)團隊提出,考慮到數(shù)據(jù)的安全性,是否需要設(shè)置用戶在登錄情況下半個小時不操作,就自動退出登錄。一開始我還非常高興并且采納了技術(shù)團隊的建議,上線后卻遭到用戶強烈吐槽頻繁的重新登陸。
原因是用戶操作系統(tǒng)的環(huán)境是在一個有嚴(yán)格權(quán)限控制的物理環(huán)境,不會存在有其他相關(guān)人員能夠隨意進出和操作的情況,這就是我之前沒有結(jié)合實際情況判斷需求真?zhèn)巍?/p>
真需求還是偽需求有幾個簡單的判斷標(biāo)準(zhǔn):
- 需求提出方是不是我們的真實用戶;
- 是個性化需求還是通用需求;
- 需求是否和公司的利益存在沖突。
所以不光研發(fā)會砍產(chǎn)品經(jīng)理的需求,產(chǎn)品經(jīng)理自己也要學(xué)習(xí)砍需求。
2. 需求背后的緣由?
搞清楚需求背后的緣由是為了在產(chǎn)品規(guī)劃設(shè)計的時候,能夠達到用戶希望的效果。這個時候我們需要從用戶的真實使用場景、實際業(yè)務(wù)流程、操作的頻率入手,深入了解,以此才能在系統(tǒng)設(shè)計時找到更好的解決方案,當(dāng)然在設(shè)計過程中也要持續(xù)與用戶保持溝通,以避免錯誤理解需求或設(shè)計問題。
3. 需求是否緊急?
需求是否會影響到用戶的日常使用?不及時上線是否會對用戶或公司帶來損失?是否還有更重要的功能需求?這些都是影響需求排期的關(guān)鍵因素,所以需求需要區(qū)分優(yōu)先級、重要性,也要充分考慮公司戰(zhàn)略、投入產(chǎn)出比、團隊資源等因素。
比如我們創(chuàng)業(yè)團隊的開發(fā)資源永遠(yuǎn)是有限的,對于非緊急或并不那么重要的需求往往先放入需求池,等到后面版本再實現(xiàn)。
三、產(chǎn)品規(guī)劃設(shè)計
我理解的產(chǎn)品規(guī)劃設(shè)計其實是兩個層面的事情,“規(guī)劃”和“設(shè)計”其實是兩個層次的工作。
產(chǎn)品規(guī)劃是相對于需求的具象。相對產(chǎn)品設(shè)計的抽象,產(chǎn)品規(guī)劃包括業(yè)務(wù)流程梳理、產(chǎn)品架構(gòu)梳理、產(chǎn)品功能梳理,當(dāng)明確用戶需求之后需要對整個業(yè)務(wù)流程通過圖表的方式進行可視化的展示(Visio、Excel等),把所有流程、角色、節(jié)點、條件都羅列出來。
在梳理的時候要通盤考慮避免遺漏,這里可以自己整理一個查漏補缺表,通過查漏補缺表單和流程對應(yīng)檢查是否缺失。產(chǎn)品架構(gòu)梳理到產(chǎn)品功能梳理也是由抽象到具象的過程,我們首先通過梳理流程將不同業(yè)務(wù)流規(guī)劃成不同的系統(tǒng)板塊,再根據(jù)不同的系統(tǒng)板塊梳理羅列對應(yīng)的功能點。
比如我曾做過的一個產(chǎn)品,上級用戶向下級用戶下達的指令有不同的類型,而不同的指令類型的業(yè)務(wù)流程不同,我們就在梳理框架的時候?qū)⒉煌噶钭鳛椴煌南到y(tǒng)模塊羅列。
某類指令的實效性相較于其他指令的實效性更強,這類指令就需要加上即將逾期、已逾期等功能屬性,再根據(jù)不同的指令類型的流程和需求進一步明確功能點,這樣就可以從粗粒度的框架細(xì)化到細(xì)粒度的功能點。這樣做的好處是既可以避免功能模塊的遺漏,也可以避免因業(yè)務(wù)流程繁雜而導(dǎo)致規(guī)劃混亂的情況。
產(chǎn)品設(shè)計簡單來說就是將羅列出來的功能點,通過可視化的方式展示(包括原型圖、PRD文檔)。
曾經(jīng)剛?cè)胄械臅r候一直以畫好原型圖為終極目標(biāo),后來才發(fā)現(xiàn)畫原型是基本能力,而非核心能力,前期的調(diào)研、需求分析是輸入,原型圖、PRD是經(jīng)過梳理思考和嚴(yán)密邏輯推理后的輸出,原型設(shè)計的意義在于節(jié)省與客戶、研發(fā)、UI、測試等溝通成本和降低大家的理解成本,可以讓各方人員更明了地理解產(chǎn)品的功能與流程。
對于是高保真還是線框圖,也是根據(jù)不同公司的要求因人而異。重要地不是把原型畫得多漂亮,而是能在原型設(shè)計圖中將需求點講清楚。我一般更習(xí)慣用線框+簡單的交互,復(fù)雜交互我選擇用文字的方式梳理。
四、需求評審
其實我們做產(chǎn)品就是一個重復(fù)輸入、輸出的過程。需求調(diào)研(輸入)——>產(chǎn)品規(guī)劃設(shè)計(輸出)——>需求評審(輸出&輸入)——>原型調(diào)整(輸出)。
需求評審是每一個產(chǎn)品經(jīng)理都會經(jīng)歷的過程,產(chǎn)品在迭代,需求在更新,需求評審也會一直持續(xù)。
其實需求評審會最需要解決的問題就包括:
(1)向團隊成員傳達解釋需求價值(why),為什么會有這樣一個需求,我們?yōu)槭裁匆觯?/strong>
我們開需求評審會的成員可能包括:公司老板、業(yè)務(wù)部門負(fù)責(zé)人、研發(fā)、測試、UI等,需求的實現(xiàn)其實都是技術(shù)部門而非業(yè)務(wù)部門,他們可能對業(yè)務(wù)的理解和需求的價值并沒有老板、業(yè)務(wù)負(fù)責(zé)人、產(chǎn)品經(jīng)理深。在讓技術(shù)部門實現(xiàn)功能之前,要做到知其然,也要知其所以然。
很多時候研發(fā)的同事認(rèn)為,第一次需求確定了就不要再改了,每次讓他們修改之前的需求,總是需要軟磨硬泡,還會質(zhì)疑需求的合理性。但是市場在變化,客戶也在變,我們的產(chǎn)品更需要隨之調(diào)整。
傳達需求價值既是為了讓團隊成員對業(yè)務(wù)和需求的理解更清晰,也是為了讓他們知道這個需求并不是拍拍腦想出來的,更容易讓他們接受,也可以增強對你的信任感。
(2)向團隊成員輸出需求的具體規(guī)劃(what),這個需求的具體流程是什么,功能是什么?
會前我都會自己過一遍具體的規(guī)劃,再次梳理規(guī)劃的鏈路,保證能在會上更夠簡單、直接、明了地向團隊成員介紹。
會上首先通過思維導(dǎo)圖、流程圖的方式,讓團隊成員對系統(tǒng)的規(guī)劃設(shè)計有一個初步的印象。然后再通過原型圖的詳細(xì)說明,完整表達規(guī)劃思路。在這個過程中會穿插一些問題的討論,這個時候就需要充分聽取團隊成員的意見和建議。
雖然大家都說我們要把自己當(dāng)成用戶,但由于我們作為團隊內(nèi)部最熟悉業(yè)務(wù)流程的人,產(chǎn)品設(shè)計一定會有主觀元素在里面,有時候就難免會有一些設(shè)計不當(dāng)考慮不周的地方,這個時候團隊成員可能更容易站在用戶視角看待問題。
(3)與團隊成員協(xié)商需求的實現(xiàn)過程(how),功能如何實現(xiàn),由誰實現(xiàn),實現(xiàn)的周期?
任務(wù)分配、周期明確也是評審會的一個非常重要的環(huán)節(jié),計劃出來了得有人具體實施。這個就需要根據(jù)需求的輕重緩急、團隊資源、成員排期具體協(xié)商。
還有一些事情需要注意:
- 會前充分準(zhǔn)備,提前將相關(guān)資料文件與團隊成員共享,以避免團隊成員需要現(xiàn)場熟悉會議資料;
- 不要太玻璃心,有時候我們可能會出現(xiàn)產(chǎn)品規(guī)劃的時候有邏輯漏洞的情況,而被研發(fā)同事批得體無完膚,這個時候應(yīng)該勇敢承認(rèn)自己的錯誤;
- 會中注意控場,避免討論問題邊界太過發(fā)散;
- 會議結(jié)束前就關(guān)鍵問題進行總結(jié),確保大家對本次會議的議題達成共識;
- 會后及時做會議紀(jì)要,避免未參會人員僅能得知零散信息,導(dǎo)致產(chǎn)品推進進度慢。
五、協(xié)調(diào)跟進
我們沒有專職的項目經(jīng)理,產(chǎn)品經(jīng)理兼任項目經(jīng)理。產(chǎn)品研發(fā)迭代過程中,由產(chǎn)品經(jīng)理作為橋梁對上匯報、對下傳達,同時負(fù)責(zé)把控產(chǎn)品開發(fā)周期與進度,跨部門的協(xié)調(diào)溝通。
需求明確后,我一般會與研發(fā)負(fù)責(zé)人一起分解任務(wù)(細(xì)化到具體功能點),最終形成任務(wù)清單和里程碑;了解目前研發(fā)同事手里任務(wù)多寡,進而進行任務(wù)的分派;同時也會讓同事對分派任務(wù)進行再次確認(rèn)(簽字畫押),以增強目標(biāo)感和責(zé)任感。在整個研發(fā)過程中,我也會每天了解研發(fā)進度,以便及時發(fā)現(xiàn)并調(diào)整進度偏離的問題。
產(chǎn)品經(jīng)理還有一個很重要的職責(zé)就是跨部門甚至跨公司的協(xié)調(diào),研發(fā)同事往往更喜歡悶頭自己做自己的事情,對于這類協(xié)調(diào)溝通的事情不太擅長也不太情愿。產(chǎn)品進入研發(fā)階段,作為產(chǎn)品經(jīng)理更多也是協(xié)助研發(fā)同事能夠順利推進產(chǎn)品研發(fā)。
對外協(xié)調(diào)我們可能需要主動“組局”,比如我們經(jīng)常都會遇到與第三方公司接口聯(lián)調(diào)的情況,而跨公司協(xié)作就經(jīng)常會出現(xiàn)溝通問題、時間問題。我們需要提前把兩家公司的相關(guān)人員聚集起來共同制定目標(biāo),約定調(diào)試時間,以免出現(xiàn)一方長時間等另一方的情況(畢竟大家的時間都很寶貴)。
對內(nèi)我們也需要及時協(xié)調(diào)溝通,比如后端開發(fā)已經(jīng)把所有功能接口完成了,但前端還在等UI設(shè)計圖,導(dǎo)致項目會出現(xiàn)停滯的情況。這些都是我們需要去解決的。
六、產(chǎn)品測試
嚴(yán)格來說產(chǎn)品測試的時間和產(chǎn)品開發(fā)的時間應(yīng)該是一半一半。
沒有經(jīng)過系統(tǒng)化的測試,大概率在正式環(huán)境中會出現(xiàn)很多問題。產(chǎn)品測試也不能僅僅QA部門,作為產(chǎn)品經(jīng)理,你是設(shè)計產(chǎn)品的人也是最熟悉產(chǎn)品的人。
測試階段前將測試用例寫好真的非常重要,我們要把每一個需要測試的分支項詳細(xì)羅列,對于需要重點測試的板塊也要提醒,標(biāo)注測試方法和預(yù)期結(jié)果,不管是我們自己測試還是QA測試,甚至全員測試的時候大家方便對照。
我一般會在交給QA部門前,自己進行至少2-3次的系統(tǒng)性測試,在測試過程中也會發(fā)現(xiàn)一些自己以前沒有考慮周到,研發(fā)也沒有發(fā)現(xiàn)的問題,這樣做也是為后面測試的同學(xué)節(jié)省時間(因為我們的資源真的很緊張,我們幾條產(chǎn)品線并行,但測試人員也嚴(yán)重不足。)
我們測試問題一般是放在禪道上,然后指派給對應(yīng)的研發(fā)同事,研發(fā)同事修改完善后記錄,再進行回歸測試。雖然我不是專業(yè)的QA,我們的測試流程也沒有大廠那么嚴(yán)謹(jǐn),但在不斷地摸索過程中也發(fā)現(xiàn)了一些容易出錯的點,總結(jié)了一些方法。
七、上線、反饋、改進
產(chǎn)品做得怎么樣,就需要上線后交給用戶來評判了。
不管是項目還是產(chǎn)品都是周期的,一定會有一個開始節(jié)點和關(guān)閉節(jié)點。諾蘭模型把系統(tǒng)的周期分為初始期、普及期、控制期、整合期、數(shù)據(jù)管理期和成熟期,周期之間都必須從一個階段發(fā)展到下一個階段,不能實現(xiàn)跳躍式發(fā)展,這些周期也對應(yīng)了我們產(chǎn)品優(yōu)化迭代的進度。
沒有十全十美的產(chǎn)品,沒有能夠滿足所有用戶的產(chǎn)品。包括微信才出來的時候,同樣也有很多不盡如人意的地方,他們同樣也是通過建立反饋機制,搜集數(shù)據(jù),不斷地改進才有了現(xiàn)在的樣子。
我們做產(chǎn)品同理,我曾經(jīng)聽到一句話“如果我們不能做到一鳴驚人,那就先以破爛示人”,深以為然。我們可以允許前期產(chǎn)品的缺陷,這些缺陷或許是我們了解用戶不夠、或許是我們思考不到位、或許是我們團隊資源不足,但我們要以良好地心態(tài)去面對去解決,破爛是一時,改進才是常態(tài)。
面對用戶的反饋,擁有良好心態(tài)也是非常重要的。無論是吐槽還是謾罵,我們都要本著做產(chǎn)品的初心去面對。有人吐槽說明他們是真的在用,沒人反饋才是最糟糕的。我們要學(xué)會主動去過濾無用信息,主動尋找并聽取有效建議。
以上是我基于一個完整的產(chǎn)品工作分享的一些思考感悟。
回到文章最開始的問題,產(chǎn)品經(jīng)理的盡頭是什么?在我看來產(chǎn)品經(jīng)理沒有盡頭,只有無止盡的學(xué)習(xí)和思考,不斷地輸入再輸出。
人人都可以是產(chǎn)品經(jīng)理,但不是人人都可以做好產(chǎn)品經(jīng)理。
本文由@蹦蹦怪 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Pixabay,基于CC0協(xié)議
你的例子中說到:客戶投訴長時間不操作需要重新登錄;
但是這個功能(超時自動登出)對于2B的客戶,應(yīng)該是報障產(chǎn)品安全、用戶信息安全的最基本功能;不得不說客戶是愿意為了便利性犧牲一點安全性的。
最后你們這個功能改了嗎?
改了,還是要考慮特殊情況。
作者可以分享下讀到的那篇商業(yè)模式和盈利模式的文章嘛
http://m.22none.com/pmd/5232745.html
謝謝作者大大
產(chǎn)品經(jīng)理要學(xué)會去理解產(chǎn)品設(shè)計背后邏輯的習(xí)慣,這有利于在后續(xù)的工作中明確思路和參考。雖然產(chǎn)品都是為了盈利,但也要產(chǎn)品做得好、給用戶好的使用感受才能盈利啊哈哈。
你這名字起得可有些名字了,哈哈哈。安全行業(yè),我以為會給我們普及哪些是安全行業(yè),怎樣在里面進行創(chuàng)業(yè),看完才發(fā)現(xiàn),原來每一個行業(yè),只要不違法,都是安全行業(yè),在自己熟悉的行業(yè)內(nèi)進行創(chuàng)業(yè)。
安全的范疇太大了,有業(yè)務(wù)就需要有安全,安全和業(yè)務(wù)是互利共生。
客戶有網(wǎng)站有域名,那就需要WAF、抗DDoS產(chǎn)品;用戶有線下機房或者有云主機,那就需要相應(yīng)的配備主機安全防護產(chǎn)品;有容器就給配容器安全產(chǎn)品;有大量的數(shù)據(jù),就需要配數(shù)據(jù)治理、數(shù)據(jù)脫敏等數(shù)據(jù)安全產(chǎn)品;客戶公司規(guī)模比較大,就需要配備相應(yīng)的IDDAS體系。
安全很大,往大了說安全包括身份、日志以及專業(yè)的安全服務(wù);狹義的安全包括專業(yè)的安全服務(wù),如主機防護、態(tài)勢感知等