软件项目失败经验总结

合集下载

项目失败总结反思

项目失败总结反思

项目失败总结反思引言项目管理是一项复杂且具有挑战性的任务,尤其是在项目末尾不如预期的情况下。

我们经常会面临一些挑战,例如资源限制、时间压力、团队间的协作问题等。

这篇文章将探讨一个项目失败的案例,并总结反思与教训,以期从中汲取经验,改进未来的项目管理。

背景这个项目是一个软件开发项目,旨在开发一个新的Web应用程序,以提高组织内部的协作和效率。

项目启动时,团队充满热情,每个人都充满信心,并按照计划开始执行任务。

失败原因不清晰的项目目标和范围定义在项目开始之初,项目目标和范围没有被明确定义。

团队成员对于项目的目标理解不一致,导致团队在项目执行过程中出现了分歧。

在没有明确的项目目标和范围的情况下,项目变得模糊不清,难以衡量进展和成果。

时间规划不合理在项目启动时,时间规划没有充分考虑到团队成员的可用性和潜在的延迟因素。

团队成员被要求在短时间内完成大量任务,这导致了工作高度紧张和质量不稳定。

项目管理团队应该更加细致地规划项目的时间表,并提前考虑到潜在的延迟。

缺乏有效的沟通和协作沟通和协作是项目成功的关键因素之一,但在这个项目中,沟通和协作存在问题。

团队成员之间缺乏有效的沟通渠道,信息传递不及时,导致误解和冲突的发生。

团队成员之间的协作也存在问题,各个团队成员在工作分配和任务执行上缺乏协调,导致工作重叠和效率低下。

反思与教训清晰明确的目标和范围定义项目目标和范围的明确对于项目成功至关重要。

项目管理团队应该在项目启动之前,与团队成员一起制定明确的目标和范围,确保每个人对项目的期望一致。

这样可以帮助团队成员更好地理解项目的重点和优先级,并在项目执行过程中更好地对进展进行监控和调整。

合理的时间规划在项目规划阶段,项目管理团队应该细致地考虑到团队成员的可用性和潜在的延迟因素。

合理地估计任务完成时间,并提前留出一定的缓冲时间,以应对可能发生的延误。

项目管理团队应该和团队成员一起制定详细的时间表,并定期进行进度检查和调整。

ERP项目实施失败体会总结

ERP项目实施失败体会总结

ERP项目实施失败体会总结二年前的九月公司开始实施ERP系统,按照项目的计划半年完成实施,但是,直到现在项目还没有正式运行,项目失败的原因是什么?我大概总结了几点供大家参考:1、帐目不清ERP难有作为在企业准备上ERP系统之前,应该先问问高层领导包括自己,我们的账目是否明了?我们的人手够吗?公司上下有上ERP的愿望吗?我们希望这个项目解决我们哪些问题?如果这些问题的答案是模糊的,最好别上ERP,ERP的成功与否决定了内部的上下一致的愿望和决心,我们公司业务多样,基本上涵盖了工业企业的各种状况,在启用ERP系统之后的6个月,公司的账目一直调整不过来,帐实不符。

同时,保税与非保税物料混在一起。

今天怕海关,业务流程要重新调整,明天怕税务,业务流程还要另外调整。

长此以往,造成业务数据不准确,核算系统、成本系统都不能投入使用,库存也不准确。

这种原因的产生,不是只有我们一家企业会出现,这是中国企业的特色决定的,避这个怕那个,很多帐目不敢公布在阳光之上,上ERP就成了摆设,电脑手工两笔帐,ERP成了一个增加工作量的附加品。

2、信心不足公司很难万众一心记得一次会议上,我们CEO说:上这套系统还是有用的,万一MRP运行不起来,我们就另外换一套系统。

基础资料是整理好了的,到时将各种基础资料引入新系统就行了。

虽然这句话没什么恶意,但是连CEO都对这个系统没信心,下面的员会怎么想呢?可能在座的所有此时都会打一个大大的问号了。

另外,让公司上下了解上ERP的目的,无形中会增强工作的积极性。

