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