問題1：簡歷的照片，有用么？

BLUES回答：有用，一張照片，可以看出很多信息，顏值高會加分，這是真的，但不要拿P得離譜的照片放上面，少一點套路，多一點真誠。

那顏值不高怎么辦？——哪有那么多顏值高的簡歷啊，這是招聘互聯網公司員工，又不是選美，顏值是個錦上添花的東西，一切條件相當，顏值就加分了，尤其是對于程序員GG，他們也喜歡聽顏值高的女產品經理講需求。

一張充滿親和力的照片，或許是比較實在的，微笑+精神飽滿，就挺好了。

問題2：簡歷寫幾頁？

BLUES回答：能一頁A4紙寫完，當然更好。如果真有想表達的，兩頁A4紙，應該夠用了。

問題3：需要提供作品么？

BLUES回答：設計師簡歷，必然是需要附帶作品的。產品經理、產品運營，最好能附帶有一兩個案例，說明你的核心能力。BLUES遇到那些對梅沙教育的APP做分析報告的簡歷，通常會認真看看，畢竟也是難得的反饋。產品經理的策劃文檔（含原型）、競品分析、數據分析，能看出不少能力水平，如果真的有誠意，就主動提供一下吧。

問題4：簡歷提交用什么格式？

BLUES回答：首選PDF文檔，次之圖片格式，例如JPG。至于為什么，發WORD的，WPS的，自己把簡歷多發給幾個朋友，讓他們打開后，截圖給你看看。

下面開始說今天的話題，也歡迎有過招聘經驗的朋友，后面留言聊聊你最喜歡提問的面試題是什么？

產品經理面試必考題

這道必考的面試題目是：聊聊你做過的產品版本或一個項目。

這道問題，其實是源于結構化面試的STAR原則，這也是BLUES以前做面試官培訓時候的必講內容，典型的面試官套路。

STAR原則，即Situation（情景）、Task（任務）、Action（行動）和Result（結果）四個英文單詞的首字母組合。

S——situation，情景。

要求候選人描述他在所從事崗位期間曾經做過的某件重要的且可以作為體現其崗位能力的事件所發生的背景狀況。

T——task，任務。

考察候選人在其上述背景中所執行的任務與角色，從而考察該候選人是否做過其描述的職位及其是否具備該崗位的相應能力。

A——action，行動。

考察候選人在其所描述的任務當中所擔任的角色是如何操作，并完成任務的。這個行動的過程，是可以不斷追問細節的過程，做過與沒做過，擔任主導角色還是參與執行，可以在追問中逐漸明確。BLUES遇到過一些簡歷夸大的候選人，就會在行動講述過程中，表現出含糊不清的現象。

R——result，結果。

完成該任務在行動后所達到的效果，通常候選人求職材料上寫的都是一些結果，描述自己做過什么，成績怎樣，比較簡單和寬泛。

在面試的時候，需要了解候選人如何做出這樣的業績，做出這樣的業績都使用了一些什么樣的方法，遇到過哪些問題，如何解決，通過這些過程，我們可以全面了解該應聘者的知識、經驗、技能的掌握程度以及他的工作風格、性格特點、團隊合作等多種能力水平。

答題姿勢：白板演練

講項目的過程，BLUES會讓候選人在會議室的白板進行演講，聽的人，有產品經理、程序員等，其實就相當于這個項目的復盤，產品經理和程序員會從各自角度進行提問，也是一個PK過程。

演講完，整個白板就是一份答卷，可以很清楚的體現候選人的邏輯能力，口頭和書面表達能力。有的候選人在講述過程后，會不斷的涂改，擦除，或者寫一半發現面積不夠；有的候選人畫完流程圖，自己都看不清楚；有的候選人講完之后，白板只寫了幾個字……這都是沒有事先進行思考和準備，沒有做可用白板空間的判斷，在以前工作中或許缺乏鍛煉積累反思。

