简介这是一份面向软件项目经理、立项负责人及产品团队的「软件项目立项书」标准文档模板主要解决项目启动阶段缺少规范立项文件、目标与约束定义不清、评审缺乏依据等问题。文档以doc格式提供共1个文件压缩包约83KB正文按标准立项书结构组织包含项目名称与版本编号规范、拟制/审核/批准日期、修订历史记录、目录以及引言、项目概述、项目目标、规定与约束、项目工作范围、应交付成果、项目验收方式、项目团队组织等章节其中“应交付成果”进一步细分为需完成的项目建设、需提交用户的文档、须提交内部文档和应当提供的服务团队成员的组织结构、人员分工与协作沟通方式也有专门说明方便直接套用。目前已有1578人浏览学习适合在项目立项、方案评审或内部流程规范化时参考。借助该模板读者可快速搭建一套结构完整、符合常规评审要求的立项书框架减少从零起草与反复修改的成本。1. 软件项目立项书不是走流程是给项目上保险做一个软件项目最怕的不是技术难题而是项目刚开始时大家都没把话说透。需求方以为“很简单”研发以为“早说清楚”预算以为“花不了多少”结果三个月后需求变更堆积、预算超支、验收标准各执一词只能回过头去翻聊天记录和邮件最后变成互相甩锅。软件项目立项书就是为了提前终结这种混乱它在项目启动前把目标、范围、进度、预算、风险和团队分工一次性写到纸面上作为项目生命周期内所有活动的行动基础。刚接项目还摸不清边界的新人、被需求变更折磨的研发负责人、要跟投资方交代成本的管理者都需要这份模板。2. 立项书框架拆解从引言到交付成果每一节都在回答什么问题立项书的头部到交付成果这一段是全文的主干。我在实际填过几次之后发现这一段的每一节其实都在回答一个具体问题写的时候要带着问题去填而不是对着模板抄句子。2.1 引言四件套目的、背景、定义、参考资料的写法引言第一节是“目的”。模板里专门注释了注意这里的“目的”不是“项目目标”而是说明“这份立项书”存在的意义。很多人在这一栏直接写系统的功能等于把引言变成了需求文档。标准写法是使项目成员和项目干系人了解项目开发计划书的作用让项目团队根据本计划书开展和检查项目工作。我一般会在开头加一句“为了保证项目团队按时保质地完成项目目标”这句话看似套话实际是把立项书的执行力立住了——它不是说给上级听的是说给所有项目成员听的。接着是“背景”。这一节要回答四个 W项目名称是什么、委托单位是谁、用户单位是哪家、主要承担部门是哪个。如果这些信息不写清楚后面所有责任界定都会变成一笔糊涂账。我见过一个案例某跨平台系统升级背景里只写了“满足业务发展需要”没写委托单位和用户部门做到一半业务部门不认账说场景根本不是他们提的最后只能重新调研。背景还要交代来龙去脉这个系统为什么现在要做是监管要求、业务流程变化还是原有系统撑不住了从政治环境和业务环境两个角度写清楚项目成员才知道自己在为什么而战。再往下是“定义”和“参考资料”。定义一节列出为正确理解本计划书所用的专门术语、外文缩写词的原词及中文解释。这里有一条红线不要对业界通用术语做自定义解释否则团队内外沟通反而会产生歧义。“参考资料”要列出引用的文件资料和标准并说明获取途径常见的有项目合同、标书、上级通知、审批过的任务书。注意分辨它与后面“标准、条约和约定”的差异——参考资料是“参考”的标准条约是“必须遵守”的。我通常会列一个小表把这两个容易混淆的章节区分开章节特性判断标准1.4 参考资料参考性质要说明从哪里可以获得1.5 标准、条约和约定强制性质必须遵守不说明获取途径2.2 项目概述目标、约束、范围、交付成果的实质填法引言写完后进入项目概述这里是立项书的核心区。先写项目目标。目标可以横向分解也可以纵向分解横向是按业务线拆比如第一目标是基础数据模块上线第二目标是审批流程上线纵向是按阶段拆比如第一阶段完成需求调研第二阶段完成编码测试第三阶段完成部署验收。无论哪种拆法阶段目标都必须带上明确的时间点。我写目标的习惯是先写总目标再加一句“为实现项目的总目标必须实现以下阶段目标”然后列出各阶段目标评审人一眼就能看出层次。紧接着是规定与约束。这块很多人写不明白。规定是通过努力可以直接解决的问题属于“一定要解决才能保证项目按计划完成”的比如“必须在三天内完成需求文档确认”约束一般是难以回避的限制比如人力资源紧张只能牺牲进度或质量去平衡。判断标准就一条这件事是努力就能解决的还是怎么努力也绕不开的如果问题的出现具有不确定性就不该写在这里而要放进风险分析里。新手经常把“可能缺人”写进约束这其实是风险应该在实施计划里做概率和影响评估。然后写项目工作范围和应交付成果。范围这一节建议用功能清单替代描述性文字把要做的模块逐条列出同时把明确不做的内容也写出来后期需求变更会少一大半。应交付成果在模板里拆成四类需完成的项目建设、需提交用户的文档、须提交内部的文档、应当提供的服务。这里最常见的坑是漏掉后两类尤其培训和维护合同里可能写了但立项书里不体现项目结束时就变成口头承诺客户追着要你才想起来。我每次填完这节都会做一次交叉检查合同里的每一项服务承诺在立项书应交付成果里必须找得到对应条目。2.3 验收方式怎么定验收标准才不会事后扯皮验收这一节容易被写成“按合同验收”四个字等于没写。我在实施过程中积累的经验是验收方式至少要说清三件事内部验收和用户验收的区别、验收依据是什么、验收不通过的处理办法。内部验收是团队自查阶段通常用测试报告、代码走查记录、性能指标作为依据。用户验收是客户确认阶段一般以需求规格说明书和试运行期间的反馈记录为基准。验收依据要具体到文档名称和版本比如“根据发布日期为某月某日的需求规格说明书逐项核对”而不是模糊地写“根据功能需求”。验收流程还要写明由谁组织、由谁参与、什么时间进行、不通过怎么办。这些细节看起来琐碎但到了验收节点它们就是避免双方扯皮的全部依据。注意验收方式这一节最好在项目启动会上跟客户方逐条确认一遍。立案书签了字不代表客户记住了内容现场对齐一遍后面能少很多争执。3. 团队组织与实施计划把人的分工和项目节奏定在纸面上立项书如果只写到目标、范围和交付物就停笔那它还是一份“计划意图声明”。真正让项目能落地的是团队怎么组织、风险怎么识别、进度怎么控制这三个部分。这一章我把模板的项目团队组织和实施计划合并起来拆。3.1 组织结构与人员分工角色怎么设、分工表怎么填模板里组织结构一节要求说明项目团队需要哪些角色构成、成员来自哪个部门、各角色应该具备什么技术水平。以典型的研发项目为例角色一般包括项目总负责人、项目经理、需求分析师、架构师、开发工程师、测试工程师、运维工程师、业务接口人。注意业务接口人这个角色经常被漏掉它的存在价值是确保需求变更时有专人对接避免开发直接跟用户拉扯。组织结构可以用图形表示也可以用文字说明。除了图形外模板要求说明各个角色应有的技术水平我的做法是画一张角色与职责的对照表角色职责必备技能项目总负责人对项目整体成败负责协调外部资源管理经验、决策能力项目经理编制计划、监控进度与预算、组织评审项目管理工具、沟通能力需求分析师调研需求、编写需求文档、维护需求基线业务理解、文档编写架构师系统架构设计、关键技术选型架构设计、目标技术栈开发工程师编码实现、单元测试开发语言、调试工具测试工程师编写测试用例、执行测试、输出测试报告测试方法、缺陷管理运维工程师环境搭建、部署、运行监控部署脚本、故障排查业务接口人对接用户需求、确认变更事项业务知识、协调能力这张表填完后要落到具体的人写上成员姓名和在项目中的配置。有些公司出于隐私不会写姓名至少写角色编号和来源部门例如“需求分析师岗位由某部门A同事承担”后期人员变动也能追溯到责任人。人员分工的描述要具体到任务不要写“负责开发”而要写“负责哪些模块的编码和对应单元测试”。3.2 风险评估识别、概率、影响、对策四步走风险章节是立项书里最能看到功力的部分。模板给出的风险维度很实用工程规模进度风险比如验收延迟技术风险比如使用新技术或新设备没有经验、进入新行业业务不熟、性能要求严格用户方面的问题比如功能多次变更、用户承担的工作延误其他推测可能存在但尚未验证的风险。这个清单基本覆盖了软件项目八成以上的风险我拿到一个新项目会先按这几个维度逐项排查再补充该项目的特有风险。每一条风险要写清楚四件事风险描述、发生概率、造成的影响、应对措施。对策分三种——避免、减缓、吸纳。避免是排除风险起源最常见的是调整技术方案或砍掉高风险需求减缓是通过投入资源把概率或影响降下来比如提前做技术验证、引入外部咨询吸纳是接受后果适用于影响小或无法规避的风险比如接受项目利润降低、加班赶工。我在立项书里习惯做出风险矩阵表直接在表格里管理这些信息风险项概率影响等级对策需求频繁变更中高高减缓建立需求基线变更走评审流程关键新技术无项目经验高中高避免启动前先做技术验证预留学习时间用户配合工作延迟中中中减缓接口人每周对齐逐级上报验收进度拖延中高高吸纳进度计划预留缓冲试运行提前启动每条风险还要指定一名责任人并写明检查时间点。做到这一步风险评估才不是走过场。3.3 进度计划与里程碑阶段划分、评审缓冲和项目控制总体进度计划是项目延期的重灾区。模板要求列出项目阶段划分、阶段进度安排、每阶段应提交的成果并强调在安排阶段时间时要考虑项目阶段成果完成、提交评审、修改的时间。很多项目延期在计划阶段就已经埋下了雷——没有给评审和修改留缓冲。我的常用做法是做一张阶段计划表每一行都带交付物和起止时间阶段主要任务起止时间里程碑/交付物计划与准备立项书评审、项目启动会第1周立项书批准需求调研需求收集、访谈、原型确认第2—5周需求规格说明书系统设计架构设计、详细设计评审第5—8周设计文档编码实现模块开发、单元测试第8—15周代码与单元测试报告测试集成测试、系统测试第15—18周测试报告部署验收安装部署、试运行、用户培训、验收第18—23周验收报告注意测试阶段结束后到验收之间一定要留出至少两周的缓冲用于修复验收过程中发现的问题。控制计划方面质量保证要定义哪些记录需要保存以及保存期限比如测试记录保留半年还是三个月提前写死进度控制由项目过程控制部门或人员统一监控保留日常检查记录预算监控则定期核对实际花费与预算偏差偏差超过 10% 就预警。这三项控制计划看似管理性内容实际是项目过程中检查大家有没有偏离轨道的工具。4. 预算与支持条件把成本算明白把依赖写清楚预算这一章在立项书里常常被随手填几个数字但预算一旦失真项目后期要么超支要么追加申请被驳回。这一章拆开讲预算明细的写法以及支持条件里那些容易遗漏的依赖关系。4.1 人员成本与设备成本工作人月怎么估、硬件软件怎么列人员成本是预算的大头算法也简单每个成员预计工作人月乘以月成本。关键难在人月怎么估。我的做法是列出每个角色的投入时长按全职等效人月来算不要只写人数。比如一个开发工程师全职投入四个月记为 4 人月如果一半时间参与记为 2 人月。模板也要求列出团队每一个人的预计工作月数并把劳务需求按数量和时间两项展开。下面是一张某项目的人员成本示例表角色人数投入人月月成本万元小计万元项目总负责人11.53.04.5项目经理14.02.510.0需求分析师12.52.05.0架构师12.03.06.0开发工程师310.01.818.0测试工程师26.01.59.0运维工程师12.01.53.0业务接口人13.01.23.6合计—31.0—59.1设备成本分三类原材料费设备购置及使用费软件购置费。服务器需求要写明配置、数量和经费数据库授权、开发工具、测试工具的许可证费用也要单独列出。我见过太多人只写硬件不写软件最后数据库授权费从项目奖金里扣真的是血泪教训。4.2 其他经费预算差旅、资料、会议、培训的七类拆法模板对其他经费的分类很细致项目一复杂就容易漏项。我在立项阶段按七类逐项估算每类都给出金额和使用说明差旅费包括旅费、出租车费和出差补贴资料费包括图书、资料、复印和出版费用通信费包括市话长话、移动通信、上网费和邮资会议费包括鉴定会、评审会、研讨会和外事费办公费是购买办公用品的支出协作费是业务协作招待费和项目团队加班伙食费培训费包括培训资料编写、资料印刷、场地和设备费用。经验是每类经费估算后再预留总额约 5% 的机动预算用来应对临时出现的检测费、维修费和消耗品支出。如果项目涉及外包把外包单独列一行标注外包模块的边界和结算方式避免结算时说不清楚。4.3 支持条件内部、客户、外部三方配合清单支持条件这一章经常被当成可有可无的内容实际上它是项目能否顺利推进的依赖清单。内部支持要逐项列出项目每个阶段的支持需求包括人员、设备、软件、培训及时间要求比如“系统设计阶段需要公司内部安全评审人员投入 2 人天”。客户支持要列出需由客户承担的工作、完成期限和验收标准比如“客户需在某日期前提供业务数据样例并完成数据字典确认”。外部支持要列出需由外部支持方承担的工作和完成时间。这三项支持清单写清楚之后项目的依赖关系就一目了然后期出问题时能快速定位责任方而不是项目经理到处找人问当初是谁承诺的。4.4 项目合计经费预算一张总表收拢所有成本项目合计经费预算是前面的汇总我在立项书里会做一张总账表预算类别金额万元占比人员成本59.178.8%设备成本8.511.3%其他经费5.47.2%机动预留2.02.7%合计75.0100%这张表不仅是给领导看的更重要的是给项目经理在过程中做预算监控用的。预算监控计划要求说明如何检查项目预算的使用情况这张表就是检查工具。如果项目结束时实际支出超出合计预算的幅度较大超支理由和批准记录必须存档否则审计阶段就是大麻烦。5. 立项书翻车现场五条避坑记录这些年下来我见过不少立项书写完就当摆设的情况。下面五条坑位是最典型的每一条按照现象、原因、解决的思路拆开可以对照自己手上的立项书自查。5.1 “目的”一节写成了项目目标现象立项书里 1.1 目的整段描述系统功能比如“本系统将实现流程审批、数据看板……”引言部分直接写成了需求文档。 原因模板注释里明确写了“注意这里的目的不是项目目标”但填写的人没细读把系统要实现的东西填在了文档目的上立项书本身的定位反而没说明白。 解决确认“目的”回答的是“这份立项书为什么存在”而不是“系统要做什么”。标准写法是先说这是项目成员及干系人之间的共识与约定再说明它是项目生命周期所有活动的行动基础。系统功能留给 2.1 项目目标去写。5.2 风险只列不评等于没写现象风险章节写了十几条风险每条只有一句描述没有发生概率、没有影响评估、没有对策。评审会上被问“这条风险概率多高”负责人答不上来。 原因没有意识到风险需要量化评估或者刻意回避量化担心风险写得太严重吓到投资方。 解决把每条风险的概率和影响都分成高、中、低三级用矩阵法给总等级。概率高影响低的风险用简单应对即可概率低影响高的风险要重点防护。在对策里写清楚应对方案和启动条件投资方看到你有预案反而对项目更有信心。5.3 预算只算人不算差旅和培训现象总预算只写了人员成本项目中期因出差经费超标需要临时追加预算审批流程走了一个多月项目因等待批准被迫停工。 原因立项时只关注占大头的人员成本漏算了差旅、培训、会议等小项这些漏掉的事项到执行阶段全变成额外负担。 解决立项阶段把其他经费分类清单从头到尾过一遍每类都填一个数字即使估不准也要填一个占总额的百分比。如果是外地实施项目差旅费按实施人月乘以预估出差天数来估不要拍脑袋。5.4 验收方式写“按合同验收”验收时双方扯皮现象项目试运行结束客户认为某些功能“做得不好”拒绝签字验收团队认为功能已按需求文档实现双方各执一词。 原因验收章节只写了“按合同验收”但合同附件里的功能清单与需求文档版本不一致评审时也没有双方确认过。 解决立项书里的验收方式写明三件事验收依据是哪一版需求文档验收流程分哪些步骤验收不通过怎么处理。例如写成“根据某月某日批准的需求规格说明书逐项核对未通过项由双方协商在一个月内修复并再次验收”。注意验收方式这节要单独拿出来跟客户在启动会上逐行确认一次签字只是形式现场对齐才是真保险。5.5 进度计划没有预留评审和修改时间现象进度计划从编码到上线只排了六周没有评审缓冲。第一次设计评审后因为原型反馈需求返工了两周整个计划全部作废。 原因把理想状态当现实认为每阶段成果一次就能通过评审。实际项目里评审加修改通常要占阶段工期的 15% 到 20%。 解决每个阶段在时间安排上明确写出评审和修改的时间段比如“第5周提交需求文档第5—6周评审与修正”把评审作为独立任务写进计划表。以后无论工期多紧评审缓冲至少保留三天。6. 立项书落地后我习惯再做三个检查立项书写完不是终点它要在整个项目周期内持续发挥作用。我有三个检查习惯每次新项目立项都要走一遍。第一个是“一分钟可读懂”检查。拿立项书给一个没参与项目的同事看他能不能在一分钟内说清项目目标、交付物和最大的风险。如果说不清说明结论不突出要把每一节的结论提到开头。比如“项目核心风险是数据迁移失败其余风险都在可接受范围”这样写就比“本项目存在若干风险”有用得多。每小节第一句就该是答案后面才是解释。第二个是双向验证。把项目目标里每个可测量指标到验收方式里找对应的验收办法反过来验收方式里的每条标准到项目目标里找对应的来源。找不到对应关系的就是描述不完整。这种反向校验每周做一次能发现不少两章节各写各的、互相矛盾的问题。第三个是版本与修订习惯。模板里的修订历史记录是立项书极其关键的部分但很多团队直接忽略。立项书在项目过程中会反复调整没有留痕几个月后就说不清当初为什么这么写。从那以后我每次更新立项书都强制走一遍流程改版本号、更新修订历史表、在说明栏标注 A/M/D 对应添加修改删除、让审核人和批准人重新签日期。这份修订记录是后期出现争议时的项目证据不是应付差事的表单。另外立项书更新后导成 PDF 放到项目共享目录例会开始前把当前版本号和修订摘要贴到会议纪要里。时间紧张时只贴修订行大家就知道这次讨论的是哪一版。这套模板的章节结构覆盖了引言、概述、团队、计划、预算、支持条件和关键问题算是我见过比较完整的立项书框架。把这份资源下载到本地后建议按自己项目的实际情况逐节替换填写再用上面三个检查方法过一遍比从零开始写要省太多时间。希望帮到你。本文还有配套的精品资源点击获取