Yuxu Ge
文章 · 2025-06-11

项目管理基础知识学习笔记L3

在实际工作中，我学会罗列项目中的关键角色，并为每类角色想一想他们关心什么：

识别完"谁"是干系人后，我会进一步了解"他们有什么诉求"和"能带来什么影响"。为此，我常使用利益相关者登记表（或分析文档）来记录每个干系人的详细信息 。这个登记表通常包括：干系人所属部门及职位、对项目的期望目标、关注的优先事项、对项目的利益点和潜在影响力等。通过登记表，我可以按干系人的利益和影响对他们分类，识别出哪些人对项目成败最关键 。同时也记录他们将提供的支持或资源。这个过程让我清楚应该将主要精力放在哪些人身上，如何定制沟通策略。例如，对于高影响高利益的干系人，要高频沟通、重点满足需求；对于影响小的，则定期告知进展即可。总之，清晰识别并登记利益相关者的信息是项目沟通和管理的基础，它帮助我建立良好的关系网，平衡不同干系人的期望，促进项目顺利推进 。

如何启动项目

在识别完主要干系人后，我会着手启动项目。项目启动阶段的一项关键工作是指定项目经理——也就是明确由谁来负责这个项目的推进。我在实际中体会到，尽早确定项目经理非常重要，因为后续很多决策和沟通都需要项目经理拍板。我通常会和领导确认我的职责权限，比如对资源的调配权等，确保在后续过程中有足够的授权开展工作 。

项目初步定义也是启动阶段的任务之一。我会先弄清楚项目要解决的痛点或抓住的机会（这部分下一节详述），然后给项目下个简单的定义：这个项目打算做什么、不做什么，为什么做。这种初步定义通常体现在一个纲领性文件中，那就是项目章程。我理解项目章程就像项目的"立项说明书"，它概括了项目概况，并赋予项目正式启动的权力 。根据课程内容和我查阅的资料，一个规范的项目章程通常包含：

项目章程通常由项目发起人起草或批准，一旦签署，就意味着项目被正式批准启动，项目经理也获得了"尚方宝剑"。在我看来，章程的作用有两个：一是统一大家对项目"大方向"的认识——让所有相关方都清楚项目要做什么、为何做；二是赋予项目经理正式权力——在组织内部为项目调配资源、进行跨部门沟通有了依据。启动项目时，我习惯召开一次启动会，向主要干系人介绍项目章程的内容。这相当于项目的开球仪式，让所有人对项目的愿景、目标和基本范围达成共识，也明确各自的角色和责任。之后，项目就算正式进入执行准备阶段了。

明确问题或机会

项目之所以存在，通常是为了解决一个问题或者抓住一个机会。老师在课上强调，正确定义项目要解决的根本问题非常关键，因为它会指导项目后续的每个决策 。为此，我会先写一份问题陈述 (Problem Statement)。问题陈述要求我用简洁的一两句话清楚地说明："我们面临的具体问题是什么，或我们想要利用的机会是什么" 。

撰写问题陈述听起来简单，其实暗藏门道。我一开始经常犯的错误是把解决方案当成问题。举个例子吧，以前在一个办公系统升级项目中，我们的陈述写成："我们需要开发一个新系统来提升员工协作效率。"后来发现这其实是解决方案（开发新系统），而没有说清原始问题（现有协作效率低下的原因）。课程举了几个典型反例："我们需要新建一栋大楼""我们需要一个新网站"等等 ——这些都是直接跳到"要做什么解决方案"，而没有解释"为什么要做"。正确的做法是先追问背后的"为什么" 。我现在养成了习惯，当听到诸如"要上新系统"这样的表述时，就不停地问："为什么要上？是想解决什么痛点？" 多问几个为什么，层层剥茧才能找出问题的根源 。在刚才的例子中，我们继续问下去，可能会发现真正的问题是"现有协作平台功能落后，导致跨部门沟通效率低下"。于是，正确的问题陈述可以表述为："目前公司的跨部门协作效率低，影响了项目交付速度，在竞争中处于劣势。"一句话道出症结所在，这就是一个好的问题陈述：简明、聚焦于现状痛点，不预含解决方案。

课上老师也提供了酒店会议中心的案例：附近出现了多家新建的商务酒店，自己的酒店客房入住率直线下降，会议室预订率降低，而整个城市的会议市场需求却在上升 。据此，他们的问题陈述是："我们在不断增长的会议设施市场中正在失去市场份额" 。这个陈述言简意赅地点出了问题——市场需求在涨，我们份额在跌。这为项目指明了要解决的核心问题。