由于软件本身的原因,运行过程中的几次错误就引起了我们操作人员的极度不满,这时候就应该告诉他们,是软件就有Bug,我们这套系统是目前国内最好的,能做成这样已经很不错了。

在项目启动之初,就应该树立必胜的信心。

3、最好在开始项目之前,完成前期数据准备对于一些基础数据,例如各种基本资料的编码。

我们有必要提前完成,免得拉长项目实施周期。

在我公司的ERP实施过程中,我们花了大量的时间整理基础资料。

我在软件开发中的失误与反思

我在软件开发中的失误与反思

我在软件开发中的失误与反思在软件开发过程中,我经历了许多失误和挫折。

这些错误教会了我很多重要的教训,并且促使我反思自己的行为和决策。

在这篇文章中,我将分享我在软件开发中犯下的几个常见错误,并提出我对这些错误的反思和改进方法。

一、不完善的需求分析在软件开发的早期阶段,我常常犯一个错误,那就是对需求的分析不够仔细和全面。

我倾向于只听取部分用户的意见,并忽略了其他人的需求和反馈。

这导致了最终产品与用户期望不符,造成了沟通和使用上的问题。

反思:通过这一经验,我认识到了需求分析的重要性。

现在,我会更加注重与用户的沟通,聆听他们的想法和建议。

我会积极采取多种渠道收集不同用户的意见,并将其整合到需求分析中。

此外,我也会更加仔细地审查需求,确保在软件设计和开发之前对其进行充分的讨论和确认。

二、缺乏详细的设计规范另一个我经常犯的错误是缺乏详细的设计规范。

有时候,我会急于开始编码而忽略了一个明确的设计方案。

这导致了代码的混乱和不易维护性。

反思:我现在认识到设计的重要性,以及在编码之前制定详细的设计规范。

在项目开始之前,我会充分讨论和确定软件的整体架构,并编写详细的设计文档。

这些文档包括各个模块的功能和接口定义,以及代码的组织结构和风格指导。

通过这样的规范,我能够更好地理解和控制整个开发过程。

三、不够重视代码质量和测试在过去的项目中,我有时会为了尽快完成任务而忽略代码质量和测试。

我经常只关注功能的实现,而忽视了代码的可读性、可维护性和可扩展性。

这导致了大量的bug和更长的调试时间。

反思:现在,我已经意识到代码质量和测试的重要性。

我会定期进行代码审查,确保代码符合规范和最佳实践。

同时,我会编写详细的测试用例,并在开发过程中进行严格测试。

这样可以帮助我更早地发现和修复问题,提高软件的质量和稳定性。

四、缺乏团队合作和沟通在过去的软件开发项目中,我有时候对团队合作和沟通的重要性不够重视。

我更喜欢独自解决问题,而忽视了与其他团队成员的合作。

失败项目总结报告

失败项目总结报告

失败项目总结报告失败项目总结报告一、项目背景:本报告对于某公司在2019年启动的某项目进行总结分析,项目旨在开发一款移动应用程序,以满足用户在线购物的需求。

二、项目目标:1. 开发一款用户友好的移动应用程序,支持用户的在线购物需求;2. 实现商品展示、订单管理、支付结算等功能。

三、项目执行情况:1. 项目启动后,我们建立了一个跨职能团队,包括产品经理、设计师、开发人员和测试人员,以确保项目的顺利开展;2. 项目经理与团队成员一起制定了项目计划和里程碑,并按计划进行了项目开发;3. 在项目开发过程中,我们采用了敏捷开发的方法,进行了多次迭代和反馈。

四、失败原因分析:1. 没有与用户充分沟通:在项目开始之初,我们没有充分与目标用户沟通,了解他们的需求和期望。

这导致我们研发的产品与用户的实际需求不符,用户体验较差。

2. 开发周期过长:由于团队成员之间的协作不佳、项目管理不当,导致项目开发周期过长,不能及时满足市场需求。

3. 技术难题未能解决:在项目开发过程中,团队遇到了一些技术难题,但是我们没有积极寻找解决方案和资源支持,导致项目进展缓慢,无法达到预期目标。

五、教训和改进措施:1. 与用户进行充分的调研和沟通,了解他们的需求和期望,确保产品与用户需求相匹配。

