復盤|新一年換工作後的首次總結

收藏待读

復盤|新一年換工作後的首次總結

可能很多產品人也會有過這樣的疑問:產品的流程已經銘記於心,產品的理論也背得滾瓜爛熟,但是為什麼實際運用到工作崗位中卻還是覺得十分困難呢?

復盤|新一年換工作後的首次總結

18年10月換了新工作,對比美團和同程的工作經歷,覺得之前卻是溫室里的花朵,一切都在有條不紊的環境下進行。而現在快速增長的業務,公司以每周新進7-10人的速度快速擴張,經驗、認知和能力一次次受到挑戰,壓力還是蠻大的。

邏輯不嚴謹致產品設計質量不高而心情低落時長有,但也需要不斷構築自信心,安慰自己接下來提高。這個過程中需要不斷地學習、總結與反思,也體現了環境對於產品經理的影響,不同環境下,產品經理的價值和成長速度迥然不同。

一直看好互聯網行業是塊香餑餑,工作不愁,卻沒想2018年互聯網進入了寒冬時代。年中開始,小米、美團、拼多多、同程相繼上市;年底,很多公司面臨裁員或組織架構調整,身邊的朋友有受到波及的,才意識到這些都是真正發生在自己身邊。

我們公司還在不斷拓展新業務並於年前拿到螞蟻金服D輪融資,個人覺得還是蠻幸運的,也對面試時認可我的領導表示深深的感恩。

產品流程滾瓜爛熟,產品理論一套一套,但在這兩個多月的時間內,實際工作卻不是那麼回事兒,慢慢也暴露了越來越多的問題,自己對產品工作流程的各個節點有一些新的認識和感觸,故作此總結。

一、需求分析之識別真需求

產品是需求輸出的源頭,我們會接到來自各方的需求:運營或客服反饋、老闆或leader的個人想法、業務發展或產品本身的迭代功能……

之前項目,從需求收集到需求輸出,做的最多的是評估需求價值,即這個需求到底有沒有必要做,做了之後可以為我們帶來什麼?而現在需要考慮更多的是:需求真正是為了解決了什麼問題?是否有可替代的更好的方案?而不是用戶或客服反饋說,簡單的添加一個什麼樣的功能?或把這個功能改成什麼樣式?

用戶想要什麼不等於真實需求;可以怎麼做不等於應該怎麼做。需求分析理論我們都知道,如何把理論在實際工作中真正應用起來,是這個階段我感悟最深的一點。

我在實際項目中,根據客服反饋,將餘額提現失敗的轉人工做成了一個需求,開發到一半,才發現客服要求轉人工的真正目的是用戶風險驗證FaceBook找不回的原因,應該要解決FaceBook賬號找不回的問題,而不是客服反饋說把提現申請失敗的轉到人工審核中,讓客服操作提現申請成功。

二、產品設計之競品分析

面試的時候,我們會被問到一個問題:你有沒有了解過你行業的其他競品?如果你說沒有,那面試分數將直接下降。包括面試的這家公司的行業競品,比如,我當時去來電科技面試時,面試官問到我對來電和街電的看法。

我認為:做產品設計時競品分析是必須要做的一件事兒。大到項目立項時的競品行業分析、產品戰略,小到產品設計時具體的某個功能,你都要去借鑒,去對比,去分析。

如果競品沒有直接顯現的功能,需要觸發某個條件才能發生,那麼你就要把自己當作一個用戶,去體驗它的完整流程。

有這樣的感悟,是因為自己近期做了一個「還款提醒」功能。作為用戶,沒有借款過、逾過期,所以第一版的推送頻率和文案都是自己YY的,後面同事提到,你應該自己去體驗一下這個流程,才知道有更好的優化方向,這才意識到競品分析必須要放到產品的設計流程中來。

