软件项目的管理流程

销售关乎企业生死，可是很多企业的销售流程体系是散乱无序、效率低下；没能洞察市场寻找更多商机，项目线索不够多，即便有了项目线索也因为没能尽早有效跟踪培育线索而失去项目机会；难以快速响应客户需求；面向客户界面混乱，销售人员基本是单兵作战，难以形成战斗力，很多销售人员销售经验能力又不足，直接导致的结果就是：市场中标概率小、中标了交付也存在各种各样风险与问题、回款缓慢甚至最后成为“烂尾工程”应收帐款巨大这时候，就很有必要梳理并重造流程，并且基于流程，进行销售能力提升，构建出有执行力、有创造力、有活力的狼性营销组织。

华为LTC销售流程变革项目就是一个典型的案例，其经验值得各企业参考。其基本方法是，梳理并再造销售流程，并且把合适的销售方法、销售理念等嵌入到流程当中，同时还会组织很多场销售能力赋能培训，并提供相应的工具和模板，使得企业获得的不仅是“生硬而冷冰冰”的新销售流程，而是整个销售体系升级（包括流程、销售方法、销售工具、销售模板、人员软能力等等），努力达到这样的目标：构建出优秀的销售组织能力，未来企业项目的成功与否不再严重依赖销售个人能力及其偶然性，而是用组织能力、制度去保障提升销售成功率。新员工入职，只要经过新的销售体系培训，并按照销售流程去进行项目运作，那么可达到资深老销售的水平，确保一定的项目成功率。（不再像过去，如果资深老销售离职，就会严重影响业绩，从而实现“铁打的营盘流水的兵”，销售组织体系和流程足够成熟，人员流动对业绩冲击变小）。

许浩明老师有幸被华为抽调加入了LTC变革项目华为团队方案组与埃森哲咨询团队深度合作，一起完成了华为LTC项目的方案设计与推行，因此，在这里做些分享，希望对其他企业有一定启发，少走一些弯路

为什么华为要下决心花费几十亿来做LTC变革项目呢？因为华为已感觉到LTC项目启动之前的流程支离破碎，没有跨部门的结构化流程，没有统一端到端拉通，效率不高，项目运作质量差，制约华为发展，通过早些年的研发IPD变革项目，华为产品研发有了长足发展，可是销售线明显感觉跟不上业务发展需要，因此决心对销售流程“动大手术”，就像要成为武林高手，需打通任督二脉一样，华为希望，努力打通企业的任督二脉：研发（IPD）和销售（LTC）两条主流程（脉络），以促进和支撑业务快速发展，成为顶尖高手。

可是，LTC项目涉及了公司的正在运行中所有销售业务（项目启动之时销售收入已超3000亿），困难程度可想而知，有人比喻说，LTC变革项目就像是高速公路上给奔跑着的跑车换轮胎。确实是很有挑战的，因为不能影响公司业务呀，怎么办？所以当时变革项目我们就要谨慎地分阶段进行，第一阶段是：问题调研（面向全球各一线发问卷调查，当面访谈一部分一线，再结合从一线回来的专家的意见，归类总结出面临的、急需解决的问题）；第二阶段是方案规划设计阶段。埃森哲与华为进行梳理，输出切实可行的细化方案（这个过程，华为专家和埃森哲不断地探讨，不断地聆听一线的反馈意见，不断地优化，无数个轮回碰撞，争吵，最终才形成一个阶段性方案）；第三阶段是IT开发阶段（流程的落地，需要IT系统来承载，让所有的关键任务活动都在IT系统里跑起来，最后LTC的IT就是只要有网络，只需在IE等浏览器输入网址即可访问使用）；第四阶段是找代表处进行试点，然后再优化流程；第五阶段是找各不同区域的典型代表处来试点，然后继续优化流程；第六阶段是小面积推行，然后继续优化流程；第七阶段就是流程成熟，可大面积推广；第八阶段是不断收集问题反馈进行流程优化，发布给全球各区域使用。

另外，在LTC变革项目里，华为方案组不仅与埃森哲咨询顾问合作讨论梳理并再造销售流程，并且还和其他咨询公司合作，把其他咨询公司合适的销售方法、销售理念（如SPI解决方案销售方法）等嵌入到销售流程当中，同时我们方案组建立或刷新了许许多多华为销售工具与模板，还组织无数场销售能力赋能培训，使得项目组结果不仅是“生硬而冷冰冰”的新销售流程，而是整个销售体系升级（包括流程、销售方法、销售工具、销售模板、人员软能力等等），努力达到这样的目标：构建出优秀的销售组织能力，未来项目的成功与否不再严重依赖销售个人能力及其偶然性，而是用组织能力、制度去保障提升销售成功率。新员工入职，只要经过新的销售体系培训，并按照销售流程去进行项目运作，那么可达到资深老销售的水平，确保一定的项目成功率。（不再像过去，如果资深老销售离职，就会严重影响业绩！从而实现“铁打的营盘流水的兵”，销售组织体系和流程足够成熟，人员流动对业绩冲击变小）。最后，我们LTC项目组的部分输出件如下：

《公司各流程关系总概览图》;《销售流程总概览图V11》;《线索管理流程V11》;《项目立项流程V11》;《线索跟踪培育流程V11》;《投标流程V11》;《合同评审流程V11》;《需求引导流程V11》;《合同谈判流程V11》;《合同签订流程V11》;《合同履行流程V11》;《方案设计流程V11》;《投标价格申请决策流程V11》;《销售项目策划报告模板V11》;《痛苦链分析模板V11》;《销售项目失败总结模板V11》;《销售引导九格构想模型模板V11》;《客户决策链分析（客户关系分析）模板V11》;《关键人物表模板V11》;《产品KeyMessage模板V11》;《项目运作checklist模板V11》;《洞察客户（客户档案）模板V11》;《全球山头项目模板V11》;《大客户管理模板V11》;《如何与CXO对话培训材料V11-学员版》;《谈判的道法术培训材料V11-学员版》;《向华为学习狼性营销培训材料V11-学员版》;《项目运作与管理培训材料V11-学员版》;《品牌营销培训材料V11-学员版》;《打造高绩效团队培训材料V11-学员版》;《华为执行力为何很强培训材料V11-学员版》;《狼性渠道管理培训材料V11-学员版》；《塑造卓越的企业文化培训材料V11-学员版》;《谁杀死了合同？V11-学员版》;《以终为始的目标与计划管理V11-学员版》;《战略管理、战略解码与战略执行V11-学员版》;《中层管理领导能力提升V11-学员版》;《跨部门的沟通与协作V11-学员版》;《华为质量管理体系V11-学员版》;

这点，值得其他企业参考借鉴，流程再造不仅仅是建立输出一些流程文件，而是升级组织销售能力，唯此，才能达到提高市场竞争力的目的，决不能为了仅仅为了造流程而造流程。

华为在管理变革、管理创新与流程再造方面，如下的一些做法也很值得参考：

