公司想进行流程梳理，但找了一家咨询公司说建议先上一个IT系统，应该先梳理清楚再考虑IT吧？

2012-9-24 如何编写ＩＴ项目方案 通过学习如何编写方案，让大家进一步体会管理线索在实际工作（项目）中的应用。 帮助大家更容易地理解ＩＴ项目管理的理论体系：九大知识领域和五个过程组。 帮助大家学习掌握ＩＴ项目方案编写方法。 目录 什么是方案 如何编写需求分析 如何编写方案设计原则 如何编写解决方案 如何编写实施方案 如何编写维护服务方案 如何编写培训方案 如何编写典型案例 典型设计方案分析 方案就是解决问题的方案。 方案有：用户解决方案、项目申报方案、可行性报告等等。 写方案的目的就是让别人知道，你有能力高效、低耗、低风险地完成特定的任务目标。 方案中要解决： 为什么做 做什么 达到什么效果 谁来做 怎么做 花费多大代价 有何风险、怎么控制 质量如何保证 你是否有相应的能力 什么是方案 方案的背景，讲述当前与方案相关的社会、需求、技术等背景情况，国内外同类解决方案的情况等。一般出现在申报方案。 需求分析，即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标。给读者阐明为什么做。 方案的意义，高度概括，这个方案能解决什么问题，方案的实现能带来什么好处。一般出现在申报方案。 方案设计原则，就是在设计解决方案时，必须要遵循的原则。所谓原则，就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中，都要体现预先确定的原则。 遵循的标准，包括国标、行标、地方标等，也是在设计方案是不能突破的尺度。 方案的目标，总体概述解决问题的方案，高度概括。一般出现在申报方案。 解决方案，给读者阐明怎么做，来解决问题。是解决方案的主体。 方案有以下要点或组成部分 组织架构 实施方案（进度计划），给读者阐叙做的具体步骤，工作路线。 服务方案（服务计划），给读者阐明你有服好务的具体措施。 培训方案（培训计划），给读者阐明你有做好培训的具体措施。 沟通计划 质量控制计划 风险识别和风险控制计划 设备采购计划 工作量估算和人力资源成本预算 典型案例介绍，给读者证明，你已经具备了实现这个方案的能力。 工作基础、工作成果积累，进一步论证你具备实现这个方案的能力。 满足用户的需求、满足招标文件中提出的所有要求是编写方案的基本原则，要对用户和招标文件的每一项要求都有明确的响应，要清晰准确地领会用户的意愿，不能随意抵触或反对用户的意愿。 要努力在方案中体现我们的特点（特别是主要竞争对手所不具备的特点），要在方案中发挥我们有利的资源，厂商产品选择是要考虑利润最大化和商务可控性。 需求分析即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标。给读者阐明为什么做。 用户需求分析总会是用户解决方案的第一部分，这部分主要是分析用户项目的需求、用户的关注点和兴趣点、用户当前的资源情况和存在的问题等等。 用户需求分析是整个方案定基调的部分，是为我们为什么提供后面所描述的方案设定论点并为提供论据奠定基础。 同时，到位的需求分析，也是为我们制定方案的设计目标提供依据。 作为方案的开篇部分，如果分析到位，特别是用户的关注点和兴趣点分析到位，会立即引起用户的共鸣，迅速把用户吸引住，也更容易让用户理解我们后面的内容。 一个到位的需求分析，是一个好方案的一半。反过来讲，如果你都不能全面地把握用户的需求，你拿出来的方案也不会有什么针对性，用户不会感兴趣。 要做好需求分析，需要进行耐心细致的用户调研工作，而且根据用户项目的特点，制定明确的需求调研线索和方案。 需求分析 用户立项的宏观背景 用户立项的目的和意义 用户的组织架构 用户当前it建设的情况 采用的技术需求 软件功能需求 软件性能需求（质量需求） 平台环境需求 安全方面需求 项目风险识别 用户关注点和兴趣点详细分析等 每一部分根据需要，可以做进一步分类描述。 对于一个综合性IT应用解决方案，如金保工程方 案，需求分析应包含以下几个方面的内容 大家要注意，用户需求是多角度的 在进行需求分析描述时，各部分分类要清晰 多用条理性描述少做长篇论述 各部分内容分量要均衡 要点要清晰准确 要体现全面、到位和重点突出。 大家记住，这里每一部分的描述都将是后面相应内容的线索和论据。 用户需求分析往往是方案编写者最容易忽视的部分，好多人都是随便凑点内容，甚至凑一些根本无关的内容。 这样的后果是，因为自己不重视，也就不能真正地掌握用户的需求和期望，写出的方案针对性不强。 方案设计原则是每个方案必须的部分，也是很多方案编写者最轻视的部分，好多人的办法是随便抄一个其他方案的原则部分，应付了事。 这反映出他们根本不知道原则是什么、原则的作用是什么。 方案的设计原则是设计者对设计思想的纲领性的描述，是对需求的高度抽象和概括，是进行方案设计的最基本的指导方针。 就是在设计解决方案时，必须要遵循的原则。所谓原则，就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中，都要体现预先确定的原则。 在方案设计原则中，要表明在方案设计时重点要考虑哪些问题，要突出对用户关注点和兴趣点的对策，这些内容要与需求分析的相关内容紧密呼应。 方案设计原则的编写可以分为两大类，一类是基础性原则，一类是响应用户特殊需求的原则。 方案设计原则 基础性原则在每个方案中基本都会有，如： 先进性与成熟性的原则 先进性与保护投资的原则 安全性原则 功能完备性原则 灵活性原则 可维护性原则 可扩展性原则等等。 基础性设计原则 我们拿可维护性原则作为例子分析一下“原则”的含义 可维护性的意思是，根据我们提供的方案开发出的系统，具有方便进行维护的特点。 换句话讲，我们进行方案设计和开发时，要充分考虑今后维护的方便可行。 即便这些基本性原则可能在很多方案中都有，但也要充分理解用户的期望。 如用户项目资金充裕，那可能就要突出先进性的原则 反之，可能就需要充分考虑原有设备的复用，保护原有投资。 用户特殊需求的原则要认真下一番功夫 直接体现我们是不是重视用户的想法 是不是真正理解他们的需求 要想做好这方面的文章，就必须对用户的需求、用户的关注点和兴趣点非常清晰。 一般情况下，在介绍方案时，原则部分会有比较强的冲击效果，特别是那些很到位的响应用户特殊需求的原则。 说白了，就是告诉用户，你关心什么，那么我们就将在方案中注意、解决和实现什么。 解决方案这部分是方案的主体部分，也是分量最重的部分。需求分析部分是讲为什么设计这样一个方案、这个方案要解决什么问题、有什么意义。 方案设计原则部分讲的是我们在进行这个方案设计时应该遵循的原则，或者说是应该重点关注和考虑的问题。 标准规范部分讲的是方案设计的应遵循的标准规范。 这部分是介绍我们设计出来的结果。 是不是满足需求、是不是能够解决用户的问题、是不是遵循了原则、是不是符合相应的标准规范，全要在这部分中体现出来。 解决方案 为了让大家容易理解，我在这里用一个大家比较熟悉、比较容易联想的方案设计例子进行介绍，这个例子就是一座大楼的设计方案。 设计一座大楼是一件很复杂的工作，要考虑大楼的功能需求、外观、空间、每个楼层的房间布局、强电线路、弱电线路、供水线路、供暖线路、排污管线、各种材料等等，要进行力学分析、结构分析等，可以说设计一座大楼是一项庞大系统的方案设计工作。 后面将给大家介绍一下编写这部分内容的注意事项。 首先请大家记住，我们这里讲的设计方案，是我们与用户沟通交流的方案。 目的是让用户知道我们有能力、有措施、有保障地去实现他们的需求，是让用户树立起与我们合作的信心，但并非是一个具体的开发方案。 因此需要重点突出而不需面面俱到，不需要或者千万不要落到具体的细节上，要尽可能保证各部分内容的均衡。 设计方案编写要点之一 在方案描述部分的最前面，要有一个方案的总体描述，可以称为总体设计方案。 或成为方案蓝图 也就是项目的总体目标 这部分是对你的设计方案的高度概括性介绍。 设计方案编写要点之二 为了能让用户了解你的方案的全貌 对于比较复杂的设计项目来讲，不是几句话几段文字可以表述清楚的 需要站在不同的角度、针对于不同的层面进行介绍 譬如说大楼的外观，从正面看，你是看不到全貌的，即便你把外貌全介绍清楚了，如果不介绍其他的话，别人也很难明白这个大楼。 因此要学会角度、层次的分解 可以从类别上分，也可以从功能上分，分的目的是为了更全面、更清晰、更容易地给大家介绍你的方案。 一般一个ＩＴ项目方案包括： 技术架构 网络架构 安全架构 功能架构 性能指标 。。。 设计方案编写要点之三 对你的方案进行分解描述时，要充分考虑前面需求分析的内容。 需求分析中提到的需求和问题，在方案描述部分都要有相应的解决方案，前后呼应，前面讲为什么要做，这里讲怎么实现。 与需求分析呼应，也是方案分解描述时进行分解的参考依据。 方案是否与需求相呼应，意味着方案是否扣题。 有很多这方面做得不到位的方案，对在这个项目上行，按在另外一个项目上也行，就成大笑话了。目的性强！ 设计方案编写要点之四 对于一些用户关注的问题和需求，以及通过分析具有比较高复杂度的问题，也要分解出来进行单独讲解 一是表明我们对用户的需求的充分响应 二是表明对需求理解的深刻，尽管有些问题很复杂，但我们有可行的解决方案。 借此增强用户的信心。 设计方案编写要点之五 要与前面设计原则部分相呼应 在方案的描述中，要体现出我们是严格遵从前面制定的原则的。 同样，也要对所遵循的标准规范有呼应。 设计方案编写要点之六 多采用图示的方法 大家都知道，无论文笔怎么好，文字的东西总是比较抽象的 读者必须通过联想才能理解你描述的含义。 如大楼的外观情况，如果文字描述，很可能长篇累牍地写了一大堆，别人还是搞不明白。 而用图的形式，可能只需三两张图，就把大楼的外观展现的清清楚楚了。 图示的作用是直观。 图是对方案的高度概括和抽象。 做一张好图，要基于你对方案完全了解和掌握，也要基于你的知识和经验的积累。 真正好的方案描述都是图文并茂，用文字辅助解释图中关键的部分。 设计方案编写要点之七 要学会使用表格进行描述 与图示一样，表格也是一种非常好的方案描述的方法。 表格的作用是简练、调理、清晰，更容易让读者理解你所表述的内容。 对于一些包含大量数字，或者描述形式重复的内容，都可以采用表格的形式描述。 设计方案编写要点之八 对于一些重要的指标或用户关心的指标 需要基于你的方案进行分析 用合理的分析模型和数据 证明你的方案能够达到用户所期望的指标 例如设备配臵选型设计，用分析的指标作为依据 设计方案编写要点之九 对于一些需要利用其他厂商产品进行集成的项目 要讲明你所选择的原因和这些产品的作用 要对你所选择的主要产品从功能和性能角度进行介绍。 设计方案编写要点之十 为了突出我们期望让用户产生深刻印象的内容。 可以在方案描述的最后一部分做一个总结，可以用方案特点介绍的说法。 在特点介绍中，要突出我们独有的特点（在一定程度上会让用户去找我们竞争对手相关的内容）。 要突出用户关心的问题（与需求分析呼应）等， 大家需要注意，特点一定要“特”。 方案特点组织的好，也会对用户产生比较强的冲击力。 设计方案编写要点之十一 编写方案的时候，特别是编写这部分方案的时候 切记千万不要凑材料，这个地方抄点那个地方摘点进行拼凑，这是编写方案的大忌 如果需要摘抄一些资料，必须自己完全掌握这些资料的内容 并且确认对解决特定的问题有帮助。 设计方案编写要点之十二 开发实施计划，也称总体进度计划，是对全部相关计划的有机整合，也叫整体计划。 整体计划涵盖了开发计划、实施计划、采购计划、质量控制计划、风险控制计划、项目团队建设计划、验收计划、服务计划、培训计划等等。 项目开发实施方案（计划或工作路线） 我们常说，要完成一件事情，需要有计划、有组织、有措施、有保障地进行。 我们的设计方案完成后，接着就要给用户介绍我们怎么实施完成，这就是实施方案。 实施方案的编写需要按照有计划、有组织、有措施、有保障的线索，基于项目管理的思想进行阐述。 在这里对大家有一个要求，就是你在写出来这个实施方案之前，你已经真正明白了这个项目到底怎么干才能干好。 如果你都不知道怎么干的话，写出来的所谓的实施方案是不是可行就需要打个问号了。 这个问题在很多人在写实施方案时常犯的错误。 我们需要基于项目管理的思想来描述开发实施方案。 首先需要明确项目的目标。其实方案确定好了，总目标是非常清晰的，那就是按照用户的需求开发出系统，按照用户的时间约定部署实施完成。 但如果仅仅这样讲，那只落在了总目标的口号上了。 为了拿出真正可行的方案，需要把目标进行分解，分解成一个个阶段性目标或历程碑性目标，这项分解要尽可能的准确和详细，目标越清晰具体，越容易找到实施方案。 要反思，如果这一个个的阶段性目标都实现了，是不是就能很好地完成和实现总目标，如果是，说明你的分解基本就是合理的。 当目标分解工作完成后，各个子目标之间可能存在时序关系，也可能存在其他关联关系，为了完成每一子目标都有相应的工作内容、也需要一定时间和人力资源的支持，有一些比较复杂的工作可能需要一些方法的指导（工作预案）。 对应于每个子目标，把这些相关的东西搞清楚描述出来，然后按照时序关系排列起来，项目的实施计划就出来了。 实施计划描述需要调理，一般可以采用表格的形式。 目标分解一般是采用自上而下的方式进行 具体做法是，先围绕总目标的实现分解成几个大的阶段 然后对每个阶段进一步分解成更小的阶段 最后落实到每一项工作任务的目标上。 在实施计划中，还有一点非常重要，就是必须满足用户工期的时间要求。 项目组织架构 不管目标怎么定，方案怎么做的，有一点是确定的，就是必须要有人去按照计划 去干，去实现一个个的目标。 作为一个好的实施方案，需要对承担这项工作的队伍、人员进行组织和分工。 描述这部分内容的线索可以这样。 定义项目实施过程中的角色，根据实施计划的需要，对参与项目的人按角色进行分类，定义角色的责任。 分析一下这个项目每一个子目标实现过程中，都需要涉及到哪些类型的人，这些人与我们的那些部门有关。 设计项目组的管理架构，与实施计划相关，与工作分类和角色分工有关，要有责任明确的项目负责人角色。 如果队伍比较大涉及的部门比较多的话，项目负责人就需要具有比较强的资源协调能力，明确项目总负责人和不同类型工作的负责人。 根据计划的需要，选择明确项目成员。 一个好的实施方案，除了给用户讲清楚怎么干以外，还要介绍你的这种干法是可行的而且是风险小的，这就是实施方案的保障措施。 一般情况下，应该包含这样一些内容： 沟通协调措施，要有明确的沟通协调机制保障，项目是需要我们与用户、厂商、监理等一起配合完成的，因此必须要有良好的沟通。 质量要求和质量控制措施。 风险分析以及规避风险的措施。 预算（成本计划），包括设备采购计划和人力资源成本预算。 一些复杂工作的工作预案，要让用户知道我们是有办法有能力完成这些工作的，增强用户的信心。 验收计划 这是对双方都负责任的约定，验收方案要科学合理，要具有可 *** 作性。 对于一些特定的项目，需要对我们投入的人力和工作量进行统计。 首先，你要对用户参加培训的人员进行分类 不同类型的人员需要接受不同的培训 大体可以从系统管理角度和系统使用角度进行分类。 如系统管理员（进一步也可细分为应用系统管理人员、系统环境管理人员等）、系统使用人员（或者称用户业务人员，包括各个层面使用系统的人员）等。 培训方案要点之一培训对象分类 从管好和用好的角度，设计培训的课程 在每一门培训课程中，要对一下项目进行定义 培训课程名称 培训目的和期望达到的目标（培训完了，受训人能够达到什么水平或能力） 受训人技术基础要求 培训形式（集中上课、上机实习） 培训课时数 培训教材（必需要有明确的培训教材，除了编写或购买的教材以外，可以多选用项目交付时提供的资料，如设计方案、用户手册等） 培训内容概要（要介绍这门课程的主要内容）。 培训方案要点之二培训课程设计 根据项目总体的实施计划安排，设计课程表 课程表中要明确时间、地点、培训对象、课程 因为这里面要考虑总体进度，要考虑参训对象所受的时间、地点的制约 课程表的编排一定要合理可行。 培训方案要点之三培训课程表 最后可以介绍一下承担培训工作教师的情况 对几个主要培训教师的简历进行介绍 另外，对于一些需要比较特殊条件的培训，介绍一下我们的保障措施。 培训方案要点之四培训教师介绍 用户对维护服务的期望是： 平时通过有效的管理和监控，尽可能地减少故障概率 系统发生故障时，出现的问题能够得到最高效率的解决 这也是我们设计维护服务方案时的基本原则和目标。 维护服务方案 服务需求分析，对用户的服务需求，从主要服务项目和特点、响应时间、期望等进行比较详细的分析。 维护服务方案要点之一服务需求分析 组织管理体系，告诉用户我们公司有哪些部门、哪些人员以什么样的角色参与维护服务工作，每个角色的职责是什么。对服务组织中的核心成员进行介绍。 维护服务方案要点之二组织管理体系 服务项目定义，对于用户的服务需求进行应对，告诉用户我们围绕这个项目，能够提供什么样的服务工作，每项服务工作的含义是什么。如，我们有什么服务是对应于减少故障的，有什么服务是对应于解决问题的。 维护服务方案要点之三服务项目定义 这部分介绍的是为了完成我们提供的服务项目，我们有什么样的措施进行保证。 如，对于我们所提供的减少故障的服务，我们采取什么样的措施来实现。 服务项目和服务措施是紧密关联的，共同来表述我们能给用户什么服务和怎么给用户这些服务。 响应时间定义，这是对双方都有益的一个约定，介绍在不同情况下我们的时间响应措施。 维护服务方案要点之四服务措施手段定义 介绍从服务请求到服务结束我们的工作和管理流程。 进一步让用户明白我们拥有一个严密的服务体系，能够满足用户的服务需求。 需要的话，可以对服务流程所需的管理工具进行介绍。 维护服务方案要点之五服务流程介绍 前面把我们服务体系的服务组织、服务措施、服务流程介绍完后。 最后要针对于用户对本项目特定的服务需求进行响应。 设计满足于用户服务需有的服务方案。 这部分要对用户或招标文件中的服务要求进行点对点的应答，必须明确承诺是正满足。

