项目管理，没有你想象中那么简单

今年7月到9月，在上千位参与者的陪伴下，为友“教育科技职业的N种可能”系列“线上会友厅”火热开展。听到嘉宾高质量的分享、看到大家积极的反馈，我们决定把这八场“线上会友厅”的干货内容以文字形式整理出来，供大家回顾及收藏。

今天，我们想和大家分享“项目管理”的相关话题，带来这场分享的是拥有11年项目管理经验的小丽与曾任清华研究所学术项目主管的Cedric。希望获得完整直播回放的小伙伴，记得在文末查看回放领取方式哦！

或许你对“项目管理”这个概念还有些陌生，不要担心，先看看这篇分享的大纲。读完这篇文章，相信你会有所收获。 

小丽

11年教育从业经验

6年智适应教育项目管理及运营

PMP认证项目经理

Cedric Wang

港股上市公司运营专家

原清华研究所学术项目主管

从课程产品规划设计、开发管理到交付运营，在教培行业持续学习成长

勤勤：首先我们来聊一下当我们谈论“项目管理”时，我们到底在谈论什么？项目管理到底是做什么的？不同公司的项目管理职能，工作内容和方式有何不同？

小丽：PMBOK前几个版对项目管理进行拆分，从立项、项目章程、项目启动会议，再到中间所有的过程管理，都属于项目管理的范围。针对其中的每一个环节，项目管理需要定义活动、分析排期前后的依赖关系、有效识别风险、与项目干系人进行同步、确定信息同步的渠道等。具体可以参考“十五至尊图”。

（源自：第五版PMBOK）

以上是书本对项目管理的一个大而全的定义，但在实际操作中，不同的组织架构会影响项目管理的权限。例如，我在上一家公司做项目管理时，会涉及到采购，但现在公司的项目管理属于内部管理，通常不涉及对外采购（外包情况还是需要的），其实就没有采购管理这个环节。

我在准备这场分享的时候，发现新版PMBOK对这张“至尊图”的整体架构做了一个调整。第五版按照知识领域作划分：每一个步骤你应该做什么，你的输入是什么、你的输出是什么。在第七版中，它有一种“以终为始”的脉络：它以你具体的项目产出，或者是你对什么东西负责为划分，再去反推在这个过程当中需要准备什么。所以它的逻辑是把不同领域的项目管理工作进行了整合，清晰地展示为了达到最后的交付，项目管理应该涉及到哪些内容。
勤勤：公司架构的不同，内部管理的模式也各不相同。那在这种状况下，其实项目经理或者项目管理的职能也有挺大的差别。两位嘉宾是否可以聊一下你所在不同组织对项目经历职能的影响？ Cedric：我经历过大中型公司，也在各种小创业团队待过。我觉得在小公司、小团队中，其实一个项目经理的权限挺高的，尤其是创业团队，第三方线上管理工具很丰富，各种目标对齐也都特别方便。大公司确实会有纯做项目管理的部门，工作职责就是一个一个的带项目。对于这类项目管理，其实也大致可以分为两种，一个偏产研类的项目管理，开发完一个App或功能再去开发下一个；另一种是偏交付的项目管理，更多是面向客户交付一个项目，角色更偏向售前或和售前为一体，负责从售前解决方案到最终交付的整套流程。 从个人体感讲，最好的肯定是创业小团队，各方面协同合作都特别方便、特别容易、特别快。对于比较大的集团型公司，交付项目的过程有些重复，一个一个项目的交付或者一个一个产品的开发运营，没有自己在创业团队从零起步去做来得有意思。当然，如果公司有新业务、想做一些新产品、甚至是新的压根没有成熟流程的东西，做起项目管理会比较有意思和有挑战。可以体验到前期与上级对齐目标、跟相关方评估可用资源、画各种流程图、争取资源等全流程。
小丽：我自己其实也是从大公司的小螺丝钉、单个项目PM 做起的，对这个问题感受还是蛮强烈的。因为在大公司做项目管理的时候，需要向PMO汇报，要告诉大家这个项目的进程是什么、需要什么样的资源支持、要人要钱要时间。而对于现在的创业型团队，项目负责人本身的自主权比较大，不管是分配项目资源、还是划分项目的侧重点。

进现在这家创业公司的时候，研发部门只有三个人，我是第一个被招进来在做项目管理岗的人。所以在后面实际的运行过程中，我发现如果单纯只盯一个项目的话，不能满足公司对项目管理的要求。所以人员架构也发生了变化，从管理单个项目的PM到多个项目的PM，再到开始培养内部兼职的PM。