1、华为有魄力，舍得投入。与很多企业老板的格局明显是不同的。很多企业老板，认为管理就那么回事，管理道理都懂，遇到管理问题，内部员工自己去讨论讨论，改一改流程和管理方法修修补补即可，觉得请顾问是在浪费钱财。殊不知，因为舍不得请顾问投入，而自己看待自己企业问题往往有局限性，同时也没那个决心和魄力（自己难以下手革自己的命），使得管理总是欠缺些什么，导致错失了发展良机，最终可能碌碌无为或者被市场竞争对手淘汰。

2、华为居安思危地不断“折腾”，不管变革，不断激活组织、激活人性。绝大多数企业，除非万不得已，否则是乐于呆在自己的“舒适区”，缺少危机感，缺少创新性的。

3、华为针对管理变革，定下了一些管理变革原则。有些企业老板想变革，但是往往做不下去，或者做得效果不怎么样，因为变革，意味着权力、利益等的变化，往往是阻力很大的，员工们也七嘴八舌，各有各的道理，所以没有一些变革原则，往往是失败而告终的。

4、变革的目标一定要清晰！不能因为变革而变革，而忘了企业的根本目标！

5、华为不断变革，总结出了变革成功的十六条经验

任正非说过，管理就是抓住三件事：客户、流程、绩效，华为未来留给世界只有流程与IT支撑的管理体系，因为每个人都会过世，每种产品都终将被淘汰；企业管理归根结底就是流程的管理，就是让业务在以客户为中心的高效的流程上面跑，因此企业的管理流程重要性不言而喻。既然企业的有效管理需要流程来牵引、承载和落实，那么如何设计高效的以客户为中心的运作流程？持续管理变革应该怎么做？很多企业都希望通过重新再造流程来解决企业问题，来提升市场竞争力，大家的认识都很统一，但最终大部分企业都雷声大雨点小？具体应该怎么落地 *** 作呢？值得思考、交流。

如何编写IT项目方案通过学习如何编写方案，让大家进一步体会管理线索在实际工作（项目）中的应用

帮助大家更容易地理解IT项目管理的理论体系：九大知识领域和五个过程组

帮助大家学习掌握IT项目方案编写方法

目录什么是方案如何编写需求分析如何编写方案设计原则如何编写解决方案如何编写实施方案如何编写维护服务方案如何编写培训方案如何编写典型案例典型设计方案分析方案就是解决问题的方案

方案有：用户解决方案、项目申报方案、可行性报告等等

写方案的目的就是让别人知道，你有能力高效、低耗、低风险地完成特定的任务目标

方案中要解决：为什么做做什么达到什么效果谁来做怎么做花费多大代价有何风险、怎么控制质量如何保证你是否有相应的能力什么是方案方案的背景，讲述当前与方案相关的社会、需求、技术等背景情况，国内外同类解决方案的情况等

一般出现在申报方案

需求分析，即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标

给读者阐明为什么做

方案的意义，高度概括，这个方案能解决什么问题，方案的实现能带来什么好处

一般出现在申报方案

方案设计原则，就是在设计解决方案时，必须要遵循的原则

所谓原则，就是不能突破并必须严格遵循的尺度

在每个具体的解决方案中，都要体现预先确定的原则

遵循的标准，包括国标、行标、地方标等，也是在设计方案是不能突破的尺度

方案的目标，总体概述解决问题的方案，高度概括

一般出现在申报方案

解决方案，给读者阐明怎么做，来解决问题

是解决方案的主体

方案有以下要点或组成部分组织架构实施方案（进度计划），给读者阐叙做的具体步骤，工作路线

服务方案（服务计划），给读者阐明你有服好务的具体措施

培训方案（培训计划），给读者阐明你有做好培训的具体措施

沟通计划质量控制计划风险识别和风险控制计划设备采购计划工作量估算和人力资源成本预算典型案例介绍，给读者证明，你已经具备了实现这个方案的能力

工作基础、工作成果积累，进一步论证你具备实现这个方案的能力

满足用户的需求、满足招标文件中提出的所有要求是编写方案的基本原则，要对用户和招标文件的每一项要求都有明确的响应，要清晰准确地领会用户的意愿，不能随意抵触或反对用户的意愿

要努力在方案中体现我们的特点（特别是主要竞争对手所不具备的特点），要在方案中发挥我们有利的资源，厂商产品选择是要考虑利润最大化和商务可控性

需求分析即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标

给读者阐明为什么做

用户需求分析总会是用户解决方案的第一部分，这部分主要是分析用户项目的需求、用户的关注点和兴趣点、用户当前的资源情况和存在的问题等等

用户需求分析是整个方案定基调的部分，是为我们为什么提供后面所描述的方案设定论点并为提供论据奠定基础

同时，到位的需求分析，也是为我们制定方案的设计目标提供依据

作为方案的开篇部分，如果分析到位，特别是用户的关注点和兴趣点分析到位，会立即引起用户的共鸣，迅速把用户吸引住，也更容易让用户理解我们后面的内容

一个到位的需求分析，是一个好方案的一半

反过来讲，如果你都不能全面地把握用户的需求，你拿出来的方案也不会有什么针对性，用户不会感兴趣

要做好需求分析，需要进行耐心细致的用户调研工作，而且根据用户项目的特点，制定明确的需求调研线索和方案

需求分析用户立项的宏观背景用户立项的目的和意义用户的组织架构用户当前it建设的情况采用的技术需求软件功能需求软件性能需求（质量需求）平台环境需求安全方面需求项目风险识别用户关注点和兴趣点详细分析等每一部分根据需要，可以做进一步分类描述

对于一个综合性IT应用解决方案，如金保工程方案，需求分析应包含以下几个方面的内容大家要注意，用户需求是多角度的在进行需求分析描述时，各部分分类要清晰多用条理性描述少做长篇论述各部分内容分量要均衡要点要清晰准确要体现全面、到位和重点突出

大家记住，这里每一部分的描述都将是后面相应内容的线索和论据

用户需求分析往往是方案编写者最容易忽视的部分，好多人都是随便凑点内容，甚至凑一些根本无关的内容

这样的后果是，因为自己不重视，也就不能真正地掌握用户的需求和期望，写出的方案针对性不强

方案设计原则是每个方案必须的部分，也是很多方案编写者最轻视的部分，好多人的办法是随便抄一个其他方案的原则部分，应付了事

这反映出他们根本不知道原则是什么、原则的作用是什么

方案的设计原则是设计者对设计思想的纲领性的描述，是对需求的高度抽象和概括，是进行方案设计的最基本的指导方针

就是在设计解决方案时，必须要遵循的原则

所谓原则，就是不能突破并必须严格遵循的尺度

在每个具体的解决方案中，都要体现预先确定的原则

在方案设计原则中，要表明在方案设计时重点要考虑哪些问题，要突出对用户关注点和兴趣点的对策，这些内容要与需求分析的相关内容紧密呼应

方案设计原则的编写可以分为两大类，一类是基础性原则，一类是响应用户特殊需求的原则

方案设计原则基础性原则在每个方案中基本都会有，如：先进性与成熟性的原则先进性与保护投资的原则安全性原则功能完备性原则灵活性原则可维护性原则可扩展性原则等等

基础性设计原则我们拿可维护性原则作为例子分析一下“原则”的含义可维护性的意思是，根据我们提供的方案开发出的系统，具有方便进行维护的特点

换句话讲，我们进行方案设计和开发时，要充分考虑今后维护的方便可行