我体会到，写问题陈述有两个注意事项：一是尽量简洁，能一句话说明白绝不用一段话；二是明确区分问题和方案，杜绝把想要的方案错当成了问题。 如果实在拿不准，我就反复检查："我写的这句到底是在描述现状困境，还是已经假定了解决办法？"只有聚焦于现状困境的表述才是问题陈述。最后，不要怕麻烦，多向相关干系人验证这个陈述是否准确。通过与客户和团队讨论，我常会对问题陈述做一些调整，让大家都认同"是的，这正是我们需要解决的问题"。当根本问题或机会说清楚了，我们就打下了一个良好的开端，之后制订目标、方案都会更加有针对性。

项目目的与目标

明确了问题后，接下来就是确定项目的目的和目标。起初我对这两个词有些混淆，觉得好像都是说"想达到什么"。后来明白，项目目的和项目目标既有区别又有关联，可以这么理解：

简单来说，目的指明方向，目标设定里程碑。我现在习惯先想清楚项目的目的是什么，然后列出几个主要目标去定义成功的具体含义 。课程里提到，明确目标非常重要，因为它有助于确定项目范围、实施方案，以及日后评判成功与否的标准 。

在制定项目目标时，我还了解到目标可以分成几种常见类型，每一类关注不同的绩效方面 ：

列出这些目标后，我还需要确保目标本身定义得合理、清晰。这里就用到著名的SMART原则：Specific（具体明确）、Measurable（可衡量）、Achievable（可实现）、Relevant（相关性强）、Time-bound（有时限） 。SMART原则是目标设定的黄金准则，我在实践中深有体会：

遵循SMART原则，我把项目目标写出来后，基本上就勾勒出了项目成功的图景。此时我还会回头看看这些目标和项目的初衷（问题陈述、项目目的）是否一致。课程中建议我们将目的和目标与公司使命和战略进行对照，确保项目确实能带来预期的业务价值 。我觉得这是画龙点睛的一步：如果发现目标跟公司大方向不符，那项目可能要调整甚至喊停；如果吻合，那就更有信心推动下去。

最后，我通常会把项目目的和目标整理成书面的形式，与主要干系人再次沟通确认。这既让大家对项目成果有了统一期望，也为后续的范围定义、方案选择打下基础。项目目的和目标为项目提供了清晰的方向，有了它们，我们就知道这条路要通向哪里 。在这个方向指引下，我们才能继续规划实现路径。

制定战略

当项目的目的和目标都明确后，我发现往往实现这些目标的路径不止一条。也就是说，可以有不同的方案或战略来完成项目。那么选哪种方案最好呢？第三课介绍了一个理性选择策略的方法，我也在工作中应用过，就是头脑风暴 + 决策矩阵的组合。

第一步，头脑风暴产生选项。我会召集一群对项目比较熟悉的小伙伴一起开头脑风暴会议，大家根据之前写好的问题陈述、目的和目标各抒己见，想出可能的实现战略 。头脑风暴强调的是不设限制，尽量发散思维。我通常在会上说："现在不用管可行性，也先不评价好坏，想到啥方案都可以提。"这样的氛围下，经常会蹦出一些有创意的想法。比如针对"提升会议中心竞争力"，可能有人提"升级所有设备"，有人提"主推高科技会议套餐"，还有人提"与大型会展合作打包促销"等等。重点是先罗列出尽可能多的想法，然后再逐一评估 。

第二步，使用决策矩阵评估选项。在有了一堆备选战略后，就进入评估和筛选阶段。这里课程推荐使用"决策矩阵"，我尝试过，确实很有帮助。决策矩阵简而言之就是列出选项和评价标准的表格，通过打分来比较方案优劣 。我们小组一般会针对每个方案提出几个关键提问，作为评估标准：

通过上述多维度的评估，我们就能比较客观地找出最优战略了。通常综合评分最高、同时在可行性、风险和文化方面也过关的方案，就是值得推进的选择 。在我的经验中，有时候决策矩阵的结果会支持两三个差不多的方案，这时候可能需要进一步讨论，或者结合领导偏好、资源机会来拍板。但不管怎样，这个过程可以保证我们考虑周全，而不是拍脑门决定。

