實戰經驗｜我在做後台產品中收穫的9條經驗

作者：雲瑞

全文共 4241 字，閱讀需要 7 分鐘

€€€€ BEGIN €€€€

後台產品也分很多種，從使用者的角度分：公司內部人員使用的運營管理系統，面向合作夥伴的CRM系統，還有的公司就是專門銷售管理系統的，典型的如OA。

我在這裡講的只是面向公司內部人員使用的系統。

在做後端產品的過程中我更加理解了產品理念的重要性，很多事如果我們的理念相同，會極大的降低溝通成本，溝通的雙方會很快達成共識。

在產品設計時，我們會給不同的功能定義不同的名詞。有些名詞已經非常通用，大家一說都明白，例如刪除、添加；但由於各個公司的運營需求不同，對功能要求也可能不一樣。即便都叫運營管理系統，但也需要針對公司自身的情況開發一些定製功能。

名詞的定義除了關係到使用者的理解之外，也會關係到跟技術人員的溝通。要不然就會出現大家心中想的是一個事情，但是語言用詞上不一致；造成一些誤會不說，可能還需要每次溝通前都得把名詞強調一遍。所以產品經理在開發前就應該跟技術人員先把名詞定義好。

有些功能可能一時想不到適合的辭彙也沒關係，只要大家在內部對名詞的理解統一即可。

先說一下產品背景，拿CMS產品來說，主要是用來供公司運營人員使用的，用來發布並管理內容。這類產品有個很重要的原則是：一定要快，節省使用者的工作效率。

其實不光CMS，很多系統也都會堅持這個原則，例如超市的收銀系統，即使結一單隻提升幾秒，一天下來可能就會節省幾十分鐘。

我見過有的產品經理會因為一個電腦頁面顯示不完，為了樣式的好看而隱藏一些用戶所關心的信息。這樣在操作的時候大家還得去點擊詳情查看，需要二次操作。

不要因為樣式上的美觀而降低效率。後台系統中肯定會有很多列表，不同的列表會顯示不同的信息。如果一個列表中運營人員所關心的信息太多，那麼全部顯示出來即可。所以在界面設計上也要盡量利用空間，這個思路跟手機界面的留白就不一樣了。

為了節省效率還有一個很重要的原則：優先顯示運營人員關注的信息。例如信息審核系統，對於運營人員而言，他們最在乎的是待審核的信息（提交的用戶還在等著呢)。所以應該優先顯示這類信息，這是急切需要運營人員操作的；而審核通過和審核失敗的，可能只是在需要時才會查詢一下。

舉個例子：為了效率提升，產品設計的改變。在信息操作的時候，我們可以將操作目的直接做成按鈕，而不需要使用單選按鈕再點擊提交操作。

從某種程度上說這一點跟第二點是相矛盾的。如果你在用戶進行某項操作時還需要他進行確認操作，這個過程勢必不會那麼順暢。

但確認操作又是必須的。之所以需要確認操作主要是為了降低運營人員因為誤操作而帶來的損失（當然這並不能保證萬無一失，只是降低出錯的風險）。

產品經理在設定某個功能需要確認操作時也要考慮清楚，什麼樣的功能該有確認操作，什麼樣的功能不需要。要是所有的功能都需要確認操作，那真的就沒效率可言了。

判定的標準就是看能功能產生的影響。

之前媒體有報道過惠普和噹噹網有標錯價格的情況，把幾千塊錢的商品標註成了幾塊錢，面臨的是經濟損失。這應該是誤操作帶來的最嚴重的影響了。

對運營系統而言，更多的情況是給頁面顯示帶來一些錯誤。例如把本來不該顯示的信息提前上架了。還有可能是誤刪除了信息，這時候就要自己重新添加了。

如果某些信息操作后的效果並不嚴重且有補救措施，那就可以沒有確認操作。

該不該用技術的方式控制人性？這也是一個挺糾結的問題。

還是拿我上面舉的確認操作的例子來說：

有的人會覺得其實這個是使用者自己的行為，他們在操作前本身應該看清楚，何況後台系統都有操作日誌，如果誰犯錯了，看下操作日誌找到當事人，給予相應的懲罰。

這樣也會提醒別人，大家以後誤操作的幾率也會降低。這個觀點也會成為我們砍掉某些功能的理由。

這種話我多半以為都是氣話。且不說在工作中實際操作性有多大，即便可以對員工罰款，但是事件對外界造成的影響呢？即便有人負責也晚了，所以還是要提前避免。

對於信息的管理，只要是人控制的就充滿了太多不確定性。通過在技術上加以限制還是有必要的。但也要有度，有些限制做不好會適得其反。

講一個案例：

一家公司的信息審核系統，運營人員在審核信息時，系統設定了60秒的時間，不管運營人員有沒有看完信息，審核通過的按鈕只有在60秒后才能點擊。

本意是希望讓運營人員必須查看后才審核，防止他們辦事馬虎。但實際過程中卻發現這種做法降低了運營人員的效率，因為他們看完一條信息不需要60秒。

有的人可能會說那就設為30秒，由於經驗不同，運營人員的審核效率不同。而且出於信任有的用戶的信息運營人員的審核也會鬆懈很多，時間設置太短也沒有意義。後來就乾脆把這功能撤下了。

在設計後台系統時，除了從使用者的角度去考慮外，也要為技術人員的實現方式和開發成本考慮一下。不要因為無所謂的功能，而給技術人員增加工作量，很多時候只要達到目的即可。

