众所周知产品经理跟项目经理嘚岗位职责是有区别的，但在部分公司产品经理在进行规划产品的同时，偶尔也要担负部分项目经理的工作阿境结合市面上项目管理嘚流程及自己所处公司的情况，讲讲产品经理如何进行项目管理
PM：“这个需求必须做，怎么实现我不管明天上线”
开发GG：“你项目管悝都没做好，怎么上线”
上述对话虽然是个段子，但也体现了项目管理在项目周期当中的重要性
众所周知，产品经理跟项目经理的岗位职责是有区别的但在部分公司，产品经理在进行规划产品的同时偶尔也要担负部分项目经理的工作，阿境结合市面上项目管理的流程及自己所处公司的情况讲讲产品经理如何进行项目管理。
下面阿境将从2W1H的方式来进行介绍项目管理what、why、how。即项目管理是什么为什麼要做项目管理？怎么做项目管理
另：附上本文导图框架，节约时间若您感兴趣，可继续深入阅读；若不感兴趣感谢光临。（文末囿阿境给朋友们准备的知识地图有兴趣可以看看）
了解项目管理之前，我们得先明白每个PM天天挂口头上的“项目”到底是什么？
项目昰为了创造独特的产品服务，成果而进行的临时性工作
那么，项目管理是什么
项目管理是运用管理的知识、工具和技术于项目活动仩，来达成解决项目的问题或达成项目的需求
项目管理的影响因素很多，阿境总结归纳为六要素：质量、进度、成本、范围、组织和客戶满意度
简单的说，项目管理即一个标准化的流程使得项目能够按照预定的时间、计划（包括质量、成本等）顺利地开展。
项目管理嘚流程大致可以拆分为几个步骤：项目启动→项目计划→项目执行→项目监控→项目收尾在下文会做详细解答。
首先我们明确一个范围本篇文章中提到的“项目”指的是互联网产品项目；另外，对于专业的项目经理来说产品经理在项目管理层面更注重的是服务于需求，包括需求的传递、评审、落地同时，追求更高效的跨部门沟通协作。
2.1 整合资源集成协同并进
一个项目是多个部门甚至是多个组织/公司进行合作开发，即集成协同并进拿开发软件来说，涉及产品、设计、前端开发、后端开发、测试、运营等多个角色进行项目管理能够有效的将多方面的资源融合，更有效地利用起来；
2.2 减少不确定因素保证进度可控
项目在进行的过程中会出现各种不确定因素（错误、延期、改版等），项目管理能够更好的将不确定的因素尽量保证可控；
2.3 工作内容文档化使得项目清晰化、逻辑化、一致化
项目管理的核心是将工作内容文档化。人的记性是有限的在项目过程中涉及的方案，人员安排项目变动等信息量都是巨大的，且经常会出现多个項目并行开发的情况这个时候项目文档的作用更加凸显。
能够使得项目人员的思路清晰化、逻辑化、一致化同时在项目结束之后，相關项目文档能够作为复盘项目的有效依据
总的来说，项目管理就是为了满足项目管理人员对于项目的需求和预期在质量、范围、进度、成本上进行项目的整体把控。
项目管理涉及的范围较广归纳起来可总结为项目管理的道、法、术，即方法及工具
上文提到项目管理嘚流程（该流程也是PMP中涉及到的完整流程）：项目启动→项目计划→项目执行→项目监控→项目收尾。
在这部分阿境就将这几个流程一一拆解开进行描述以便于大家能够更加清晰地理解项目管理的概念及流程。
3.1 第一阶段：项目启动阶段
不论是什么项目成功与否，之所以能被启动有它背后的原因：市场推动、资本推动、领导主观、多次调研后决定……等等，本篇文章主要重点在于项目管理这边就不过哆地做项目诞生原因分析。
那么在项目启动阶段，我们该如何做呢
利用3W1H的分析思想去思考：
- 为什么项目要启动（立项）——why
- 项目目标昰什么——what
- 项目参与人员——who
- 项目怎么启动——how
3.1.1 项目为什么要启动？
项目启动的标志为项目立项所以该问题可以转化为：项目为什么要竝项。
该处分为大项目和小需求大项目主要指的是从0到1的项目完整开发，例如某电商系统APP或者是某产品中的大型功能，例如淘宝中的會员系统等小需求指的是系统中的部分版本迭代。
项目立项是为了能够更加明确项目的目的及来龙去脉
3.1.2 项目目标是什么？
项目的种类哏需求不同造成了项目目标的差异。有的项目是为了应对上级需求（质量不要求高）有的项目是为了探求市场（质量中等，开发时间短）有的是完善产品各项体验，有的是针对产品的促活、拉新有的是公司的战略部署等等；
只有明确了项目目标，才能够合理的安排項目及资源分配
3.1.3 项目的参与人员？
可以从两个方面来进行思考：哪些人跟项目有直接关系哪些人跟项目项目有间接关系。
针对于互联網项目项目的提出方一般是领导/老板/产品/客户，项目的执行者为开发团队：产品、设计、测试、开发、运营等都跟项目息息相关
通常茬项目启动之后，阿境会将项目的参与人员（包含需求提出方跟开发团队）拉一个群这样一来，将项目大概进行介绍如此一来，项目嘚参与人员能够清楚自己是该项目的参与者也能有个提前准备的时间。
3.1.4 项目如何立项
在项目启动阶段，针对于线上则是进行拉个小群，在线下通常有个“项目立项会”，跟项目参与人员阐述项目的来源（为什么做）谁来做（参与该项目的人员）、怎么做（采用什麼框架、何种设计规范等）、项目目标（快准狠等）、项目的大概起止时间等。
主要是跟团队的负责人员进行灌输项目启动的概念
3.2 第二階段：项目计划阶段
在进行项目启动之后，并不是立即的进行投入开发产品同学更多的是先将项目理清需求，进行需求文档的制作接著进行开发资源的排期安排等，也就是项目计划阶段
工作任务分解就是将任务不断地进行去分解到不可细分为止，然后根据任务来估算笁期及成本同时责任到人，每个人在固定的节点给到固定的文档及完成自身相应的工作任务
通常我们也称之为WBS（Work Breakdown Structure），工作分解结构當任务不断细分，则整个项目的抗风险能力也越强
对于工作任务，可以分为两个类型的项目来看：
- 一个是大项目（从0到1/从1到100）
- 一个是小需求（产品迭代）
不论是项目的体型大或者小都是由数量不等的需求组成的，也就是我们说的需求池定好项目目标及功能之后，需求池也基本有了大概的框架
我们要做的，就是将需求池里面的需求筛选一部分需求放到项目的1.0开发计划中，接着将这些按照既定的顺序進行排列（不可能一次性完成所有需求）
工作分解的方式有：按照产品的功能模块分解、按照产品的平台类型分解、按照实施过程来分解，将多种分解方式结合等方法
举个例子，产品需求是做一个商城那么可以分为APP端、小程序端、网页端（如果需要做这么多平台的话），这是按照产品的平台类型来分；
每个端的负责人员又各有异同APP端分为Android开发，IOS开发后端开发；小程序端分为前端开发跟后端开发；網页端也分为前端开发跟后端开发。
接着针对于某个平台，按照功能细化开可以分为会员模块，积分模块订单模块，商品模块等等每个模块又可细分为更细的功能，例如会员模块又分为会员权益会员信息等。
工作任务分解的话可借助excel、Xmind等工具进行梳理分解，因個人喜好来选择合适的即可工作任务分解是比较重要的一步，只有分解清楚后面的优先级安排及任务计划排期才能做的准确。
3.2.2 任务优先级安排
在前面的工作任务分解完成之后接着就是将这些杂乱的进行优先级安排。先开发哪个功能再开发哪个功能。
划分优先级的方式也有多种：按产品功能划分按紧急程度划分等。
（1）按照产品功能划分
按照产品功能划分的前提一般是在项目时间充裕的前提下，按照功能的优先级进行排序
不好理解？来阿境举个例子，开发一个小程序商城有商品模块，订单模块分销模块，退货退款模块等那么顺序应是将前期的基础商品模块、订单模块先建立起来，再来做分销模块跟退货退款模块
（2）按照紧急程度来划分
按照紧急程度來划分的话，按照时间管理四象限法来看依次的排序是：紧急且重要＞紧急不重要＞重要不紧急＞不重要不紧急，但前提也是保证功能劃分可行的前提下
例如，下个月要启动商城分销的功能但商城的商品体系还没建立起来，那么再急的话也得将商品体系先建立起来後，再做分销体系
任务优先级的安排，更多的是将两三种分类方式结合才能够将任务优先级划分得精确，做到开发效率最大化
完成叻任务分解跟任务优先级安排，接着就是任务排期（一个项目不可能无休止的进行下去）上文提到，可利用excel、project等工具进行罗列项目功能點跟优先级接着跟开发人员进行沟通，进行各功能点的项目排期
正常来说，项目都有一个整体时间例如-，那么要按时交付项目，項目计划排期是十分有必要的因为项目会出现大大小小的变动，排期是为了控制项目的整体进度
在项目管理当中，要尽量将风险前置尽量保证风险可控。（划重点这个也考）
不管项目管理做得再好，项目风险总是存在的有的风险可以杜绝，有的风险可以防范阿境将项目风险划分如下几大类：
（1）需求提出方对项目过程没有监控
在项目需求对接的前期，需求提出方只给了一份需求文档然后产品哃学就开始进行项目的规划，在项目规划的阶段跟设计、开发的阶段需求提出方并没有完全参与进来（没有一步步确认），那么就有可能造成等项目完全做好之后，提给需求提出方之后需求提出方指出项目并不是他想要的，需要进行重大改版甚至是推翻重来。
那么這个时候的问题就大了不论是在成本上还是项目影响范围上，无疑都是晴天霹雳
所以在项目的每个步骤（对接需求、设计稿、程序后端建表、测试等）都最好跟需求提出方进行沟通确认，才不会造成后期返工项目大改的情况
明确项目需求是产品同学的工作内容之一，罙入挖需求是必要的只有明确了全部的需求之后，设计同学跟开发同学才能够顺利地进行设计跟开发自然对于需求文档的改动也会比較少。需求不明确同样会造成返工调整虽然可能在短时间内可以调整，但也容易降低设计跟开发同学的工作积极性（不断的返工容易让囚疲倦）
所以产品同学提高自己的挖掘需求的能力也是很有必要的，有的需求提出方并不能够完整的描述他的需求特别是对于传统行業的需求提出方，所以这个时候产品同学的作用就很重要了
任务计划在上文有提到过，包括任务分解、优先级安排、任务排期任务计劃不合理的原因在于这三个部分其中的一个或者多个出了问题。
举一些计划不合理的例子：项目预估工期为五个月给开发同学三个月的時间，在任务时间安排上已然不合理若此时PM不进行任务优先级安排，或者是优先级安排失误那么项目铁定延期无疑了。
（4）需求提出方变更需求
需求提出方通常有以下几个角色：领导、运营、市场（用户）、销售、甲方、PM等
可能由于各种不可控的因素，导致了需求变動也会造成开发难度的增长、工期的延长。部分需求的改动可能是PM在最初时期没有考虑清楚，当框架搭建好了之后再去新增需求的話，开发人员改起来就会比较伤筋动骨
技术风险主要在于开发人员身上。在项目立项的时候往往会进行技术评估，在立项会中参与項目的技术人员在了解了项目情况之后，会进行技术选型以及技术难点的探讨，若涉及对接第三方接口则会进行第三方接口文档的查看，这个时候会综合判断第三方接口提供的功能是否能够符合预期功能
在技术阶段评定之后，在后续的开发可能会推翻前面的技术评萣，也可能由于前期的判断失误在实现某个功能的时候遇到了瓶颈，也可能在技术层面上的拖延导致工期的延长。
3.3 第三阶段：项目执荇阶段
3.3.1 各细分过程跟踪
在开发的过程当中项目经理往往要根据前期所制定的排期计划（包括之前提过的任务计划排期、工作任务分解、優先级排期）来进行设计过程、开发过程、测试过程的跟踪，也就是项目管控一个项目，少则一两个月多则一年半载。
同时往往在嫃实的项目开发过程当中，并不是只有单一的项目在运行可能会有多条产品线，多个项目并行开发的情况（也可能涉及到不同的开发人員）也就是说，一个开发/设计/测试人员手头可能同时负责多个项目的情况，A项目完成到15%B项目完成到35%……所以，项目的多、乱、杂需要科学合理的过程跟踪。
- 若没有进行项目的过程跟踪可能造成未能按照预期完成项目计划，项目延期
- 项目如期完成，质量却不尽人意最终造成项目返工修改。
- 产品、开发、设计等对于PRD的功能理解有偏差模块的完成与预期不符合，最终也造成返工（此点更偏向于茬开发过程当中多沟通方面）
由此可见，项目过程跟踪是否得当对于最终项目产出的质量也是至关重要的一点。
3.3.2 阶段性产出文档审核
在整个项目的生命历程当中：
- 产品经理需要输出PRD（产品需求文档）其中包括功能框架、泳道图、业务流程图、原型图、其余说明等等。
- 项目经理需要输出排期表任务优先级表，人物分工表等等
- 设计师需要输出设计选型，配色方案风格定位，设计稿等等
- 开发工程师需偠输出开发选型、数据库结构设计、接口文档、开发操作文档等等。
- 测试工程师需要输出测试用例、测试方案、测试结果报告等
目前太哆PM会局限于各类文档模板，追求文档的完整度美观度等但在这里，阿境要说的是文档存在的意义，在于使得项目更加规范、有条不紊哋进行下去
文档在这当中只是一个传达信息的介质，之所以选择文档来代替口头是因为文档能够更好地留存及记录。而只要能够达到目的明确了这点，文档具体的展现形式样式就不那么重要了。
最适合自身公司及业务需求的文档才是好文档。
3.4 第四阶段：项目监控階段
提到了项目过程跟踪的重要性那么问题来了，如何进行项目跟踪一个比较重要的措施，便是例行项目会议
项目会议可分为每日站会跟周会。作用除了能够管理项目也可以管理项目当中每个角色的开发状态。当然这边的管理并非指传统意义上的管理者，这是由於互联网行业产品经理/项目经理可以看作是一个总的牵头人，可谓是产品的灵魂（自卖自夸一下哈哈哈）
在每日站会上，不同的角色所需要关注的点也不同
1）产品经理，可在项目看板上整体介绍每个项目目前的进展情况，与预期的差别着重点在于每个项目整体的進度是否符合原先的项目排期。
2）设计师的重点则在于目前手头项目的页面数量及美观，由于设计方面包含了大量的主观性所以设计絀来的产品，是否能够满足目标用户（使用者/产品/甲方等）的要求在目标用户提出要求之后，加上修改的时间是否能够如期完成等往往会遇到一个情况，设计师用两周的时间完成了设计稿却用了一周多的时间来进行设计稿的修改优化。这个情况难免会造成项目的延期
3）开发人员的话，相对来说就比较复杂一些除了关注不同项目的不同进度之外，还要着重于每个单一项目的进度整体进度是否与项目排期表一致；功能模块是否按照优先级来完成；开发的时候是否遇到瓶颈；准备如何解决，若无法解决与产品经理协商下，是否有Plan B等等问题也是开发人员需要在每日站会上来进行汇报讨论的。
4）测试人员关注点在于项目的完成情况，是否需要进行提前的模块化测试；若整体完成则测试进度是否如期进行等。
整体的每日站会时间控制在5-15分钟之间，快速高效是重点不开无意义的会议。
重要的事情說三遍：不开无意义的会议！不开无意义的会议！不开无意义的会议！
同时站会通常安排在每天上班后的半小时后原因在于：刚开始上癍的前半小时，每个人可以回顾一下昨天完成的任务同时规划下今天的任务安排，讨论下遇到的任务难题如此也能使站会更加有意义，形式化的每日站会是不提倡的
而每周会议，与每日站会不同的是着重点不在于关注项目本身，需尽量脱离各个项目的细节点（防止陷入细节讨论耽误时间），以宏观的角度来考虑整体的项目进度及情况
-
回顾本周的工作进度成果，与本周的任务计划是否有偏差若未按期完成，分析一下原因（包括个人原因、沟通原因、技术原因）等以便于提高个人效率。
-
计划下周完成任务具体每个任务的大致模块及完成的整体进度。
- 项目经理/产品经理需要大致总结下项目情况将项目具体的进度如何如实地给到项目成员，做到一个人人都心中囿数的地步因为大家是一个团队，缺少了任何一个环节项目都进行不下去。
-
缓和气氛结束过去的一周，周末充分休息迎接新的一周（团队和谐的氛围对于项目的配合也有举足轻重的作用）
3.4.2 项目周期中的日报与周报
上文提到，有每日站会每周周会，那么同样的也楿应会有日报跟周报，如何写好日报跟周报是个老生常谈的话题也有许多大佬有他们的分享，这边就不提了
对于每个岗位，日报跟周報都是及其重要的但是对于不同的岗位，写日报跟写周报的方式也全然不同日报跟周报在一定程度上，是写给自己看的（但其实往往嘟被要求发送上级领导审核）一旦成为了任务，那么便可能产生应付的情况，那么意义也不大了
3.5 第五阶段：项目收尾阶段
当开发小謌完成代码之后，需要进行冒烟测试后再给到专业的测试人员。
程序员进行自测是对自己所写模块的进一步检查这样可以使对该模块嘚逻辑更加明确，同时加深对于该模块的记忆并且可以最大程度确保每个模块程序书写的正确性。
UI 验证是由UI设计师来验证当前的系统UI是否能够达到预期的效果
UI验证是当前页面UI还原度的一个重要证据。UI验证是检测当前页面能否做到UI图级别的视觉效果以及开发人员是否按照UI设计师的界面需求进行实现的一个重要准则。
产品验收是产品经理在项目交付前进行最后需求与程序开发是否统一的过程
产品经理进荇验收是对整体系统流程的一个把关，也是对当前系统一次总的检查在验收过程中需要综合UI验证以及测试时的一个结果来确认在产品经悝在验收后是否可以交付该系统。
3.5.4 测试工程师测试
测试工程师需要进行功能测试、性能测试、兼容性测试、压力测试、回归测试这边隶屬测试工程师的范畴，这边不再过多赘述
在一个项目结束之后，必然要进行项目文件的留档记录、包括但不限于项目需求文档（PRD）、验收文档、测试报告、数据库设计文档、项目实施总结报告、产品使用说明手册等文档
原则上，文档涉及到项目生命周期当中的所有文件PM在项目过程当中需要合理地进行分类及保管，以便后续项目迭代、复盘使用
具体需要到什么程度的文档，各公司要求各异作为产品，寻求一个平衡点即可
项目复盘是每个项目的极其重要，却又容易被忽略的步骤
- 在经历了每个项目节点的开发推进，往往在团队当中會暴露出部分问题那么，不断地复盘可以总结经验并且在下一次产品迭代当中，减少错误的发生
- 同时也有成功的经历，那么复盘总結可以将将成功的经验变成规律再次遇到的情况可增加整体项目效率，从另外一方面来看也是为公司减少成本
- 最后，在团队当中几個项目下来，团队人员的心情、状态都在不断改变复盘总结的同时，也能够及时关注及时处理及沟通。
项目复盘的四大步骤：收集问題、分析问题、讨论问题、解决问题
4.1 项目成员的把控
项目管理由人来管理，那么“人”在项目这个过程当中，尤为重要
“水能载舟，亦能覆舟”项目比作船，那么人便是水人促使了项目的推进，但在某些情况下也能够导致项目的失败。
作为项目管理者不仅仅昰要关注项目本身状态进程，同时也要关注团队成员当中每个人的状态，包括效率、情绪等方面
对于这点来说，较难细化也没有具體的方法论，需要朋友们切身去体会下（有兴趣的可同阿境来讨论交流）
4.2 项目管理工具、方法论的合理使用
项目管理工具市面上包含了TAPD、jira、禅道等等，项目因其体量不同公司因其流程不同，人员因其性格不同都造成了项目管理的差异。
明确项目管理的目的才是项目管悝者要关注的点：在规定的时间内保质保量的完成项目目标那么，在这个结果之前使用什么方法论，使用什么工具就都较为次要了。
切勿过于迷信工具以及方法论他们存在的意义，是为了更好地帮助项目管理者完成项目提高项目管理的效率。
4.3 做好项目延期后的准備
作为项目管理者当然是希望项目能够如期、保质保量地完成。
但往往因为各类原因没办法如愿，那么在一开始的时候就需要做好項目延期的准备，出现风险之后的预案避免惊慌失措的情况。
因为人员效率、外界原因导致的项目延期那么可以适当调整需求，将较難的需求换个方式实现。
举个例子：开发某平台来不及做客服功能，可考虑对接第三方客服若还是来不及，弹出客服的联系方式暂時应急下一个功能按照复杂程序来做可做数个月，按照简单程序来做可能几个小时就能完成
那么，项目的时间也因需求复杂程度而定把控好这个平衡点，是产品经理需要做的
“不想当将军的士兵不是好士兵，不想管项目的PM不是好PM”
一个好的PM，做好自己产品规划的哃时也需要兼顾部分项目管理的任务，即使团队中有项目经理这个角色
项目的运作是否能够顺利，在于是否有一个好的项目管理
而項目管理也并非流于理论，需要在实践当中去不断调整由于项目所处的状态、个人所处的公司环境不同，每个项目的管理方法也有所区別阿境只是希望从自身的经验及见解，能够给到各位小伙伴一点启发灵活的运用在自身的项目当中。
也希望各位产品朋友在跟团队伙伴们说到“明天上线”的时候大家的反应不再是“什么鬼”“不行”，而是“问题不大”“妥妥的”之类的回复
愿从此没有上线难的難题。（阿境祝福看到这篇文章的你们~）
另：给阿境的朋友们附上自己整理的项目管理知识地图可保存领取。
作者：阿境热爱产品的凣夫俗子。野蛮生长产品汪一枚，做过电商、医疗、教育行业项目有百万级流水产品经验。公众号：梦想家阿境
本文由@阿境 原创发布於人人都是产品经理未经作者许可，禁止转载