搜索引擎的整个工作过程视为三个部分：一是蜘蛛在互联网上爬行和抓取网页信息，并存入原始网页数据库；二是对原始网页数据库中的信息进行提取和组织，并建立索引库；三是根据用户输入的关键词，快速找到相关文档，并对找到的结果进行排序，并将查询结果返回给用户。以下对其工作原理做进一步分析：

一、网页抓取

Spider每遇到一个新文档，都要搜索其页面的链接网页。搜索引擎蜘蛛访问web页面的过程类似普通用户使用浏览器访问其页面，即B/S模式。引擎蜘蛛先向页面提出访问请求，服务器接受其访问请求并返回HTML代码后，把获取的HTML代码存入原始页面数据库。搜索引擎使用多个蜘蛛分布爬行以提高爬行速度。搜索引擎的服务器遍布世界各地，每一台服务器都会派出多只蜘蛛同时去抓取网页。如何做到一个页面只访问一次，从而提高搜索引擎的工作效率。在抓取网页时，搜索引擎会建立两张不同的表，一张表记录已经访问过的网站，一张表记录没有访问过的网站。当蜘蛛抓取某个外部链接页面URL的时候，需把该网站的URL下载回来分析，当蜘蛛全部分析完这个URL后，将这个URL存入相应的表中，这时当另外的蜘蛛从其他的网站或页面又发现了这个URL时，它会对比看看已访问列表有没有，如果有，蜘蛛会自动丢弃该URL，不再访问。

