对产品经理而言，需求确定、功能设计完成之后，最重要的就是开发环节的项目管理。虽然部分公司有专门的项目经理负责，但对于产品来说，自己也需要掌握这一能力，避免被坑。

一直以来，我们看过很多人在讲项目管理，讲wbs、讲甘特图、讲进度管理… 但实践起来却总觉得不尽如人意。为什么会出现这样的问题呢？

笔者在实践中也和大家有过这样的疑问，但后来发现，其实我们讲的都只是进行项目管理的手段方式，其实并没有完整谈到项目管理的底层逻辑。

那怎样才是有效项目管理的底层逻辑？

笔者先抛出观点：其实有效项目管理可以在法家中可以找到灵感。三者：道、势、术。其中，道为组织的相关制度、规则、流程；势为公司授予的范围权力；术为个人的项目管理能力与艺术。如果三个中不能至少满足两个，那这个项目管理往往也无法很好地推进及产出成效。

一、项目管理之道：规则

规则用于解决风险，保障最终的底线。

这一点主要体现在对公司制度、流程的利用上。

许多PM（既指产品也指项目）在进行项目管理的时候，一方面会顾忌自己对项目把控太严，让项目成员觉得自己过于凶恶；另一方面又担心项目成员对项目不上心，导致项目进度、质量等失控。

为什么在公司中有人唱红脸就一定需要人唱黑脸？正是因为我们需要对成员进行激励；为什么需要黑脸，也是因为需要让成员知道惩罚，来解决底线/风险问题。而公司的制度、流程的有效利用，就满足我们在项目管理中对黑脸的利用需要，由于是公器，大家往往不会有太多异议，从而实现公对公，私对私。

1. 制度

一些公司为了保障项目/日常开发的按计划进行，会制定一些规章制度，有些是正激励，有些是负激励。如通过项目达成率、千行代码bug率、bug二次打开量、系统稳定性、PRD一次评审不通过率等指标，设置奖惩机制，来保障基础的质量底线，以支持项目按进度正常进行并如期达成目标。

像是上述的一些指标，都可以作为我们利用的制度规则，来为我们的项目进度与质量兜底。

2. 流程

为了提高效率、方便生产与管理，以前车间工厂会将一项工作拆成几个步骤节点完成，一则便于员工快速了解上手，二则形成标准化，三则流程的拆解与实现也会提升整体的效率，最后也便于责任分解，解决扯皮问题。

就如那个经典问例：如何将一头大象塞进冰箱？塞进的方法有很多种，但是也需要列出第一步、第二步、第三步…这其实就是拆解落实这个流程。

在一些规模较大或是管理较好的企业，已经形成了自己的SOP（Standard Operating Procedure标准操作程序），理清一个业务落地或日常工作的SOP，甚至有些还给出了部门、员工个人协作的SOP。

标准的作业流程让员工减少判断，以熟悉的方式处理工作，这极大降低了员工对这些工作的思考时间、沟通成本，让员工可以将更多的时间与精力花在更有价值的事情上，提高整体的效率降低其他无谓成本。

就如哲学家怀特海所说：“随着不假思索下意识即可操作的事情的增加，人类文明就提高了很大一步。”

图为笔者基于boardmix绘制的功能开发流程图

当然，许多小型公司为了产出效率，往往会忽略流程，这也说不上错误，这是因为场景不一样。

生存与死亡就在一瞬间的小型公司，快就代表了活下去的机率，如果硬是要满足规范流程则有些本本主义，没有实事求是；但若公司发展到了一定规模，涉及到了多部门协作时，还没有建立标准流程，这其中的隐患也带来的其他成本不可谓不大。

基于以上两点，我们也可以反过来看看自己的组织，是否形成了相对完备的制度、标准的流程，来为项目的推进保驾护航。正所谓无规矩不成方圆，如果在没有基础的规则，那也项目管理也无疑是无根之草，流水浮萍。

二、项目管理之势：权力

权力，代表我们可以影响到的范围、可以使用到的资源。

一个失势之人，就如丧家之犬，无法被重视，无法很好地把控自己的项目，也无法高效调动相关资源进行支持。如果一个想要做好自己的项目，则一定要在项目开始之前，为自己推进项目争取到充足的权力。同样，想要自己的下属的项目可以良好推进，也要对下属给到充足的权力支持。

1. 方向

