IT需求如何主动支撑，快速支撑，高效支撑

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

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

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

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

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

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

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

一般出现在申报方案

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

给读者阐明为什么做

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

一般出现在申报方案

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

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

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

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

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

一般出现在申报方案

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

是解决方案的主体

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

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

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

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

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

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

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

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

给读者阐明为什么做

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

借此增强用户的信心

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

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

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

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

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

图示的作用是直观

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先需要明确项目的目标

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

质量要求和质量控制措施

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

项目需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。 在原则上，需求阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，监理方必须加强项目管理和项目分析工作，在具体的 *** 作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用承建方的软件。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、开发范围上有发言权。 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题： 1最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。 2需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的专家和知识。此时，用户就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 需求自身经常变动 根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。 分析人员或客户理解有误 软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳而无功。记得一则笑话，有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”所以分析人员知识的专一性也会造成需求分析的误解和失败。这时，咨询监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。 需求分析方法论 根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。 第一阶段：“访谈式”（Visitation） 这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式”（Inducement） 这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以 *** 作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。 实现手段：拜访（诱导）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式”（Afirm） 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及 *** 作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档） 整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。

重庆电信企业信息化事业部 傅诣

      目前垂直的部门管理模式对“以客户为中心”、“零不爽”要求弊端日益明显。特别是在当前市场需求瞬息万变，需求要求快速支持的背景下，需求无法高质量的实现，首先表现在需求实施的效率与速度上，无法快速支持需求。其次表现在需求实施质量上，需求上线问题较多，带来很多次生问题，需求质量业务单位与分公司都不满意，影响IT口碑。

      以客户需求为中心，启用矩阵式需求管理，建设高、精、尖需求界面团队，在企信部设立后方资源池，深入需求一线，让需求一线指挥炮火，实现需求小前端，大后端，前端综合化、后端专业化，后端全力支持前端。

现状：目前企信部采用传统的垂直化组织架构，各域组织界面分明，容易形成部门壁垒，需求由需求前置团队接收，分派到各个域，较为复杂的联合需求由各域分别评估，各域再进行联合确认，再与需求业务单位进行沟通，期间反馈多次，效率较低，特别是在部分需求细节存在问题时，往往需要多次开会共同确认，在实现方案上各部门也往往各执一词，耽误需求实施时间，也影响需求实施质量。

措施：

1采用需求矩阵式管理：针对重要需求，采用项目制管理，由各部门部门负责人、技术专家、实施人员、厂商组建临时需求实施团队，此团队不隶属于任何一个部门，采用承包方式，将需求承包给虚拟团队，每个需求团队负责人拥有可以“呼唤炮火”的权利与“签署责任书”的义务，做到权责对立，平衡（后面会详细说明）。这样就可以整合事业部各部门的专家优势，打通部门壁垒，快速实现需求。该方式也就在事业部层面就形成了一个垂直于传统部门的需求实施矩阵，与各域的生产维护形成互补。

2“黄金四边形”：黄金四边型目标是建立贴近需求一线的敏捷化组织，在事业部层面对外形成统一的界面，能灵敏捕捉到公司领导及一线的关键需求，找准需求“痛点、关键点”，迅速调动资源，建立专项团队，灵活快速实现需求，打破部门壁垒，突破原始需求流程的烦冗。团队必须包含“项目经理”、“需求分析团队”、“方案设计实施团队”、“后期维护支撑团队”四个关键团队，形成黄金四边型。

各团队职责如下

（1）项目经理：项目经理是团队的****，是需求的第一责任人，拥有“呼唤炮火”调度资源的权利，同时，也是需求目标达成的第一责任人，签署需求实施承诺责任书，在需求完成后接受事业部对实施情况的考评。厂商负责人也纳入项目经理。