二、预处理，建立索引

为了便于用户在数万亿级别以上的原始网页数据库中快速便捷地找到搜索结果，搜索引擎必须将spider抓取的原始web页面做预处理。网页预处理最主要过程是为网页建立全文索引，之后开始分析网页，最后建立倒排文件（也称反向索引）。Web页面分析有以下步骤：判断网页类型，衡量其重要程度，丰富程度，对超链接进行分析，分词，把重复网页去掉。经过搜索引擎分析处理后，web网页已经不再是原始的网页页面，而是浓缩成能反映页面主题内容的、以词为单位的文档。数据索引中结构最复杂的是建立索引库，索引又分为文档索引和关键词索引。每个网页唯一的docID号是有文档索引分配的，每个wordID出现的次数、位置、大小格式都可以根据docID号在网页中检索出来。最终形成wordID的数据列表。倒排索引形成过程是这样的：搜索引擎用分词系统将文档自动切分成单词序列-对每个单词赋予唯一的单词编号-记录包含这个单词的文档。倒排索引是最简单的，实用的倒排索引还需记载更多的信息。在单词对应的倒排列表除了记录文档编号之外，单词频率信息也被记录进去，便于以后计算查询和文档的相似度。

三、查询服务

在搜索引擎界面输入关键词，点击“搜索”按钮之后，搜索引擎程序开始对搜索词进行以下处理：分词处理、根据情况对整合搜索是否需要启动进行判断、找出错别字和拼写中出现的错误、把停止词去掉。接着搜索引擎程序便把包含搜索词的相关网页从索引数据库中找出，而且对网页进行排序，最后按照一定格式返回到“搜索”页面。查询服务最核心的部分是搜索结果排序，其决定了搜索引擎的量好坏及用户满意度。实际搜索结果排序的因子很多，但最主要的因素之一是网页内容的相关度。影响相关性的主要因素包括如下五个方面。

