產(chǎn)品經(jīng)理半年工作總結(jié)
經(jīng)過一個半月的努力，終于在放假前一天提交了app store審核。
這是我的第一款產(chǎn)品，中途踩了不少坑，也挖了不少坑。雖然不知道這款產(chǎn)品最后的結(jié)局是怎樣，但是這半年的收獲很值得拿出來單獨說一說。
我準(zhǔn)備分成兩個大部分來聊：產(chǎn)品設(shè)計、項目管理。
一.產(chǎn)品設(shè)計
產(chǎn)品設(shè)計的整個過程應(yīng)該包括用戶調(diào)研、需求分析、版本規(guī)劃、競品分析、功能點列表、原型設(shè)計。
今天重點聊聊原型設(shè)計、競品分析這兩小點。
1.原型設(shè)計
作為新人，一開始在畫原型的時候，會不知道如何下手，不知道這個頁面應(yīng)該長成什么樣子。造成這個的原因是沒有深入地思考過到這個頁面的作用是什么，即這個頁面要達(dá)到什么目標(biāo)。是為了讓用戶做出什么操作?還是讓用戶來查看什么數(shù)據(jù)?
每個頁面都有自己的目標(biāo)，如果這個頁面沒有目標(biāo)，可有可無，那它就不應(yīng)該存在。如果清晰地思考過這個頁面的作用，那么就可以羅列出這個頁面的元素，并排出優(yōu)先級。
接下去才進(jìn)入琢磨原型的過程，這個時候又是老生常談的問題了，不要閉門造車。應(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是用來輸出原型的，而不是用來琢磨原型的。如果一開始直接用Axure來"試"原型，既浪費時間又費力，畢竟操作鍵盤鼠標(biāo)遠(yuǎn)沒有用紙筆來的快。
在設(shè)計V1.0版本的時候，功能、次核心細(xì)節(jié)的取舍是一個技術(shù)活。
功能的取舍最難，因為你會認(rèn)為很多功能都是重要的，很多功能都需要上線。我認(rèn)為V1.0版本和最小化可行產(chǎn)品(MVP)存在一些差異，MVP是在驗證一個新生兒產(chǎn)品的可行性，但是很多V1.0版本的產(chǎn)品，是已有這個市場，那此時就不能按照MVP的方法砍功能，否則上線一個沒有核心競爭力的產(chǎn)品是沒有意義的。
V1.0版本完全可以不顧次核心細(xì)節(jié)，比如ios原生的選擇日期插件比較枯燥、冰冷，你可以加上自己的元素讓選擇日期帶有產(chǎn)品溫度。但是這樣無疑會加重開發(fā)的工作量，互聯(lián)網(wǎng)產(chǎn)品講究小步快走，快速開發(fā)上線迭代。在第一個版本，要平衡好產(chǎn)品的附加分與產(chǎn)品開發(fā)的速度，不需要把第一個版本的產(chǎn)品做的大而美。
2.競品分析
我認(rèn)為真正的競品分析有兩個境界。第一層是分析競品的功能、原型、交互;第二層是分析競品的產(chǎn)品定位、目標(biāo)用戶、發(fā)展方向。
目前我只達(dá)到了第一層，所以今天只能聊聊第一層的內(nèi)容。
當(dāng)你在設(shè)計某一功能時，如果競品也有類似功能，此時你應(yīng)該是對這個功能進(jìn)行差異化分析。競品為什么有這個功能?它的目標(biāo)用戶和你一樣嗎?它的這個功能滿足的需求和你一樣嗎?這個功能呈現(xiàn)出這個樣子或者這個功能這么使用是基于當(dāng)時的什么前提條件?這個前提條件適用于你嗎?這個前提條件現(xiàn)在還是這個樣子嗎?
當(dāng)你進(jìn)行了這一系列的分析，你就能清楚地知道這個功能你應(yīng)該直接抄還是應(yīng)該抄一部分改一部分還是應(yīng)該全部改。如果盲目地抄競品，那你的產(chǎn)品永遠(yuǎn)不可能做出差異化，只能默默地跟在競品的屁股后面走。
二.項目管理
1.溝通
整個項目下來，主要的溝通人員有設(shè)計師、程序員、測試人員。
我認(rèn)為與設(shè)計師溝通的重點是，拿著原型和設(shè)計師說這個頁面的作用以及需要突出什么元素。一個頁面一個頁面地過，雖然這樣費時間，但是節(jié)省了很多修改的時間。
因為設(shè)計師思考的方式是以美為主的頁面，難免會忽略掉"美"以外的元素，所以在設(shè)計之前，就應(yīng)該溝通好這個頁面需要達(dá)到什么目的，突出什么內(nèi)容，這樣才不會在設(shè)計的時候走偏。
和開發(fā)溝通是最最最最困難的，一方面我們不懂技術(shù)，不能很好地設(shè)計出讓他們邏輯好做又能達(dá)到目標(biāo)的產(chǎn)品，所以在開發(fā)之前，一定要拿著原型和交互、實現(xiàn)邏輯好好溝通評審!!有任何邏輯不同的地方，才能馬上修改，以免開發(fā)到一半再推倒重來，會被打死。。。
因為程序員自己看你的原型開發(fā)，一定會開發(fā)出偏離你設(shè)想的東西。比如沒有留意到需要采集某個數(shù)據(jù)、讓數(shù)據(jù)運算、數(shù)據(jù)需要實時采集更新，甚至是憑著自己的想象來做。任何細(xì)節(jié)的東西，一定要在開發(fā)前溝通好，否則框架搭完了才發(fā)現(xiàn)，那基本已經(jīng)來不及了。。。不是被懟就是得砍了。。。
小公司的測試人員一般是由別的崗位充當(dāng)?shù)慕巧?，他們不像程序員、更不想你那么了解產(chǎn)品。所以最好的辦法就是，寫下測試文檔，精確到流程、功能、頁面讓他們測試，否則他們測試的時候，一頭霧水 云里霧里。反復(fù)找你詢問，效率很低，還不如自己測
2.進(jìn)度跟進(jìn)
項目進(jìn)度跟進(jìn)表是一個極其重要的東西!
項目進(jìn)度跟進(jìn)表是一個極其重要的東西!
項目進(jìn)度跟進(jìn)表是一個極其重要的東西!
時刻把握整個團隊的進(jìn)度，是實現(xiàn)項目準(zhǔn)時上線的必要條件。為了防止團隊有人掉鏈子，需要時刻跟進(jìn)、更新、記錄進(jìn)度。否則到后面會嚴(yán)重影響整個項目甚至整個團隊。
3.階段驗收
不論是設(shè)計還是開發(fā)還是測試，每做完一個功能/頁面都要驗收一次。
很多人都會把功能/頁面拆分著做，但是會出現(xiàn)做一半就擱置的問題，到最后才發(fā)現(xiàn)前面遺留了很多半成品。
甚至是以為功能/頁面做完了，然后就接著往下做。殊不知，根本就不能用
所以階段性驗收十分重要!還要檢查是靜態(tài)數(shù)據(jù)還是真正接上了接口的數(shù)據(jù)!
愿2020年不負(fù)自己，不負(fù)寄予我厚望的人，不負(fù)付我錢的老板。