即便这些基本性原则可能在很多方案中都有，但也要充分理解用户的期望

如用户项目资金充裕，那可能就要突出先进性的原则

反之，可能就需要充分考虑原有设备的复用，保护原有投资

用户特殊需求的原则要认真下一番功夫直接体现我们是不是重视用户的想法是不是真正理解他们的需求要想做好这方面的文章，就必须对用户的需求、用户的关注点和兴趣点非常清晰

一般情况下，在介绍方案时，原则部分会有比较强的冲击效果，特别是那些很到位的响应用户特殊需求的原则

说白了，就是告诉用户，你关心什么，那么我们就将在方案中注意、解决和实现什么

解决方案这部分是方案的主体部分，也是分量最重的部分

需求分析部分是讲为什么设计这样一个方案、这个方案要解决什么问题、有什么意义

方案设计原则部分讲的是我们在进行这个方案设计时应该遵循的原则，或者说是应该重点关注和考虑的问题

标准规范部分讲的是方案设计的应遵循的标准规范

这部分是介绍我们设计出来的结果

是不是满足需求、是不是能够解决用户的问题、是不是遵循了原则、是不是符合相应的标准规范，全要在这部分中体现出来

解决方案为了让大家容易理解，我在这里用一个大家比较熟悉、比较容易联想的方案设计例子进行介绍，这个例子就是一座大楼的设计方案

设计一座大楼是一件很复杂的工作，要考虑大楼的功能需求、外观、空间、每个楼层的房间布局、强电线路、弱电线路、供水线路、供暖线路、排污管线、各种材料等等，要进行力学分析、结构分析等，可以说设计一座大楼是一项庞大系统的方案设计工作

后面将给大家介绍一下编写这部分内容的注意事项

首先请大家记住，我们这里讲的设计方案，是我们与用户沟通交流的方案

目的是让用户知道我们有能力、有措施、有保障地去实现他们的需求，是让用户树立起与我们合作的信心，但并非是一个具体的开发方案

因此需要重点突出而不需面面俱到，不需要或者千万不要落到具体的细节上，要尽可能保证各部分内容的均衡

设计方案编写要点之一在方案描述部分的最前面，要有一个方案的总体描述，可以称为总体设计方案

或成为方案蓝图也就是项目的总体目标这部分是对你的设计方案的高度概括性介绍

设计方案编写要点之二为了能让用户了解你的方案的全貌对于比较复杂的设计项目来讲，不是几句话几段文字可以表述清楚的需要站在不同的角度、针对于不同的层面进行介绍譬如说大楼的外观，从正面看，你是看不到全貌的，即便你把外貌全介绍清楚了，如果不介绍其他的话，别人也很难明白这个大楼

因此要学会角度、层次的分解可以从类别上分，也可以从功能上分，分的目的是为了更全面、更清晰、更容易地给大家介绍你的方案

一般一个IT项目方案包括：技术架构网络架构安全架构功能架构性能指标

设计方案编写要点之三对你的方案进行分解描述时，要充分考虑前面需求分析的内容

需求分析中提到的需求和问题，在方案描述部分都要有相应的解决方案，前后呼应，前面讲为什么要做，这里讲怎么实现

与需求分析呼应，也是方案分解描述时进行分解的参考依据

方案是否与需求相呼应，意味着方案是否扣题

有很多这方面做得不到位的方案，对在这个项目上行，按在另外一个项目上也行，就成大笑话了

目的性强！设计方案编写要点之四对于一些用户关注的问题和需求，以及通过分析具有比较高复杂度的问题，也要分解出来进行单独讲解一是表明我们对用户的需求的充分响应二是表明对需求理解的深刻，尽管有些问题很复杂，但我们有可行的解决方案

借此增强用户的信心

设计方案编写要点之五要与前面设计原则部分相呼应在方案的描述中，要体现出我们是严格遵从前面制定的原则的

同样，也要对所遵循的标准规范有呼应

设计方案编写要点之六多采用图示的方法大家都知道，无论文笔怎么好，文字的东西总是比较抽象的读者必须通过联想才能理解你描述的含义

如大楼的外观情况，如果文字描述，很可能长篇累牍地写了一大堆，别人还是搞不明白

而用图的形式，可能只需三两张图，就把大楼的外观展现的清清楚楚了

图示的作用是直观

图是对方案的高度概括和抽象

做一张好图，要基于你对方案完全了解和掌握，也要基于你的知识和经验的积累

真正好的方案描述都是图文并茂，用文字辅助解释图中关键的部分

设计方案编写要点之七要学会使用表格进行描述与图示一样，表格也是一种非常好的方案描述的方法

表格的作用是简练、调理、清晰，更容易让读者理解你所表述的内容

对于一些包含大量数字，或者描述形式重复的内容，都可以采用表格的形式描述

设计方案编写要点之八对于一些重要的指标或用户关心的指标需要基于你的方案进行分析用合理的分析模型和数据证明你的方案能够达到用户所期望的指标例如设备配_选型设计，用分析的指标作为依据设计方案编写要点之九对于一些需要利用其他厂商产品进行集成的项目要讲明你所选择的原因和这些产品的作用要对你所选择的主要产品从功能和性能角度进行介绍

设计方案编写要点之十为了突出我们期望让用户产生深刻印象的内容

可以在方案描述的最后一部分做一个总结，可以用方案特点介绍的说法

在特点介绍中，要突出我们独有的特点（在一定程度上会让用户去找我们竞争对手相关的内容）

要突出用户关心的问题（与需求分析呼应）等，大家需要注意，特点一定要“特”

方案特点组织的好，也会对用户产生比较强的冲击力

设计方案编写要点之十一编写方案的时候，特别是编写这部分方案的时候切记千万不要凑材料，这个地方抄点那个地方摘点进行拼凑，这是编写方案的大忌如果需要摘抄一些资料，必须自己完全掌握这些资料的内容并且确认对解决特定的问题有帮助

设计方案编写要点之十二开发实施计划，也称总体进度计划，是对全部相关计划的有机整合，也叫整体计划

整体计划涵盖了开发计划、实施计划、采购计划、质量控制计划、风险控制计划、项目团队建设计划、验收计划、服务计划、培训计划等等

项目开发实施方案（计划或工作路线）我们常说，要完成一件事情，需要有计划、有组织、有措施、有保障地进行

我们的设计方案完成后，接着就要给用户介绍我们怎么实施完成，这就是实施方案

实施方案的编写需要按照有计划、有组织、有措施、有保障的线索，基于项目管理的思想进行阐述

在这里对大家有一个要求，就是你在写出来这个实施方案之前，你已经真正明白了这个项目到底怎么干才能干好

如果你都不知道怎么干的话，写出来的所谓的实施方案是不是可行就需要打个问号了

这个问题在很多人在写实施方案时常犯的错误

我们需要基于项目管理的思想来描述开发实施方案

首先需要明确项目的目标

其实方案确定好了，总目标是非常清晰的，那就是按照用户的需求开发出系统，按照用户的时间约定部署实施完成

但如果仅仅这样讲，那只落在了总目标的口号上了

为了拿出真正可行的方案，需要把目标进行分解，分解成一个个阶段性目标或历程碑性目标，这项分解要尽可能的准确和详细，目标越清晰具体，越容易找到实施方案

