> 口播：同学们好，我们开始上课。今天进入《软件项目管理》的第二讲——第 2 章，软件项目启动。 > 上节课我们建立起了整门课的"地图"：什么是项目、什么是软件项目、生命周期、五大过程组、十大知识领域、八大绩效域。从今天起，我们沿着这张地图往前走，走到项目生命周期的第一步：启动。 > 这一章其实只回答四个问题：这个项目该不该干？谁来干？凭什么授权他干？开工之前，大家有没有把话说清楚、把共识立起来？ > 我们还会跟着一个案例走到底——某大型连锁超市的智能库存管理系统。它在启动阶段踩了哪些坑，后面又是怎么一步步"还债"的，今天全部讲透。 > 请把这句话记在笔记本第一行：项目启动是项目的"第一粒扣子"，第一粒扣错了，后面九成的日子都不好过。 > 今天的节奏是：先看案例，再依次讲启动概述、项目立项、项目准备工作、识别干系人、制定项目章程、项目启动大会。

> 口播：今天的课，六块内容排成一条线。 > 01 软件项目启动概述——启动到底包含哪些动作； > 02 项目立项——要不要干？项目建议书、可行性研究、评估与决策； > 03 项目准备工作——谁来当项目经理、用哪种组织结构； > 04 识别干系人——谁影响项目、谁被项目影响； > 05 制定项目章程——启动阶段最正式的一份文档； > 06 项目启动大会——把项目"官宣"给全体相关方。 > 学习目标是四句话：能说明项目启动的全流程；能写出项目建议书与可行性研究的要点；能比较三类组织结构；能识别干系人并制定项目章程。这四条，也正是本章期末要考的四类题。 > 上课之前先回顾 30 秒：项目的五大特征是什么？（停顿）对——目、独、临、约、不：有目标、独特性、临时性、受制约、不确定性。今天我们会反复用到"临时性、独特性、不确定性"这三把尺子。 > 另外提醒一句：今天讲的所有流程都不是纸面文章。启动阶段每少做一步，后面就要多还一次债——案例里我们马上会看到这笔债是怎么还的，而且利息很高。

> 口播：案例背景是这样一家企业：某大型连锁超市。连锁超市的生意，说白了就是"货进得来、卖得掉、别压库、别过期"。 > 它当时头疼三件事，请把这三个痛点记住：第一，库存管理效率低——盘点靠人工、补货靠经验；第二，库存成本上升——钱压在了仓库里，周转不起来；第三，商品过期损耗严重——尤其是生鲜和短保商品，卖不掉就只能报损。 > 这三个痛点其实是一体三面：库存不准，所以补货不准；补货不准，所以不是缺货就是积压；积压久了，就是损耗。要治根，就得让库存算得准、补得快。 > 于是公司决定：全面升级库存管理系统，引入智能预测算法和自动化补货机制，实现库存的精准管理和优化。请注意这两个技术词——智能预测算法、自动化补货机制。今天它们会变成这家公司最大的坑，我们后面会回来算这笔账。 > 接着看它的启动过程。做对的部分：项目团队按标准流程编制了《项目建议书》和《可行性分析报告》，论证了系统的经济效益与社会效益；高层领导迅速决策并批准启动项目。听起来很规范，对不对？流程走了、文件写了、领导批了。 > 但埋下隐患的部分在这里：启动时未充分考虑技术可行性——智能预测算法的准确性要求、数据集成的技术难度、自动化补货机制的技术实现方案，这三样都缺乏深入的分析和调研。 > 我给大家一个生活化类比，帮你们记住这个坑：这就像装修房子，预算做了、风格定了、家里人也点头了，唯独没有确认"承重墙能不能敲、下水改不改得动"。前面的账算得再漂亮，一动锤子就全乱。 > 软件行业里同样的事天天发生：某团队立项做"智能推荐"，商业价值论证了三页纸，却没确认自家推荐算法的冷启动数据够不够，上线后推荐不准，用户反而流失得更快。 > 再补一层背景，帮大家理解为什么"库存"是连锁超市的命脉。连锁超市是典型的薄利多销行业：单件商品毛利不高，靠的是周转速度；而库存恰恰是周转的闸门——压得多，资金就沉淀在仓库里；压得少，又容易缺货、丢单、伤客。所以对这个行业来说，库存管理系统不是"锦上添花的信息化项目"，而是直接影响现金流和客户体验的核心系统。 > 也正因为它重要，公司上下都盼着它快点上、快点见效——而这种"求快"的氛围，恰恰是启动阶段最容易出问题的地方：越是重要的项目，越容易在论证上偷工减料。 > 那么请大家再想一层：公司真正想要的，到底是一套"系统"，还是"库存降下来、损耗降下来"？显然是后者。项目只是手段，业务结果才是目的——这句话在写项目建议书和可行性研究时会反复用到：所有论证都要指向"业务上得到了什么"，而不是"我们上了什么技术"。 > 所以这个案例的第一问就是：可行性报告都写了，为什么还会埋下隐患？ 大家先把这个问号带着，等会儿讲"可行性研究五个维度"时，我们一起把它拆开。

> 口播：项目批准了，接着看后面的发展。先看风险暴露。 > 第一件事，派谁当项目经理：这位项目经理具备网站开发的丰富经验。网站开发是好事，但这家超市的项目涉及跨领域技术整合与多部门协作——智能预测算法、库存数据集成、门店与总部流程改造，这些已经超出了传统网站开发的范畴。结果是：管理风险未充分识别，启动阶段就出现了沟通不畅、决策滞后。 > 第二件事，开发阶段的表现：团队与业务部门沟通出现偏差，对超市实际运营场景与库存管理需求理解不一致；智能预测算法、自动化补货的技术方案研究不足；到了集成测试阶段，遇到较多技术难题与性能瓶颈，项目出现延误。 > 我把这条因果链写在黑板上，请大家顺着看：技术可行性没做深 → 方案带着大量未知进入开发 → 与业务部门需求没对齐 → 集成测试集中爆发 → 工期延误。这不是运气不好，这是启动阶段欠下的账，在中后期一次性偿还。 > 生活化类比：这就像一场接力赛，第一棒交棒时没对准手，后面每一棒都在追着棒跑，越跑越乱。启动阶段没对齐的东西不会自动消失，它只会以"返工"的形式回来。 > 这里我再补一个细节，请大家体会"沟通偏差"到底是怎么产生的。业务部门说的是"这个商品经常缺货，顾客天天抱怨"，这是业务语言；开发团队听到的可能是"需要一个缺货预警功能"，这是功能语言；算法团队心里想的又是"要有足够的历史销量数据才能预测"，这是数据语言。三种语言之间如果没有"翻译"，需求就一定会走样。 > 再打个生活化的比方：这就像点菜——顾客说"来点清淡的"，厨师理解成"少放盐"，端上来一盘水煮青菜；可顾客心里想的是"不要放辣"。谁都没有说谎，结果就是不对。需求对齐的本质，是把不同角色的语言翻译成同一份可验证的描述。 > 课堂互动：现在给大家 3 分钟。四人一组讨论两道思考题，2 分钟后我请一组代表发言。 > Q1：这个项目的启动存在哪些具体问题？ > Q2：针对上述问题，如何有效解决？ > 好，我们一起来归纳。请大家对照黑板右侧的"案例诊断"区。 > 问题有五个：① 技术可行性论证不足——算法准确性、数据集成难度的调研都没做透；② 干系人识别不充分——业务部门的需求没有被对齐；③ 沟通规划缺失——启动时"沟通不畅、决策滞后"就是症状；④ 风险识别缺位——用一个不熟悉该领域的项目经理，又没有识别跨领域整合的风险；⑤ 启动大会"开了但没开透"——团队对目标的理解只停留在表面，实施步骤、任务分配、风险认知都不足。 > 对策对应五条：立项阶段补足技术可行性研究、认真做干系人分析、编制沟通计划、列出风险清单、把启动会做深做实。 > 这五条，就是今天这节课六块内容的主线——我们后面每一块，都是在补这五个坑。