一直以来，我们经常听人说：做项目/产品，最重要的不是做什么，而是不做什么。但在实际落地中，受领导、业务方、甲方等影响，使得项目的方向摇摆不定，逐渐加码，不仅给开发团队上强度，还让项目的进度与完成目标变得风雨飘摇。

吾有一友，当年负责给某事业单位做一个功能，原需求是一个审批功能，满足单位内的流程审批。一听挺正常的，朋友输出一般通用的审批功能交互原型方案后，客户提出说他们单位的（原来系统的）审批是没有工作流的，为了让审批流程更有“空间”，审批节点的人只能传给自己能传范围内的人来进行下一审批，怎么知道流程到哪了呢？不知道。怎么知道流程结束了审批通过了呢？不知道。

朋友觉得离谱，而且公司底层支持的工作流不支持这种逆天操作啊，但毕竟领导、商务、客户都这样说做了，就硬着头皮做完了，并配置了一些加签、回退等审批操作，开发们虽然也不理解，但也支持着弄完了。

开发完后的演示，客户看过后整体比较满意，但又提出单位的领导有些年纪比较大，这么多操作不知道点哪个，要将这些加签、回退操作全部移除，只保留同意和拒绝操作。开发们觉得无语，做了又删，但看在平时和朋友的关系不错的份上，还是没有多说什么，给改完了。

开发完后第三次给客户演示的时候，一个级别比较高的客户来了，说怎么没有那些加签、回退的操作，而且还要支持评论的时候发文件、表情包。领导和商务还是答应下来了，这下朋友和开发们一起爆炸了，这发现根本不是原来简单的审批，而是一个满足了单位内部交流兼审批的功能，然而当时定下的交付时间…

要是能重来，我要选…啊不是，如果在深入调研的基础上，PM能够有一定决定方向的权力，对不合理的需求说不，那也不会如此被动，随风飘摇。

不过做G端项目、定制化项目时，那确实客户是爹，还是得看客户的需求，毕竟，甲方爸爸有没有付钱才是衡量这类交付型项目的唯一标准。但如果经常加码又改动需求，项目的负责人或高层没有出面插手的话，那项目团队和进度都得崩。

2. 人力

事在人为，没有充足的人力支持，项目是起不来的。但有人了，没有名，人也是调动不起来的。

所谓君权神授、尚方宝剑，讲的就是权力的名正言顺，其他人在这个名下服从于这个人的安排。项目的开踢也离不开每位成员的支持，但如果项目的人员调动没有经过授权的过程，也就没有这个名。

如果想项目顺利开始和推进，最好拉个会议，由领导出面，向所有需要参与项目的人员打声招呼，让所有需要参与项目的成员知道将参与这个项目、配合支持你，了解你是项目的负责人，这样项目的开头与推进会轻松很多，同时配置充足的人员，完美。

笔者曾经在跟进一个项目时，又因项目推进支持原因，同时接下领导提的一个需要跨团队协作的项目。由于开发资源资源已经在推进笔者负责中的项目，所以需要外地部门的来支持另外一个项目的开发推进。当时笔者认为领导已经和笔者说过项目由笔者来负责，于是直接找外地部门的开发leader和开发们来开会支持，但结果可想而知，我们的项目和人家的kpi又不相关，人家也不太情愿的样子，项目进度推进出现了许多问题。现在想来，如果能重来，一定得先拉个会，拉上相关参与得成员，让领导讲两句给一把尚方宝剑…

3. 财物

财物，一个是财，一个是物。

大家出来工作，除了职业发展空间等因素外，其中还有重要的因素就是收入。如果负责人在权力范围内可以为项目成员争取到较好的项目完成激励，必然会激励成员去推进项目，但若争取到了且项目如期完成后，却没有许诺的激励，则会激起成员的负面情绪。其次就是物料支持，满足项目在推进所需要用到的软硬件物料，在合理范围内钱能解决的都不是问题。

4. 政治

这是一个比较隐蔽且少人提到的点，一般很少有人会认为政治也会影响项目进度，但实际上在项目的推进中，政治因素的影响无处不在，站队、办公室政治都会影响整个项目的推进乃至存活，在一些大公司中也要考虑这些微妙且敏感的点。

总而言之，如果没有授予负责人相应的权力，项目也易如风中凌乱的小草、无舵之船，随风飘荡。

三、项目管理之术：手段

许多人提及项目管理的时候，主要提的都是这个维度的方法，这些方法的巧妙运用往往让项目管理变得事半功倍。笔者将这个维度分为六个部分，并在其中提一些常用方法，用来抛砖引玉

