后臺產品經理,需要重視這4個能力

43 評論 47278 瀏覽 465 收藏 8 分鐘

在一個沒畢業的大學生都能對你設計的app前端頁面品頭論足的時代,一個合格的后臺pm愈發珍貴。

以我自己經歷的項目和身邊同行朋友的經驗,項目的產品leader都是在全部或部分職業生涯中做過后臺產品的;直白的來說,同樣的工作經驗,后臺pm的工資是同樣優秀的前臺pm的1.5倍以上。

自己剛畢業時做過一年的前端產品,后來臨危受命負責項目的整個后臺,并逐漸迷上了這塊。結合2年的后臺經驗,我認為后臺pm最看重邏輯思維能力、對所做業務足夠熟悉、項目需求管理和推進能力、后臺設計架構可擴展性兼容性高這幾塊。

邏輯思維能力

一種是系統內的邏輯。后端系統在頁面設計方面要求不會非常高,只需要做到布局清楚,做好提示減少誤操。如同做支付的人經常講路由和成本,其他后端系統也有類似的考慮,就是信息的路由。

一條請求發過來,不管是要查詢信息,還是要執行某個操作,都離不開系統內幾個模塊的信息流轉和同步。這條請求包含哪些數據,對數據需要做哪些處理,處理是人工做還是系統做,如果是人工做,還需要有系統的校驗和保存,處理后提供什么要的結果,結果如何展示,是否需要把結果通過接口或批量報表的形式提供給其他后臺模塊。往往在思考這些問題的時候,一張清晰的數據交互時序圖,可以幫助你解決很多問題,也更容易把你的想法傳達給開發同事。

另一種是寫后臺PRD時的邏輯。比如一個功能點,邏輯思維一般的人描述可能就是實現了xxx功能;而一個邏輯思維嚴謹的人,會清晰的描述出,前置條件,觸發因素,產生結果,系統處理規則,默認是什么樣,有數是什么樣,數據多了是什么樣,異常是什么樣。總結一下,就是條例清楚的表達出需求的來龍去脈。

充分跟需求方溝通,然后思維導圖羅列出功能架構,再基于這些,做邏輯圖。思路一定要清晰,否則很難推進下去。一定要盡量想的全面,別到時候需求評審時候,這里有問題,哪里不全面,會被開發笑話的。自己不清楚的時候,別指望別人能清楚的理解你。

熟悉自己在做的業務

熟悉自己在做的業務,是需要對服務體系內的業務流程足夠了解的,因為你設計的后臺是要去幫助他們更好的處理業務,你對業務流程不夠了解的話,設計出來的產品就會不貼合實際的使用場景。

對于業務的理解,可以概括為三點:

  1. 前臺有什么,后臺管什么,比如最基礎的用戶管理、商品管理、訂單管理、內容管理等等
  2. 對后臺系統的管理,比如個人信息管理、權限管理;
  3. 數據管理,一款好的產品一定是用戶利益和產品利益的結合體,而最能客觀反映產品利益的就是數據,所以平臺數據化;其次是邏輯思維,基本業務流程化、特殊場景特殊處理,與前臺互動的觸發機制等等

以自己在做的代購工具項目(自創業,已經成功賣給某電商平臺),我需要去了解整個代購的接單流程,為此我加了十幾個高質量代購群,并且自己把積累的這些認識的核心代購拉了個種子用戶群,每日堅持在群里發紅包向他們了解最真實的需求。為此我設計的后臺中,除了常見的商品管理模塊、訂單管理模塊,在此基礎上我加了自建商品庫(為了滿足代購創建一些銷量好,但免稅店沒有的商品,比如某幾類雜志)、委托單管理模塊和采購清單管理模塊,委托單和采購清單的實際應用場景請自行思考,就當是課后作業,答對有微信紅包。

項目需求管理能力

項目需求管理能力,我認為可以分為兩塊,需求池管理和明辨真偽需求。

一個比較大的后臺項目,可能涉及到多個前端產品的需求,好多功能,比較分散,并且多線并行。這時候需要一個需求池來管理需求,我一般采用excel把負責的需求匯集成一個需求池,并上傳公司內網,支持團隊內小伙伴的多人在線編輯,隨時更新各自跟進的需求的進度。需求池一般需要優先級、提出人、需求進度、預計上線日期等關鍵字段。

明辨真偽需求的前提,是懂業務!懂業務!懂業務!重要的事情說三遍。業務方的提的要求是一匹可以跑得更快的馬,但是實際你要給他的是一輛車。在跟業務方聊天的時候,不一定要記住他要求你做什么,但是你一定要記住他提出來種種的原因和期望實現的目的。

再就是后臺除非大版本大改動,否則基本上不會走版本,許多小改動當日改當日上,而且一般后臺產品會對接多個業務方,需求排期整理也是個技術活……

另外,有些常見改動模塊或者重復類功能,一定要做成靈活可配置,能幫你懟回去N多“白癡”需求。

對后續業務需求和功能的可擴展性

考慮后續業務的擴展,一個后臺管理系統,是為了滿足老板、運營等角色的管理需求?,F在階段的管理是為了滿足現有階段業務的需要,后續業務量上來了,一定要考慮擴展性。

舉一例,運營人員后臺上傳照片時,如果你簡單的想到一個button單張上傳,可以滿足現有業務的需求。但一旦量大了呢?上千上萬張圖片,一個一個button的去點么?