我们的项目多属于跨部门协作，所以兼任PM就需要向多方汇报，一方面需要和自己行政职级上的老板汇报，另一方面还要跟项目成员同步近期是否有一些变化。这个同步很重要，项目成员需要了解到决策转变背后的原因，这也需要一些技巧。

（直播分享PPT，由嘉宾提供）

勤勤：那我也来分享一下我自己经历过的项目管理。我之前是在一家美国的教育科技公司，采用的是agile的项目合作模式，国内称之为“敏捷开发”。对于平台型产品，一个 scrum team （项目团队）中包括1~2个产品经理、若干开发工程师、若干测试工程师、和一个scrum master。这里的 scrum master 在很大程度上类似项目经理的一个角色。在我们公司，所有的 scrum master 会汇总在一个 PMO （Program Management Office）部门下面，他们会负责协调和调度整个公司的这些项目所需的一些资源，并作时间线的这个整合，对这个项目的交付去负责。

这也是一个很明显的矩阵性架构：所有的工程师汇报给开发经理，产品汇报给产品总监，可能还有一些用户体验的人汇报给这一领域的专家，而同时也有横向的项目管理团队。整个团队按照agile的方法论去做项目管理，比如两周作为一个 sprint （迭代期），每个人在每天的stand-up meeting 中汇报昨日工作内容、今日计划工作内容、是否被 block 等，以此确保所有人都同步到所有的信息。在每个sprint的结尾，我们会有一次总结，并计划下一个两周sprint做什么。总体而言是个不断循环往复的项目推进过程，也是大公司中一种较为成熟的项目管理形式。

勤勤：项目管理的很多方法论对日常生活也很有帮助，结合案例分享，两位是否可以聊一下如何有效进行项目范围管理？就我个人经验而言，经常出现项目范围不断扩大的情况。有时我们想到一个新点子，就把它加进来，然后想到一个新机会，也把它加进来，然后这样永远加下去永远完不成任务。

小丽：就像勤勤所说，项目进展时会有非常多的 idea ，导致项目范围无限蔓延。那在控制范围上，首先需要所有人都要约定好，不管是 CEO 、总监、还是项目成员，都需要确定本次项目的目标123是什么，并且以正式的邮件发出去确认。如果再有新的想法，我们可以把它记录下来，放在需求池中，一期项目结束后，专门开项目需求的评估会议，把这个池子的东西捞出来看看，再按照优先级慢慢填补进去，这个过程其实相对会比较好一点。

举个例子，比如老板定了一个非常大的目标，说我们要做一辆特斯拉。那这个特斯拉首先要实现的目标是在大街上走。那一期目标并不是打造车的框架、制定每个零件或者螺丝钉。我们可能一开始的目标是先做个自行车，等确保能走了再把自行车变成一个三轮车。产品形态虽然会发生变化，但是我的终极目标是确定的。我知道我的目标是一辆特斯拉，我只是从三个轮的变成四个轮的，从原来那种比较难看的造型再变成一个好看的样子。后续的一些功能，例如人工智能导航、倒车影像，在初期或者一期项目是非必要的。

所以其实项目经理的一个非常大的挑战就是控制这些范围的变更和边界。这里，我认为项目经理需要做到“有条件的接受和无条件的拒绝”。

“无条件的拒绝”是指：一旦出现你认为非常不合理的需求，比如严重偏离预期目标，不管提需求的角色是谁，必须无条件地拒绝，因为如果项目发起人授权给项目经理管理这个事情，就必须相信项目经理的专业性。

“有条件的接受”是指：其实项目经理给成本、时间、资源都留了一个冗余值。如果你在中间有一些弹性的调整，这是 OK 的。如果你想要 A ，你就必须能够接受B 的延期、或者我在资源上的倾斜。这个也是沟通技巧。

勤勤：今天的听众我觉得大部分都不是做项目经理的，但是我听完这个特别有共鸣。这让我联想到自己对个人代办事项的管理。我在做自己每周计划的时候，会留大概 20% 的自由度，以此防止那些突然出现的任务。对于这些突然出现的任务，我也会评估这件事情是不是真的非得这周做？如果我塞了之后，肯定需要挤走一些我这周本来可能计划的事情，那我要挤哪些东西出去？然后如果不是必须做的话，我就把它往后排。所以这就相当于我对本周工作范围的一个管理。我曾经也会给自己排特别多事，但当突然来一堆必须我做这周做完的一些任务的时候，我就会非常难受，所以我后来会慢慢不断地调整，并找到一个比较稳定的状态。

勤勤：那我们说了这个项目范围管理，接下来聊一下项目的时间管理吧，也可以分享一下相关的小工具。

小丽：我在上一家公司时，项目团队每天都要提交周报和日报。日报要求所有人填写一天 8 个小时分别分配给哪些项目以及时间比例如何。最后就能输出一个较为完整的项目成本。假设说实际工时比预计超出了十多个小时，我们就要去看在哪个环节上是可以节省时间的。

