ERP软件项目经理如何开展项目调研_实施选型_信息化_IT专家网

项目开发方面

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。eas项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。

项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。

项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)

设计

重视架构设计。eas项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一)[1][2][3][4]

善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下，为了项目进度不出现大的偏差，eas项目组并没有过分强调技术，特别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却能够有效地保证项目的进度。从eas最初的架构设计来看，我们引入了 castle与aop，试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用wcf，利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断地放弃了采用wcf的构想，同时又克服了技术困难，坚持了对castle与aop的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。

重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户，则客户更能够理解系统的实现，促进沟通的有效性与准确性。在eas项目中，我们从一开始就确立了原型设计小组，并在分析需求阶段，就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计规范，以约束所有的ui设计。同时，必须培养专门的ui设计师，在开始原型设计时，就尽快完成ui交互的设计。并且，必须成立专门的ui 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的ui设计人员，原型设计可以由需求分析师来完成)

测试

测试成员应了解需求。如果不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)

测试之初必须确定测试原则，对bug的严重程度进行分级。同时，必须确定修复bug的优先级别。

进度管理

保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 rup或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。

要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。

制定项目计划时，必须考虑阶段评审与同行评审的时间。这一点在eas项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及qa及时掌握项目进度，有利于对项目进度的管理。

变更管理

变更包括需求变更、人员变更。如果不控制好，两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述，而eas项目中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。

如果发生人员进入的情况，那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，如果需要新成员加入，发生变更的最佳时机是项目前期。如果在项目中后期加入新成员，无疑则意味着项目出现了灾难性的后果。而新增加的成员，由于不熟悉项目，所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系，反而会带来负面影响。

人员的退出很多时候是不可控的，同时对项目带来的影响也是不可估计的。为了将这些影响降到最低，就必须在项目开始之初就要确立编码规范。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进行合理的评估，并及时报告项目管理部，并与客户及时沟通。如果对项目进度有严重影响，应争取最大的努力取得客户的理解，提出项目延期的申请。

风险管理

要在项目开始之初就考虑到项目过程中可能出现的所有风险，是不现实的。但是，我们必须考虑对风险的管理，尤其是在制订项目计划以及创建团队的时候，考虑这一因素。风险有很多，包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划，而一旦发生了风险，则必须及时响应，组织相关人员解决风险。不能忽略任何一个小的风险，否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。

成员管理

不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时，必须时刻注意成员状况，即使处理工作出现的矛盾与摩擦，随时保证团队合作精神得到最大程度的执行。

持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展，必须告知全体成员，如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班，只能降低项目成员的工作效率。项目过程中，如能适当地开展一些活动，无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻，项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。

必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外，一个好的领导也是至关重要的。因此，必须选择合适的项目组长，通过他们掌握整个项目团队成员的工作进展。同时，还要了解每个成员的能力，以安排合适的角色与岗位。

重视开发组与测试组以及项目管理小组的合作。项目组是一个整体，每个成员的角色不同，但大家都是团队的重要一员。

作者:张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（mvp），著作/译作包括《软件设计精要与模式》、《wcf服务编程》。张逸熟悉c#，asp，wcf等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 soa企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

正所谓知易行难，目标管理并不仅仅是管理目标这么简单，它有一套完备的目标体系。它需要科学的方法，需要一种对时机、风险、分寸的把握和判断的能力。

目标管理是管理大师彼得·德鲁克在其名著《管理实践》中最先提出的，他提出目标管理与自我控制的相互结合使用。德鲁克认为，并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。MBO（ManagementByObjectives，目标管理）是为了实现项目的任务与目的，给各层级人员从上至下制定切实可行的目标，并且各层人员必须在规定时间内完成指定任务的一种管理方法。

去掉繁复的理论体系的包裹，目标管理其实很朴素，手段其实很简单。它需要做好三件事--目标设定、制定计划并控制、度量目标达成度。也就是说，项目启动前要有目标和计划，项目进行当中要有控制，项目结束之后要对目标进行度量。目标管理的关键点在一头一尾，头是分层级设定目标，尾就是考核、评价和奖惩。

因此，目标管理是一种程序或过程，

项目管理者通过目标对下级进行管理，当确定了项目总体目标后，必须对其进行有效分解，转变成各个部门/团队以及各个员工的分目标，管理者根据分目标的完成情况对下级进行考核、评价和奖惩。所以，目标管理量化了目标，从而使目标具体化、可视化。

（2）目标分解与考核量度

