找總結網(wǎng) > 工作總結 > 工作總結范文 > 產(chǎn)品經(jīng)理半年工作總結

產(chǎn)品經(jīng)理半年工作總結

| cwl2

產(chǎn)品經(jīng)理半年工作總結

經(jīng)過一個半月的努力,終于在放假前一天提交了app store審核。

這是我的第一款產(chǎn)品,中途踩了不少坑,也挖了不少坑。雖然不知道這款產(chǎn)品最后的結局是怎樣,但是這半年的收獲很值得拿出來單獨說一說。

我準備分成兩個大部分來聊:產(chǎn)品設計、項目管理。

一.產(chǎn)品設計

產(chǎn)品設計的整個過程應該包括用戶調(diào)研、需求分析、版本規(guī)劃、競品分析、功能點列表、原型設計。

今天重點聊聊原型設計、競品分析這兩小點。

1.原型設計

作為新人,一開始在畫原型的時候,會不知道如何下手,不知道這個頁面應該長成什么樣子。造成這個的原因是沒有深入地思考過到這個頁面的作用是什么,即這個頁面要達到什么目標。是為了讓用戶做出什么操作?還是讓用戶來查看什么數(shù)據(jù)?

每個頁面都有自己的目標,如果這個頁面沒有目標,可有可無,那它就不應該存在。如果清晰地思考過這個頁面的作用,那么就可以羅列出這個頁面的元素,并排出優(yōu)先級。

接下去才進入琢磨原型的過程,這個時候又是老生常談的問題了,不要閉門造車。應該多看看優(yōu)秀的產(chǎn)品是怎么做的,然后自己再適當?shù)母脑?,這對于1-3年的產(chǎn)品經(jīng)理應該是最快最穩(wěn)的方法。

在琢磨原型的過程中,應該使用紙筆而不是Axure。當你用紙筆已經(jīng)構建了基礎的原型框架后,再用Axure實現(xiàn)出來做調(diào)整,這才是高效率的方法。Axure是用來輸出原型的,而不是用來琢磨原型的。如果一開始直接用Axure來"試"原型,既浪費時間又費力,畢竟操作鍵盤鼠標遠沒有用紙筆來的快。

在設計V1.0版本的時候,功能、次核心細節(jié)的取舍是一個技術活。

功能的取舍最難,因為你會認為很多功能都是重要的,很多功能都需要上線。我認為V1.0版本和最小化可行產(chǎn)品(MVP)存在一些差異,MVP是在驗證一個新生兒產(chǎn)品的可行性,但是很多V1.0版本的產(chǎn)品,是已有這個市場,那此時就不能按照MVP的方法砍功能,否則上線一個沒有核心競爭力的產(chǎn)品是沒有意義的。

V1.0版本完全可以不顧次核心細節(jié),比如ios原生的選擇日期插件比較枯燥、冰冷,你可以加上自己的元素讓選擇日期帶有產(chǎn)品溫度。但是這樣無疑會加重開發(fā)的工作量,互聯(lián)網(wǎng)產(chǎn)品講究小步快走,快速開發(fā)上線迭代。在第一個版本,要平衡好產(chǎn)品的附加分與產(chǎn)品開發(fā)的速度,不需要把第一個版本的產(chǎn)品做的大而美。

2.競品分析

我認為真正的競品分析有兩個境界。第一層是分析競品的功能、原型、交互;第二層是分析競品的產(chǎn)品定位、目標用戶、發(fā)展方向。

目前我只達到了第一層,所以今天只能聊聊第一層的內(nèi)容。

當你在設計某一功能時,如果競品也有類似功能,此時你應該是對這個功能進行差異化分析。競品為什么有這個功能?它的目標用戶和你一樣嗎?它的這個功能滿足的需求和你一樣嗎?這個功能呈現(xiàn)出這個樣子或者這個功能這么使用是基于當時的什么前提條件?這個前提條件適用于你嗎?這個前提條件現(xiàn)在還是這個樣子嗎?

當你進行了這一系列的分析,你就能清楚地知道這個功能你應該直接抄還是應該抄一部分改一部分還是應該全部改。如果盲目地抄競品,那你的產(chǎn)品永遠不可能做出差異化,只能默默地跟在競品的屁股后面走。

二.項目管理

1.溝通

整個項目下來,主要的溝通人員有設計師、程序員、測試人員。

我認為與設計師溝通的重點是,拿著原型和設計師說這個頁面的作用以及需要突出什么元素。一個頁面一個頁面地過,雖然這樣費時間,但是節(jié)省了很多修改的時間。

因為設計師思考的方式是以美為主的頁面,難免會忽略掉"美"以外的元素,所以在設計之前,就應該溝通好這個頁面需要達到什么目的,突出什么內(nèi)容,這樣才不會在設計的時候走偏。

和開發(fā)溝通是最最最最困難的,一方面我們不懂技術,不能很好地設計出讓他們邏輯好做又能達到目標的產(chǎn)品,所以在開發(fā)之前,一定要拿著原型和交互、實現(xiàn)邏輯好好溝通評審!!有任何邏輯不同的地方,才能馬上修改,以免開發(fā)到一半再推倒重來,會被打死。。。

因為程序員自己看你的原型開發(fā),一定會開發(fā)出偏離你設想的東西。比如沒有留意到需要采集某個數(shù)據(jù)、讓數(shù)據(jù)運算、數(shù)據(jù)需要實時采集更新,甚至是憑著自己的想象來做。任何細節(jié)的東西,一定要在開發(fā)前溝通好,否則框架搭完了才發(fā)現(xiàn),那基本已經(jīng)來不及了。。。不是被懟就是得砍了。。。

小公司的測試人員一般是由別的崗位充當?shù)慕巧?,他們不像程序員、更不想你那么了解產(chǎn)品。所以最好的辦法就是,寫下測試文檔,精確到流程、功能、頁面讓他們測試,否則他們測試的時候,一頭霧水 云里霧里。反復找你詢問,效率很低,還不如自己測

2.進度跟進

項目進度跟進表是一個極其重要的東西!

項目進度跟進表是一個極其重要的東西!

項目進度跟進表是一個極其重要的東西!

時刻把握整個團隊的進度,是實現(xiàn)項目準時上線的必要條件。為了防止團隊有人掉鏈子,需要時刻跟進、更新、記錄進度。否則到后面會嚴重影響整個項目甚至整個團隊。

3.階段驗收

不論是設計還是開發(fā)還是測試,每做完一個功能/頁面都要驗收一次。

很多人都會把功能/頁面拆分著做,但是會出現(xiàn)做一半就擱置的問題,到最后才發(fā)現(xiàn)前面遺留了很多半成品。

甚至是以為功能/頁面做完了,然后就接著往下做。殊不知,根本就不能用

所以階段性驗收十分重要!還要檢查是靜態(tài)數(shù)據(jù)還是真正接上了接口的數(shù)據(jù)!

愿2020年不負自己,不負寄予我厚望的人,不負付我錢的老板。

11540