1. 项目人力

成事在人。项目成员的人员状态与关系如何，对于项目的战斗力有极大的影响

1.1 团队情绪

照顾团队情绪，主要是对团队的保护。在项目团体的协作中，由于项目往往带有时间进度、业绩的压力，尽管PM在项目中承担的上层、外部压力也很大，但这些压力也只能尽量先由PM进行承担，不将这些压力下放到项目成员。

同时关注项目成员的情绪变化，一旦成员的情绪出现异常需要及时介入，避免由于成员情绪的影响导致实施进度受影响，甚至是出现团队成员异动。因此在这个临时的项目小家庭，PM只能当好这个家长的角色，维护好团队内的氛围，充分相信自己的团队，让团队成员的积极情绪始终在线。

但有个小tip：PM在为对团队进行保护和争取权益的时候，也可以让团队成员感知到你的动作，这样他们不仅知道自己的目标实现会有回报，也知道你的努力付出，这对提升成员关系、团队情绪与你在团队中的个人形象与魅力都有较大帮助。

当然，PM自己也要做好自己的情绪建设，摆正心态与位置。

1.2 成员关系

成员间关系不错有时候可以解决很多问题，像是一些问题咨询、支持，关系好的话刷个脸就可以轻松搞定。

在团队成员关系中，笔者认为主要分为五类：a.友谊型；b.和谐型；c.利益型；d.保守型；f.竞争型。

1. 在友谊型中，由于性格特质、兴趣爱好等关系使然，与这些成员的关系往往非常不错，也有较深的私交，这类的成员可遇不可得，做好关系维护即可。
2. 和谐型在公司中比较常见，他们一般对所有人都不冷不热，干好自己的活，对和谐型成员加强联系，多帮小忙，积攒人品，建立良好的关系。
3. 利益型在公司中也比较常见，他们往往关心实现的结果是否对自己有益，无益则不关心，对利益型成员需要做好认知同步，让他清楚你们的利益一致，同时也要尽量为项目争取到较好的预期收益。
4. 保守型算是公司中的坏分子，往往趋利避活，是个老油子，对于这种成员我们需要注意他对团队的影响，避免一颗老鼠屎坏了一锅粥，如果可以将这类成员从团队中移除最好，如果不能的话则要充分利用制度与流程，明确个人责任，至少保证他负责的任务能如期完成。
5. 竞争型的成员的利益一般与自己存在竞争关系，往往会出现明面和谐背地暗斗情况，我们可以通过利益方式，尽量形成利益一致情况，争取将竞争型成员往利益型成员转变。如果实在不行则使用保守型的对待方式，保障项目正常进行。

总而言之，对于友谊型、和谐型、利益型成员，我们要努力维护；对于竞争型我们要努力争取；对于保守型我们要在保障项目进度的基础上尽早移除。做到朋友多多的，敌人少少的。

2. 项目范围

划定项目实施的范围是开始项目的前提，如果范围没有划定清楚就开始，那要吃的苦头还在后头咧。在项目范围的管理中，笔者将之拆解为三个部分：调研时的范围内容确定，沟通时的文档记录确定，实施时的内容拆解确定。

2.1 范围内容确定

项目的开发范围，依赖于对项目需求的深度调研，发现真实需求，以便在范围内用最低成本实现最大价值。避免需求调研不清，导致项目范围变动，需求反复建起又推翻。

在调研时，需要注意的是需求的提出人并非是需求的使用人，并且需求上线后影响的人也不一定是需求的使用人与提出人。

如何确定真实需求，只有到需求产生的场景中和相关的人员聊一聊，并且询问在这种情况下，他们原来的解决措施是怎么样的，对于一个说起来比较重要紧急，但是实际上又没有相应的应对措施的（哪怕是简单的），那极大可能是一个伪需求。

关于场景的记录与还原，杨堃老师曾提过一个公式：基本场景=人物 时间 地点 起因 经过 结果。这个公式可以很好帮助我们还原场景，去除提出人的主观因素，感受原始需求的原汁原味。

2.2 文档记录同步

无论甲方项目也好，内部项目也罢，在调研、需求沟通等涉及沟通与输出内容的，一定要做好文档记录及同步涉及到的所有人员。没有及时记录及同步的，要么是懒要么是没有经过毒打。文档的形成及@所有相关成员，可以定下内容，有效避免相关人员的扯皮，而且做到有据可依。基于这份记录来实施的项目内容，哪怕项目实施中或完成后有人提出异议，只要这份文档在，我们就是有理的一方。

