“管理是一种实践，其本质不在于知，而在于行”——彼得·德鲁克

作为一名初入职场的校招生，你是否有过这样的疑问：项目经理究竟扮演着怎样的角色？是老板的传声筒，单纯地传达上级的指令？还是团队的监工，专注于监督和追踪每个人的工作进度？抑或是项目的一块砖，哪里需要哪里搬？当然，上传下达、监督进度以及解决问题确实是项目经理职责的一部分，但是项目经理仅仅是做这些的吗？在基础流程之上我们还需要学会哪些技能？我们的职责定位是什么？我们如何展开管理工作而避免被项目成员当作以上三种角色？接下来我将从具体执行的视角，讲述一些我的思考和感受。全文内容主要围绕五大过程组之中的启动、规划、执行和监控四个部分来进行整理和分享，希望可以给同是校招生的你带来一些共鸣和启发！

一、项目管理，我们的职责是什么？

每一个岗位都有其特定职责，详细的包含了员工所需要负责的具体工作任务，它指导了员工应该“怎么做”。那么项目经理的职责是什么呢？我认为，首先是项目的交付，在此之上是价值和收益的交付，并从关注事的维度转变为关注人的维度，助力组织能力的建设。

交付项目是项目经理工作的基础，助力达成项目目标。为了交付项目，项目经理需要去监督项目的进展，完成内部的上传下达，帮助解决项目推进过程中的问题并交付项目成果。

交付项目的基础上，更高阶的项目经理可以带领项目组交付更高的价值和收益。处于此阶段的项目经理具备了一定的战略管理能力，可以从较高层次审视项目并引导项目向着更有利于组织发展的方向推进。

交付更高的价值和收益的同时，项目经理也需要关注团队的管理，助力组织能力建设。其一，关注团队成长。项目经理在推进的过程中，需要有意识的了解团队成员，包括但不限于他们的能力和性格，以便更高效的进行资源优化和配置。同时每一个项目从组建走向成熟，都会经历组建期、冲突期、规范期、成熟期四个阶段，项目经理需要在每个阶段重点关注团队的成长。其二，强化项目管理与执行能力，形成固定节奏。每个团队都有能力范围和边界，项目经理需要敏感的抓住团队的吞吐量。让团队形成固定的工作节奏，然后根据指定的里程碑，让团队在实现一个个里程碑的过程中松弛有度。

二、项目管理，我们如何开展工作

（一）项目启动

在项目启动初期，我可能会思考以下几个问题：如何制定项目目标，制定项目目标后如何拆解达成目标的路径以及如何整合团队共同朝着目标前进。对于新手项目经理来说，盲目的推进项目可能会失去项目节奏。我们可能会面对这种情况，项目的相关成员提出许多需求希望放在项目里推进，但是一部分是有利于项目的，一部分可能不会对项目的目标达成产生关键作用。如果预计在目标达成的路径中，某个需求并不会起到关键作用，那么我们就需要谨慎对待，邀请相关方共同评估。如果将完成项目的过程比作盖房子，那么我们首先需要打好地基和骨架，方才能在之上添砖加瓦。

1.明确项目目标——敏捷铁三角+SMART

制定目标的基本原则

SMART原则：项目目标一定要是清晰明确的、可衡量的、可实现的、与业务整体目标相关的以及保证时限的。同时我们在制定目标的时候也要注意它是否具有挑战性，如果在项目复盘的情况下发现完成度超出原定目标过多，可能就存在目标制定合理度的考量。

敏捷铁三角原则：项目最直接的目标=项目价值+质量保证+特定约束（范围+时间），在特定约束条件下，控制产品遗留隐患对交付产品的使用及维护的影响，关注人员能力提升，尽可能将项目/产品价值最大化。

• 约束目标：敏捷铁三角的基本前提，项目的目标应该是在约束的条件下（如时间、资源有限等情况），达成价值目标和质量目标。
• 价值+能力目标：将项目的价值最大化是项目管理的主导因素，不同类型的项目会有不同的价值目标，但它们有一个共同点，就是项目价值是站在组织而不是项目的角度来看的。
• 质量目标：相比于传统铁三角，敏捷项目铁三角更加关注于目标达成/交付产品的质量。