2. 强化项目管理和团队合作,确保项目按计划进行,提高项目执行效率。

3. 解决技术难题时,及时寻找相应的资源和专业支持,加快项目的进展。

六、项目总结:本项目虽然失败,但是我们从中学到了宝贵的经验教训。

我们意识到项目开发的重要性,包括与用户的充分沟通、良好的团队合作和高效的项目管理。

我们将以本次失败为契机,加强自身的能力和团队的协作,以期在未来的项目中取得更好的成果。

七、结语:在项目失败的情况下,我们应该不气馁,而是从失败中总结教训,积极改进,进一步提高自身的专业能力和项目管理水平,为公司的发展做出更大的贡献。

软件工程项目实践中的经验教训和体会

软件工程项目实践中的经验教训和体会

一、概述在软件工程项目实践中,经常会遇到各种各样的挑战与困难。

通过总结项目经验教训,可以更好地应对类似问题,提高项目的成功率和效率。

本文将结合个人实践经验,分析软件工程项目中的常见问题,并提出相应的解决方案和体会。

二、需求分析1. 经验教训:在项目初期,需求分析不够充分和明确,导致后期频繁变更需求,影响项目进度和质量。

2. 解决方案:在项目启动前,充分交流和理解客户需求,制定详细的需求文档,并与客户进行确认,尽早确定需求,并设立变更控制机制。

3. 体会:需求分析是软件工程项目中至关重要的一环,只有深入了解客户需求,才能确保后续的开发工作能够有条不紊地进行。

三、团队管理1. 经验教训:团队成员交流不畅,任务分配不合理,导致开发进度缓慢,甚至出现资源浪费。

2. 解决方案:建立有效的团队交流机制,明确每个成员的职责和任务,定期进行进度汇报和问题讨论,及时调整团队资源分配。

3. 体会:团队的协作和交流至关重要,只有团结一心,才能有效地推动项目进展。

四、技术选型1. 经验教训:在技术选型上盲目追求新技术,导致项目实施难度增加,成本和风险增加。

2. 解决方案:在技术选型前,充分评估技术成熟度、适用性和团队技术水平,选择稳定成熟的技术,尽量避免过度追求新技术。

3. 体会:技术选型需要谨慎,需要综合考虑技术成熟度和团队实际情况,避免过度追求新技术带来的风险和不确定性。

五、项目进度控制1. 经验教训:项目进度缺乏有效控制,导致项目延期,增加成本和风险。

2. 解决方案:设立详细的项目计划和进度控制表,建立完善的项目管理机制,及时发现和解决进度偏差,确保项目按时交付。

3. 体会:项目进度控制是项目管理中至关重要的一环,需要不断跟踪和调整,确保项目能够按计划进行。

六、质量保障1. 经验教训:在项目实施过程中,质量保障工作不足,导致项目交付后出现大量bug和质量问题。

2. 解决方案:引入合适的质量保障工具和流程,建立完善的质量管理体系,进行全程的测试和质量监控,确保项目交付的质量。

软件工程师常见错误分析心得

软件工程师常见错误分析心得

软件工程师常见错误分析心得在软件开发过程中,常常会遇到各种问题和错误,这些错误可能导致项目延期、功能不完善甚至严重影响系统的稳定性和安全性。

作为软件工程师,我们需要不断总结经验教训,分析错误根源并采取相应措施,以便在今后的工作中避免重复犯错。

本文将就软件工程师常见错误进行分析并提出相关心得。

一、缺乏设计和规划很多错误都源于软件项目在开始阶段缺乏足够的设计和规划。

这种情况下,软件工程师可能会直接进入开发阶段,而忽略了系统的整体架构和细节需求。

这样做往往会导致开发过程中经常出现需求变更、重复劳动和代码混乱等问题。

针对这个错误,我个人总结出以下心得:1. 充分了解客户需求:在项目开始之前,与客户进行深入交流,明确他们的需求和期望,以便为软件开发制定合理的设计和规划。

2. 完善的系统设计:在进入开发阶段之前,充分进行系统设计,包括整体架构、模块划分、接口设计等,尽量避免后期频繁的需求变更。