2.3 实施内容拆解

为了方便项目的实施，我们也需要对项目内容进行拆解，以便后续梳理功能框架、数据建模等，同时也是为了对整体项目难度有个基础的判断，并且项目的内容拆解越细，就越方便我们对后续项目时间的把控。

在内容拆解中，有个项目管理的工具推荐给大家——WBS（Work Breakdown Structure 的简称，意为工作分解结构），将复杂的项目或任务拆分成一系列具体、可操作的组成部分。下面就是一个将大象塞进冰箱的WBS示例。

3. 项目时间

项目最重要的就是在项目工期内完成达标交付，因此项目时间管理和预估就十分重要。

现在许多团队已经在使用项目协作工具，比如asana、PingCode、Worktile、teambition等，其中的功能就支持对项目时间的查看与管理。在平常也有些常用的项目实践管理工具：项目燃尽图、甘特图。

3.1 项目燃尽图

它的好处就在于结合了项目的计划工期（参考线）以及实际的完成实践（实际线），将工期数据可视化，让我们看到项目进度的更新状态报告，使每个成员都能了解到最新的项目进度信息。

但燃尽图缺点在于只显示已完成的故事点数，对于其他的内容情况（如：哪些故事已经也在开始中？还有哪些故事没完成？是不是同时有几个故事都在进行？等等）都不知道。而如果燃尽图出现与预估不一样的变化，我们也比较难判断是已完成的故事的影响还是又增减了什么故事。

3.2 甘特图

甘特图可以通过条状图来显示项目、进度和其他时间相关的系统进展的内在关系随着时间进展的情况，在一般的项目管理中应用最多的也是这个工具。

在甘特图中，满足这几个关键要素：任务列表（知道要干什么）、任务顺序（知道要先干哪个后干哪个）、任务时间（知道要干多久）、任务人员（知道负责人是谁、参与人是谁）。其次还可根据情况注明任务需要什么支持，任务/项目的里程碑在哪。

以上基本满足了对整体项目任务计划及进度的基本了解与安排。

由亿图项目管理软件Edraw Project提供的甘特图模板图

但以上的都只是工具的使用，核心还是需要形成一个团队内沟通机制（将会在5.项目沟通中说明），让自己对项目过程有整体的把控。可以让项目成员定期（如一日、一周）汇报个人的进度情况，保证自己可以及时掌握项目进度信息，做好情况的应对与调整。

4. 项目质量

在PM圈中流传着一个经久不衰的笑话：客户想要的和最后实现的，并搞出了许多梗图。事实上确实也经常出现这样的搞笑情况，除了客户不断叠加的新想法，还有我们自己开发的效果等原因，这就不得不让我们重视起项目质量管理。笔者将项目质量管理分为前中后三个阶段——前：计划与目标；中：测试与检查；后：结果价值分析。三个阶段的侧重点各有不一。

4.1 计划与目标

这点与2.项目范围、3.项目时间相关，主要是在项目开始先确定要做的内容，以及后续的计划形成与计划跟进。侧重的是对项目计划进度的把控，但需要注意的是，需要为项目留出充足的冗余时间，这个时间一般用于对完成的结果的测试，以及测试后的优化时间。

如果为了讨好高层、客户而一昧地挤压这块地冗余时间，项目出现问题的时候就缺少了灵活处理的空间。同时可以在原计划的任务完成时间前设置一个“预定完成时间”，团队尽量在预定完成时间点完成需要开发的内容，这样也有利于处理这个任务可能会发生的事情。有时慢即是快，为了追逐所谓的快，反而容易变慢。

4.2 测试与检查

在这个阶段主要是对开发结果进行测试，以及验收是否达到设计目标。在这个节点主要留足测试时间，进行相应测试。

在测试前最好先再梳理一次功能的业务流程、权限情况，及其他一些功能的细节内容，并抓紧与各方确认功能内容，方便及时调整。以下是测试环节可能包括的方式：