目标管理是通过目标的设置和分解、目标的实施及完成情况的检查、奖惩为手段，通过员工的自我管理来实现目的的一种管理方法。过程不重要，结果重要。可能管理过程是松散的，但结果却是受到控制的。在目标分解过程中，权、责、利三者明确，只有每个员工完成了自己的分目标，整个项目的总目标才有完成的希望。

总的来说，目标管理加大了对员工的绩效考核力度。目标管理以制定目标为起点，以目标完成情况的考核为终结。至于完成目标的具体过程、途径和方法，上级并不过多干预。所以，在目标管理制度下，监督的成分很少，而控制目标实现的能力却很强。

（3）目标管理的优点

一是目标管理对项目内易于度量和分解的目标会带来良好的绩效。例如，对于在技术上具有可分性、可量化的工作，由于责任、任务明确目标管理常常会起到立竿见影的效果，而对于技术不可分的任务则难以实施目标管理。二是目标管理有助于改进团队的职责分工。例如，由于项目目标的成果和责任力图划归一个职位或部门，容易发现授权不足与职责不清等缺陷。

（4）目标管理的缺点

在实际项目运作中，目标管理也存在许多明显的缺点。主要表现在：一是IT项目内的许多目标都难以定量化、具体化，或许多工作在技术上不可解，或项目环境的可变因素越来越多，使项目活动的不确性越来越大，这些都使得IT项目的许多活动制订数量化目标是很困难的。二是目标商定可能增加管理成本。目标商定要上下沟通、统一思想是很费时间的，同时每个团队、个人都关注自身目标的完成，很可能会忽略了相互协作和总体目标的实现，滋长本位主义、临时观点和急功近利倾向。三是有时奖惩不一定都能和目标成果相配合，也很难保证公正性，从而削弱了目标管理的效果。

