一．項(xiàng)目管理

1.項(xiàng)目管理定義

項(xiàng)目管理是項(xiàng)目的管理者，在有限的資源約束下，運(yùn)用系統(tǒng)的觀點(diǎn)、方法和理論，對(duì)項(xiàng)目設(shè)計(jì)的全部工作進(jìn)行有效地管理。即從項(xiàng)目的投資決策開(kāi)始到項(xiàng)目結(jié)束的全過(guò)程進(jìn)行計(jì)劃、組織、指揮、協(xié)調(diào)、控制和評(píng)價(jià)，以實(shí)現(xiàn)項(xiàng)目的目標(biāo)。 項(xiàng)目經(jīng)理：PM（Project Manager）。

?項(xiàng)目經(jīng)理特性：(1)目標(biāo)驅(qū)動(dòng)：按質(zhì)按量的達(dá)成目標(biāo)； (2)系統(tǒng)思維：系統(tǒng)的思維，有項(xiàng)目管理的方法和理論； (3)風(fēng)險(xiǎn)意識(shí)：風(fēng)險(xiǎn)意識(shí)，如能夠判斷研發(fā)代碼隱藏的問(wèn)題、能通過(guò)需求知道實(shí)現(xiàn)風(fēng)險(xiǎn)； (4)數(shù)據(jù)量化：拿數(shù)據(jù)說(shuō)話，通過(guò)數(shù)據(jù)量化是否達(dá)到目標(biāo)。

2.開(kāi)發(fā)模式

開(kāi)發(fā)模式有：瀑布開(kāi)發(fā)、敏捷開(kāi)發(fā)、螺旋開(kāi)發(fā)等。主要講瀑布開(kāi)發(fā)模式和敏捷開(kāi)發(fā)模式。

瀑布開(kāi)發(fā)模式，是一種比較傳統(tǒng)的軟件開(kāi)發(fā)模式。瀑布開(kāi)發(fā)是一個(gè)剛性的線性模型，其中包括順序階段（要求、設(shè)計(jì)、實(shí)時(shí)、驗(yàn)證、維護(hù)），其中每一個(gè)階段的目標(biāo)性很明確，而且在進(jìn)入下一個(gè)階段之前，每個(gè)階段目標(biāo)必須100%的完成，但這種模式如果進(jìn)行回溯修改時(shí)會(huì)比較麻煩。

敏捷式開(kāi)發(fā)，以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開(kāi)發(fā)。通過(guò)迭代開(kāi)發(fā)，關(guān)注互動(dòng)溝通等方法來(lái)降低軟件開(kāi)發(fā)過(guò)程中的風(fēng)險(xiǎn)，同時(shí)也可以減少在開(kāi)發(fā)中的資源消耗。好處是通過(guò)早期發(fā)現(xiàn)和修復(fù)缺陷來(lái)提高開(kāi)發(fā)的效率。

互聯(lián)網(wǎng)中常見(jiàn)的開(kāi)發(fā)模型-敏捷開(kāi)發(fā)。 互聯(lián)網(wǎng)的項(xiàng)目多以敏捷開(kāi)發(fā)為主。敏捷開(kāi)發(fā)的核心理念是以簡(jiǎn)單有效的方式快速達(dá)成目標(biāo)，并在這個(gè)過(guò)程中及時(shí)響應(yīng)外界的變化，做出調(diào)整。

二．互聯(lián)網(wǎng)產(chǎn)品研發(fā)管理全流程

互聯(lián)網(wǎng)產(chǎn)品研發(fā)項(xiàng)目主流程，分三大階段：需求階段、開(kāi)發(fā)階段、發(fā)布階段，這樣一個(gè)Round一個(gè)Round循環(huán)。

1.需求階段

需求階段包括，需求準(zhǔn)備、需求內(nèi)審、需求評(píng)審會(huì)、需求定稿。

(1)需求準(zhǔn)備

(2)需求內(nèi)審

內(nèi)部的評(píng)審，如果有多個(gè)產(chǎn)品經(jīng)理或者多個(gè)需求，進(jìn)行X.X版本需求內(nèi)審，評(píng)定需求優(yōu)先級(jí)、評(píng)定需求可行性。評(píng)審后，確定X.X版本的需求。

(3)需求評(píng)審會(huì)

需求評(píng)審會(huì)由產(chǎn)品經(jīng)理發(fā)起，介紹產(chǎn)品功能背景及設(shè)計(jì)方案擺在臺(tái)面上進(jìn)行討論P(yáng)K，直到形成統(tǒng)一結(jié)論的過(guò)程。

目的：明確項(xiàng)目目標(biāo)、了解方案、排憂解難、眾志成城。