3. 详细的开发计划:制定详细的开发计划,包括每个阶段的工作目标和时间节点。

同时,进行合理的任务分配,确保团队成员清楚自己的职责和工作重点。

二、不注重代码质量和测试在软件开发中,我经常发现一些错误是由于对代码质量和测试工作的忽视造成的。

一些软件工程师可能会急于完成任务,忽略了代码的可读性、可维护性和健壮性。

同时,测试工作也常常被放到最后,导致问题难以发现和解决。

针对这个错误,我个人总结出以下心得:1. 遵循编码规范:编写规范化、可读性高的代码,并且注重命名规范、注释与文档的编写。

这有助于团队成员之间的沟通交流,也方便后期的代码维护。

2. 引入代码审查:通过代码审查的方式,及时发现潜在的问题和不规范的代码,确保代码质量。

审查过程中要注重团队协作,尊重他人意见,并及时改进。

3. 强化测试意识:在开发过程中,要有良好的测试习惯,充分自测代码,并进行单元测试、集成测试和系统测试等多个层面的测试工作,确保软件的质量。

三、沟通不畅和缺乏团队协作一个团队的成功往往离不开良好的沟通和团队协作。

项目失败总结与反思

项目失败总结与反思

项目失败总结与反思引言在项目开发过程中,有时我们不可避免地会遭遇失败。

这种失败提醒我们需要审视自己的做法,从而汲取经验教训,避免类似错误的再次发生。

本文将回顾一个项目失败的案例,并就其原因进行分析和反思,希望能给读者带来启示。

项目背景本项目是一个电商平台的开发,目标是为用户提供一个方便快捷的购物体验。

项目启动时,团队成员积极参与和投入,充满激情和期望。

项目过程规划与需求调研在项目规划阶段,我们对市场进行了调研和分析,并根据用户需求制定了详细的项目计划。

然而,在需求调研中我们存在一些问题。

首先,我们没有充分了解用户的真实需求,只是通过市场调研得出一些表面的结论。

其次,我们未能准确估计项目时间和资源的需求。

这些问题最终导致了后续开发过程中的误差和延期。

开发与测试项目开发过程中,团队成员分工明确,高效工作。

然而,由于对需求的理解不准确,我们遇到了一些技术难题。

这些问题在进行系统集成和测试时才被发现,导致了进度的严重延误。

此外,我们在项目开发过程中没有进行足够的自测,而是依赖于最终系统的测试阶段,这也是一个失误。

项目交付由于项目延期和质量问题,我们最终未能按时交付项目。

虽然我们在最后的冲刺阶段加班加点,但无法弥补过去的错误和延误。

对于客户而言,项目交付延误导致了一系列的负面影响,从而影响了项目的成功度和客户满意度。

失败原因分析经过项目的失败,我们认为主要的原因有以下几点:1.需求理解不准确:在项目启动阶段,我们没有充分了解用户的真实需求,并仅仅依靠市场调研做出了一些推测,导致了后续开发过程中的误差和延期。

2.进度管控不力:我们在项目开发过程中未能准确估计项目时间和资源的需求,导致无法按时完成开发任务。

3.缺乏自测:在项目开发过程中,我们依赖最终系统的测试阶段进行调试和修复,而未能进行足够的自测,导致了在系统测试阶段遇到一系列的技术难题。

4.项目交付延误:由于项目进度延误和质量问题,我们未能按时交付项目,给客户造成了一系列的负面影响。

失败项目总结经验怎么写

失败项目总结经验怎么写

失败项目总结经验1. 引言失败是项目管理中不可避免的一部分,每个项目都可能面临失败的风险。

然而,通过总结经验教训,我们可以学到宝贵的教训,并提升我们在未来项目中的表现。

本文将总结一次项目失败的经验,并提出一些建议,以帮助未来的项目获得成功。

2. 项目背景在项目失败的情况下,首先需要明确项目的背景和目标。

本项目是一个软件开发项目,旨在开发一款人力资源管理系统,用于帮助公司管理员工数据、薪资等信息。