> 口播：好，我们进入第一块：01 软件项目启动概述。 > 这一块只解决一个问题：启动阶段到底要做哪些事，顺序是什么。 这里特别提示一句：启动不是一个"动作"，而是一串有先后的动作——先论证、再决策、再授权、最后对齐。顺序错了，后面全乱。 > 案例里那五个坑，有四个就出在这一块：建议书走了形式、可行性研究空心、决策太快、基础工作没做够。所以这一块是今天的重头戏。 > 再补一句它的"地位"：这一块像整章的总纲——后面五块内容，其实都是这五个环节中的某一步被放大来讲。这一页听懂了，后面听的都是细节；这一页糊了，后面会越听越乱。 > 也请大家记住"概述"这两个字的分量：它不讲细节，只讲顺序和依赖。在项目管理里，顺序本身就是一种专业能力——同样五件事，顺序错了，成本能差出好几倍。

> 口播：软件项目启动是项目生命周期中的第一步，它主要通过一系列活动，为项目的成功执行打下基础。这五个关键环节，请务必背下来，考试必考。 > 第一，项目建议书的编写：明确项目的背景、目标和预期成果，为立项提供依据。它的语气是"我建议做这件事"。 > 第二，可行性研究：分初步和详细两个阶段，评估项目的技术、经济、资源可行性，确保项目具备实施条件。它回答的是"这件事能不能干成"。 > 第三，项目评估与决策：基于可行性研究结果对项目进行全面评估，最终决定是否立项。它回答"干不干、批不批"。 > 第四，立项后基础工作：制定项目章程、指派项目经理、识别干系人——明确项目目标、范围和资源分配。它回答"谁来干、怎么干、凭什么叫得动人"。 > 第五，启动大会收尾：与团队和干系人就目标、需求、时间安排达成一致，为项目推进奠定基础。它回答"大家认不认"。 > 一句话记忆：建议书（想干什么）→ 可研（能不能干）→ 决策（干不干）→ 基础工作（谁来干、怎么干）→ 启动会（大家一起认）。 我把这五个环节再压缩成五个动词：提 → 证 → 批 → 备 → 认。 > 为什么顺序不能颠倒？因为每一步都在给下一步提供依据。跳过可研直接决策，决策就没有依据；跳过基础工作直接开工，团队就没有授权、没有边界。这也正是案例里"高层迅速批准"的问题所在——快不是错，"没有依据的快"才是错。 > 生活化类比：这五步就像去医院看病。先挂号说症状（建议书），再抽血拍片（可研），医生看报告下结论（评估决策），然后定主治医生、安排床位（基础工作），最后把病情、治疗方案和注意事项跟家属讲清楚（启动会）。跳过拍片直接开刀，谁都不敢。 > 软件行业实例：一家公司要做"双十一大促临时优惠系统"，同样是先写立项说明，再做技术可行性确认（现有优惠引擎能不能撑住峰值），然后评审决策，再指派项目经理、识别运营与财务干系人，最后开启动会把上线窗口和回滚方案讲清楚。 > 回到案例：超市项目的五个环节表面都走了——建议书写了、可研报告编了、高层批了、人也派了、会也开了。但它踩的坑是：第二个环节"可研"空心，第四个环节"基础工作"里派了一位跨领域的项目经理，第五个环节"启动会"没开透。 请记住这个结论：启动流程"走完"不等于"走实"。 > 最后再给一个实务提醒：这五个环节之间是输入输出的关系——建议书是初步可行性研究的输入，可研报告是评估决策的输入，立项文件是制定章程的输入，章程又是启动会的依据。你只要顺着这条"文件流"去记，整条链子就不会乱。

> 【思政落点 1】 这里我要特别强调"程序"二字。为什么启动要一步一步走流程、留文档、做评估？不是为了增加手续，而是因为程序是最可靠的"防错机制"。现实中很多项目出问题，追根溯源就是"该走的程序没走、该论证的没论证、该签字的人没签字"。对将来做软件的你们来说，依法合规、按程序办事，既是保护项目，也是保护自己——合规不是束缚，是护栏。

> 口播：第二块：02 项目立项。 > 立项回答一个问题：这个项目到底该不该干？ 它包含四个阶段：立项申请、初步可行性研究、详细可行性研究、评估与决策。 > 请特别注意它的定位：立项是项目启动前的关键环节，它决定项目能不能正式进入实施阶段，也直接决定后面的章程怎么定、团队怎么建、资源怎么分。换句话说，立项是整个项目的地基。 > 案例里"高层迅速决策并批准启动"，就是这一步走得太快。下面我们一层层把它拆开看，先看四个阶段。 > 顺便说一句：立项做得好，还有一个容易被忽视的好处——它让"不干"这个决定变得容易。敢于在立项阶段否掉一个不靠谱的项目，本身就是项目管理能力的体现，因为在这一步停下来的成本最低。

> 口播：项目立项是项目启动前的关键环节，它决定了项目是否能够正式进入实施阶段，也为后续的项目章程制定、团队组建、资源分配等环节提供基础。这句话里有两个信息：一是"前置"，二是"打基础"。 > 立项管理分四个阶段，请按顺序记牢： > ① 项目建议与立项申请——把想法写成文件，正式提出"我想干这件事"； > ② 初步可行性研究——先粗筛一遍，看看值不值得花更多的钱和时间去做深入研究； > ③ 详细可行性研究——全面深入论证技术方案、市场、投资、风险，为项目决策提供详实依据； > ④ 项目评估与决策——由第三方评估，拍板定案。 > 这里有一个非常重要的例外：小型项目可以合并初步可行性研究和详细可行性研究阶段，但详细可行性研究不可或缺。为什么？因为详研是决策的唯一依据，省掉详研，评估和决策就成了无源之水。 > 生活化类比：这四步很像买房。先在脑子里种草（建议申请），再上网看看这个小区大概什么价位、有没有明显硬伤（初研），然后实地看房、查产权、算月供、问学区、看物业（详研），最后请评估机构估价、自己签字成交（评估决策）。前两步花的是时间和心思，第三步花的是真金白银——所以顺序上一定是先初研、再详研，不能一上来就请评估机构。 > 软件行业实例：一家银行要上线"智能客服"，先写立项申请；初研阶段发现现有语料严重不足，果断暂停，只损失了两周调研时间；另一个项目初研顺利，详研阶段测出高峰期并发撑不住，于是调整了技术方案和采购预算——花在可研上的时间，都是在替开发阶段省钱。 > 回扣案例：超市项目"高层迅速决策并批准启动"——快是好事，但如果技术可行性这一步没有做扎实，快就等于把风险往后推。今天省下的两周调研，后面要用几个月的返工来还，还要搭上团队士气和客户信任。

