項(xiàng)目管理本質(zhì)上是在管理信息和人，如何將正確的信息在正確的時(shí)間點(diǎn)傳達(dá)到正確的人，是一門學(xué)問。本文將從項(xiàng)目管理的5個(gè)環(huán)節(jié)入手，分別介紹每個(gè)環(huán)節(jié)要注意的事項(xiàng)。

一、需求文檔

1. 異常狀態(tài)

比如：異常流程、頁面的缺省狀態(tài)、數(shù)據(jù)的溢出空值狀態(tài)等。這些異常狀態(tài)，如果在開發(fā)階段才被發(fā)現(xiàn)，你就不得不向開發(fā)做需求澄清，向設(shè)計(jì)師要求補(bǔ)充UI，他們可能臉上笑嘻嘻，心里MMP，項(xiàng)目進(jìn)度也很有可能受到影響。

以前看過一句話，產(chǎn)品經(jīng)理腦海中的需求變更，才是成本最小的需求變更。因此，及時(shí)在需求文檔階段標(biāo)明異常狀態(tài)。個(gè)人認(rèn)為，需求文檔寫得最理想的狀態(tài)是，任何人但凡有任何需求上的疑惑，你就把需求文檔甩給他看，他就懂了。

2. 動(dòng)態(tài)數(shù)據(jù)

產(chǎn)品界面上的數(shù)據(jù)分靜態(tài)和動(dòng)態(tài)2種，靜態(tài)數(shù)據(jù)一般是客戶端寫死，動(dòng)態(tài)數(shù)據(jù)一般是接口傳的。對(duì)于界面的動(dòng)態(tài)數(shù)據(jù)，可以單獨(dú)列一個(gè)表格，標(biāo)明數(shù)據(jù)名稱、數(shù)據(jù)格式以及數(shù)據(jù)的溢出空值狀態(tài)。

如果是比較大的項(xiàng)目，可以用Xmind列出產(chǎn)品的總體信息結(jié)構(gòu)，也就是產(chǎn)品涉及到的全部字段。服務(wù)端開發(fā)可以通過參考你的字段表，很便捷地創(chuàng)建數(shù)據(jù)結(jié)構(gòu)，開發(fā)接口，從而加快項(xiàng)目進(jìn)度。

3. 數(shù)據(jù)指標(biāo)、埋點(diǎn)需求

臨到項(xiàng)目上線才想起要數(shù)據(jù)埋點(diǎn)，而具體埋什么數(shù)據(jù)不知道，導(dǎo)致數(shù)據(jù)埋點(diǎn)不準(zhǔn)確或不全面，效果評(píng)估大打折扣，對(duì)于一個(gè)項(xiàng)目來說是比較打擊士氣的。這其實(shí)是缺乏數(shù)據(jù)意識(shí)的體現(xiàn)，為了需求而需求，不知道需求要達(dá)成什么目的，也就不知道衡量目的的數(shù)據(jù)指標(biāo)，也就不知道生成數(shù)據(jù)指標(biāo)的數(shù)據(jù)埋點(diǎn)該怎么做。

理想的解決方案，在需求文檔階段，首先明確衡量需求的數(shù)據(jù)指標(biāo)，思考一下指標(biāo)可以通過什么數(shù)據(jù)生成？

通過集成的第三方數(shù)據(jù)統(tǒng)計(jì)工具就可以，那就確保統(tǒng)計(jì)工具可用。通過數(shù)據(jù)庫保存的字段就可以，那就注意第2項(xiàng)中的動(dòng)態(tài)數(shù)據(jù)。如果必須通過數(shù)據(jù)埋點(diǎn)才行，那就將埋點(diǎn)需求納入需求文檔，作為需求的一部分提給開發(fā)。

二、技術(shù)評(píng)審、排期

1. 技術(shù)難點(diǎn)

一旦技術(shù)難點(diǎn)在開發(fā)階段才被發(fā)現(xiàn)， 那將極大加劇項(xiàng)目延期的風(fēng)險(xiǎn)。都說產(chǎn)品經(jīng)理要懂點(diǎn)技術(shù)，這里就可以派上用場(chǎng)。評(píng)審前，提前預(yù)估技術(shù)難點(diǎn)，評(píng)審中遇到技術(shù)難點(diǎn)，停下來，讓負(fù)責(zé)的開發(fā)注意一下。能在會(huì)上評(píng)估就在會(huì)上評(píng)估掉，如果真的比較復(fù)雜，會(huì)后讓開發(fā)做一下技術(shù)調(diào)研，再排期。這樣給出的排期在項(xiàng)目進(jìn)度上相對(duì)可控。

如果評(píng)估出來發(fā)現(xiàn)技術(shù)難點(diǎn)的開發(fā)量遠(yuǎn)超預(yù)期，那就要考慮下需求的性價(jià)比，是否有替代方案，是否轉(zhuǎn)為迭代需求等？