该项目计划周期为6个月,涉及15名开发人员和5名业务人员。

3. 失败原因分析3.1 需求分析不充分项目在需求分析阶段出现了问题。

由于没有足够的时间和资源进行详尽的需求收集工作,我们只能依赖业务人员提供的初步需求列表。

然而,当软件开发过程中遇到新需求或变更时,我们没有建立起有效的变更控制机制,导致需求范围的不断扩大,最终导致项目时限无法满足。

3.2 项目管理不当项目管理方面也存在问题。

项目进展缺乏透明度,与开发团队的沟通不够及时和充分。

项目经理在关键决策上缺乏主动性和决断力,导致处理问题的能力受到了限制。

此外,项目计划和进度控制也比较松散,没有建立有效的项目监控机制,导致项目偏离预期。

3.3 团队合作与沟通问题团队合作和沟通方面也存在一些问题。

团队成员之间的合作不够紧密,缺乏有效的团队协作机制。

开发人员和业务人员之间的沟通和理解存在障碍,导致需求理解不准确,开发结果与预期不符。

4. 得出的教训4.1 充分的需求分析和管理需求分析是项目成功的基础,必须投入足够的时间和资源来开展这项工作。

发现和解决需求中的不明确性和冲突是至关重要的。

此外,建立起有效的变更控制机制,确保新需求的控制和管理,以避免项目范围的不断扩大。

4.2 健全的项目管理机制项目管理的有效性对项目成功具有决定性的影响。

必须建立透明、及时的沟通机制,确保项目进展的可见性和团队成员之间的有效沟通。

此外,项目经理应该具备足够的决断力和处理问题的能力,及时做出关键决策。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

项目失败经验总结1、在项目初期没有进行风险得管理探讨,项目远景定义与功能集合得详细定义。

当项目走了很远,出现很多问题得时候,领导总算想起要做一个边界定义,但这个时候已经迟了,项目已经变得不可控制。

经验总结:由于客户一般对计算机不就是很了解,与她们交流就是用软件行业得专业俗术语,她们根本就不懂,如果用文档也很难把需求写得那么明白,而且文档很多得话,客户都瞧烦了,很不直观。

如果让客户一瞧就可以瞧出这个就就是她们想要得,我认为最好得方式就就是做系统原形(界面得功能模拟)。

系统原形应该在需求分析师得指导下完成,当然开发只就是界面得功能模拟,没有底层代码得实现。

这样做得目得有三个好处,一就是客户很直观得瞧到她们得系统就是什么样子得以及怎么操作,二就是这些开发得成果就是可以二次利用得,三就是可以更好得激发客户得需求。

2、不注重用户参与.没有一开始就让用户参与详细需求得制定得做法,大部分都就是靠需求采集人员得猜想,猜想往往与实际有差距,造成系统功能不切合实际,与项目实际需求差距大,运行效果差。

经验总结:项目得开始与结束用户就是需要一直参与进来得,我们每做个可以运行得功能等就需要与用户交流,这样可以避免很多风险也可以尽早发现需求得误解得等等。

需求调研前期得《信息化规划》、《目标与范围》与需求调研末期得《软件开发需求规格说明书》都要跟客户签字确认,这样既能保证我们所理解得需求就就是客户所要得,也使得项目末期跟客户验收时有据可依.3、集团化以后,项目经理没有意识到信息化核心问题就是管理变革问题,还跟着原来得思路开发软件。

在组织架构、权限、供应商等方面与力与集团理解不一致,没有分别按组织进行区分。

经验总结:要根据企业业务需求制订策略,调整软件组织结构, 详细设计软件各组织架构之间得逻辑关系,做好这些最基础得功课,避免信息化项目成为无本之木。

4、软件开发人员、设计人员能力得低下、项目经理得管理能力不足。

低素质开发人员由于没有接触过实际业务,无法跟客户沟通,甚至害怕客户提出需求,总就是担心客户得需求会增加自己得工作量,不愿配合.导致无法理解真正得需求,也无法改进系统功能.设计人员能力得低下,设计系统结构时过于定制,系统得可扩展性较弱,给后期维护带来巨大得负担与维护成本得激增。