（1）关键词常用程度。经过分词后的多个关键词，对整个搜索字符串的意义贡献并不相同。越常用的词对搜索词的意义贡献越小，越不常用的词对搜索词的意义贡献越大。常用词发展到一定极限就是停止词，对页面不产生任何影响。所以搜索引擎用的词加权系数高，常用词加权系数低，排名算法更多关注的是不常用的词。

（2）词频及密度。通常情况下，搜索词的密度和其在页面中出现的次数成正相关，次数越多，说明密度越大，页面与搜索词关系越密切。

（3）关键词位置及形式。关键词出现在比较重要的位置，如标题标签、黑体、H1等，说明页面与关键词越相关。在索引库的建立中提到的，页面关键词出现的格式和位置都被记录在索引库中。

（4）关键词距离。关键词被切分之后，如果匹配的出现，说明其与搜索词相关程度越大，当“搜索引擎”在页面上连续完整的出现或者“搜索”和“引擎”出现的时候距离比较近，都被认为其与搜索词相关。

（5）链接分析及页面权重。页面之间的链接和权重关系也影响关键词的相关性，其中最重要的是锚文字。页面有越多以搜索词为锚文字的导入链接，说明页面的相关性越强。链接分析还包括了链接源页面本身的主题、锚文字周围的文字等。