当最终方案选定后，我感觉项目一下进入了一个新阶段。此时，我们就对"要做什么"和"怎么做"有了一个清晰的蓝图。接下来很多细节（例如分解具体任务、安排资源等）都会以此为基础逐步展开 。课程中建议我们把这个决策矩阵工具应用到自己的项目中去评估战略，我已经实践过，效果不错 。未来我会继续用这种理性的方式来制定项目战略，毕竟前期把路选对了，后面走起来才会轻松顺利。

如何发现需求

有了明确的战略后，下一步我通常会深入到需求层面。课程强调："项目的目的、目标和解决方案告诉了我们要完成什么，以及大致怎么做，而需求则进一步详述了最终交付成果需要实现的具体功能和条件" 。通俗来说，需求（Requirements）就是项目需满足的详细用户需求或业务需求清单，它回答的是"项目交付物具体应该是什么样子"。这一部分工作非常关键，因为如果需求没搞对，最终成果很可能无法让利益相关者满意；反之，如果加了一堆不必要的需求，就会无端增加项目时间和成本 。

为了更好地理解，我会将目标和需求的关系举个例子来说明：在会议中心升级项目中，有一个目标是"使用最新型的计算机和视听设备来提升会议体验" 。围绕这个目标，我们可以进一步明确出几个具体需求，比如："在所有会议展示厅安装超高清（4K）显示屏" ，"在整个酒店及会议区域提供高速802.11n无线网络覆盖" 。这些需求就比目标更具体、更具可操作性：它们规定了具体要交付什么。目标只是说要用最新技术设备，需求则细化为"什么设备、多高级别"。当然，我们还可以把需求写得更详细，比如"每个展示厅配备不小于100寸的4K显示屏，支持HDMI和无线投屏"等等。这就是需求定义在向下展开细化。

我在工作中发现，获取正确的需求往往充满挑战，常见的难点包括 ：

面对这些挑战，我一般分三个步骤来"发现需求"：

第一步：收集需求信息。这一步就是想方设法把需求挖掘出来。课上介绍了几种常见的方法，我结合自身经验，总结如下几种有效的需求获取手段：

第二步：分析和澄清需求。当第一轮收集到一堆需求后，工作还远没完——其实才刚开始 。接下来我会对原始需求进行整理和分析 。首先检查有没有不合理或缺失的地方：有时候干系人提的需求可能前后矛盾，或者讲得含糊不清，需要澄清 。我会把这些疑点标出来，再去一一追问。还有些需求之间可能有重复，或者属于同一类，我会进行合并归类 。分析的过程通常是反复迭代的——往返沟通几次才能把问题说透 。课程里提示我们可能需要经过几轮才能真正弄清项目的真实需求 。这在我经验中太常见了：每当我以为搞定了，拿给用户确认，他们又会想起新的点子或者否定之前的想法。所以要有耐心，通过多轮问答和验证，逐渐把需求雕琢得一致、无遗漏。

第三步：记录和确认需求。当感觉需求信息已经相对稳定、合理，我就会开始编写需求文档 。记录需求时，我遵循几个原则：一是用清晰、无歧义的语言描述 。尽量避免行话和模棱两可的词，确保不同的人读起来理解相同。二是结构化分类：把需求按类别整理，比如功能需求、性能需求、界面需求、培训需求等。这有助于检查是否有遗漏，也方便日后查找 。三是对每条需求最好指明来源（是谁提的）和优先级，以便后续权衡取舍。需求文档初稿写好后，我一定会请主要干系人过目，进行确认（sign-off）。只有大家一致点头说"是的，我们需要的就是这些"，项目才算真正有了明确的蓝图。后续设计、开发、测试都将严格对照这些需求来进行。

总的来说，需求阶段是项目计划中最磨人的环节之一，但也是决定项目成败的基础。我在实践中越来越体会到，花时间把需求搞清楚是值得的：与其等项目后期发现偏离了客户期待，不如一开始就把事情问明白、想清楚。毕竟项目最终要交付的东西，都是在需求里事先写明了的 。只有当需求扎实明确，项目团队才能对准正确的靶子努力，不会做了很多"无用功"或者错事重做。

明确可交付成果与成功标准

