中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

怎么挖掘市場需求？需求有了，怎么表達出來呢？需求寫出來了，接下來怎么和其他部門的人溝通呢？

對于一個剛畢業的產品新人來說，一上手就哐哐被安排了兩個大項目，而且還沒有人帶，導致我踩了無數的坑。

當然我要感謝我總監心這么大，就這么放心的讓我去干了……畢竟有些坑是非踩不可的，早踩早吸取經驗，也算是一種成長吧！

做產品呀，最重要心態要好~

那么我就以一個踩過無數坑的小白的粗淺認識，來總結一下我2018年做產品的心得吧。希望日后再回顧這篇文章時，可以欣慰不曾再犯同樣的錯誤。（為區分“產品經理”這個職務和“互聯網產品”這個東西，以下簡稱產品經理為PM，互聯網產品為APP）

PM是一個什么樣的角色？個人覺得，PM，就是千萬用戶的發聲者。PM肯定是最了解用戶的人，并且可以站在用戶的角度來審視自己做的APP到底是好是壞，然后自信的提出“這里不行，要改”。

當別人提出質疑時，可以很自信地反駁“我看了10萬條用戶反饋；拉了500人的用戶群，每天以普通用戶的身份和他們聊天；我發了100個社區動態，每一篇都可以獲得用戶100贊以上。沒有人比我更懂用戶！”這就是我總監在做管理者之前的日常，這樣的自信，誰還能反駁呢。如果要讓別人心服口服，就必須做到別人無法超越。

PM一定是高要求的人，不能放棄對高品質結果的追求，不能太好說話，不能這也行那也行。因為PM后面還有設計、開發，如果第一道關就不嚴格，后面就會一點點打折，最后出來的效果可能只能達到預期的60%了。

怎么挖掘需求？

1. 多用自家的APP。

把自己當成是普通用戶，按照自己的需要去用APP，然后在使用過程中感受自己的心理變化：用到什么功能的時候會覺得下次還想用；用到什么功能的時候感覺眉頭一緊，搞不懂怎么用，或者和自己預想的操作結果發生了偏差。

心理變化是很微妙且一瞬即逝的，所以要刻意練習，練習放大自己的心理感受，這一點我還沒做得很好，下次試試用筆或手機記錄下來吧！

2. 多用別人家的APP。

同樣類型的APP，使用下來，一定會有一個最為喜愛的，至于為什么寵兒是這一個，就非常值得研究了。比如你拍了一張好看的照片想要分享給大家看，微信朋友圈、QQ空間、ins、微博……

你第一反應是上傳到哪里？如果是我，我會首先上傳朋友圈，為什么——因為朋友圈有很多我的朋友，他們會給我點贊，受到贊我會很開心。

這么一想，微信就很值得研究了呀，它是如何做到現在的用戶規模的？它的使用體驗是怎么做的？它的每一次版本更新為什么要這么做？……

作為PM新人，可能很多時候都是接到一個需求就著手開始做了，這個時候，個人覺得，比起臨時抱佛腳的競品分析，平時使用APP的積累更加重要。

當你對一個功能束手無策的時候，如果腦海里立馬就可以蹦出“我記得某某APP有這樣的邏輯，我學一下”那就是很高效的一種辦法了。

能做到這樣，就必須要多用各種各樣的APP，大致理解它們的邏輯。

不要報以鄙視的心態去看任何一個能安裝到你手機上的APP，也許它界面真的很丑，也許它體驗真的很渣，但是它一定有它存在的合理性。

不能輕易去否定一個team的成果，幾個人幾十個人的頭腦，加起來總不會蠢到哪里去吧。

至于他們會什么這么做，也許是資源限制，也許是市場需要，這就需要深入研究了。

3. 多接觸用戶。

了解自己的用戶，才能更好地了解他們需要什么樣的產品，他們的需求到底是啥。

多看用戶反饋，能夠來反饋的人，一定是真的喜歡這個APP，希望它做得更好，所以他們的意見很有參考價值。

多看用戶評論，社區類的、短視頻類的產品，有很多用戶之間的互動，比如我沒事的時候就喜歡刷抖音，而且每條必看評論，評論里會發現很多有意思的人，有的時候看一些評論，你會覺得“臥槽，居然有人會這么想？”沒辦法，這就是用戶呀，有著各種奇妙的想法和心里感受。

了解別人家是怎么做的，為什么這樣做；了解自家的用戶需要什么樣的功能，這樣，才能挖掘出真正的好的需求。

怎么寫需求？

1. 確定需求列表。

拿到一個項目課題的時候，先挖掘需求，然后整合這些需求，按照APP的框架用腦圖把需求列表先畫出來，然后做取舍，哪些要做，哪些不做，哪些下一個版本做。需求列表中只需要寫明“做什么”，不需要寫“怎么做”。

比如：天貓精靈APP項目→設置→音量設置-手機調節天貓精靈音量。列出自己的需求列表之后，一定要及時和老大溝通，反復討論，反復確認。

首先要確保在“項目大體邏輯”這個大方向上自己的想法和老大的想法保持在統一戰線。否則如果按照自己的想法往下做，錯了就是完全自己背鍋，如果是老大的決定，那至少大家都不會怪一個新人。

2. 畫高保真原型圖。

確定做什么之后，就是怎么做了，我學到的習慣，是先畫出原型圖，再寫相關的邏輯，原型圖畫出來，界面上需要什么元素有了，寫邏輯的時候就基本不會漏掉某些功能。如果沒有頭緒，不知道怎么畫圖，最基本的辦法，看看市面上類似的產品，把圖copy下來。

年少輕狂的時候，我對于copy這件事也是嗤之以鼻，總覺得那是一種很low的手段。但是認清現實之后就發現，“抄”也是一門藝術。