在講項目過程中，候選人的肢體語言，聲音，眼神等都能體現出溝通交流能力。

項目講述過程，也是考察項目管理能力，從項目開始到結束，有過什么樣的風險預估，經歷過哪些階段，每個階段有無遇到問題，如何解決。

講述產品，必然會有一些技術提問，考察產品經理的一些技術背景，對技術問題的理解，如何與程序員溝通等。

如果在講述產品過程，沒有出現邏輯圖、原型圖等元素，BLUES會專門要求候選人畫一些圖，考察基礎的手繪能力。

遠程面試怎么辦？

說實話，我比較喜歡現場面試，目前遠程面試也有一些候選人，但發OFFER的比例，還是現場面試居多，因為遠程面試會有不少因素妨礙面試判斷，例如典型的通信信號問題導致聲音視頻不清晰，會降低面試效率。所以，通過遠程面試的候選人，BLUES還是希望有機會當面聊聊，畢竟招聘一個人，就是希望以后能長久一起并肩奮斗的伙伴。

是否錄取：是否愿意每天一起工作？

我在面試結束后的內部評價過程中，通常都會讓面試官自己好好考慮，這個候選人，就是以后每天要在一起工作的伙伴，你是否會因為有這么一位伙伴并肩奮斗而感到榮幸，工作更有動力，工作效率會更高。

沒通過面試不代表能力不行

沒有通過面試，啥原因呢？

最主要的原因，當時是能力與崗位的匹配問題。前面的那道必考題，基本可以考察出候選人70%的能力水平是否達標。不知道其他招聘產品經理的朋友，是否也會采用這樣的方式進行判斷。

有時候沒有通過面試，不代表你不夠優秀，而是你擅長的部分，或許并不是公司需要的。例如有一位面試者，運營能力很強，但想做產品策劃，就不一定會錄取。這也是面試過程中的意愿匹配考察。

候選人的預期薪酬與公司判斷的差異。

進入梅沙科技之后，在3個月試用結束轉正評價時候，會有一次薪酬回顧，判斷當前定薪是否與能力水平匹配，候選人可以在三個月的試用期判斷工作內容與個人的產出貢獻，是否匹配當前薪酬，主動提出要求進行協商，所以三個月的試用期很關鍵。

如果是應屆畢業生沒有通過面試，通常是個人在對產品經理這個崗位的主動追求不夠，不少同學會說自己很喜歡產品經理這個崗位，但僅僅是喜歡，真正付出時間和努力去喜歡的程度，還是不夠。由此表現出對產品經理職業的理解，對產品策劃思維，對用戶體驗等多方面產品能力水平的不足。

作為交互設計師，你肯定會遇到打開產品經理發給你的交互原型時，映入眼簾的是非常擁有“個人魅力”的交互文檔，那么我們的工作就是將這些擁有“個人魅力”的文檔進行重新梳理，補充缺失的東西，刪除冗余的地方，將文檔規范化。下面是在梳理過程中經常遇到的十二個問題，分享給大家，一起學習。

01、沒有頁面結構和編號的文檔

對于產品經理來說，他們是產品設計的輸出者，對于產品的邏輯和流程他們再了解不過了，但是對于交互文檔的閱讀者來說，他們是要通過文檔內容了解頁面結構和產品功能的，所以清晰的頁面結構和頁面編碼可以幫助閱讀者快速的找到頁面，了解頁面結構和功能邏輯。

02、更新日志內容描述不詳細

對于執行者而言，指令不詳細相當于沒有指令。所以，對于研發、設計和測試人員，文檔的更新日志是為了幫助他們知道這個版本更新的功能具體是什么，細節有哪些。

03、排版不整齊

整潔有序的臥室和邋遢的臥室，你更喜歡哪一個?交互設計文檔也是一樣，整潔的文檔說明更有利于閱讀者閱讀。

04、丟失功能

