軟件開發：對於產品經理須要哪些平常工做嗎

       

      對於想作軟件開發的企業來講，產品想法很重要，這影響着產品怎麼實現。一個產品的出現源於一個想法，怎麼讓想法變成具體的東西，這個就須要產品經理或者有很好規劃的人員來完成。那麼從事軟件開發工做的產品經理有哪些平常工做呢，小編來爲你們分享分享。

      1、用戶調研

     用戶調研分爲定性分析和定量分析。定性分析是指用戶訪談，定量分析是指調查問卷。

     用戶訪談。固然訪談須要必定的技巧，更多的傾聽爲主，以瞭解用戶的心裏想法爲主。訪談時對用戶的初步回答反覆追問「爲何」，引導用戶從表面的行爲開始思索，清理出行爲背後的動機、需求乃至價值和文化觀念。

     調查問卷。問卷調查是一項有目的的研究實踐活動，設計的問卷是爲你的特定研究目的服務的，這是設計問卷以前必須植根於腦海中的一個觀念。既然問卷調查是一項有目的的研究實踐活動，那麼從理論指導實踐的角度出發，在設計問卷前必需要作好充足的理論準備，宏觀層面上應作到如下兩點：

     1.明確大家研究的主題是什麼？

     2.明確大家想經過問卷調查獲取的信息有那些。經過調研問卷你能夠定量的驗證你提出的需求。

     2、需求的收集，創建本身的需求池

     收集各個部門的需求，創建本身的需求池。並按期對需求池進行整理。你的需求池裏面有不一樣人提出的需求。

     需求來源：需求池裏面有可能包含老闆提出的戰略性需求、客服反饋的需求、用戶訪談得來的需求、調查問卷得來的需求、數據分析得來的需求。記錄好每一個人提出的需求，這樣當你在作需求分析的時候若是不知道需求後面的本質需求，你能夠找到那我的進行了解,這樣有助於你把握需求的本質。

      按期對需求池作必定的梳理。產品部門按期讀需求池進行整理，那些需求是下一步要作的，那些需求是是能夠暫緩的，那些需求是不作的，對需求池進行梳理和分類。

      不一樣終端的需求要分開。分爲APP、PC、微官網、前臺、控臺這些。

     3、產品迭代前寫一份立項報告

     經過對需求池的整理之後，你決定要作那些不作那些。須要出一份立項報告和技術部門過一下，這樣技術能夠安排開發週期。技術也能夠從技術的角度給一些意見說那些能夠作，那些能夠暫時不作，這樣技術在開發以前有一個心理預期，這樣在你開原型評審會的時候阻力會小不少。這裏教給你們一個小技巧：作立項報告的時候能夠多寫一些需求，這樣多一些的需求能夠給技術砍掉。

      4、競品分析

      俗話說知己知彼，百戰不殆。你作的東西別人也在作，買東西都還須要貨比三家呢。作競品分析有兩個目的，第1、揚長避短。吸引別人作的長處，發現別人作的不足的地方。第2、驗證與測試。別人上的這個功 能市場反饋怎麼樣，有沒有遇到啥問題，經過競品肯定市場機會點。

      競品分析有必定的流程。能夠從「戰略層-範圍層-結構層-框架層-表現層」這幾個層面進行分析。

      (1).戰略層：肯定競品的商業模式、產品定位、市場情況、盈利狀況等，目的是肯定方向，瞭解市場。

      (2).範圍層：競品的目標人羣，知足了什麼需求，用戶的滿意度如何，目的是參考競品的目標人羣以及需求的重要度。

      (3).結構層：競品的主要功能架構、特點功能、發展模式，優缺點總結，目的是尋求差一點。

     (4).框架層：競品主要任務流程的順暢，交互的細節，邏輯的準確，頁面的框架，目的是優化流程，提升用戶體驗。

     (5).表現層：競品是視覺風格，顏色層級，文案的運用等，目的是維持用戶對這類產品的傳統認知的基礎上打造產品獨特性。

     5、原型評審和PRD文檔製做

     競品分析作完之後，開始根據競品分析的結果。開始本身的功能設計，流程的繪製，在原型上加一些功能的註釋，這樣在敏捷開發的時候能夠節省PRD文檔的製做，也能夠在和技術開會的時候不會遺漏本身想講的東西。

     原型評審的時候技術人員的有效意見必定要虛心接受，不要以爲本身是產品就高高在上，涉及到原則問題堅持。別人提的有益意見也要虛心接受，只有這樣你才能避免死逼，項目才能儘快落地。至於PRD文檔的制 做。有時間的話能夠寫word文檔，沒時間的話能夠直接在原型中製做文檔。

     但文檔必須包含的部分有：

     (1).產品版本的迭代歷史。清晰的告訴項目成員每次改變都改了那些東西。

     (2).需求功能清單。有需求功能清單 的時候技術人員在開發的時候纔不會遺漏，測試工程師也會根據你的需求功能單來進行測試。

     (3).全局結構圖和重要的功能流程圖不能少。全局結構圖。產品全局結構圖至關於房子的骨架，至關於文章的目錄，別人看過你的全局結構圖就知道你的產品大概分紅那幾個部分。其次，一些重要的功能流程圖須要寫，這樣有助於開發人員思路的創建。

     (4).異常流程要考慮清楚。只有異常流程考慮清楚產品經理纔不會挨批，技術開發起來纔不會出現問題。

     (5).重要名詞要定義。對於首次出現的名詞須要定義，這有這樣別人在看到名字的時候纔不會有疑問，再跑來找你問。

     6、項目管理

     項目進度表。文檔交給技術開發之後，就須要制定一個項目時間表，並向領導彙報。首先要全面地收集他們在聽完需求文檔評審後對於產品自己的意見與建議，而後逐項予以合理的解釋，以保證程序員哥哥們打心底裏認同這個產品，認同這個產品的每個需求。另外做爲一個PM，也應該要對基本的開發流程有所瞭解在制定每一個需求的開發週期時提出正確的建議，保證最終的項目開發時間表既不會拖慢整個項目的進度，也沒有超出程序員哥哥們天天正常的工做量，保證他們不會感到過大的開發壓力。

      進度跟蹤。對於項目進度要作到心中有數，天天更新項目進度表，並幫助技術解決他們在開發過程當中遇到的問題，並將本身看到的潛在問題儘可能扼殺在萌芽中。固然，跟進並非每天問工程師進度，須要給他們鼓勵打氣，並描述產品的將來前景，讓團隊中的每個人都感覺到本身的重任並願意承擔。可能有些團隊裏面是CTO擔任項目經理，這也無可厚非，畢竟在項目成員中程序員佔了大半資源，固然產品經理要儘可能參與這個過程中。不能當局外人。

     7、產品上線前協助測試

     大公司有明確的職位分工：工程師、測試、設計、運營都由不一樣的人負責，測試天然是測試工程師的事，而在中小型創業公司，人員匱乏，不少團隊只有工程師和產品經理，工程師負責開發，開發之外的事情全都由產品經理承包，這 其中天然包括測試。但不管如何產品經理都要儘可能參與測試工做，保證產品是按照你的預期作出來的。

     (1).首先與測試組溝通協做，肯定產品測試排期。

     (2).跟進測試進度參與產品測試。

     (3).將測試出來的bug記錄下來，並拍好優先級，反饋給技術來發人員。

     功能測試是合格產品經理的必備素質，產品經理要協助測試工程師完成測試報告並敦促工程師團隊改進產品。

     8、產品培訓和推廣

     給業務方培訓、推廣產品。客服可能須要給用戶解答問題，因此每次迭代的內容都須要給客服培訓，好讓客服組織話術來應對客戶隨之而來的一些問題。同時也須要給市場、運營等部門培訓，讓他們知道產品到了那些階段，有那些改變，一是讓各個部門之間知道本身正在作的事情，二也好讓營銷市場部門作好宣傳與推廣。

     收集產品使用反饋，爲迭代作準備。產品上線後設計的好很差，有哪些用戶滿意的，有那些用戶不滿意的。都會有用戶進行反饋，收集並分析這些用戶需求，並記錄在你的需求池裏面，爲下一次迭代作準備

     9、數據分析

     產品上線後產品設計的好壞很大程度上能從數據上體現出來。例如你設計個活動分享頁面，用戶能夠經過好友分享的界面直接註冊，那麼你就要統計這個頁面的點擊量、PV/UV、頁面訪問市場、訪問深度、用戶的跳出率、用戶的轉化率等來評估你設計的好壞，以及活動的效果。再好比你產品進行改版，你須要評估改版的好壞。你就須要關注30日留存率提升了仍是下降了，別關注7日留存率。由於你的產品剛更新你的粉絲用戶可能會很活躍，致使7日留存率變高，這個時候你說你的改版比較成功可能沒有說服力，也許30日之後你的用戶活躍度變低了，30日留存率也變低了。

     10、總結

     以上大概就是從事軟件開發產品經理的平常工做內容，每一個公司可能根據本身的不一樣狀況有些流程會有增減，但基本上是這些。軟件開發過程當中產品經理在項目研發中起着重要的角色，影響着產品的質量、時間、整個過程的完成度。