首先。。一定要先对公司做基本的梳理。。不要自己公司的情况还没有搞清楚就盲目的去上IT系统。。这里就要说一下。不要完全相信咨询公司。。这类公司说白了就是为了多赚钱。。所以会根本不考虑贵公司的基本情况就推销IT系统。但是作为自己人还是要对公司有一个最基本的了解。。然后再根据自己公司的情况来上IT系统的。。但是上IT系统也是必要的。。毕竟现在的公司管理更多的要依靠自动化系统来完成的。。IT系统的建立不仅可以方便管理企业。。也可以让员工的办公更简化。希望对你有帮助

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。北京IT培训建议在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

错误跟踪管理系统为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。

目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件(商业软件)、Mozilla公司的Buzilla软件(免费软件)，以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。

作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。

正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。

软件错误的状态新信息(New)：测试中新报告的软件缺陷;打开(Open)：被确认并分配给相关开发人员处理;修正(Fixed)：开发人员已完成修正，等待测试人员验证;拒绝(Declined)：拒绝修改缺陷;延期(Deferred)：不在当前版本修复的错误，下一版修复关闭(Closed)：错误已被修复;Bug管理的一般流程测试人员提交新的Bug入库，错误状态为New高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open如果不是错误，则拒绝，设置为Declined状态。

到底什么是IT规划？IT规划需要做些什么？企业内部不同的人有不同的想法; 而在企业外部，软硬件厂商、咨询公司等人士也会有不同的说法。1、IT规划的定义

通俗派的说法:

“IT规划（IT planning）”是“信息化规划”的简称，是指在理解企业发展战略和评估企业IT现状的基础上，结合所属行业信息化方面的实践和对最新信息技术发展的认识，提出企业信息化建设的远景、目标和战略，以及具体信息系统的架构设计、选型和实施策略，全面系统地指导企业信息化建设，满足企业可持续发展的需要。