很多功能是要有前后操作邏輯的，比如新建一個內容，那么對于新建的內容，是否需要編輯和刪除功能，對于數據量大的新增內容，是否需要提供查詢功能，這些都需要考慮進去，如果需要，那么下一步就把他們補充進去吧。

比如下面這個例子：

產品要的功能是：

1、通過頁面中兩個字段進行查詢，在下方列表中顯示查詢結果;

2、通過頁面中兩個字段進行新增，新增后在下方列表中展示新增的結果。

問題分析：

1、查詢功能和新增功能公用了同兩個字段，邏輯混亂;

2、點擊新增不會出現新增頁面只是在本頁提示請選擇上面兩個字段，缺失新增功能;

3、如果缺失新增功能頁面，那么編輯頁面同樣也是缺失的;

產品經理在輸出交互原型時容易忽略的十二個問題

解決方案：

1、將查詢功能和新增/編輯功能通過不同頁面進行區分，各自負責各自的功能;

2、補充查詢功能的重置，方便快速重新操作;

3、點擊新增進入面包屑下一級顯示需要新增的字段，保存后存入列表結果中;

05、功能過于復雜

合理的使用交互組件可以簡化用戶操作，提高操作效率，所以了解每個組件的實現功能和用戶的使用場景非常重要。

比如選擇一個時間范圍，用兩個時間選擇器可以實現此功能，用一個時間選擇器也可以實現此功能，兩者相比較，使用一個組件可以減少用戶點擊的次數，體驗效果更佳。

06、操作順序混亂

我們的閱讀順序通常是從上往下，從左往右，但是如果偏偏要改變這個順序，那么就會增加用戶的使用成本。

我們來看下面的這個例子：

操作者是物業的管理人員，使用場景是將負責的小區的公共區域產生的費用分攤給對應的客戶，從而完成費用統計。

操作步驟：

第一步：選擇小區，表計類型、分攤方式等基本配置信息;

第二步：設置分攤范圍，即選擇需要分攤的客戶都有哪些;

第三步：將基本配置信息和所選的分攤客戶進行保存，得出該小區的分攤費用結果。

問題分析：

1、所有的操作按鈕都放置在一起，沒有優先級;

2、所有操作按鈕在頁面的中間放置，有些操作不符合操作順序;

3、刪除選中分攤設置按鈕刪除的是哪些內容，有疑問;

4、清空操作是清空哪些內容，有疑問;

5、客戶選擇彈框中的按鈕冗余，分不清楚每個按鈕的使用規則;

針對以上問題進行重新設計：

解決方案：

1、將作用于同一個內容的操作按鈕進行分組;

2、根據用戶操作步驟，將操作按鈕進行先后分級;

3、在保證功能實現的前提下刪除多于的操作按鈕;

4、規范多選操作的交互樣式;

通過以上分析，我們在做交互設計的時候，首先要詳細了解它的使用場景，使用步驟，實現的目標，了解之后再做設計重構就會很有針對性，而且很高效。

07、使用截圖

有時候我們會在交互文檔中發現整張截圖，通常是因為產品經理們比較忙，他們在看到同類功能頁面的時候直接截圖過來，以表示他們想要的功能設計，好吧，你贏了，我們來改成可編輯的樣式吧。

08、缺少功能指引

我們先來看下面的一個例子吧。

這個功能的需求是用戶需要選中彈框中的一條數據，帶入到上級頁面的查詢項中，但是怎樣將彈框中查詢到的數據選中，用戶就需要開動腦筋了各種嘗試了，單擊、雙擊還是全選?

我們對彈框進行了優化，加入單選按鈕和確認按鈕，用戶就明白了。

09、缺少面包屑

頁面中的面包屑是用來告知用戶當前所在的位置以及它的上級頁面是哪里，相當于頁面的導航和定位，如果沒有頁面定位，用戶在多層級的結構中很容易迷失，所以用面包屑給用戶一個指引吧，迷失的感覺可不是很好，但是需要注意一點，面包屑導航的層級最多不要超過三個，太復雜的事情誰都不會喜歡。