• 黑盒测试：不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
• 白盒测试：确保应用程序或网页在加载时能够正常显示，同时没有出现任何错误或异常的测试。
• 灰盒测试：介于白盒测试与黑盒测试之间的一种测试，多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
• 单元测试：对软件中的最小可测试单元进行检查和验证。
• 冒烟测试：确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
• 容量测试：测试软件系统在最大负载量下的容量和性能，及其在超负荷情况下的表现和稳定性。
• 回归测试：修改了旧代码后，重新测试之前已经测试过的测试用例，以确认修改没有引入新的错误或导致其他代码产生错误。
• 越权测试：针对是否存在越权漏洞或越权访问进行测试。
• 模糊测试：通过提供随机的非预期的输入来检测程序中的错误、漏洞等，可以帮助发现程序中的边界条件错误、内存泄漏、缓冲区溢出等问题。
• 集成测试：将程序或硬件配置中的多个单元或模块被组合在一起并进行测试。
• 压力测试：针对特定系统或者组件所做的测试，目的是确认其稳定性。
• 用户接受度测试：在“真实环境”中由特定的用户（如用户、需求方）进行测试，确认功能是否满足预期。

4.3 结果价值分析

这个阶段一般在项目上线后，主要是对项目功能的使用、稳定性等数据进行回收分析。

一些团队会忽略这个阶段，上线就上线了，但是如果情况允许的话，最好还是走完这个流程。

一来检验需求质量，如果上线后发现这个功能使用情况与预期差距较大，也可以让我们自己反思在提出/接收需求时，是否有对需求进行深入理解、判断？是否有更好的处理方法？是否这个需求可以拒绝/不做？方便后续可以更好处理需求；

二来对开发的质量、系统稳定性进行再次验证。

三来基于对功能的上线数据分析，我们也可以思考是否可以有更好的优化。

5. 项目沟通

项目的沟通需要注意聊对人、聊得及时，并且要留下沟通痕迹。

5.1 聊对人

要和涉及项目业务的KP聊（key person，关键人物）。包括我们的领导、项目开发的主要推进人以及需求方（也会是甲方）。

• 对于我们的领导，我们主要及时做好信息的同步（向上管理），这不仅方便上级对项目进度的了解，也更熟悉项目团队情况，也方便我们申请资源支持及项目完成后为团队争取更多的权益，毕竟酒香也怕巷子深，会哭的孩子有奶喝；
• 对于项目开发的主要推进人，比如主要的开发负责人，业务支持方。我们主要多提醒、沟通，及时了解他们的进度情况、需要的支持，确保项目需求没跑偏，并及时为他们提供支持；
• 对于需求方，如果是内部需求，除了需求的提出人，我们更重要的是到需求的来源处，找到需求的使用人和被影响人聊一下，确认需求（也许不一定要做呢？而是有其他非项目的原因导致大家认为需要做这个东西），实施完成后再同步相关的需求方。如果是外部需求（如甲方客户），除了需求的对接人，最好也要和客户中可以拍板的话事人搭上关系，避免对接人的单方面想法以及需求无法拍板导致的推进困难。

同时也要注意维护关系，这种维护依赖于信任的建立，信任来源于两点：1.响应；2.主动帮助。核心就在于是让客户感受到你不是为了拿到项目钱而已，而是真心地站在客户一方，从他们的角度出发，及时响应、做好反馈，帮忙出谋划策、解决烦恼。

有几个小招：

• 比如在一些无关重要的功能上，可以帮忙提出自己的优化想法，让客户觉得你也主动帮他想；比如客户有紧急运营支持/bug处理时，能调动资源及时支持（需求的话一般尽量不接）；
• 比如项目的进度要定期同步，如果完不成时要提前告知让对接人可以留有汇报余地；
• 再比如项目里程碑或发版时，给到一些好看的成果介绍图（例如项目这一期实现多少个功能、用时多少一些数据展示图；
• 再例如版本迭代做个海报，这也方便对接人汇报，领导最喜欢看这种数据很好的样子内容了）。

这些微妙的客户关系运营手段都能帮你在与客户建立很好的信任关系。

5.2 聊得及时

聊并不一定是对话，也可以是信息的同步。

项目团队内的话，主要是做好定期同步即可，例如项目成员的日报、周报，让自己可以把握住情况。但最好还是每周开个短时间的周会，大家在这个时间段内同步完成情况、是否需要支持协调。有些团队会使用站会的方式（由于站着累，大家也想快点结束，一般汇报的内容也比较集中不容易分散，时间一般10分钟左右），效果也挺不错的（如果既站会又讲得久，那当我没说，那可遭老罪了）

对于领导与需求方，我们做好定期汇报即可，如果需要资源支持或是临时发生变动、项目由于某些原因无法如期完成时，一定一定要及时同步。

5.3 留下痕迹