（2）需求分析团队：需求分析人员是与业务单位接触的排头兵，是第一接触人，首要任务是找到需求的“痛点”或“题眼”，其次是需求实施的桥梁，对外，负责引导业务单位按照IT“先上菜”进行推进，引导业务单位采用IT推荐的需求实施方案与分布实施的时间计划；对内，负责将需求与方案设计实施团队沟通，形成需求支撑方案，并与前端沟通。再次，在需求实施全生命周期中对需求变更进行管理。分析团队工作必须量化，每个需求必须要有需求分析说明书，每次需求会议必须要有需求沟通（或评审）会议纪要，每次需求变更需要有需求变更记录。

（3）方案设计实施团队：由各域的专家与执行人员组成，负责需求实施方案的落地，并与需求人员一起对实施方案向业务单位沟通，达成一致，最后由此团队的实施人员完成需求上线（执行人员可能与后面的“后期维护支撑团队”人员重复）。方案实施团队必须输出每个需求的方案，方案由事业部形成统一的模板输出，方案质量纳入管控。此环节是当前需求实施中的短板，很多需求在完成需求分析后，直接丢给厂商实施，实施方案中功能部分内容没有评审，界面部分在实施中也没有DEMO，没有也业务单位沟通，导致质量不被业务单位认可。该点如何提升，建议如下：

首先把需求分为5个层次，要求在方案模板中必须都进行说明，底层为功能需求，仅仅针对功能本身；第二层为服务需求，本层包含业务及流程，提升服务能力的需求；第三层为体验需求，考虑到客户感知的需求，含易用性， *** 作性，感知方面；第四层为关系需求；顶层为成功需求，即满足公司组织成功，有效推动业务发展。我们现在往往注重第一层的功能需求，对其他层次需求不够关注。即使在第一层功能需求中，还存在“简单功能做不好，复杂功能做得好”的情况，原因就是以IT惯性思维技术为导向，没有以客户需求为中心，没有抓住需求“痛点”，将IT功能做得复杂。后续，我们要多放精力到第2至第5个需求层次中，更加注重易用性， *** 作性，快速支撑。

（4）后期维护支撑团队：目前我们往往“重建设，轻维护”，需求上线后，就算完了，监控、作业计划没有跟上，上线后也不能主动发现问题，往往前端发现问题后，已经晚了，造成了较严重的后果。对此，后续维护支撑团队，首要任务是建立需求上线初期的监控保障手段，用数据说话，证明新需求上线后的运营情况，提前于业务单位发现问题，及时处理。其次，对新需求上线后的监控，作业计划进行实施，对新需求上线后出现的问题进行集中解决，为一线提供支撑。

前面说了，我们建立了矩阵式需求管理制度，组建了高、精、尖的需求团队，那么如何进行运作？

1小前方，大后方：需求分析团队直面业务单位，但我们后面有一个强大的支撑保障团队（各域专家、实施人员、战略合作伙伴等），各域整合资源形成整体支撑大平台，提供解决方案，提供技术支持，这样才能让小前方需求分析人员有底气，有引导需求，主导实施的资本。

2一线呼唤炮火：当需求人员或需求预沟通发现重点需求时，一线要迅速做出反应，立即呼唤炮火支撑，后端将根据需求难易程度，配备必要的资源，在实施过程中动态补充人员，必要时采用王牌团队或王牌专家，快速应对需求，落实方案，稳步推进。

实现小前方、大后方，一线呼唤炮火的措施：

（1）呼叫的炮火要集中在一点原则：集中在“痛点”或“需求题眼”上，才能实现“闪电战”。这也是中心领导说的先上关键“菜”。虽然我们呼唤到了火力，但是如果针对整个需求的方方面面，无法显示出火力的局部优势（火力被分散了），这就要求我们的需求项目团队，与业务单位沟通，集中火力先上关键“菜”，这个原则的度一定要控制好。

（2）组织人员保障：按不同域对不同人员进行打标，定义他们的责任，为他们指明发展方向，形成人力资源池。按照需求项目管理，需求实施需要管理者、需求分析人员、技术保障人员、上线后维护支撑人员。需要对各部门人员打标，属于哪一种角色，形成专家库，为随时组建队伍做准备。