10、出現雙彈框

彈彈彈，彈走魚尾紋。彈框是打斷用戶操作的一種非常不友好的交互方式，所以我們要盡量的減少彈框的出現，可以利用面包屑多層級設計減少彈框的出現。

11、不一致

字段文案不一致

同一個字段的名稱不統一，導致這種問題的原因之一是產品功能復雜，在沒有統一規范的前提下由多人負責產品輸出。建議把同一個產品中使用到的所有字段進行梳理和規范，包括字段名稱，字段長度限制，選擇項的內容等等，梳理后，不管多少人進行修改，都可以保持一致性。

操作位置不一致

同樣的操作在不同的頁面放置的位置不一致，用戶剛習慣了一種操作，到了另一個頁面，迷茫了，操作位置變了，用戶還要重新適應，無形中增加了用戶的學習成本。所以，遇到不統一的地方，別猶豫，統一它們。

比如常用的操作：保存取消;保存返回;新增;批量刪除;

提示文案不一致

雖然說同一句話可以用多種文案來表達，但是在產品設計中，同樣的功能同樣的提示還是需要保持統一的，用戶使用產品一段時間后，就會養成習慣，當看到某幾個字的時候就知道這句話的意思。

12、用很多文字描述一個復雜流程

人腦處理圖片信息的速度要快于文字，所以當我們給別人講述一個流程時，用流程圖展示要比文字描述更直觀，閱讀人員可以清晰快速的知道這里是需要判斷的，從而避免功能遺漏，所以試著用流程圖代替那些密密麻麻的文字吧。

以上十二個問題就是本人在工作中接到產品經理的原型圖時經常遇到的一些問題，但是我們的目標是一樣的，就是給用戶提供最好的服務，所以大家奔著一個方向努力，發現問題、分析問題、解決問題，共同努力創造更好的產品。

用戶需求是產品經理工作的基本出發點，不管是前期的行業調研、競品分析，還是產品研發過程的溝通傳達，還是產品上線后持續的迭代改進，頭腦里都需要圍繞用戶需求展開。

產品經理要挖掘出真實的用戶需求，是需要花些功夫的。用戶需求，字面上看，由用戶和需求兩個詞組成。分解來看，

首先，你的產品不是氧氣，不是黃金，不可能所有人都需要，因此要確定具體的目標用戶，越精準越好，通過用戶研究來確定核心用戶。然后去了解這些用戶在現實生活中，或是在使用別的產品過程存在哪些問題，這些問題是用戶們需要被滿足，但尚未被滿足的，即所謂的痛點。

挖掘核心用戶的痛點，可以通過數據分析、用戶訪談、可用性測試、問卷調查等方式，另外，在研究競品的過程中，產品經理盡量讓自己變成小白，初步去感受競品的不足，并思考潛在的機會。

通過以上兩步，就能給出用戶畫像了。簡單的理解，用戶畫像就是真實用戶的虛擬化表達，但具備了真實用戶的典型特征，以此為基礎，產品經理就要從用戶和需求的分析中加工出用戶需求了。

需求分析的步驟

從事需求分析以來，不管是自己參與的或是完全由自己一個人需求調研的，也有過大大小小項目需求調研的經歷。這周去了深圳某券商進行了為期一周的需求調研，需求調研完成之后，其實總結下來有些套路可以使用。

如果把IT比做一個江湖，無論是什么公司什么業務的需求，練好這個武功心法“四層五步五清法”，可以從宏觀上以及部分微觀上理解用戶的需求。之所以說是部分微觀，是因為具體的需求，還得具體的分析，但練好這個武功心法，在需求分析的宏觀上可以說沒有問題。

對于需求分析人員從宏觀上做需求調研的時候，需要弄清楚這四個層次(對于一般的需求分析人員弄清楚前面兩個層次也是可以的)。

分析用戶需求的四個層次

四層：

1.第一層職能層：梳理各部門的職能。