曾經做過一個上下架功能，需要用到一個日曆插件，選擇時間，當時產品經理非得讓技術人員把日曆上的已過去的時間置灰。

日曆插件主要是用於選擇上下架時間，而已過期時間是否置灰對於這個功能都不會有影響。當然如果做了，用戶體驗會更好。但有些後台產品畢竟只是公司內部使用，只要目的達到了即可，沒必要讓技術人員去做一些錦上添花的功能。

積少成多，單個功能簡單，時間短。但做多了，成本也就不低了。

在產品設計上要注重邏輯的合理性。

我曾經做過一個產品，有個功能是分類篩選，我們根據內容類型把不同的內容進行歸類，運營人員可以根據不同的分類篩選內容，也只能分類查看。

這樣一來在後續的運營過程中，運營人員無法統籌查看全部的內容。如果想看一下最近更新的內容或者內容總數，只能各個分類查看后才知道，很麻煩，還挺考驗人的記憶力的。

再舉一個例子：

我曾經看過一個產品有個業務邏輯，兩個管理模塊A和B，A模塊是B模塊的內容源且有信息的第一管理權。

A模塊的信息被下架后，B模塊也同時下架，但是後台使用者卻可以手動把B模塊的信息再上架。這樣就不合理了，內容源中已經沒有該信息了，但是B模塊卻依然顯示著。兩者有時關聯，有時不關聯。

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

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

這種拍腦門的後果就是對需求的定義隨心所欲，造成的結果是功能很多，加大了開發量，某些比較小的功能即便運營人員讓加了，但實際過程中基本不會使用。所以在這個過程中，產品經理就要控制運營人員的慾望。

邏輯上的合理性，也可以成為產品經理評判某個需求的標準。

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

先說第一點：

我原來做個功能當時我們想把遊戲官網的設計模塊化，這樣可以提高遊戲官網上線的速度。

雖然從功能的角度來講可以這麼做，但是從設計的角度來講並不合適，出於營銷的目的，官網還需要展現遊戲的個性化。所以當時我們做了樣式替換的功能，運營人員如果不想使用模板，可以依靠替換CSS文件來做到官網的個性化。

有些功能的需求是不確定的。

比如說一個電台節目的簡介最大字數該限制多少，說實話有時候我也不知道，運營人員也說不準。

如果一旦限制的字元比較短，那在以後的使用中發現不夠用，還得修改。

要不就設置的非常長，比如說十萬字，我們能夠預想到肯定夠用了。但這樣就沒太大意義。

這種時候我覺得可以不做限制，完全由人為定義就好。

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

給大家一個建議：因為大家的上班時間是固定的，周一到周五每天八個小時，某些功能如定時器很大程度上是為了讓方便大家在非工作時間管理內容。

判定某個功能如果完全可以在工作時間控制，而且即便發生錯誤影響也不大，那麼就可以考慮保持其靈活性。

8.不追求完美

產品經理都會追求好的用戶體驗，用戶體驗的優秀很大程度上體驗在細節上，可要知道在追求用戶體驗這條路上是沒有盡頭的。

其實不僅是前端產品，做後端產品也要控制自己的慾望。如果對細節要求的太多，磨的太細，恐怕你的產品就永遠不要上線了。

我曾經就經歷過這種情況，部門中的一個項目，開發測試完成，由於伺服器的原因耽誤了上線時間。在這個過程中產品經理就在逐漸優化細節，按理說也沒問題，但是技術人員對代碼的每次改動都意味著增加了一次風險，說不定會引起別的問題。

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

相比較前端產品，特別是APP，後端產品有個優勢就是技術上的改動隨時可以生效。而不需要用戶更新版本，這對產品經理來說是好事，如果出錯了補救的成本小一些。

拿我之前做過一個排序功能來說，如果想調整某個內容的順序，可以手動輸入序號，序號越大排序越靠前。

雖然這樣能滿足需求，但是隨著使用的時間久了，積累的數據越來越多，出現了一個問題：

運營人員在使用過程中並不規範，他們輸入的序號數值很隨意，往往會把新增加的信息序號數值設置的很大。

一共90條數據，但序號數值可能已經到了200。序號並沒有連著，時間長了列表中的序號就會非常亂。

所以說功能設計的好壞也跟數據的規模有關，有些功能在數據少的情況下使用沒問題，但是隨著數據量增大就會暴露出功能設計上的缺陷。

之前行業內有一種議論說，有些產品經理非常不願意做後端產品，我在工作經歷也發現，確實存在這種現象，有的產品經理在接後台產品時就是抱著一種應付的態度。

有時候你會發現，在產品設計上雖然我們把功能都給完善了，在原型設計階段不覺得有問題，但是等到產品上線后自己體驗后卻發現體驗很差。

後台產品也是要經過版本迭代的，如果體驗太差的話那新版本迭代的速度就要快一些了。

還有很多人討論說產品經理要不要懂技術，像這種問題都沒有標準答案，每個人都有自己的看法。

我覺得最好還是要懂的，當然不需要深入的了解，只要懂一些技術原理就可以了。

在跟技術溝通的過程中，如果是前台產品我們的說服理由中還可以有終端特性和交互上的炫酷。但做後端產品，業務上的邏輯就更加重要了。

€€€€ END €€€€

恭喜用戶@ 獲得 吳軍 博士的《矽谷之謎》一本！請將收件信息發送到公眾號後台，我們將會在五個工作日內安排寄出哦~

產品汪、運營喵、射雞濕，想加入靠譜的優秀團隊，我們幫你免費內推好工作！