<menu id="ycqsw"></menu><nav id="ycqsw"><code id="ycqsw"></code></nav>
<dd id="ycqsw"><menu id="ycqsw"></menu></dd>
  • <nav id="ycqsw"></nav>
    <menu id="ycqsw"><strong id="ycqsw"></strong></menu>
    <xmp id="ycqsw"><nav id="ycqsw"></nav>
  • 什么叫產品思維,產品思維的定義


    無論你是公司管理層還是用戶層,從這篇文章,你都可以簡單了解到:什么叫產品思維?以及自查:我們是否在同一思考維度。本文分為3個章節:第一部分會根據實例來演示下什么是產品思維;第二部分簡述我的產品思維;第三部分則根據我們日常碰到的常規問題的一些建議,enjoy!

    你是產品,那你有產品思維嗎?

    我是產品,我為產品打call,我有產品、設計、看問題、找問題的思維。

    一、產品思維實例推演

    1. 背景

    公司研發了一款軟件,讓你去用用看,順便提提意見。

    然后,你就問:這個軟件干嘛的,想達到什么目的。

    公司告訴你:這個是一個門戶,想解決我們公司多個系統多個賬號的問題、實現統一管理、消息代辦的統一管理。

    OK,了解后,我們就開始體驗門戶,我們從以下幾個主要點來分析:你是否有產品思維?

    2. 初體驗,單點認證及門戶與子系統之間的交互

    1. 輸入賬號、密碼,登錄后,門戶首頁赫然出現了系統A、B、C個系統的應用;
    2. 點擊鏈接進入系統A,頁面只展示了系統A的空白首頁,沒有其他菜單;
    3. 從系統A注銷登錄,發現頁面定位到了門戶的登錄頁,而且門戶首頁的登錄也失效了。

    看到上面的3個步驟,你會提出什么疑問,以及你會用何種方式來進一步驗證探討你的猜想?

    以下是我的疑問和進一步的操作:

    為啥只有系統A、B、C 3個應用,剩下的D、E呢?是什么控制對我們的可見性不同?(已經確定A、B、C、D、E 5個系統已經全部集成完成。)

    ——進一步去看了A、B、C 3個應用是公共應用,D、E是非公共應用,驗證了是應用的類型控制可見權限。

    為何單點到系統A,跟我之前登錄到系統A看到的菜單和內容不一樣呢?門戶與各系統之間的認證、角色權限如何界定和管理的?

    ——與研發人員核實,是需要系統A根據門戶的賬號分發接口獲取哪些人具有系統使用權限,然后在系統A中給對應人員分配權限。

    基于以上回答,你是否會提出疑問:等于一個用戶對系統的角色權限需要門戶和系統來配合完成,那這樣是否達到了賬號、權限、角色同一管理的目的?

    為何從系統A注銷頁面會定位到了門戶的登錄頁,系統A的登錄屏蔽了、系統A的賬號密碼還可以用嗎?任何一個系統注銷為何會導致全部登錄都實效?

    ——與研發人員核實所有系統采用信任的機制,即其中任何一個系統注銷,所有系統均注銷;所有系統不保留單獨登錄頁面,均使用門戶登錄賬號密碼登錄;

    基于以上信息,你是否會提出疑問:采用信任機制,每個系統都需要時刻對登出信息進行獲取——是否會占用資源導致系統運行速度減慢?以及,這種信任機制是否合適?

    我們要改變用戶的習慣,使他們在系統操作完后是關閉頁面而不是登出;還有,所有的登錄統一定位到門戶,如果門戶出現異常,是不是我們所有的業務都要停止?

    3. 與其他門戶進行對比

    在了解公司門戶后,可以看看其他公司或者業界評價比較好的門戶產品是怎么做的。再對比下,你應該就會對門戶有個比較深入的概念,以及公司目前所做的門戶是否是真正意義上的門戶。

    二、什么是產品思維

    有以下定義:

    • 就是透過現象看本質——可以通過頁面信息架構分析出實體關系以及數據庫表結構的設計;可以根據功能設計看出他們之間的關聯以及交互邏輯;
    • 能基于現有模塊去構建、梳理新的功能需求,并提供解決方案;
    • 能以閉環為前提,去思考產品流程的合理性及存在的問題;
    • 擅長場景設計,并有一套可視化分析模型;
    • 善于從反向/分支流程逆向看問題,分析系統健壯性;
    • 能從用戶的訪談/調研中獲取關鍵線索并能敏銳的察覺用戶需求與系統的差異性。

    三、日常用到的,你所不知道的產品思維

    1. 考慮功能的可擴展性(這個很重要哦)

    對于有權限設置的功能來說,首先考慮的是其可擴展性——即在不需要動代碼的前提下就可以達到權限的配置和功能的使用。

    example:

    背景:門戶上的每個可見內容都是以區塊的形式呈現,區塊分為公共應用和非公共應用,公共應用即無需配置,大家都可見,非公共應用即需要對用戶授予權限方可見。

    需求:現在需要開發一個待閱通知管理功能,只有企劃部、人事部才可以去發布待閱通知。

    問題:基于此需求,你覺得這個待閱通知管理功能的權限應該如何設置?

    有興趣的同學可單獨私我,共同討論。

    2. 對于用戶要求比較復雜的功能,建議分次迭代

    一期先精簡基礎邏輯線,涵蓋基礎功能,保證能基本用的起來;二期,針對附加控制、權限邏輯疊加的限制性需求。

    這樣分次迭代的好處是:一方面是給需求提出方足夠的時候思考自己需求的合理性,believe me ,他們會隨時更改需求的;另一方面是時間的有效利用,防止功能太復雜,驗證和開發時間上都比較長,操成周期比較長。

    3. 接受不合理需求的產品都是懷著“你不懂我”的心思來做的

    你想知道怎么拒絕不合理需求嗎,特別是領導提的不合理需求,有2個好辦法,睜大眼睛好好看哦。

    1. 丟出去,丟給別人,免得看見心煩,至于怎么丟,這就看局勢和情商了(此處好想大笑)。
    2. 丟不出去的時候,就認命吧,按照領導的意思來,但心里一定要默念“我們不一樣,我們不一樣,我們不一樣”,這樣你會舒服點。

    這點純屬吐槽,因為我們相信,說出來也許會舒服點,不過確實很舒暢。

    OK,本文先到這里吧,有機會再來。

    版權聲明:本文內容由互聯網用戶自發貢獻,該文觀點僅代表作者本人。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容, 請發送郵件至 舉報,一經查實,本站將立刻刪除。

    發表評論

    登錄后才能評論
    国产精品区一区二区免费