要反思，如果这一个个的阶段性目标都实现了，是不是就能很好地完成和实现总目标，如果是，说明你的分解基本就是合理的

当目标分解工作完成后，各个子目标之间可能存在时序关系，也可能存在其他关联关系，为了完成每一子目标都有相应的工作内容、也需要一定时间和人力资源的支持，有一些比较复杂的工作可能需要一些方法的指导（工作预案）

对应于每个子目标，把这些相关的东西搞清楚描述出来，然后按照时序关系排列起来，项目的实施计划就出来了

实施计划描述需要调理，一般可以采用表格的形式

目标分解一般是采用自上而下的方式进行具体做法是，先围绕总目标的实现分解成几个大的阶段然后对每个阶段进一步分解成更小的阶段最后落实到每一项工作任务的目标上

在实施计划中，还有一点非常重要，就是必须满足用户工期的时间要求

项目组织架构不管目标怎么定，方案怎么做的，有一点是确定的，就是必须要有人去按照计划去干，去实现一个个的目标

作为一个好的实施方案，需要对承担这项工作的队伍、人员进行组织和分工

描述这部分内容的线索可以这样

定义项目实施过程中的角色，根据实施计划的需要，对参与项目的人按角色进行分类，定义角色的责任

分析一下这个项目每一个子目标实现过程中，都需要涉及到哪些类型的人，这些人与我们的那些部门有关

设计项目组的管理架构，与实施计划相关，与工作分类和角色分工有关，要有责任明确的项目负责人角色

如果队伍比较大涉及的部门比较多的话，项目负责人就需要具有比较强的资源协调能力，明确项目总负责人和不同类型工作的负责人

根据计划的需要，选择明确项目成员

一个好的实施方案，除了给用户讲清楚怎么干以外，还要介绍你的这种干法是可行的而且是风险小的，这就是实施方案的保障措施

一般情况下，应该包含这样一些内容：沟通协调措施，要有明确的沟通协调机制保障，项目是需要我们与用户、厂商、监理等一起配合完成的，因此必须要有良好的沟通

质量要求和质量控制措施

风险分析以及规避风险的措施

预算（成本计划），包括设备采购计划和人力资源成本预算

一些复杂工作的工作预案，要让用户知道我们是有办法有能力完成这些工作的，增强用户的信心

验收计划这是对双方都负责任的约定，验收方案要科学合理，要具有可 *** 作性

对于一些特定的项目，需要对我们投入的人力和工作量进行统计

首先，你要对用户参加培训的人员进行分类不同类型的人员需要接受不同的培训大体可以从系统管理角度和系统使用角度进行分类

如系统管理员（进一步也可细分为应用系统管理人员、系统环境管理人员等）、系统使用人员（或者称用户业务人员，包括各个层面使用系统的人员）等

培训方案要点之一培训对象分类从管好和用好的角度，设计培训的课程在每一门培训课程中，要对一下项目进行定义培训课程名称培训目的和期望达到的目标（培训完了，受训人能够达到什么水平或能力）受训人技术基础要求培训形式（集中上课、上机实习）培训课时数培训教材（必需要有明确的培训教材，除了编写或购买的教材以外，可以多选用项目交付时提供的资料，如设计方案、用户手册等）培训内容概要（要介绍这门课程的主要内容）

培训方案要点之二培训课程设计根据项目总体的实施计划安排，设计课程表课程表中要明确时间、地点、培训对象、课程因为这里面要考虑总体进度，要考虑参训对象所受的时间、地点的制约课程表的编排一定要合理可行

培训方案要点之三培训课程表最后可以介绍一下承担培训工作教师的情况对几个主要培训教师的简历进行介绍另外，对于一些需要比较特殊条件的培训，介绍一下我们的保障措施

培训方案要点之四培训教师介绍用户对维护服务的期望是：平时通过有效的管理和监控，尽可能地减少故障概率系统发生故障时，出现的问题能够得到最高效率的解决这也是我们设计维护服务方案时的基本原则和目标

维护服务方案服务需求分析，对用户的服务需求，从主要服务项目和特点、响应时间、期望等进行比较详细的分析

维护服务方案要点之一服务需求分析组织管理体系，告诉用户我们公司有哪些部门、哪些人员以什么样的角色参与维护服务工作，每个角色的职责是什么

对服务组织中的核心成员进行介绍

维护服务方案要点之二组织管理体系服务项目定义，对于用户的服务需求进行应对，告诉用户我们围绕这个项目，能够提供什么样的服务工作，每项服务工作的含义是什么

如，我们有什么服务是对应于减少故障的，有什么服务是对应于解决问题的

维护服务方案要点之三服务项目定义这部分介绍的是为了完成我们提供的服务项目，我们有什么样的措施进行保证

如，对于我们所提供的减少故障的服务，我们采取什么样的措施来实现

服务项目和服务措施是紧密关联的，共同来表述我们能给用户什么服务和怎么给用户这些服务

响应时间定义，这是对双方都有益的一个约定，介绍在不同情况下我们的时间响应措施

维护服务方案要点之四服务措施手段定义介绍从服务请求到服务结束我们的工作和管理流程

进一步让用户明白我们拥有一个严密的服务体系，能够满足用户的服务需求

需要的话，可以对服务流程所需的管理工具进行介绍

维护服务方案要点之五服务流程介绍前面把我们服务体系的服务组织、服务措施、服务流程介绍完后

最后要针对于用户对本项目特定的服务需求进行响应

设计满足于用户服务需有的服务方案

这部分要对用户或招标文件中的服务要求进行点对点的应答，必须明确承诺是正满足

导语：关于软件项目的管理流程，相关人员来了解一下吧。下面是我收集整理的软件项目管理流程，供各位阅读和参考。

一、     风险评估

软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面：

1      产品规模风险

项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关：

(1)  估算产品规模的方法

(2)  产品规模估算的信任度

(3)  产品规模与以前产品规模平均值的偏差

(4)  产品的用户数

(5)  复用软件的多少

(6)  产品需求变更的多少

2      需求风险

很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的，这些的风险因素有:

(1)  对产品缺少清晰的认识

(2)  对产品需求缺少认同

(3)  在做需求分析过程中客户参与不够

(4)  没有优先需求

(5)  由于不确定的需要导致新的市场

(6)  不断变化需求

(7)  缺少有效的需求变化管理过程

(8)  对需求的变化缺少相关分析等

3      相关性风险

许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险， 能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题,与外部环境相关的因素有：

(1)  客户供应条目或信息

(2)  交互成员或交互团体依赖性

(3)  内部或外部转包商的关系

(4)  经验丰富人员的可得性

(5)  项目的复用性

4      技术风险

软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。 在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。关于技术主要有下面这些风险因素：

(1)  缺乏培训

(2)  对方法、工具和技术理解的不够

(3)  应用领域的经验不足

(4)  对新的技术和开发方法应用不熟悉

5      管理风险

尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足——不能检查到自己的错误。因而，使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：

(1)  计划和任务定义不够充分

(2)  对实际项目状态不了解

(3)  项目所有者和决策者分不清

(4)  不切实际的承诺

(5)  不能与员工之间的进行充分地沟通

