必备：日活千万AI＋产品手册.doc

　　必备：日活千万AI＋产品手册.doc

　　具体内容：分享调研内容，收集建议，确认feature及DEMO

　　对应产出：会议纪要

　　会议纪要组注意事项：主要包括时间、地点、人物、会议议题、讨论内容、会议结论、确定问题、遗留问题、后续计划及跟进人等。

　　会议纪要范例：

　　▍2.4 Kick off

　　具体内容：

　　特殊说明：并非所有项目均需进行，启动大型项目或重要并完整的新项目时进行kick off。

　　对应产出：会议纪要，确认PM、FE、RD、QA对应负责人，明确接口人，技术人员对应一个PM接口人。

　　▍2.5 资源引入

　　具体内容：商务合作需求，商务接口人

　　提出方式：邮件方式详细描述资源需求

　　资源需求要点：

　　对应产出：需求邮件及资源到位的情况。

　　▍2.6 UE效果图

　　具体内容：提请UE需求——UE接口人。

　　提出方式：邮件方式，将详细描述UE需求发出，附Demo图。若需交互设计师执行交互设计，请与交互设计师优选沟通，完成交互设计设计稿后交付视觉设计师执行。

　　UE需求要点：

　　UE需求沟通：

　　对应产出：邮件需求及UE效果图交互设计图。

　　▍2.7 PRD撰写

　　具体内容：输出产品详细需求文档，清晰描述产品功能逻辑，策略及统计需求。

　　对应产出：PRD，最终版本需上文档保管中心对应所立项目。

　　2.7.1 PRD定位

　　PRD受众：FE/RD/QA等。

　　PRD重点，需求的定义，而不是需求的实现。

　　2.7.2 清晰的结构

　　适当拆分：例如大型栏目，进行复杂功能改版，复杂产品管理后台的。

　　提供完整的流程：文字概述，流程图。

　　利用目录控制大局：目录不宜太细，且提供，链接指向相应页面，各级目录编号不建议使用：一、1、（1），推荐使用1、1.1、1.1.1。

　　突出重点：需要强调的内容，都用粗体，或不同的颜色标出，必要时使用截图，尽量用流程图，列表，对比等形式展现，避免大量文字模糊不清。

　　2.7.3 合理的顺序

　　根据用户的使用流程进行描述：适用于新的产品，入口-使用-退出。

　　根据功能的依赖关系：适用于产品的新功能，新升级，使用文字开锁或流程图。

　　使用表格和截图：对同类信息适当使用表格归纳，对承载很*敏*感*词*的页面应使用截图帮助理解。

　　2.7.4 完整的细节

　　用户状态的记录策略，如切换TAB，下次进入是否为其记录上次状态，这里特殊字符的限制，比如：定宽式样设计的字数上限。

　　各种错误的提示信息：所以PRD给出各种预期到的错误，详细错误号，及对应信息可由RD提供列表。

　　对其他产品的依赖及影响：是否需要其他产品提供支持或对其他产品构成影响。

　　2.7.5 严谨的措辞

　　不使用含糊词句：

　　不要和其他产品类比：例如：同开放平台改版保持一致等。

　　预期到会变动的地方需明确指出：预计后期升级的困难，帮助技术设计时考虑到可扩展性。

　　字数类描述：使用字节，不要使用字（防止理解不同、可用字进行补充说明）。

　　

　　必要的备注说明：提示信息必须明确真实文案，与需求描述文字区别显示。

　　2.7.6 变更需求

　　技术评审前：变更需求需要有版本记录，需要随版本号给出日期，各版本的修改内容，提供各版本PRD撰写人。

　　PRD修改记录示例：

　　技术评审后：

　　原则上不允许随意变更需求，除非有重大失误或影响用户体验方面可以变更需求，变更需求需要获得指导人确认后，召集项目相关同学沟通变更内容，口头达成一致后更新PRD，对应变更内容，需以批注形式标注。上传文档保存处，邮件通知项目相关同学PRD已更新及更新内容。

　　▍2.8 产品评审

　　具体内容：PM内部讨论及确定PRD及UE图。

　　争议处理：产品凭内部评审过程中，如遇到意见分歧的情况，可通过如下几个方法进行处理，用准确的数据说话，必要时可进行AB测试，线上尝试。

　　注意事项：欢迎提出不同的建议和意见，内部评审务必达成产品需求内部一致，但是需要发在产品内部群或者产品内部会中，避免到技术评审后在公共群及公共会议室PM/PD组内才发表不同意见，影响PM专业度，或者技术误认为产品内部没有达成一致就提出开发需求。

　　对应产出：会议纪要修改后的PRD既有意图。

　　▍2.9 技术评审

　　具体内容：与负责项目的技术人员进行技术评审，评估实现难度，问题以及风险点。

　　评审准备：

　　对应产出：

　　开发阶段

　　▍3.1 立项

