策劃經理面試需要有哪些技巧呢，大家有面試策劃經理的經驗可以分享嗎?以下是本站小編為大家整理的關於，希望大家喜歡!
1、充分練習
因為各種主動，被動的原因，跳過幾次槽。我沒裸辭過，所以剛開始就只是挑合適的公司面，但後來發現，明明是你心動的公司，卻與你失之交臂。我也有精心準備過，但很多時候因為行業與圈子的關係，認識總是會有短板的。看到到這點後，在今後的找工作中，我跑得比較勤，多收集面試問題，多準備。據我的經驗證明，每次面試下來，無論成功與否，都會有些問題值得你再三斟酌。每個用人單位都會有自己考量人才的角度，如果你能把方方面面的問題梳研究透，相信面試成功機率能大大提高。
這裡有個例子，公司有個技術員，出去找工作。人家整理了份面試200題，後來真的找了份薪資不錯的工作，他manager跟我說，他絕對是個面試水平大於他真實工作水平的人。可見面試總結是多麼重要。
2、準備套路
從HR處得到有用資訊。當你收到HR的面試邀請電話時，除了HR給你的面試資訊外，我們還可以問：職位在組織架構中的位置，所在團隊規模，大概負責什麼樣專案。這樣可以幫你快速瞭解到JD上了解不到的資訊。
認真研究JD，每家公司性質不一樣，所以對專案經理要求也不一樣。我們在研讀JD的時候，基本可以看出在這家單位裡，專案經理扮演什麼樣的角色，如有些注重專案管理，有些注重需求，有些注重售前，有些注重程式碼能力。所以不同方向的JD要準備不同的內容。
研究公司相關資料，包括從公司主頁瞭解主營內容，從各種職業網站看一些評價。好有一些思想準備。相信大家都懂的。
自我介紹，要簡潔重點。專案經驗以數字總結，如果有特別出名的，可以點名。能力方面，最好跟JD匹配。離職原因，相信每個HR都會問的，所以我就先想好個理由直接說了。
3、常見問題
總結了幾個常見問題的回答思路。
怎樣控制需求變更?
在專案中，需求變更問題最為突出。但對待需求變更的態度，不能一概而論。可遵循瞭解-變更-分析-評估-控制的原則。
瞭解：瞭解變更的業務細節，即功能變化，然後瞭解使用者背後的真實用意。
分析：分析需求變更的原因，我總結了以下四種：
1.使用者經驗不足，專案組人員對業務也不熟悉，使用者提不出合理需求，專案組也無法給出專業的意見。這種情況，在試執行的時候，會有個需求爆發期。
2.使用者見異思遷，隨時有新想法。
3.沒有抓住關鍵專案關係人，遺漏重要需求。
4.客觀因素的改變：關聯絡統升級，換領導，縮短工期，預算減少等。
評估：評估需求的重要性，難易度，緊急度，及變更對專案的影響。從PMBOK理論來看專案管理有四個制約因素：時間，質量，範圍，成本。如果不做，可以從需求是否是偽需求(把列印輸出從Excel換成PDF, 只是為了讓使用者不能修改)，或者無關緊要的需求(網站要好幾套面板)來指出對時間，質量，範圍，成本的影響。如果需求變更確定要做，必定是以犧牲這四者的一個或若干個為前提的。這個一定要跟使用者說清楚，並得到認可的。
控制：其實就是流程的控制了，詳見下一個問題。
怎樣實施需求變更?
PMBOK中需求變更控制流程：
瞭解變更{獲得正式書面的.變更請求}
綜合評估變更影響
準備處理變更的方案
通知專案干係人
批准或拒絕變更
更新專案管理計劃和專案檔案
通知受變更影響的干係人
跟蹤變更的實施情況
在沒有系統學習這些理論之前，我有些點做到了，但往往又忽略了些你以為不重要的東西。而正是這些細節，在後面影響了專案進度。所以這些步驟，必須爛熟於心。舉個例子：
我現在負責一個硬體裝置專案的專案。在我們裝置裡有一個晶片，由美國Team來開發，每次韌體升級也有走正規的需求變更管控流程。但升級歸升級，卻沒人來通知過我們。以至於測試組在做測試的時候，晶片crash的頻率很高。後來我們跟美國團隊溝通，人家說我們這塊晶片要求的韌體最低版本是118，你們現在的是98，當然不行!關鍵是，沒人通知過我們啊。這種問題就是因為沒有通知受變更影響的干係人引起的。因此強調下上面的變更控制流程每一步都有存在的必要性。
怎樣做專案實施?
專案實施經常進行不順利，其實就是系統試執行，沒人願意用。對甲方負責人來說，單位花了那麼多錢，確沒給單位帶來效益的提高，這個壓力很大。對乙方單位來說，如果系統沒人用，以後就沒回頭生意了，所以專案實施很重要。
對此，首先試執行前要做好充分測試，保證系統質量;其次爭取最高領導的支援;做好甲方單位操作人員，維護人員的培訓;要準備好試執行方案，包括各種輔助管理制度，應急預案等。
這裡兩個小提示，1、培訓不僅僅是開個大會培訓就好了，培訓會結束後，各種溝通渠道走起來。甚至需要深入一線。後期服務的到位，才能讓系統健康執行起來。2、在系統上線前，專案組可以先放一批資料到系統裡，有了資料的系統就有生命。在深入一線時，可以用這些資料生成各種報表，讓工作人員認識到，系統的好處。
公司產品很多，業務部門都提需求，都說自己的需求很重要。產品經理那需求堆積如山，開發進度嚴重拖後，開發人員身心疲憊。如何讓有限的開發團隊來面對無限的業務需求呢?
這個問題來源於合資網際網路公司，我覺得這個應該是產品經理怎麼來確定需求的優先順序的問題。如果產品經理沒有很好的業務知識來判斷需求的重要級別，優先級別，那我們就用資料說話。把需求都記錄下來，問問需求提出者，這個需求做完後能產生什麼效益。讓對方給個數據，再把這個資料跟績效掛勾。順便提下，現在很多稍大的私企工資都是跟績效掛勾的。外企也有，但是隻影響年終獎，但是私企的話，直接影響當月工資或季度獎金，而季度獎很多都是從月薪的一部分。所以有了績效考核制度，相信部門提需求時，會三思而行，這樣需求質量也會高很多。
最後，提醒下平時工作中要注意總結歸納，專案結束後做好經驗教訓總結。關於最成功的，最有挑戰的，學到最多的專案都選一個代表專案出來。面試嘛，就像考試一下，掌握幾種經典題型，總能以不變應萬變的。