> 口播：项目建议书是项目建设单位向上级主管部门提交的关键文件。 它依据什么来写？课件列得很清楚：国民经济趋势、国家及地方规划、产业政策、市场需求、项目所在地条件，以及本单位的战略。请注意，这些依据都不是"我们内部想不想"，而是外部大势＋自身战略的结合——立项不能脱离大环境。 > 它的核心内容有四块，请大家记牢： > ① 项目背景和必要性——项目为什么开展，要解决什么问题； > ② 市场分析与预测——市场现状是什么，未来趋势怎么走； > ③ 预期成果与市场定位——产出什么东西，面向哪一类市场群体； > ④ 实施所需必要条件——需要哪些资源、技术、资金。 > 我把这四块压缩成一句口诀：为什么做（背景与必要性）、做给谁（市场与定位）、做什么（预期成果）、靠什么做（必要条件）。 > 特别要强调它的定位：建议书是"申请"，语气是"我建议做这件事"，它不等于批准。批准的依据，是接下来的可行性研究。很多同学写建议书时写成"我们已经决定要做"，这是越权——建议书没有决策权，只有建议权。 > 生活化类比：项目建议书就像求职时的自荐信——你说"我适合这个岗位、我能带来什么"，但录不录用，得看后面的笔试面试（可研）和 HR 评审（评估决策）。自荐信写得再漂亮，也不能自己给自己发 offer。 > 软件行业实例：一家公司要给政务客户做"一网通办"平台，建议书里必须写清政策依据、市场与客户需求、预期交付成果，以及必需的资质与数据条件——少写"资质条件"这一条，后面投标就会被卡住。 > 回扣案例：超市项目的建议书按流程编制了，但从案例后面暴露的问题看，它对"实施所需必要条件"里的技术条件写得太轻——智能预测算法的准确性要求、数据集成的难度，都只停留在设想，没有作为"必要条件"被认真评估。这就提醒我们：建议书的第四块不是凑数的，它是后面可行性研究的靶子。

> 口播：可行性研究要回答的不是"想不想干"，而是"能不能干成"。它从五个维度展开，请大家对照屏幕上的表格，一条一条看： > > | 维度 | 核心要点 | > |---|---| > | 技术可行性 | 现有技术能否支持项目目标，并在规定时间内完成。例：当前技术水平下开发特定功能的可能性 | > | 经济可行性 | 成本效益核算：项目支出、收益、投资回报期、敏感性分析 | > | 社会效益可行性 | 对组织内部（品牌形象、竞争力）与社会（就业、环保）的影响 | > | 运行环境可行性 | 用户管理体制、人员素质、数据资源等运行环境是否适配。例：员工操作能力能否满足新系统要求 | > | 其他可行性 | 法律可行性（是否合法合规）、政策可行性（是否契合政策导向） | > > 五个维度，我给大家一个记忆抓手——"能不能、划不划算、顺不顺、合不合法、还有没有别的"：技术＝能不能做得出来；经济＝划不划算；社会效益＝对组织内外有没有正面影响；运行环境＝用起来顺不顺（人、制度、数据跟不跟得上）；其他（法律与政策）＝合不合规。 > 判断方法上要有一个"顺序感"：技术可行性是入场券——技术上做不到，后面算得再漂亮都是零；法律可行性是一票否决——不合规，利润再高也不能干；经济可行性是决策核心——老板最终看的是划不划算；运行环境可行性最容易被忽视——系统再好，员工不会用、数据喂不进去，一样白搭。 > 生活化类比：这五问跟你买车几乎一模一样——这车在我这边的路况能不能开（技术）、养得起养不起（经济）、家人坐着舒不舒服、开出去有没有面子（社会效益）、我媳妇会不会开、车位够不够（运行环境）、能不能上牌、限不限行（法律与政策）。少问一条，都可能买回来一辆"停不了的神车"。 > 软件行业实例：一个团队做"人脸识别门禁"，技术上成熟、经济上也便宜，但它涉及个人信息采集——法律与政策可行性直接决定了这件事能不能落地；如果部署在学校，还要考虑宿管人员会不会操作、闸机数据能不能接入现有系统，这就是运行环境可行性。 > 回到案例：超市项目倒在哪儿？技术可行性——智能预测算法的准确性要求、数据集成的难度、自动化补货的实现方案，都没有深入论证。请记住这句话：一份"看起来齐全"的可行性报告，如果关键维度是空心的，它就是一张通行证，而不是一张保险单。 > > 【思政落点 2】 做可行性研究，最忌讳"为了通过而论证"。数据挑好看的用、风险一句带过、测算只算乐观情形——报告是漂亮了，但坑的是团队、是公司，最后是用户。实事求是、数据说话、不回避风险，这是专业精神，也是职业诚信。 请记住：可研报告上的每一个数字，将来都要有人为它负责。 > > 课堂练习（1 分钟）：请快速判断，下面哪一项属于经济可行性？ > A．新系统上线后员工能否熟练操作　B．投资回报期是否可接受　C．是否符合《数据安全法》　D．现有技术能否实现毫秒级响应 > 答案：B。 A 属运行环境可行性，C 属法律可行性（归入"其他"），D 属技术可行性。做错的同学，请把五个维度再默念一遍。

> 口播：可行性研究分两个阶段，请大家分清它们的"分工"。 > ① 初步可行性研究：初步评估项目的必要性、周期、资源等，核心目的是——判断这个项目值不值得投入更多资源去做深入研究。说白了，它是"粗筛"，防止你在一个明显不靠谱的想法上继续砸钱。 > ② 详细可行性研究：全面深入分析技术方案、市场、投资、风险等，为项目决策提供详实依据。它是"细算"，是决策的直接来源。 > 两者的关系很像招聘：初研是简历筛选，详研是面试＋背景调查。简历阶段发现不对口，就不用浪费面试官的时间；但真正决定录不录用的，是面试和背调。 > 再看详细可行性研究报告的结构（表 2-2），请对照屏幕，把几个关键块记下来： > > | 目录项 | 主要内容 | > |---|---| > | 项目背景 | 项目名称、承担单位、主管部门、客户、可行性研究依据等 | > | 可行性研究结论 | 项目目标、规模、技术方案、进度计划、投资估算、财务评价等 | > | 技术背景 / 发展现状 | 国家、地区、行业规划与客户需求；国内外技术历史、现状与趋势 | > | 市场调查分析 | 产品用途、市场调研、开发环境、市场预测等 | > | 客户现行系统情况 | 客户资源、现行系统功能与需求调查 | > | 项目总体目标 | 项目目标、技术方案、核心问题分析等 | > | 实施进度计划 | 阶段划分、进度安排、项目里程碑等 | > | 投资估算 | 总投资、资金筹措方案、投资使用计划等 | > | 项目组人员组成 | 组织方式、人员构成、培训计划等 | > | 项目风险 | 关键技术风险、需求不确定性、其他风险 | > | 经济效益 / 社会效益 | 经济效益预测；社会效益分析与评价 | > | 结论 / 附件 | 可行性研究结论与立项建议；相关文件、图表、调查数据 | > > 怎么用这张表？ 它就是一份"可研报告目录模板"。将来你写可研，照这个目录一项一项填，就不会漏项。特别注意两块——项目风险和社会效益：它们是同学们写可研时最容易漏的，而恰恰是评审专家最爱问的。 > 记忆抓手：把这张表想成一条线——从哪来（项目背景与技术现状）→ 给谁用（市场与客户现状）→ 做多大（目标与进度）→ 花多少（投资估算）→ 谁来做（人员组成）→ 有啥险（项目风险）→ 值不值（经济与社会效益）→ 结论附件。八步顺着走，报告的骨架就立起来了。 > 回扣案例：如果当年超市项目按这张表认认真真填过一遍，"项目风险"那一栏里就会写下"智能预测算法的准确性尚未验证""与现有收银和仓储系统的集成难度未知"。决策层在批准的时候，就会多问一句。表格不是形式，它是把"没想到"变成"写下来"的强制动作。