图1 项目目标SMART原则和敏捷铁三角原则

总的来说，当了解到项目受到的时间和资源上的限制的前提下，完成项目产品的交付，达成对组织目标有利的指标，且能够保证项目交付产品的质量，就完成了对一个项目的项目目标的初步制定。

2.思考项目达成路径框架——把控项目节奏

项目立项必定承载着某些期许，无论是业务指标的提升抑或是产品能力的建设。我会经常问我自己几个问题：这个项目目标对于我们搜推有什么价值？这个项目目标对业务侧有什么价值？在搜推场域来开展这个项目跟在其他场域开展项目存在哪些优势？例如在我负责的项目中，我负责的是在搜推场某些产品能力的建设，我们就需要制定这样一个达成目标的框架：建设基础的产品能力——为该产品能力寻找一个核心的点（我们的优势）进行迭代——运用我们的优势能力和收益数据在事业部内进行宣讲——获得更多事业部的加入和支持——提高业务指标并达成项目目标。有了整体框架之后，我们就可以顺着主要框架对项目进行推进。

3.识别干系人——因人制宜

在项目初期，项目经理如何识别项目的干系人

• 第一，确认核心干系人。干系人是指参与项目活动和受项目影响的人或群体。例如项目的交付形式是产品功能，那么核心干系人就包含项目的Owner、主产品、运营、核心的研发同学等。
• 第二，在确定核心干系人之后，由核心干系人识别出其他相关参与方。例如产品可能分为前台产品、分发产品、以及平台产品等。从项目经理的视角来看，即便项目需要交付的只是一个前台产品形态的改变，但是其背后可能涉及到分发产品以及平台产品的参与，这些项目干系人需要由整个核心干系人团队来进行识别。同时向我们提需的业务方应该也属于相关干系人，业务方可能来自于品类和事业部，也可能来自于用增平台。当我们的开发依赖于其他产品能力，需要我们向其他项目组提需，那么支撑平台的产品同学和研发同学也属于我们的相关干系人。一种特殊情况是测试同学，由于测试同学属于流动资源，需要进行申请资源，所以在项目组内也处于相关干系人的地位。
• 第三，确认干系人的原则是不放过任何一个环节。尤其是在产品需求评审的环节，有一些产品功能可能仅仅需要自测就可以，但是有一些产品需求需要测试同学的加入。由于测试是流动资源，在产品功能开发完成后再去申请会很被动，因此在项目初期，项目经理一定要确认是否需要测试资源，并在一开始就邀请测试同学参与其中。

图2 识别干系人

项目经理如何管理项目的干系人——识别项目成员的性格特征

例如在我接手的项目中，产品经理偏向互动型，因此要随时给予肯定并表达友好，让他意识到你在随时帮助推进这个项目，同时在他面对压力的时候尽量少去打扰。研发偏向稳健型，因此需要尽量在项目初期尽可能准确的识别研发的开发工作，尽量减少其开发任务的变动，同时在研发遇到困难的时候要及时帮助他们做出决策，多给予肯定。测试同学偏向谨慎型和稳健型的中间态，既对项目有高标准，比较追求细节，但是同时也很有责任心，会主动为项目提供支持。当然每一个项目组的干系人均有不同的性格特征和处事方法，想要在项目前期就根据项目成员的性格特征来制定计划依赖于丰富的项目经验。

图3 项目干系人性格判断图

（二）项目规划

1.范围管理——拆解需求跟踪矩阵

范围管理原则

• 敏捷原则。对于需求不断变化、风险较大或者不确定性较高的项目，在项目开始时通常无法明确项目范围，而通过在项目进行期间通过多次迭代确定项目范围。但是注意一旦项目立项成功，起码要确定第一个Q的项目范围，通过对第一个Q的项目进展以及成果进行复盘，再迭代确认后续的项目范围。

拆解需求跟踪矩阵

（1）WBS需求跟踪矩阵