（3）需求考评机制：事业部拟定出台《需求实施承诺书》，包含权利与义务。权利是可以在一定范围内调配资源，承诺为需求完成的目标，在完成目标时对应的奖励与惩罚。项目经理代表团队签署承诺书，并在需求上线后1个月内接受事业部考评，并进行奖励或处罚，并给团队及成员等级评定。

（4）团队及专家等级晋升机制：各种人才打标后，均成为此类型的专家，需要对组建的团队与专家根据需求实施效果进行考评，采用军队的晋升方式。通过考评筛选出王牌团队与王牌专家，在遇到重要需求，疑难问题时，优先使用王牌团队与王牌专家，使其成为“特种部队”。这样做的目的，是将事业部目前的“屯兵模式”提升为“精兵模式”，让不确定、困难复杂的关键需求，由精兵完成，提升感知。通过此方式，还可以建立企信部的战略预备队，为IT队伍的后续发展提供帮助。

（5）仲裁（指导）委员会：仲裁委员会设立的目的就是打破部门间的壁垒，具备横向传递沟通及协同作战能力。前面说到，项目经理作为需求项目实施的第一负责人，具有一定的动态调配资源的权限，但如果在需求实施工程中，出现与职能部门的壁垒或冲突，或遇到其他管理问题、人力资源问题，由仲裁委员会仲裁决定。建议仲裁委员会由事业部领导及部门领导组成，针对非技术性问题进行协调仲裁。

（6）技术委员会：事业部技术委员会负责需求实施中遇到的方案问题解决及支撑，特别是对在哪个系统实施较优方面进行确认。在需求遇到技术难题时，技术委员会将对技术细节进行指导。

（7）需求管理平台（缺失）：事业部目前使用门户及ITSM系统结合对需求流程进行管理，但缺失一个统一的需求管理平台，各部门目前均使用EXCEL对需求进行管理，哪些需求已超期，哪些需求为事业部当前重点需求，哪些需求不合理，没有一个需求管理系统进行管理，所以，建立一套需求管理分析系统，迫在眉睫。

（8）会议管理系统（缺失）：以业务部为例，上周业务部有10个会议，其中需求会议6项。业务部目前通过人员进行管理，罗敏每周五发会议周报，列举会议清单，从安徽学习后，业务部要求每个参会的人员出具会议纪要，由罗敏汇总。简单会议出简单的会议纪要，重要会议，出详细的会议纪要。我们希望有一个会议管理系统，将每次会议的纪要进行上传，纳入系统管理，这样，可以有效杜绝需求、专项工作进度上下不一致的情况。

（9）需求变更文档化：加强需求文档管理，这里重点强调一下需求变更管理，由于一些重要需求是公司领导需求，需要业务单位按照领导要求细化，并不断与领导沟通，这样必然会多次变更需求，IT为保障需求尽快上线，必然存在需求在实施中多次变更的情况。这就要求，每次需求变更必须文档化，把整个需求变更的情况记录下来，也要求需求团队与方案设计团队、后续维护支撑团队做好沟通，将每次确认的内容文档固话。这里建立事业部出具需求变更模板。

（10）需求模式固化：先选取少量需求试点此方式，在积累经验后，迅速固化实施流程，并将流程清晰、重复运营的流程及工作模板化，抓住主要的模板建设，再把相关的模板流程串起来，不断优化。形成知识库，事业部通过呼叫炮火的方式，集中支持，集中处理，解决共性问题，这些共性问题的解决要形成知识库，在后续遇到类似问题时，快速支撑。

（11）需求透明化：月初，需求版本部署会议，与业务单位沟通本月需要实现的需求；月中，由事业部整体出面（或各需求项目经理）与需求业务单位就需求进度进行沟通；次月上线后，与需求单位进行需求后评估，对需求后续维护及问题解决进行落实，对需求后评估结果进行沟通。

（12）加强需求过程管控：在建立此机制后，需要进一步加强需求过程管控，授权不等于放任，必要时实时监控。

以上就是关于如何编写IT项目方案全部的内容，包括:如何编写IT项目方案、如何进行需求分析、IT需求如何主动支撑，快速支撑，高效支撑等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！