> 口播：可行性研究做完了，谁说了算？三个要点。 > 第一，项目评估：由第三方依据国家政策、法规、行业标准等，从国民经济、社会影响、组织业务三个角度全面评估项目的可行性，最终输出《项目评估报告》。 > 第二，报告内容包括三块：项目概况——基本情况加上综合评估结论，比如是否批准项目、是否建议贷款这样明确的意见；详细评估意见——对技术可行性、经济可行性、市场需求等做细致的分析阐述；总结与建议——点明重大问题和潜在风险，提出针对性的改进措施。 > 第三，决策：基于评估结果，决定项目是否立项。 > 这一页的关键词只有三个字——"第三方"。为什么必须第三方？因为申报方和评估方不能是同一方，否则就是"自己给自己打分"。你既当运动员又当裁判，这场比赛还有意义吗？ > 生活化类比：贷款买房的时候，银行不会只听你说"我这房子值五百万"，它会派自己的评估师上门估值，也可能请第三方评估机构出具报告——这就是为了防范"报高价、多贷款"的道德风险。项目评估引入独立第三方，起的是同一个作用。 > 软件行业实例：政府信息化项目在立项前，通常要经过专家评审或第三方咨询机构评估，从合规性、技术路线、投资合理性等角度出具意见。这也解释了为什么有的项目"申报材料很厚，但被评审专家问三句就露馅"——因为评估看的不是你的排版，看的是你的论证。 > 回到案例：超市项目"高层领导迅速决策并批准启动"，看上去效率很高。但如果评估环节只是"内部过一下"，技术上的空洞就没有人替决策层把关。评估与决策的价值不在快，而在于"有人替你把不该批的项目挡下来"。 > > 【思政落点 3】 这一页的思政点非常硬核：依法合规、客观公正、独立评审。国家政策、法规、行业标准是评估的依据，这意味着立项不是"领导拍脑袋"，而是在制度和法律框架内做决策。将来你们走上工作岗位，可能会遇到"先把项目立了、手续后补"的诱惑。请记住今天这句话：程序合规是底线，科学决策是能力，独立客观是品格——既当运动员又当裁判，赢的是一时，输的是整个职业信誉。

> 口播：第三块：03 项目准备工作。 > 项目批准了，接下来两件事最关键：选对人、搭对架子。"选对人"就是指派项目经理；"搭对架子"就是选择组织结构——职能型、项目型，还是矩阵型。 > 为什么这两件事属于"准备"而不属于"执行"？因为它们决定了项目的权力结构：谁能拍板、谁向谁汇报、资源怎么调。这些定不下来，项目一开工就会在"到底听谁的"上面消耗时间。 > 提醒一句：这两件事都属于"任命与授权"的范畴，一旦宣布就很难悄悄改回来——准备阶段多花一天，执行阶段少吵一周。 > 案例里的第一个大坑——派了一位只有网站开发经验的项目经理，就出在这一块。

> 口播：项目经理是"派"出来的还是"选"出来的？我们先看来源，它一共两条道。 > 一是内部选拔——具体方式有部门推荐、PMO 指派、高层指定、人才计划选拔。它的优势是：熟悉组织文化与流程，有内部工作经验，知道谁能配合、哪道手续该找谁。 > 二是外部招聘——方式有公开招聘、猎头服务、合同聘用、伙伴推荐。它适用于需要特定领域经验或高技术要求的项目，比如公司第一次做人工智能项目，内部没人干过，就只能到外部去找。 > 生活化类比：内部选拔像球队从青训队提拔，懂战术、磨合快；外部招聘像转会引进外援，能力强、但需要一段适应期。两种都不是万能药，关键看项目的需要。 > 第二，项目经理的能力，四项：① 项目管理技能；② 战略与商务技能；③ 领导力；④ 技术能力。 请注意这个顺序——技术能力排在最后。这说明一个很重要的判断：项目经理不是"技术最强的人"，而是"最能带成事的人"。 技术最强的人去做项目经理，常常忍不住自己上手写代码，反而耽误了协调、决策和争取资源。 > 第三，项目经理的职责，七项：项目规划与目标设定、团队建设与管理、进度／资源／预算管理、沟通与协调、风险与质量管理、问题解决与决策支持、项目交付与收尾。从"定目标"到"交付收尾"，一头一尾，全生命周期都得管。 > 第四，项目经理的权力类型，有两种分法：按管理职责分——决策权、组织权、指挥权、人事权、经济权；按来源和作用分——职位权力、奖赏权力、惩罚权力、专家权力、参照权力。 > 这里有一个特别值得记的点：职位权力、奖赏权力、惩罚权力是"组织给的"；而专家权力（你的专业让人服气）和参照权力（你的人格魅力让人愿意跟）是"自己挣的"。 一个好的项目经理，靠后两种的时候更多——因为前者只能让人"服从"，后者才能让人"跟随"。 > 软件行业实例：互联网公司常设"技术负责人＋项目经理"双岗，讲的就是这个道理——技术负责人负责"做得对"，项目经理负责"做得成、按时交、大家还愿意跟着干"。 > 回扣案例：超市项目派了一位"网站开发经验丰富"的经理，去管一个"跨领域技术整合＋多部门协作"的项目——这是典型的"人岗不匹配"。启示很明确：选项目经理，要先看项目特征（跨领域吗？多部门吗？高风险吗？），再看人的能力组合，不能只看他过去做得多好。

