IT项目质量管理技巧应用的注意事项

从信息技术在企业中的发展过程看有六阶段、五阶段和三阶段模型。著名的诺兰模型为六阶段，即初始、传播、控制、集成、数据管理和成熟阶段。五阶段模型是由Boar提出的IT（Information Technology）与企业业务结合过程，即局部开发、内部集成、业务过程再设计、业务网络再设计、业务范围再定义，其中前两个层次对企业的变革是渐进性的或改良性的，后三个层次对企业的变革则是革命性的影响，也就是说，如果信息技术只是叠加在现存的组织状况上，那么它获得的利益是边际性的。[8]提出三阶段模型的主要有斯科特·莫顿和肖夏纳·朱波夫等，他们将其分为工作自动化、信息管理和经营转型三个阶段，而世界银行发表的Nagy Hanna的《信息技术的扩散：工业化国家的经验及其对发展中国家的教训》中认为信息技术基本按照替代、强化和变革三个阶段扩散。

1211 实施方法研究

ERP的实施可以遵循传统信息系统的开发过程，如结构化法、原型法、面向对象的方法等，也可以采用一些新的技术方法，如快速应用开发（RAD）、业务流程再造（BPR）、组件技术等。一个ERP实施方法论的一般框架包括基本原则、实施阶段、建模工具、实施主体、实施工具、培训文档、技术和服务支持等，在ERP实施中选择一种方法论是重要的，它可以为项目规划、设计以及实现提供一个框架，避免项目的无序和混乱，提高成功实施项目的置信度。

（1）ERP实施的四、五、六阶段模型。针对ERP的自身特性，不少学者开始探讨其独特的开发过程。Rose在研究15个ERP案例的基础上提出了ERP实施过程的五阶段模型，这五个阶段分别是设计、实施、稳定、提高、提升[9]。设计阶段包括ERP系统选型、定义项目实施范围及确定系统结构；实施阶段包括配置和实施软件等；经过实施企业改进绩效后便是稳定阶段；提高阶段是业务流程的优化；提升阶段是业务流程的转变。通过整合Rose的五阶段模型和Markus、Tanis的四个过程（准备、执行、调整、前进或上升），Shanks等提出了四阶段模型，即计划、实施、稳定、提高。而六阶段模型来源于Copper和Zm ud[10]的IT项目实施六步骤理论（开始、分析、适应、接受、程序化、提升），众多学者认为这六个阶段不仅有效地解决了IT、MRP的执行，也非常适用于ERP的实施[11]。一些学者则认为，ERP系统的成功实施只是系统持续改进的开始[12]，系统持续改进对于企业充分发挥ERP系统的潜力，获取和保持企业的竞争优势是很重要的。

（2）过程模型与ASAP法。根据客户需求快速有效地进行项目实施，更是众多软件商所追求的一个主要目标，世界著名ERP供应商SAP公司，针对企业的规模大小就提出了“过程模型”与ASAP[13]两种方案。过程模型是SAP公司在1995年引入的，它将ERP实施过程划分为四个阶段，按顺序分别为组织和概念设计、详细设计和系统安装、运行准备、投入运行，每个阶段又由一些子阶段、活动和工作组件构成。例如R/3过程模型的实施方式是，首先以SAPR/3中提供的业务参考模型为模板，编辑对公司竞争优势非常重要的过程列表；然后参考业务模型清楚地定义出公司的特殊需要，识别出业务参考模型中没有充分覆盖的区域，利用业务工程师中的向导开发出定制的模型。ASAP（Accelerated SAP）方法主要面向中小企业，其线路图由四个主要阶段（项目准备、经营蓝图、实现、最后准备），及投入运行后的技术支持组成。具体到项目的实施又可分为分步实施、全面实施或滚动实施，分步实施就是按模块的先后顺序进行，而全面实施（big bang）是所有模块同步进行，滚动实施（roll-out）则是在一个地方创建一个模型，然后推广到其他地方。