技术派的说法:

IT规划很简单，就是要建立先进的、企业级的IT架构，选择一系列先进的软件来实现规划的IT架构。

软件公司的说法:

以前都没有IT规划，我们的软件都很先进，很多企业都在使用我们的软件，已经经受了实践的考验。即便没有IT规划，这种软件也完全能为企业创造价值。

2．企业内部的定义

领导的说法:

IT规划到底是什么、怎么定义并不重要，重要的是我希望这个规划能够支持我们业务的发展，能够得到落地执行。

业务等应用部门的说法:

IT规划是IT部门的事情，与我们没有多大关系。IT规划应该是IT部门考虑怎样为我们建立一套信息系统，来提高我们的工作效率，最好还能够帮我们降低运营成本。

IT部门的说法:

IT规划不仅仅是IT部门的事情，整天都被那些业务、财务、行政等应用部门吆喝来、使唤去，忙得不可开交。领导对于信息化建设的投资没有底，我们得规划出

一个信息化建设的计划，然后到领导那儿申请预算，才能把那些服务器、路由器以及软件系统买回来。

从企业信息化建设的整体上看，IT规划只是管理信息化的十步闭环中的一个环节（如图1所示）。IT规划要想获得领导和业务部门的认可，必须最终能够被落地执行，从业务出发是必然的选择。

