项目管理

项目管理：项目的管理者，在有限的资源约束下，运用系统的观点，方法和理论，对项目涉及到全部工作进行有效的管理。即对从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。

开发模式

瀑布式开发

瀑布式开发模式是一种传统软件的开发模式，瀑布法是一个刚性的线性模型，其中包括顺序阶段（要求，设计，实施，验证，维护），其中每一个阶段的目标性很明确。而且在进入下一阶段之前，每个阶段目标必须100%完成，但这种模式如果进行回溯修改回比较麻烦。

敏捷开发

通过迭代的方式开发，关注互动沟通等方法来降低软件开发过程中的风险，同时也可以减少在开发中的资源消耗。好处是通过早期发现和修复缺陷来提高开发的效率。

迭代开发：是一种软件开发的生命周期模型，与其对应的还有瀑布模型，螺旋模型等。

互联网的项目多以敏捷开发为主。因为敏捷开发的核心理念是以简单有效的方式快速达成目标，并在这个过程中及时响应外界的变化，做出调整。

版本迭代样例

互联网产品研发管理全流程

产品研发项目主流程图

需求阶段

需求准备

需求内审

评定需求优先级，评定需求的可行性。

需求评审会

概要：由产品经理发起，介绍产品功能背景及和设计方案。一切问题摆在会议上进行讨论，直至形成统一结论的过程

目的：明确项目目标，了解方案，排忧解难，众志成城

评审什么：

• 版本Feature List（要做什么，为什么要做）
• 基本交互原型（方案是否靠谱，做到什么程度）

可能出现的问题及解决方案：

• 观点不一致（学会挖掘背后）
• 立场不一样（求同存异）
• 进入细节（放过细节）
• 一站到底（从深往浅拉）
• 以己概全（核心讨论可行性，日后再说）
• 开会分神（适度休息，每个需求提醒相关人员）
• 效率低下（控制时间）
• 时间太长（主持人特权）

小技巧

提前沟通：提前找负责该模块的开发或Leader沟通思路

会议总结：及时输出会议纪要。待讨论的问题责任明确到人。会后跟踪，私下讨论。

会议两部分： 1.版本Feature list评审。只与Leader进行，只讨论目的和可行性。 2.需求详细方案评审。和负责项目的开发，测试进行。讨论细节。

谨记

产品经理的原则与调性：

产品经理要有自己的原则，以及愿意为此负责的担当和自信

对需求足够把握的时候，该强势时就应该强势

同时，该听的意见要倾听

研发阶段

产品在研发阶段的定位

1.了解、推进进度，确保发布的时间（监督进度）。比如开晨会，周会

2.解决问题，调整与优化。确保产品和预期一致。记得同步测试。

3.上下保持沟通，确保信息一致。

开发时间评估

需求评审会后，开发Leader组织，同步结果到产品。

输出结果：对应每个需求所需的人/日

产品经理：适度评估时间准确性，有预留风险的预判。

测试用例评审

测试用例评审主要针对研发和测试

产品经理在初期多参与完善需求的异常逻辑及边界情况。

开发阶段常见问题

需求打折：功能比想象的复杂，做不完。做完会超出发布时间。

无法实现

产品体验与测试

产品经理：确保开发实现的功能与产品经理预期的一致

测试人员：确保功能在各种场景下定使用正常情况

体验与测试阶段的问题

体验产品：发现大量的细节不符合预期

测试人员反馈：某个功能会造成性能的卡顿，有可能造成不少OOM的问题。或存在一个致命的BUG，不同意发布。

发布阶段

todo list

项目方面：灰测（1测，2测）Check list

产品层面：上线前版本验收。准备FAQ，客服手册，What's new？

运营层面：发布渠道准备，运营推广计划。

灰测：在版本稳定后，让少部分用户参与提前体验，以达到发现隐藏问题的目的

怎么定义？

什么范围？

WHY？

怎么实现？

Bug Review

严重：严重级别个bug视情况确定是否发布

中等：视情况排入修复版本

体验/小bug：产品经理跟进

产品验收

Check list 或 发布评审会：

一般由测试或项目经理拟订，各方负责人确定并打勾

产品验收：

确保产品的基本功能与需求是一致的，无核心问题的；

确保产品的交互及UI符合设计要求

建议对照需求文档来验收

可能得问题

验收没通过

严重Bug太多

基本功能与预期不一致

解决方案：

• 若Bug较多，但不是严重性质的Bug，且版本功能重要，可以发布，但是要尽快发布修复版本

• 若Bug较多，而且有严重级别Bug，需要根据出现场景及频率来判断

• 若有严重级别Bug并且是核心流程或功能，不能发布

FAQ & 客服培训

客服培训：

• 上线前将新增/修改的功能同步至客服
• 教客服如何使用，方便解答用户疑问
• 产品经理也需要周期性的做客服工作

随时更新FAQ：

• 将新功能常见的疑问写成文档补充至FAQ
• FAQ用H5实现

发布渠道

iOS：App Store

Android：应用宝，360......

渠道包管理与上传：

产品经理：维护好渠道ID表，渠道包验证

运营：包的上传及图片素材准备

研发：将ID号打包进渠道包

测试：协助测试渠道包是否正常使用

提示升级

强制升级：重大问题，阻碍式功能上线

提示升级：重要版本

自动升级：常见版本

以上三种升级方式，在交互体验上应该如何设计？

发布

适合发布的时间是周几？几点？

周二，周四 下午

需要注意的点：

发布后至少留守1个小时确保服务的稳定。

协助客服处理紧急问题，适当给予关怀。

群的维护与核心用户周知。

上线的邮件

内容

告知：XX版本XX日期发布了

展示：主功能特性

感谢：领导，技术，设计，测试....

汇报的意义

为什么要汇报？

领导需要安全感

团队需要鼓舞及反馈（如果数据不好怎么办）

项目需要有始有终

对自己来说：

刷脸，刷存在感，刷影响力

给自己的成绩单，检验目标

用户的反馈

属于需求池范围的，重要但不紧急

属于BUG，一定要紧急处理

运营推广

好产品离不开好运营

产品经理，在功能设计初期，就要介入运营。以产品功能为切入点，引导运营拓展方案。

小结

没有一帆风顺的项目，爬过的坑将成为宝贵的经验