项目搞清楚要交付什么和如何评判成功，对我而言是一件安心的事。课程第三课谈到了可交付成果（Deliverables）和成功标准（Success Criteria），我觉得这个概念很实用。我理解可交付成果就是项目应当交付的具体结果，可以是有形的产品，也可以是无形的成果 。例如一栋新楼、一款软件、一次培训服务，甚至"销售额提高15%"这种业务指标，也可以视为一种成果 。而成功标准则是用来衡量可交付成果是否达到预期的方法或指标 ——换句话说，就是对"成功"的定义。

在第三课中，讲师强调了几点让我印象深刻：

为清晰起见，我常把可交付成果及成功标准整理成一个表格或清单。例如：

通过这样的清单，我对整个项目要交付的东西和衡量标准一目了然。这也方便和干系人沟通他们关心的结果。可交付成果清单告诉我们项目应该交付哪些结果，成功标准则帮助判断这些结果是否达到了我们想要的品质 。在执行过程中，我们就按这个清单逐项去实现、去验收。每完成一个交付物，就意味着项目向成功又迈进一步。可以说，明确交付物和标准就像给项目制定了"完赛条件"，而我的任务就是带领团队逐一满足这些条件。

明确假设与风险

在项目规划阶段，我还会特别注意列出项目的假设和风险。起初我对这部分不太重视，觉得有些"想太多"。后来踩过坑才意识到：假设和风险如果不提前说清，日后可能给项目带来大麻烦。第三课中讲到，项目成功的关键因素之一就是尽早明确项目的假设和风险 。听完后我马上应用到自己的项目中，效果很好。

假设（Assumptions）可以理解为那些我们暂时认为为真的前提 。因为项目在启动时很多情况还不确定，我们往往会假定一些条件来进行规划。例如假设"关键技术人员一直可用""供应商能按期交货""市场环境保持稳定"等。然而，假设毕竟只是主观认定，未被确认就拿来当基础，如果将来事实并非如此，那项目就会受到影响 。举个例子：我们假设"设备供应商负责布线安装"，结果对方以为"布线应该由我们内部IT部门做" 。双方各怀假设，最后可能导致布线没人做，墙都封起来才发现出纰漏 。类似情况在现实中不少见。因此，我学到的教训是：一定要把各方的隐性假设显性化 。很多时候人们自己都没意识到他们在假定什么，所以需要项目经理像侦探一样不停问问题，把那些"没说出口的假设"挖出来 。我在讨论会上会反复确认："这个任务到底是谁负责？""你预期某某会做好哪件事，对吗？"不怕啰嗦，多问几次，直到确认所有人认知一致 。只有把假设亮出来公开讨论，我们才能避免日后互相埋怨"我以为你会做""我以为不用做"之类的问题。

风险（Risks）则是项目中可能发生的不确定事件，分为威胁（负面影响）和机会（正面影响）两类，不过多数时候我们更关注负面风险 。风险的特点在于不确定：也许会发生也许不会，但一旦发生就会影响项目目标 。所以识别风险就是在给项目做"未卜先知"的功课。我以前总嫌在项目前期讨论各种风险太悲观，后来发现及早识别风险有两个好处：一是可以帮助管理层决策 。如果一开始就发现项目存在许多重大风险点，让高层知道项目成功概率不高，也许干脆就不投这个项目了 。与其中途失败，不如一开始慎重。二是对于继续进行的项目，我们提前知道了风险，就能制定应对预案或加入缓冲，提高项目抗风险能力。课程建议我们在项目早期花点时间明确可能影响项目的风险 ，这一点我强烈认同。尤其是那种毁灭性风险，比如政策变化、资金断裂之类，如果前期识别到了，可以在章程决策时就提出，引导高层考虑是否要上马这个项目 。

在实践中，我通常会在项目章程或范围说明书里，加一个章节列出关键假设和风险。具体做法是：

在课程练习中，老师让我们记录自己项目的假设和风险 。当我动手去列的时候，才意识到每个项目真的都有不少假设和风险，以前很多都疏忽掉了。现在把它们写出来管理后，项目的不确定性反而降低了。我也养成一个习惯：定期监控这些假设和风险 。假设有的后来被证实不成立了，那就赶紧调整计划；风险如果临近发生就触发应对措施。通过不断跟踪，我们可以确保假设和风险始终在掌控范围内 。

总之，假设和风险管理让我对项目的底牌更心中有数。明确假设可以防止沟通误区，明确风险可以未雨绸缪。虽然我们无法消除所有不确定性，但至少可以提前想到并做好准备。说到底，项目管理很大程度上就是管理不确定性，而假设与风险就是不确定性的两种体现形式。把它们处理好，项目成功的几率也就大大提高了。