產品設計的過程中,也需要考慮:

  • 是否需要UE、UI稿輸出?
  • 是否考慮了異常情況,邊界情況?
  • 流程是否形成了閉環?在新增一個功能時特別要注意對其他模塊的影響,最好的做法就是把自己當作用戶,反覆體驗整個流程,關注點不能只在新增的功能點上。
  • 是否需要新舊版本兼容?
  • 是否有利於功能延展,版本迭代?
  • 上線後若出現BUG、異常、效果不明顯、影響流程、影響體驗,是否可及時根據已有邏輯控制風險(如該功能有配置開關、可通過下線banner、關閉入口解決)
  • 是否需要A/B test?
  • 是否需要數據埋點?

上述提到的每一點在產品設計過程中都是應該考慮的(如果有需要補充的,歡迎後面留言討論)。

三、文檔撰寫之條理清晰

因目前負責模塊較之前更複雜一些,且大多數都是在已有的功能上做重構或優化,PRD文檔在開發的過程中一次又一次被挑出描述不清楚,尤其是寫類似「和XXX功能保持一致」這樣的話。

事實上,之前做XXX功能的開發同事和目前做新需求的往往不是一個人,他們不能確定」XXX功能」到底是怎麼樣的?

在已有的功能上做重構或優化,需要在文檔中講述新的需求是新增、刪除還是更新之類的;同時文案也要易懂,不存在歧義。

原型上,需要標明當前頁是從哪個頁面或哪個按鈕跳轉來的?當前頁返回,又是回到了哪個頁面?同樣得,彈窗上的按鈕,「取消」也好,「確認」也罷,必須要寫清楚點擊後的效果。是又發生了頁面跳轉還是停留當前頁?

我們目前的App,因之前原型設計時,對頁面或按鈕跳轉沒有說明,導致同樣的功能,安卓和IOS跳轉到不同的頁面,兩邊的開發在實際開發過程中根據自己的理解「自定義」跳轉。

四、需求評審之背景講解

之前需求評審時一上來就跟開發講功能點:我需要一個什麼功能,這個功能應該做成什麼樣子。

如果開發不了解需求背景或需求目的,他們就真的只會按照原型原封不動的去「實現」出來, 但如果他們了解需求背景,也會有自己的思考,去看這個功能合不合理,或以一種可拓展性更強的方式來實現。

五、項目跟進之快速解決問題

需求評審完以後,進到開發環節。在實際開發過程中,具體的細節問題往往比自己想像的多很多。也經常發生:用A方案好還是B方案好? 這個時候需要產品的判斷力和決策力,你必須自己能做主,在最快的時間內拍板,到底採用哪種方案,這是快速解決問題的能力。

項目上線後,線上產品出現異常,你能最快找到問題並協調開發將問題解決。這些在目前項目中時長發生,也是在這個過程中,慢慢學會分析問題原因的能力。

換了新工作後,996是常事,周末外出幾次最後又回到公司看數據解決問題。比如上周末從草莓園回來,因線上產品出了問題,下午四五點又回公司解決問到到晚上十點多,朋友調侃我拿一天當兩天用,才意識到,咦?這一天真是又玩了又工作了。

但是從沒後悔過,也不羨慕看劇吃飯逛街的清閑生活,反而很興慶,工作的滿足感遠遠超過了辛苦和疲倦,甚至超過了當初愛情帶來的短暫的幸福感。人在年輕的時候就應該竭盡全力去做自己想做的事兒,包括工作。 我願意用現在這般辛苦,換取一個無怨無悔的人生。

作者:花開不敗,微信公眾號:涵小仙女,產品經理,文藝女青年一枚,白天工作,晚上碼字,愛美,愛跑步,愛旅行,願我手寫我心,餘生不將就

本文由 @花開不敗 原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

原文 : 人人都是產品經理

相關閱讀

免责声明:本文内容来源于人人都是產品經理,已注明原文出处和链接,文章观点不代表立场,如若侵犯到您的权益,或涉不实谣言,敬请向我们提出检举。