做好项目管理对于每个职场人来说都是一件非常重要的事情。笔者根据三年的工作经验，整理出一套自己的方法论，分享给大家，希望能有所帮助~
你为什么写这篇文章？
我从事项目管理大约3年了。从一开始什么都不懂，到现在一直在同时处理很多重点项目。希望可以总结一下，帮助自己梳理出自己的方法论，这样以后就可以更清晰更方便的完成后续的项目交付，也可以为以后总结自己的不足找到依据。
各种项目和各种项目管理方法
“一切都是产品，一切都是项目”
以上是我对一切的理解。每一个“物”都可以理解为一个产品，每一个“物”都可以理解为一个项目。世界上每一件“事”都有自己的处理方式。投入工作，可以理解为各种项目都有各种项目管理方法。
我不赞成用统一的项目管理方法来管理所有的项目，比如工程项目和RD项目、瀑布项目和敏捷项目等等。
事实上，按照细分类别，行业内已经出现了很多项目管理方法论。比如华为有一套“六步一法”的方法论。现在让我介绍一下我总结的项目管理方法。
六个部分和一种方法:
第一步:明确目标，确定范围；第二步:制定主要项目里程碑；第三步:分解项目活动，准备工作计划；第四步:质量控制和实施说明；第五步:制定时间表和场地计划；步骤6:制定区域规划流程；方法一:项目的沟通策略:我写的项目管理方法的分类和内容:
首先，我的行业是软件行业，工作内容是交付项目管理；这类行业的特点是:公司有标准产品，但交付给客户时会接受一些定制开发。
经过长时间的实践，我总结出了自己针对这类行业的项目管理方法:二维四阶段项目管理法。
下面介绍一下这个方法的内容:
四阶段法的用途是什么？
首先，方法论的作用一定是指导工作，所以方法论的使用建议是:在项目的各个阶段规划项目时，按照方法论梳理项目交付过程。
那么方法论有什么用呢？所谓“方法论”，其实就是前人总结出来的经验。积极正确地运用方法论，可以避免工作中大多数“坑”的存在。
什么是二维四级？
二维:内部维度和外部维度。
主要按照利益划分维度，维度主要用于区分利益相关方；内在维度是“自己人”，尤其是与项目利益正相关的人；外在维度是“外人”，尤其是与项目利益负相关的人。
无论是内部维度还是外部维度，都会有帮助项目经理推进项目的关联方，也会有阻碍项目经理推进项目的关联方。因此，在项目启动初期识别各个维度的关联方对于未来的项目交付尤为重要。
四个阶段:启动阶段、方案阶段、RD上线阶段和收尾阶段。
根据不同的目的，将项目交付的不同目的划分为不同的交付阶段，并在每个阶段完成分配的任务，是二维四阶段法的核心。
在日常生活中，人处理事情的步骤基本上是:接到通知要做一件事，知道它要做什么，去做，就做好了。
因此，根据人们的日常习惯，将项目交付分为四个阶段进行管理更加直观和方便。
下图是二维四阶段法的实施流程图:
每个阶段人员的职责:
在项目交付过程中，每一类相关方都有不同的责任。在这种方法中，责任总结如下:
各阶段工作内容简述:
序
与传统的大型项目交付相比，标准产品模块+定制项目交付有很大的不同，不同之处包括但不限于:
传统的大型项目已经成熟，市场上有标准的可交付成果。与传统IT行业相比，交付流程有标准的产品模块，不可能根据客户需求设计交付所有产品。与新兴的SaaS产品互联网公司相比，产品应用环境复杂，功能相对不全，很难直接让客户使用标准的产品功能模式。近年来，它比新成本会计更难。中国出现了数十家以此类项目为主营业务的公司，之所以如此，是因为这类公司希望以项目来养产品，最后成为纯粹的SaaS公司。但由于其特殊的产品类型和复杂的功能，离最终结果还有很长的路要走。
换句话说，这样的标准模块+定制项目还会长期存在。
下面正式介绍一下“二维四阶段”:
初始阶段
“项目”定义为“创造独特产品、服务或成果的临时性工作”，其中“临时性”是指工作必须有确定的开始和结束时间，启动阶段就是定义这个项目的“开始”。
启动阶段的目标是:
将项目负责人从业务上调任项目经理；组织公司内部项目成员和甲方项目利益相关方，成立项目组，确定分工；确认项目的“开始”时间，动员项目组成员开始工作。根据启动阶段的目标，启动阶段需要完成的工作一般包括:项目资料的移交和收集、项目组的成立和项目启动会的组织，其中:
项目资料的移交和收集:主要指项目经理与业务或其他成员之间项目资料的移交和收集。其中，项目信息主要是指:客户的需求、客户的组织结构、客户主要对接的人员和项目利益相关方、客户对本项目的内部期望/目标、客户公司信息和对接人员/部门信息。业务人员可能没有所有的项目信息，所以如果有任何缺失的信息，项目经理和业务人员应该继续收集。
项目资料交接和收集的主要意义是让项目经理从客户公司信息、组织架构信息、成员信息、目标信息等多个维度详细了解客户及其对项目的期望。，以便分析客户相关成员对项目的可能支持。
知己知彼，百战不殆。
组建项目团队:项目需要有人来执行，但项目经理不可能独自完成项目；因此，在项目正式开始之前，需要完成项目组的组建和任务分配。
在这个阶段，新手常见的错误就是只完美的定义了我们公司的项目成员，而没有定义我们客户的项目成员，或者说定义不清晰。这样就会导致项目变更或者客户方需要提供资料的情况下，找不到客户的联系人或者相关负责人，导致项目延期的问题。
所以在确认项目组的时候，除了内部成员之外，还需要详细了解客户的决策者、项目的主要对接人、与决策者的联系人、相关业务的用户等角色是谁，尽量把这些人都纳入项目组成员。或者由客户决策者共同定义和分配这些成员，从而达到建立客户侧项目团队的目的。
项目启动会:当项目数据收集完毕，内部项目组成立，客户端项目组确定后，需要一个“仪式”向所有项目成员宣布项目正式启动。这个“仪式”就是项目启动会。
在项目启动会上，我们需要明确客户方的项目成员，争取更多我们可以调用的资源，所以在项目启动会上，客户的决策者必须到场，我们需要决策者的帮助，帮助我们调动客户方的人力资源。
计划阶段
从启动阶段确定项目何时启动后，就可以进入项目方案阶段了。这一阶段的目标是:
根据合同内容，调查客户的相关要求和期望；需求范围趋同，交付目标统一；确认项目实施和RD计划；双方确认项目“解决方案”。方案阶段主要是确认“怎么做”和“做多少”，所以这个阶段的主要任务是:业务需求调研、项目方案输出、方案输出和确认。
业务需求调研:由于项目需要交付的产品都是toB产品，客户的需求是决定产品形态的最重要因素，因此业务需求调研阶段的工作尤为重要。至于这个阶段的工作为什么叫“业务需求调研”而不是“需求调研”，原因是在了解客户需求的同时，也要了解客户的业务是如何运作的，客户的要求是否能满足客户真实的业务场景。
同时，作为一个专业的项目经理，他需要对整个业务有一个前瞻性的考虑，他还需要结合自己对业务的思考和规划，在调查业务需求时对客户进行适当的引导。
这部分工作主要包括:确定业务需求调研对象，根据客户需求编写业务需求调研内容，实施调研，输出业务需求调研报告，由双方签字或邮件确认。
项目产出:计划是项目正常交付的基础，也是内部项目成员实施项目的标准。
在制定项目计划时，首先根据客户的需求确认各项任务的实施/RD周期和前提条件，然后根据客户的时间预期调整工作，最后输出项目实施计划或项目实施方案供双方确认。
输出:这里的“解决方案”通常指的是“业务解决方案”，即整合了我们自己公司的产品能力和调研时收集的客户的业务需求并最终输出的统一解决方案。
这项任务是整个项目交付过程中最重要的部分。导出此计划的意义在于统一公司内客户和项目成员的目标，限定项目的需求范围和产品形式，避免因前期需求沟通内容不清、合同中需求描述不完善、人员交替等原因造成的需求范围不清的现象。
因为每个公司的产品形态不同，需要的商业解决方案也不同，所以无法详细定义商业解决方案的具体内容。但一般来说，商业方案应该包括项目背景、项目目标、业务需求调研内容、产品设计方案、职能部门/负责人等。，可以根据不同的产品形态有选择地增减。
需要注意的是，商业解决方案中对产品的描述应尽可能表现为高保真的原型图+文字说明，以约束产品细节的边界。同时，商业解决方案必须由决策者签字或通过电子邮件确认后，才能进行下一步的RD工作。否则，一旦发生变化，成本可能会翻倍。
在线阶段
项目经理在上线阶段的主要工作是监督项目成员按照项目计划和解决方案内容，保质保量按时完成开发，并可以交付给客户。因此，这一阶段的目标是:
确保产品按时上线；上线后，客户可以使用。在RD投放阶段，项目经理需要做以下工作:协助项目成员完成产品RD投放，培训客户，投放动员会，签署产品投放确认单。
协助产品RD投放和培训:在产品RD投放过程中，涉及的任务很多，但大部分都是由实施者推动的。相关任务可能包括:
购买和准备RD在线环境；与各个部门持续沟通，如产品经理、RD、测试、运维等。，确保准确的需求沟通；与甲方项目相关人员沟通，收集基本业务信息，完成配置；准备产品手册和功能培训材料等。产品推出动员会:其实大多数情况下，客户对“推出”的理解和我们对“推出”的理解是不一样的。我们认为，当代码在正式环境中部署时，就意味着产品的推出，客户对推出的理解可能是多种多样的。我们需要一个“仪式”来统一我们对“发射”的理解。
同时，产品上线后，由于责任、工作量增加等各种原因，客户的相关成员可能不会正式使用产品功能，使得产品功能交付后无人使用。我们还需要一个正式的产品推介会，向项目的相关成员推广和介绍产品，并通过客户的决策者促进客户方的相关成员使用相关的产品功能。
了解了以上两点关于“产品发布动员会”的作用后，我们就可以组织和发起一个动员会了。动员大会的注意事项如下:
保证甲方决策者的存在，否则很难大概率提拔甲方项目相关成员；尽量保证产品功能的责任分配到人，而不是角色或部门；否则成员会因为责任不清而互相推诿；会后要留下会议纪要、考勤记录等文件的痕迹。同时，项目经理还需要根据合同约束或项目需求安排一些产品功能培训。
签署产品上线确认单:几乎在每一个项目中，产品上线都是项目的关键里程碑，因此确认这项工作的完成也非常重要；
上线产品确认单应详细描述已完成项目和待完成项目，以便于后续工作和项目验收。
关闭阶段
产品上线后，标志着这个项目的完成，但实际上项目最后阶段的工作可能不会少。
因为业务研究阶段和产品开发阶段的研发与产品投放之间有一个时间间隔，很难保证需求100%按照原来的业务解决方案处理。同时，很难保证在初始阶段推出的产品没有缺陷...
在项目的最后阶段，主要目标是:
完成前几个阶段未完成的任务。解决前几个阶段的问题。改进合同中要求的可交付成果。进行项目验收。在项目收尾阶段，项目经理要做的事情归结为一句话——“查漏补缺”。主要工作内容包括:检查和完成未完事项，验收前沟通，工程验收会议，签署工程验收单。
检查并完成未完成的业务:收尾工作80%的主要工作是检查并完成未完成的业务，其中未完成的业务包括:未完成的需求、待解决的bug、未提供的文档、未配置的配置项、未提供的培训等。，无法详细描述。
但需要注意的是，理想状态下，项目经理的主要职责是按照“清单”完成事情。也就是说，在这个阶段，主要目标是完成所谓“清单”的上述要求的未竟事业——即各种合同、需求变更单、补充协议等。
接受前的交流:“中国的社会是人的社会”，即使发展到现在的繁荣，依然逃不过人情世故。
做项目的时候，最难的其实是项目的验收。难的是，即使合同中的内容全部满足，也不一定能满足关键对接人的需求。所以在正式验收之前，一定要组织多次的预验收沟通。沟通的主要内容是了解客户方验收的流程和对本次验收起关键作用的关键人员的想法，并逐一克服，直到整个验收过程中的所有人员都同意项目验收。
至于所有克服的方法，不管是合同谈判、高层施压、利益诱惑还是其他手段，因为对接人的性格特点、当时的形式、项目经理的个人经历，都无法说清；
项目验收会议:当验收前的沟通顺利完成后，项目验收会议就成了一种形式；但即使是正式会议，甲方的决策者也必须出席。毕竟，没有什么比决策者现场做出的决定更有说服力了。
签署项目验收表:项目验收表可以在项目验收会议上当场签署，也可以在会后当天或一周签署。最好不要耽搁太久。
当工程接收证书签署后，就意味着工程的交付已经完成，项目经理可以和业务一起移交工程了。交接的主要目的是让业务继续跟进工程款和是否有二次销售机会。
至此，二维四阶段投放法已经全部介绍完毕，篇幅有限，无法一一展开所有细节。只能说交付过程中最关键的节点，特殊细节后面继续分享~
本文由@李强原创发布~人人都是产品经理。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
