把项目理解成一件事儿，则项目管理由三要素组成：对象（人或者资源）、时间、事
明确什么人在什么时间做什么事情，为进度和结果负责。目标是做成这件事儿，相关支持是人、资源、时间。
把项目管理分为两个部分：
做什么——需求管理
怎么做——项目规划及执行
需求管理：要做的事儿从哪儿来？是什么？怎么分？什么时候做？
注意：一定反复确认原始需求，保证理解的正确性
需求来源：
PM关于需求的采集需要有明确的时间点和对接人，常见的需求来源有以下几个渠道：
老板：
弄清楚老板意图很重要！！！可能是随口提的，可能只是想法或建议，或者老板觉得必须要做的（不排除我们的level无法理解老板的意图:(）产品经理直接或间接收到老板的需求，要慎重抉择衡量之后及时给老板反馈：
*如果可行--给出排期（包含所需成本）
*如果不可行--给出不可行原因（性价比或者技术原因等）及其他替代方案
*勇敢说不--老板可能只是随口提起，如果方案性价比不高，一定要给出自己的建议及原因
PS：一定一定要正确理解老板的需求！不要似是而非，不要想当然！
用户：
用户的需求大多来源与用户调研或者用户反馈，产品经理需要在正确理解需求的基础上，明确需求的必要性（详见下文用户需求KANO模型）
运营：
运营同学可能也会提一些功能性需求，此时需要产品同学进行抉择后与运营同学沟通并给与反馈（运营需求的收集也需要周期性进行汇总~）
产品内部：
产品经理内部根据产品发展阶段、参考竞品、数据结果反馈等渠道提出新的需求，没啥好说的，内部做好沟通~
技术：
研发同学提出的需求一般包含两个方面，
a:本身的技术优化或者bug修复（这个产品同学明确好排期与优先级，技术同学定技术方案即可）
b：研发人员可能会说，我觉得XX需求是不是可以这样做（他们会从技术+用户的角度提出建议或者意见），此类需求，产品明确必要性之后做出解释或者抉择~
测试：
测试同学会从”细节+逻辑+用户“的角度，提出他们会觉得哪种用户体验更好，可能包含一些逻辑上的漏洞建议，功能或者技术上的建议，当然更多的是指出bug，总之还是悉心听取并有选择的采纳
商务：
还有商务同学，（可能会比较强硬：（ ）
由于业绩压力，商务同学会说送给我加广告，XX地方都加上，这个时候要进行决策与衡量（保体验or保收入，有些决定需要问题上浮才能够定的哈~）
总之：
1.需求收集需要有周期性的安排和规划
2.收集需求时，一定要反复确认，避免理解偏差
3.虚心听取，认真考量，及时反馈，相信大家都是抱着对产品好的态度提出的需求，无论是否可行，都要认真对待并给出反馈（重视每一个需求和提出人）
4.记得，还可以问题上浮！
建立需求池：明确格式，及时更新
简单说来，需求池就是对收集的需求进行记录和管理，包含需求描述、来源、状态等，不同公司需求池的格式不同，通常用excel或者腾讯文档等进行记录，重点就是及时更新（比较琐碎的工作）
需求分析：需求优先级定义
需求分类：
常见需求细分如下（需求分类有助于确认需求所需资源并定义需求优先级）
UX：用户体验型需求，例如触区调整，流转动画等
UI：设计优化，例如更换启动图、调整icon大小
功能型需求：与业务相关，例如增加页面或调整逻辑，增加模块等
运营需求：一般与运营对象相关，例如活动的处理或者分发样式的处理等
数据需求：一般由运营同学或产品经理提出，常见于数据上报
技术需求：技术同学提出，代码优化、结构调整、控件更换或者bug修复等
商业化：常见于广告等
确定需求优先级：
优先级的定义需要结合项目所处阶段、需求来源（老板的需求要慎重对待）、需求重要性&紧急程度、需求所需的资源支持（人力、机器、时间等）、需求可能带来的收益评估等多方面因素综合考量。
确定项目所处阶段：
项目处于不同阶段，有不同的北极星指标，这个指标可能时随着数据表现和业务发展不断变化及调整的，我们的需求一般需要围绕着提升北极星指标展开。（例如：小说类应用，项目发展初期的北极星指标可能是有阅读的人数比例，或者是有效阅读（阅读超过XX章节）的人数比例，围绕这个指标，让有阅读的用户阅读更多<——更多用户产生阅读<——激起用户的阅读欲望<——用户能够见到或者找到自己想要阅读的书<——优化分发，就是结合项目所处阶段，确定北极星指标，并以此逐层递进拆解需求的过程）
需求重要性：
一般使用”四象限法则“确认需求的重要程度，同时结合”KANO模型“确定需求的必要性和紧急程度。
四象限法则：
1.重要并紧急：此类需求若以版本为节点，一般不超过3个，否则表示项目管理出现了问题
2.重要不紧急：可提前调研，提前规划，合理排期即可
3.不重要但紧急：常见于小bug修复
4.不重要也不紧急：在做好需求池管理
PS：明确上述的紧急和重要是针对整个项目而不是针对产品部门！！
用户需求KANO模型：
基本（必备）型需求——我可能不用，但你不能没有
当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低；
期望（意愿）型需求——我想要用，所以你不能没有
当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低；
兴奋（魅力）型需求—你没有我也没啥想法，你有了这个功能，我会觉得哎呦还不错
用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升；
无差异型需求——这个功能有没有我不在乎
无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意；
反向（逆向）型需求——我不喜欢有这个功能的应用
用户根本都没有此需求，提供后用户满意度反而会下降
需求评估：
需求评估一般是在确定需求重要度的基础上，结合需求所需要的资源和成本，评估需求的性价比和优先级，我们当然希望用最小的投入得到最大的产出。一般评估之后，可以将需求划分为：
a.重要需求：以发版为节点的重要需求，必须做的
b.分支需求：重要需求，但是需要耗费较多资源，则分支做，并在规定时间内合并至主版本
c.分散型随版需求：常见于项目初期，存在很多的UX优化点，而此时项目版本迭代较快（可能1-2周），则可以每一周随版一些优化需求
d.持续分支需求：重要不紧急需求，需要较长时间段的调研和准备，一般分为调研、方案讨论、执行几个部分
=========================分割线=============================
项目规划及执行
确认了需求优先级之后，以版本为单位进行项目管理，项目执行过程还包含以下环节：
需求设计：产品同学完成需求文档及需求原型（需求原型用最简单的线框图，以免影响设计同学），一般需至少提前1-2个版本进行规划
UI设计：一般需求文档及原型图完成之后，需要进行UI设计，有的公司也会放在需求评审之后（不过用UI图进行评审更加准确）产品同学需要将功能目的和重要性同步设计同学，以便设计同学进行排期及正确设计
需求评审：叫上所有相关人员一起开会吧~，会议时间要控制，以图说话，开发及测试注意点提前说明，具体规则及细节见文档。一定要hold住场面，不要掉进细节陷阱，毕竟大家的时间和宝贵——产品需要尽可能的完善文档和规则
需求排期：(需求工作量预估）需求评审后，需要给出排期，方便项目安排，排期包含
a.服务端排期(执行过程中，一般至少提前客户端半个版本）
b.客户端排期（接口已提供/数据已通/模拟假数据）
需求开发：（一般服务端提前半个开发周期，保证客户端接口可用）
需求测试：测试（服务端、客户端）
需求上线：服务端上线、客户端灰度、客户端大发版
开启升级（建议或强制）
以上版本规划为理想情况，一般来说，真是的发布过程中，一定会有根据之前版本的数据表现所需要进行的需求调整，或者会插入一些紧急需求。开发过程中也会遇到一些不可抗因素，需要届时进行取舍。
项目管理执行--明确时间点、风险点、信息同步、取舍（延期or砍功能）
项目执行过程中的注意点：
1.项目开始前明确大家目标一致性，解释功能和目的（例如本阶段我们的主要目标是提升新用户留存，所以功能重点在优化新用户分发）
2.项目开始时，保证需求理解一致性！！所有！所有相关人员的需求理解一定要一致！
3.资源的合理协调：确定什么人怎么做，做多久（产品同学需要对相关人员，特别是研发和测试的能力和习惯有一定的认知，便于合理 安排时间）
4.信息同步非常重要！开发过程及时跟进，问题及时提出，风险及时报备！
5.目标及时调整（取舍）：一个关于延期or砍功能or寻找代替方案的问题，一般来说是之前步骤没有做好留下来的坑，但是无可避免
6.人员的鼓励（看人下菜碟）----对项目相关成员的预期与考量（能力、质量、时长等），兼职鼓励师吧！
7.项目目标验证：主要看数据--崩溃率、功能数据表现、核心指标数据表现
8.及时总结
