把項(xiàng)目理解成一件事兒，則項(xiàng)目管理由三要素組成：對象（人或者資源）、時(shí)間、事
明確什么人在什么時(shí)間做什么事情，為進(jìn)度和結(jié)果負(fù)責(zé)。目標(biāo)是做成這件事兒，相關(guān)支持是人、資源、時(shí)間。
把項(xiàng)目管理分為兩個部分：
做什么——需求管理
怎么做——項(xiàng)目規(guī)劃及執(zhí)行
需求管理：要做的事兒從哪兒來？是什么？怎么分？什么時(shí)候做？
注意：一定反復(fù)確認(rèn)原始需求，保證理解的正確性
需求來源：
PM關(guān)于需求的采集需要有明確的時(shí)間點(diǎn)和對接人，常見的需求來源有以下幾個渠道：
老板：
弄清楚老板意圖很重要?。。】赡苁请S口提的，可能只是想法或建議，或者老板覺得必須要做的（不排除我們的level無法理解老板的意圖:(）產(chǎn)品經(jīng)理直接或間接收到老板的需求，要慎重抉擇衡量之后及時(shí)給老板反饋：
*如果可行--給出排期（包含所需成本）
*如果不可行--給出不可行原因（性價(jià)比或者技術(shù)原因等）及其他替代方案
*勇敢說不--老板可能只是隨口提起，如果方案性價(jià)比不高，一定要給出自己的建議及原因
PS：一定一定要正確理解老板的需求！不要似是而非，不要想當(dāng)然！
用戶：
用戶的需求大多來源與用戶調(diào)研或者用戶反饋，產(chǎn)品經(jīng)理需要在正確理解需求的基礎(chǔ)上，明確需求的必要性（詳見下文用戶需求KANO模型）
運(yùn)營：
運(yùn)營同學(xué)可能也會提一些功能性需求，此時(shí)需要產(chǎn)品同學(xué)進(jìn)行抉擇后與運(yùn)營同學(xué)溝通并給與反饋（運(yùn)營需求的收集也需要周期性進(jìn)行匯總~）
產(chǎn)品內(nèi)部：
產(chǎn)品經(jīng)理內(nèi)部根據(jù)產(chǎn)品發(fā)展階段、參考競品、數(shù)據(jù)結(jié)果反饋等渠道提出新的需求，沒啥好說的，內(nèi)部做好溝通~
技術(shù)：
研發(fā)同學(xué)提出的需求一般包含兩個方面，
a:本身的技術(shù)優(yōu)化或者bug修復(fù)（這個產(chǎn)品同學(xué)明確好排期與優(yōu)先級，技術(shù)同學(xué)定技術(shù)方案即可）
b：研發(fā)人員可能會說，我覺得XX需求是不是可以這樣做（他們會從技術(shù)+用戶的角度提出建議或者意見），此類需求，產(chǎn)品明確必要性之后做出解釋或者抉擇~
測試：
測試同學(xué)會從”細(xì)節(jié)+邏輯+用戶“的角度，提出他們會覺得哪種用戶體驗(yàn)更好，可能包含一些邏輯上的漏洞建議，功能或者技術(shù)上的建議，當(dāng)然更多的是指出bug，總之還是悉心聽取并有選擇的采納
商務(wù)：
還有商務(wù)同學(xué)，（可能會比較強(qiáng)硬：（? ）
由于業(yè)績壓力，商務(wù)同學(xué)會說送給我加廣告，XX地方都加上，這個時(shí)候要進(jìn)行決策與衡量（保體驗(yàn)or保收入，有些決定需要問題上浮才能夠定的哈~）
總之：
1.需求收集需要有周期性的安排和規(guī)劃
2.收集需求時(shí)，一定要反復(fù)確認(rèn)，避免理解偏差
3.虛心聽取，認(rèn)真考量，及時(shí)反饋，相信大家都是抱著對產(chǎn)品好的態(tài)度提出的需求，無論是否可行，都要認(rèn)真對待并給出反饋（重視每一個需求和提出人）
4.記得，還可以問題上浮！
建立需求池：明確格式，及時(shí)更新
簡單說來，需求池就是對收集的需求進(jìn)行記錄和管理，包含需求描述、來源、狀態(tài)等，不同公司需求池的格式不同，通常用excel或者騰訊文檔等進(jìn)行記錄，重點(diǎn)就是及時(shí)更新（比較瑣碎的工作）
需求分析：需求優(yōu)先級定義
需求分類：
常見需求細(xì)分如下（需求分類有助于確認(rèn)需求所需資源并定義需求優(yōu)先級）
UX：用戶體驗(yàn)型需求，例如觸區(qū)調(diào)整，流轉(zhuǎn)動畫等
UI：設(shè)計(jì)優(yōu)化，例如更換啟動圖、調(diào)整icon大小
功能型需求：與業(yè)務(wù)相關(guān)，例如增加頁面或調(diào)整邏輯，增加模塊等
運(yùn)營需求：一般與運(yùn)營對象相關(guān)，例如活動的處理或者分發(fā)樣式的處理等
數(shù)據(jù)需求：一般由運(yùn)營同學(xué)或產(chǎn)品經(jīng)理提出，常見于數(shù)據(jù)上報(bào)
技術(shù)需求：技術(shù)同學(xué)提出，代碼優(yōu)化、結(jié)構(gòu)調(diào)整、控件更換或者bug修復(fù)等
商業(yè)化：常見于廣告等
確定需求優(yōu)先級：
優(yōu)先級的定義需要結(jié)合項(xiàng)目所處階段、需求來源（老板的需求要慎重對待）、需求重要性&緊急程度、需求所需的資源支持（人力、機(jī)器、時(shí)間等）、需求可能帶來的收益評估等多方面因素綜合考量。
確定項(xiàng)目所處階段：
項(xiàng)目處于不同階段，有不同的北極星指標(biāo)，這個指標(biāo)可能時(shí)隨著數(shù)據(jù)表現(xiàn)和業(yè)務(wù)發(fā)展不斷變化及調(diào)整的，我們的需求一般需要圍繞著提升北極星指標(biāo)展開。（例如：小說類應(yīng)用，項(xiàng)目發(fā)展初期的北極星指標(biāo)可能是有閱讀的人數(shù)比例，或者是有效閱讀（閱讀超過XX章節(jié)）的人數(shù)比例，圍繞這個指標(biāo)，讓有閱讀的用戶閱讀更多<——更多用戶產(chǎn)生閱讀<——激起用戶的閱讀欲望<——用戶能夠見到或者找到自己想要閱讀的書<——優(yōu)化分發(fā)，就是結(jié)合項(xiàng)目所處階段，確定北極星指標(biāo)，并以此逐層遞進(jìn)拆解需求的過程）
需求重要性：
一般使用”四象限法則“確認(rèn)需求的重要程度，同時(shí)結(jié)合”KANO模型“確定需求的必要性和緊急程度。
四象限法則：
1.重要并緊急：此類需求若以版本為節(jié)點(diǎn)，一般不超過3個，否則表示項(xiàng)目管理出現(xiàn)了問題
2.重要不緊急：可提前調(diào)研，提前規(guī)劃，合理排期即可
3.不重要但緊急：常見于小bug修復(fù)
4.不重要也不緊急：在做好需求池管理
PS：明確上述的緊急和重要是針對整個項(xiàng)目而不是針對產(chǎn)品部門??！
用戶需求KANO模型：
基本（必備）型需求——我可能不用，但你不能沒有
當(dāng)優(yōu)化此需求，用戶滿意度不會提升，當(dāng)不提供此需求，用戶滿意度會大幅降低；
期望（意愿）型需求——我想要用，所以你不能沒有
當(dāng)提供此需求，用戶滿意度會提升，當(dāng)不提供此需求，用戶滿意度會降低；
興奮（魅力）型需求—你沒有我也沒啥想法，你有了這個功能，我會覺得哎呦還不錯
用戶意想不到的，如果不提供此需求，用戶滿意度不會降低，但當(dāng)提供此需求，用戶滿意度會有很大提升；
無差異型需求——這個功能有沒有我不在乎
無論提供或不提供此需求，用戶滿意度都不會有改變，用戶根本不在意；
反向（逆向）型需求——我不喜歡有這個功能的應(yīng)用
用戶根本都沒有此需求，提供后用戶滿意度反而會下降
需求評估：
需求評估一般是在確定需求重要度的基礎(chǔ)上，結(jié)合需求所需要的資源和成本，評估需求的性價(jià)比和優(yōu)先級，我們當(dāng)然希望用最小的投入得到最大的產(chǎn)出。一般評估之后，可以將需求劃分為：
a.重要需求：以發(fā)版為節(jié)點(diǎn)的重要需求，必須做的
b.分支需求：重要需求，但是需要耗費(fèi)較多資源，則分支做，并在規(guī)定時(shí)間內(nèi)合并至主版本
c.分散型隨版需求：常見于項(xiàng)目初期，存在很多的UX優(yōu)化點(diǎn)，而此時(shí)項(xiàng)目版本迭代較快（可能1-2周），則可以每一周隨版一些優(yōu)化需求
d.持續(xù)分支需求：重要不緊急需求，需要較長時(shí)間段的調(diào)研和準(zhǔn)備，一般分為調(diào)研、方案討論、執(zhí)行幾個部分
=========================分割線=============================
項(xiàng)目規(guī)劃及執(zhí)行
確認(rèn)了需求優(yōu)先級之后，以版本為單位進(jìn)行項(xiàng)目管理，項(xiàng)目執(zhí)行過程還包含以下環(huán)節(jié)：
需求設(shè)計(jì)：產(chǎn)品同學(xué)完成需求文檔及需求原型（需求原型用最簡單的線框圖，以免影響設(shè)計(jì)同學(xué)），一般需至少提前1-2個版本進(jìn)行規(guī)劃
UI設(shè)計(jì)：一般需求文檔及原型圖完成之后，需要進(jìn)行UI設(shè)計(jì)，有的公司也會放在需求評審之后（不過用UI圖進(jìn)行評審更加準(zhǔn)確）產(chǎn)品同學(xué)需要將功能目的和重要性同步設(shè)計(jì)同學(xué)，以便設(shè)計(jì)同學(xué)進(jìn)行排期及正確設(shè)計(jì)
需求評審：叫上所有相關(guān)人員一起開會吧~，會議時(shí)間要控制，以圖說話，開發(fā)及測試注意點(diǎn)提前說明，具體規(guī)則及細(xì)節(jié)見文檔。一定要hold住場面，不要掉進(jìn)細(xì)節(jié)陷阱，畢竟大家的時(shí)間和寶貴——產(chǎn)品需要盡可能的完善文檔和規(guī)則
需求排期：(需求工作量預(yù)估）需求評審后，需要給出排期，方便項(xiàng)目安排，排期包含
? ? a.服務(wù)端排期(執(zhí)行過程中，一般至少提前客戶端半個版本）
? ? b.客戶端排期（接口已提供/數(shù)據(jù)已通/模擬假數(shù)據(jù)）
需求開發(fā)：（一般服務(wù)端提前半個開發(fā)周期，保證客戶端接口可用）
需求測試：測試（服務(wù)端、客戶端）
需求上線：服務(wù)端上線、客戶端灰度、客戶端大發(fā)版
開啟升級（建議或強(qiáng)制）
以上版本規(guī)劃為理想情況，一般來說，真是的發(fā)布過程中，一定會有根據(jù)之前版本的數(shù)據(jù)表現(xiàn)所需要進(jìn)行的需求調(diào)整，或者會插入一些緊急需求。開發(fā)過程中也會遇到一些不可抗因素，需要屆時(shí)進(jìn)行取舍。
項(xiàng)目管理執(zhí)行--明確時(shí)間點(diǎn)、風(fēng)險(xiǎn)點(diǎn)、信息同步、取舍（延期or砍功能）
項(xiàng)目執(zhí)行過程中的注意點(diǎn)：
1.項(xiàng)目開始前明確大家目標(biāo)一致性，解釋功能和目的（例如本階段我們的主要目標(biāo)是提升新用戶留存，所以功能重點(diǎn)在優(yōu)化新用戶分發(fā)）
2.項(xiàng)目開始時(shí)，保證需求理解一致性??！所有！所有相關(guān)人員的需求理解一定要一致！
3.資源的合理協(xié)調(diào)：確定什么人怎么做，做多久（產(chǎn)品同學(xué)需要對相關(guān)人員，特別是研發(fā)和測試的能力和習(xí)慣有一定的認(rèn)知，便于合理 安排時(shí)間）
4.信息同步非常重要！開發(fā)過程及時(shí)跟進(jìn)，問題及時(shí)提出，風(fēng)險(xiǎn)及時(shí)報(bào)備！
5.目標(biāo)及時(shí)調(diào)整（取舍）：一個關(guān)于延期or砍功能or尋找代替方案的問題，一般來說是之前步驟沒有做好留下來的坑，但是無可避免
6.人員的鼓勵（看人下菜碟）----對項(xiàng)目相關(guān)成員的預(yù)期與考量（能力、質(zhì)量、時(shí)長等），兼職鼓勵師吧！
7.項(xiàng)目目標(biāo)驗(yàn)證：主要看數(shù)據(jù)--崩潰率、功能數(shù)據(jù)表現(xiàn)、核心指標(biāo)數(shù)據(jù)表現(xiàn)
8.及時(shí)總結(jié)