6      安全风险

软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方 面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们 软件项目潜在的风险。

7      回避风险的方式

(1)  以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。再以书面方便形成《用户需求》这一重要的文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。

(2)  设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。

(3)  需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。

(4)  控制系统的复杂程度，过于简单的系统结构，对用户来使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。

(5)  从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。

(6)  设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。

二、     成本预算

1      成本预算方式

(1)  自上而下的预算方法

自上而下的预方法主要是依据上层、中层项目管理人员的管理经验进行判断，对构成项目整体成本的子项目成本进行估计，并把这些判断估计的结果传递给低一层的管理人员，在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计，然后继续向下一层传递他们的成本估计，直到传递到最低一层。

使用此预算方式，在上层的管理人员根据他们的经验进行的费用估计分解到下层时，可能会出现下层人员认为上层的估计不足以完成相应任务的情况。这时，下层人员不一定会表达出自己的真实观点，不一定会和上层管理人员进行理智地讨论，从而得出更为合理的预算分配方案。在实际中，他们往往只能沉默地等待上层管理者自行发现问题并予以纠正，这样往往会给项目带来诸多问题。

自上而下更适用于项目启动的前期，与真实费用相差在30% ~ 70%之间。

Scrum使用自上而下的成本预算方式，它不会立即精确地确定成本，而是以最大限度容纳客户对未来产品要求所产生的变更。

(2)  自下而上的预算方法

自下而上方法要求运用WBS（Work Breakdown Structure，工作分解结构）对项目的所有工作任务的时间和预算进行仔细考察。最初，预算是针对资源（团队成员的工作时间、硬件的配置）进行的，项目经理在此之上再加上适当的间接费用（如培训费用、管理费用、不可预见费等）以及项目要达到的利润目标就形成了项目的总预算。自下而上的预算方法要求全面考虑所有涉及到的工作任务，更适用于项目的初期与中期，它能准备地评估项目的成本，与真实费用相差在5% ~ 10%之间。

注解：WBS

WBS是面向提交成果对项目的分解，从提交成果的列表可以确定每个提交成果需要执行的活动。Scrum会对WBS进一步细化，把一个迭代分解为一个或多个的工作包，再把工作包分解为细小的开发任务（一般开发任务的开发周期在15个工作小时以内）。

2      确定项目支出

总体成本预算就是结合下列多个成本预算方式综合计算的开发成本：

(1)  零基数预算

在成本预算的初期应该使用零基数的计算原则，而不可以使用类似于：以上一年总体费用加上20% 这样粗略的方式计算项目成本。

(2)  软硬件成本、物品成本

物品成本是指类似于：服务器（RAM 硬盘 CPU NIC卡 RAID簇）成本、维护成本、机房租金、光纤通讯成本、软件成本等的成本。

计算成本时需要考虑组装硬盘需时的长短，技术人员需要具备的质素，产品供应商能否提供保证质量，管理时是否需要额外的管理人员这些多方因素。

(3)  软件许可证成本

(4)  外包成本

当使用类似：视频、短信、移动电信类服务、门户网站等子项目时可以考虑以外包形式完成，以降低开发成本。

(5)  人力资源成本

计算人力资源成本时应该使用以最高和最低的工作效率估算平均效率的方式，计算出人力资源的平均成本。

(6)  维修保养成本

三、     客户沟通的过程

从客户沟通的方向出发来看，软件项目可分为：需求识别、方案定制、项目实施、项目结束等4个不同的阶段，各个阶段都具有不同的沟通重点。

1  需求识别阶段

(1)  文本沟通

在需求识别的前期，应该通过问卷、原型展示、界面展示、逻辑处理展示、准化文档模板等方式进行全方位多角度的分析，随时将不明确之处反馈给客户,以期待客户解答。并以文本记录的方式建立需要分析书，并要求客户审核需求分析书，以达到需要分析与客户的真实期望高度一致的结果。

(2)  业务逻辑沟通

在进行业务沟通时，应该了解客户的行业语言，以促进业务分析的过程，越过应用需求和开发之间的鸿沟。沟通过程提倡以草图或者可视信息化的方式进行, 针对不同层面的企业用户提供最适合的 *** 作界面。以多角度的方式思考问题，要抓住需求重点,尤其是客户方领导所关注的创新类和实用类需求。

(3)  需求变更的规范化管理

需求变更在软件开发类项目中是可以理解的,但必须对需求变更做好规范化的管理，以避免出现需求无止境变更的风险。需求变更必须由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的，开发方应该做好详细的文本记录,让客户了解需求变更的实际情况和开发方为之所付出的成本代价。

2  方案定制阶段

该阶段项目的主要任务是与客户共同制定一个以前期明确的需求、双方的资源、项目开始的阶段、实施的时间约定、项目费用限制等为基础的具有可 *** 作性的项目计划,从本阶段开始争取客户全面参与项目的管理，并以双方的共同利益考虑项目实施的具体计划与风险规避。

3  项目实施阶段

在该阶段,软件项目团队应该与客户共同领导项目的实施。同时,项目团队应实时评估客户满意度,并通过持续改进的方式提高客户满意度,还应要求客户参加必要的培训,以及在必要时检查项目产品。在出现客户的需求变更前,应主动与客户沟通交流,使客户充分了解项目的每个环节,以及变更带来的影响,减少需求变更。如果出现客户需求变更,应与客户一起共同解决由变更引起的成本、进度、质量变化。

4  结束阶段

该阶段主要进行项目成果的移交，并把系统交付给维护人员，帮助客户实现商务目标，结清各种款项。完成这些工作后应该进行项目评估，审核此项目的成果并总结项目经验。

5  售前人员注意事项

在产品型项目作为开发成果时，相关销售人员应该注意：对产品的推销不应该过分承诺。如果过分承诺,会给后续的项目实施带来困难;一旦承诺没有兑现,也会降低客户满意度,影响今后合作。如果有附加承诺,一定要以文本形式记录，让实施项目经理知晓并传达给项目组成员。

注解：在软件项目中,需要明确以下四种客户角色

A   要明确最终使用部门和用户,要去了解他们现有的工作方式,要让他们知道项目的目标框架,知道项目要解决他们的哪些困难,但绝对不是全部困难,这样可以较好的控制项目范围。

B   要明确需求的提出者,他或者他们要能够代表最终客户群体。提出产品需求的这类客户要具有一定的技术、业务能力和权威,能够真正代表最终客户团队的意愿和想法,最好有IT基础,能够用IT语言描述问题和需求,以利于双方的沟通、协作,避免产生歧义。

C   要明确做需求确认的中层领导,他要把握方向。软件开发项目是解决实际生产或者管理问题,同时 也是领导系统建设的具体实现,做需求确认的客户领导,既要了解高层领导的系统建设要点和方向,又要谙熟具体业务和生产管理实际。如果是这样的客户领导来把 握和决策,对企业软件开发项目的顺利进展作用非凡。

D   要明确谁来对成品提意见,谁来验收。项目验收环节,是项目的收尾环节,如果验收的人对项目初期的需求目标不了解,会从态度和产品实际使用效果上对验收产生负面的影响,对提供产品的企业关闭项目非常不利。根据实践总结,由需求提出人和确认人来做项 目的验收工作,能够促进项目的顺利完成,避免延期。

