一．项目管理
1.项目管理定义
项目管理是项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论，对项目设计的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。 项目经理：PM（Project Manager）。
项目经理特性：(1)目标驱动：按质按量的达成目标； (2)系统思维：系统的思维，有项目管理的方法和理论； (3)风险意识：风险意识，如能够判断研发代码隐藏的问题、能通过需求知道实现风险； (4)数据量化：拿数据说话，通过数据量化是否达到目标。
2.开发模式
开发模式有：瀑布开发、敏捷开发、螺旋开发等。主要讲瀑布开发模式和敏捷开发模式。
瀑布开发模式，是一种比较传统的软件开发模式。瀑布开发是一个刚性的线性模型，其中包括顺序阶段（要求、设计、实时、验证、维护），其中每一个阶段的目标性很明确，而且在进入下一个阶段之前，每个阶段目标必须100%的完成，但这种模式如果进行回溯修改时会比较麻烦。
敏捷式开发，以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。通过迭代开发，关注互动沟通等方法来降低软件开发过程中的风险，同时也可以减少在开发中的资源消耗。好处是通过早期发现和修复缺陷来提高开发的效率。
互联网中常见的开发模型-敏捷开发。 互联网的项目多以敏捷开发为主。敏捷开发的核心理念是以简单有效的方式快速达成目标，并在这个过程中及时响应外界的变化，做出调整。
二．互联网产品研发管理全流程
互联网产品研发项目主流程，分三大阶段：需求阶段、开发阶段、发布阶段，这样一个Round一个Round循环。
1.需求阶段
需求阶段包括，需求准备、需求内审、需求评审会、需求定稿。
(1)需求准备
(2)需求内审
内部的评审，如果有多个产品经理或者多个需求，进行X.X版本需求内审，评定需求优先级、评定需求可行性。评审后，确定X.X版本的需求。
(3)需求评审会
需求评审会由产品经理发起，介绍产品功能背景及设计方案摆在台面上进行讨论PK，直到形成统一结论的过程。
目的：明确项目目标、了解方案、排忧解难、众志成城。
参与对象：开发人员、测试人员、设计师、运营人员、产品经理。
评审内容：版本Feature List、基本交互原型 。版本Feature List：要做什么？为什么要做这些？ 基本交互原型：方案是否靠谱？做到什么程度？
可能出现的问题？立场不同、观点不一、进入细节、一站到底、以己概全、开会分神、效率低下、时间太长。 解决思路：求同存异、学会挖掘背后、放过细节、从深往前拉、核心讨论可行性、日后再说、适度休息、每个需求提醒、相关人员、控制时间、主持人特权。
会议总结：及时输出会议纪要、待讨论问题责任明确到人、会后跟踪、私下讨论。
(4)需求定稿
求同存异。 产品经理的原则与调性：产品经理需要有自己的原则，以及愿意为此负责的担当与自信，对需求足够把握的时候，该强势的需要强势；当然，该听的意见要听。
2.研发阶段
产品在研发阶段的定位：了解并推进进度、确保发布时间、监督进度、解决问题、调整与优化、确保产品与预期一致、需求变更同步、上下沟通、确保信息一致。
研发阶段，包括开发时间评估、测试用例评审、迭代开发、产品验收、测试。
开发阶段常见问题：1）需求打折(功能比想象中复杂、做不完、真要做完赶不上发版。 了解下真正原因，加加班、激励、沟通，挖掘下背景)；2）无法实现（分析下原因。比如，开发不能实现，找出竞品可以实现，怎么办呢？我们能不能攻攻关。 遇到这两种情况下，我们怎么办呢？）不能研发说不能实现就不能实现。
(1)开发时间评估
需求评审会后，开发Leader组织同步结果给到产品。 输出结果：对应每个需求的人/日。 产品经理：适度评估时间准确性，有预留风险的预判。
(2)测试用例评审
测试用例评审主要针对研发和测试，产品经理在初期参与。完善需求的异常逻辑及边界情况。
(3)产品体验与测试
产品体验，偏向正向的逻辑，至少基本流程能测通。如果产品体验都不能通过，直接打回去重做。产品体验通过后再进行测试开测。
产品经理，确保开发实现的功能与你的预期一致。 测试人员，确保功能在各种场景下都可正常使用。
体验与测试阶段的问题：体验产品发现大量细节不符合预期。 测试人员反馈： 这个功能会造成性能的卡顿，有可能造成不少OOM的问题。这里存在一个致命的bug，不同意发布。 这时怎么办？判断什么样的bug，是否为主要功能的bug？
3.发布阶段
发布阶段，包括三面的工作内容：项目方面、产品层面、运营层面。 项目方面：灰测（1测、2测）、Check List 产品层面：上线前版本验收、准备FAQ&客服手册 运营层面：发布渠道准备、运营推广计划
(1)灰测
灰测是在版本稳定后，让少部分用户参与提前体验，达到发现隐藏问题的目的。怎么定义？什么范围？怎么实现？Why？ BUG Review 严重：严重级别bug，视情形确定是否发布。 中等：视情况排入修复版本。 体验/小BUG：产品经理跟进。
(2)发布准备
Check List& 发布评审会：一般由测试或者项目经理拟定，各方负责人确定并打钩。 产品验收：确保产品的基本功能与需求是一致的，无核心问题的、确保产品的交互及UI符合设计要求、建议对照需求文档来验收。
可能的问题：验证不通过。严重级别bug太多；基本功能与预期不一致。 若Bug较多，但非严重性质的bug，且版本的基本功能重要，可发布，但需要尽快发布修复版本。 若Bug较多，且有严重级别的bug，需要根据出现场景及频率来判断。 若有严重级别的bug且是核心流程或功能，不可发布。
客服培训：上线前将新增/修改的功能同步至客服、教客服如何使用，方便解答用户疑问、产品经理也需要周期性的做客服工作。
更新FAQ：将新功能常见的疑问写成文档补充至FAQ，FAQ用H5实现。
(3)上线/提交应用市场
发布，确定适合发布的日期和时间。需要注意的点，发布后至少留1个小时已确保服务文档，协助客服处理紧急问题，适当给与关怀。群的维护以及核心用户通知。
发布渠道管理与上传，维护好发布渠道ID，确保渠道包正常使用。
提示升级，有三类：强制升级、提示升级、自动升级。 强制升级：有重大问题，阻碍试功能上线。 提示升级：重要版本。 自动升级：常规版本。
发送上线邮件，邮件内容： 告知xx版本xx日期发布了；展示：主功能特性；跟进：告知后续跟进计划。
数据汇报，上线后进行数据汇报。为什么要汇报？汇报哪些内容？领导需要安全感，团队需要鼓励及反馈；项目需要有始有终。 汇报时间：上线一周后，第一个月 汇报方式：邮件。汇报内容：基础数据变化，版本覆盖率、新增/优化功能数据变化、核心功能情况（对比同一时段）、后续规划等。
(4)用户反馈
收集用户反馈，评估优先级。重要不紧急的进入需求池，紧急的进入bug缺陷修复。
(5)需求池
做好需求池需求管理，做好版本规划。