不论是项目成员、甲方还是内部需求提出方，尽量对应有一个沟通平台（群），里面需要有高层领导，每次的需求确认结果、项目进度等等，最好都在群内沟通，可以的话也@相关KP，避免私聊导致出问题时的死无对证。最好可以形成相关的会议纪要、需求沟通书（尤其是面对甲方时更要注意这类文档的留痕）。

在沟通的技巧方面，推荐大家看科里• 帕特森的《关键对话：如何高效能沟通》。要在沟通中分清主次矛盾，并紧抓主要矛盾——我们对话的目的。并且为了这个目的，要时刻关注对话走向，建立共享观点库、关注情绪来维护对话的安全感，在包容他人观点的同时也要坚定正确的观点。

6. 项目风险

6.1 需求变更风险

一般内部需求的话，需求变更风险还是比较低的，并且可以通过调整优先级及排期处理。而外部需求（甲方）的话，则比较容易出现这类风险。但应对的话同2.项目范围，调研及确定好需求范围；以及5.项目沟通，及时同步并留痕。

6.2 项目技术风险

由于一些需求的提出会涉及到一些新技术应用，这就为项目的实施带来技术风险。如果判断需求会有新技术应用情况的话，就要及时考虑安排人员进行提前学习，并了解是否还有其他的替代方案，做好二手准备。

6.3 合同条款风险

这点往往被许多人忽略掉。这点很重要！这点很重要！这点很重要！！！重要的事情说三遍！不会有人以为签在合同上的东西不重要吧？不会吧？不会吧？在合同条款出来的时候，领导、商务、项目就要全面、仔细、准确地了解合同条款的全部内容！对于一些没定的、模糊的内容要尽快明确、调整或补充协议。

笔者朋友曾经就吃过一个亏。

曾经在做一个项目的时候，领导和商务为了吸引客户，在需求沟通书上自己填写了一个当时还刚开始开发的功能。但在与客户沟通阶段时，客户的对接人明确说当前暂不需要这个功能（由于客户不要，这个功能的开发资源就调到其他功能上了，功能还没开发完），朋友当时和领导及商务说，既然客户不需要，我们就将这块需求从沟通书中移除吧，但是领导说没关系，留着就留着呗。

谁知道后面领导和商务做合同的时候居然还直接用了最终需求沟通书的内容，这个功能理所当然地也写进了合同！后面项目开发完成，领导和商务在给客户做UAT的时候，客户的领导就问合同中有这个功能，怎么现在又没有了，要立刻加上。

还记得那是周二下午的六点，领导和商务对朋友说真的真的为项目团队向客户尽最大努力争取时间了，然后要周五保质保量完成这个功能的开发并上线。好家伙，当时劝你们别加到需求沟通书和合同上的时候你们怎么不听呢？现在反过来将压力全给到了项目团队。

一个还开发内容还没过半的功能，三天时间，那三天项目团队披星戴月，一台电脑、一双手、一个梦想，终于是完成了，团队也爆炸了。

当然还有项目范围风险、沟通不良风险、项目成员素质及流动风险、需求不明风险、项目进度风险、领导支持授权少风险、项目质量风险、系统环境风险等，这些在上文中都有提到相应一些方法与注意，故而不再赘述。

手段在于细节，如果没有手段耕耘，项目管理只能是一片荒田

四、写在最后

在项目管理的道、势、术三者，如果缺了道，没有规则的约束，会让项目容易混乱，更易发生风险。

在小公司的项目还可以依赖于PM的势与术来带好一个又一个项目，但毕竟不是长久之法，如果后面PM离开了，那后面的就再起不能了；如果缺了势，依赖于公司的道和PM的术，也能让项目勉强走完，但由于缺少势来为团队稳定方向，争取人、钱，团队也容易对公司形成负面情绪，久之也不利于团队稳定；如果缺了术，依赖公司已有的道和高层授予的势，项目是可以跑下去的，但PM还有什么用呢？这种情况谁都可以当PM了。没有术的运用，也就无法更好的发挥对所有资源的利用，调动各方的配合，在一些细节的控制上也不能很好实现。

当然，项目管理涉及到的范围与内容很大，笔者提出的观点也只是九牛一毛，在实际的落地中也会因为情况不同产生对应变化。尽管本篇讲的是项目管理，但笔者认为在公司的协作管理中，依然离不开以上三个方面。

欢迎大家留下自己的想法，一起交流。

本文由 @Hank 原创发布于人人都是产品经理。未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。