實戰(zhàn)經(jīng)驗|我在做后端產(chǎn)品中收獲的4條經(jīng)驗(續(xù))

7 評論 8130 瀏覽 47 收藏 9 分鐘

之前寫過一篇文章講《實戰(zhàn)經(jīng)驗|我在做后端產(chǎn)品中收獲的5條經(jīng)驗》,如果你沒看過這篇文章,閱讀本文前,建議先讀一下這篇文章。這篇文章接著這個話題,繼續(xù)分享我在做后端產(chǎn)品中收獲的經(jīng)驗,這次主要講四點。

1.邏輯上的合理性

在產(chǎn)品設(shè)計上要注重邏輯的合理性,我曾經(jīng)做過一個產(chǎn)品,有個功能是分類篩選,我們根據(jù)內(nèi)容類型把不同的內(nèi)容進行歸類,運營人員可以根據(jù)不同的分類篩選內(nèi)容,也只能分類查看。這樣一來在后續(xù)的運營過程中運營人員無法統(tǒng)籌查看全部的內(nèi)容,如果想看一下最近更新的內(nèi)容或者內(nèi)容總數(shù),只能各個分類查看后才知道,很麻煩,還挺考驗人的記憶力的。

再舉一個例子,我曾經(jīng)看過一個產(chǎn)品有個業(yè)務(wù)邏輯,兩個管理模塊A和B,A模塊是B模塊的內(nèi)容源且有信息的第一管理權(quán)。A模塊的信息被下架后,B模塊也同時下架,但是后臺使用者卻可以手動把B模塊的信息再上架。這樣就不合理了,內(nèi)容源中已經(jīng)沒有該信息了,但是B模塊卻依然顯示著。兩者有時關(guān)聯(lián),有時不關(guān)聯(lián)。

其實從技術(shù)上來講,怎么做都可以,完成由人定義。但是如果邏輯上不合理的話,不僅開發(fā)過程中難以溝通,而且運營人員在使用過程中也會覺得很亂。

我之前講后端產(chǎn)品受使用者干預(yù)性比較大,因為本身就是供他們使用的,所以我們在設(shè)計功能的時候也會收集運營人員的需求。在這個過程中有時候運營人員的需求是合理的,有必要的,但有時候也不合理,純屬那種拍腦門的決定。

這種拍腦門的后果就是對需求的定義隨心所欲,造成的結(jié)果是功能很多,加大了開發(fā)量,某些比較小的功能即便運營人員讓加了,但實際過程中基本不會使用。所以在這個過程中,產(chǎn)品經(jīng)理就要控制運營人員的欲望。

邏輯上的合理性,也可以成為產(chǎn)品經(jīng)理評判某個需求的標準。

2.保持靈活性

之所以要做到靈活性,主要原因有兩個,一個是對于運營需求的滿足,另一個是某些功能需求的不確定性。

先說第一點,我原來做個功能當時我們想把游戲官網(wǎng)的設(shè)計模塊化,這樣可以提高游戲官網(wǎng)上線的速度。雖然從功能的角度來講可以這么做,但是從設(shè)計的角度來講并不合適,出于營銷的目的官網(wǎng)還需要展現(xiàn)游戲的個性化。所以當時我們做了樣式替換的功能,運營人員如果不想使用模板,可以依靠替換CSS文件來做到官網(wǎng)的個性化。

有些功能的需求是不確定的。比如說一個電臺節(jié)目的簡介最大字數(shù)該限制多少,說實話有時候我也不知道,運營人員也說不準。如果一旦限制的字符比較短,那在以后的使用中發(fā)現(xiàn)不夠用,還得修改。要不就設(shè)置的非常長,比如說十萬字,我們能夠預(yù)想到肯定夠用了。但這樣就沒太大意義。這種時候我覺得可以不做限制,完全由人為定義就好。

做技術(shù)的人流行一種說法,不要寫死。保持靈活性,也是為了避免某些地方寫死而給自己造成一些麻煩。

給大家一個建議,因為大家的上班時間是固定的,周一到周五每天八個小時,某些功能如定時器很大程度上是為了讓方便大家在非工作時間管理內(nèi)容。判定某個功能如果完全可以在工作時間控制,而且即便發(fā)生錯誤影響也不大,那么就可以考慮保持其靈活性。

3.不追求完美

產(chǎn)品經(jīng)理都會追求好的用戶體驗,用戶體驗的優(yōu)秀很大程度上體驗在細節(jié)上,可要知道在追求用戶體驗這條路上是沒有盡頭的。其實不僅是前端產(chǎn)品,做后端產(chǎn)品也要控制自己的欲望。如果對細節(jié)要求的太多,磨的太細,恐怕你的產(chǎn)品就永遠不要上線了。