參與對(duì)象：開(kāi)發(fā)人員、測(cè)試人員、設(shè)計(jì)師、運(yùn)營(yíng)人員、產(chǎn)品經(jīng)理。

評(píng)審內(nèi)容：版本Feature List、基本交互原型 。版本Feature List：要做什么？為什么要做這些？ ?基本交互原型：方案是否靠譜？做到什么程度？

可能出現(xiàn)的問(wèn)題？立場(chǎng)不同、觀點(diǎn)不一、進(jìn)入細(xì)節(jié)、一站到底、以己概全、開(kāi)會(huì)分神、效率低下、時(shí)間太長(zhǎng)。?解決思路：求同存異、學(xué)會(huì)挖掘背后、放過(guò)細(xì)節(jié)、從深往前拉、核心討論可行性、日后再說(shuō)、適度休息、每個(gè)需求提醒、相關(guān)人員、控制時(shí)間、主持人特權(quán)。

會(huì)議總結(jié)：及時(shí)輸出會(huì)議紀(jì)要、待討論問(wèn)題責(zé)任明確到人、會(huì)后跟蹤、私下討論。

(4)需求定稿

求同存異。 產(chǎn)品經(jīng)理的原則與調(diào)性：產(chǎn)品經(jīng)理需要有自己的原則，以及愿意為此負(fù)責(zé)的擔(dān)當(dāng)與自信，對(duì)需求足夠把握的時(shí)候，該強(qiáng)勢(shì)的需要強(qiáng)勢(shì)；當(dāng)然，該聽(tīng)的意見(jiàn)要聽(tīng)。

2.研發(fā)階段

產(chǎn)品在研發(fā)階段的定位：了解并推進(jìn)進(jìn)度、確保發(fā)布時(shí)間、監(jiān)督進(jìn)度、解決問(wèn)題、調(diào)整與優(yōu)化、確保產(chǎn)品與預(yù)期一致、需求變更同步、上下溝通、確保信息一致。

研發(fā)階段，包括開(kāi)發(fā)時(shí)間評(píng)估、測(cè)試用例評(píng)審、迭代開(kāi)發(fā)、產(chǎn)品驗(yàn)收、測(cè)試。

開(kāi)發(fā)階段常見(jiàn)問(wèn)題：1）需求打折(功能比想象中復(fù)雜、做不完、真要做完趕不上發(fā)版。 了解下真正原因，加加班、激勵(lì)、溝通，挖掘下背景)；2）無(wú)法實(shí)現(xiàn)（分析下原因。比如，開(kāi)發(fā)不能實(shí)現(xiàn)，找出競(jìng)品可以實(shí)現(xiàn)，怎么辦呢？我們能不能攻攻關(guān)。 遇到這兩種情況下，我們?cè)趺崔k呢？）不能研發(fā)說(shuō)不能實(shí)現(xiàn)就不能實(shí)現(xiàn)。

(1)開(kāi)發(fā)時(shí)間評(píng)估

需求評(píng)審會(huì)后，開(kāi)發(fā)Leader組織同步結(jié)果給到產(chǎn)品。 輸出結(jié)果：對(duì)應(yīng)每個(gè)需求的人/日。 產(chǎn)品經(jīng)理：適度評(píng)估時(shí)間準(zhǔn)確性，有預(yù)留風(fēng)險(xiǎn)的預(yù)判。

(2)測(cè)試用例評(píng)審

測(cè)試用例評(píng)審主要針對(duì)研發(fā)和測(cè)試，產(chǎn)品經(jīng)理在初期參與。完善需求的異常邏輯及邊界情況。

(3)產(chǎn)品體驗(yàn)與測(cè)試

產(chǎn)品體驗(yàn)，偏向正向的邏輯，至少基本流程能測(cè)通。如果產(chǎn)品體驗(yàn)都不能通過(guò)，直接打回去重做。產(chǎn)品體驗(yàn)通過(guò)后再進(jìn)行測(cè)試開(kāi)測(cè)。

產(chǎn)品經(jīng)理，確保開(kāi)發(fā)實(shí)現(xiàn)的功能與你的預(yù)期一致。 測(cè)試人員，確保功能在各種場(chǎng)景下都可正常使用。

?體驗(yàn)與測(cè)試階段的問(wèn)題：體驗(yàn)產(chǎn)品發(fā)現(xiàn)大量細(xì)節(jié)不符合預(yù)期。 測(cè)試人員反饋： 這個(gè)功能會(huì)造成性能的卡頓，有可能造成不少OOM的問(wèn)題。這里存在一個(gè)致命的bug，不同意發(fā)布。 這時(shí)怎么辦？判斷什么樣的bug，是否為主要功能的bug？