当出现严重问题时,项目经理没有根据现阶段状况重新评价需求分析结果、开发人工数估算、设计结果等就匆忙采取头痛医头、脚痛医脚得措施,致使问题更严重。

经验总结:实行双项目经理制度:为开发项目设定两个项目经理岗位,一个负责技术岗位,另一个负责管理岗位.目前,国内得软件开发企业得项目经理一般都就是一名,而且就是技术出身得占绝对多数,她们主要擅长得就是技术研发,在管理方面先天不足,这不利于项目风险管理与控制。

通过增加专门得管理经理岗位,可以弥补技术出身得项目经理得不足,提升软件开发项目得管理水平。

而且这样得经验也已得到了国外业界大多企业得认可。

技术岗位:负责技术框架得稳定性与可扩充性、质量得保证、风险得预测以及数据库得设计,模块测试、接口测试、白盒测试等;对于该项目具体需要多少人员、时间;到底需要什么层次技能得程序组组长与具体开发人员给出详细得计划;对程序组每周具体得开发目标得进行检测验收,保证开发进度.以及其它需要考虑得问题等,如网络速度,服务器访问量,数据库查询优化,都需要整体考虑。

管理岗位:掌握行业知识、项目得前期调研、需求分析、功能模块架构设计、人员得管理、实施计划得安排执行与跟踪.提交《目标与范围》与需求调研末期得《软件开发需求规格说明书》。

一个项目在前期得工作非常重要,就算就是一个错误得话,后面有再强大得开发团队也就是白搭。

我们还就是一个年轻得团队,很需要公司来培养这样得人才,如果就是遇到项目,再招外来人员来担当这样得工作,风险就是可想而知得。

而且这样得人员肯定就是从项目实战中成长起来得,不就是有其她软件项目管理经验得人员或者技术开发人员转过来就可以做好得,更不就是从书本或者参加某些培训就可以学到得。

5、一味得追求快速开发,时间进度。

每天都加班加点地工作,造成人员流动得扩大以及工作效率得降低.最后无论客户,还就是开发人员,都想早点结束项目.经验总结:项目中有个不变得金三角法则,即时间、功能与资源。

我个人得意见就是用我们得实际能力按照一个正常得进度去做,一个项目在功能、时间与资源一定得情况下,没有捷径可以走得,必须一步一个脚印。

6、胡子眉毛一把抓,不分主次.整个项目没有指定里程碑或规定设计评审期,没有计划什么时间节点完成某一个组织或部门得信息化评审后,再进行下一个阶段得开发计划与实施。

摊子铺得太大,软件人员与准备严重不足.经验总结:根据企业不同得发展阶段,按照规划逐步深入,这样一方面可以避免投资得盲目性,另外一方面在前期得投入收到效果后,再进行下一阶段投入得同时,员工与企业领导也容易接受,软件人员得压力也会相对减少。

7、开发结果不验收测试,开发技术水平低下.开发结果没经过测试就给客户上线使用,造成报表得数据很多对不上账目,已经打印出来得报表,过几天再打印数据就不一样了。

由于项目经理没有明确要求技术水平,寄希望于员工自己努力,造成打印得单据上,‘毛重’减去‘皮重’不等于‘净重'得情况。

经验总结:必须做好充分准备得开发计划,对于该项目具体需要多少人员、时间;到底需要什么层次技能得程序组组长与具体开发人员给出详细得计划。

8、没有项目总结会议,不重视项目质量.软件从实施开始就产生了很多问题,但遗憾得就是从开始到结束没有组织过一个项目总结会议,问题日积月累,最后导致项目失败。

不重视项目质量。

在代码与数据库设计中时间投入很少,这些工作本来就就是比较抽象得,需要不断得研究与推敲才能设计好得,但就是我们为了时间进度,很快就赶出来了。

经验总结:每日必须召开项目总结会议,随时捕获风险,当日事当日毕。

软件开发初期得时候,就开始猛抓质量,而不就是走“先上线、后优化”得项目常规实施方法。

若发现质量不合格得地方,就让开发人员重新返工。

9、软件版本发布周期频繁。