創新固然是牛的，但是如果我自己做的創新就是不如市面上有的，那我為什么不吸取他們好的地方呢？

“抄”來的界面只是最表層的東西，具體的邏輯、這句文案怎么寫、這條分割線怎么放、這個按鈕什么樣式，這些全都是我自己研究出來的東西呀。

做PM不能沒有UI的感覺，如果只會寫邏輯，那跟UI設計師溝通的時候就會非常吃力，你看到一個UI界面，你感覺不對，但就是說不出哪里不對，是不是很難受？如果你可以一眼看出這個字號不對，這個配色不是我們APP有的配色，這個行高有問題，那么就會在UI設計時占有主動權，也可以push設計做得更好。

怎么訓練自己對UI的感覺呢？copy+思考，這里指的是平時有空的時候，臨摹各家做得好的APP界面，像素級copy，邊畫邊思考，為什么這么布局，圖片尺寸為什么是這樣，字間距、行高為什么是這樣，字號、配色為什么是這樣的。

這樣做的效果也許不會在平時工作中立竿見影，但是潛移默化的會讓自己有一點UI的分寸吧。拒絕做設計師口中的PM。

3. 畫交互邏輯圖。

簡單來說，就是頁面之間的跳轉，頁面元素的點擊之類的，需要整體列出來，一個一個界面排好，用箭頭指示這一步跳轉到下面那一步，之類的。這一個步驟，在大項目中非常重要，如果不梳理整體的邏輯，而是直接開始寫每個界面的邏輯，就會糾結在細枝末節上，而對整體失去把握。

畫出一份這樣的邏輯圖之后，跟老大、業務方、開發溝通的時候，就會輕松很多，可以讓他們先在腦海里對這個項目形成一個大致的概念，這樣他們也不至于看著你的需求懵，不知道這是個什么鬼東西。

4. 地毯式寫需求。

如上述，已經畫出了原型圖，那么就可以開心的寫邏輯了。對照頁面上的元素，從頭到尾，一個一個來。

五字秘訣“增刪改跳空”——交互（點擊、跳轉……）、顯示（最大字數、圖片尺寸、配色及蒙層……）、規則（出現、消失、位置、變更……）、特殊情況（網絡問題、為空情況、錯誤問題……）。

怎么溝通？

1. 換位思考。

PM最常溝通的人應該算是程序員吧，程序員每天都跟代碼打交道，他們對于一個需求的理解方式一定和PM是不同的，但是恰好PM寫的需求是給他們看的，所以必須要讓他們看得懂。這就需要換位思考，既然我的思考方式他們不理解，那么就試試他們的方式來思考。

2. 確保理解。

因為大家對需求理解不一致的緣故，最后做出來的東西根本不是我最初想要的，然后要不就是我妥協，要不就是改代碼，反正搞得大家都不會很愉快。這是我曾經踩過的坑，如果我可以確認大家都對需求有統一的認知，那就可以避免這個問題。

上面有提到，畫整體的邏輯圖，就是幫助其他同事理解我的需求的方式之一，首先讓他們對項目有一個整體的概念，要讓他們先知道我要做的是一個什么東西，我為什么要做這個東西，他們理解需求來源和整體之后，就不會跑太偏了。

我遇到過很坑的，可能也是比較常見的溝通失誤，就是講完需求，跟開發確認是不是都理解了，然后開發大大們很愉快的說理解了呀。

但是做的過程中再確認，就發現，嗯？怎么和我說的不一樣啊，理解偏差了啊……

避免這個問題，大概就只能反復和開發溝通吧，就是多講幾遍，給他們灌輸，講一遍，問一遍“我表達清楚了么？”然后最好讓他們復述一遍看是否有偏差，這樣反復確認。麻煩也沒辦法，總比代碼寫完了再來改要好，一定要先確保需求沒問題再開始寫代碼。

3. 不要放棄對結果的高要求。

如果你想做一個100分的好結果，你把項目交給設計、開發之后，他們出來的結果打個折，可能就只剩下80分、60分了……

PM是一個把控全局的角色，首先要堅定自己對結果的高要求，不能自己這里就先給了一個80分，那后面分數就只會越來越低。

舉個例子，如果一個設計稿出來，不去挑毛病、不去優化，直接就去開發了，開發過程中還有樣式的偏差，那最后做出來的頁面根本就不能看了。但如果在設計階段可以有更高的要求，逼一把設計師，出多幾稿，對比得出最好的，那后面就會穩妥很多。

任何時候，都要想著“我要做到100分，做到最好”，那如果客觀原因做不到100分，最后出來的結果也不會差太多。

4. 需求變更咋整呢？就可能心態要好吧，擁抱變化，以不變應萬變吧。

需求變更是不可能避免的，因為業務方總會有新想法，老大總覺得做得不夠好。

變更一定要及時，第一時間先通知開發暫停相關需求開發，將大致邏輯告訴他們。然后再盡快整理文檔同步。這樣做可以節省下開發不必要功能的時間，時間就是金錢，能省一點是一點。

因為過多的需求變更，引起開發小情緒的時候，等他們冷靜一下后再把需求要這么做的理由跟他們講清楚，理由一定得有理有據且邏輯清楚，加上業務方面和公司利益方面的考慮效果更佳。開發們也是講道理的，而且相當敬業，所以不會打死PM的。

以上，大概就是2018年我做PM踩過了一堆坑之后的個人經驗。都說PM要望天，但是我個人覺得自己現在基礎技能掌握的還不夠，所以總結的都比較淺顯易懂，比較適合日常工作。

期待一下我2019年的成長，是不是可以有更多望天的體會？到時候再來總結吧！

本文由 @小仙女仙女兒 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議