的越全面，在后面的开发中才会越顺利。
在经过缓冲期后，程序猿们基本已经对项目的工作量了然于胸了，这时程序猿往往会提出一些建议，出现最多的情况有以下两种：
程序猿希望对需求提出异议（比如页面交互，以及部分流程）；
程序猿希望砍掉部分需求。
针对第一点，我们一定要耐心听完程序猿修改需求的理由。
千万不要觉得需求分析是自己的职能，他们提建议是在多管闲事；想把一件事做到面面俱到是很难的，有时候程序猿提的点子正好是你没想到的地方。
当出现这种情况时，不要着急给答复；回去将程序猿给出的方案和之前自己的方案仔细对比一下，选出一个最优的。
如果你觉得程序猿给出的建议更好，那么就采纳程序猿的建议，同时更新文档并告知其他团队人员。
如果是第二点，那么就要分情况讨论了：
如果是不那么重要的需求，可以放在下个版本，如果是自己本身也模棱两可的需求，那么直接砍掉就好了；
但如果是核心需求，那么坚决不砍，绝不让步，核心需求是下个版本最重要的部分，是万万砍不得的。
当把工作量弄清楚以后，下一步就是确认开发顺序和开发时间。
2. 确认开发顺序
这里主要需要确认的就是先开发哪些功能模块，后开发哪些功能模块，这里注意，有了开发顺序才能进行项目排期。
在确认开发顺序的时候，我们仍然要和项目经理进行充分沟通，明确本次开发中有溢出风险的模块，也就是说出了问题会严重影响其他模块乃至整个产品上线的地方。
举个栗子：
假如我这次做的是一个智能穿戴设备的APP，那么最有溢出风险的模块是哪个呢？
不是注册登录，也不是数据显示，而是设备与手机进行蓝牙连接的模块：
注册登录我们可以用第三方登录来解决，如果数据展示因为工期问题做不完，我们也可以砍掉部分展示数据以保证按时上线；但蓝牙设备连接是不可能砍的，这是智能穿戴设备功能的基础。
所以说，蓝牙设备连接就是有溢出风险的模块；在开发顺序中一定要放在前面，这样我们就可以先对蓝牙连接模块进行测试，这样出现问题时可以提前解决，不会影响其他功能。
3. 确认开发时间
当确定好开发顺序后，我们就可以根据开发顺序来确认每个模块的完成时间了。
用甘特图是一个不错的选择——制作甘特图的时候，我们需要定任务，确职责；在表中我们要写明任务，负责人，起止时间，以避免后期的扯皮。
而在开发过程中，前端在进行框架选取及页面开发的时候，是不需要后端提供数据的，在后端进行数据库设计以及编写接口的时候，也是不需要UI设计师切图的——因此，前端开发和后端开发是可以并行的。
如下图所示：后端的横向柱状图空缺的部分，是留给他们进行接口调试和bug修改的。
上图这张甘特图只是举例，在实际的工作中，可以按每个模块来划分，将核心的、高风险的模块向程序猿重点说明，在开发的过程中也要更细致的跟进。
如果项目有明确的截止时间，那么我们就根据截止时间来倒推每个模块的完成时间。
如果时间实在不够，砍需求吧，程序猿们会感激你的。
三、项目跟进
经过前期的工作，我们终于把事情推进到开发阶段了，那么产品经理在开发过程中会很轻松么？
当然不是，我们要对产品的结果负责，当然要对项目进行跟进。
1. 鳟鱼和桥梁
在项目跟进的过程中，我们虽然对敲代码没有发言权，但是我们要时刻清楚地知道项目动态，并作为程序猿们沟通的桥梁，遇到问题时要协调相关人员进行沟通，像鳟鱼一样提高团队的积极性和效率。
项目动态我们可以用每日站立会的方法来进行。
站立会表面听起来是开会，但是实际上我们不需要拘泥于开会的地点和形式，我们可以在每天早晨刚到公司的时候和程序猿沟通，也可以午休后在工位上进行，甚至一起上厕所的时候也可以。
开会的内容主要是昨天都做了什么，今天要做什么，遇到或者可能会遇到哪些问题；然后我们要积极的去协调，来帮助程序员解决问题。最好在程序猿开发某个模块之前与他进行需求再确认，以确保最终开发出来的东西是我们心中所想的那样。
在这个过程中，需要我们自身有主人翁意识，灵活而又勤快的去推动项目的进行。
2. 异常情况处理
虽然做足了准备，但还是经常会有异常情况出现，可能出现的异常情况有：
1）程序员对需求理解有