几乎每天都需要进行一次版本更新,有时候1天更新几次.更新完成后,客户无法登陆,软件功能无法使用,以前录入得数据瞧不见等情况。

让客户怨声载道,骂声一片.经验总结:发布周期为1周1次或2周1次,在版本更新前,必须做好充分得测试,方可交给客户使用。

10、不重视客户体验,缺少抵御风险得奖励机制。

系统不以客户为中心,不能提高业务部门得工作效率,忽视了客户体验;通常10分钟能完成得工作,工作人员操作软件1小时才能完成。

很多时候加班就是没有加班费得,并且在实施过程中又没有任何奖励.所以,员工认为就是这套系统拖累了她.虽然项目对公司有益,对她个人就没有多少好处了。

经验总结:公司应该拿出一部分预算,有计划有规模地组织用户进行测试,对操作员给出得体验意见做好详细得记录,并给予充分得重视,对其中有用得软件改进意见给出相应得奖励.做好足够得风险应对计划,抵御这种影响所带来得对系统本身得顺利实施以及实施人员得信心与工作激情得冲击。

11、缺少数据风险意识。

在系统得并行阶段,没有统一得基础数据,如材料编码、单据标准等。

数据录入得缺少合理安排,缺少数据风险意识。

用户总就是反映报表数据与小票单据帐目对不上,录入得小票数据丢失了。

软件系统就是一个高度集成得系统,一个环节得出错将可能导致一系列得错误,所以,对数据得准确性提出了很高得要求。

经验总结:必须制定《公司基础信息编码》,搭建了整个信息化制度.在项目实施过程中,针对类似得问题也不能光靠人工对账减少错误,而应该采取一定得控制措施,利用系统设置,做好问题得预防措施。

比如我们可以建立每日审账制度,在系统中进行设置,每天录入完成得票据都进行核对,核对完成后进行锁账.出台《操作规程》,《操作员奖惩办法》等等,规避风险。

12、不注重细节。

天下大事,必做于细。

1%得错误往往会导致100%得失败.力与项目在开发得时候,仅仅就是满足于“软件可以使用”或“功能能够实现”得情况,并没有关注到每个设计、每次改动、每天得操作。

经验总结:在此对之前开发过程中一些可以改进得细节列出,进行总结,在今后得开发中将进行改进。

(1)软件每一个打开得窗体都应该写上标题,而不能就是默认得标题.(2)操作按钮位置、操作顺序必须一目了然。

(3)软件得功能都加上快捷键,使它适应不同操作习惯得用户.(4)每一个窗体都加上“关闭"快捷键,当用户需要关闭窗体时,只需要点“ESC" 键就可以退出,方便用户得操作。

(5)所有输入文本框都必须按照用户得业务要求进行排列,使用户可以更快更好地输入数据.(6)进入系统以及退出系统时,如果程序执行比较耗时得代码,应该给出个提醒,而不能让用户傻等,最好放到线程中处理,不能让主线程出现假死状态.(7)用户登陆得窗口,应该自动帮用户记住用户名,用户可以自己确定就是否要记住密码。

(8)复杂得查询条件,错误提示之后,原来得输入就是否都还保存?如果都没有了,用户要再输入一遍会很烦。

(9)查询错误或无结果,必须有提示。

(10)下拉框中得数据必须有排序.(11)系统中得各种提示必须要合理,不能有误导用户得情况。

当然,还有许多需要注意得技术与非技术得细节问题,往往我们技术人员觉得不重要得东西偏偏就是用户觉得最重要得。

我相信,在软件开发得过程中,您只有琢磨您得用户就是怎么想得,您才能使我们得软件更加完美,付出得越多,得到得越多。

13、没有结果得结束.我们几乎听不到有人出来说项目失败了,我们听到得就是延期、暂停、取消等等形容词,但就是其实,我们其实应该承认,我们有做了一个失败得项目。

经验总结:我们花了钱,项目失败了,但至少应该买到教训.项目得成败就是变数多多,既有技术得,也有管理得,也有关系得,既有自身得,也有客户得,但就是只要我们把我们可以控制得做好了,至少这个项目成功了一半。

相关文档
最新文档