> 口播：我们先给职能型组织结构下一个定义——它是按照专业职能来划分部门的组织：财务部、人力资源部、市场部、技术部，各管一摊，每个部门负责自己领域的业务。 > 这种结构最像什么？最像一所大学：教务处、学工处、财务处、各个二级学院，各管一段；也像一家医院，内科、外科、放射科、检验科，各有各的专业领地。放到软件公司里，就是技术部、测试部、实施部、运维部这么排。 > 那么项目来了怎么办？通常是从技术部抽三个开发、测试部抽一个测试，临时拼一个项目组，项目经理往往由某个部门的经理兼任。注意了，这就是职能型的要害——项目经理是"借人干活"，人还是部门的。 > 它的优点有三条。第一，人员配置灵活，技术专家可以同时为多个项目提供支持——同一位数据库专家，上午帮 A 项目，下午帮 B 项目，人力不浪费。第二，部门内都是同行，交流方便，技术问题容易解决——前端和后端坐在一起，喊一声就能问。第三，技术连续性好，员工有清晰的晋升路径——从初级工程师到技术专家，这条路是看得见的。 > 但它的缺点同样致命。第一，项目支持不足、责任分散。为什么？因为部门经理关心的是本部门的活儿，项目只是"顺手帮个忙"，一旦部门自己的任务紧张，项目就排到后面去了。第二，跨部门沟通困难，容易忽视项目整体目标——各部门守着自己的考核指标，没有人对"这个项目能不能按期交付"负总责。第三，项目人员积极性较低、缺乏归属感，因为他的考核、加薪、晋升都在部门手里，不在项目手里。 > 那什么时候适合用职能型？给大家一个判断：业务稳定、项目小、以技术分工为主的组织。比如一家 20 人的小软件公司，常年做同一类外包项目，谁擅长什么一目了然，由一位部门经理带着就干完了，没必要给每个项目单独搭班子、单独核算。 > 但要特别注意：职能型最容易出事的时刻，就是跨部门协作变多的时候。 一个项目一旦牵涉三个以上部门、还要对外承诺交付日期，职能型就开始"推不动"，这时候就该考虑换结构了。 > 用一句话记住它：职能型，部门说了算；项目经理权力最小，通常只挂一个协调员或联络员的头衔——只能"沟通"，不能"命令"。

> 口播：再看另一个极端：项目型组织结构。定义是——以项目为核心，项目经理全权负责项目，拥有调动资源的权力。它不再是"借人干活"，而是"连人带资源一起划给项目"。 > 生活里的类比是剧组：拍一部电影，导演、摄影、灯光、服化道全部为这部戏服务，戏拍完，剧组解散，人各回各家。装修队也一样，从进场到交钥匙，整队人都听工长的。 > 软件行业的实例：某公司要集中 80 人攻关一个为期两年的核心系统，怎么做？成立独立的项目部，开发、测试、需求、实施，甚至财务和采购的支持人员都进项目组，项目经理有自己的人事权、预算权和考核权，直接向公司高层汇报。这就是典型的项目型。 > 优点两条，都很硬。第一，项目经理能快速决策，项目组聚焦单一目标，进度、成本和质量能灵活控制——因为不用层层请示，也不用跟别的部门抢人。第二，每个成员只有一个领导，避免多重领导带来的冲突，沟通顺畅、责任清楚。 > 缺点也是两条。第一，项目组独占资源，项目之间共享不足。一个项目养一批人，项目结束前这批人不能被别的项目用；公司同时开三个项目，就要养三套测试班子，成本高，闲时浪费。第二，项目经理与成员之间的依赖性强，跨部门沟通困难；项目一旦结束，成员很难回到原来的部门，归属感受影响，职业发展路径也容易断。 > 再回扣一下我们的案例：如果超市的智能库存系统当初就成立一个独立项目部，由项目经理全权负责，开发、测试、业务分析、实施人员全部进组，直接向高层汇报——那么"技术方案研究不足""多部门协作扯皮"这两个坑，至少有一个会被提前暴露出来，因为没有人能再把责任推给"那不是我们部门的事"。 > 当然反过来看，如果只是日常的小修小补也用项目型，那就等于大炮打蚊子：人配齐了、架子搭起来了，活却只有那么一点，成本全浪费在等待和沉没上。 > 一句话记住：项目型，经理说了算；PM 权力最大，人、钱、事一把抓。

> 口播：第三种是矩阵型组织结构。定义是——它把职能型和项目型的特点结合起来：员工同时隶属职能部门和项目团队，项目经理与职能经理共享管理权，资源调度更高效，也促进了跨部门合作。 > 生活类比：大学生既是某个班的学生，又是校篮球队的队员——辅导员管你的学业，教练管你的训练，两边都是你的领导。工作里也一样：你的人坐在技术部，但你同时在为 A 项目干活，可能还要支持 B 项目。 > 软件行业实例：一家高科技企业同时推进 6 个客户项目，就需要复用各部门的算法专家——每位专家横向上参加一到两个项目，纵向上仍然归算法部管理。这就是矩阵型。 > 优点三条：充分利用各部门的技术、人才和设备；促进成员学习与知识交流；提升对客户需求的关注。 > 这里我要重点讲它的管理难点，也是本章的难点之一：两个领导、责权必须划清。 一个员工的绩效考核、请假、培训归职能经理；任务优先级、交付节点归项目经理。两人一冲突，员工就"两头挨骂"。所以矩阵型要真正跑起来，必须先把三件事写清楚：谁定优先级、谁考核、争议由谁裁决。这三件事不清，矩阵型就会从"高效复用"变成"互相甩锅"。 > 互动：三个场景，请判断更适合哪种组织结构。① 一家 20 人的小软件公司，常年做同一类外包项目；② 某公司要集中 80 人攻关一个为期两年的核心系统；③ 一家高科技企业同时推进 6 个客户项目，需要复用各部门的算法专家。 > 参考答案：① 职能型——项目小、业务稳定，靠部门分工最省成本；② 项目型——要集中力量打硬仗，PM 必须有权；③ 矩阵型——多项目并行，又要复用专家。 > 这里再补一句实务体会：矩阵型是三种结构里对管理成熟度要求最高的一种。它要求公司有清晰的考核制度、有能拍板的上级、有畅通的争议裁决通道。很多公司学矩阵型，只学到了"两套汇报线"，没学到"责权先划清"，结果就是员工双倍汇报、项目双倍扯皮。 > 回到案例：超市项目之所以在启动阶段就出现"沟通不畅、决策滞后"，本质上就是没有一个明确规则来回答"这件事谁说了算"。组织结构选对了，还得把规则立起来。 > 一句话记住：矩阵型，两个领导说了算；资源用得最省，但责权划不清就会乱。

> 口播：第三个板块讲完了，我们把目光从"结构"转到"人"。项目启动阶段有一门功课，看起来最不技术，却最容易让项目翻车——识别干系人。 > 什么叫干系人？一句话：所有能影响项目、或者会被项目影响的组织和个人。请注意这句话有两个方向：一是"他能影响项目"——客户、领导、监管机构；二是"项目会影响他"——门店店长、收银员、供应商的送货司机。 > 为什么单独给它一页？因为这是启动阶段唯一一项"人"的功课，也是最容易漏项的功课：漏掉一个关键干系人，后面要多付十倍的沟通成本。 > 下一页我们把干系人分成内部 5 类、外部 5 类，逐类看清楚。 > 说得再直白一点：这一页不是在教你填表格，而是在教你做事之前先想明白——这件事会动到谁的奶酪，谁又会来动你的进度。

