《项目管理指导手册》2026版-心得（二）

背景：

 上一篇，讲了我基于“还原论”的思维方式，将项目管理的本质还原成了：项目类型+组织架构+交付模式=项目管理架构；

 侧重点在不同交付模式下不同角色的分工以及项目管理所产生的交付物，但是在我这几年管理项目部的经验，发现很多人经常会把【项目】 和 【项目管理】两件事弄混；

引用PMBOK的原话：

什么是项目：是为了创造独特的产品、服务或成果进行的临时性工作。
什么是项目管理：项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。

为什么会弄混？ 举个例子，我手底下的项目经理经常出现一种情况，工作很努力，今天跟开发进度，明天催需求文档，后天又在业务部门演示demo。我又不能说这些事情不是项目经理干的，但是他真的没在“管”项目。

他做的事情其实是一个“实施”干的活，我管这种叫“推项目”。  当然项目是要推动的，但是项目经理更重要的是要去“管项目”，不是做一个跟单！

正文：

我也经常怀疑自己，一个项目到底要怎么管？ 这是灵魂拷问，前面就说了项目是为了提供独特的产品或服务所做的临时性工作，项目都是独特的，项目管理不也应该是独特的吗？

为此，我还查了一下 TM 什么是管理？ 有两派说法：

法约尔——管理就是计划+组织+指挥+协调+控制；
德鲁克——本质是让人的长处得到发挥，让短处变得无关紧要；

 

以前，我更擅长跑敏捷，所以我更能理解德鲁克的说法激发人性真善美那一套。 而现在自研项目变的越来越少，并且项目的类型越来越多样（参考前文的项目分类），我反而更理解法约尔说的。

也是根据我理解的法约尔，我把【项目管理】的主要活动拆成了6个阶段，4个决策点，8个控制点，以及48个【管理活动】。

像前面说的“般若龙象功”一样，我自己是没有练成，算是一种项目管理“武功”的猜想；

初初来看，这个套路平平无奇，说来说去还是裁剪PMBOK的49个过程。我的出发点是：

第一，不能像PMBOK那样抽象，好像放之四海皆准，但是又要具体到能指导一个IT项目管理部门进行项目管理，这决定了一套项目管理框架的颗粒度问题；

第二，项目经理拿到项目，就知道自己应该从事项目活动，也就是解决前面说的项目经理搞不清楚自己是在做项目还是在管项目，这里48个活动都是项目管理活动；

 

举个反例，如果我们按照软件的套路，那项目管理是什么：

瀑布：需求分析---<评审>----概要设计---<评审>----详细设计---<评审>----开发---<评审>----单元测试---<评审>----集成测试---<评审>----用户测试---<评审>----发布；

敏捷：接受需求---<迭代计划会>----迭代冲刺----<每日站会>----用户评审----<迭代评审会>----发版----<迭代复盘会>；

 

发现问题没有，如果按照软件开发的套路，项目管理就是一直在开会、评审。一个项目经理的职责是让项目成功，换言之就是达成项目目标。

说句废话：项目的目标要能够达成，首先要项目目标能够被达成，好似钓鱼要到有鱼的地方钓；

 

因此，我在框架中设定了“概念阶段”，概念阶段最重要的就是 做可行性验证。

我今年的项目中有一个五百万级的项目，是采购一款成熟的检测插件，这个插件是世界级的，业内也比较有名。

我们在前期商务沟通的的时候号称三年前在我们公司做一个测试，完全符合我们公司要求，这次时间紧、任务重。直接跳过了POC环节，并且在商务环节售前人员对我们要求表示so easy！

项目一边制定SOW，一边走商务协议。 我拿到供应商给的SOW，差点肺气炸了。 前期我们业务部门提的要求，那些指标参数，能删的都删掉了，不能删的也降低了要求。

随后，项目一直卡着没开启动会，在SOW环节反复拉扯了2个月，总监这边也叫停了项目。

这就是一个跳过概念阶段，直接启动项目的案例，常胜将军之所以常胜不败，是他只打能打赢的仗；

不敢说，按照这套框架去做项目一定常胜不败，只能说跳过这些环节，风险极大！

 

===========================================华丽的分割线=========================================

管理活动这么多，那项目经理起到决定性的管理在哪里？我认为有8个，绝不可手软，绝不可跳过，否则后患无穷。

 

今年也是一个非常小的项目总共才五十万，买一个管理系统，我认为小的不能再小了。也是通过供应商采购，有一些二开的需求。系统蓝图也是评审了的，供应商也一直报告开发进度没有问题。
但是，离上线还有一周的时候，我们要求供应商提供测试用例 和 测试报告，供应商以人手不足为由，让我们直接UAT。而UAT涉及3个部门，邀请业务部门测试，部门部长安排经理，经理安排小弟，最后来的就是小弟的小弟；
随便测测就在测试用例上面签字了，其实就算他们认真测，由于自身水平问题也测不出业务问题。

我这边这个IT项目经理，还大大咧咧跟我说业务部门没什么人来测试，但是都签字了。我这边再反复跟供应商确认，说发现的问题在上线前会把发现的那些问题解决，并且发现的都是小问题；

后果就是，上线第一天，系统就瘫痪了。更神奇的是，原来那些应该来参与UAT的人 这会都出现了，你一言我一语的吐槽这个系统垃圾。

好在业务部门老大顶住压力了，采取了线上线下并行的方式，原来业务怎么走现在还怎么走，同步也在线上走一遍，业务部门瞬间压力翻一倍，都投诉到业务部门老大那，就这样并行了一个月才稳定下来；

我很多次回想，要是业务部门老大也站旁边冷眼旁观的话，这个项目就GG了。

所以，像这种案例《测试报告》的评审是必须要被控制的，这就是项目经理要管理的关键点。

除了这8个控制点，还要配套4个决策点。

 

像刚刚测试报告，业务部门的关键用户要测试，要会签。 但不仅仅做到这一步就可以发布上线了，我上面说的这个五十万的系统上线就直接跳过的 决策点控制  这个关键点。

测试完成之后形成测试报告，要在项目指导委员会 进行汇报的， 有项目指导委会 决策是否上线。 像我刚刚情况已经是不幸中的大幸，UAT不认真、测试报告不评审，系统上线不会上会决策；

所以，我设置的这些阶段、这些控制点、决策点，真的是一步一坑踩过来的，不是不能跳过，但是能多做一项，就能多一分胜算。

 

第一部分讲了项目管理的架构，这是第二部分项目管理的框架，就写到这里吧！