3、“IT规划”的“广义”与“狭义” 广义的“IT规划”包含了“IS规划”与狭义的“IT规划”两个部分。细分来说，“IS规划”（Information System Strategic Planning, 简称ISSP）筹划的是：在理解企业的发展远景、业务规划的基础上，形成信息系统的远景、信息系统的组成架构、信息系统各部分的逻辑关系，以支撑企业业务规划（Business Strategic Planning，简称BSP）目标的达成。有时，我们看到一些业内外的探讨，关于ISSP和BSP的集成问题，其实说的就是这个层次间的衔接。而“IT规划”(Information Technology Strategic Planning），是承接IS战略之后，对信息系统各部分的支撑硬件、支撑软件、支撑技术等进行计划与安排，简而言之，是围绕“T”来展开。下文中除特别说明以外，“IT规划”都是取广义范围。

其实信息化具体项目的实施是“最后为之”的事情，需要在以上的种种战略“有个说法”以后才进行。而现实中，很多企业的信息化建设恰恰是反其道而行之，从如何选择硬件、软件开始。

4、“IT规划”的“客观”与“主观”

进行IT规划是要解决两个问题，一个是客观问题，一个是主观问题。

由于缺乏IT规划，很容易导致系统繁多、信息孤岛、维护费用高、收益低、风险高等等。正是有了IT规划，我们才能避免在信息化建设的时候“脚踩西瓜皮，溜到哪儿算哪”，从客观上防止以上严重后果的发生。

所谓“广义”的IT规划是指从企业的战略出发，充分分析企业核心价值链的运作模式，进而找出IT的支撑点和机会点，从而明晰企业的IT战略，并构筑企业的IT应用蓝图、IT治理模式、信息资源体系及系统实施规划等，以实现对企业战略目标达成的有效支持。而“狭义”的IT规划则侧重对系统硬件、系统软件、开发技术等进行计划与安排，是围绕技术展开的。这里，我们所讨论的IT规划主要是针对“广义”的IT规划。一般情况下，IT规划的运作思路是按照四个步骤展开的，IT战略明晰、IT能力分析、IT解决方案和IT行动方案。在IT战略明晰阶段，需要分析企业的战略、愿景和目标，并对核心价值链的相关业务环节进行深入的分析，从业务模式和流程入手找到IT的支撑点和机会点，进而构建支持业务发展策略的IT战略，制定信息化建设的目标。在IT能力分析阶段，首先会结合企业的IT支撑点，从核心业务环节入手，分析并形成企业不同层面的IT需求和IT目标。然后，构建合理的IT评估模型对企业的信息化现状进行全面的评估，并进行差距和约束条件分析，为后面的IT蓝图及系统规划提供依据。在IT解决方案阶段，需要结合上面两个阶段的成果，设计企业的IT应用蓝图，进行应用系统的集成点分析并构建企业的IT基础架构，同时对这些内容进行深入的描述和分析。在IT行动方案阶段，需要对设计的IT蓝图进行全面的规划，制定企业的信息化建设步骤，进行风险及效益分析，同时给出企业的IT治理方案，并在此基础上形成企业具体的信息化行动方案，指导企业的下一步行动。这里，我们不想用长篇大论来介绍IT规划的具体内容和成果，而是想就目前存在的一些IT规划项目无法帮助企业解决实际问题的现象展开一些讨论。这些IT规划项目和企业的实际信息化建设往往存在“两张皮”的现象，在IT规划阶段，项目组会帮助企业描绘一幅美好的信息化建设的蓝图，并且会运用各种“科学”的分析工具以及众多“新鲜”的名词告诉企业应该如何如何。而在项目组撤出之后，企业在实际开展信息化建设的时候往往会发现IT规划的内容很难落到实处，甚至脱离企业的实际情况，没办法只得自己从头再来，既浪费了企业的时间和金钱，又动摇了企业信息化建设的信心。第一，迷信最佳实践，一切向标杆看齐，IT规划的时候忽略了企业的实际情况，包括企业的人文环境、地域文化、历史传统等的差异，尤其是处于变革期的国内企业需要发展所面临的各种各样的管理和运营的“个性化”问题。这种情况下，咨询顾问总是试图用技术驱动管理和业务的变革，并且缺乏和企业各个层面有效的沟通，因而很难帮助企业建立务实高效的信息化框架，甚至会给企业带来一些误导，以致在后续的信息化建设过程中出现各种各样困惑企业的实际问题。最近业界炒的比较多的某商业银行核心业务系统升级的知名项目，可能就存在这样的问题，在前期规划和选型的时候过于强调系统的先进性和标杆案例，忽略了企业自身的业务和管理现状，导致系统建设过程不可控，最后项目被停掉了。第二，咨询公司缺乏对国内企业管理和业务问题的深刻理解，没有能力摸清企业的运营脉搏，IT规划报告里面虽然也包括企业战略明晰、业务和流程梳理等，但由于咨询顾问的阅历和认识深度不够，往往造成这些分析结果无法跟后面的IT战略、IT蓝图及行动方案有效的结合起来，结果报告内容很多，看起来“繁花似锦”，但实际每部分内容都是割裂的，没有形成完整的逻辑关系，最终给企业提供的方案还是侧重技术可行性，是“狭义”的IT规划。这里，需要解释的是，目前阶段，国内企业希望解决的问题一定是综合的，即使是IT建设也一定是解决企业的战略、管理及业务等方面的问题，甚至还需要借助IT提高企业的执行力、弥补制度的不足并提升文化的建设等等，有些方面可能会违背IT的初衷，但这是目前国内企业的现实，也是在IT规划过程中必须面对的问题。因此，如何切实的支撑面向企业战略的业务发展策略、有效匹配业务模式和IT系统，找出可以落地的IT支撑点，并形成各个层面的IT需求是IT规划需要真正关注的。第三，规划过程中重视应用系统和网络、硬件平台的建设，而忽略了跟企业管理和业务密切相关的信息内容本身，往往是建设了很多信息系统，但却得不到支撑企业运营的信息资源。企业高层往往会抱怨：“为什么我想知道的很多东西，在这样先进的信息系统中，就是看不到呢？为什么在市场形势突变的时候，我们的信息系统无法敏感地捕捉变化？”。分析可知，这样的IT规划更多是满足企业的技术需求，而不是为企业的业务拓展和管理运营服务的。如果按照这样的思路去构建企业的IT整体框架，那在信息系统建设完之后，绝大多数的员工仍将不知道如何利用信息，以及如何让这些信息产生价值。企业的信息系统，也就没有任何管理和维护的意义和价值。因此，进行全面的企业信息资源规划也是IT规划的重要内容。第四，IT治理方案流于形式，起不到“三分技术、七分管理”的作用，IT治理或者叫IT管理是IT规划方案中必须要包括的，可能跟前面几个问题一样，这也是涉及企业管理方面的问题。由于IT对国内企业来说还是一个新鲜事物，企业很难积累起很好的IT管理的经验，况且国内企业管理的个性化问题比较突出。因此，如果不能很好的理解企业的文化、IT发展背景、管理运营模式等问题，制定的IT组织体系、IT管理制度、IT管理流程及IT绩效考核等IT管理体系最终只能落在纸面上，无法贯彻执行下去。同时，长期以来企业的IT部门往往充当的是企业的成本中心兼服务机构，责任无限大，权力一点点，出现问题IT部门更多的是跟业务部门妥协，这就更造成IT管理的难度。因此，如何结合企业的实际情况，制定“少而精”而不是“大而全”，并且可 *** 作的IT治理方案是IT规划的关键。第五，没有认识到IT规划的重要性，投入的资源不够。这个问题是非技术和管理的问题，但往往也是最重要的问题。很多企业做IT规划的初衷都是好的，也认识到了不按照“总体规划、分步实施、重点应用”的步骤进行信息化建设是不行的，但是在实际项目运作的时候则由于各种各样的原因造成项目金额小、时间紧、投入少、内容全。当然这种现象也有可能是由一些不负责任的咨询公司引导造成的，变成了一个商业驱动的项目。这种情况下，势必造成项目运作是蜻蜓点水式的，面面俱到，但又无法深入，最终很难给企业提出切实可行的行动方案。“屁股决定脑袋”的道理是谁都懂的，因此足够的资源投入也是IT规划项目务实的基本保障。这里，想要IT规划更加务实，首先需要结合企业实际情况，认清IT规划到底能够为企业做什么？如何真正支撑企业的战略、管理和运营？笔者的观点是，IT规划可能不需要进行SWOT分析、不需要进行波士顿矩阵分析、不需要进行竞争态势分析，那些是战略规划需要做的，不能不分清红皂白，一锅菜乱炖。IT规划需要做的是明晰企业的战略，进而找到支撑战略实现的业务发展策略，然后分解到核心价值链的各个业务环节，看看这些业务环节需要具备怎样的能力才能够支撑这些业务发展策略，同时分析出这些业务环节要想具备这些能力哪些是需要IT系统来辅助实现的，并阐明IT系统应该如何做才能让业务环节具备这些能力。这样就可以一层层分解出来IT到底怎么支持业务运营，并进而支持企业战略。拿笔者曾经咨询过的一个案例来说，客户处于竞争激烈的服装行业，要想实现客户创造卓越服饰企业的目标，需要不断满足消费者对时尚的追求，应对快速变化的市场需求。这就要求企业必须建立快速响应的业务策略，这种快速响应不单单是各个业务环节本身的快速响应，需要价值链整体，甚至整个供应链的快速响应。那么就可以分析出为了支撑这种快速响应的业务策略，各个业务环节（包括研发、采购、生产、配送等）需要实现信息的实时共享、并且加强计划的协调性（当然，也还需要其它的能力），而这两点恰恰是IT系统所擅长的，这样就可以有效的找到IT的支撑点，进而进行详细的需求分析，并完成应用系统设计与实施规划，从而给企业提供针对性很强的解决方案。其次，IT规划需要从IT应用的源头入手，挖掘企业到底需要哪些信息？这些信息存在哪里？通过哪些渠道可以获取？怎样对这些信息进行分析、处理、存储和传播？这些信息对企业有哪些影响？企业怎样才能知道哪些途径提供的信息有价值、哪些途径提供的信息价值含量低？企业如何能够调整自己的信息渠道？从而进一步帮助企业搭建合理的信息资源体系，以及信息编码体系，并结合IT需求分析，提供完整的信息内容解决方案，为企业以后的信息系统实施提供切实可行的基础支持。同时，通过制定信息分类、存储、传输和使用的标准，形成规范和制度，并应用相应的IT管理手段，包括激励机制和绩效考核等，对信息内容的加工处理进行规范，真正实现企业信息化建设的意义和价值。接着，IT规划要想务实还要能够在结合企业实际IT需求的基础上，认真分析和比较适合企业的IT应用系统，尤其是大型IT应用平台（像ERP、SCM等），需要针对行业和业务特点，找出几家成熟的软件供应商，客观的进行比较分析，分析的内容包括平台的成熟度、平台的技术方案、相关行业的成功案例、厂商的实施服务能力、本地化开发和服务能力以及性价比等等，并给企业提出客观的建议。由于大型IT应用系统是非常复杂的，因此在比较和分析的时候一定要从细节入手，最好能帮助企业形成各个模块的功能需求说明书，这样在以后企业选型的时候也可以针对性地进行系统测试，Demo演示等等，让企业的选型能够最大程度的达到信息对称，从而实现理性回归，不至于被软件供应商的理念和关系所迷惑。这里，为企业提供全程的软件选型服务也是IT规划务实的一个方面。最后，IT规划在建设企业IT管理体系的时候要挖掘IT管理问题的根源，并考虑企业推广应用的可行性，形成简单可行的解决方案，让企业能够执行。还拿笔者的一个咨询案例来说，客户应用系统上的数据总是不准确，业务部门整天埋怨IT部门工作做的不好，系统不可靠，还不如原来手工 *** 作，并警告IT部门如果再这样他们就不用系统了。IT部门被搞的紧张兮兮的，整天忙在如何设定权限、记录日志、跟踪分析及系统提示上，试图用技术手段解决数据不准确的问题，后来发现问题还是无法解决。这里，通过调研和访谈我们发现，企业对系统数据准确性的考核指标只有IT部门的员工承担，并有相应的激励和惩罚机制。而真正使用系统的各个业务部门的 *** 作员和业务主管，则不会因为系统数据不准确而影响他们的个人利益。这样的话，他们在数据录入和修改的时候就很随意，有的时候甚至故意让数据不准确，以掩盖他们工作中的一些问题。后来通过调整考核指标，加强监督和控制，并制定灵活的激励和惩罚机制就解决了数据不准确的问题。因此，在设计IT管理体系的时候就要从这些实际问题出发，设计可行的解决方案，让业务部门和IT部门能够形成利益共同体，变单向服务为合作伙伴，共同让信息系统在企业内部产生最大的效益。否则，设计的IT管理体系就只能中看不中用了。目前，国内企业的信息化建设也经历了几起几落，取得了一些成绩，也积累了一些经验教训，总的来说还是任重而道远。IT规划作为企业信息化建设的指明灯，就像医生给病人开的处方一样重要。然而，好的医生可以药到病除，而庸医则不但不能治病，还有可能耽误治疗，让小病变成大病。

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

      目前垂直的部门管理模式对“以客户为中心”、“零不爽”要求弊端日益明显。特别是在当前市场需求瞬息万变，需求要求快速支持的背景下，需求无法高质量的实现，首先表现在需求实施的效率与速度上，无法快速支持需求。其次表现在需求实施质量上，需求上线问题较多，带来很多次生问题，需求质量业务单位与分公司都不满意，影响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项目方案.ppt全部的内容，包括:如何编写IT项目方案.ppt、IT搜索引擎的环节有哪些、公司想进行流程梳理，但找了一家咨询公司说建议先上一个IT系统，应该先梳理清楚再考虑IT吧等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！