比如：异常流程、页面的缺省状态、数据的溢出空值状态等。
这些异常状态，如果在开发阶段才被发现，你就不得不向开发做需求澄清，向设计师要求补充UI，他们可能脸上笑嘻嘻，心里MMP，项目进度也很有可能受到影响。
以前看过一句话，产品经理脑海中的需求变更，才是成本最小的需求变更。
因此，及时在需求文档阶段标明异常状态。
个人认为，需求文档写得最理想的状态是：任何人但凡有任何需求上的疑惑，你就把需求文档甩给他看，他就懂了。
2.动态数据
产品界面上的数据分静态和动态2种，静态数据一般是客户端写死，动态数据一般是接口传的。
对于界面的动态数据，可以单独列一个表格，标明数据名称、数据格式以及数据的溢出空值状态。
如果是比较大的项目，可以用Xmind列出产品的总体信息结构，也就是产品涉及到的全部字段。
服务端开发可以通过参考你的字段表，很便捷地创建数据结构，开发接口，从而加快项目进度。
3.数据指标、埋点需求
临到项目上线才想起要数据埋点，而具体埋什么数据不知道，导致数据埋点不准确或不全面，效果评估大打折扣，对于一个项目来说是比较打击士气的。
这其实是缺乏数据意识的体现——为了需求而需求。
不知道需求要达成什么目的，也就不知道衡量目的的数据指标，也就不知道生成数据指标的数据埋点该怎么做。
理想的解决方案，在需求文档阶段，首先明确衡量需求的数据指标，思考一下指标可以通过什么数据生成？
通过集成的第三方数据统计工具就可以，那就确保统计工具可用。
通过数据库保存的字段就可以，那就注意第2项中的动态数据。
如果必须通过数据埋点才行，那就将埋点需求纳入需求文档，作为需求的一部分提给开发。
一旦技术难点在开发阶段才被发现，那将极大加剧项目延期的风险。
都说产品经理要懂点技术，这里就可以派上用场。
评审前，提前预估技术难点，评审中遇到技术难点，停下来，让负责的开发注意一下。
能在会上评估就在会上评估掉，如果真的比较复杂，会后让开发做一下技术调研，再排期。
这样给出的排期在项目进度上相对可控。
如果评估出来发现技术难点的开发量远超预期，那就要考虑下需求的性价比，是否有替代方案，是否转为迭代需求等？
如果整个项目的开发量远超预期，那就考虑根据需求的优先级，将项目划分成多期开发。
2.环节进度可交叉
设计—>服务端开发—>客户端开发，它们不是一条流水线，一个环节完成才能进入下一个环节，环节进度是可以相互交叉的。
这样做的好处是：尽可能在一段时间内，充分利用资源。
简单来讲就是：谁都别闲着。
举2个例子：
例1：设计师可以先设计出整体的UI框架，把界面上元素的位置、尺寸定好，就能给到客户端开发了，然后再设计icon、banner等相对耗时的元素，客户端到时候替换一下即可。
例2：服务端开发有了需求文档，也可以着手开发数据库、接口和管理后台。
数据库和接口可以先开发，让客户端先接起来，有问题能及时暴露。
接口很多，则可以按照产品模块分批给。
至于管理后台的功能，开发通过底层数据库也能实现，因此优先级可以往后，放到数据库和接口稳定后再开发。
在一个中大型项目中，项目例会很有必要，多方可以及时同步信息，暴露问题。
项目例会的频率，可以根据项目周期、干系人多少，灵活调整。
如果项目到达一个里程碑，很有必要在项目例会上向大家宣告目前已经拿下的战果，鼓舞士气。
2.需求变更
遇到变更，首先考虑必要性。
如果影响到主流程，不改不行；果断同步给相关开发，说明变更原因，评估变更额外增加的开发量以及对项目进度的影响。
如果是体验上的优化，考虑移入迭代需求。
对于产品经理来说，完成比完美更重要。
死抠细节，只会加剧项目风险，同时你在项目成员心目中的靠谱值也会被蚕食殆尽。
一旦确定变更纳入到本次项目中，将变更记录到文档中，说明变更内容、变更原因、负责人等。
3.提前同步项目风险
遇到项目中可能的延期，提前向项目干系人同步项目风险，说明延期原因。
等到已成既定事实再同步，产品可能不自觉就成背锅侠了。
产品验收主流程就行，细节交给测试。
将验收过程中发现的问题汇总再交给开发，集中处理bug效率更高。
如果bug一个个提，他们肯定烦。
2.UI验收的优先级
验收和测试时间充裕的话，UI验收可以和产品验收同时进行。如果时间紧张，UI可放到最后验收，先把流程和逻辑测好。完成比完美更重要，你懂的。
及时同步上线信息给项目干系人，并感谢项目成员的辛苦付出，这既是一个交代，也是对他们付出的肯定。
2.成果通报
项目有实质性成果，及时通报，成员的士气会得到极大提振，你在项目成员心目中的靠谱值会上升一点点。
如果成果显著，向上级申请项目奖金，请项目成员出去搓一顿，你的靠谱值会飙升。