我曾經(jīng)就經(jīng)歷過這種情況,部門中的一個項目,開發(fā)測試完成,由于服務(wù)器的原因耽誤了上線時間。在這個過程中產(chǎn)品經(jīng)理就在逐漸優(yōu)化細節(jié),按理說也沒問題,但是技術(shù)人員對代碼的每次改動都意味著增加了一次風險,說不定會引起別的問題。

除了用戶體驗外,功能也是如此。有些需求其實運營人員也沒有考慮清楚,即便是提出來了,也是一時興起,缺乏說服力。如果是這樣,在滿足基礎(chǔ)需求的前提下,我們不妨暫且把新功能放一放。等最終考慮清楚了再開發(fā),免得做無用功。

相比較前端產(chǎn)品,特別是APP,后端產(chǎn)品有個優(yōu)勢就是技術(shù)上的改動隨時可以生效。而不需要用戶更新版本,這對產(chǎn)品經(jīng)理來說是好事,如果出錯了補救的成本小一些。

4.產(chǎn)品功能的優(yōu)劣會受數(shù)據(jù)規(guī)模影響

拿我之前做過一個排序功能來說,如果想調(diào)整某個內(nèi)容的順序,可以手動輸入序號,序號越大排序越靠前。雖然這樣能滿足需求,但是隨著使用的時間久了,積累的數(shù)據(jù)越來越多,出現(xiàn)了一個問題。運營人員在使用過程中并不規(guī)范,他們輸入的序號數(shù)值很隨意,往往會把新增加的信息序號數(shù)值設(shè)置的很大。一共90條數(shù)據(jù),但序號數(shù)值可能已經(jīng)到了200。序號并沒有連著,時間長了列表中的序號就會非常亂。

所以說功能設(shè)計的好壞也跟數(shù)據(jù)的規(guī)模有關(guān),有些功能在數(shù)據(jù)少的情況下使用沒問題,但是隨著數(shù)據(jù)量增大就會暴露出功能設(shè)計上的缺陷。

結(jié)語

之前行業(yè)內(nèi)有一種議論說,有些產(chǎn)品經(jīng)理非常不愿意做后端產(chǎn)品,我在工作經(jīng)歷也發(fā)現(xiàn),確實存在這種現(xiàn)象,有的產(chǎn)品經(jīng)理在接后臺產(chǎn)品時就是抱著一種應(yīng)付的態(tài)度。

有時候你會發(fā)現(xiàn),在產(chǎn)品設(shè)計上雖然我們把功能都給完善了,在原型設(shè)計階段不覺得有問題,但是等到產(chǎn)品上線后自己體驗后卻發(fā)現(xiàn)體驗很差。后臺產(chǎn)品也是要經(jīng)過版本迭代的,如果體驗太差的話那新版本迭代的速度就要快一些了。

#專欄作家#

云瑞,微信公眾號:馬虎眼,人人都是產(chǎn)品經(jīng)理專欄作家。片刻產(chǎn)品經(jīng)理,五年產(chǎn)品人,走在內(nèi)容社交產(chǎn)品路上,死磕產(chǎn)品設(shè)計,喜歡玩各種APP,玩桌球,打羽毛球,歡迎與大家交流。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 后端產(chǎn)品還需要盡可能的實現(xiàn)模塊化,像我們公司的系統(tǒng)沒有很清晰的邊界。會導(dǎo)致系統(tǒng)之間的耦合性很高。逐漸會拖慢后續(xù)迭代的速度

    來自廣東 回復(fù)
  2. 感觸很深,后臺開發(fā)的過程中對體驗做了很多妥協(xié),在原型上做了的細節(jié)也因為進度問題暫緩

    來自四川 回復(fù)
  3. 有同感

    來自北京 回復(fù)
  4. 深有感觸

    來自廣東 回復(fù)
  5. 后臺產(chǎn)品開發(fā)最大的麻煩就是跟運營人員的溝通,不確定性太高,需要不斷的修改原型,然后不斷的討論進行討論到他們想要的東西;
    在考慮交互體驗還得考慮開發(fā)的難易程度。

    來自山東 回復(fù)
    1. 同感,我們這簡直就是運營一言堂!

      回復(fù)
  6. 自己的思考,挺好的,支持下,多做記錄總結(jié),總是好的 :mrgreen:

    來自廣東 回復(fù)