四、     需求分析

1     需求分析的过程

需求过程包括需求开发和需求管理2个部分：

(1)  需求开发就是对开发前期的管理，与客房的沟通过程，可以分为4个阶段：需求获取、需求分析、编写需求和需求验证。

(2)  需求管理：就是软件项目开发过程中控制和维持需求约定的活动。包括：变更控制、版本控制、需求跟踪、需求状态跟踪。

2      需求的层次

需求的层次包括：业务需求、用户需求、功能需求、非功能需求等4个方面。

3     需求开发阶段的重点

(1)  提取业务对象

业务对象是指系统使用的真实对象，例如一个供应链管理 (Supply Chain Management ,简称SCM) 业务对象主要包括：生产批发商、零售商、送货商、顾客多个层次。

(2)  提取业务流程

在了解业务逻辑的过程中，应该列举出所开发软件模块的各自职能，并细化每个工作流程，深入分析业务逻辑。

(3)  性能需求

在分析的前期应该注意客户对所开发软件的技术性能指标，如存储容量限制、运行时间限制、安全保密性等。

(4)  环境需求

环境需求是指软件平台运行时所处环境的要求，如硬件方面：机型、外部设备、数据通信接口;软件方面：系统软件，包括 *** 作系统、网络软件、数据库管理系统方面;使用方面：使用部门在制度上， *** 作人员上的技术水平上应具备怎样的条件。

(5)  可靠性需求

对所开发软件在投入运行后发生故障的概率，应该按实际的运行环境提出要求。对于重要的软件，或是运行失效会造成严重后果的软件，应提出较高的可靠性要求。

(6)  安全保密要求

在需求分析时应当在这方面恰当地做出规定，对所开发的软件给予特殊的设计，使其在运行中，其安全保密方面的性能得到必要的保证。

(7)  用户界面需求

为用户界面细致地规定到达的要求。

(8)  资源使用需求

开发的软件在运行时和开发时所需要的各种资源。

(9)  软件成本消耗与开发进度需求

在软件项目立项后，根据合同规定，对软件开发的'进度和各步骤的费用提出要求，作为开发管理的依据。

(10) 开发目标需求

预先估计以后系统可能达到的目标，这样可以比较容易对系统进行必要的补充和修改。

4      需求分析的任务

需求分析的主要任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型，其流程如下：

(1)  确定对系统的综合需求（功能、性能、运行、扩充需求）

(2)  制作产品需求文档 (PRD)

(3)  分析系统的数据需求（概念模型、数据字典、规范化）

(4)  导出目标系统的详细的逻辑模型（数据流图、数据字典、主要功能描述）

(5)  开发原形系统

(6)  从PRD提取编制软件需求规格说明书（SRS）

注解：SRS格式

1引言  2系统概述（项目背景、系统目标、核心业务流程） 3术语说明  4系统结构（架构图、功能图）

5主体功能与业务逻辑（重点） 6接口需求（内部、外部接口、） 7网络总体设计（拓扑网络、主机、组网）

8运行环境（Linux、Windows、IIS、 WebLogic、Tomcat、OLAP、OLTP、JDK 80 、NET Framework 40等）

五、     面向对象程序设计（略）

1      设计原则

(1)  SRP单一职责链

每个类都应该只负责做一件事。

(2)  OCP开封闭合原则

软件的实体（类、模块、函数等）应该是可以扩展的，但是不可修改的。

(3)  LSP替换原则

子类必须能替换他们的基类型。

(4)  DIP依赖倒置原则

高层模块不应该依赖于低层模块，二者都应该依赖于接口与抽象类。抽象不应该依赖于细节，细节应依赖于对象。

(5)  ISP接口隔离原则

不应该强迫客户依赖于并未使用的接口，而应该把胖接口分离。

2      实现UML建模

(1)  业务对象的提取

(2)  根据SRS、CRC等实现用况建模

(3)  实现业务顺序图

(4)  建立类图，根据用况图建立对象之间的关联

(5)  绘制活动图、实现协作图、状态图

六、     开发管理

1      建立项目计划

(1)  设计总体架构

针对系统的实施需要，采取适当的且成熟的框架结构。

(2)  控制可扩展度

扩展度过大，将提高系统的复杂程度，延长开发时间；扩展度过低，会直接影响系统的二次开发与维护。控制系统的可扩展性，能提高开发效率，降低系统维护的难度。

(3)  建立基础设施

合理分配部署软、硬件等基础设施所需要的时间与成本（例如：服务器的订购安装、光纤接入、软件平台订购）。

(4)  划分开发任务

利用WBS（Work Breakdown Structure，工作分解结构）对可交付结果进行分类与划分。每个项目都能划分为多个不同阶段，每个阶段又可以分为多个工作包（Work Package），工作包是WBS里最小的可交付结果，最后从工作包中分解出多个开发任务列表。

(5)  部署开发进度

一个项目应该按进度划分为多个开发阶段，每个阶段的开发周期一般在30~60个工作日以内。在此阶段内应该与客户举行协商会议，制定产品路线图，在开发过程中邀请客户积极参与并提出反馈意见。然后把该时段内的开发任务按照开发难度，依赖性，重要性等多方条件划分为多个迭代周期。

在Scrum 敏捷软件开发原则中，应该把每个迭代任务进一步细分为多个开发任务列表，再开发任务分配给组员各自负责，而开发时间应该控制在15个工作小时以内。如果开发时间超出15个工作小时，应该考虑把开发任务再度细化。开发任务建议应该由组员自主选择，而不要使用强制分配的方式。

(5)  测试项目成果

每个工作包都应该同步部署测试工作，提高项目的质量。对出错BUG的工作包应该由测试人员以文本方式记录，向开发人员展示错误所在，让开发人员及时进行修改。

2      管理开发团队

(1)  组建团队

按照工作任务与项目时间的前提条件建立团队，按团队职责分配人员，一般团队人数应该控制在8~12人之间。当团队人数超过15人时，应该考虑把团队分解成2个独立团队，负责不同的开发任务。

(2)  分配开发任务

在每个迭代周期内（一般是15~30个工作日），应该把每个工作包进一步细分为多个开发任务，再开发任务分配给组员各自负责，开发时间应该控制在15个工作小时以内。如果开发任务的开发时间超出15个工作小时，应该考虑把任务再度细化。而开发任务应该以自由选择的方式分配给每个组员。

(3)  监督开发进度

在迭代的前期举行一次会议，让组员了解开发的进展及流程，并以自主选择的方式分配开发任务。期间可使用Microsoft Project等工具记录开发流程的进展，在每个工作包完成开发后应该进行性功能的测试，并以文本方式记录测试结果。

每天举行一次15分钟的站立会议，让组员交待昨天已完成的开发任务，当天将要做的任务，与开发过程中所遇到的问题。并在每周末举行一次例行会议，交待总体进程。

在迭代末期举行一次冲刺会议，总结项目的进展，交行已完成的任务，回顾该迭代周期内所遇到的问题，为下一个迭代做好准备。

(4)  系统测试

对每个已完成的工作包进行适时的测试，保证系统质量与性能。对测试结果进行文本的记录，并把测试结果与绩效工资收入挂钩，并以真实数据计算组员的绩效收入。

