step1：启动/规划——项目前期准备，kickoff
当领到这个目标，并被任命为项目pm之后，我们首先要进行项目的背景及目标了解。这里也简单介绍一下：我们之前参加了一个项目经理的培训，这次主要将学员们组织起来，通过吃火锅的形式来实操项目管理方法，同时增进感情。目标很简单：在活动当天（x号x点至x点），负责活动小组7人，经费400元，活动方提供场地，自带餐具，使用活动组经费完成采购，烹饪，聚餐以及餐后清理工作；组员吃好喝好。
启辰菌说：在领到项目之后，不要马上进行项目推进，而是要先就项目合理性，项目目标，项目预期，项目时间，项目预算等与资源方达成一致，这样可以更准确的安排项目节奏，管理起来更加游刃有余。
项目交付物（一）项目内容拆解图：
在pm确认并认可项目目标之后，pm会简单进行项目内容拆解，具体如图（初稿，勿喷o(∩_∩)o）：
项目内容拆解不包括排期，主要是工作内容的分解。
有了项目拆解稿之后，我们简单开了项目沟通会议，和项目成员同步了我们的项目背景及目标；确定了几个关键时间点及交付物；同时简单过了下项目内容拆解图，进行头脑风暴，进一步细化项目内容拆解图。
启辰菌说：有关项目拆解：确认项目目标之后，pm需要进行的是与项目成员同步项目目标，背景，以及进行项目内容的拆解。合理的项目内容拆解，能让项目成员明确项目的边界，明确看到项目的进度。但由于pm毕竟是人不是神，有很多时候都需要整个项目组进行头脑风暴，来进一步完善拆解图，同时细化的过程也会增加项目成员的参与感。
项目交付物（二）类型总结：
交付物一般包括几种类型：
计划型交付物：如项目内容拆解图，行动计划表，成本预算表，一页纸项目计划表等；
进度型交付物：项目日报，周报等；
里程碑型交付物：立项报告，结项报告，项目阶段文档等。
安利xmind，拆解项目，脑暴神器。
会后，我们组建了项目im群，邮件群，微信群在群里统计了大家的空闲时间，以及饮食喜好，对项目内容中是否有在行，愿意主动帮忙的地方。很快我们也达成了一致。pm依据大家的时间及专业能力做了简单的项目排期。
启辰菌说：
保持沟通：保持流程的沟通是pm的重要职责。项目开始之际，应通过多种通讯方式的选择，尽量保证可以随时联系上项目成员，方便后续跟进；
了解项目成员：项目中的每个人都是独立的个体，大家围绕着一个共同的目标一起努力。这时应该充分发挥成员的主观能动性，专业的人做专业的事，这样才能更高效完成项目。pm的重要一点是有效统筹项目中的人，物，资金。
上面一切准备就绪之后，我们简单开了kickoff会，重申了以上达成共识的一点，重点强调了目标，项目分解，项目资源，项目排期。在大家达成一致后，pm产出了立项报告，成本预算表以及行动计划表，并邮件抄送了邮件组，并将关键节点在im群中设为公告，方便大家查阅。这样项目就算正式开始啦！
启辰菌说：
kickoff会的目的：明确项目背景，目标，资源，排期等关键需求。作为项目的里程碑节点，该环节交付物为立项报告，成本预算表以及行动计划表。
项目交付物（三）立项报告，成本预算表，行动计划表：
立项报告：一份较为完整的立项报告包括项目名称，项目背景，项目目标，项目人员，项目时间，项目pm，项目交付物，项目成本，涉及团队等因素。
成本预算表：成本预算表每个团队格式不同，简单格式由支出项，数量，价格组成。
行动计划表：以甘特图形式标记团队各个成员工作内容及时间，便于跟踪。其中有报警项，如果进度delay严重，可以及时发现，具体如下：
有关项目管理工具：
这里分享几种常用的项目管理工具：
omniplan：用于管理项目（比excel专业，但是excel更加普遍）
一页纸项目管理工具：可以视为是行动计划表+成本预算表的合体，适合快速统筹项目资源，网上下一个马上就可以用，具体如下：
step2：执行/监控——项目推进，关键节点检查
kickoff会之后，项目就正式开始了。虽然项目时间比较短，但我们还是定了好几个关键时间点。现在pm的角色主要就变为进度跟进者，资源协调者，风险解决者。需要做的主要是走查，确保进度（比如采购，食具，会场检查等子项目进展）；人，时间，资金不被其他项目或需求挪走（比如临时会议导致没空参与采购）；如果被挪走后，怎么灵活应变。还有就是组织项目站会，以及写项目日报啦。
启辰菌说：
当项目正式推进时，关键点就成了风险管理了。项目会面临各种风险，主要有目标变动，人员变动，时间变动，资金变动。这些风险都可以通过灵活调拨资源，砍功能点，项目节奏调整来应对，但最严重的风险是业务变动，有可能整个项目对被砍掉。大部分情况下，这种风险一旦发生，pm铁定要背锅的，这说明在第一步项目背景和目标了解的时候，没有做好本职工作而直接执行了（如果整个bu被砍掉。。。那就真的没办法了┑(￣д ￣)┍）。
对于pm来说，无论事前想的再详细，项目总会有风险发生的。项目风险管理是很重要的！所以每天都要更新行动计划表，日报等，都是为了有效监控进度和风险！
常用项目跟踪的方法：主要可以从以下三个方面进行考虑：
1、事项管理——站会
组织站会。每日站立可以在同样的时间和同样的地点召开，会议准时开始，最好不要超过15分钟，每一个开发团队的成员都必须发言，会议中不进行讨论，发言内容需提供以下信息：
昨天完成了什么
今天即将做什么
遇到了什么困
一方面可以避免有些同事在项目过程中沉浸在自己的世界里，方向走偏了自己没有发现。另外一方面是能帮助大家克服人性上的懒惰因素，在每天汇报工作进度中给大家形成适度的压力。
2、人员管理——保持沟通
pm需要多沟通，了解项目组每个成员的表现，对表现突出的给予赞赏和肯定，对表现不好的则应提出相应的提醒。
另外一点，产品经理要去多和项目组的成员进行沟通，这种沟通不仅仅是工作上的沟通，还可以聊聊生活方面的东西，这样不仅可以促进你和项目成员之间的关系，还能及时知晓他们的生活状态，也是有利于项目管理的。
3、预算管理——了解开支
运营活动相关的项目管理，就经常会涉及到项目开支的问题，这里的监控其实主要是记录下所有的开支流水，看下与项目计划初始阶段的预算相比是否有超出的情况。这个时候可以好好和运营的相关同事进行沟通，找出具体的费用超出项，分析原因找到相应的解决方案。
step3：收尾——项目验收，复盘
在小伙伴的共同努力下，有惊无险的进行了整个活动，包括采购，会场踩点，会场资源检查，吃饭，清洗收拾等环节之后，活动发起方和pm验收了这个项目。验收完成后，我们现场进行了一个简短的项目review。pm带头说了项目中的问题点，总结了好的地方，也检讨了做的不好的地方；项目组成员也都进行了发言。结束后，大家各自回家，而pm则默默敲完结项报告，项目总结文档，邮件抄送项目组全员及活动发起方，项目相关文档进行归档。项目圆满结束！撒花~下午茶走起~
启辰菌说：
项目验收环节，包括关键节点的验收，交付物的验收，项目目标的验收，风险管理效果的验收等几大块。另外项目review是非常关键的环节，有利于项目成员沉淀好的项目管理经验，扬弃影响项目效率或者风险管理不当的做法。review可以单出会议纪要，也可以与结项报告一起整理。
项目交付物（四）结项报告：
结项报告：结项报告主要包括几个部分：对项目背景，目的，分解后的项目目标，参与人员，责任部分，考核标准，交付物checklist，项目成果及效果，复盘及风险报告，沉淀及总结等。
以上就是一个简单项目的项目管理方式。吃火锅项目，麻雀虽小，五脏俱全，其中总结出来的项目管理方法，在复杂项目的管理中，亲测实用！项目管理其实方法论比较简单，但是魔鬼在细节，魔鬼在执行。希望对大家的日常项目管理有所启发。
耗费时间和精力：最初大家还是愿意接受线下手工的方式写字操作各自任务记录，后面每人每日都要花费大量时间手写任务列表，进行卡片粘贴。到最后整个团队都觉得这样写起来很麻烦，逐渐放弃了手动写的过程，转而进入线上工具的管理。
更新删除麻烦：团队每个人每天都需要对今天完成的任务进行更新，多数时候当大家拿起笔去更新时重写内容时就开始愁苦。写了一天代码要下班了还得重新写字更新今日任务，尤其碰到需要删除重新的需求任务更是崩溃。
历史记录找不到：每天只能看到当天完成了什么，昨天完成了什么。当整张墙贴的密密麻麻时，想找一个人任务时，眼睛都要瞅半天。此时大家真想有个“搜索”功能。尤其在每期迭代结束后，统计每个人任务进度时，简直要崩溃。此时多希望有个工具能帮我做这件事。
子任务拆分不方便：产品需求永远都会拆分子任务，研发在开发时也需要拆分更细的子任务。此时自己用人工的方法来做就显得特别麻烦，尤其拆好的子任务要做拆分修改时，更是麻烦。
人员管理麻烦：我们当初整个看板名字是固定的，随着后续有新同事进来，旧同事离开，整个看板都需要更新。这时就需要把看板上的所有任务全部清除后再重新布局。
后面尝试转移到线上工具管理后，整个研发团队的迭代节奏明显加快许多，原先将近两周才完成的迭代、现在相同任务量缩短到一周。每日晨会、站会时间也由半小时缩短到15分钟。研发团队每日下班的时由原先花费将近10分钟更新今日任务的时间，缩短至1-2分钟搞定下班回家。从这个现象可以看出一个有效的工具能帮助研发团队提高效率。
在产品迭代流程方面，我们采用周期的研发节奏，整个产品研发的迭代顺序大致是 需求收集 – 需求分析 – 功能策划 – 原型设计 – 需求评审排期 – 开发阶段 – 测试阶段 – 上线阶段，这里实现一个完整的迭代。
对项目时间管理，本来采取的是线下excel表格管理，后面也逐渐转移线上工具化管理。
下面就详细讲解下 在产品迭代项目的每个阶段我们都做了什么。
需求收集阶段
产品部门有自己的需求收集和分析方法，我们会在建立一个“需求池 ”，产品会将收集来的各方面需求收录到池子里。需求池的需求主要来源于市场、用户、竞品、老板、产品经理。我们会用线上工具将需求进行分类管理，比如app端需求、运营需求、网页端需求等等。并定期对需求池中的需求进行合并删减。
在需求收集阶段，产品部会和运营、市场、商务等同事进行详细沟通，确保了解每一个需求的目的和意义。
需求分析阶段
对建立的“需求池”，产品对定期进行评估，评估也是基于产品内部的讨论，在讨论前一定要确保了解每一个需求背景和意义，不要一个人拍脑袋把需求拍出来。我们崇尚以产品为公司核心导向，所以产品经历的决定权很重要，直接影响公司战略走向。所以对于需求池的需求进行详细分析时，一定多基于用户、市场和公司角度出发。
对需求池的需求分析主要做两件事：
整理需求池内容，从优先级和重要性两个纬度进行产品功能筛选。
确定需求池优先级和重要性后，进行需求标记，创建新迭代并关联需求。
确定要做的需求后，就需要开始细化需求。这时候就考验产品经理的功底了。
功能策划阶段
在确定要做的需求后，为了保证需求在研发阶段的完整性和可分工。需要在功能策划阶段就要对产品需求进行模块拆分和任务拆分。确保需求的颗粒度与研发时间评审的模块一致，如果不知道怎么拆分，需要提前与研发同学沟通。
在任务拆分后，为了保证及时同步给研发同事，需要将子任务先在线上工具关联到迭代，目的主要有两个：
可以让研发同时知道下一期功能范围和模块，提前进行技术框架搭建或技术预研。
方便产品同事（多人负责一个模块）的协作设计。
在线上工具上，可以对需求进行关联，比如父子关系，方便连续查找，树形结构更容易一目了然。
原型设计阶段
原型设计阶段最难管理的是版本问题，这里包括两类文件的版本管理。
产品经理的原型稿件
设计师的高保真设计稿
首先，原型稿修改的次数远远会大于设计稿，主要因为一些需求会在评审后或者开发中才会发现问题。修改或者补充的。再者，我们的创业公司原型稿上大都有交互说明一起的，一般修改/补充文字说明比较多。而且原型稿的使用对象更多是研发和测试同学，所以每一次版本记录和修改后同步都是巨...