1、產(chǎn)品經(jīng)理半年工作總結(jié)甄選產(chǎn)品經(jīng)理半年工作總結(jié)甄選 經(jīng)過一個半月的努力，終于在放假前一天提交了app store審核。 這是我的第一款產(chǎn)品，中途踩了不少坑，也挖了不少坑。雖然不知道這款產(chǎn)品最后的結(jié)局是怎樣，但是這半年的收獲很值得拿出來單獨說一說。 我準備分成兩個大部分來聊：產(chǎn)品設(shè)計、項目管理。 一.產(chǎn)品設(shè)計 產(chǎn)品設(shè)計的整個過程應(yīng)該包括用戶調(diào)研、需求分析、版本規(guī)劃、競品分析、功能點列表、原型設(shè)計。 今天重點聊聊原型設(shè)計、競品分析這兩小點。 1.原型設(shè)計 作為新人，一開始在畫原型的時候，會不知道如何下手，不知道這個頁面應(yīng)該長成什么樣子。造成這個的原因是沒有深入地思考過到這個頁面的作用是什么，即這個頁

2、面要達到什么目標。是為了讓用戶做出什么操作?還是讓用戶來查看什么數(shù)據(jù)? 每個頁面都有自己的目標，如果這個頁面沒有目標，可有可無，那它就不應(yīng)該存在。如果清晰地思考過這個頁面的作用，那么就可以羅列出這個頁面的元素，并排出優(yōu)先級。 接下去才進入琢磨原型的過程，這個時候又是老生常談的問題了，不要閉門造車。應(yīng)該多看看優(yōu)秀的產(chǎn)品是怎么做的，然后自己再適當(dāng)?shù)母脑欤@對于1-3年的產(chǎn)品經(jīng)理應(yīng)該是最快最穩(wěn)的方法。 在琢磨原型的過程中，應(yīng)該使用紙筆而不是Axure。當(dāng)你用紙筆已經(jīng)構(gòu)建了基礎(chǔ)的原型框架后，再用Axure實現(xiàn)出來做調(diào)整，這才是高效率的方法。Axure是用來輸出原型的，而不是用來琢磨原型的。如果一開始直

3、接用Axure來試原型，既浪費時間又費力，畢竟操作鍵盤鼠標遠沒有用紙筆來的快。 在設(shè)計V1.0版本的時候，功能、次核心細節(jié)的取舍是一個技術(shù)活。 功能的取舍最難，因為你會認為很多功能都是重要的，很多功能都需要上線。我認為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)

4、品講究小步快走，快速開發(fā)上線迭代。在第一個版本，要平衡好產(chǎn)品的附加分與產(chǎn)品開發(fā)的速度，不需要把第一個版本的產(chǎn)品做的大而美。 2.競品分析 我認為真正的競品分析有兩個境界。第一層是分析競品的功能、原型、交互;第二層是分析競品的產(chǎn)品定位、目標用戶、發(fā)展方向。 目前我只達到了第一層，所以今天只能聊聊第一層的內(nèi)容。 當(dāng)你在設(shè)計某一功能時，如果競品也有類似功能，此時你應(yīng)該是對這個功能進行差異化分析。競品為什么有這個功能?它的目標用戶和你一樣嗎?它的這個功能滿足的需求和你一樣嗎?這個功能呈現(xiàn)出這個樣子或者這個功能這么使用是基于當(dāng)時的什么前提條件?這個前提條件適用于你嗎?這個前提條件現(xiàn)在還是這個樣子嗎? 當(dāng)

5、你進行了這一系列的分析，你就能清楚地知道這個功能你應(yīng)該直接抄還是應(yīng)該抄一部分改一部分還是應(yīng)該全部改。如果盲目地抄競品，那你的產(chǎn)品永遠不可能做出差異化，只能默默地跟在競品的屁股后面走。 二.項目管理 1.溝通 整個項目下來，主要的溝通人員有設(shè)計師、程序員、測試人員。 我認為與設(shè)計師溝通的重點是，拿著原型和設(shè)計師說這個頁面的作用以及需要突出什么元素。一個頁面一個頁面地過，雖然這樣費時間，但是節(jié)省了很多修改的時間。 因為設(shè)計師思考的方式是以美為主的頁面，難免會忽略掉美以外的元素，所以在設(shè)計之前，就應(yīng)該溝通好這個頁面需要達到什么目的，突出什么內(nèi)容，這樣才不會在設(shè)計的時候走偏。 和開發(fā)溝通是最最最最困難

6、的，一方面我們不懂技術(shù)，不能很好地設(shè)計出讓他們邏輯好做又能達到目標的產(chǎn)品，所以在開發(fā)之前，一定要拿著原型和交互、實現(xiàn)邏輯好好溝通評審!有任何邏輯不同的地方，才能馬上修改，以免開發(fā)到一半再推倒重來，會被打死。 因為程序員自己看你的原型開發(fā)，一定會開發(fā)出偏離你設(shè)想的東西。比如沒有留意到需要采集某個數(shù)據(jù)、讓數(shù)據(jù)運算、數(shù)據(jù)需要實時采集更新，甚至是憑著自己的想象來做。任何細節(jié)的東西，一定要在開發(fā)前溝通好，否則框架搭完了才發(fā)現(xiàn)，那基本已經(jīng)來不及了。不是被懟就是得砍了。 小公司的測試人員一般是由別的崗位充當(dāng)?shù)慕巧麄儾幌癯绦騿T、更不想你那么了解產(chǎn)品。所以最好的辦法就是，寫下測試文檔，精確到流程、功能、頁面讓他們測試，否則他們測試的時候，一頭霧水 云里霧里。反復(fù)找你詢問，效率很低，還不如自己測 2.進度跟進 項目進度跟進表是一個極其重要的東西! 項目進度跟進表是一個極其重要的東西! 項目進度跟進表是一個極其重要的東西! 時刻把握整個團隊的進度，是實現(xiàn)項目準時上線的必要條件。為了防止團隊有人掉鏈子，需要時刻跟進、更新、記錄進度。否則到后面會嚴重影響整個項目甚至整個團隊。 3.階段驗收 不論是設(shè)計還是開發(fā)還是測試，每做完一個功能/頁面都要驗收一次。 很多人都會把功能/頁面拆分著做，但是會出現(xiàn)做一半就擱置的問題，到最后才發(fā)現(xiàn)前面遺留了很多半