之前在一篇文章中看到說互聯網公司給實習生做的是比較不費腦或繁瑣的工作,競品分析和收集用戶反饋已經算高級的了。如果這種觀點成立的話,那我做的事情應該算是略高級的了,我一般都是進行競品分析、收集用戶反饋,並且給出方案,能被評審通過的方案就採納執行。

前幾天和部門的產品leader一起吃飯,談論了不少產品相關的話題。他說我對產品的理解是比較到位的,理論知識也比較紮實,但是缺少項目實踐經驗,說回去讓我自己自己考慮一個方案,並且自己負責跟進方案的落實。於是我這個產品新人便有機會自己負責一個小的功能的上線全流程,功能上線后還是很有成就感的,也反思總結了下功能從0到1的全流程,望各位前輩不要見笑。

一.需求調研

需求的來源一般有產品本身、數據分析、競品、用戶反饋、PM自發、來自BOSS這幾類,但並不是說所有的需求都要進行滿足,首先應該去分析辨別是真的需求還是只是偽需求,是否為剛需,需求頻次如何,需求的用戶基數有多大。然後也需要結合產品的定位,公司的資源,開發實現的難易程度,優先級,性價比去將合理的需求轉化為產品需求。

我們這個產品的需求來源於用戶反饋,通過用戶反饋的數據發現確實是有此需求,並且根據數據來看需求的人數較多。於是我便又去調研了幾個直接競品(與我們產品的業務模式重疊性較大,目標用戶相同)的處理方式,根據分析調研后的數據得出這個需求應該需要滿足的結論,於是我針對兩種典型的用戶採用了兩種不同的處理方案,考慮到類型二用戶的特殊性,我又將類型二的用戶細分為兩種方案(暫定為方案a與方案b),方案初步定下來之後我便去找mentor初步評審去了。

二.產品評審

方案評審前一定要自己想清楚方案的細節,以及作出此方案決定的緣由,最好是有數據支撐或者其他支持。切勿拍腦袋下定論,這樣評審的時候會死的很難看,別問我怎麼知道的。還有在定方案的時候如果牽扯到技術的問題,請提前找技術確認,提前找技術確認,提前找技術確認,不要等方案定下來之後,然後技術說實現不了。Mentor說理論上來講一般的需求都是能夠實現的,只是實現成本大小的問題,當然還有和技術的熟識程度。不停的請吃飯、請吃飯、請吃飯,陪加班、陪加班、陪加班就能快速和技術們打成一片了……

方案一初審就通過了,沒有什麼問題,Mentor關於方案二的兩種情況細緻的問了幾個問題,便問我為什麼不採用另外的一種處理方式,我說考慮到可能需要對接API的問題,然後Mentor說這個不需要對接API,碰到這樣的技術問題你應該去找技術確認。我說知道了,便回去重新修改了一下方案二中的兩個方案。Mentor確認之後讓我就方案二中的a方案和b方案去找技術評審確認下採用哪種方案。

三.技術評審

最開始我是在RTX和技術Leader溝通的,Mentor問我打算什麼時候和技術溝通的時候,我說正在溝通啊,然後Mentor告訴我這種複雜的問題應該是提前和技術預約好時間段,進行當面溝通,在評審前做好準備工作,盡可能的將需要問到的問題提前列舉出來,提升溝通的效率,在溝通完成之後需要就會議內容進行整理總結。

於是我在整理好方案,並做好準備工作之後便提前和技術Leader預約了個時間點,我把需求和方案拿給他的時候,他說:“方案一沒什麼問題,方案二需要改動的東西太多,實現不了”。我的內心幾乎是崩潰的,於是我就和他說需求已經定下來了,一定需要做。技術Leader確認后問到“已經確定要做了是吧?”我說“是的。”

然後我們就方案a和方案b進行了討論,技術Leader問了好多邊界問題,有的我考慮到了,有的邊界問題我根本沒有想到。雖然我被虐的慘無人道,還是要說技術的思維嚴謹程度真是太贊了。最後得出的結論是方案a要優於方案b,但是…還是採用方案b吧。我問技術Leader“以後應該還是要使用方案a的啊”,技術Leader說“方案a是比較合理的,估計以後也會使用方案a的。但是方案a需要改動的東西太多了,就先採用方案b吧。”我說“那以後需要用到方案a的時候怎麼辦?”技術Leader說“那到時候再改吧。”我……

然後就決定採用方案b了,後來我默默地去問技術的同事“你們是不是通常都是這麼處理?”技術說“對啊對啊,都是哪種實現方式最容易,改動最小就使用哪種方式。”我說“那就是不停的改改改么?”得到技術肯定的回答之後,我就問“那以後牽扯到很大的改動的時候豈不是就要整個架構重構了?”他沉默了……