(5)  解决开发中所遇到的问题

对开发人员进行前期培训，可适当按工作能力分配任务，指导组员的开发。当遇到问题时应该在当天的站立会议时即时提出，并在15个工作小时内解决所遇到的问题以防止问题进一步扩大。

3      监管产品质量

(1)  质量需要的是计划、设计而并非审查的。在产品建立的初级，必须与“质量保证”（QA）的部门进行协商，以正式文档的方式，决定恰当的质量策略和标准。

(2)  在开发过程中使用TDD（测试驱动开发）的模式，提高开发质量。测试人员应该以文本方式记录bug，并与开发人员共同工作的，把突出的缺陷演示给开发人员，以提高修改的效率。

(3)  在每个迭代的结束时进行一次产品效果的演示，从客户、使用者、高层领导中收集反馈信息。在团队内部举行评审会议，分析测试结果，了解产品性能，为下次迭代所需要做的改进做好计划。

4      修改项目计划

(1)  在产品需要识别阶段，应该以文档形式记录产品功能与开发流程，在开发计划需要修改时，应该与客户共同探讨，让客户了解计划修改对项目进度所造成的影响。

(2)  项目计划的修改应该由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的。

(3)  计划的变更应该做好详细的文本记录，让客户了解需求变更的实际情况和开发方为之所付出的成本代价。

七、     产品交付

1      项目的后期审核

在项目开发最终完成后，对开发人员来说可算是放下工作的重担，但对项目经理来说这往往是项目的关键时刻。前期的风险评估、成本预算、需求分析、软件设计都是为了引导项目走向这一时刻，此时所有的目光都将投向项目管理人员。你可能发现大量而琐碎的工作将要在几个小时内完成，此刻项目经理更需要保持清醒与镇定，把最后的工作视为微型项目来对待。细致地对项目进行后期的审核，分析项目成果、项目团队的效率、可交付产品的价值，以此审核结果可作为项目管理经验总结的一部分。

2      质量评审

在项目交付前，应该把项目交给相关的“质量保证”（QA）部门进行质量评审，并邀请典型用户感受产品的质量。

3      项目的最终交付

正常情况下在项目的前期就会订立项目交付的协议，项目交付方式分为非正式验收与正式验收两种。一般在项目完成后都会先进行非正式验收，让客户体会项目的质量并提出反馈意见，最后在客户肯定产品质量后再以书面协议的形式进行正式的产品验收。

4      项目的最终报告

在项目的最后，应该制定项目的最终报告，此报告可以视为是对该项目一个记录，但报告不必包含项目的所有方面。一般最终报告应该包含以下方面：

(1)  最初引进项目时的初期项目视图

(2)  对该项目的价值评估及支持性信息

(3)  项目的范围

(4)  项目的开发流程及WBS

(5)  项目的会议记录

(6)  项目变更的报告及变更的理由

(7)  与项目相关的沟通过程文件

(8)  项目的审核报告与客户验收报告

(9)  项目成员的表现报告

(10) 项目的最终成果

问题一：怎样写项目的立项依据 你可以先看看相关的书籍和文献 然后通过对比 就能了解自己的优势 立项依据其实和写文章的前言差不多但是写的时候一定要注意了 不能把目前该领域中存在的问题 都提出来在写的时候主要是 说明该项目有多么美好的前景 在国计民生中有多么重要的作用然后提出你们小组的最近发现的改进 但是还有一些东东是暂时难以解决的 最后说你们的项目对该领域有非常重要的提高jiangcj0520(站内联系TA)在写的时候主要是 说明该项目有多么美好的前景 在国计民生中有多么重要的作用然后提出你们小组的最近发现的改进 但是还有一些东东是暂时难以解决的 最后说你们的项目对该领域有非常重要的提高在写的时候主要是 说明该项目有多么美好的前景 在国计民生中有多么重要的作用然后提出你们小组的最近发现的改进 但是还有一些东东是暂时难以解决的 最后说你们的项目对该领域有非常重要的提高(2)国内情况应包括申请者自己的研究工作(3)必须阐明申请人要从事本项研究的理由(4)坚持“有所为，有所不为”的基本国策，填补空白不是立项依据立项目的要明确，申请理由要充分，立项依据既不要太科普，又要把关键问题交待清楚，能引起评审人的兴趣，愿意继续读完你的申请。能够让人不愿放弃地阅读你的申请书，那样的申请才有竞争力。

问题二：立项包含哪些内容,其先后顺序是 立项申请，至少要包括以下几点

1你想做什么？――研究目的

2你为什么要做？――研究意义和立论依据

3你准备如何去做？――研究方案

4以前已经有人做过什么或你做过什么？――研究基础

5你期待得到什么样的收益――研究带来的经济效益或社会效益

问题三：项目可行性研究的依据和范围是主要指的什么 (一)可行性研究的依据

一个拟建项目的可行性研究，必须在国家有关的规划、政策、法规的指导下完成，同时，还必须要有相应的各种技术资料。进行可行性研究工作的主要依据主要包括：①国家经济和社会发展的长期规划，部门与地区规划，经济建设的指导方针、任务、产业政策、投资政策和技术经济政策以及国家和地方法规等；②经过批准的项目建议书和在项目建议书批准后签订的意向性协议等；③由国家批准的资源报告，国土开发整治规划、区域规划和工业基地规划。对于交通运输项目建设要有有关的江河流域规划与路网规划等；④国家进出口贸易政策和关税政策；⑤当地的拟建厂址的自然、经济、社会等基础资料；⑥有关国家、地区和行业的工程技术、经济方面的法令、法规、标准定额资料等；⑦由国家颁布的建设项目可行性研究及经济评价的有关规定；⑧包含各种市场信息的市场调研报告。

(二)可行性研究的质量要求

可行性研究工作对于整个项目建设过程乃至整个国民经济都有非常重要的意义，为了保证可行性研究工作的科学性、客观性和公正性，有效地防止错误和遗漏，在可行性研究中，(1)首先必须站在客观公正的立场进行调查研究，做好基础资料的收集工作。对于收集的基础资料，要按照客观实际情况进行论证评价，如实地反映客观经济规律，从客观数据出发，通过科学分析，得出项目是否可行的结论。(2)可行性研究报告的内容深度必须达到国家规定的标准，基本内容要完整，应尽可能多地占有数据资料，避免粗制滥造，搞 。在做法上要掌握好以下四个要点：①先论证，后决策；②处理好项目建议书、可行性研究、评估这三个阶段的关系，哪一个阶段发现不可行都应当停止研究；③要将调查研究贯彻始终。一定要掌握切实可靠的资料，以保证资料选取的全面性、重要性、客观性和连续性；④多方案比较，择优选取。对于涉外项目，或者在加人WTO等外在因素的压力下必须与国外接轨的项目，可行性研究的内容及深度还应尽可能与国际接轨。(3)为保证可行性研究的工作质量，应保证咨询设计单位足够的工作周期，防止因各种原因的不负责任草率行事。

(三)可行性研究的主要内容

各类投资项目可行性研究的内容及侧重点因行业特点而差异很大，但一般应包括以下内容：

