作者：木木三（转载已取得作者授权）
在项目正式开发之前召开的会议有启动会议、需求评审会议、原型会议这三个会议。进入开发阶段后相继召开开发会议与发布前期会议；其实开发期间还有许多大大小小的需求变更会议。
一、启动会议
为了保证项目能够紧张有序的推动，项目启动会通过多次会议总结后才召集所有项目干系人参与，以达到短时间、高强度、高效率、群策群力完成对产品的第一次、也是最重要的一次决策，实现项目高周转。 会议要求发起人、客户和其他干系人参与启动过程可以建立对成功标准的共同理解，提升可交付成果的可接受性，提高客户和其他干系人的满意度。对于会议我们有自己严格的章程：
会前准备：确认会议时间、参会人员与会议内容后，将会议地点与时间还有会议阶段要准备的内容以邮箱的形式发送给每一位参会人员，并确认双方时间与实际到会人员名单，确认会议通知都送达。
参会人员： 会议主持人（项目发起人或产品部负责人参会人员）；董事长（必须参加第一次和最后一次会议）；公司总经理；产品部成员；项目发起人，项目团队相关成员；
会议召开方式：面对面办公。
注：启动会之前，针对项目预案，必须与部门关键人员提前沟通，以保证启动会方案报批通过，降低方案反复的风险。每次会议项目经理务必安排专人记录、整理会议纪要产品经理负责最终成果整理。启动会是我们对项目的判断和决策，是项目的其中一个阶段性成果。若由于市场变化或政府报批原因，预案、成本等被调整甚至颠覆，可直接反映在方案阶段成果中，不再重新召开启动会。
确定会议目标：
- 明确项目成功标尺及具体指标，达成共识、做出承诺。
- 对项目进行推演，设定项目的价值点、决策点、控制点。
- 识别项目风险点，提出预案。
- 启动会是职能向项目团队的交底会。
- 针对目标和工作范围做好减法，对意愿和能力、资源之间的差距应有清醒认识。
会议开始参会各方必须在参会前确认各自物料是否准备就绪：
发起人会前准备：
- 项目工作说明书（业务需求、产品范围描述、战略计划等）；
- 商业计划书（市场需求、组织需要、技术要求、团队介绍等）;
- 协议（定义项目初衷）;
产品部会前准备：
- 组织过程资产（历史信息与经验知识库）；
- 事业环境因素（质量标准、组织结构等）；
- 技术判断；
会议输出：
- 初步确定提交时间
- 定义初步范围和落实初步财务资源
- 确定责任人
- 确定审批流程
- 初步制定项目成功标尺
- 设定项目愿景—需要完成什么
- 明确市场定位、产品定位、项目范围和目标
- 最终输出项目章程并立项
若会议最终未达成共识，经双方协商一致，开展第二次项目启动会议或项目终止；
大型复杂的项目应该被划分为若干阶段，在此类项目中随后各个阶段也要进行启动过程，以便确认在最初的指定项目章程和识别干系人过程中所做出的决定是否依然有效。在每个阶段开始时进行启动过程，有助于保证项目符合预定的业务需要，核实成功标准，审查项目干系人的影响、动力和目标。然后决定该项目是继续、推迟还是中止。
二、需求确认会议
会议流程
产品项目需求会议
就产品开发而言，在设计开发之前必须先明确项目范围定义和优化目标以及需求，为实现目标制定行动方案用于指导项目的实施的项目管理计划和项目文件。
由于项目的复杂性，可能需要通过多次反馈来做进一步分析，随着收集和掌握的项目信息或特征不断增多，项目很可能需要进一步规划。
会前准备：
确认会议时间、参会人员与会议内容后，将会议地点与时间还有会议阶段要准备的内容以邮箱的形式发送给每一位参会人员，并确认双方时间与实际到会人员名单，确认会议通知都送达。并在会议开始前就准备好会议需要的文档与演示资料。
参会人员：
- 会议主持人：项目发起人或产品负责人
- 参会人员：公司总经理；产品部成员；项目团队相关成员；
会议召开方式：
- 如会议内未达成共识，需召开多次会议；
- 每次会后，分头收集信息，进行专业间碰撞
- 会议在会议室展开，会议地点双方协商决定
- 每场会议双方都需做会议纪要
会议目标
- 确定产品方向
- 识别项目风险点，提出预案
- 会议开始前业务部门应负责收集需求，产品团队通过会议获取需求，并依据需求确定产品范围；
- 双方会议前依据项目启动会议的对接情况进行竞品分析与用户调研；通过会议确定最终方向与定位。
- 双方收集需求讨论分析，最后根据需求制定WBS工作分解
业务团队会前准备：
- 收集用户需求
- 展开竞品分析与市场调研；
- 进行业务流程梳理；
产品部会前准备:
- 用户调研结论;
- 竞品分析结论；
- 产品范围管理；
- 初步的需求文档与信息架构；
- 一级界面布局；
- 产品的进度、项目风险分析、产品需求、成本预算、沟通计划、人力资源分配等各方面管理计划；
会议输出：
- 产品范围管理、
- 落实财务资源与预算
- 初步的进度确认
- 产品范围说明书
三、原型会议注：在时间允许的情况下，产品部需要将项目可交付成果划分为更小更详细的产品可核实的功能；会议结束后产品部项目负责人需要将最新的需求及时更新并依据会议结果制定需求变更表或新增需求表，以便项目成果可追溯。
产品原型会议
原型会议属于项目执行阶段的重要关键环节，关系到整个APP的运营、设计与开发过程。通过原型会议可以基本确认这个产品是否可以进入开发阶段，业务逻辑是否有问题等。
会前准备：
确认会议时间、参会人员与会议内容后，将会议地点与时间还有会议阶段要准备的内容以邮箱的形式发送给每一位参会人员，并确认双方时间与实际到会人员名单，确认会议通知都送达。并在会议开始前就准备好会议需要的文档与演示资料。
参会人员：
- 董事长，董事长助理，公司总经理；项目发起人及团队相关负责人；产品部成员；技术部负责人；
会议召开方式：
- 如会议内未达成共识，需召开多次会议；
- 会议在会议室展开，会议地点双方协商决定
- 每场会议双方都需做会议纪要
会议目标
- 业务依据产品原型设计核实流程是否正确；
- 技术部门依据原型初步估算整体进度；
- 产品部根据会议情况进行进度评估；
会前准备:
- 原型交互；
- UI根据原型与最初产品定位设计三套方案供分析；
会议输出：
- 产品原型流程确认；
- 设计方案确认；
注：进入原型阶段后，项目开展过程中有任何问题应该开小会议协商,及时解决,项目执行阶段需要实时监控项目进展的问题。
在原型会议后紧接着应该有一个设计确认会议。以下是设计确认会议流程图：
设计确认会议
设计确认会议是产品将UI设计整体进行展示此次会议主要就是审核设计质量与最终开发的交互成果。
会前准备
确认会议时间、参会人员与会议内容后，将会议地点与时间还有会议阶段要准备的内容以邮箱的形式发送给每一位参会人员，并确认双方时间与实际到会人员名单，确认会议通知都送达。并在会议开始前准备好UI设计稿以便展示。
参会人员
- 会议主持人：项目发起人或产品负责人
- 参会人员：项目发起人及团队相关负责人；产品部成员；
会议召开方式：会议在会议室展开，会议地点双方协商决定
会议目标
- 确定UI设计最终设计
- 初步确定可进入开发时间；
会前准备: UI设计稿;
会议输出：
- 确认时间节点；
- 设计稿最终确认；
- 切图标注
四、开发会议注：若UI方案已经确认，UI设计稿最终可产品部内部会议进行最终确认。UI设计员在此次会议开展后需要将标注、切图交付给相对应的开发人员。
开发会议：开发会议主要是进行难度的评估与开发进度管理，进行开发人员的分配与需求管理。
会前准备：
确认会议时间、参会人员与会议内容后，将会议地点与时间还有会议阶段要准备的内容以邮箱的形式发送给每一位参会人员，并确认双方时间与实际到会人员名单，确认会议通知都送达。
参会人员：
- 会议主持人：项目发起人或产品负责人
- 参会人员：董事长，董事长助理，公司总经理；项目发起人及团队相关负责人；产品部成员；技术部负责人；
会议召开方式：会议在会议室展开，会议地点双方协商决定
会议目标
- 确定开发进度管理；
- 技术难点分析；
- 项目开发优先级分析；
会前准备: 最终UI设计稿与交互原型、各个相关人员排期
会议输出：
- 确认开发的时间节点；
- 确定可进入开发时间
- 初步预测上线时间；
发布前会议: 开发人员开发好测试完毕后，在正式上线前开展一次项目演示会议，最终以双方满意作为产品上线的标准。
会前准备：
确认会议时间、参会人员与会议内容后，将会议地点与时间还有会议阶段要准备的内容以邮箱的形式发送给每一位参会人员，并确认双方时间与实际到会人员名单，确认会议通知都送达。
会议前需要设计好会议流程制订一张会议纪要表，并准备好录屏演示、讲解的ppt以及前期准备的所有文档与确认立项文档。
参会人员：
- 会议主持人：产品负责人
- 参会人员：董事长，董事长助理，公司总经理；项目发起人及团队相关负责人；产品部成员；
会议召开方式：
- 会议在会议室展开，会议地点双方协商决定；
- 多媒体功能会议室
会议目标
- 项目版本进入收尾阶段；
- 交付可交付成果；
会前准备:
- 录屏演示demo;
- 会议流程打印；
- 项目宣讲ppt；
- 前期所有相关文档；
- 确认函
会议输出：
- 确认函签字；
- 确定是否可以上线
以上是根据项目开展过程进行的流程开展的会议的总结，只针对新项目上线试用，如果项目已经上线就不需要这样的流程。以上流程图中的董事长为公司的总负责人。
以下附图产品部日常的一些工作流程，仅供参考：
项目沟通计划
项目负责人每周最少一次与业务团队进行项目沟通，通过与业务沟通提炼最新产品需求，并分析需求的优先级与重要程度决定是否需要新增需求。
新增需求：
如有新增或变更需求，需提交需求变更或需求新增审批件给董事长审批，如果是重大需求变更，需要召开需求变更会议。通过董事长审批即可进入项目执行阶段，详细流程参考本文第四章第3节至第5节原型—设计—开发—发布的流程执行。
审批未通过：
若董事长审批未通过，则需依据需求重新分析并修改新增需求方案或变更需求方案的审批件，再次循环审批流程。
无新增需求：
若没有新增需求或变更需求则将本次沟通做沟通纪要或沟通反馈。
循环变更需求例如：
- 输入：被批准变更请求A、B、C
- 输出：因为A、B、C的变化所引起的D、E、F、G的变更变化，为了让D、E、F、G也可以顺理成章的允许变更，所以要提出变更D、E、F、G的请求，等待批准。
- 循环结束条件1：所有D、E、F、G的变更都被批准，且皆为了满足A、B、C变更过所带来的连锁变动。
- 循环结束条件2：D、E、F、G所引起的H、I、J、K的变更也获得了批准，且皆为了最终满足A、B、C变更过所带来的连锁变动。
（可以理解为A、B、C为批准的变更请求源。D、E、F、G可理解为 因为A、B、C的变更被允许，所引起的其他一系列需要变更的变更，那么D、E、F、G提出后，需要再一次等待被批准后执行）
项目跟进
用户需求/反馈收集：
项目负责人根据项目上线情况及时收集用户反馈，并依据收集的需求做相对应分析与记录，如有变更需求需提交审批件，做相对应的功能改进；如果项目跟进过程中有重大的需求变更，需要召开需求变更会议并提交审批件由董事长审核；
数据跟踪：
定期进行数据查询与分析，根据现阶段数据情况及时分析反馈目前产品所存在的问题与需改进的地方，提出相对应的改进方案；
了解市场：
关注同行运营模式变化，实时关注市场动向，与业务部门保持密切的联系，根据市场运营情况，做出相对应的运营调整。
PS: 转发此篇文章到朋友圈或者是产品经理群，并截图发给微信chanpin628，可以找我领取一份完指定行业的PRD文档。
想学习更多关于产品、职场、心理、认知等干货，可长按右边二维码，关注我们。
面试一对一辅导
责任编辑：
