比如：異常流程、頁面的缺省狀態(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)品的總體信息結(jié)構(gòu)，也就是產(chǎn)品涉及到的全部字段。
服務端開發(fā)可以通過參考你的字段表，很便捷地創(chuàng)建數(shù)據(jù)結(jié)構(gòu)，開發(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ā)。
一旦技術(shù)難點在開發(fā)階段才被發(fā)現(xiàn)，那將極大加劇項目延期的風險。
都說產(chǎn)品經(jīng)理要懂點技術(shù)，這里就可以派上用場。
評審前，提前預估技術(shù)難點，評審中遇到技術(shù)難點，停下來，讓負責的開發(fā)注意一下。
能在會上評估就在會上評估掉，如果真的比較復雜，會后讓開發(fā)做一下技術(shù)調(diào)研，再排期。
這樣給出的排期在項目進度上相對可控。
如果評估出來發(fā)現(xiàn)技術(shù)難點的開發(fā)量遠超預期，那就要考慮下需求的性價比，是否有替代方案，是否轉(zhuǎn)為迭代需求等？
如果整個項目的開發(fā)量遠超預期，那就考慮根據(jù)需求的優(yōu)先級，將項目劃分成多期開發(fā)。
2.環(huán)節(jié)進度可交叉
設計—>服務端開發(fā)—>客戶端開發(fā)，它們不是一條流水線，一個環(huán)節(jié)完成才能進入下一個環(huán)節(jié)，環(huán)節(jié)進度是可以相互交叉的。
這樣做的好處是：盡可能在一段時間內(nèi)，充分利用資源。
簡單來講就是：誰都別閑著。
舉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ā)。
在一個中大型項目中，項目例會很有必要，多方可以及時同步信息，暴露問題。
項目例會的頻率，可以根據(jù)項目周期、干系人多少，靈活調(diào)整。
如果項目到達一個里程碑，很有必要在項目例會上向大家宣告目前已經(jīng)拿下的戰(zhàn)果，鼓舞士氣。
2.需求變更
遇到變更，首先考慮必要性。
如果影響到主流程，不改不行；果斷同步給相關開發(fā)，說明變更原因，評估變更額外增加的開發(fā)量以及對項目進度的影響。
如果是體驗上的優(yōu)化，考慮移入迭代需求。
對于產(chǎn)品經(jīng)理來說，完成比完美更重要。
死摳細節(jié)，只會加劇項目風險，同時你在項目成員心目中的靠譜值也會被蠶食殆盡。
一旦確定變更納入到本次項目中，將變更記錄到文檔中，說明變更內(nèi)容、變更原因、負責人等。
3.提前同步項目風險
遇到項目中可能的延期，提前向項目干系人同步項目風險，說明延期原因。
等到已成既定事實再同步，產(chǎn)品可能不自覺就成背鍋俠了。
產(chǎn)品驗收主流程就行，細節(jié)交給測試。
將驗收過程中發(fā)現(xiàn)的問題匯總再交給開發(fā)，集中處理bug效率更高。
如果bug一個個提，他們肯定煩。
2.UI驗收的優(yōu)先級
驗收和測試時間充裕的話，UI驗收可以和產(chǎn)品驗收同時進行。如果時間緊張，UI可放到最后驗收，先把流程和邏輯測好。完成比完美更重要，你懂的。
及時同步上線信息給項目干系人，并感謝項目成員的辛苦付出，這既是一個交代，也是對他們付出的肯定。
2.成果通報
項目有實質(zhì)性成果，及時通報，成員的士氣會得到極大提振，你在項目成員心目中的靠譜值會上升一點點。
如果成果顯著，向上級申請項目獎金，請項目成員出去搓一頓，你的靠譜值會飆升。