ERP项目在开展具体的上线工作前，需要在前期项目启动等交接工作的基础上对项目的实际情况做进一步的了解，通常需要进行项目的调研工作。项目调研是认识企业的一种有效手段，通过调研可以对企业有更加深入的了解，为于日后的实施工作能够开展尽可能地减少障碍。在调研的过程中将从业务层和人员关系层两方面进一步接触： (1) 对企业的整体情况有个更加深入的了解。例如企业的背景、生产特点、人员素质、人员配合程度等等。对企业基本概况的了解可以便于项目经理制定出正确的实施策略，指导项目按照既定的目标完成。 (2) 更加清晰地了解企业的业务。在前期的售前调研并不会很详细，一般为较长时间以前，而且随着人员的更替以及实际业务情况的变化，也需要重新进一步地了解企业的实际业务情况。 (3) 可以就这个机会对企业的各岗位人员和职责认识。在调研过程中，双方不断的沟通，实施方的人员同企业方的人员会进一步认识。同时可以通过调研了解企业人员的实际职责，了解企业一些潜在的文化，避免在以后的工作过程中制造太大的阻力。 (4) 调研的过程也可以同一些关键用户沟通具体业务的处理模式。业务人员的需求往往同实施人员设想的方案存在一定的差异，通过调研过程中的沟通可以发现一些明显的差异。对于需求和设计方案上的差异，在分析总结后，如果确实是设计方案的问题，可以及早沟通并相应调整设计方案，如果是用户业务模式的问题，或者是需要优化的流程内容可以同用户协调沟通，避免上线过程中造成过大的阻力。 (5) 了解企业方对于项目实施工作重点期望解决的问题。项目的实施是满足既定的需求，企业方期望解决的问题应该作为重点问题加以解决。 项目调研工作包含的内容和形式较多，通常情况下，具体业务过程包括调研资料下发、现场问答和具体细节沟通等。 在项目的启动过程中就可以发放项目的资料，这一过程也可以提前放到项目启动前，具体需要同项目负责人沟通好。 项目调研资料的内容涉及企业运营和管理过程当中的方方面面，总的来说主要包括以下几方面内容。 第一， 企业的概况。需要通过调研对企业的概况深入了解，包括企业的性质、从事的行业、生产的产品、生产过程、管理部门管理现状、生产部门管理现状、普遍反应的企业管理问题等等，从宏观上把握整个项目所属企业的情况，便于针对不同类型的企业采用不同的实施策略。对于有些实施公司存在一套完整的实施方法，但是在实际 *** 作中仍然需要根据实际情况灵活使用。 第二， 具体业务流程现状。需要通过项目调研过程了解企业目前业务流程的现状，从而进一步分析现有流程，并进一步整合和优化。在项目后期的流程优化过程中需要结合企业的实际情况进行综合的优化整合，从业务流程性角度来解决实际业务处理过程中的问题。 第三， 了解各层次人员对项目的需求。总的来说项目是服务于企业整体，但是在实施的过程中同样需要照顾到企业的各层次人员的一些需求，并进行及时的沟通，避免出现需求满足情况同预期存在较大差异而影响实施的效果，毕竟一个各层次人员都反响较差的项目是很难评价为一个真正实施成功的项目。另外，客户的各层次人员的需求需要认真分析，有些需求是同项目实施的目标想违背的，或者是不合理的，需要协调客户方的项目负责人认真沟通。 对于不同的实施公司，调研资料的样式也是不尽相同，调研资料需要根据具体情况来确定采用何种模式，例如：问答式、开放式、混合式等。 第一种方式是问卷式，也就是罗列一系列问题让业务人员回答，此种调研资料的优点是可以对一些自己关心的业务点尽可能详细的设计问题，整理各业务点较简单，缺点是业务人员容易产生反感，有点类似于做试卷，而且对一些问题业务人员无法系统地说明; 第二种方式是开放式，开始部分一般列举一个实例，然后业务人员参照实例进行本岗位的业务现状等的填写，此方式的优点在于业务人员可以根据自己熟悉的流程进行撰写，思路相对较清晰，不足之处在于用户书写的内容不受控制，对一些细节问题不会做过多的说明; 第三种方式是混合式，是以上两种方式的结合，就是说一部分问卷式，主要是对一些具体的细节问题让业务人员逐个回答，对一些流程让业务人员开放式书写。以上三种方式各有优劣，需要针对不同的项目情况来分别采用，主要的参考因素包括对项目前期的了解情况、项目人员的素质和配合程度、项目后期调研的详细程度、参考调研的实施人员的层次水平和结构等。如果后期打算详细了解具体业务问题，可以采用开放式，通过调研资料了解企业的大概流程，对一些关心的业务有一个初步的了解，在调研的过程中深入了解，此种方式对业务人员造成反感较小。不论采取何种方式，都需要各业务部门能够如实地反应本部门的需求，便于项目的实施工作能够达到预期的效果，避免出现项目的实施方向错误，作为项目经理需要对需求进行重点把关，避免超合同的内容。 在项目调研完成后，根据项目的需要，项目组负责起草一份项目的总体业务解决方案或者需求分析报告，确定双方实施工作需要达到的目标及基本的解决思路，具体的实施在后续的实施过程中将有针对具体业务的业务方案作为支撑。如果项目较小或者不需要，可以不采用。在起草解决方案的过程中，需要严格遵照原合同及相关技术协议的要求，避免实施范围的人为扩大。 在项目调研阶段，项目经理需要管理好的资源包括：实施顾问、企业各业务部门负责人及关键用户、企业方高层、企业方项目负责人等。 项目调研阶段，项目经理主要需求达到两个目的：第一，了解企业实际的现有需求，以此作为整个实施工作的指导;第二，有效地控制需求的确认不超过原来的合同或者技术协议的范围。

VUCA一词起源于上世纪90年代的美国军方，是Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）的首字母缩写。VUCA概括了后互联网时代的世界特征——复杂多变。我们所处的世界变化越来越快，知识边界不断被突破，项目管理也不例外。

传统的项目管理虽然认识到项目具有渐进明细的特点，但在计划、执行、监控过程中还是明显强调瀑布特点：制定计划前要“清晰、完备、准确地界定项目的工作范围(SOW)，作为整个项目工作的基础”，然后是“分解出足够详细的工作步骤(WBS)”， 把WBS作为整个项目计划、执行、监控的核心。虽然传统的项目管理中也提到滚动计划，但还是以稳定为基调，把适应变化作为辅助，而VUCA时代恰恰是以变化为最大特点，传统的项目管理方法很难适应这个前提，从而使得计划赶不上变化，项目计划往往成为一纸空文。

传统的项目执行出现问题，多归因为项目工作范围界定不够准确、项目计划不够详尽。应对的策略也很粗暴：一方面是在合同谈判的时候尽量界定清楚、不含糊其辞；另一方面在合同执行的时候，据理力争，合同约定之外的尽量拒绝。

由于各种原因，合同约定一般很难满足SMART原则，“聪明的”乙方则会跟客户约定以“签字后的需求规格说明书”作为验收依据。这样“需求规格说明书”就成了双方的“必争之地”。在项目费用、执行周期固定的情况下，甲方项目经理自然希望乙方能提供更多的、更高品质的功能，至少可以更好地向领导交差；乙方项目经理则希望能以最小的资源投入、冒最少的风险、尽快交付，能拿到更多的项目奖金。