实际时间管理的过程中，由于团队资源共享，我们一定会有小伙伴同时在多个项目中。那就需要和他沟通并争取他的时间。他会首先告诉我能分配在我的项目上的时间。

工具方面的话可以用钉钉或者其他平台的项目管理表、任务管理工具等。比如有些工具可以分配任务到个人，并且可以设置自定义提醒。另一方面，我觉得在做项目排期时，需要清楚哪些内容是可以并行的。比如我在和A沟通时，我的另一些团队成员已经在准备他们负责的内容。而且我最近惊奇地发现，现在的小学数学题，已经出现了类似的时间管理训练，比如“洗脸几分钟，刷牙几分钟，背单词几分钟，吃早饭几分钟，问你最快可以多长时间出门”，其实这就是项目管理当中非常重要的时间管理的思维。

Cedric：我想到分享的工具是XMind。你在头脑风暴时，会记录这个项目到底是有哪些维度、哪些相关部门，你可以把每一条小记录定上预期开始日期、任务周期，XMind高级版可以帮你一键转成一个甘特图。就我个人而言，我觉得甘特图适合人员多且杂的项目，而对于稍微简单点或者很成体系的项目，可能图的意义就有限了。

 （直播分享PPT，由嘉宾提供）

小丽：早期的项目管理工具是离线的，包括XMind的甘特图，只有创建者每天在盯这个文件、更新它的状况。现在像飞书的多维表格、钉钉、 Worktile等，更加类似一个线上合作的项目看板，所有的项目成员都能看到自己所处的项目环节、上下游对自己的期望等。这个对于项目成员来说还是蛮重要的。

此外，项目管理很重要的一点是有仪式感。不管是项目的启动、里程碑还是结束，一定要有仪式感，尤其在跨部门协作的时候。

Cedric：小丽提到的设置仪式感是个很好的建议，我也会想应用在之后的项目管理中。在这里我还想给大家介绍一下流程图。流程图可以帮助我给各个角色分配任务、分配他们的上下游关系、争取资源、并且把他们对齐。每个人的职责、上下游确认之后，出了问题去找谁就清楚了。

勤勤：关于项目团队，我们可以先聊下如何搭建架构，再聊聊怎么去管理团队、保证这个团队能够持续地向着这个项目目标推进。

小丽：我们现在的团队角色很多元，有老师、产品经理、开发、测试、技术，也有我们交付给市场外面的这一些业务方。为了保证项目有序推进，在整个项目过程中，我们会有几次比较大的时间节点，一定会把所有人召集在一起。这也是我刚才提到的“仪式感”。我们会在项目启动大会上告诉大家项目背景和预期产出，项目中期会有项目评审会，最后产品交付的验收会议后，我们可能会非正式地做一个小型的项目团建。

有些人会开玩笑说“项目经理在整个的项目的过程当中没有做任何实际的活，因为开发其实有开发的小伙伴在做，产品设计有产品经理在做”，我们内部也有个段子说“项目经理就是活儿你们干，背锅我来”。其实这都说明项目经理要对整个项目的成功与否负责任。所以我会和项目小伙伴说你就撸起袖子加油干，后面的责任都是项目经理来扛。这在管理团队上是蛮重要的，可以让他们卸下压力和包袱。

勤勤：我也分享一下我们小团队的项目管理经验。首先要明确项目的owner是谁，这个owner有且只能有一个，负责整体推进和做决策。项目分为若干个子任务，每个子任务也会各自的owner。除此之外，每个owner会有一个stakeholder，通常是更加资深的小伙伴，负责在owner拿不定主意的时候帮助决策。比如说活动之间出现了需要协调的问题或者出现一些资源争夺的问题时， 由项目owner来解决，owner解决不了的时候上报给 stakeholder。这也是我在踩了一些坑之后的一个总结，能够保证决策快速做出、各个子项目之间也可以更有效地协调，不至于卡到某一个地方。

勤勤：项目进展的时候需要沟通的地方太多了，会遇到各种各样的坑，两位是否可以各讲一个有效沟通的技巧？

小丽：我把项目沟通分为正式沟通和非正式沟通两种。对于项目的重要节点，例如项目启动、里程碑的交付、或者项目范围的变更，这些都需要走正式沟通。例如写一份邮件并确保对方收到邮件，作为双方约定的过程。一些项目经理可能会踩到这样的坑：一件事情只是口头和开发人员说了一下，开发可能转头就忘了。最后交付时，发现功能设计和约定的不一样，他会说并没有收到你给的通知。其实现在大家面对面聊天的内容太多了，一会儿聊中午吃什么，一会儿聊工作，对方很容易就忘记了。所以对于重要的信息，即使不用邮件告知对方，也一定需要形成文字类型的东西给到对方。