四.產出原型圖

對於已經確定的方案,可以在產出原型圖的時候把一部分的工作就交由技術開始併發執行,比如需要接口啊,技術需要看一下之前的代碼啊,先考慮採用哪種實現方式,出現問題及時溝通,不要等到所有的方案都定下來之後才去找技術人員。

在產出原型的時候需要將邊界問題、默認值、極限值這些東西想清楚,確定用戶的主要使用流程、支線流程、異常流程,以及異常情況的處理方式,提示語、操作反饋等。同時還應該注意操作的前置條件,是否涉及賬號、權限問題,在操作成功之後的情況又是什麼樣子的,有無進行數據上報的需要,這些都是需要自己想清楚的。這裏面有很多坑雖然自己現在並不能夠都考慮到,但是也會盡可能的去考慮的全面一點。

五.勾搭UI

Mentor要求功能要在四天之內上線,留两天的時間給技術人員進行開發,所以在進行項目之前,我繪製了一個小型的甘特圖,方便自己跟進項目,後來發現那只是理想的狀況,事實是遇到了很多問題。方案推倒重來花了半天,技術Leader根本沒時間,約個時間評審就等了兩個多小時,導致最後視覺稿只能延遲到第三天。然後快下班的時候驚悉UI妹紙明天請假了,所以我就在臨近下班的最後去找的UI幫忙產出視覺稿。

在UI妹紙很是嫌棄的目光中,我把線框圖交給她了,UI妹紙很是幽怨的說道“哪有你這樣的啊,快下班了才來提需求的,啊?”我說“本來是打算明天請你出視覺稿的,不是剛剛才知道你明天不上班么。”還好之前部門聚餐的時候發現UI妹紙是屬於典型的吃貨,就說回頭請她吃飯,UI妹紙立刻兩眼放光的回道“好啊好啊”,於是有驚無險的產出了視覺稿。產出視覺稿之後,我又將方案完善了一下,然後去找技術Leader預約資源,技術Leader給我分配了個技術人員,準備第二天開發。

六.研發測試

研發並沒有什麼問題,整個流程中技術就和我確認了幾個具體的問題,其他都正常進行,技術花了接近两天的時間實現了功能。功能研發完成之後,就發到測試環境了,我測試了兩個小時之後發現沒有什麼問題,就讓技術把新功能上線了。

雖然說只是上線一個小功能,但也算是自己第一次獨立負責的一個功能的全流程,功能上線之後還是感覺略有成就感的,感謝隊友們,雖然目前我可能還會有點坑,但是我也會繼續努力快速成長的。

回過頭來總結一下這個功能上線的全過程,順便也將自己踩過的坑和經驗心得匯總一下,希望能夠幫助到像我一樣的新人。

心得之一:一定要採用技術和UI常用的方式進行交流,用他們的語言說話;

心得之二:下結論的時候一定要想清楚,有哪些論據可以支撐你的結論;

心得之三:說服別人時用調研得到的數據說話,爭取做到有理有據,事實說話,不要摻雜過多的主觀因素;

心得之四:自信,做完了相關的準備工作之後,說話一定要有自信,如果說你自己都不能相信你自己的Idea,你怎麼能夠去把你的Idea推銷給別人呢?

心得之五:討論之前先界定問題的邊界,確定你們討論的是同一個話題,定義的是同一個內容。Mentor關於某一個問題在RTX上和我討論了近5分鐘,他一直捉急我沒有get到他要表達的點,我一直捉急我本就就是使用他說的那種方式,沒有改動的必要。後來我們面談的時候,我才發現他錯把我們產品正在使用的樣式當成了我的Demo。

心得之六:可并行執行的事項就并行執行,由於時間有限,所以需要提前合理的安排好,將能夠同時進行的工作同時展開。

心得之七:優先級,做事一定要分優先級,可按照重要程度與緊急程度來進行劃分,先做重要緊急的事,最後做不重要不緊急的事情。先做重要的事情,酌情處理緊急的事情,不然很可能會一直疲於奔命於緊急不重要的事情。

心得之八:性價比,做事需要考慮投入產出比,優先做性價比高的事情,減少做性價比不高的事情,甚至根本就不去做性價比低的事情。

以上就是產品新人第一次負責一個新功能上線的全部流程,希望能夠對你有哪怕一點點的幫助,也希望廣大前輩們不要見笑,人艱不拆啦……

 

關於我:起點學員王家郴,公眾號(產品經理從0到1),每周都會在公眾號上寫點東西,歡迎關注,求指教、求分享、求交流。目前是大四黨、產品經理實習生,奔走在產品的道路上,漫漫產品路,與君共勉。

本文系起點學院廣州1509期優秀學員@王家郴 原創發布,未經作者許可,禁止轉載。