　　具体内容：评审通过后，项目负责人立项，项目正式开始启动，进入开发阶段。

　　对应产出：需求分析邮件，排期。

　　▍3.2 跟进开发

　　具体内容：PM/PD跟进前后端开发进度，处理开发中遇到的问题，如需求有调整和改动，需及时更新加的。推进项目顺利进行。

　　注意事项：开发过程中尽量避免修改需求，如遇重大问题，需要修改，见2.7.6变更需求部分操作。

　　对应产出：前后端开发顺利完成，如修改需求，更新PRD邮件通知。

　　测试阶段

　　▍4.1 配置数据

　　具体内容：配置现场真实数据，需要人工配置的具体的数据内容。

　　操作步骤:如配置推荐数据需提前向市场运营组提出需求。

　　对应产出：线上真实数据，达到上线数据要求，邮件记录通报。

　　▍4.2 效果确认

　　具体内容：PM，UE，对前后端开发效果进行确认反馈问题及时修复调整，使之达到预期效果可上线状态。

　　注意事项：

　　效果确认点：PM确认产品功能及页面，UE确认，页面设计及交互效果。

　　对应产出：修复问题，PM、UE邮件记录。

　　▍4.3 内测组投放

　　具体内容：QA投放公测版本。到荣誉内测组，跟进内测组用户，反馈的问题和建议，推动完成bug修复，收集到的用户建议转化为相关需求，作为后续迭代计划。

　　对应产出：邮件记录，需求收集整理录入到文档管理的产品需求池，产品视图-spark需求管理。

　　▍4.4 BUG修复

　　具体内容：跟进QA发出的测试问题，推动完成BUG修复。

　　对应产出：测试报告。

　　上线阶段

　　

　　▍5.1 上线通报

　　具体内容：上线前一周或更早时间，邮件通报版本上线公告介绍上线发布内容。

　　通告形式：release notes+功能介绍。

　　具体操作：

　　邮件通报项目组相关人员，及公司全组release notes+功能介绍，release notes尽量简明扼要，列举出版本发布的新功能及优化功能点，并附上相关的功能截图介绍。

　　对应产出：邮件记录官网应用升级提示，release notes。

　　示例：

　　▍5.2 效果回归

　　具体内容：

　　PM QA等对线上效果进行再次确认，如有必要请UE同学，确认页面及功能模块的设计实现完成度与UI问题。

　　针对QA测试的BUGLIST，PM需要确认debug的优先级，建议如下：

　　对应产出：bug review 会议召集、邮件记录输出。

　　▍5.3 小流量因素，（投放内侧组）or A/B test

　　具体内容：

　　选择部分用户或者终端进行升级，进行小流量引流，投放内测组，效果，观测，平稳过渡，若有需要进行ABCtest，则进行部分用户小流量上线验证。

　　当然，无论是小流量引入还是A/B test，都只是手段。PM同时更应该注重数据和用户需求的研究与分析，利于各种简单有效的手段进行验证测试，避免产品功能风险。

　　另外，A/B test需要有足够的UV样本量。A/B test核心是分流，如果样本量太少，有可能会被偶然因素影响，对结果判断会有干扰。

　　▍5.4 开放正式入口

　　具体内容：

　　方式：提前通过邮件申请首页推荐位入口和周期，经和市场运营团队协商一致后，有运营进行操作。

　　对应产出：邮件通知入口开放，效果数据同步。

　　运营阶段

　　▍6.1 效果评估

　　具体内容：开放入口数据统计稳定后，累计两周左右数据后，进行对比分析，给出线上，后续迭代计划。

　　对应产出：效果评估报告、邮件发出。

　　效果评估示例：

　　▍6.2 项目总结

　　具体内容：对于流程周期较长的项目进行项目总结，主要对项目中自己或其他角色做得好和不好的地方，以及后续改进方法进行总体阐述。

　　对应产出：项目总结报告邮件发出。

　　▍6.3 运营推广

　　具体内容：

　　对应产出：PV/UV/VV使用时长等关键指标上持续优化。

　　▍6.4 持续优化

　　具体内容：产品持续优化，迭代。

　　对应产出：迭代计划。

　　总结

　　本篇列举了一个日活千万的智能硬件平台软件部分的生产流程，可有效地帮助从事智能硬件的产品人员，产品策略能力的快速提高。

　　当然快速提高的前提是基础扎实，产品的基础工作是不经一番彻骨寒，岂得梅花扑鼻香，成功走出来的产品几乎是砥砺过开发、实践过营运、更是经历过市场用户的检验，这种经历也许痛、也许苦，但最终一定会使产品的思想更丰盈。

　　作者：连诗路，公众号：LineLian。微信私号 Line，人人都是产品经理专栏作家，前阿里产品专家，希望与创业者多多交流。

　　本文原创发布于人人都是产品经理。未经许可，禁止转载。