• 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格，跟踪从需求到设计、从设计到编码、从编码到测试，从测试到可交付成果的全流程映射过程。上述需求跟踪矩阵适用于一个项目可以拆解多个需求的情况下。

（2）WBS拆解步骤

• 提出具体需求：根据产品需求来源的两种不同方式，获取初始需求文档。
• 需求确认：所有项目的参与人员举行会议讨论需求，确认所有主要的项目工作，确认项目工作分解的方式。
• 制作详细的WBS分解：将项目目标需求进行详细分解，详细到可以根据各个工作包进行估算用时、安排进度、分配负责人等。
• WBS更新：随时其他计划活动的进行，不断地对WBS进行更新和修正，直到覆盖所有工作。

图4 WBS需求拆解表

当出现项目范围蔓延时，应该怎么做

• 首先要明确范围的蔓延来源。一般范围的蔓延主要有两种：一是需求本身考虑不周全，在开发过程中不断进行修改，导致需求范围蔓延；二是管理层会单独给负责具体执行的开发人员提额外需求。
• 针对第一点，需要我们在立项之初就明确需求，所有的分析需要以业务为导向且围绕项目目标进行。同时建立必要的变更流程，要求变更流程必须经过上级审批，将变更控制提升到一定高度，以增加变更的成本，从根本上控制需求范围的蔓延。
• 针对第二点，当管理层提出需求的时候，项目经理需要首先与管理层做充分的沟通，了解需求背后的原因和期望，如果是确实会对指标产生巨大影响的变更，首先要跟领导确认是否可以等待下一个版本进行迭代开发，如果比较紧急，那就需要明确修改的工作量，跟项目团队进行评估给出可行性意见或方案，并同步到管理层修改并调整预期和变化。

2.进度管理——关键路径明确总体时间线

关键路径分析

可用来预测整个项目的持续时间。项目的关键路径是决定项目最早完成时间的一系列活动，是通过网络图的最长路径。例如下图共有四条路径可以达到目标8，耗时分别是14、16、9、14，因此B-E-H-J时间最长，为项目的关键路径。

图5 关键路径分析

一些进度管理的关注点——测试资源提前参与的重要性

项目经理必须让所有的干系人参与到进度制定的过程，尤其测试同学。例如在我接手的项目中测试环节出现了非常多的坑，有一部分原因就是在产品设计后期，才有测试资源进入，在产品需求评审的环节没有测试同学参加，导致后期测试进入了解背景花费了一定的时间，也忽略了一些本可以在需求评审环节可以识别的坑。

（三）项目执行

1.进度管理——Delay怎么办

当开发时间不足的时候，或者出现临时风险导致不能按时完成项目交付物交付的时候，项目经理应该怎么做？

例如在我的项目的推进过程中，第一期产品要求729前台联调、731整体联调，813上线。但是在26号当天，保障前台正常开发的前置依赖均没有ready，导致前台联调时间可能受到影响，此时可以采取以下做法：

• 第一，快速跟进，并行施工，以缩短关键路径的长度。例如要求算法同学同时进行开发，如果有前置依赖的可以先开发算法逻辑，待前置依赖ready立马进入开发进程。在项目过程中存在着依赖关系，有些是强制性依赖关系，有些是自由依赖关系，这些依赖关系使得项目之间存在着先后次序，在进度落后的情况下我们可以打破这种先后次序，使得某些活动重叠进行。当然，打破这些次序大多数情况下会对项目产品的质量带来风险，但是自由依赖关系则不存在这个问题，因此可以首先调整那些自由依赖关系的活动，然后再考虑强制性依赖关系的活动。
• 第二，经产品（负责人）同意，减少活动范围或降低活动要求。例如在测试过程中，可以采用mock数据进行测试。保证开发项均能在对应时间内开发完成，但是由于时间原因缺少的数据采用虚拟数据进行测试。
• 第三，赶工，投入更多资源或增加工作时间。找到项目卡点同学，找到他的老板拉会，要求该同学赶工加班完成工作。但是我认为最管用的方法还是：大家线上会议共同操作，在群里的沟通总是存在一定的滞后性，导致进展频频延迟。
• 第四，如果真的由于各种原因导致需求不能上线，可以申请延期集成/服务端先走紧急上线流程xbp审批，写风险邮件报备（不提倡）。