> 口播：先把定义钉死：项目干系人，是所有能影响项目、或受项目影响的组织和个人——内部外部都算，主动参与的算，被动关联的也算。 > 请看这张表，左半是内部 5 类，右半是外部 5 类。我们逐类过一遍，每一类都问三个问题：他是谁？他关心什么？漏掉他会怎样？ > 内部第一类，发起人——通常是 CEO 或分管副总这样的高层领导，项目的发起者和出钱人；他关心项目值不值得做、跟公司战略合不合；漏掉他，你连资源都批不下来，出了事也没人替你说话。 > 第二类，项目经理——项目的整体管理者与推进者；关心目标、进度、成本、风险；这一条不用多说，漏掉他项目就没人为结果负责。 > 第三类，团队成员——真正写代码、做测试、写文档的人；关心自己干什么、标准是什么、有没有成长；漏掉他，任务落到谁头上都说不清，进度只能靠猜。 > 第四类，职能经理——在职能型和矩阵型组织里掌握人力与资源的人；关心本部门的负荷和人员发展；漏掉他，你借不到人，借到了也可能随时被抽走。 > 第五类，PMO——项目管理办公室，提供支持、规范流程；关心项目的合规性和报告口径；漏掉它，你在流程、模板上会反复返工。 > 外部第一类，客户——提出需求、验收成果的一方；关心功能能不能用、值不值这个价；漏掉他，验收时一句"这不是我要的"就能让你返工重做。 > 第二类，最终用户——每天真正使用系统的人，往往就是门店店长、收银员、库管员；关心好不好用、会不会增加工作量；漏掉他们，系统做得再漂亮也没人用。 > 第三类，供应商——提供硬件、软件、技术或服务的一方；关心合同、付款和自己的交付节奏；漏掉他，设备到不了位，你的进度表就是一张废纸。 > 第四类，监管机构——负责合规审查的部门；关心数据安全、隐私和行业规范；漏掉他，验收阶段可能被一票否决。 > 第五类，股东——项目的投资方；关心投入产出和风险敞口，他要的是"这笔钱花得值不值"。 > 现在把这张表回扣到我们的超市案例：业务部门、门店运营这些人，就属于最终用户（在集团口径下也可视为内部业务方）。他们恰恰没有被充分识别和参与，结果开发团队"对超市实际运营场景和库存管理需求理解不一致"，到集成测试阶段才暴露问题，直接造成返工和项目延误。漏掉一个关键干系人，后面要多付十倍的沟通成本——这句话不是修辞。 > 课堂练习：校园二手交易平台项目里，"学校信息安全主管部门"属于哪类干系人？核心诉求是什么？参考：属于监管类干系人（校内则为内部监管）；诉求是合规与数据安全。这类干系人的特点是——平时不出现，验收时一票否决，必须提前纳入。

> 口播：干系人认全了，接下来是启动阶段最正式的一件事：制定项目章程。 > 前面所有的活——建议书、可行性研究、评估与决策、选项目经理、定组织结构、识别干系人——都还是在"准备"；而章程，是把这些准备的成果写成一份有约束力的正式文件，报批、签署、生效。 > 有一句话请先记住：项目章程一旦被批准，就标志着项目的正式启动。 > 它回答的是四个问题：凭什么是这个项目？凭什么由你来管？你有多大权？什么时候算干完？下一页先讲它的定义和四大作用。 > 这里还要把两个概念分开：章程和合同不是一回事。 对内部项目，章程相当于公司给自己发的"开工令"；对外部客户项目，章程是在合同框架内制定的，二者不能打架。

> 口播：先给定义，请大家跟着我抠关键词。项目章程是项目启动阶段的一份正式文档，它全面记录三样东西——商业需求、项目论证、以及对顾客需求的理解；它明确新产品、服务或成果的交付目标；它的目的是确保干系人在三件事上达成共识：主要可交付成果、关键里程碑、项目参与者的角色与职责。 > 拆开看三层：第一，它是"正式文档"，不是会议纪要，更不是口头承诺；第二，它记录的是"为什么做"（商业需求、项目论证）和"顾客要什么"，而不是"具体怎么做"；第三，它管的是共识——可交付成果、里程碑、角色职责。 > 生活化类比：章程有点像聘书加驾照。聘书告诉你：你被任命为这个项目的负责人，你有这些权限；驾照告诉你：你能开哪一类车、上路的边界在哪里。没有这两样就上路，那叫无证驾驶。 > 软件行业实例：在智能库存系统项目里，章程会写明——项目目的（降低库存资金占用与商品过期损耗）、可测量的目标、总体里程碑进度计划（具体日期以签署文本为准）、项目经理及其职权、预先批准的财务资源，以及谁有权批准。写清楚了，后面跟门店、采购、IT 各部门打交道，都是"照章办事"。 > 四大作用，请记牢：① 任命项目经理并明确其权责；② 赋予项目合法地位——让这个项目在公司里有"名分"，别人必须配合；③ 设定项目的总体目标；④ 明确项目与组织战略目标之间的直接关联——说白了，就是让所有人知道"我们干这件事，是为了公司的那件大事"。 > 为什么"批准即启动"这四个字这么重要？因为从这一刻起，项目花的每一分钱、占用的每一份人力，才算有了正式出处；后面的范围、进度、成本、风险计划，才有立足点。反过来说，章程迟迟不批就大干快上，那叫无授权施工——做得越多，风险越大。 > 再补一个同学常问的问题：章程批了以后还能改吗？答案是——重大变更需要经过发起人或批准人同意，并走变更流程；章程本身不做日常修改。 日常调整写进项目管理计划，不要动不动就去改章程。 > 再用一句话收口：章程既是"授权书"——给你调人调钱的权力；也是"责任书"——目标、边界、里程碑、审批要求都白纸黑字写在那里，干不成是要交代的。

> 口播：制定章程不是拍脑袋写作文，它有四类依据，缺一样都会写歪。我们一类一类看。 > 第一类，立项管理文件。 它包含商业需求、成本效益分析等内容，是前面立项、可行性研究、评估决策留下的成果，为决策提供依据。这里有个考点请注意：项目经理无权直接修改立项管理文件，但可以提出调整建议。 为什么？因为它是上级或评审机构批准过的文件，改它就等于改决策依据，必须走流程、留痕迹。 > 第二类，合同。 如果项目是替外部客户做的，合同就是法律框架：目标、范围、交付要求、付款条款都在里面。章程的很多内容，其实就是把合同语言翻译成项目语言。还要注意一条——章程不能与合同冲突，合同优先。 > 第三类，事业环境因素。 分内外两部分：内部包括组织文化、组织结构、设施、IT 工具、资源可用性、员工能力；外部包括市场、法律法规、行业标准、财务环境。举我们案例里的例子：门店网络条件差、收银员对电脑操作不熟练，这些都属于内部环境因素，会直接影响界面设计和培训方案——你在章程里写目标的时候，就得把它们考虑进去。 > 第四类，组织过程资产。 包括标准化政策、流程、程序，监督与报告机制，模板（比如公司统一的项目章程模板），以及历史数据与经验教训库。这类东西的最大价值是四个字：别重新发明轮子。上一轮项目踩过的坑，已经写成经验教训了，你照着改、照着避就行。 > 讲完四类依据，有两个提醒必须说。第一，项目章程是连接项目执行与需求的纽带，它要确保项目既符合组织战略目标，又能和日常运营衔接。第二，应尽早任命项目经理，最好在制定章程的时候就确认——因为章程批准之后，项目经理才获得调配资源的正式权力。太晚任命，等于开局就慢半拍。 > 最后呼应一下上节课：第三、第四类依据，就是第 1 章讲过的"事业环境因素"和"组织过程资产"——同一个概念，到启动阶段就要真正用起来，而不是停在名词解释上。 > 再补一句总结：这四类依据里，前两类管"该做什么"，后两类管"能怎么做"，一条一条对齐，章程才不会写成空中楼阁。