在“合同谈判”胜过“合作共赢”的情况下，乙方项目团队虽然在需求调研上投入大量的精力，但客户不愿配合、拒不签字的场景时有可见，更有甚者乙方会设计晦涩的需求文档、复杂的变更流程，甚至应用了多种心理效应，就是为了约束客户不要再变了。

对于第一种变更，乙方需求分析人员如果有丰富的领域知识与实 *** 经验，能设身处地地分析，大多能够避免。但由于人的思维定势及碎片化倾向，一次很难考虑周全，难免会有遗漏，譬如酒店管理系统中的入住功能，“团队入住希望能住到相邻房间”这样的约束，可能事先很难想到，只有在系统投入使用后才能发现这个不便。为避免这类变更，传统的做法是加大需求捕获与分析的力度，这容易事倍功半，也容易造成“过度工程”的问题。

对于第二种变更，传统的项目管理中一般归到风险范畴，譬如甲方换了领导或项目负责人，组织结构调整，外部环境发生重大变化、设备不到位等等，这些都是风险，都会给项目工作范围带来变化。传统的应对策略是识别、分析、跟踪、应对风险，增加缓冲资源与时间。但风险的概率特性，为管理层提供了侥幸的借口，风险缓冲很容易被上级砍掉，风险被直接转嫁给员工，通过员工的加班加点来弥补。

第三类变更，不是由于问题变了，而是解决问题的方式变了。在汽车没被发明的年代，客户希望更早到达目的地，只会想要一辆更快的马车，而福特却造出了汽车。同样的问题不同的解决方案，效果自然不一样，项目工作范围也会截然不同。

VUCA时代，复杂与变化已经成为主旋律。在这个强调以客户为中心，强调为客户带来价值的时代，项目还要因循计划、不拥抱变化，一方面确实不易做到，另一方面也一定会损害客户关系。

VUCA时代的IT项目管理该如何开展呢？

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

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

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

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

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

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

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

一般出现在申报方案

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

给读者阐明为什么做

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

一般出现在申报方案

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

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

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

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

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

一般出现在申报方案

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

是解决方案的主体

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

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

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

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

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

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

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

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

给读者阐明为什么做

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

借此增强用户的信心

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

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

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

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

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

图示的作用是直观

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先需要明确项目的目标

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

质量要求和质量控制措施

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。

第一步：需求调研分析

第二步：概要设计

第三步：详细设计

第四步：编码

第五步：测试

第六步：软件交付准备

第七步：验收

当前，软件的趋势是朝着更大更复杂的系统发展。这部分地是因为计算机的处理能力每年都在增大，导致用户对它的期望更多。同时，这种趋势也受到为交流各种信息（从纯文本到格式化文本到图像到图表再到多媒体）而不断扩大互联网的使用的影响。在产品版本的不断升级过程中，我们了解到产品是如何被改进的，因此我们对越来越复杂的软件的胃口也就越来越大。我们需要更符合我们的需要的软件，但是，这种需要反过来又使得软件越来越复杂。总之，我们需要更多。

希望软件运行得越来越快捷。推向市场的时间是另一个重要的推动因素。

然而，要达到这个目的是困难的。我们对强大、复杂软件的需要与软件开发的当前状况并不一致。今天，大多数人还在使用25年前使用的旧方法来开发软件。这就是症结所在。除非我们革新我们的方法，否则，我们无法达到开发当前所需的复杂软件的目标。

我们可以把这个软件问题归结为软件开发人员面临的将一个大型软件项目的众多线索综合在一起的困难。软件开发界需要一种受控的工作方式。它需要一个过程来集成软件开发的许多方面。它需要一种通用方法，该方法能：

提供应如何对整个开发团队的开发活动进行组织的指导；

综合指导单个开发人员和开发团队；

规定开发成果是什么；

提供监控和衡量一个项目中的产品和活动的标准。

一个定义良好且管理良好的过程是区别成效卓著的项目和不成功项目之间的重要指标。昌平IT培训发现“统一软件开发过程”正是我们在软件开发上面临的难题的解决之道。

以上就是关于互联网IT项目的管理心得体会全部的内容，包括:互联网IT项目的管理心得体会、如何做好IT项目管理、ERP软件项目经理如何开展项目调研_实施选型_信息化_IT专家网等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！