我国某些企业根据自己的经验，也提出了一些较为适合国内企业的实施方法，如金蝶公司的金手指六步法、神州数码公司的e-through实施方法论等。金手指的六个步骤分别是项目组织、系统培训、系统定义、数据准备、系统切换、运行维护，每个步骤均列出了关键的问题、因素和活动。例如，系统定义包括：业务流程分析、二次开发需求分析、二次开发需求确认、业务流程确定、需求反馈、业务流程反馈和变更等。

（3）融合BPR的实施模式。业务流程再造（BPR）是由美国MIT教授Hammer于1990年提出的，BPR就是对企业的业务流程进行根本性的再思考和彻底的再设计，从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量。许多成功的BPR 案例表明，信息技术是企业流程再造的使能器[14]，这主要体现在信息技术作为自动化的动力，将从根本上改变经营管理活动的处理方式。针对我国企业的现状，国内也有不少学者对ERP与BPR的有效整合进行了分析，甚至给出了信息技术与流程整合的简单模型。但多数研究所涉及的内容仅仅是一条思路，而香港理工大学工程学院提出的ERP与BPR整合模式则比较具体，其层次模式的顶层包括了系统规划、流程再造、系统设计和系统评价[15]。

1212 过程优化方法

ERP作为先进管理思想的载体，为企业优化业务流程提供了模式，但如何快速、有效、合理地利用BPR理论对企业现有业务流程进行分析和优化，以便有效实现物流与信息流的有效整合，是近年来理论界讨论比较多的一个问题。综合各种文献可以看出，其研究主要集中于过程建模和量化分析两个方面，分析步骤包括三步：①了解、分析现有的流程，利用各种工具绘制流程图或进行建模分析，发现再造的机会；②对流程进行重新设计，绘制再造后的流程图；③制定流程再造实施方案。

企业建模是指使用适当的表达方式从一个或多个角度（如数据、功能、组织、过程）对一个企业的体系结构进行描述，以产生一系列能代表该企业实际状况的企业模型。目前较为完善的建模框架有John Zachman的Zachman、欧共体的CIMO SA、美国Purdue大学的PER A、德国Saarland大学的ARIS框架，虽然Zachman框架被认为是企业建模领域中的权威，但ARIS框架在经营过程建模方面具有更大的优势。一个经营过程模型是由一系列企业活动组成的经营过程链，以及由经营过程链与其他视图的关联所组成，完整的经营过程链是由事件、活动、状态组成的序列[16]。描述经营过程链的三种主要建模工具是IDEF3（ICAM Definition3）、EPC（Event-driven Process Chain）和Petri网，以及基于UM L的面向对象经营过程的建模方法。近年来有关过程模型构建的研究也比较多见，比如过程描述、订单优化法、PBWD（Product Based Workflow Design）法、Petri网的过程建模等。

业务流程优化的出发点有流程综合和流程分解两种。流程分解首先分析现有的流程，识别出需要重新设计的流程，考虑信息技术的支持能力，对流程进行逐级分解得到新流程设计方案；流程综合则以现有流程为出发点，对原有的流程合并、删除或增加等进行重新设计。由于流程分解多用于原有流程的设计很不合理时，且实施难度较大，而流程综合方法虽受原有设计的影响，对企业流程整合更具有实践性[17]。也有不少学者通过相邻矩阵的关联及转换关系，直接对BPR 进行定量化的研究，如基于活动－组织流程图的业务流程分析方法、基于过程代数业务流程评估等。

IT项目的风险管理

风险一词越来越被概念化，并随着人类活动的复杂性和深刻性而逐步深化，及时在IT项目同样存在，下面我为大家准备了关于IT项目风险管理的文章，欢迎阅读。

一、风险的定义

风险有两种定义：一种定义强调了风险表现为不确定性;而另一种定义则强调风险表现为损失的不确定性。