如果整個(gè)項(xiàng)目的開發(fā)量遠(yuǎn)超預(yù)期，那就考慮根據(jù)需求的優(yōu)先級(jí)，將項(xiàng)目劃分成多期開發(fā)。

2. 環(huán)節(jié)進(jìn)度可交叉

設(shè)計(jì)—>服務(wù)端開發(fā)—>客戶端開發(fā)，它們不是一條流水線，一個(gè)環(huán)節(jié)完成才能進(jìn)入下一個(gè)環(huán)節(jié)，環(huán)節(jié)進(jìn)度是可以相互交叉的。這樣做的好處是，盡可能在一段時(shí)間內(nèi)，充分利用資源。簡單來講就是，誰都別閑著。

舉2個(gè)例子：

• 例1：設(shè)計(jì)師可以先設(shè)計(jì)出整體的UI框架，把界面上元素的位置、尺寸定好，就能給到客戶端開發(fā)了，然后再設(shè)計(jì)icon、banner等相對(duì)耗時(shí)的元素，客戶端到時(shí)候替換一下即可。
• 例2：服務(wù)端開發(fā)有了需求文檔，也可以著手開發(fā)數(shù)據(jù)庫、接口和管理后臺(tái)。數(shù)據(jù)庫和接口可以先開發(fā)，讓客戶端先接起來，有問題能及時(shí)暴露。接口很多，則可以按照產(chǎn)品模塊分批給。至于管理后臺(tái)的功能，開發(fā)通過底層數(shù)據(jù)庫也能實(shí)現(xiàn)，因此優(yōu)先級(jí)可以往后，放到數(shù)據(jù)庫和接口穩(wěn)定后再開發(fā)。

三、開發(fā)

1. 項(xiàng)目例會(huì)

在一個(gè)中大型項(xiàng)目中，項(xiàng)目例會(huì)很有必要，多方可以及時(shí)同步信息，暴露問題。項(xiàng)目例會(huì)的頻率，可以根據(jù)項(xiàng)目周期、干系人多少，靈活調(diào)整。如果項(xiàng)目到達(dá)一個(gè)里程碑，很有必要在項(xiàng)目例會(huì)上向大家宣告目前已經(jīng)拿下的戰(zhàn)果，鼓舞士氣。

2. 需求變更

遇到變更，首先考慮必要性。如果影響到主流程，不改不行，果斷同步給相關(guān)開發(fā)，說明變更原因，評(píng)估變更額外增加的開發(fā)量以及對(duì)項(xiàng)目進(jìn)度的影響。如果是體驗(yàn)上的優(yōu)化，考慮移入迭代需求。

對(duì)于產(chǎn)品經(jīng)理來說，完成比完美更重要。死摳細(xì)節(jié)，只會(huì)加劇項(xiàng)目風(fēng)險(xiǎn)，同時(shí)你在項(xiàng)目成員心目中的靠譜值也會(huì)被蠶食殆盡。

一旦確定變更納入到本次項(xiàng)目中，將變更記錄到文檔中，說明變更內(nèi)容、變更原因、負(fù)責(zé)人等。

3. 提前同步項(xiàng)目風(fēng)險(xiǎn)

遇到項(xiàng)目中可能的延期，提前向項(xiàng)目干系人同步項(xiàng)目風(fēng)險(xiǎn)，說明延期原因。等到已成既定事實(shí)再同步，產(chǎn)品可能不自覺就成背鍋俠了。

四、產(chǎn)品驗(yàn)收、UI驗(yàn)收、測(cè)試

1. bug收集

產(chǎn)品驗(yàn)收主流程就行，細(xì)節(jié)交給測(cè)試。將驗(yàn)收過程中發(fā)現(xiàn)的問題匯總再交給開發(fā)，集中處理bug效率更高。如果bug一個(gè)個(gè)提，他們肯定煩。

2. UI驗(yàn)收的優(yōu)先級(jí)

驗(yàn)收和測(cè)試時(shí)間充裕的話，UI驗(yàn)收可以和產(chǎn)品驗(yàn)收同時(shí)進(jìn)行。如果時(shí)間緊張，UI可放到最后驗(yàn)收，先把流程和邏輯測(cè)好。完成比完美更重要，你懂的。

五、上線

1. 上線通報(bào)

及時(shí)同步上線信息給項(xiàng)目干系人，并感謝項(xiàng)目成員的辛苦付出，這既是一個(gè)交代，也是對(duì)他們付出的肯定。

2. 成果通報(bào)

項(xiàng)目有實(shí)質(zhì)性成果，及時(shí)通報(bào)，成員的士氣會(huì)得到極大提振，你在項(xiàng)目成員心目中的靠譜值會(huì)上升一點(diǎn)點(diǎn)。如果成果顯著，向上級(jí)申請(qǐng)項(xiàng)目獎(jiǎng)金，請(qǐng)項(xiàng)目成員出去搓一頓，你的靠譜值會(huì)飆升。

本文由 @ 產(chǎn)品微醺 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖作者提供