一個系統如果涉及到很多部門，那么梳理各部門的職能能幫助我們去理解他們提出需求的原因，甚至通過了解各部門的職能反過頭去質疑其他部門提出的需求。

舉一個很簡單的例子，某券商的風控部牽頭要建設信用風險管理系統，為實現監管的“同一客戶，同一業務，統一管理”，風控部將其他業務部門也納入到系統中來，在需求調研階段，某業務部門提出在實現一個報表查詢到時候，需要部門與部門的權限隔離，即固收部的看固收部的持倉數據，其他部門在看同一張報表的時候看不了固收部的持倉數據。

咋一聽這個需求提的很合理，但是風控部的職能是從公司整體上控制風險并防范風險，風控部可以看所有業務部門的數據。

用戶提需求的時候只是出于自身考慮，并沒有想到其他部門，所以當需求涉及多個部門的時候，需求分析人員在需求調研階段把各部門的職能弄清楚。

2.第二層業務層：梳理業務。

沒有人會無緣無故去購買一個系統，對于企業而言購買系統就是想將公司的業務放在系統上去做。不同類型的企業或不同部門，業務是不一樣的，業務的復雜程度決定了系統的復雜程度，若一個復雜的業務能夠被梳理的邏輯清晰條理清晰，系統也不會很復雜，但前提是你很懂很懂業務。

當一個業務小白如何快速的理解業務，可以搜集業務相關的名詞解釋，弄懂這些名詞算四分之一理解業務。每種業務都會有其特定的術語，比如在物流行業，你需要知道什么是貨代、郵路、頭程、預報等等，在金融行業，你需要知道什么是股票質押、債券投資、融資融券、資管計劃，除此還不夠，你需要理解透每一個業務以及業務與業務的差別，比如股票質押與融資融券的差別在哪?

3.第三層數據層：梳理信息。

這需要需求分析人員懂一些技術才能梳理清楚，對需求分析人員很高要求的一個層次。對于系統的底層數據，需要梳理數據與數據的流向，數據與數據的邏輯關系，這些都梳理清楚以后，對于現在的開發或是以后的迭代都能起到很大的作用。

4.第四層：梳理支撐環境。

業務需求以及數據都弄清楚以后，還需要考慮非功能性的需求，比如系統的硬件環境和軟件環境是什么，用谷歌瀏覽器還是IE瀏覽器等。

以上是四層五步法的四層，如何去實現上面的四層，做到以下“五步”：

根據組織結構梳理職能域，比如機構/部門的職能，各崗位的工作職責

根據職能域梳理業務元素，包括業務術語、名詞解釋等

根據業務元素梳理業務活動，如業務流程、業務環節、狀態、信息等

根據業務活動梳理業務等內外聯系，如業務協作、信息流向

描繪業務架構、信息架構，如用戶分類、業務分類、信息分類

四層和五步做到以后，問自己幾個問題，看看是否真正的理解需求：

業務對象清楚了沒有?系統的用戶以及各功能模塊的用戶是誰是否清楚。

業務流程清楚了沒有?各環節的處理人以及處理動作是否清楚。

業務場景清楚了沒有?每個需求的業務場景是否弄清楚，所有需求的業務場景是否能連接在一起，在腦海中完整的形成一個故事。

業務事項數量清楚了沒有?一共有多少個需求，一共有多少種角色，一共有多少張報表，一共有多少個前置條件……

跨部門的業務關系清楚了沒有?這個部門與那個部門的關系以及產生的哪些業務往來是否清楚。

四層五步五清法都做到以后，你可以把一個需求故事的大綱弄明白，再加上具體細節的需求分析(請查看之前的文章有寫如何去分析不同類型的需求)，把細節填充在需求故事的大綱里面，一個完整的故事就出來了。

需求分析人員能把一個需求故事從頭到晚每一處都講清楚，在需求的把控上大體上不會出錯，要知道需求要是錯了，后果是很嚴重的。