• 自動秒收錄
                    • 軟件:1973
                    • 資訊:57811|
                    • 收錄網站:279872|

                    IT精英團

                    B端產品的需求管理和迭代優化

                    B端產品的需求管理和迭代優化

                    瀏覽次數:
                    評論次數:
                    編輯: 喵星人
                    信息來源: 增長研究社
                    更新日期: 2022-08-15 13:02:04
                    摘要

                    本篇目錄:原始需求與產品需求區分原始需求和產品需求原始需求提報管理產品需求的層次和價值需求的三個層次需求的四類價值需求池管理需求的優先級成本價值

                    • 正文開始
                    • 相關閱讀
                    • 推薦作品

                    本篇目錄:

                    原始需求和產品需求

                    區分原始需求和產品需求;提交原始需求以管理產品需求的水平和價值。

                    三個需求層次和四種價值需求池管理

                    需求優先級

                    成本模型、RICE模型、值域模型和KANO模型要求的驗證和評估

                    通過拆解指標評估業務需求收入,通過NPS評估用戶需求收入,通過綜合方案評估技術需求收入。終極衡量指標:研發;檢查用戶迭代中的資源管理。

                    研發的人力資源;d資源跟蹤產品開發不同階段的技術資源。產品投產后,需要不斷升級、迭代、優化。產品經理應該管理需求,區分優先級,決定工作計劃,選擇做什么和不做什么。

                    在本文中,我們進一步討論B端的需求管理和迭代優化。首先,我們介紹了原始需求的收集和管理。其次,討論產品需求的分類、層次和價值,然后談需求池的管理,同時深入討論需求的優先級設計。最后分享一些需求驗證和持續迭代中技術資源合理分配的思路。

                    原始需求與產品需求優化

                    原始需求和產品需求是需求分析和管理中最基本、最重要的概念。首先,我們需要明確它們的定義和區別。

                    區分原始需求和產品需求

                    無論是產品經理通過訪談和問卷收集的,還是業務方和用戶主動提交的需求,原始需求,原始需求,都可能存在一些混合需求,可能是用戶提出的痛點描述或解決方案。原始需求是終端用戶/客戶提給產品經理的訴求描述。

                    產品經理通過分析挖掘原始需求,找到痛點,形成軟件產品設計方案,從而形成產品需求.產品需求是粒度清晰、邏輯嚴謹完整的產品需求,是產品經理提給研發人員的軟件設計方案。.

                    在處理過程中,原始需求是最原生態的需求描述,充滿了不確定性;產品需求則是分析問題后的的解決方案(或初步的思路拆解),具備確定性。的原始需求可能被分解成多個產品需求,或者與其他原始需求合并成為同一個產品需求。原始需求和產品需求是多對多的關系,產品需求會對應多個R & amp任務和測試任務。邏輯關系如下圖所示。

                    "https://p3-sign.toutiaoimg.com/tos-cn-i-qvj2lq49k0/59d8e6cd427e4551b58410a75196406d~noop.image?_iz=58558&from=article.pc_detail&x-expires=1661143852&x-signature=mJWk6H38L9TW2JgfPAvxy6gXCgY%3D" img_width="1080" img_height="102" image_type="1" mime_type="image/png" web_uri="tos-cn-i-qvj2lq49k0/59d8e6cd427e4551b58410a75196406d">

                    原始需求和產品需求的關系

                    例如,M公司分銷平臺業務中,業務運營同學提交了一個原始需求,希望支持品類券(針對特殊品類生效的優惠券),并且發券數量超過1000張需要觸發審批。這個原始需求里邊包含了兩個需求,一個是增加新的營銷工具(品類券),目的是提高客單價和收入;另一個是審核規則,目的是控制風險。

                    果凍分析后,將這個原始需求拆解為兩個產品需求,分別是品類券需求和審批流需求,其中審批流需求合并到規劃中的流程引擎項目中,構建一套完整的審批解決方案,品類券需求提交研發后,研發根據功能feature又創建了多個研發任務,包括:

                    • 任務一:品類券在商城前端的展現(包括購物車、訂單、個人中心等位置);
                    • 任務二:品類券在后臺的管理配置功能(包括列表頁、創建編輯頁);
                    • 任務三:品類券的發放提醒功能(這部分可能會調用現成消息接口);
                    • 任務四:品類券在交易結算中的分攤邏輯,以及臺賬和財務處理規則;

                    實際研發任務拆的會更細致,以上僅僅是示意,而且以上拆分的顆粒度,依然是功能點級別,每一個功能點背后可能還要對應多條研發任務。

                    可見,原始需求并不直接等同于產品需求,產品經理需要完成原始需求到產品需求的轉換設計。

                    我們在前面文章介紹的需求分析十三要素五步法,就是對原始需求的分析過程,而其中第五步設計產品方案,輸出產物就是產品需求。

                    在口頭交流中,為了方便,我們往往將原始需求和產品需求混在一起討論,不會做嚴謹的區分;例如,當我們說“這個需求優先級不高”,這句話說的既可能是原始需求,也可能是產品需求。但在正式的需求池管理中,一定要對兩者進行區分,否則會帶來管理和執行上的混亂。

                    原始需求提報管理

                    不論是甲方做對內系統的產品經理,還是乙方做商業化的產品經理,都會面臨一個比較苦惱的問題,業務方或者客戶,總是提一些一句話的拍腦袋需求,很多時候根本沒有想清楚,但也會耗費產品經理大量的時間去溝通核實。

                    為了避免用戶不經思考隨意提需求帶來沒必要的資源損耗,可以考慮讓用戶通過填寫需求提報模板來提交需求,促使用戶提需求前把一些關鍵事項想明白,提高需求質量,尤其適合甲方公司。(乙方公司面臨的現實情況是需要更好的主動服務客戶,如果讓客戶通過模板提需求估計老板也不同意?。。?/p>

                    具體模板見下表,內容很容易理解,此處不再贅述,可以根據自身情況調整后使用。再次強調的是,任何需求,都應該提前想清楚需求價值,以及上線后如何衡量價值是否實現,并依據效果做持續的閉環優化跟蹤。不論是誰發起的需求,都應該提前想清楚需求的預期收益和度量方式。

                    原始需求提報表

                    需求編號

                    BRD_業務部門縮略編碼_yyyy-mm-dd

                    新需求:此部分由業務人員填寫

                    需求變更:此部分由業務人員填寫,需要寫明原需求編號

                    需求名稱


                    提交人


                    業務負責人


                    提交時間


                    期望上線時間


                    優先級

                    采用公司統一定義的項目管理優先級定義,例如高、中、低

                    問題描述

                    業務中遇到的問題,需要清晰、詳盡

                    期望目標

                    期望解決哪些問題,或改善哪些指標

                    預期收益

                    預期獲得的收益,盡量用客觀數字描述

                    期望解決方案

                    期望的問題解決方案

                    期望上線日期

                    yyyy-mm-dd

                    存在風險

                    預計需求背后可能存在著的各類風險,包括業務風險、商業風險

                    相關部門

                    干系人1

                    收益/影響

                    干系人2

                    收益/影響



                    產品需求的層次和價值

                    產品需求,從軟件工程角度來講,可以分為功能需求、非功能需求;從需求背后的業務價值和分類的角度來講,又可以分為業務需求、用戶需求、技術需求,這也體現了B端需求的三個層次。

                    需求的三個層次

                    在C端產品設計中,常常將馬斯洛模型作為C端產品需求洞察的理論基礎,并依此推演C端產品的用戶價值,以及進一步延展出用戶旅程、KANO模型等一系列構建C端產品設計的方法論。遺憾的是,這些模型和方法論并不完全適用于B端產品設計與需求管理,主要基于以下原因。

                    • B端產品面向企業或組織,幫助其解決某類經營管理問題,對于機構來講,需求的本質在于業務管理,無法通過馬斯洛模型來定義描述。
                    • B端產品的關注對象,除了機構本身,也需要關注業務用戶,而業務用戶的需求動機也并非馬斯洛模型可以解讀。
                    • B端產品作為復雜系統,除了承載業務目標,還需要考慮軟件架構設計、體系構建等問題,因此需求分析管理中,對于軟件產品本身還需要有足夠的關注度。

                    基于以上所述,可以發現,B端產品的需求來源和場景復雜,很難像C端產品那樣基于馬斯洛模型從單一維度去覆蓋需求洞察的工作,而需要從幾個維度分開來審視B端的需求類型和層次。

                    實際上,我們可以將B端需求分為三大類,分別為業務需求、用戶需求、技術需求,這三個類別本身由上到下具備層次關系,每一類需求處理權衡時都有不同的考量。

                    業務需求

                    業務需求,是自頂向下的需求,往往來自于中高層管理人員(或監管、政策要求),基于業務運營管理的直接訴求和要求,例如業務規則、管理制度、業務流程、組織機構,這些都屬于業務需求。

                    業務需求的分析過程,往往采用了經典傳統的軟件需求分析設計思路,重點通過業務診斷分析、抽象建模(DDD設計思想)、流程再造(BPR)的方式,進行需求分析和設計工作。

                    業務需求,承載了B端產品的業務價值,為相關業務的運營管理助一臂之力。注意這里所說是業務價值,而非商業價值。商業價值往往要上升到企業的層面,而B端產品多數情況是為單一業務部門服務,承載的更多是業務價值。

                    業務需求,多數情況下難以衡量具體的收益,例如,很難衡量設計開發了某個CRM管理模塊,就會對銷售業績有多少程度的提升;即便如此,產品經理也要盡量嘗試量化收益和價值,關于幾類需求收益價值的討論,在本章第四節會進一步展開。

                    用戶需求

                    用戶需求,是自下向上的需求,來自于一線業務用戶和基層管理人員,更多體現著業務人員對業務規則、流程、系統操作交互上的改進訴求。

                    現如今SaaS形態的B端產品都更加關注用戶體驗,其交互體驗和操作流暢度要好于傳統的管理軟件。在梳理B端產品的用戶需求時,可以大量借鑒C端產品的需求管理方法論,例如客戶旅程地圖,KANO模型等。

                    用戶需求體現了用戶價值?;ヂ摼W思維下,即便是B端產品,也需要重視用戶體驗和用戶價值,包括了功能滿意度和操作效率等;尤其是工具型、基礎服務類產品,解決了一線用戶的痛點,就是解決了業務的痛點,產品賦能終端用戶、重視體驗就顯得更為重要。

                    通過針對功能模塊定期的滿意度調研(NPS)可以較好的度量用戶需求的滿足情況。另外也可以從效率提升、時間節約的角度去衡量、評估收益。

                    技術需求

                    B端產品復雜程度高,建設到一定階段,甚至有些時候在建設初期,就要考慮功能復用問題,以及與其他系統的架構設計與交互問題。例如,對于業務系統的權限管理模塊,是復用基礎服務,還是獨立開發?對于消息中心和公告通知模塊,是復用基礎服務還是獨立開發?除此以外,還有類似于軟件產品功能完備性提升的訴求,例如靈活的后臺配置模塊,報表引擎的配置,視圖編輯器的配置,這類需求,我們可以統稱為技術需求。

                    技術需求往往不具備明顯的業務價值(但可能具備用戶體驗價值,例如視圖編輯器的能力構建),但是在軟件系統結構合理性設計上,具備顯著價值。除了讓架構合理,還能節約重復開發的人力浪費。產品需求承擔了軟件的系統價值,為系統自身優化而服務,讓系統自身合理并增值。

                    對于技術需求的收益評估,可以考核功能復用以及架構完善,對研發人力的成本節省。

                    業務需求、用戶需求、技術需求,作為B端需求的三大類型,也體現出了層次關系。對于B端產品的核心目標,首先服務于業務,要滿足業務需求;其次,要關注用戶的體驗和效率,滿足用戶需求;最后,要考慮軟件結構的合理性,滿足技術需求。

                    【資源推薦】

                    關于需求層次的更多分析,推薦貝恩咨詢分別于2016年、2018年發表于哈佛商業評論(HBR)的兩篇論文,探討了基于馬斯洛需求層次在2C領域的價值要素金字塔模型;以及借鑒馬斯洛模型,嘗試構建了2B業務的價值要素金字塔模型。

                    需求的四類價值

                    B端產品需求的價值可以從對內對外兩個視角分為商業價值、技術價值、業務價值、用戶價值四大類。

                    商業價值

                    如果是商業化售賣產品,我們首先要判斷的是需求的商業價值,是否符合產品本身的定位和規劃,是否遵循產品商業化售賣的戰略訴求和經營要求。

                    例如,在M公司分銷平臺的SaaS化設計中,是否要實現銷售型CRM模塊,這就是一個涉及商業價值判定的決策,而非基于客戶的業務訴求;從業務價值來看,銷售管理對客戶的業務是有益的,但從商業價值來看,該模塊不符合產品定位,并且會泛化產品邊界,擴大研發成本,稀釋商業競爭力,因此我們不考慮實現它。

                    如果是對內使用的產品,商業價值是比業務價值層次更高的,從企業整體戰略經營角度帶來的價值。

                    例如,M公司分銷平臺的設計,首先是為了實現對分銷業務支持賦能的業務價值,在更深的層面,則支撐了M公司期望實現多元化經營戰略的商業價值的。

                    業務價值

                    B端產品除了承載商業價值,更需要幫助客戶、用戶在業務上取得成功,這是B端產品的業務價值。

                    我們在第1章講到過,B端產品對企業來講承擔著提升收入、降低成本、提高效率、保證品質、控制風險的重任,這些都是B端產品的業務價值。

                    用戶價值

                    B端產品本質上是為了解決業務問題而存在的,但設計過程中也要考慮終端用戶的體驗問題,包括是否能夠提升一線效率和滿意度,這是產品的用戶價值。有些時候,賦能用戶,其實也是賦能業務,提升了用戶價值,也就提升了業務價值;例如針對協同辦公類產品,提升整體使用體驗,可以提高員工的工作效率,實際上也提升了企業整體的運作效率。尤其是針對工具型、基礎服務型產品,提升了用戶價值,也就提升了業務價值。

                    技術價值

                    軟件產品在構建過程中,自身也存在技術層面的優化點,比如說,我們要將列表頁進行支持自定義設置的改造,從而解決為不同客戶三天兩頭硬編碼修改列表頁的煩人工作,這類需求是為了降低研發成本,或提升產品化能力而存在的;再比如說,為了解決企業客戶重復的問題,我們需要將產品背后的應用架構進行主數據改造,這類需求是為了改善架構合理性而存在的;這些都是技術需求背后可能的價值。

                    以上需求的四類價值,不論是商業化軟件產品,還是對內使用的產品,業務價值、用戶價值、技術價值本質上都最終服務于商業價值;而需求的三個層次正好一一應對這三類價值。

                    產品規劃建設過程中,四類價值的優先級并不是一成不變的,不同的產品階段可能有不同的優先級策略。

                    例如,M公司分銷平SaaS商業化的初期,要先解決客戶的業務問題,需求的業務價值優先級高于技術價值。但隨著客戶數量的增大,一些交互層面的定制化需求越來越多,不支持,傷害用戶體驗;硬編碼支持,又浪費研發資源。此時,技術需求的優先級可能就會提高,類似于自定義視圖編輯器這種組件的設計需要被采納執行,而這么做,是因為產品對業務的支持已經有很好的成熟度,需要加大產品化能力,強化配置能力,核心目的也是為了服務產品的商業價值。

                    小結

                    最后,我們通過一張圖,來總結回顧需求的類型、層次和價值,如下圖。

                    需求的類別和價值

                    對原始需求分析后,進行拆散或合并,形成產品需求。從軟件工程角度來講,產品需求可以分為功能需求和非功能需求,從業務角度來講,又可以分為業務需求、用戶需求和技術需求,這也體現了需求的層次,具有天然發的優先級屬性。這三層需求也分別體現著產品的業務價值、用戶價值和技術價值,最終都是為了服務于商業價值。

                    需求池管理

                    產品經理需要管理維護兩個需求池,原始需求池,和產品需求池。

                    原始需求池記錄了所有用戶端提報的原始需求記錄,產品需求池,是對用戶需求經過初步分析拆解后形成的需求清單。

                    用戶需求池體現的是從用戶提報的角度來記錄,產品需求池體現的是從產品管理的角度來記錄。用戶需求和產品需求應該有明確的關聯,可以互相追溯,一方面方便用戶從提報需求的角度理解相關工作的進展,另一方面幫助產品經理找到產品設計背后對應的原始需求軌跡。

                    原始需求一旦記錄在案,更多的是存檔保留,產品需求則可能被更新、調整。一旦產品需求形成產品方案投入研發,就會進入明確的項目管理周期。

                    有條件的話,需求池管理應該使用項目管理軟件進行,但只要負責人用心,Excel同樣可以管理好需求池。下邊,我們來介紹一個產品需求池中典型的字段:

                    • 產品需求ID

                    需求唯一性主鍵。

                    • 原始需求ID

                    對應的原始需求編號,可以為多個。

                    • 產品線

                    描述需求所在產品線(或對應的業務線),例如CRM系統或客服系統等。

                    • 需求類型

                    需求類型應該做謹慎的設計分類,主要目的用來分析資源在不同業務方向上投入的情況??赡艿男枨箢愋桶I務需求、用戶需求、技術需求,或者純粹根據業務價值分類,包括:提升規模、降低成本、提高效率、控制風險、保障品質、體驗優化等??傊?,要根據自身情況設計一個合理的分類。

                    • 是否插隊

                    用來專門記錄需求是否在項目執行中做了插隊執行的字段。

                    • 主題

                    需求的一句話概述。

                    • 內容

                    需求的具體描述。

                    • 來源

                    需求的提出人,或提出部門。這個數據可以來自于原始需求。

                    • 需求提出日期

                    收到需求的日期。有些公司會要求產研團隊提高需求響應速度,可能會通過上線日期和需求提出日期的時間差來進行考核評估。

                    • 優先級

                    優先級會在下一節詳細介紹。

                    • 迭代版本

                    如果采用了敏捷開發模式,就需要標記需求排期開發時的迭代版本。

                    • 業務負責人

                    該需求業務口的唯一負責人

                    • 產品經理

                    該需求對應的產品經理。

                    • 研發負責人

                    研發負責人一定是研發的整體負責人,而不應該分成后端負責人、前端負責人,因為那樣很可能導致兩者各自負責自己的工作,但是對于技術實現的整體方案和進度沒有把控,相當于沒有技術負責人。

                    • 測試負責人

                    如果研發負責人全權管理研發、測試工作,則不需要單獨指定測試負責人。否則,要明確安排測試負責人,對質量結果和進度負責。

                    • 狀態

                    狀態用來描述需求的生命周期,狀態值可以包括如下選項:

                    待跟進、需求調研中、PRD編寫中、待PRD評審、待技術評審、待排期、待開發、開發中、待測試、測試中、待驗收、待上線、已上線、暫停、終止。

                    這些狀態值較好地覆蓋了從需求采集到上線的完整生命周期,仔細觀察后可以發現,這些狀態的設計符合我們在介紹狀態機圖時提出的建議,即狀態應該是能持續足夠時長的,不應該是很快就結束的(所以我們沒有定義“需求評審中”這種狀態,因為需求評審只需要開幾個小時的會議就可以完成,沒有必要在開會前改一下需求狀態,開會后再次修改)。

                    • 狀態變更說明

                    對某些狀態字段的補充解釋,例如如果狀態被修改為“暫?!?,需要選擇被暫停的具體原因。

                    • 計劃上線日期

                    計劃上線日期是在技術評審結束后,研發負責人確定工時和資源投入后給出的目標上線日期。

                    • 實際上線日期

                    實際上線日期是系統的真正上線時間。通過對比實際上線日期和計劃上線日期,可以統計項目的延期情況,并進一步分析延期原因。

                    • 前端開始日期/前端結束日期

                    前端開發工作的開始日期和結束日期。

                    注意,工期和工時是兩個完全不同的概念,工期是指開發時長,工時是指工作量。例如,為了開發某功能,安排了2名研發人員,從9月1日開始開發,到9月5日提測,則工期是5天,工時是10人日。如果這兩名研發人員并不是同時介入的,其中一名研發人員是9月1日介入的,另一名在9月3日才介入,到9月7日提測,則整體工期是7天,但工時依然是10人日。

                    • 前端研發工作量(人日)

                    即前端開發工作預計投入的總工時。在敏捷開發中,可能通過基于經驗的“點數”來評估工時。

                    此外,后端開發及測試的開始時間、結束時間、工作量,這些字段的含義與前面所講的類似,不再贅述。

                    • 發版計劃

                    在移動端產品中,需求上線可能涉及發版,即需要發布新的客戶端,因此要在表格中記錄發版的版本號。

                    合理運用上述模板,可以幫助產品經理將需求和項目管理得井井有條。認真填寫模板中的各項內容,可以幫自己較好地分析需求跟進情況、研發效率、工作量投入等。

                    如果某個需求涉及跨端或跨團隊開發,則需要按照子項目將模板進一步細化,例如每個子項目要安排各自的研發負責人、產品負責人,有各自的工時、工期等,然后再填寫具體字段。

                    在實踐中,并不一定在產品需求池中記錄管理研發狀態,有可能產品需求池只管理產品層面的需求清單,具體的研發執行,會通過另一個研發任務池進行管理??傊?,根據自己團隊的習慣和風格,或者公司的統一要求,選定一個模式或方案,持續執行,正確記錄相關字段和內容,保證可以做出11.3小節那樣的整體性分析,以便持續優化產研效率,就可以了。

                    需求的優先級

                    需求優先級的判斷,是產品經理工作的一個難點。決策先做什么,再做什么,決定了產品的發展路徑和節奏,甚至會決定產品在市場環境中競爭的優劣。遺憾的是,優先級的判斷,在實踐中,很難通過一套理性的方法論作為客觀的執行依據,很多時候,優先級的判定是一門藝術,融合了對戰略、市場、競爭態勢、業務發展、研發資源、團隊情況的綜合判斷。

                    即便如此,產品經理需要了解業界經典的優先級定義的方法論,在不同的場景和情況下,給自己更多的思路和啟發。

                    成本價值模型

                    成本價值模型,是優先級判定最基本的、最通用的方法論,也是其他理論的核心基礎。

                    如果通過研發成本和需求價值這兩個維度劃分出四個象限,可以將需求放置在某個象限之中,根據需求所在不同象限,可以得到優先級的劃分策略,這就是成本價值模型。

                    需求優先級的成本價值模型

                    • 第一象限中的需求,價值巨大,但成本投入也比較大,理性的做法,應該是規劃并持續關注。
                    • 第二象限中的需求,價值巨大,實現成本又很低,當然要快速拿下,所以我們應該迅速投入。
                    • 第三象限中的需求,價值和成本都很低,這就有點像雞肋,食之無味,棄之有肉。處理的策略可以是關注并抽空實現。
                    • 第四象限中的需求,價值很低,實現成本反而很大,這種需求沒有做的必要哦了,我們應該忘掉他們。

                    綜上可以給出,位于不同象限需求的優先級,即II > I > III > IV。

                    然而,需求的實現成本相對容易衡量,需求的價值卻很難量化評估!

                    RICE模型

                    對于SaaS軟件,判斷需求的價值時,還可以將受影響客戶數量考慮進來,這就需要參考來自硅谷的RICE模型。

                    RICE是四個單詞的縮寫,分別代表:

                    • R:Reach,需求功能觸達的客戶數量;
                    • I:Impact,需求的價值打分,例如可以定義1到10分;
                    • C:Confidence,產品經理對需求的信心程度,是一個基于主觀判斷的修正參數;
                    • E:Effort,需求需要投入的研發人天;

                    通過這四個變量,對需求進行打分,可以得到優先級RICE得分,計算公式如下:

                    RICE Score = Reach * Impact * Confidence / Effort

                    例如,下表是兩個需求通過RICE模型計算后的得分,根據分數,認為需求1優先級高于需求2。

                    通過RICE模型對需求優先級進行打分

                    需求

                    Reach

                    Impact

                    Confidence

                    Effort(人天)

                    RICE Score

                    需求1

                    100

                    3

                    80%

                    30

                    8.0

                    需求2

                    500

                    1

                    60%

                    35

                    6.7

                    RICE模型很好地納入了受影響客戶數量這個因素,但也有其局限性。

                    首先,關于Impact產品價值,本身就是很難量化的一個引子,所以RICE模型并不能解決成本價值模型中面臨的困境,如何定義需求的價值?

                    其次,在商業運作中,并不能簡單的認為,在其他變量相同的情況下,需求影響的客戶數量多,優先級就高。有些需求,可能只服務于某個頭部客戶,但卻具有標桿效應和示范效應,本身就有很高的商業價值。

                    因此,關于RICE模型的應用,要想清楚場景和目的。

                    價值范圍模型

                    價值范圍模型,是一個專門分析、衡量需求價值的模型,是我根據工作實踐總結而成的,在和不同的企業交流中,我發現很多團隊有著類似的思考和實踐。

                    我們可以將一個軟件產品所能提供的價值(即本書中多次提到的B端產品的五個典型價值,規模、成本、效率、風險、品質,再加一個產品本身的用戶體驗)列在縱軸,把業務相關的利益方都列在橫軸,就得到一個多象限矩陣,有了這個矩陣,我們可以根據當前階段業務的計劃和商業的訴求,制定一個優先級打分表。

                    和業務方達成一致認知,設計好這張表格,后續所有的需求,都可以找到表格中的位置,以及對應的優先級。

                    例如,下圖是M公司分銷平臺的范圍價值模型打分表,表格中縱軸是分銷平臺對業務本身的價值,橫軸是涉及到的利益方,單元格中直接定義了優先級。

                    M公司領導本身也代表了業務,所以提升收入的相關需求都可以納入M公司領導和提升收入這兩個坐標定位的單元格,我們認為分銷平臺核心目的是提升收入,所以這類需求優先級最高。

                    而針對M公司領導個人的降本增效、產品體驗類需求,優先級都比較低,因為領導本身也不常用系統,不用為了領導一個人的使用體驗而投入資源進行優化。

                    我們再來看看客戶采購人員,對于他們來講,不存在提升收入的業務價值,所以單元格用橫線填充;而操作效率、交互體驗,防錯控制更重要一些,所以產品體驗和控制風險兩個單元格的優先級定義為Medium。

                    以此類推,基于對業務的判斷和理解,梳理了角色和產品本身具備的業務價值,進一步設計了完整的優先級打分表。

                    價值范圍模型打分表

                    價值范圍模型比較適合用于企業對內產品研發中的需求優先級打分,在實際應用中會有很多變化和調整,例如作為一個中臺產品,可以將橫軸替換為中臺產品服務的各個事業部業務線,提前規劃好對不同業務線的支持力度,作為優先級判斷的決策依據。

                    設計一張得到所有人認可、意見統一的價值范圍模型打分表,還能避免未來和業務方扯皮的問題。任何需求都能在提前定義的表格中找到優先級的位置,不用再根據誰的嗓門大來做決策。

                    ANO模型

                    KANO模型,常常用來分析單一用戶視角下需求的接受度,由東京理工大學教授狩野紀昭(Noriaki Kano)發明。嚴格來講,KANO模型研究的是產品功能點和用戶滿意度之間的關系,但結論可以作為優先級的排序依據。

                    KANO模型雖然并不是為互聯網產品發明,但卻是互聯網圈最網紅的方法論。簡單來講,KANO模型將產品的功能點對用戶進行問卷調研,通過正反兩問來獲取用戶的感知,類似于這樣:

                    正向提問:如果提交訂單后馬上提示開發票,你的感受是:

                    A.我很喜歡 B.理應如此 C.無所謂 D.勉強接受 E.我不喜歡

                    反向提問問:如果提交訂單后并不提示開發票,你的感受是:

                    A.我很喜歡 B.理應如此 C.無所謂 D.勉強接受 E.我不喜歡

                    接下來,對用戶的反饋進行統計,獲得不同答案結果的占比,并統計到下表。

                    KANO模型統計表


                    不提供此功能

                    我很喜歡

                    理應如此

                    無所謂

                    勉強接受

                    我不喜歡

                    我很喜歡

                    Q

                    A

                    A

                    A

                    O

                    理應如此

                    R

                    I

                    I

                    I

                    M

                    無所謂

                    R

                    I

                    I

                    I

                    M

                    勉強接受

                    R

                    I

                    I

                    I

                    M

                    我不喜歡

                    R

                    R

                    R

                    R

                    Q

                    拿到統計數據后,經過一系列計算,可以分析出功能點的屬性特征,具體有以下五種:

                    • A,魅力屬性:提供功能用戶會很喜歡,但不提供也無所謂;
                    • O,期望屬性:提供功能用戶很喜歡,不提供則不喜歡,用戶對功能有強烈期待;
                    • M,必備屬性:提供功能用戶覺得感受一般,但不提供則用戶強烈不喜歡,說明是必備功能;
                    • I,無差異屬性:不論是否提供功能,用戶感受都趨于平和;
                    • R,反向屬性:提供功能用戶不開心,不提供功能用戶反而開心;
                    • Q:可疑結果:結論邏輯相悖,屬于臟數據;

                    KANO模型的具體詳細說明,網絡上資料很多,本書不再贅述。此處需要強調的是,KANO模型并不完全適用于B端,因為B端背后面臨著多角色和多利益方,而不同利益方之間可能具有利益互反的特點。

                    例如,釘釘的已讀未讀功能,對老板來講,可能是期望屬性,而對員工來講,可能是反向屬性。

                    再例如,銷售型CRM的拜訪錄入功能,對老板來講,可能是必備屬性,而對一線銷售來講,可能是反向屬性。

                    因此,對KANO模型的使用,一定要明確場景,切勿盲目應用。

                    需求的驗證和評估

                    我們已經多次強調,作為一名產品經理,分析需求時一定要提前考慮好,上線后如何持續跟蹤,判斷功能是否達到了預期的業務效果。但是客觀的講,B端產品的功能,很多時候,難以量化收益,或者說很難衡量需求或項目的效果。因為B端產品最終要解決業務問題,而業務上的效果和效益,除了軟件產品本身的影響以外,往往還取決于業務政策,以及業務人員的能力和態度等多方面的因素。

                    舉個例子,針對給銷售人員使用的OCRM系統,做了若干需求預期提高銷售的轉化率,但實際上影響轉化率的因素太多了,客戶質量,傭金政策,銷售能力,都是影響因素,這些因素互相摻雜在一起,導致項目組很難衡量轉化率指標的變化,究竟有多少是因為產品功能影響改善的。

                    即便B端產品很多時候收益和效果難以量化,在我們的日常工作中,團隊管理和要求中,依然要保持數據評估工作的持續性和嚴謹性,思考項目收益如何衡量的過程,本身也是對需求和項目更深層次的分析論證的過程。如果你不能度量一件事情,那么你一定要謹慎思考到底該不該去做。

                    根據B端需求的三個層次具有天然的區別,我們可以針對三類需求分別思考如何衡量其收益。

                    通過拆解指標評估業務需求收益

                    評估業務需求的價值,可以先找到其對企業的價值大類(無外乎規模、成本、效率、品質、風險),然后盡量將價值大類的一級業務指標拆細,嘗試找到和業務需求最相關的二級指標或三級指標,作為評估度量的核心指標。

                    不論是規模、成本,還是效率、品質,在業務運作中,都可以首先找到對應的一級指標,例如:

                    • 針對銷售部門,規模的一級指標可能是“簽單交易額”;
                    • 針對客服部門,成本的一級指標可能是“每千人客戶的客服人力成本”;
                    • 針對配送部門,效率的一級指標可能是“配送及時率”;
                    • 針對采購部門,品質的一級指標可能是“采購質量合格率”;

                    各個業務線或業務單元,都會有核心一級指標作為北極星指標存在,指引業務的方向和目標。通過將一級指標層層拆解,盡量找到貼合需求價值的二級或三級指標。

                    例如,某在線教育的OCRM產品經理在設計實現了銷售打單輔助工具,在試聽課結束后生成小孩在試聽課中的精彩片段,由銷售人員發給家長,作為銷售打單工具。該產品功能,核心目標是提高轉化率,但是轉化率作為二級指標,顆粒度依然很粗,影響因素太多。此時,我們嘗試將轉化率漏斗進行層層拆解:

                    轉化率 = 試聽課邀約率 * 試聽課出席率 * 出席完課率 * 完課支付轉化率

                    此時,轉化率二級指標被拆解成了更細的四個三級指標。而上述案例中提到的產品功能,顯然目的不是提高試聽課約課率,也不是試聽課出席率,更不是出席完課率,而是在小孩上完試聽課之后,幫助銷售完成臨門一腳的拍單工作,顯然,該產品功能最能影響的三級指標,是完課支付轉化率。

                    因此,我們可以確定,針對該項目,考核指標選取完課支付轉化率,觀察項目上線前后指標的變化來評估項目收益。

                    但是,這個評估方法依然是不完美的,即使到了很細節的三級指標,在業務上的影響因素依然非常多,以完課支付率為例,該指標依然受到潛在客戶的質量,以及銷售個人能力的外部因素影響。為了更加客觀的分析,需要采用AB測試的辦法,選取兩批特征完全相同的銷售線索,一組作為實驗組,提供精彩視頻功能,一組作為對照組,不提供精彩視頻功能,從而觀察兩者在完課支付轉化率上的對比,來評估項目收益。

                    然而,B端功能很多時候難以采用AB測試,例如流程類的調整,上線就是全量,是沒有辦法新舊并存局部上線的。這可能正是B端產品業務收益難以衡量的一個致命問題,B端產品的AB測試以及小流量實驗,實施成本太高,甚至無法實施,這就導致很難準確的比對、測量項目收益。而我們只能盡量選取精準的相關的三級指標來嘗試衡量收益。

                    以上提到的逐層拆解指標來衡量項目收益的思路,實際上也是B端業務分析拆解的思路。在業務分析過程中,通過對數據指標的逐步拆解,發現問題,針對某個關鍵指標設計改進方案,落地實施。

                    通過NPS評估用戶需求收益

                    用戶需求來自終端用戶,可能包括業務訴求,但更多的是體驗優化。如果是業務類訴求,評估方式見上一節,如果是體驗優化類訴求,一方面可以衡量操作效率的提升,另一方面還可以通過凈推薦值NPS(Net Promoter Score)來考核用戶對功能優化的滿意度變化情況。

                    NPS由貝恩咨詢發明,本身是企業用來衡量消費者對產品和服務的忠誠度與口碑,在消費互聯網領域也有廣泛的應用,是一種非常容易使用的用戶忠誠度、滿意程度評估工具。

                    NPS的使用非常簡單,設置一道問卷題目,然后將選擇9、10分的百分比,減去選擇0到6分的百分比,就得到了NPS分數,如下圖。

                    NPS的使用和計算

                    不同領域、地區、企業規模的NPS均值并不相同;對產品功能調研NPS,得分的絕對值參考性有限,更好的使用方法,可以持續觀察NPS的變化趨勢。例如,可以針對產品的不同模塊定期調研NPS得分,判斷用戶體驗是否持續改善。

                    下圖是來自咨詢公司Retently的分析報告,展示了全球B2B業務不同領域的NPS得分情況(數據樣本來自于該公司的客戶資源庫),其中軟件行業的2022年NPS均值大概在40%,供大家參考。

                    Retently發布的2022全球B2B業務不同領域NPS平均分

                    通過綜合方案評估技術需求收益

                    技術需求又可以細分為四類,分別是基礎能力建設、中臺建設、純技術建設優化,這四類方向區別比較大,如何評估收益,需要分別探討。

                    對于基礎能力建設項目,考核交付質量和時間

                    B端產品,作為復雜系統,一整套體系的運轉,必須是多種類型的軟件功能組合而成,例如,要有基本的權限管理,消息提醒管理,數據字典配置管理等功能,當發展到一定階段,還需要流程引擎、報表引擎、表單引擎、視圖編輯器這些組件能力。

                    這類對業務沒有明顯價值和收益,但對于軟件系統又非常需要的功能,屬于基礎建設功能。對于此類項目,只需要正??己私桓顿|量、交付時間就可以,沒必要為了評估而非要生搬硬套某些業務價值,造成沒必要的麻煩。

                    對于中臺建設項目,考核系統接入量以及人力節約

                    中臺的目的是抽象建設可以復用的軟件系統或模塊,例如將各個業務系統都需要使用的消息中心、短信中心抽象成基礎服務,供多個系統使用。對于中臺產品或項目,我們可以考核其接入的客戶端數量,來衡量其被復用能力的強弱,以及推廣落地的結果。

                    此外,中臺產品很重要的一個目標,是所謂避免重復造輪子問題,那么則可以通過其接入的客戶端數量,來估算研發人力成本的節省。

                    通過考核中臺產品客戶端的接入數量,可以很好地倒逼中臺產品經理像一個推銷員一樣去推銷自己負責的中臺產品。因為多數情況下,大型企業的多部門產品線,并不在意甚至并不愿意主動接入中臺產品。雖然我們說中臺建設需要自上而下的意志,但是更多時候也需要自下而上的倒逼推進。

                    對于純技術項目,考核系統穩定性、安全性、時效性

                    對于純技術優化需求和項目,例如微服務化、代碼重構等,都是為了保證系統能夠運行的更加穩定、高效,架構更加合理,靈活性更強,可以考慮衡量系統的穩定性、安全性等非功能性指標。當然這些工作更多屬于技術團隊決策,產品經理了解即可。

                    終極衡量指標:考核使用人數

                    我們已經講了這么多評估的方法,但是很多時候,我們依然很難衡量某些B端產品功能對核心指標的影響程度,但兩者在邏輯上卻又有著明顯的相關性。

                    例如,某銷售人員使用的OCRM系統,產品經理對客戶詳情頁做了全面的升級,提供了豐富的視圖,可以讓銷售人員了解潛在客戶的所有重要信息,通過對其進行畫像標記,剖析其潛在需求和興趣點,幫助銷售人員更好的了解客戶,從而成功轉化。那么,如何衡量這套全新的“客戶詳情頁”的價值和收益呢?

                    再例如,某客服系統,上線了若干針對一線主管使用的報表,幫助其更好的監控、管理下屬團隊的服務過程和服務水平。那么,如何衡量這些報表對客服業務服務質量和服務水平的改善作用呢?

                    如果你不能明確你的產品對業務產生的收益是什么,那么至少你可以評估有沒有人使用這些功能。這是非常具備實操性的一種評估方法,如果你設計了新的功能,那么,保留老功能的入口,讓用戶用腳投票,看看到底哪一套更受歡迎。當然,有些新功能的推廣是需要培育的過程,讓用戶慢慢適應接受。但是,如果沒有明確的策略要求,完全可以讓新老功能并存,看看到底哪套功能做的好。如果上線的功能沒有人用,那么一定是哪里出了問題!

                    前邊提到的詳情頁以及報表的案例,都可以考核用戶使用的UV、PV,來衡量產品的價值,以及是否成功。

                    收益難以量化評估,是B端產品共同的難點。但作為B端產品經理,依然要盡最大努力評估、分析需求,否則就沒有繼續優化迭代決策的依據,也是對公司寶貴RD資源最大的浪費。

                    本節給出了不同類型產品需求的評估思路,只是供大家參考,希望給大家啟發;實際業務中情況要更加復雜,必須做出靈活調整和設計,而不要生搬硬套。

                    迭代中的研發資源管理

                    企業級軟件產品在技術上具有高度復雜性,研發人員不可能把所有精力都只投入在功能開發上,而應該分配一定的資源在技術優化和重構上。本節,我們來探討研發資源的有效利用,以及產品不同發展階段的技術資源投入問題。

                    研發資源的人力跟蹤

                    在迭代優化過程中,產品經理要充分調動并利用研發資源,通過對人員的合理調配,保障不同項目之間無縫銜接,避免因為時間窗口不匹配導致研發資源閑置。

                    如何準確管理研發人力呢?有一種很簡單實用的辦法,也是傳統項目管理中常用的辦法,即制作一張研發人力資源安排圖,通過這張圖可以清晰地看出每個研發人員在不同需求、項目上的時間投入規劃,并據此安排后續的工作。

                    在工作中,研發人員、產品經理、業務人員之間總會有這樣的爭執:為什么沒有排期?你們在做什么?人力都鋪在哪兒了?如果有這樣一張圖來清楚地呈現研發人員的工作安排,就可以避免這些爭執。因此,維護好這張研發人力資源安排圖,也是對研發人員的一種保護,避免他們“蒙受”工作不飽和的懷疑和指責。

                    研發人力資源安排圖

                    產品不同發展階段的技術資源投入

                    軟件的代碼需要不斷地優化。如果軟件升級迭代過程中只做產品功能需求,而不做技術優化,隨著功能的積累,軟件系統會變得越來越脆弱,運行速度會越來越慢,甚至頻繁宕機。因此,在日常的迭代升級中,必須給技術優化預留足夠的資源。

                    應該投入多少資源做技術優化?這個問題在產品經理和研發負責人之間似乎很難達成一致。研發負責人想多投入一些資源優化系統,而產品經理則認為應該首先解決業務需求。如何平衡業務需求和技術優化之間的資源分配問題呢?

                    從大的方面來說,這和系統所處的階段有很大關系,不同階段資源分配的思路完全不同。結合業務發展周期,我們將系統建設歸納為四個階段,分別是初創階段、瓶頸階段、重構階段、穩定階段。

                    初創階段

                    在初創階段,業務還處于探索試錯期,業務本身不一定能成功。在這個階段,系統從無到有地構建起來,研發團隊要開足馬力支持業務,本階段的重點在于“活下去”。構建的系統是一套全新的干凈系統,沒有任何歷史包袱,因此,可以鉚足勁兒開發業務功能,而不用太在意代碼、架構的合理性,此時可以只預留10%的資源做技術優化,甚至不做技術優化。只要研發團隊的水平靠得住,一套全新的系統在全力運轉的狀態下對業務支持一年的時間,應該是綽綽有余的,而一年正好是驗證業務是否能夠存活下去的關鍵時間點。

                    瓶頸階段

                    經過一年的探索,證明了方向是正確的,業務取得了初步成果,并繼續保持高速發展。業務對新功能的渴望持續且強勁,產品研發團隊依然開足馬力,但此時系統已經顯現出疲態,“技術債”問題出現:曾經的設計缺陷、硬編碼、架構不合理等問題逐漸凸顯出來,系統三天兩頭出問題,Bug繁出,穩定性差,與此同時,業務需求繼續井噴!

                    對于產品研發來說,一半的資源被修復Bug和迫在眉睫的技術優化占用,另一半資源被難以維護的老代碼拖住。產品研發團隊既不能痛快地滿足業務需求,也不能爽快地一次性解決系統結構問題。此階段可能會持續1年到1.5年的時間,可謂整個產品研發團隊的“噩夢時期”。

                    重構階段

                    業務繼續發展且相對穩定,業務需求依然絡繹不絕,但系統已瀕臨崩潰的邊緣。所有人都明白,償還技術債的終極時刻來臨了:公司層面決定,業務需求給技術重構讓路,留給研發團隊充足的時間重構系統,一次性解決歷史問題。此階段可能會安排80%的資源做技術優化重構工作,包括代碼解耦、拆庫拆表、中間件升級、接口化、服務化等。

                    對于瓶頸階段和重構階段分別持續多久、在什么時候發生,這個問題很難準確回答,取決于業務情況、系統狀況、技術團隊的話語權等因素。

                    此外,也有“邊開飛機邊換引擎”的成功案例,即在不影響業務的情況下,持續升級系統,開發新功能的同時完成系統重構,但難度相對較大。需要結合具體的系統架構和實際情況來判斷采取什么方案。

                    穩定階段

                    該階段業務發展穩定,系統運行平穩,Bug 少,不宕機。業務需求依然不停地提出,但此時研發工作顯得井井有條。即便如此,依然需要預留10%到20%的研發資源持續做技術優化,這是保證系統持續穩定的秘訣。

                    綜上所述,業務需求和技術優化的研發資源分配,要根據業務發展和系統建設的階段來合理安排。不同階段對兩者投入的資源比例可參考下表。

                    不同系統發展階段下技術優化資源投入比例建議

                    系統階段

                    時間周期

                    特點

                    業務需求資源占比

                    技術優化資源占比

                    初創

                    0~1年

                    系統從無到有構建,業務飛速運行、試錯

                    90%

                    10%

                    瓶頸

                    1~2.5年

                    業務繼續發展,系統問題不斷

                    50%

                    50%

                    重構

                    2.5~3年

                    業務逐漸穩定,系統問題嚴重

                    20%

                    80%

                    穩定

                    3年以上

                    業務持續穩定,系統穩定

                    80%

                    20%

                    商業化產品的發展階段

                    以上分析和節奏適用于企業自研系統、支撐業務快速開展試錯的情況;商業化軟件產品的節奏不太一樣,雖然商業化產品一開始也不能太復雜,而應該首先快速驗證市場,但相對于自研系統,對產品和技術架構的合理性、規范性要求更高一些,因為畢竟是企業的主營售賣產品,而非某個業務的輔助支持工具,所以一開始的設計、投入需要更嚴謹,更充分,因此商業化產品本身的瓶頸期和重構期的出現時間可能會更晚一些,但發展過程同樣也會經歷以上四個階段,在技術資源的投入分配上原則是類似的。

                    從產品的角度看“流”:認知重要性的三個問題
                    ? 上一篇 2022-08-15
                    為什么中國和美國在SaaS的差距越來越大?
                    下一篇 ? 2022-08-15
                    • 某網站SEO案例 網站無外鏈 僅半年時間日均IP近10萬 為什么?
                      0閱讀 0條評論 個贊
                      01、案例來源:這個案例來源于白楊流量匯一個會員提問哈,如下圖:我猜他應該想問為什么?我們就來看看這個網站哈?!?/div>
                    • 來自《隱入塵煙》的啟發:刷屏有方法
                      2閱讀 0條評論 個贊
                      讓我們先來看兩個關于分享行為的實驗,哈佛大學兩位神經科學家簡森米歇爾和黛安娜塔米,想研究和了解分享行為給人們帶來的正向反饋,曾做了下面兩個實驗:……
                    • 網站每天更新幾篇文章 一篇文章可以帶幾篇錨文本
                      1閱讀 0條評論 個贊
                      對于網站每天更新幾篇文章,搜索引擎沒有設定上限,也沒有設定下限,關鍵在于您能否保證文章質量。若能保證文章質量,更新的越多越好,若不能保證文章質量,更新多少都沒有意義?!?/div>
                    • 什么是餌料替換?什么是長尾關鍵詞庫?
                      1閱讀 0條評論 個贊
                      什么是誘餌替換(Bait and Switch)?誘餌替換會受到搜索引擎懲罰嗎?我通過:百度百科、搜狗百科、360百科、維基百科、了解了關于“誘餌替換”的相關內容。百度百科、搜狗百科、360百科的解讀近乎相同?!?/div>
                    • 2022 Tik Tok電子商務質量內容描述
                      0閱讀 0條評論 個贊
                      隨著抖音電商高速發展,電商創作者群體日益龐大,除專業從業人員外,也有興趣電商新人不斷涌入,平臺圍繞《電商內容核心創作理念》搭建《電商內容質量分級……
                    發表評論 共有條評論
                    用戶名: 密碼:
                    驗證碼: 匿名發表
                    • 網站內鏈優化有哪些細節?如何優化?
                      38閱讀 0條評論 個贊
                      都知道內鏈很重要,但是、卻不知道內鏈為什么重要,這是典型的“不看本質”行為。正是因為看不到內鏈的本質,才導致了內鏈的錯誤做法,究竟怎么做內鏈才能發揮其應有的作用呢?……
                    • 給運營負責人交個朋友:品牌的自播是殘酷的 不合適就會被淘汰
                      8閱讀 0條評論 個贊
                      啟動一項新業務并非一蹴而就的事情,需要找到對的人,在對的時機,做對的事情。作為一家抖音平臺的一家超級渠道,交個朋友的代運營業務在剛被提出時,并沒……
                    • 給自己制定一個SEO標準:做好本地SEO優化
                      23閱讀 0條評論 個贊
                      人的一些操作常常會隨著“心情”與“當前認知”的變化而變化。比如我、心情好的時候寫文章會認真一些,心情不好的時候寫文章會敷衍一些。有時間的時候就瘋狂更新 ,沒有時間的時候就不更新?!?/div>
                    • 如何解決企業網站更新問題?收錄的文章會有排名嗎?
                      0閱讀 0條評論 個贊
                      企業網站更新遭遇內容缺乏的問題一直是“SEO”的痛點,目前并沒有完美的解決方法,目前比較靠譜的方案是首先制定一個“文章更新計劃”,再根據實際情況進行內容拓展,填補一些與企業相關的內容?!?/div>
                    • 一個新網站如何快速優化排名?
                      0閱讀 0條評論 個贊
                      網站上線之后,需要面臨的問題不少,同樣的也要注意幾個工作流程,這樣才能讓新站更快參與排名,下面我們就來看看吧。新站在上線之后,需要大量的內容,如果前期只有一個人優化網站,那么每天都需要定時更新內容,確定每天的更新文章數量以及頻率,這樣蜘蛛能夠按照我們制定的更新時間來抓取,對于新站來說……
                    • 如何有效高效的做網絡營銷 掌握這種方法不做無用功
                      0閱讀 0條評論 個贊
                      俗話說:“酒香不怕巷子深!隨著信息時代的到來,網絡營銷已經成為企業推廣的重要營銷方式。越來越多的企業開始在網絡營銷上下功夫,幫助企業品牌更快更準……
                    • 全面剖析需求的挖掘與分析
                      0閱讀 0條評論 個贊
                      2獲得包括《需求挖掘分析pdf完整版》《需求文檔范例》《需求自檢表》《需求排期表》《需求分析ppt》等多份阿境獨家實用文檔?!?/div>
                    • 化妝品代理商如何進行網絡營銷?
                      0閱讀 0條評論 個贊
                      化妝品代理商如何進行網絡營銷?隨著美容市場競爭的加劇,化妝品代理商迫切需要有效的營銷手段來滿足發展需求,如今,互聯網已經成為最大的媒體平臺。大多……
                    • 我要去學谷歌SEO 谷歌翻譯的文章是原創文章嗎?
                      21閱讀 0條評論 個贊
                      今天剛剛入手了一款VPN,入手VPN的想法很簡單,就是為了研究谷歌google SEO,研究谷歌SEO有兩個目的。1、人總是需要進步的,積極學習才不會被淘汰出局?!?/div>
                    • 如何進行有效的網絡推廣?
                      32閱讀 0條評論 個贊
                      在當今的互聯網時代,人們的生活習慣已經被網絡所改變,比如網上購物,在這樣一個時代的背景下,企業也改變了自己的推廣方式,每個人都巧合地選擇了網絡營……
                    • 跑遍原產地 匯聚一堂 首屆DTANK聯合研究大會圓滿落幕
                      3閱讀 0條評論 個贊
                      優勢特色產業帶是區域經濟發展引擎之一。隨著各產地電商高速發展,抖音電商推出多項舉措,助力產業帶發展。作為抖音電商的生態參與者,產業帶服務商助力萬……
                    • 發射GMV增長超過5倍 齊飛共同演示了如何運行“熱”時 自我廣播“冷”開始
                      12閱讀 0條評論 個贊
                      以上圍繞著“冷啟動不順利”的問題,是諸多品牌在開始落地抖音電商相關運作時都可能遇到的情況,也是抖音電商DP服務商祈飛在合作NEIWAI內外時所面……
                    • 疫情期間你的現金流健康嗎?
                      0閱讀 0條評論 個贊
                      “VUCA”即 Volatile,Uncertain,Complex,Ambiguous。今年上半年加劇的疫情給很多企業踩了一個急剎車,企業的收……
                    • 原創內容和高質量的外部鏈接能幫助我們優化網站嗎?
                      0閱讀 0條評論 個贊
                      我們都知道百度在不斷的升級算法,查漏補缺,主要是為了防止采集和黑帽手法的滋生,導致搜索生態過于腐爛,影響到用戶的搜索體驗,從而流失大量的流量,那么我們在做SEO優化的時候……
                    • 什么是SEO優化?SEO的工作原理是什么?
                      1閱讀 0條評論 個贊
                      什么是SEO優化?……
                    • 領導力是帶領人們去他們從未去過的地方
                      14閱讀 0條評論 個贊
                      創業是一場沒有終點的修煉,基本功是否扎實直接關系著企業能走多遠。用1天時間全面闡釋了對于領導力的理解,更重點講授了領導力標準如何在企業落地,又如……
                    • 網站結構設計如何幫助SEO優化?
                      0閱讀 0條評論 個贊
                      SEO不僅需要我們做好網站優化,還要站在用戶的角度上面想問題,比如說我們如何讓網站的設計讓用戶更加滿意,停留時間更長,幫助我們網站能夠被蜘蛛喜歡,被用戶喜歡,這就涉及到了web前端開發的事情了……
                    • 將供應鏈轉變為“價值鏈”
                      3閱讀 0條評論 個贊
                      很多高管都意識到,企業是否具備“韌性”,重要的一點就在于是否構建了完善的供應鏈體系。埃森哲近期對全球九個行業900家公司的高管調研顯示,越來越多……
                    • 如何提高在線品牌推廣公司的營銷能力
                      4閱讀 0條評論 個贊
                      隨著互聯網的發展,企業可以在互聯網上尋求更多的發展機會,企業可以通過營銷網站逐步實現企業宣傳和產品銷售。企業云營出成功的營銷網站,需要提高網站的……
                    • 任最新演講:未來三年 以生存為最重要綱領
                      0閱讀 0條評論 個贊
                      8月22日下午,華為內部論壇上線了一篇關于《整個公司的經營方針要從追求規模轉向追求利潤和現金流》的文章。任正非在文內提到,全球消費能力下降的情況……
                    最近發布資訊
                    更多
                    被闺蜜的男朋友cao到跪地求饶