1．投资必要性。主要根据市场调查及预测的结果，以及有关的产业政策等因素，论证项目投资建设的必要性。在投资必要性的论证上，一是要做好投资环境的分析，对构成投资环境的各种要素进行全面的分析论证，二是要做好市场研究，包括市场供求预测、竞争力分析、价格分析、市场细分、定位及营销策略论证。

2．技术可行性。主要从项目实施的技术角度，合理设计技术方案，并进行比选和评价。各行业不同项目技术可行性的研究内容及深度差别很大。对于工业项目，可行性研究的技术论证应达到能够比较明确地提出设备清单的深度；对于各种非工业项目，技术方案的论证也应达到目前工程方案初步设计的深度，以便与国际惯例接轨。

3．财务可行性。主要从项目及投资者的角度，设计合理财务方案，从企业理财的角度进行资本预算，评价项目的财务盈利能力，进行投资决策，并从融资主体(企业)的角度评价股东投资收益、现金流量计划及债务清偿能力。

4．组织可行性。制定合理的项目实施进度计划、设计合理的组织机构、选择经验丰富的管理人员、建立良好的协作关系、制定合适的培训计划等，保证项目顺利执行。

5．经济可行性。主要从资源配置的角度衡量项目的价值，评价项目在实现区域经济发展目标、有效配置经济资源、增加供应、创造就业、改善环境、提高人民生活等方面的效益。

6．社会可行性。主要分析项>>

问题四：什么是立项批文？ It's a 批文

问题五：研发报告中的立项依据主要是泻什么 技术指标包含几个方面

首先是项目本身的设计规模，生产能力，预期的产出效果（例如生产出的产品符合XXX规范，达到国内或国际XXX样的水平）

第二是产品的相关执行标准，规范，达到的生产标准，技术特点，生产技术方案，关键工艺流程、设备选择等方面。

问题六：科研项目立项程序是什么 科研立项是指做科研工作的一个程序。科研是指科学研究，立项指通过申请、审批等流程，建立一个项目课题。

一般科研立项需要提交项目申请书及可行性报告到相对应的归口部门（单位），进行申请、审核、审批再确定能否立项。

1 提出项目课题：

课题来源主要有：

a 公司内各单位申请立项研究的课题；

b 上级安排的科研项目；

c 外单位委托公司承担或合作的科研项目；

d 公司领导和技术例会、质量例会提出的攻关课题；

e 企业中长期发展规划中的科研课题为年度计划立项来源之一。

2

填报立项申请书：根据选题来源和科研主要范围，各单位提出课题并填报立项申请书；

3 课题评审：

a 评审由技术管理部组织，技术副总经理主持，有关单位领导和专家参加，对各单位提出的课题进一步进行评审，做出评审结论，对确定立项的课题经技术副总经理审批后，做为计划（草案）编制依据；

b 评审主要内容：研究的迫切性与重要性；技术先进性、适应性和可靠性；技术后果的危害性；成功的概率；经济效益和社会效益。

4 确定课题负责人：经技术管理部审查同意后，各申报单位确定课题负责人；

5 编写课题设计、计划任务书，按期送交技术管理部；

课题设计埂计划任务书的基本内容包括：课题来源，课题研究的目的、意义，国内外水平概况预期目标和技术经济效果，技术关键及试验研究内容，计划进度和采取主要措施，需购置的设备、仪器，经费预算及来源，协作单位及任务分工。

6 完成立项。

注：上级安排的科研项目、承担的外单位科研项目及公司领导提出的攻关课题，由技术管理部确定课题负责单位。

问题七：建设项目立项的法律法规依据是什么发改委管的 云浪轩:你好！ 我国加入世贸组织后，商品房建设项目不需要到发改委办理建设项目立项了！ 但是，以下建设仍然需要办理范围 ①使用 性资金投资建设的项目②国家机关的基本建设项目③城镇基础设施建设项目④经济适用住房、学生公寓、 办事依据 1、国家计委计投资（1996）693号《关于重申严格执行基本建设2、程序和审批规定的通知》第一条 3、国发[2004]20号《国务院关于投资体制改革的决定》 4、国家发改委令（2004年19号）《企业投资项目核准暂行办法》5、国家发改委令（2004年22号）《外商投资项目核准暂行管理办法

问题八：研究基金申请书报告正文中"立项依据与研究内容"内容包括哪些 什么情况呀？

问题九：启动新项目时，大家新项目立项的依据有哪些呢？ 一个店的效益有很多因素影响，开店之前先考察好当地的消费水平，以及消费习惯，选择地段比较好的地段，这些只是前提条件，其中还要看你的经营策略等等。进口食品应该是可以的，目前国内的食品问题出现了很多，进口食品得到越来越多百姓的信赖，不过呢做生意都是有风险的，存在着多种因素，实际状况无法预测

问题十：哪些项目需要发改委审批？ 100分 首先说明几点：现行的项目审批立项实行审批制、核准制、备案制三种方法。

三者的要求：1、审批制项目（凡使用 性资金的建设项目都使用审批制。 直接投资或资本金注入的审批建议书和可研；企业投资使用 补助、转贷、贴息的只审批资金申请报告），审批流程：项目单位提交建议书至发改审批，根据批复办理选址、用地、环评预审后将预审手续，将预审文件与可研报告一起报送发改审批，最后依据发改批复办理规划、国土的正式手续。至此，项目的立项工作基本完成，可以做后续工作了：编制和审批初步设计、概算及工程勘察、项目招投标、设计和审查施工图、办理施工许可证。

2、核准制企业不使用 性资金投资建设的重大和限制类固定资产投资项目（即下面所指的《目录》内容）仅需提交申请报告。核准流程：项目单位先申请办理规划、国土、环评预审手续，将预审文件附在项目申请书（一式五份）中报送发改核准。然后依据核准批复办理规划、国土等正式手续。

3、备案制（除以上两种情况外的一律备案制）。备案流程：项目单位先向发改备案，然后根据备案批复申请办理规划、国土、环评等审批手续。

再来回答你的问题：

问题1： 就是项目凡是使用了 性资金的（ 性资金包括：财政预算投资资金（含国债资金）；国际金融组织和外国 贷款等 外债资金；纳入预算管理的专项建设资金；法律、法规规定其他 性资金。 投资按照资金来源、项目性质和宏观调控需要，分别采用直接投资、资本金注入、投资补助、转贷、贴息等投资方式）只要使用了上述所列的 性资金的建设项目，都要采取审批制。

问题2：几乎所有的项目都要发改审批立项，我想你的体育馆俯会堂也要。具体是实行审批制还是核准制或是备案制就要看具体情况了。1要看你们是不是自己出资金，如果是自己自筹资金，那么只有核准制或是备案制。 2如果该项目属于《 核准的投资项目目录》（2004年本）那么就实行核准制。3《目录》以外的一律实行备案制。

几乎所有的项目都要发改审批或核准或备案，规划部门选址规划批复，国土部门的用地意见批复、环保部门的环评意见。有些还须建设部门、安全部门的意见等等。如果还有不懂可以去看下《国务院关于投资体制改革的决定》

以上就是关于LTC概述与核心精要全部的内容，包括:LTC概述与核心精要、如何编写IT项目方案、软件项目的管理流程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！