3.發(fā)布階段

發(fā)布階段，包括三面的工作內(nèi)容：項(xiàng)目方面、產(chǎn)品層面、運(yùn)營(yíng)層面。 項(xiàng)目方面：灰測(cè)（1測(cè)、2測(cè)）、Check List ?產(chǎn)品層面：上線前版本驗(yàn)收、準(zhǔn)備FAQ&客服手冊(cè) ?運(yùn)營(yíng)層面：發(fā)布渠道準(zhǔn)備、運(yùn)營(yíng)推廣計(jì)劃

?(1)灰測(cè)

灰測(cè)是在版本穩(wěn)定后，讓少部分用戶參與提前體驗(yàn)，達(dá)到發(fā)現(xiàn)隱藏問(wèn)題的目的。怎么定義？什么范圍？怎么實(shí)現(xiàn)？Why？ BUG Review ?嚴(yán)重：嚴(yán)重級(jí)別bug，視情形確定是否發(fā)布。 中等：視情況排入修復(fù)版本。 體驗(yàn)/小BUG：產(chǎn)品經(jīng)理跟進(jìn)。

(2)發(fā)布準(zhǔn)備

Check List& 發(fā)布評(píng)審會(huì)：一般由測(cè)試或者項(xiàng)目經(jīng)理擬定，各方負(fù)責(zé)人確定并打鉤。 產(chǎn)品驗(yàn)收：確保產(chǎn)品的基本功能與需求是一致的，無(wú)核心問(wèn)題的、確保產(chǎn)品的交互及UI符合設(shè)計(jì)要求、建議對(duì)照需求文檔來(lái)驗(yàn)收。

可能的問(wèn)題：驗(yàn)證不通過(guò)。嚴(yán)重級(jí)別bug太多；基本功能與預(yù)期不一致。 若Bug較多，但非嚴(yán)重性質(zhì)的bug，且版本的基本功能重要，可發(fā)布，但需要盡快發(fā)布修復(fù)版本。 若Bug較多，且有嚴(yán)重級(jí)別的bug，需要根據(jù)出現(xiàn)場(chǎng)景及頻率來(lái)判斷。 若有嚴(yán)重級(jí)別的bug且是核心流程或功能，不可發(fā)布。

客服培訓(xùn)：上線前將新增/修改的功能同步至客服、教客服如何使用，方便解答用戶疑問(wèn)、產(chǎn)品經(jīng)理也需要周期性的做客服工作。

更新FAQ：將新功能常見(jiàn)的疑問(wèn)寫成文檔補(bǔ)充至FAQ，F(xiàn)AQ用H5實(shí)現(xiàn)。

?(3)上線/提交應(yīng)用市場(chǎng)

發(fā)布，確定適合發(fā)布的日期和時(shí)間。需要注意的點(diǎn)，發(fā)布后至少留1個(gè)小時(shí)已確保服務(wù)文檔，協(xié)助客服處理緊急問(wèn)題，適當(dāng)給與關(guān)懷。群的維護(hù)以及核心用戶通知。

發(fā)布渠道管理與上傳，維護(hù)好發(fā)布渠道ID，確保渠道包正常使用。

提示升級(jí)，有三類：強(qiáng)制升級(jí)、提示升級(jí)、自動(dòng)升級(jí)。 強(qiáng)制升級(jí)：有重大問(wèn)題，阻礙試功能上線。 提示升級(jí)：重要版本。 自動(dòng)升級(jí)：常規(guī)版本。

發(fā)送上線郵件，郵件內(nèi)容： 告知xx版本xx日期發(fā)布了；展示：主功能特性；跟進(jìn)：告知后續(xù)跟進(jìn)計(jì)劃。

數(shù)據(jù)匯報(bào)，上線后進(jìn)行數(shù)據(jù)匯報(bào)。為什么要匯報(bào)？匯報(bào)哪些內(nèi)容？領(lǐng)導(dǎo)需要安全感，團(tuán)隊(duì)需要鼓勵(lì)及反饋；項(xiàng)目需要有始有終。 匯報(bào)時(shí)間：上線一周后，第一個(gè)月 匯報(bào)方式：郵件。匯報(bào)內(nèi)容：基礎(chǔ)數(shù)據(jù)變化，版本覆蓋率、新增/優(yōu)化功能數(shù)據(jù)變化、核心功能情況（對(duì)比同一時(shí)段）、后續(xù)規(guī)劃等。

(4)用戶反饋

收集用戶反饋，評(píng)估優(yōu)先級(jí)。重要不緊急的進(jìn)入需求池，緊急的進(jìn)入bug缺陷修復(fù)。

?(5)需求池

做好需求池需求管理，做好版本規(guī)劃。