> 口播：有了依据，接下来用什么方法把章程写出来？五种，请先记口诀：专家、脑暴、焦点、访谈、人际技能。 > ① 专家判断：请具备领域专业知识、经验和技能的个人或小组，基于对项目的深入理解给出判断。举个例子：智能库存系统里"预测算法的准确率目标定到多少才合理"，就该去问做过零售预测的专家，而不是坐在会议室里拍脑袋。 > ② 头脑风暴：团队协作的创意生成方法，集思广益，短时间内产生大量想法和解决方案。它的规矩是——先求量、不批判，把话都说出来。 > ③ 焦点小组：结构化讨论，由有相关背景的人组成，围绕目标、需求、风险、成功标准收集深度意见。放到案例里，就是把总部采购、门店店长、IT 运维请到一张桌上，专门谈"这个项目做成什么样才算成功"。 > ④ 访谈：与干系人或专家一对一沟通，收集高层级需求、假设条件、制约因素、审批标准等关键信息。一对一的好处是：有些话，人在大会上不会说，在办公室里才会说。 > ⑤ 人际关系与团队技能：通过冲突管理、引导等技巧，确保章程实际可行、各方需求都被考虑。举个具体冲突：门店希望"操作越简单越好"，IT 希望"数据实时同步"，两个诉求天然打架，这时候就需要有人把双方拉回到一个可执行的平衡点上。 > 生活化类比：这五种方法很像装修前的准备——找老师傅看房屋结构（专家判断）、一家人随口说想要什么（头脑风暴）、拉上设计师坐下来定风格（焦点小组）、单独问问老人用起来方不方便（访谈）、最后靠嘴皮子把争执拉回一个方案（人际技能）。 > 给一个判断抓手，方便你考试时对号入座：问"经验"用专家判断，问"数量"用头脑风暴，问"深度共识"用焦点小组，问"敏感信息"用访谈，问"矛盾"用冲突管理与引导技巧。 > 最后提示一句：这五种方法在后面范围、进度、风险各章还会反复出现，它们是项目管理的"通用工具箱"，今天先混个脸熟。

> 口播：制定章程的结果有两样东西：一份项目章程，和一本假设日志。 > 先说章程的 11 项核心内容。我按"为什么做、做成什么样、有什么风险、花多少钱、谁来管"这条主线把它串起来，你不用死记顺序，但要能一条一条数出来。 > 先说"为什么做"：① 项目目的；③ 高层级需求与描述。再说"做成什么样"：② 可测量的项目目标和成功标准；⑤ 总体里程碑进度计划；⑨ 项目退出标准。接着说"有什么风险、要满足什么条件"：④ 整体项目风险；⑧ 项目审批要求。最后是"花多少钱、谁来管"：⑥ 预先批准的财务资源；⑦ 关键项目干系人名单；⑩ 项目经理及其职责和职权；⑪ 发起人或其他批准人员信息。 > 我们数一遍：一二三四五六七八九十、十一——11 条，一条不少。 > 请注意这里的关键词："高层级"和"总体"。章程只写"总体里程碑进度计划"，不写"第 3 周完成数据库详细设计"；只写"预先批准的财务资源"，不写每一项采购的报价。章程要高层级，不写细活。 > 第二样产出是假设日志，用来记录项目生命周期中的假设条件和制约因素——比如"预算上限是多少""交付周期不能超过多久""假设门店网络改造后能支持数据实时同步"。为什么要单独记一本？因为假设一旦不成立，计划就得重做，它是最早、最便宜的风险识别机会。 > 顺带说一句：章程的这些内容，不是给项目经理一个人看的——发起人看的是目的和目标，团队成员看的是里程碑和职责，财务看的是预先批准的预算。同一份文件，不同的人各取所需，这就是它必须写清楚的原因。 > 章程写完怎么自检？我给大家准备了自检五问，请跟我一起念一遍：目的清不清？目标能不能量？风险列没列？里程碑有没有？谁批谁管写没写？ 这五问全答得上来，章程基本就站得住。 > 课堂练习：请判断下列内容是否属于项目章程。A．"本项目须在 2027 年 6 月 30 日前上线"；B．"第 3 周完成数据库详细设计"；C．"项目经理有权调配 5 人以内开发资源"；D．"采用 Vue 3 ＋ Spring Boot 技术栈"。 > 答案：A 属于——它是总体里程碑进度计划；C 属于——它是项目经理及其职责和职权；B 不属于——它是详细的进度计划，属于后续的项目管理计划；D 不属于——它是技术方案，通常写在技术文档或项目管理计划里。请记住这句话：章程管授权和边界，不写细活。

> 口播：最后一块内容：项目启动大会。前面所有工作都是"先把事想清楚"，启动大会是把这些成果从文件里搬出来，当着所有人的面讲清楚、认下来。 > 项目启动会议是项目生命周期中的关键环节，它标志着项目正式步入实施阶段，由项目经理主导，目的是确保各方干系人对项目目标、范围、需求、背景以及各自的职责有清晰认识。 > 一句话记住它的分量：启动大会不是"宣布开工"的仪式，而是"对齐共识"的现场。 > 还有一点要提醒：启动大会不是"领导讲话会"，主角是项目经理和团队——领导到场是表态支持，真正的信息传递和分工确认，必须由项目经理来完成。 > 下一页我们讲三件事：请哪些人、走哪几步、要拿到什么结论。

> 口播：项目启动会议是项目生命周期中的关键环节，标志着项目正式步入实施阶段，由项目经理主导，确保各方干系人对项目目标、范围、需求、背景及各自职责有清晰认识。我们讲三块。 > 第一块，参会人员。 内部包括：项目经理、团队成员、公司领导、PMO 代表、变更控制委员会即 CCB 成员、相关职能部门负责人。外部包括：客户代表、供应商代表等关键干系人。这里有一个细节要划重点——参会名单由项目经理审核。为什么强调这一点？因为名单就是"谁被正式纳入了项目"的证据；名单漏了谁，后面争论"这事该谁配合"时你就没有依据。 > 第二块，会议流程，分三段。 ① 会前筹备：确认汇报材料、议程、人员名单，完成通知与签到。别小看签到，它是"信息已传达"的书面痕迹。② 核心环节：项目经理介绍项目——目标、里程碑、分工、风险等，然后是答疑澄清，最后请公司领导做动员。③ 会后输出：生成会议纪要，记录主题、结论、待办等，作为后续跟踪的依据。 > 第三块，要拿到的关键结论，四条。 第一，团队对项目基本信息、目标和计划有全面了解；第二，明确项目风险识别清单及初步应对措施；第三，确定项目总体分工及下阶段工作任务；第四，增强项目团队成员的凝聚力和士气——这一条看着"软"，其实最硬，因为项目后期靠的就是这股劲。 > 现在回扣我们的案例：超市项目"启动了，但没启动透"——启动会上团队对整体目标只有初步理解，具体实施步骤、任务分配、风险挑战的认知仍然比较薄弱。这就是典型的"形式启动了、实质没启动"。判断一次启动会成不成功，就看三件事：目标是否对齐、分工是否清楚、风险是否上桌。

