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