图6 赶工及快速跟进对比

进度管理之封闭开发

在项目进行过程中，如果交付周期不足，则需要经过C2决策是否需要进入封闭开发状态。封闭开发状态过程中，首先需要确定封闭期间内的详细排期，具体格式如下表所示。将需要开发的项目划分为若干个不同项，细化至具体的负责人，并规划排期。

图7 封闭开发排期安排

在正式进入封闭开发后，需要每天check进度。需要由项目经理将每日每人的工作量划分清楚，出一个checklist表格，记录开发进度以及出现的风险问题。进度填报由项目经理每天晚上18：00小窗大家，或是以日会形式（15分钟以内）快速对一下进度。（日会可能会导致研发人员额外工作量，大家配合度不高，建议当每一个开发项结束当天晚上check对应开发同学，确保开发项按时交付）

图8 封闭开发日会

2.风险管理——解决项目问题

项目风险来源

• 产品功能中耦合其他系统能力：当项目需要实现的产品功能需要另一套产品能力时，很容易受到其影响，例如依赖的产品能力延迟上线或是中间出现bug，都会对项目产品造成影响。对于项目经理来说，应该在方案制定的过程中尽量减少对其他系统的依赖和耦合，在项目开发时长确实不够不得不依赖于另一套产品功能的情况下，应该尽量留出风险响应时间和Plan B，降低项目风险。
• 项目干系人的影响：项目经理应该根据项目干系人的能力感知对其可能出现的风险进行预判。例如有项目干系人工作的颗粒度较大，完成的工作内容不够仔细导致在一期迭代内出现过问题，那么项目经理就应该在其之后的工作中多加提醒，在后续迭代过程中更加关注其之前出现过问题的部分。

新人项目经理如何识别项目风险，可以用到哪些方法

• 头脑风暴：风险的识别依赖于整个团队共同产出。在制定计划的时候，项目经理应该尽可能全面的识别相关方进行风险识别。此时就可以用到关键链进度管理方法，为风险预留出缓冲时间，保障项目成果按时交付。
• 非正式沟通：心理学认为单独工作的个人所产生的想法要比通过面对面的小型小组进行头脑风暴产生的想法多。由于团体效应的存在，个人害怕社会上的不赞成、权力阶层的影响以及一两个强势的声音，通常会抑制许多参与者的想法产生。因此项目经理可以与项目的核心技术成员通过线下one one闲聊的形式，获取更多与项目风险有关的信息。
• 做好项目复盘工作：对于新入门的项目经理，往往不具备那么多的经验去识别风险。因此需要在每一个团队识别到风险后记录在风险登记册上，同时也要记录开发过程中遇到的每一个问题，一个问题就可能对应未来的一次风险。通过不断地积累，项目经理就可以在以后的项目过程中更好的做好风险识别和预判。

当项目进行过程中出现项目成员上报风险，项目经理应该如何去处理

• 先确认是否真的存在风险。在项目成员报风险之后，项目经理需要先多方确定确实出现了风险。然后项目经理需要向风险提报者提问几个问题：风险是什么原因造成的？该风险涉及到的相关方有哪些？风险会带来什么样的后果？
• 风险排查：如果风险提报者无法回复第一个问题，也就是说风险原因还需要排查。那么此时项目经理由于得到的都是碎片化的信息，可能也无法准确的判断风险原因。这时候就需要向风险提报者确认该风险的相关方，大概率就是开发这项产品功能的研发上下游、产品以及测试同学。项目经理可以通过快速短会的方式定位问题所在。
• 风险影响：风险可能会导致产品功能延期上线等一系列后果，项目经理应该在相关同学报出风险后，及时询问风险可能带来的最严肃的后果。如果该风险影响较大，应及时上升。
• 风险规避：当项目组提前识别到一些风险可能存在的情况下，可以采取风险规避的方式消除风险。例如识别到产品功能对另一项能力的依赖，但是两个系统的耦合可能会带来问题，那么在进行产品设计的时候我们也许可以尝试自行开发该项能力来规避风险。但是可能带来的结果是开发时间延长。
• 风险接受：如果相关同学提到风险是项目可以接受的，那就进行风险报备后同步进行风险问题修正，但是不会影响项目进展。