若风险表现为不确定性，说明风险产生的结果可能带来损失、获利或是无损失也无获利，属于广义风险，金融风险属于此类。而风险表现为损失的不确定性，说明风险只能表现出损失，没有从风险中获利的可能性，属于狭义风险。

广义的风险展现出来的是机会，虽然这种机会可能让我们的项目变得颗粒无收，但如果一旦机会有利于项目，则可以大赚一笔，风险投资家们心中的风险正是广义的风险，所以风险才会吸引他们投入巨大的资金。而作为项目管理者来说，风险对他们意味着失败的危险，因此必须将任何风险扼杀于摇篮之中。

二、IT项目风险的特征

由于软件本身的特点，导致IT项目与传统项目有很大差异，因此IT项目的风险管理难度要比传统项目大。

1需求不稳定

软件项目的需求多变已成为软件业界的共识，正因为需求的多变，才让瀑布模型一直遭受到软件工程界的抨击，因此诞生了原形模型。在IBM的RUP和众多的敏捷方法论中，一直将需求不确定列为软件项目的最大特点，因而出现了拥抱变化一说。

当一个IT项目开始实施的时候，如果客户连他需要做什么，要实现一些什么功能都不能确定的话，那么做软件实施的工程师他们又如何能够知道自己要开发一个什么样的软件系统出来呢所以他们只有在漫长的等待过程中，不断遭受到客户的“批评”，在经历了“九九八十一次磨难”之后，才恍然大悟，原来就是要做一个这样的系统啊!

这有点像盲人走路一样，盲人根本就不知道前面是什么，因此他往前走一小步，如果不是路，则向左旋转一点点，再次用脚探探前面，如果是路的话，则可以往前迈一步。如果这个盲人运气不好的话，第一脚就在悬崖边上踏空，那么他将跌入万劫不复的深渊。我们的项目也如同这个盲人，稍有不慎就可能让自己走向失败，这是一个多么大的风险啊。

2项目规模估计不准确