编写范围陈述

在完成了上述步骤（干系人、目标、需求、可交付成果、成功标准、假设和风险）之后，最后要做的一件重要工作是编写项目范围陈述。项目范围陈述（Project Scope Statement）是一个用来清晰描述项目边界的文档：说明项目包含哪些工作内容，不包含哪些内容 。可以说它划定了项目的领地，告诉团队和干系人"我们的责任到此为止，超过这个界限就不归我们管"。我个人觉得范围陈述对控制项目边界、防止范围蔓延有极大的作用。

编写范围陈述时，我通常提炼前面已经明确的信息：

  1. 包含的范围：根据之前确定的需求和可交付成果，我会在范围陈述里列出项目团队将要完成的主要工作和产出 。这部分可以看作项目的"包括项"。例如，对于会议中心升级项目，范围陈述可能写："本项目包括会议室多媒体设备升级、网络基础设施升级、会议预订系统软件更新、相关员工培训"等等 。这些都是团队需要做的事，属于项目范围之内。
  2. 排除的范围：这一项很关键，也常被忽略。范围陈述里我一定会写明不在本项目范围内的事项 。为什么要强调不做什么呢？因为有些事情乍一看好像相关，但实际上并不包含在本项目里，提前说清可以避免日后产生误解和额外要求 。课程举的例子是酒店会议中心升级项目中，酒店客房家具升级不在范围内，因为客房家具几年前刚更新过，不在此次技术改造项目里 。又比如，"本项目不负责改造完成后的市场宣传推广，那将由市场部另立项目负责" 。像这样，把边界以外的内容明确列出来。我自己的经验是，排除项最好针对那些容易被认为应该做但我们其实不做的工作，或者可能在界限处模糊的事项。例如，实施新软件系统项目中，可能要声明"不包括旧数据的历史清洗"之类。不写出来，别人可能以为你会做。
  3. 范围描述：有时我还会在范围陈述开头用一两句话概括项目的整体范围，等于是给包含项和排除项做个总结。比如："本项目旨在改造提升会议中心的硬件和软件设施，以提供更好的客户体验。项目聚焦于技术升级，不涉及土建扩建和市场运营活动。" 这样的描述读起来一目了然。

在写范围陈述时，我发现一个好方法是对照先前列出的假设再过一遍。看看有无新的范围内或范围外内容需要补充 。比如我们假设家具可以兼容新技术，那么家具更新就明确排除在范围外 ；假设市场宣传另做打算，那我们就把市场宣传列为范围外 。通过核对假设，我可以确保范围陈述没有遗漏关键点。

完成初稿后，我会请主要干系人（客户、发起人等）审阅确认范围陈述。这就像画了一条大家都能看见的"楚河汉界"，确认过后谁也不能轻易越界。如果后续有人提出新需求或任务，我就可以拿出范围陈述来对照："这个在我们的排除列表里呢，如果一定要做，就意味着范围变更，我们需要启动变更流程。" 这让需求和范围的讨论有据可依，而不会演变成无原则地增减工作。

项目范围陈述实际上定义了项目的边界 。有了清晰边界，我们才能判断项目有没有跑题，是不是做多了或做少了 。每当项目进行中发生争议时，我都会回到范围陈述，看事情是否在当初约定的范围之内。如果不在，那就按变更流程处理，而不会稀里糊涂把所有要求都接下来。可以说，范围陈述既保护了团队防止过度承诺，也确保了客户得到该得的成果，不会少交付东西 。它是项目计划阶段非常重要的基准文件。

总之，在项目规划启动的过程中，编写范围陈述是最后把所有信息收拢成一个清晰定义的步骤。我通常在完成它之后，感觉项目的"框架"已经扎实搭好——干系人清单、目标、需求、可交付成果、成功标准、假设、风险、范围边界，这些内容相互关联，形成一个整体的项目蓝图。拿着这份蓝图去汇报、沟通，别人很快就明白我们项目要做什么、不做什么了。作为项目经理，我也心里有数，接下来可以带领团队按图施工。回顾第三课所学，这一系列步骤让我认识到：只有前期规划想清楚、说清楚，项目后期执行才能少走弯路。

© 2026 Yuxu Ge ·