项目经理的职责定位就是解决项目中的问题，以便团队更好的完成既定目标，但是项目经理应该如何来解决问题呢

• 收集项目信息：当你掌握足够的信息的时候，你才有足够的话语权。很多时候项目没办法很好的开展的原因不一定是团队的不配合，或许是因为作为项目经理，你掌握的信息太少了。因此项目经理接触一个项目的首要任务应该是收集项目信息，如果负责的是多个项目，还需要对项目的优先级进行排序，根据排序来收集项目信息。那么如何来获取项目信息呢？

主动获取，一是自己对业务要花时间了解，通过核实目标（相信团队，但必须核实），对齐计划、进度来了解；二是可以通过例会制度（比如周会），由团队成员汇报，项目经理整合汇报的内容，从而获取到有效的信息；三是主动和高层领导沟通汇报项目的情况。之所以要主动和高层领导沟通，是要不定期地了解他们对项目的期望，因为他们的期望往往会对项目的目标造成影响。

被动获取，主要依赖于团队的阶段和成熟度，由团队成员主动同步项目的信息，或进度，或风险。团队组建初期和冲突期，项目经理可以根据团队的特点建立必要的规则，其中一条就包括：当出现目标无法按时完成，或者过程中出现问题时，应及时和项目经理同步。团队规范期和成熟期，可以逐步物色团队中有项目管理意识的成员，赋予模块负责人或者特性负责人的职责，由他们来和项目经理同步项目的相关事项。

• 产生解决问题的方案：比如在收集信息中，发现了有团队成员反馈：需求频繁变更。界定确实是需求有变更，那么要明确变更的根因。若根本原因是需求变更流程混乱，执行不到位，那对应的解决方案是要对需求变更流程进行必要的优化。同时对于领导关心的问题，最好是给出两个方案，并且分析两个方案的优劣，提供充足的信息，这样在汇报沟通的时候，让上层领导做选择题，更好地进行决策。
• 解决方案的跟进：方案的落地执行，项目经理还有一个持续跟进的过程。尤其是团队组建初期的时候，项目经理跟进的到位与否，会直接影响方案落地执行的结果。

3.沟通管理——微权力下提高领导力

作为一个刚入职的项目经理，当你处于有责无权力的情况下，应该如何开展项目管理

• 项目经理尽量不要作为专家参与具体交付的工作，尽量只专注于项目管理的工作。
• 项目经理需要学会“借力”：当初入职场的项目经理没有权利去命令大家做一些事情的时候，此时可以借助”领导“的能力。很多时候领导者缺少信息来源，项目经理有一个重要的职责是提供信息给领导做决策，因此项目经理可以通过汇报的方式影响领导的认知和决策，进一步督促大家开展工作。
• 向上管理：为了说服上级支持自己的工作并且帮助自己解决有挑战性的问题，项目经理在进行汇报前应该站在领导的高度思考自己的问题并给出解决方案，尤其注意在汇报的时候要讲清楚背景后，再给出解决方案，领导应该做出的是选择题而不是问答题。同时项目经理在项目初始阶段，切记单纯附和领导的期望而做出过度承诺，一次项目的失败很有可能影响你与领导之间的信任基础。在和领导沟通时，要尝试用领导能接受的方式降低上级的期望值，例如在肯定上级想法的同时提出自己对项目的担忧，即项目风险。
• 全方面学习：我认为项目经理需要不断扩展自己的知识面，但不求精。我们需要把自己的知识领域从点扩展到线，再扩展到面。只有更方面的知识都懂一些，并能够把知识串联成一个体系，在遇到问题的时候才能够迅速给出解决办法，在跟技术人员或者是产品开会解决问题的时候，才能够搞懂他们的解决问题的逻辑。如果连他们的话都听不懂，何谈去解决和推动。
• 擅用领导力：领导力不同于管理能力的有：管理能力是直接利用职位权力，而领导力则是利用关系的力量指导与发挥影响并进行合作。领导力要求项目经理关注长期愿景、维护人际关系、激发团队人员的信任。所以在项目初期，项目经理应该尽量快速的帮助产品和运营同学推进难点，建立自己的影响力。在很多项目管理的书籍中都有提到过，当项目经理过于依赖使用权力、金钱或者惩罚来影响人们，项目很有可能会失败，但是当项目经理用愿景和专业知识来影响员工，员工成功的可能性更大。