当老师给我们布置作业的时候，如果他多布置了几个题目，下面的同学便会大声地嘘叹，开始私下的嘟噜：“又要做一个多小时了!”。学生们在很短的`时间内就能够准确的估计作业量大不大，他们的估计凭借着他们每天一次的做作业的经验和那一瞬间对题目的印象，虽然他们并没有做过刚布置的这些题目，但是估计得仍然是那么的准确。

任何一个建筑工程的项目经理都能对自己的项目进度掌握准确，在他们的眼中，只要资金到位，则进度就可以得到保证。工地需要多少人，什么时候需要开始进行什么工序的施工，什么时候需要加班，这些都在他们的心中掌握着。资金就是他们最大的风险。

而软件项目与之不同，在软件项目开始后，很少有缺钱的。只看到过资金没有到位的“烂尾楼”，但是从来没有看到过由于项目资金没有到位的问题而导致未完成的软件项目，就算是缺钱也是因为签合同的时候要少了。

再优秀的软件项目经理，他也无法预计好自己的项目什么时候能够完成，因为在他进行估算的时候，客户的需求还没有搞清楚呢!再者，建筑工程可以通过预算很准确地得出整个建筑的工程造价，而软件项目却很难，因为不管是代码行估算法，还是功能点方法，都远不及“我猜，我猜，我猜猜猜”中猜得准确，这些方法很多时候甚至不如算命先生算得准。

3人的因素对项目影响很大

人可以说是整个软件项目的灵魂，软件项目不需要钢筋、水泥和沙石，也不需要任何的施工机械。软件项目的原材料就是人的思想和智慧，而计算机和CASE软件则是项目的施工工具。通过键盘和鼠标，无数的程序代码在程序员手中诞生了。如果要问软件项目最大的成本在哪里，那么答案只有一个，就是人力成本。

一个优秀的程序员的工作效率要远远高于一个蹩脚的程序员，一个程序新手甚至根本就不能够产生任何生产效率。不仅如此，新手的错误行为，将让熟练员工牺牲很多时间来帮助新手纠正他们的错误，甚至可能导致降低软件开发的效率。

虽然软件项目已经实施角色分工和管理，但是相对于其他工程的分工来说则分工比较单一。软件项目中，一般分有：系统分析师、架构师、设计师、程序员、测试工程是及配置管理人员和项目经理等。这样的分工并不能有效地降低他们工作内容的复杂度。如果能像建筑工程中的砌墙、浇注混凝土、搭脚手架那样分工细致的话，则培训软件蓝领也不会需要费如此大的力气了。

;

IT项目开发人员普遍认为，要高质量并按时完成项目是难以实现的，项目经理们并非不想要高质量的项目成果，他们只是想在质量的基础之上，能够按时完工和低于或等于预算的情况下，实现这个项目。有些项目管理技巧虽然确实可以成功地在降低成本和开发时间的同时不会对质量造成影响，然而，必需注意的是，过度地利用这些技巧就有造成灾难性后果的潜在可能。

1、时间盒(Time boxing)

在破坏项目质量的事件列表上，时间盒的应用排在第一位，当您告诉某人在任务必须移交之前，他拥有多长时间来完成这项工作，我说“移交”而不是“完成”，因为在极端情况下，这经常意味着代码并不完善，仅仅是抓紧时间去完成这项工作。

在大多数情况下，时间盒是有效的，因为它可以做到四件事：

1 它迫使开发者能够富有创造性地在他们的预算之内发现解决方案。

2 它排除了经常添加在软件中不必要的虚饰，而这些虚饰往往并不能增加软件的价值。

3 它防止开发者过度测试。

4 目的只是要得到这件产品，在完整的质量评价(QA)阶段将会有详细的测试，希望在此阶段中能够发现代码中存在的问题。

当存在未知问题，或技术没有经受检验，或没有正确的方法来检验结果的时候，时间盒就无能为力了;当时间盒很小，而且在分配的时间之内并没有可能的办法来实现目标时，这种方法也是无效的。换句话说，时间盒可以很好地解决一些问题，比如充分理解、谨慎评估和执行类的任务;然而，也确实存在时间盒方法不能很好解决的问题，比如研究和发展，还有解决问题等等。

如果时间盒是正确使用的，那么不应当导致测试到很糟糕的代码，这些糟糕的代码可能会导致数百个小时的诊断和返工。时间盒应当适度使用来确保最低的成本、最快和最高质量的软件。

2、误期

所有人都要有奋斗的目标，里程碑是一种受到尊敬的方法，它用来激发人们向同一个目标前进，这种动力可以在很短的时间内得到重大成果。然而，每个人都必须承认里程碑所界定的时间并不是每次都能实现，这时就必须要做出新的决定。

项目经理们必须要在团队中树立里程碑的目标，以此来激励他们前进，但是，当里程碑确立的日期并不现实，而且队员们一再出错，那就应该重新评估这个计划了。如果因为某种特殊情况可以使这个日期不再重要，那么当这个重要日期真正来临的时候，整个团队就只有很小的动力来实现这个里程碑日期。当整个团队连续错过了10个日期，那么第11个日期还重要么这就像喊着“狼来了”的孩子一样。

如果在设定的时间线之后并没有任何处罚，那么当错过这个时间的时候就应该强制执行或者移动整个时间线。

长远来看，不断创造持续的压力和令人迷惑的环境并不能创造出好的软件，开发人员需要能够专心工作的环境。完成项目的日期和关于里程碑日期是否真实的混乱，经常会导致开发人员在开发过程中跳过关键步骤或者造成难以发现的问题。

3、忽视相关性

在软件开发中，我们有很多技巧可以用来延迟相关性，我们可以停用一些函数、移动相连的基本架构，或者绕开众多的错误处理，在正确使用的情况下，所有这些技巧都可以帮助推进一个项目，然而，当为了完成项目，而这些技巧的成本因素又没有被考虑到整个计划当中时，就埋下了烦恼的种子。

很多时候，在项目中排列软件开发的顺序是非常具有挑战的事情，相关性并不容易被发现，因此也就不可避免地有很多相关性因素没有被安排到计划当中。为这些不可预见的相关性安排日程表可以让人变得疯狂，因此，压制相关性的方法是经常使用的，但是，如果过度使用了这些技巧，这些费用可能经常会占据项目总成本中很重要的一部分，而且直到项目的最后才会被发现。

所以要确信您现在所做的对于管理相关性是必需的，不会添加过多的成本，而且是整个软件开发项目中必不可少的一部分。当项目经理不能在成本与降低相关性的便利中取得平衡，那么他们草率地组装的代码将会展示出质量问题。

4、假装没有错误

在项目管理中，忽视并不是一种幸福。为了成功地完成项目，除了不可阻挡的政治压力，向公司其他的员工介绍项目的风险也是必需的。几乎每个软件开发项目都有延期或超出预算或同时出现这两种情况的风险。

问题在于，当最终某一时间，这些风险真正变为现实的时候将会引起恐慌，每个人都在混乱中将项目其余的部分组装在一起，整个项目的质量将因为最终轻率的装配而遭受损失。

当然，当整个项目还没有落后于计划之前，这一问题还不会充分暴露出来，然而，大多数项目都有办法只让项目的某些部分落后一点点，而几乎每个项目都有过于仓促的风险，这是因为管理层在很长一段时间之内都在项目没有任何问题之后得知项目的真实状态。

不知道你这么问是不是不想学习编程和数据库？

学习IT项目管理可以使你具备成为一个项目经理的基础知识。

但是，程序和数据库都是IT项目中需要的基础工具，就像你做木匠活要有改锥和钳子，就算你不学习怎么制作改锥和钳子，但也必须知道他们怎么使用、有什么功能。不然你也当不好木匠。

学习还是要全面。

IT项目管理肯定要包括程序和数据库的知识，但没有专门学开发的课程那么深入，除此之外是质量控制、进度控制，法律法规方面的知识，应该属于涉及面比较宽泛的学科。

软件开发项目中会遇到哪些问题呢参加软件学习不得不了解在以后工作中会出现的状况，IT培训为你提前解析。

1)新手。任何项目组成员都不可避免地出现新手，他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太短，往往技术不成熟，没有形成良好的开发习惯，所以编写代码质量较差，问题很多。他们常常成为项目组的“鸡肋”，用多了项目质量无法得到保证，不用则又人手不够。当然北大青鸟校区的学子毕业就已经有一年多的工作经验，已经是熟手了。

2)人员变动。一个维护时间稍长一点儿的软件项目，人员变动是在所难免的。老员工被调动到其它项目去了，由新员工来接替他们的工作。北大青鸟校区软件讲师在一次软件培训课堂上就说到，在我的项目组中，人员调动达到了90%，没有调走的就是我自己。新员工在接替老员工进行代码维护，甚至继续进行新的开发的时，由于对原有代码以及设计思路理解的偏差，也会出现大量的低劣代码。

3)不规范的代码编写。即使除去以上两个问题的影响，项目组成员编写的代码同样会出现问题。在项目开发之初，我们往往会制定一个代码编写的规范，但在项目开发过程中，许多成员往往会忽视这些代码规范而进行随意的编写。随意地代码编写会降低代码的可读性、可维护性和易变更性。那么，我们应当采用什么样的管理措施，保证代码的规范，提高代码的质量呢

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

以上就是关于实施模式与过程研究全部的内容，包括:实施模式与过程研究、IT项目的风险管理、IT项目质量管理技巧应用的注意事项等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！