Cedric：同意小丽！会议一定要做会议纪要，把讨论下来的事都落在纸上。飞书文档一个很方便的功能是“@”，在会议纪要中就可以通过 @相关同事 来安排任务，这也方便后续的追踪和管理。

还有一个值得说的点是向上的沟通。有一次项目遇到了风险，我就在群里@大老板 ，大老板和我隔了大概有两个级别，所以我在群里@他告知项目风险，并且艾特了直属的相关同事。我以为他在群里能关注到相关同事的协同情况，但最后项目还是出现了一些小风波。之后他提到这件事时，问我为什么不直接打电话。我当时的顾虑是项目风险是个概率事件，为了这个概率问题就给跨级的老板打电话会有些微妙。但是我后来意识到，如果这个风险真的发生会出现大问题，那么该打的电话还是得打。

勤勤：项目风险管理这块我做的不是很好，所以想听一下两位是怎么做这块的？

小丽：项目从立项开始就是有风险的，在整个项目管理和交付的过程中，风险依旧存在。比如双减政策，叫做外部的政策风险，不可控也无法避免，我们能做的只有及时关注市场分享，关注国家政策，关注同类型的竞品在做什么。所以遇到不可抗风险时，只能接受。

有经验的项目经理，是可以预料到项目可能会存在的一些风险。假设我曾经做过类似的项目，那我就会知道可能会有延期的风险，会有人员变动的风险。那么针对这些风险，我们在项目之初就可以制定一些策略，比如对于变更频繁的需求方，我们必须做到事事书面确认，把风险化解在每一个步骤中。另一种是风险的转移，告知对方如果在某个时间点前无法给到某个材料，我们下周就无法启动，把风险转移。这个比较考验项目管理的能力，因为需要在项目全过程预见风险，并且针对风险提出应对措施。

Cedric：项目风险管理最重要的还是预见风险、评估风险，并且事前制定解决方案。当时我在做部门内首个to-C的在线训练营项目时，项目上只有我和一位实习生，相当于只有一个半人。在一家主要面向B端的公司运营一个100多人的C端项目，我在梳理训练营各环节后判断需要找一个能实现更多互动与管理功能的工具。于是在评估后，向管理层汇报说在现有人员及资源下，我需要用钉钉社群来运营训练营，只有这样才可以避免后续的潜在交付风险。

最终第一期项目运营顺利，训练营结束时直接钉钉群禁言，把后续的常见问题梳理成FAQ放在群内，我负责的首期训练营开开心心地结束了项目交付。然而后续几期训练营负责同事没能坚持住用钉钉群，转向了微信群运营，在训练营服务周期结束后，微信群内不定时的消息使得其他同事精力就要一直放在上面，一定程度上影响了常规的B端项目交付。

 （小编：还有更多实战案例在完整回放里哦！）

两位嘉宾的分享到这里就告一段落了，从项目的范围管理、时间管理，再到项目的风险管理分享，希望你在嘉宾分享中有所启发。同时，我们还要再次感谢在直播分享中参与“共创板”撰写的小伙伴：Allan J. Wan、崔文辰、何昊、拾壹、William、张卉！（以上为共创者在“共创板”中的签名，以首字母排序）

在分享的最后，两位嘉宾也对观众的提问进行了逐一解答，如果这里也有你感兴趣的问题，欢迎在回放中寻找答案！

“国内公司（大厂/中型公司）对于PMO的要求会有什么差别？”

“创新项目难以评估时间怎么办？”

“如何提升团队整体的项目管理意识、把一个缺乏时间/成本观念的团队打造成一个有项目管理文化的团队？”

（以上为直播参与海报，参与方式相关信息已不适用；与回放为同一链接）

“线上会友厅”系列直播回放是为友会员的专属福利。为友会员或报名参加了本场直播的小伙伴可以直接扫描上方海报中的二维码进入回放链接，再次回顾精彩分享。

错过直播报名且希望获取回放的小伙伴，扫描上方海报中的二维码，即可参与超低价拼团。以9.9元/人的价格领取价值99元的完整回放！为了不错过“拼团成功”的消息提醒，记得关注「为友EdwithU服务号」哦！

（进入服务号点击“关注”吧！）

欢迎在评论区留下你对「教育科技项目管理」的思考呀，我们也将持续推送精华内容整理，期待你的持续关注！

若对EdwithU为友感兴趣，请添加EdwithU创始人勤勤企微，留言“为友”。

若想直接成为EdwithU为友会员，免费解锁全部回放，请扫描下方二维码。