项目经理如何顺利的开展一次会议

• 第一，确认相关干系人。如果项目经理无法确认所有会议需要的干系人，可以请核心干系人帮忙补充。在会前项目经理应该与主要的干系人沟通本次会议，同时周知次要干系人如有需要临时上会，防止会议时突然叫人比较难。
• 第二，介绍会议背景。会议背景可以是项目的背景、目前的进展、目前遇到的问题等等。背景应该以以下原则进行介绍：先介绍大背景（例如集团战略规划、项目立项原因、项目面临风险等），再介绍本次会议的目标。在介绍过背景后，可以请相关同学补充。
• 第三，介绍完背景后要描述具体动作。包括现在正在推进的需求、为了达成项目目标采取的举措、乃至面对风险项目经理的解决办法等。项目经理需要让所有的相关方了解其自己的打算，先给出一种解决办法，接下来再que对应人补充细节。
• 最后，进行会议的过程中，很容易发生参会人员思维发散的情况，这时候项目经理应该及时将话题收敛，保障会议按照目标进行。

项目经理如何进行一次汇报

（1）项目汇报原则SOP——SCQA模型

• 情景：描述当前背景或者环境
• 冲突：指出主要问题或挑战
• 问题：提出关键问题
• 答案：给出解决方案或建议

（2）项目汇报类别

• 日常报告：进展+未来计划
• 紧急事项汇报：对于紧急突发事件，项目经理应该遵循及时不隐瞒、结论先行的原则。汇报内容应该包含当前遇到问题及影响、问题出现的原因、解决方案、目前做出的努力、希望得到的帮助与支持等。

图9 汇报流程总结

4.变更管理——变更管理流程

当项目推进过程中，出现需求变更的要求，项目经理应该如何解决

• 原则是非必要情况不变更。当项目进行过程中确实出现计划排期外的、紧急需要开发的内容时，在研发上报该变更点之后，应该先跟对应的产品同学确认该更改是否必要进行，将涉及到该处变更的相关方全部拉入一个讨论组，共同商议变更事宜。（按照经验来说，很大一部分的变更都可以不做，或者说使用现有能力来完成。）
• 为小的变更制定一个快速决策的过程。
• 较大的变更需要上升+1、+2。

图10 变更流程

（四）项目监控

项目周会

项目监控是一个针对项目目标来衡量进展情况、监测计划的偏离程度，并采取纠正措施使项目进展与计划相匹配的过程。在每次周会前，需要完成以下几点工作：

• 根据参会主要人员的日程安排周会、日会时间，并提前预定会议室
• 在参会前一天提醒全体提报议题
• 在会议当天，会议开始前艾特相关提报议题的人员按时参会
• 会议结束后及时填写会议纪要，24小时内发到各个参会人邮箱，同时及时跟进待决策项

最后，我想说的是，项目管理是一门实践的学问，经历的越多，积累的经验就越多，就会本能的规避很多的风险和问题。实践伴随着不断的学习，才是一个项目经理可以最快成长的方式。我们应该把70%的时间应用在项目的实践上，通过不停的思考和复盘项目推进过程中遇到的问题，将现有的经验应用到未来项目的推进中；20%的时间用来跟有经验的项目经理、业务同学、技术同学沟通、交流，借鉴他们处理问题的思路并从中吸取经验；10%的时间用来学习项目管理的基础知识体系框架，并阅读相关书籍，从中学习他人的思路和想法。总之，项目经理从菜鸟到优秀，知行合一是必经之路，愿我们每一位项目经理，都可以成为知行合一的项目管理者！