祝你在成為優秀后臺pm的路上,成功邁出第一步!

 

作者:菜月昂,BAT金融,90后產品汪,現居上海

本文由 @菜月昂 原創發布于人人都是產品經理。未經許可,禁止轉載

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 您好,可以加微信嗎?

    來自上海 回復
  2. 牛逼牛逼,小程序代碼誰寫的?你自己寫的嗎?

    來自廣東 回復
  3. 謝謝作者的分享,作為新入坑的后臺產品汪,真的是受益匪淺~~

    來自北京 回復
    1. 收益真的很多??!

      回復
  4. 關于項目管理那一塊,個人想補充三點;
    1、需求迭代版本的內容應該需要產品把控;
    2、每個版本上線后,產品經理必須參與驗收;
    3、需求變更進度和結果。

    來自廣東 回復
  5. 受益匪淺,上班兩天,才定位清楚自己,看了這篇文章,感覺自己的未來充滿了挑戰和不可預測性,也許此刻的我這四大能力都不確定,但是誰都不能確定未來。三個月后,我再來讀一遍這篇文章

    來自貴州 回復
    1. 加油,愿你歸來已有心得

      來自上海 回復
    2. 三個月到了,親,喊你回來一下

      來自河南 回復
    3. 快回來,我也要三個月后回來看,希望能轉正。。。

      回復
    4. 三個月了,愿你已經正式入坑PM ??

      來自廣東 回復
    5. 八個月后回來看,已轉正,但是進入到了瓶頸期

      來自廣東 回復
    6. 瓶頸都會有的,看哪方面的瓶頸,如果說是成長方向的話,私以為先往項目經理方向發展挺不錯的,多爭取獨立負責項目或產品的機會。

      來自廣東 回復
    7. 項目經理偏向于項目管理和技術(王語嫣不會武功,卻懂得各個武功的原理和破解),而技術對于我來說是半路出家,弱項,怎樣提升 ??

      來自廣東 回復
  6. 看過一句話,后臺產品經理做的最好的境界就是大家感受不到你的存在,哈哈 用起來行云流水

    來自北京 回復
    1. 哈哈,為后臺產品經理瘋狂打call

      來自上海 回復
  7. 非常贊,目前前端產品兼后臺。在工作中發現后臺比前臺更有趣,想往后天發展。 ??

    來自香港 回復
    1. 先向明天發展吧 ??

      來自廣東 回復
    2. 哈哈

      來自北京 回復
    3. 有意思有意思

      來自北京 回復
  8. 看到數據交互時序圖 想到了UML建模,期待分享一下數據交互時序圖的構思思路 ?? ??

    來自上海 回復
    1. 抽空整理下,最近剛好需要對產品架構進行整體建模梳理

      來自上海 回復
    2. 哈哈哈,來催「UML建?!沽?/p>

      來自北京 回復
  9. 有后臺產品經理的書可以推薦一手么?

    回復
    1. 不需要書,有看書的時間建議深入業務

      來自上海 回復
  10. 想想我們沒有產品經理的公司,既要做開發,還要自己理清業務,不是產品前臺后臺要自己做,而是開發的前端 后端也要自己做,心疼領導每天火急火燎的看系統、提問題~心累,身累矣

    來自北京 回復
    1. 創業公司吧

      來自廣東 回復
  11. 想想自己 既要負責前端產品設計,又要設計后端功能。

    來自福建 回復
  12. 同在上海,同是90后,加個微信有空多交流?

    回復
    1. ??

      來自北京 回復
  13. :mrgreen:

    來自北京 回復
  14. 恩恩

    來自北京 回復
  15. C2C?難道是客戶提交委托單,然后平臺上高質量的代購進行搶單,提供采購清單及預算,由客戶再次確認?怎么有點滴滴的味道,哈哈。個人瞎想,希望作者指點 ?

    來自廣東 回復
    1. 是的,流程基本就是這樣,采購清單主要服務接單的人,委托單服務求購者,對標類似滴滴 :mrgreen:

      來自上海 回復
  16. 大膽的猜一下,委托單和采購清單場景:A沒時間下訂單,提交一份需要買的商品委托單或者采購清單,本公司客服人員幫A下訂單;這就映襯了不管B端還是C端都是用戶,都有懶惰性。

    來自北京 回復
    1. 哈哈,流程接近了,你的想法是B2C,但其實我們做成了C2C

      來自上海 回復
  17. 學習了。后臺的難度,很多時候確實比前臺的大一些

    來自浙江 回復
    1. 難度越大,收入越高,不可替代性越強,值得

      來自上海 回復
    2. 對頭,就是要做一般人做不了的事,這樣才值錢。

      來自廣東 回復
  18. 深度好文,如果有需求池的模板共享就更完美!

    來自浙江 回復
    1. 并不需要模板,其實就是一個excel表格,里面加很多字段。需求描述、提出背景、提出人、時間、所屬功能模塊一類的,后面可以加上處理/反饋,要不要做,啥時候做一類的,重要不在于模板,而在于能把這件事執行下去,提出-反饋-排期,我的看法!

      來自廣東 回復
    2. 后面可以寫一篇專門講講需求池的構造和運用,請繼續關注~

      來自上海 回復
    3. 期待你的分享

      來自廣東 回復
    4. 我又來了,催更啦「需求池的構造和運用」

      來自北京 回復