> 口播：启动大会的最后一块，是待办事项。课件里给了两条：第一，根据会议内容编制《项目启动会议纪要》，确保所有相关责任人都收到；第二，相关责任人按纪要要求开展各自工作，确保项目顺利推进。 > 请看表 2-4，这是项目启动会议纪要模板，我们逐行过一遍。表头部分：会议名称（项目启动会）、会议主题/时间/地点、记录人/审核人、参会人员。正文部分三块：会议内容——记录讨论事项，并分项罗列具体讨论的问题；会议结论——记录讨论结果，并针对具体问题得出讨论结论；待办事项——记录待解决的问题和待跟进的事项。 > 这张表最容易被当成"填空题"，我要特别强调一句：纪要不是"会议流水账"，而是"责任清单＋跟踪依据"。 什么叫流水账？就是"某年某月某日开会，领导讲话，大家讨论热烈"——这种纪要写完就进抽屉。什么叫责任清单？就是每一条待办都能回答三个问题：谁负责？什么时候完成？完成的标志是什么？ > 给大家一个可以直接用的写法：待办事项不要写"尽快完成需求调研"，而要多写几个字——写成"由某某（责任人）在某个时点前（期限）提交需求调研提纲（交付物），并抄送项目经理"。多写这一句，纪要就从"记录"变成了"管理工具"。 > 另一个细节：模板里为什么要有"记录人/审核人"？因为纪要也需要审核确认——记录人负责如实记录，审核人负责认定结论，这样纪要在后续追责和变更时才有公信力。 > 最后强调一句：纪要在会后及时发出，并确保所有相关责任人都收到。没收到，等于没写；没写，等于白开。 > 我再补一个很实用的动作：纪要发出之后，下一次例会的第一件事就是对着待办清单逐条过——完成的项目销项，没完成的当场说明原因、给出补救计划和时间点。这样纪要才不只是"发出去了"，而是真的在推动项目往前走。 > 反过来提醒一句：如果待办清单写完就没人再看，这个项目很快就会进入"开会—忘记—再开会"的循环，这也正是很多项目"会开了不少、进度却没动"的原因。

> 口播：今天我们用一张全景图收口，请大家跟着我一起走一遍这条知识线。 > 01 启动概述：五个环节——建议书、可行性研究、评估与决策、章程／经理／干系人、启动大会。一句话就是：立项决定"干不干"，章程决定"谁来干、怎么干"，启动会决定"大家认不认"。 > 02 项目立项：四阶段流程；小型项目可合并初步与详细可研，但详细可行性研究不可或缺；五个维度是技术、经济、社会效益、运行环境、其他（法律与政策）；评估必须由第三方独立完成，再据以决策。 > 03 项目准备工作：选对人——项目经理的来源、四种能力、七项职责与五类权力；搭对架子——职能型部门说了算、PM 权力最小，项目型经理说了算、PM 权力最大，矩阵型两个领导共享管理权、资源最省但责权必须划清。口诀：小项目看职能、大攻关看项目型、多项目并行看矩阵。 > 04 到 06 是三件事：识别干系人（内 5 类＋外 5 类，漏掉关键干系人就要多付十倍沟通成本）；制定章程（四类依据、五种方法、11 项核心内容＋假设日志，自检五问）；开好启动大会（人员、流程、四条结论，会后的纪要是责任清单＋跟踪依据）。 > 【思政落点 4】（1 分钟） > 今天有一条线贯穿始终，我要郑重地说一遍：依法合规、实事求是、客观公正。立项与招投标要遵纪守法、程序合规，因为程序是最可靠的防错机制；可行性研究要实事求是、科学严谨，不能"为了通过而论证"，数据不能凑、效益不能吹；第三方评估要独立客观，不能既当运动员又当裁判。同学们将来一定会遇到"先把项目立了、手续后补"这类诱惑，请记住：把项目做对，先要把人做正。 > 作业布置（计入平时成绩，学习通提交）：① 项目建议书的作用是什么？② 项目可行性研究内容有哪些？③ 项目可行性研究阶段包括哪些？④ 项目经理需要哪些能力？⑤ 对于给定的软件项目案例，分析其在项目启动过程中出现的问题。⑥ （思政思考题） 结合政府采购或企业招标中的一个真实案例，分析"围标串标""最低价中标忽视质量"等现象对项目的影响，谈谈坚守诚信底线、依法合规的重要性，300 字以内。 > 下节课预告：第 3 章软件项目采购管理——东西怎么买、招投标怎么组织、评分表怎么编、合同怎么签怎么管。提前想一想：如果一个项目必须外包，你最担心什么？ > 今天就到这里，下课，同学们再见！

## 四、板书设计（建议）

黑板分三块，随讲课逐步生成：

`` ┌────────────────────┬─────────────────────┬──────────────────────────┐ │ ① 流程区（左） │ ② 对照区（中） │ ③ 案例诊断区（右，全程保留）│ │ │ │ │ │ 启动五环节： │ 组织结构三选： │ 超市智能库存系统踩的五个坑：│ │ 建议书 → 可研 → │ 职能型=部门说了算 │ ① 技术可研空心 │ │ 决策 → 基础工作 → │ 项目型=经理说了算 │ （算法/集成/补货方案） │ │ 启动会 │ 矩阵型=共享管理权 │ ② 干系人漏识别（业务部门）│ │ │ （两个领导·责权要清） │ ③ 沟通无规划 │ │ 可研五维度： │ │ ④ 风险未识别（跨领域） │ │ 技术·经济·社会· │ 干系人：内5（发起人/ │ ⑤ 启动会没开透 │ │ 运行环境·其他 │ 经理/团队/职能经理/ │ │ │ （法律·政策） │ PMO）外5（客户/用户/ │ 对策：补技术可研＋干系人 │ │ │ 供应商/监管/股东） │ ＋沟通计划＋风险清单＋ │ │ 章程＝授权书＋责任书 │ │ 启动会做深做实 │ │ 自检5问：目的清不清· │ 判断口诀：小项目看职能│ │ │ 目标可量否·风险列没列│ 大攻关看项目型· │ 金句：把项目做对， │ │ 里程碑有没·谁批谁管 │ 多项目并行看矩阵 │ 先要把人做正 │ └────────────────────┴─────────────────────┴──────────────────────────┘ ``

## 五、常见学生疑问与应答