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

B端的需求和C端有比較大的差異：C端的用戶畫像，在B端更多是以角色、權力和義務的劃分。在這種情況下，我們的需求處理方式也會有所不同。

交互設計其實就是用戶的行為設計，既然是圍繞用戶的行為，那么我們首先得清楚我們的用戶是誰。

《俞軍產品方法論》里提到“用戶不是自然人，而是需求的集合”

不同于我們常見的C端產品，在B端中，用戶主要是職場人，而不是基于性別、年齡或喜好等個人特質來劃分。相反他們以角色、權利和義務來區分。因此用戶需求分析更側重于角色需求，而不是個人特征。舉例來說一位財務經理在審批報銷單時，無論其性別或興趣如何，他們只關心有效管理財務流程。

如果企業有眾多的職能和職位，他們都是我們接下來新產品的需求對象，我們該如何搞懂需求？

接下來我將從需求背后的角色分類，以及如何從中提取需求這兩部分展開，一起來看看吧~

01 搞清楚角色是誰

B端產品服務所面向的角色多種多樣，不是單一的一個人，通常包括決策者、管理者和執行者三個不同維度。這些角色在使用產品時具有各自不同的需求和關注點。我們需要在全局的角度去精準定位以及抽取不同角色的需求。

1.1 決策者

決策者通常是企業的高層管理人員，他們對產品的采購決策至關重要，這可能是公司的CEO、董事會成員，或者是科研院所的院士、教授等。盡管決策者很少甚至完全不使用產品，但他們的關注點在于產品能否為企業帶來實際價值，解決現實問題，從而實現企業的利益最大化。

與C端產品不同，B端產品的設計必須以滿足決策者的需求為首要目標。這意味著我們需要重點關注產品能否在降低成本、提升效率、增加收入等方面給企業帶來直接的經濟效益。因此在產品設計過程中，我們需要將解決企業問題作為優先考慮的核心，而不是僅僅追求用戶體驗的完美。

在與決策者溝通產品需求時，我們不應過分強調產品的美觀或交互體驗，而是應該更專注于產品的商業價值和實際效果。因此我們的目標是確保產品能夠在解決企業問題和實現商業目標方面取得最佳效果，以此來贏得決策者的信任和支持。

1.2 管理者

B端類型的產品除了一線的執行者外還有一個重要的角色——管理者。他們通常負責業務的管理與監督，屬于次要的執行者或者間接的執行者。他們一般是是公司的中高層人員，產品是否被公司所接納，還在于管理者是否買賬。他們的需求也要放在優先級相對較高的位置。

管理者的需求是對公司總目標的分解。不同級別的管理者關注的業務需求也不一致。中層管理者側重過程數據，高層管理者側重結果數據。他們的期望通常比較具體，能簡單快速的找到自己的任務并順利的完成就好。因此在需求整理階段要特別關注他們的訴求。

1.3 執行者

執行者是產品最頻繁的使用者，類似C端「用戶」的概念。他們格外關注產品的易用性，希望產品界面簡潔明了，功能易于操作，能夠快速上手，以提高工作效率。

執行者對產品的操作會直接影響到管理者對數據的分析和決策，進而影響其監督和評估團隊的工作情況。因此執行者對產品的反饋可能影響管理者對產品的印象。若我們希望客戶持續選擇我們的產品，我們就必須確保在NPS（凈推薦值）上能夠滿足執行者的需求。

02 需求提煉的標準是什么

需求提煉就是搜集和梳理需求的過程，這期間我們經常會遇到各方不同的觀點。在這種情況下，如何在眾說紛紜的環境中做出權衡是一個困擾我們許久的問題。接下來我希望分享一些我的想法，或許能給同學一些啟發。

2.1 觸達量

當涉及到需求爭議時，我們需要牢記B端產品多人協作與集體訴求優先的原則。因為B端產品是為了服務整個組織或團隊，而不是個人。因此在處理時，我們傾向于優先考慮應用更廣的集體需求。在白盒SONiC項目中，我們曾遇到過這樣的情況：在設計網絡拓撲結構時，部分團隊成員主張采用一種復雜的結構，而另一些則傾向于簡化設計。在這種情況下，我們更傾向于采納能夠滿足大多數人需求的簡化設計方案，因為這能夠提高產品的整體適用性和易用性。

在同一個用戶群體內，不同的用戶通常有著相似的工作環境和職能角色。這意味著他們對產品的期望和需求往往是趨同的。舉個例子，對于白盒SONiC產品的網絡管理員而言，他們更關注產品的穩定性和性能優化，而不太在意個性化的用戶界面。因此在產品設計中，我們會更加注重滿足整體用戶群體的共性需求，而不是過分迎合個別用戶的特殊偏好。

此外在需要多人協作完成的場景中，我們會更加傾向于考慮人數較多的需求。例如在白盒SONiC產品的開發過程中，我們面臨著需要多個團隊同時協作的情況，如網絡架構師、開發工程師和運維團隊等。因此我們會優先考慮那些能夠促進團隊協作、降低操作沖突和數據錯亂的功能需求，以提高整體工作效率和協作質量。

2.2 優先級

敏捷開發作為目前主流的開發模式，以快速迭代、小步快跑為特點，在較短的開發周期內提交軟件，強調在每個迭代周期結束時逐步交付需求。

在處理魚龍混雜的需求時，我們需要有效評估它們的優先級。需求管理實質上也是優先級管理，需要合理安排有限的時間和資源。因此我們可以采用“四象限法則”來劃分需求處理順序的評估標準。

首先，重要且緊急的需求通常涉及產品的核心功能或主要流程，應當列為研發周期的最高優先級，重點跟進。

其次，緊急但不重要的需求通常是臨時性的，對整體產品的后續迭代影響有限，可以暫時放置，考慮在二期規劃中實現。

重要但不緊急的需求往往具有長期收益性，可以作為緊急需求之后的次優先級。

最后，不重要也不緊急的需求優先級較低，可以考慮不予實現，以節省資源集中精力應對更緊急、更重要的事務。

2.3 權重值

提煉需求的最終目標是為了更好地解決業務問題，實現商業目標。

在B端產品中，由于各產品干系人擁有不同的權力和付費能力，他們對需求的重視程度也不盡相同。一般來說，決策者＞管理者＞執行者的順序決定了需求的優先級。因此權力和付費能力較高的決策層和管理層的需求通常會被優先考慮和滿足。

因此我們在提取B端需求時，可以采用一個重要性公式來量化需求的重要程度：

重要性=觸達量×優先級×權重值

03 寫在最后

在實際的B端需求溝通中，各部門常常為了謀求自身利益而激烈地爭論各自需求的優先級，追求局部效益的最大化。這種情況下，不同部門間往往會出現激烈的辯論，每個人都試圖爭取自己需求的優先權。

面對來自多方渠道的需求輸入，建立一套公開、透明、可靠的需求評估機制尤為重要。采用類似于”需求重要性公式”的機制可以有效協調各方對于需求優先級和上線時間的期望，從而避免對產品部門產生抱怨和不配合的情緒。通過明確的評估標準和流程，可以確保所有利益相關者都能參與到需求決策的過程中，并最終達成共識。

以上只是我針對公司角色類型以及需求評估內容的個人感悟，希望該文章對你有所啟發，也歡迎感興趣的同學一起探討~