項目管理本質上是在管理信息和人，如何將正確的信息在正確的時間點傳達到正確的人，是一門學問。本文將從項目管理的5個環(huán)節(jié)入手，分別介紹每個環(huán)節(jié)要注意的事項。
一、需求文檔
1. 異常狀態(tài)
比如：異常流程、頁面的缺省狀態(tài)、數(shù)據(jù)的溢出空值狀態(tài)等。這些異常狀態(tài)，如果在開發(fā)階段才被發(fā)現(xiàn)，你就不得不向開發(fā)做需求澄清，向設計師要求補充UI，他們可能臉上笑嘻嘻，心里MMP，項目進度也很有可能受到影響。
以前看過一句話，產(chǎn)品經(jīng)理腦海中的需求變更，才是成本最小的需求變更。因此，及時在需求文檔階段標明異常狀態(tài)。個人認為，需求文檔寫得最理想的狀態(tài)是，任何人但凡有任何需求上的疑惑，你就把需求文檔甩給他看，他就懂了。
2. 動態(tài)數(shù)據(jù)
產(chǎn)品界面上的數(shù)據(jù)分靜態(tài)和動態(tài)2種，靜態(tài)數(shù)據(jù)一般是客戶端寫死，動態(tài)數(shù)據(jù)一般是接口傳的。對于界面的動態(tài)數(shù)據(jù)，可以單獨列一個表格，標明數(shù)據(jù)名稱、數(shù)據(jù)格式以及數(shù)據(jù)的溢出空值狀態(tài)。
如果是比較大的項目，可以用Xmind列出產(chǎn)品的總體信息結構，也就是產(chǎn)品涉及到的全部字段。服務端開發(fā)可以通過參考你的字段表，很便捷地創(chuàng)建數(shù)據(jù)結構，開發(fā)接口，從而加快項目進度。
3. 數(shù)據(jù)指標、埋點需求
臨到項目上線才想起要數(shù)據(jù)埋點，而具體埋什么數(shù)據(jù)不知道，導致數(shù)據(jù)埋點不準確或不全面，效果評估大打折扣，對于一個項目來說是比較打擊士氣的。這其實是缺乏數(shù)據(jù)意識的體現(xiàn)，為了需求而需求，不知道需求要達成什么目的，也就不知道衡量目的的數(shù)據(jù)指標，也就不知道生成數(shù)據(jù)指標的數(shù)據(jù)埋點該怎么做。
理想的解決方案，在需求文檔階段，首先明確衡量需求的數(shù)據(jù)指標，思考一下指標可以通過什么數(shù)據(jù)生成？
通過集成的第三方數(shù)據(jù)統(tǒng)計工具就可以，那就確保統(tǒng)計工具可用。通過數(shù)據(jù)庫保存的字段就可以，那就注意第2項中的動態(tài)數(shù)據(jù)。如果必須通過數(shù)據(jù)埋點才行，那就將埋點需求納入需求文檔，作為需求的一部分提給開發(fā)。
二、技術評審、排期
1. 技術難點
一旦技術難點在開發(fā)階段才被發(fā)現(xiàn)， 那將極大加劇項目延期的風險。都說產(chǎn)品經(jīng)理要懂點技術，這里就可以派上用場。評審前，提前預估技術難點，評審中遇到技術難點，停下來，讓負責的開發(fā)注意一下。能在會上評估就在會上評估掉，如果真的比較復雜，會后讓開發(fā)做一下技術調研，再排期。這樣給出的排期在項目進度上相對可控。
如果評估出來發(fā)現(xiàn)技術難點的開發(fā)量遠超預期，那就要考慮下需求的性價比，是否有替代方案，是否轉為迭代需求等？
如果整個項目的開發(fā)量遠超預期，那就考慮根據(jù)需求的優(yōu)先級，將項目劃分成多期開發(fā)。
2. 環(huán)節(jié)進度可交叉
設計—>服務端開發(fā)—>客戶端開發(fā)，它們不是一條流水線，一個環(huán)節(jié)完成才能進入下一個環(huán)節(jié)，環(huán)節(jié)進度是可以相互交叉的。這樣做的好處是，盡可能在一段時間內，充分利用資源。簡單來講就是，誰都別閑著。
舉2個例子：
- 例1：設計師可以先設計出整體的UI框架，把界面上元素的位置、尺寸定好，就能給到客戶端開發(fā)了，然后再設計icon、banner等相對耗時的元素，客戶端到時候替換一下即可。
- 例2：服務端開發(fā)有了需求文檔，也可以著手開發(fā)數(shù)據(jù)庫、接口和管理后臺。數(shù)據(jù)庫和接口可以先開發(fā)，讓客戶端先接起來，有問題能及時暴露。接口很多，則可以按照產(chǎn)品模塊分批給。至于管理后臺的功能，開發(fā)通過底層數(shù)據(jù)庫也能實現(xiàn)，因此優(yōu)先級可以往后，放到數(shù)據(jù)庫和接口穩(wěn)定后再開發(fā)。
三、開發(fā)
1. 項目例會
在一個中大型項目中，項目例會很有必要，多方可以及時同步信息，暴露問題。項目例會的頻率，可以根據(jù)項目周期、干系人多少，靈活調整。如果項目到達一個里程碑，很有必要在項目例會上向大家宣告目前已經(jīng)拿下的戰(zhàn)果，鼓舞士氣。
2. 需求變更
遇到變更，首先考慮必要性。如果影響到主流程，不改不行，果斷同步給相關開發(fā)，說明變更原因，評估變更額外增加的開發(fā)量以及對項目進度的影響。如果是體驗上的優(yōu)化，考慮移入迭代需求。
對于產(chǎn)品經(jīng)理來說，完成比完美更重要。死摳細節(jié)，只會加劇項目風險，同時你在項目成員心目中的靠譜值也會被蠶食殆盡。
一旦確定變更納入到本次項目中，將變更記錄到文檔中，說明變更內容、變更原因、負責人等。
3. 提前同步項目風險
遇到項目中可能的延期，提前向項目干系人同步項目風險，說明延期原因。等到已成既定事實再同步，產(chǎn)品可能不自覺就成背鍋俠了。
四、產(chǎn)品驗收、UI驗收、測試
1. bug收集
產(chǎn)品驗收主流程就行，細節(jié)交給測試。將驗收過程中發(fā)現(xiàn)的問題匯總再交給開發(fā)，集中處理bug效率更高。如果bug一個個提，他們肯定煩。
2. UI驗收的優(yōu)先級
驗收和測試時間充裕的話，UI驗收可以和產(chǎn)品驗收同時進行。如果時間緊張，UI可放到最后驗收，先把流程和邏輯測好。完成比完美更重要，你懂的。
五、上線
1. 上線通報
及時同步上線信息給項目干系人，并感謝項目成員的辛苦付出，這既是一個交代，也是對他們付出的肯定。
2. 成果通報
項目有實質性成果，及時通報，成員的士氣會得到極大提振，你在項目成員心目中的靠譜值會上升一點點。如果成果顯著，向上級申請項目獎金，請項目成員出去搓一頓，你的靠譜值會飆升。
本文由 @ 產(chǎn)品微醺 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載
題圖作者提供
版權聲明：本文內容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。