亲身体验软件项目管理中的十大误区
软件开发中的十大常见错误及其解决方案
软件开发中的十大常见错误及其解决方案软件开发是一个复杂而繁琐的过程,即使经验丰富的开发人员也难免会犯错。
本文将详细介绍软件开发中的十大常见错误,并提供了相应的解决方案,以帮助开发人员更好地提高开发质量,避免这些错误。
错误一:不合理的项目管理在软件开发中,缺乏合理的项目管理容易导致进度延迟、质量下降等问题。
解决方案是建立详细的项目计划和进度表,明确任务分配和时间安排,并保持团队成员间的良好沟通和协作。
错误二:不完善的需求分析需求分析是软件开发的重要一环,不完善的需求分析导致功能不完备、用户不满意等问题。
解决方案是与客户充分沟通,明确需求并编写清晰详细的需求文档,同时采用敏捷开发的方法对需求进行迭代和调整。
错误三:代码质量低下代码质量低下会导致软件缺陷增多、性能下降等问题。
解决方案是提高开发人员的编程技能,制定严格的代码规范,并使用代码静态分析工具进行代码检查和优化。
错误四:缺乏测试测试是保证软件质量的关键环节,缺乏测试容易导致软件存在各种缺陷。
解决方案是建立完善的测试计划,包括单元测试、集成测试和系统测试,并使用自动化测试工具提高测试效率。
错误五:不合理的架构设计不合理的架构设计会导致软件难以扩展、维护困难等问题。
解决方案是在项目初期进行全面的架构设计,考虑到软件的可扩展性、可维护性和性能等方面,并遵循设计模式和最佳实践。
错误六:安全性问题安全性问题是现代软件开发中不可忽视的重要问题,缺乏安全设计容易导致信息泄露、恶意攻击等风险。
解决方案是采用安全开发的方法,进行安全性需求分析和威胁建模,并使用安全性测试工具进行漏洞扫描和安全代码审查。
错误七:性能问题性能问题是用户体验的重要方面,不良的性能会导致软件响应缓慢、卡顿等问题。
解决方案是在开发过程中关注性能问题,进行性能测试和优化,并合理选择数据结构、算法和编码方式。
错误八:不合理的代码复用代码复用是提高开发效率的重要手段,但不合理的代码复用会导致系统的耦合度增加、可维护性下降等问题。
项目管理的十大误区
项⽬管理的⼗⼤误区01误区⼀:项⽬管理⽐技术⼯作轻松很多如果把技术类⼯作⽐作⼀部风景纪录⽚,项⽬管理就会是⼀部惊悚⽚:- 新的⼀天⼀定会有新的惊喜(xia);- 每⼀段看似平坦的路途都会有数不尽的坑;- 好不容易淌过了雷区;。
锅从天来谅你是达康书记,也⽆话可讲。
02误区⼆:考取证书是项⽬管理⼯作的前提掌握项⽬管理的基础知识是开展项⽬管理的必要前提。
学习何必靠考证,⽹络就是⼀个好地⽅。
那么如何进⼊项⽬管理呢?建议按以下两步进⾏(切实可⾏,童叟⽆欺):- 主动承担举例⽽⾔,你可以在有余⼒时找项⽬经理,聊聊他的苦恼和难题,并主动请缨承担部分⼯作,久⽽久之,你会取得项⽬经理的倚赖,并开始承担越来越多的实际项⽬管理⼯作。
- 申请调岗在掌握了基础知识并获得了实际项⽬管理经验之后,你可以尝试向主管项⽬的领导提出调岗的请求。
助你成功的因素:-- 已有的努⼒和成效,-- 合作过的项⽬经理对你正⾯的评价。
请相信,你⼀定会被注意到的。
03误区三:制定⼀个周详的计划,然后严格地执⾏计划赶不上变化,⽽项⽬经理每天就⽣活在变化之中。
别问我为什么。
04误区四:项⽬经理⽆需关注项⽬执⾏的细节⽤⼀个真实的例⼦来说明吧。
有⼀个从事重⼯业的企业,他们的项⽬⼤量使⽤脚⼿架。
⼀直以来,按照市场价估算的脚⼿架预算总是不够。
可是,由于脚⼿架在项⽬造价中占⽐不⾼,项⽬经理们已经把脚⼿架超预算当作了⼀个⽆可避免的存在。
终于,有⼀个项⽬组在成本压⼒下,项⽬经理牵头开始详细核查项⽬开销,脚⼿架超⽀作为成本控制⽬标被列⼊了名单。
初步研究发现,现有的安装顺序造成脚⼿架的多次拆卸和重装,⽽每次的拆卸和重装都是⼀次新的计费。
最严重的区域,甚⾄出现了同⼀个组块拆卸和重装多达五次。
了解了问题的根源后,项⽬经理⽴即组织相应部门(计划部,⼯程部,采购部,建造部等)开展安装顺序的优化⼯作,⽬标定位在降低建造安装⼯作的总体成本。
在诸多努⼒之下,项⽬组最终实现了盈利。
项⽬经理需要具备项⽬的⼤局观,不应该沉浸在项⽬执⾏的细节中。
项目管理的十大误区
项目管理的十大误区项目管理的十大误区项目管理运用各种相关技能、方法与工具,为满足或超越项目有关各方对项目的要求与期望,所开展的各种计划、组织、领导、控制等方面的活动。
yjbys店铺下面为你整理了项目管理的十大误区,希望对你有所帮助。
1、鼓包现象“毯子底线是什么?”这是项目结束是经常问到的一个问题。
在项目中,主要的工作通常得到特别的关注,但是那些边缘的事却总是被忘记,或是推迟到“以后”再做。
在项目结束时,就会有好几堆(从毯子底下扫出来的事)需要处理。
我们将这种现象称为“鼓包现象”,因为项目组成员认为这种现象是,项目结束前,所有这些“额外的”工作就突然冒出来了。
症状任何人们认为“以后会做”、但是却不在计划内的事;增长的日志(问题、缺陷等);假定在项目最后才完成文档。
在大多数项目计划中,没有“以后”这个时间。
因此这些事要么取消了,要么在结束时疯狂的仓促完成。
2、缺少维护文档时常,项目工作紧张时,第一个去掉的就是文档工作。
有时即使项目有时间,也不会创建文档;或是创建了文档,却很少在项目进行过程中维护它。
症状产品与需求文档不符;技术文档过时,无法保证技术的延续;没有记述项目的决策及决策原因的文档;没有对变化的审计跟踪。
这确实是一个问题,因为文档是为项目服务的。
一旦项目结束了,将来的项目和维护这个项目的人员,都需要通过文档来了解项目创建了什么、为什么要创建它们,以及如何创建它们。
否则,它们就会像前人一样,落尽同样的陷阱—在这种情况下,“忽视文档中的历史的'人,注定要重蹈覆辙”。
3、源头不保证质量项目组成员并不总是认可“源头质量”的说法。
有时候他们会有这样的想法,即“别人会发现我那些错误”,而不是认为自己要对质量负责。
项目经理无法评审所有的工作,所以他们必须依赖其他项目组成员。
因此,项目组成员必须担负起责任,确保所有他们署名的工作,代表他们的最高水平。
症状没有评审,就交付了有错误的工作成果;不测试开发出的代码;不关注对工作成果的提交。
项目管理潜伏的12大雷区
项目管理潜伏的12大雷区在众多项目运营中,都存在着管理不善的问题。
这是许多IT 管理人员不可回避的棘手问题。
的确如此,即便采用项目管理软件监控项目流程,但在实际操作中,IT 项目的部署周期往往比原计划更长,从而致使项目成本的增加,甚至超过预算。
是什么导致项目逐渐偏离最初的部署?美国著名的网站调查访问了几十名IT 主管及项目管理人员,从中总结出了12条常见的项目管理误区,并提出了相应的解决方案以避免因为耗时过长而导致增加潜在成本的问题。
项目管理误区1:没有指派最适合的人管理最适合的项目技术解决方案供应商Force 3公司咨询服务&项目管理办公室副总裁Sudhir Verma 解释道,“最常见的资源分配模式是将大部分的精力主要投放在寻找适合的资源而非寻找适合的项目管理人员。
” 事实上,“挑选项目管理者往往考虑他(她)的时间档期,而非他(她)是否具备相应的技术技能”。
但值得注意的是,一个缺乏相关专业技能或者经验不足的项目管理者往往可以“扼杀”一个项目。
解决方案:物色最佳项目管理人选,此人需要通晓技术,技术技能应与项目需求相匹配。
项目管理误区2:不能为项目团队注入活力导致一个项目失败的原因往往是因为他们没有获得相关部门和相关工作人员的充分支持,没有充分调动相关部门和相关人员的积极性,从而令项目步履维艰。
为企业提供员工培训并指导如何有效沟通的管理咨询公司CEO,Bill Rosenthal 称:产生这种情况的原因为:“1)项目经理没有明确项目团队中每个人的角色;2)项目经理没有清晰阐述当项目圆满完成时每个人可获得的收益;3)项目经理没有清晰阐述如何评估个人对整体项目运作的贡献值。
4)项目经理没有使项目形成适当的紧迫感,他们通常认为项目将会进展的十分顺利”。
解决方案:项目经理在初始阶段就应将所有人召集到一起(务必确保非现场的工作人员通过先进的技术手段也可以一并加入会议中),做一次关于项目及其重要意义的演讲并激发起每一位员工的斗志。
软件测试过程中的10个误区
软件测试过程中的10个误区下面给出了一些关于软件测试的最常见的误区。
误区1:测试太贵了现实-有一种说法,在软件开发过程中为测试付出的代价很低,可能会导致以后的维护或修正需要支付更多费用。
早期测试在许多方面节省了时间和成本,但是在没有测试的情况下降低成本可能导致软件应用程序的不正确设计使得产品无用。
误区2:测试耗费时间现实-在SDLC阶段,测试从来不是一个耗时的过程。
并且,诊断和修复在测试期间发现的错误是一项耗时但富有成效的工作。
误区3:只测试了完全开发的产品现实-毫无疑问,测试取决于源代码,但审查需求和录制测试用例与开发的代码无关。
然而,作为开发生命周期模型的迭代或增量方法可以减少测试对完全开发的软件的依赖性。
误区4:完成测试是可能的现实-当客户或测试人员认为可以进行完整测试时,这成为一个问题。
所有路径都可能已经经过团队测试,但完全测试是不可能的。
在软件开发生命周期中,可能存在一些从未由测试团队或客户执行的场景,并且可能在项目部署完成后才会表现出来。
误区5:经过测试的软件无错误现实-这是客户、项目经理和团队管理者所信奉的一个非常普遍的误区。
没有人能够绝对肯定地声称软件应用程序100%无错误,即使具有出色测试技能的测试人员已经测试了应用。
误区6:错过的缺陷是由测试人员造成的现实-即使在执行测试之后,将仍然存在于应用程序中的错误归咎于测试人员也不是一种正确的方法。
这个误区涉及时间、成本和不同场景。
但是,测试策略也可能导致测试团队错过错误。
误区7:测试人员对产品质量负责现实-这是一个非常常见的误解,只有测试人员或测试团队才应对产品质量负责。
测试人员的职责包括帮助利益相关者识别错误,然后由他们决定是修复错误还是发布软件。
当时发布软件会给测试人员带来更大的压力,因为他们会因任何错误而受到指责。
误区8:应尽可能使用测试自动化来缩短时间现实-是的,测试自动化确实减少了测试时间,但在软件开发过程中无法随时启动测试自动化。
【项目管理知识】亲身体验软件项目管理中的十大误区
亲身体验软件项目管理中的十大误区随着计算机硬件水平的不断提高,计算机软件的规模和复杂度也随之增加。
计算机软件开发从“个人英雄”时代向团队时代迈进,计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。
这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法,完成思想观念上的转变。
在此分析了10个在现代项目管理中思想观念上容易陷入的误区,希望能够抛砖引玉,引发大家更多的思索和讨论。
误区1:在项目的需求分析阶段,开发方与客户方在各种的问题的基本轮廓上达成一致即可,具体细节可以在以后填充。
因为无论开始时有多么细致,以后对需求的修改几乎是必然的。
分析:这是一种非常危险的思想。
实际上许多软件项目失败的主要的原因就是需求阶段对问题的描述不够细致,导致后来预算超出或者时间进度达不到要求。
正确的做法是:在项目需求分析阶段,双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。
并且,在需求分析结束以后,双方还要建立可以直接联系的渠道,以尽早地对需求变动问题进行沟通。
(范围的核实和项目验收都要根据范围基准进行。
因此前期的范围说明书和范围的基线至关重要)误区2:软件项目的需求可以持续不断的改变,而且这些改变可很容易地被实现。
分析:的确,在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。
随着开发进度的推进,往往会有一些需求的改变。
而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。
不过,这并不表明“软件项目的需求可以持续不断的改变,而且这些改变可很容易地被实现”。
实践表明:随着开发进度的推进,实现软件需求更改所需要的代价呈指数形式增长。
假定在需求分析阶段实现需求更改需要花费1倍的代价;那么,在系统设计和编码阶段,需要花费1.5-6倍的代价;在系统测试阶段需要花费10-20倍的代价;在软件版本发布以后,甚至可能要花费60-100倍的代价。
14种常见的项目管理失误
1.缺乏适当的人员与技能影响:用人不当与资源分配失调是项目管理失误中最常见的一种现象。
一个项目能否圆满完成,人员与技能的配备占了主导因素。
用人不当的结果往往会导致项目无法继续执行,这样就算计划再好,也是纸上谈兵。
解决方案:IT与项目经理应全面了解及掌控技能与资源情况,包括对项目顾问、合约承包商和外包商的详细评估。
使用项目管理软件可以帮助项目经理充分掌握所有团队成员的技能与工作量分配。
在了解分工与职责后,IT与项目经理就可以决定如何在日常工作和项目中合理分配资源。
指派专门的资源经理来负责解决人员与资源的分配问题也是一个不错的主意。
2.缺乏富有经验的项目经理影响:如果没有一名经验丰富的项目经理掌舵,项目很可能会随着发展而失去控制。
解决方案:聘用一名符合项目要求,并拥有出色人际关系处理技巧的项目经理。
他应当有号召力,能够管理风险,并在团队成员和外部参与者之间起到协调作用。
此外,一名优秀的项目经理也应该具备相关技术的知识与技能。
3.没有遵循标准的项目管理流程影响:这是项目管理中的第二大常见失误。
缺乏合理的流程会抬高项目风险,加大项目失败的可能性,最终导致无法在限定的时间与预算内完成项目。
解决方案:制定良好的项目管理流程能助你提高项目效率,并及时捕捉到项目执行过程中的各种问题,控制风险。
4.流程太多太杂影响:过多的流程会让项目失去灵活性,继而影响参与者的积极性。
曾经有一家软件开发商告诉客户公司的项目经理,他们能够在不增加成本与工作量的基础上添加额外的功能,但项目经理却回绝了这一建议,因为他觉得公司用户并没有要求这一功能。
其实,只要不影响项目预算与计划进度,又征得用户的同意,多添加一些功能是利大于弊的。
解决方案:提高灵活性,与项目支持者及参与者积极沟通。
5.对项目变更缺乏追踪影响:要么预算超支,要么进度拖慢(或两者兼有)。
解决方案:建立正式的变更申请流程,任何项目范围内的变更(比如添加新功能)都应在变更文件上详细注明,并由项目最高主管审核批准。
项目管理十大风险点及措施
项目管理十大风险点及措施项目管理十大风险点及措施1. 范围定义不清范围定义不清是项目管理中常见的风险点之一。
在项目开始之初,如果没有明确定义项目的范围和目标,就会导致项目执行过程中的混乱和不确定性。
措施- 在项目计划阶段,确保项目范围得到明确定义。
明确项目的目标、可交付成果和关键利益相关方的需求。
- 建立一个明确的变更控制过程来管理项目范围的变化。
确保变更都经过审批,并评估其对项目成本、进度和质量的影响。
2. 不充分的沟通和沟通障碍良好的沟通在项目管理中是至关重要的。
缺乏沟通或沟通障碍会导致信息传递不畅,误解和冲突的发生。
措施- 建立一个有效的沟通计划,明确沟通的渠道、频率和内容。
确保信息准确传达给所有项目团队成员和利益相关方。
- 促进团队成员间的合作和沟通,鼓励他们提出问题和分享意见。
确保团队能够互相支持和协作。
3. 时间规划不合理项目时间规划不合理是导致项目延期的主要原因之一。
如果项目计划的时间安排不合理,就会给项目执行带来压力,并可能影响项目的质量。
措施- 在项目计划阶段,确保项目时间规划经过充分的评估和分析。
根据项目的复杂性和资源可用性,合理安排项目的里程碑和活动时间。
- 追踪项目的进展情况,及时发现项目进度偏差,并采取相应的措施来调整项目计划。
4. 不明确的角色和责任在项目执行过程中,如果项目团队成员的角色和责任不明确,就会导致项目进展缓慢,任务重叠或遗漏。
措施- 明确定义项目团队成员的角色和责任,并在项目启动时进行沟通和确认。
- 建立一个有效的沟通渠道,以确保团队成员之间的协作和信息共享。
定期进行项目团队会议,讨论项目进展和解决问题。
5. 缺乏资源资源缺乏是一个常见的项目管理风险。
如果项目缺乏足够的人力、物力或财力资源,就会影响项目进展和质量。
措施- 在项目规划阶段,识别项目所需的资源,并与相关利益相关方协商和确认资源的可用性。
- 在项目执行过程中,监测和控制项目资源的使用情况。
及时调整资源分配,以确保项目能够按计划进行。
计算机软件的十大易错点与常见问题解答
计算机软件的十大易错点与常见问题解答第一章:安装与配置1.1 安装时出现错误的解决方法在安装计算机软件时,可能会遇到各种错误信息,例如无法找到文件、系统不兼容等。
解决方法包括检查安装包是否完整、检查硬件和操作系统要求是否满足,并尝试以管理员权限运行安装程序。
1.2 配置问题的解决方法软件配置问题可能导致功能无法正常运行或性能下降。
解决方法包括检查配置文件是否正确、检查与其他软件的冲突以及查找相关的软件文档或社区来获取支持和建议。
第二章:性能与优化2.1 软件运行缓慢的原因和解决方法软件运行缓慢可能是由于硬件资源不足、程序设计不合理等原因造成的。
解决方法包括增加硬件配置、优化程序代码、使用专业的性能分析工具等。
2.2 内存泄漏与内存管理内存泄漏是指程序在使用完内存后未正确释放,导致内存占用量不断增长。
解决方法包括及时释放不再使用的内存、使用垃圾回收机制等。
第三章:数据管理与安全3.1 数据备份与恢复数据备份是保证数据安全的重要手段。
解决方法包括定期进行数据备份、选择合适的备份介质和方式、进行恢复测试等。
3.2 数据丢失的原因与防范措施数据丢失可能是由于硬件故障、误操作或恶意攻击等原因造成的。
解决方法包括定期进行数据备份、使用数据恢复工具、加强数据安全措施等。
第四章:网络与通信4.1 软件无法连接网络的原因与解决方法软件无法连接网络可能是由于网络设置不正确、防火墙阻止了连接等原因导致的。
解决方法包括检查网络设置、防火墙配置以及与网络管理员或软件开发者进行沟通等。
4.2 网络延迟与优化网络延迟可能导致软件响应缓慢或连接不稳定。
解决方法包括改进网络拓扑、增加带宽、使用压缩技术等来优化网络性能。
第五章:用户界面与交互设计5.1 用户界面设计原则与实践优秀的用户界面设计能提升软件易用性和用户体验。
解决方法包括关注用户需求、简化界面操作、进行用户测试和反馈等。
5.2 用户反馈与问题解答用户在使用软件时可能遇到各种问题和困惑。
浅析软件项目管理中的10个误区.doc
浅析软件项目管理中的10个误区:前程() 2009-12-2811:52:37 【前程:】随着计算机硬件水平的不断提高,计算机软件的规模和复杂度也随之增加。
计算机软件开发从"个人英雄"时代向团队时代迈进,计算机软件项目的管理也从"作坊式"管理向"软件工厂式"管理迈进。
这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法,完成思想观念上的转变。
笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区,希望能够抛砖引玉,引发大家的思索和讨论。
误区1:在项目的需求分析阶段,开发方与客户方在各种的问题的基本轮廓上达成一致即可,具体细节可以在以后填充。
因为无论开始时有多么细致,以后对需求的修改几乎是必然的。
分析:这是一种非常危险的思想。
实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致,导致后来预算超出或者时间进度达不到要求。
正确的做法是:在项目需求分析阶段,双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。
并且,在需求分析结束以后,双方还要建立可以直接联系的渠道,以尽早地对需求变动问题进行沟通。
误区2:软件项目的需求可以持续不断的改变,而且这些改变可很容易地被实现。
分析:的确,在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。
随着开发进度的推进,往往会有一些需求的改变。
而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。
不过,这并不表明"软件项目的需求可以持续不断的改变,而且这些改变可很容易地被实现"。
实践表明:随着开发进度的推进,实现软件需求更改所需要的代价呈指数形式增长。
假定在需求分析阶段实现需求更改需要花费1倍的代价;那么,在系统设计和编码阶段,需要花费1.5-6倍的代价;在系统测试阶段需要花费10-20倍的代价;在软件版本发布以后,甚至可能要花费60-100倍的代价。
项目管理常见的7个误区
项目管理常见的7个误区阻碍项目管理走向成熟的7大误区--《项目管理最佳实践方法》误区1:我们的最终目标是实施项目管理目标错了!最终目标是不断发展的项目管理系统和能够可靠地保证项目持续成功的流程。
成功地完成一两个项目并不代表之后的项目都会成功。
误区2:我们必须在特定的时间点之前,建立达到一定数量强制的表格、模板、指南和检查表体系。
标准错了!项目管理成熟度只能通过建立基于时间的成熟度指标,并使用评估工具进行衡量。
表格、模板、指南和检查表都是必需的,但数量如果太多,对项目管理成熟度没有帮助。
专注于整个组织中开发一套大家都接受并支持的项目管理体系方法,项目管理走向成熟的进程就会加快。
项目管理的成功必须基于组织行为,而不是基于流程。
误区3:我们需要购买项目管理软件来为走向成熟的进程加速。
途径错了!选择软件的目的必须是对项目和机构本身都有利,如通过效率、效能、标准化和一致性来降低成本。
任何人都可以购买成套软件来实施一点点项目管理,然而有效的项目管理系统和流程并不会就此产生。
项目管理软件不是:项目管理问题的灵丹妙药或快捷补丁;项目管理中人力因素的替代品;管理项目所需要的知识、技能和经验的替代品;人为决策过程的替代品。
误区4:我们必须一小步一小步地实现项目管理,用大家都能看得到的小型突破性项目。
方法错了!最好的方法是用大型项目作为突破性项目,如果大项目的管理是成功的,就说明同样的流程在小项目上也会奏效,而反过来就未必是这样的。
用大型项目作为突破性项目是存在风险的。
误区5:我们不需要对突破性项目的成果进行追踪和公开。
行为错了!只有强调项目管理在项目成功中的作用,才会令整个公司获益。
误区6:我们需要高级管理人员的支持。
基本正确!我们需要“看得见摸得着”的高层支持。
他们必须召开会议表明对项目管理的支持,并参加一系列项目团队会议。
他们必须对项目管理实施过程中出现的问题保持一种开放接受的态度。
误区7:我们需要项目管理课程来让员工成为PMP专家。
项目管理的常见误区
第1页共1页
发生变动。这是项目周期的一部分。而且在任何长期的项目中,你确实必须 为技术的改进和变化做好计划。
误区五:用项目完成的百分比和预算与实际结果的对比来测评。 这是学生们在项目管理课上所学到的传统的并且得到认可的方法。遗憾的 是,在系统项目中,即使这是可能的,也很难清楚地识别项目完成的百分比。 最能说明问题的变量就是人工时间。因此,预算就是一个预告性的指示器。 你可以通过评估未解决的问题和难题来更好地测评项目。 误区六:每个系统项目都是独特的。 这看起来是一个直率的表述。然而,如果你接受了,你就会倾向于孤立地 管理项目,并且不能从教训中学到什么。项目具有独特的属性,但是在新技 术的外表下,它们还是有很多共同之处。 误区七:投入项目上的人力,多多益善。 在某些业务项目上确实如此。但在系统项目管理中却很少是这样的。人们 的技能和知识是不能互换的。如果多一些人加入到系统项目中来,由于协调 不利和要培训人员以快速适应工作,通常会减慢项目的进度。
格式为 Word 版,下载可任意编辑
项目管理的常见误区
误区一:要成功,项目就需要专用的资源。 20 年以前这是正确的,但是现在情况则不同了。系统项目要求在整个项目 生命周期中,不同的人要具有不同的技能。对多数企业而言,要求大量的全 职人员把全部时间都专注于项目的整个过程,是不可能的。 误区二:项目经理必须拥有足够的自主权。 这种想法是基于这样的理念,即项目具有独立的特点,项目经理要对项目 全权负责。现在,这是不现实的。项目都是相互关联的,资源是共享的。甚 至项目经理也是在多个项目之间进行பைடு நூலகம்享和分配的。 误区三:项目成功的标志就是系统上线。 这是对成功的传统和狭隘的定义。这就是为什么许多系统人员认为项目是 成功的,而业务经理却认为项目是失败的原因。这是视角的问题。许多系统 人员认为当软件可以运行时,工作就结束了。但是,业务经理却认为当业务 过程由于系统运行而得到改进时,项目才算结束。尽管项目成本大部分花在 了系统上,但是收益却更多地体现在业务的变革和改进上。 误区四:项目成功依赖于清晰、稳定的需求。 传统的系统生命周期强调要正确地了解需求。如果这一步做到了,那么设 计和开发就非常容易成功了。因为它们是可以满足需求的。这在理论上是对 的,但是在实践中却很糟糕。业务经理可能直到他们看到些什么才知道需要 些什么。当他们见到并使用了系统和技术时,他们的需求才会自然出现并且
软件项目管理中的几个误区
软件项目管理中的几个误区随着现代企业管理理念与方式的不断跟进与更新,项目管理软件成为企业转型升级加速器的趋势愈发明显,随之计算机软件的规模和复杂度也相应增加。
软件开发从“个人英雄”时代向“团队时代”迈进,软件项目管理也从“作坊式”管理向“软件工厂式”管理不断迈进。
这就要求软件项目管理人员应该更深一步地理解与掌握现代软件工程的理论方法,完成思想观念上的转变。
个人结合工作实际在此分析几个在现代软件项目管理中容易陷入的思想观念误区,希望能够抛砖引玉,引发大家更多的思索和讨论。
误区一:在项目的需求分析阶段,开发方与客户方就需求方面的基本轮廓达成一致即可,具体细节以后再填充。
这种误区产生的主要原因是双方当事者认为无论项目开始时的需求工作做得有多么细致,以后对需求的变更是必然存在的。
其实,这是一种非常危险的思想。
实际上有很多软件项目最终失败的最主要的原因就是需求阶段对问题的描述不够细致,导致后来项目预算超支或者项目进度达不到要求。
个人认为正确的做法是:在项目需求分析阶段,双方必须尽可能全面地、细致地讨论项目的应用背景、功能要求、性能要求、操作要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。
并且,在需求分析结束以后,双方还要建立有效的沟通机制,就需求变动问题能够尽早地进行协调。
误区二:在公司人力资源紧张而引发开发进度滞后的情况下,可以聘请更多的程序员加入到开发团队中,通过增加人力资源来赶上进度。
笔者认为在“软件工厂式”项目管理时代,开发方应根据公司目前的软件项目管理水平慎重考虑此类做法。
如果新加入的“应急式”程序员对公司目前开展的软件开发项目有一定的行业了解,并且能够很快适应开发方的项目管理方式、软件开发风格、团队协作氛围,那么此类“新人”的加入对项目发展是有益的。
否则,可能会出现“帮倒忙”的不良现象。
因为有的程序员尽管其个人能力很强,但是为了使其与项目团队一起协同工作,不得不分出人手对其进行与项目相关的技术及业务培训,更要花大气力去引导其融入开发团队。
【推荐下载】软件项目管理中的易错点介绍
[键入文字]
软件项目管理中的易错点介绍
随着计算机硬件水平的不断提高,计算机软件的规模和复杂度也随之增加。
以下是为您提供的软件项目管理中的易错点。
软件项目管理中的易错点
计算机软件开发从个人英雄时代向团队时代迈进,计算机软件项目的管理也从作坊式管理向软件工厂式管理迈进。
这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法,完成思想观念上的转变。
笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区,希望能够抛砖引玉,引发大家更多的思索和讨论。
误区1:
在项目的需求分析阶段,开发方与客户方在各种的问题的基本轮廓上达成一致即可,具体细节可以在以后填充。
因为无论开始时有多么细致,以后对需求的修改几乎是必然的。
分析:这是一种非常危险的思想。
实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致,导致后来预算超出或者时间进度达不到要求。
正确的做法是:在项目需求分析阶段,双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。
并且,在需求分析结束以后,双方还要建立可以直接联
1。
软件开发项目管理中的“经典错误”
软件开发项目管理中的“经典错误”有一些低效率的管理实践操作仍被许多人采用,造成了完全可以预期的不好的结果,这些实践操作就被称为“经典错误”。
大多数“经典错误”都有一个具有诱惑力的外表。
你需要拯救一个落后于进度的项目吗?那就增加人手吧。
你想减少日程安排吗?那就把日程安排得更紧一些吧。
团队中的一个关键人物激怒了其余队员?那就在项目结束后炒他鱿鱼吧。
你有一个很紧急的项目要完成?那就把目前所有可用的人力资源召集起来开始工作吧,越快越好!开发者、管理人员和顾客通常会有很好的理由来解释自己的所作所为,所以这些“经典错误”的具有诱惑力的外表也是解释为什么会再三犯下这类错误的原因。
但是,由于“经典错误”已经发生过很多次了,因此它的结果是可以预期的,这些结果显然会和人们原来希望得到的结果不一致。
本章列举了36个“经典错误”,每个错误我本人至少见过一次,而且有许多是我自己也犯过的。
你会从案例分析3-1中识别出这些错误。
这些错误的共性在于,如果你想避免它们,那么你的软件项目就肯定不能开发得很快。
但如果你不去避免他们,你注定会开发得很慢。
如果有些错误看起来很熟悉,好像自己也犯过,不用担心,振作起来。
因为有许多人犯过相同的错误,而且一旦你了解了这些错误给你的开发速度所带来的影响,你就可以在制订计划的时候进行风险控制。
有些错误会在本书的相应章节中进行讨论,有些则不会进一步讨论。
为了便于查阅,这些“经典错误”被分类成了人员、过程、产品、技术等四个方面。
人员这里是一些与人员有关的经典错误。
#1:不确定的激励措施无数的调查研究表明,激励很可能是提高产品产量和质量的最有效的措施(Boehm 1981)。
在案例分析3-1中,在管理的实施中充斥着不确定的激励措施。
开头是一番虚情假意的激励性谈话,中间是要求员加班加点地工作,最后管理者去享受了一个长假,而员工却要在假期中继续工作,为的只是那些少得可怜的额外奖励。
#2:糟糕的人事管理在激励之后,对产品产量有巨大影响的不是由团队队员个人的能力决定就是由队员之间的关系所决定(Boehm 1981, Lakhanpal 1993)。
软件开发团队主管易犯的十个错误
软件开发团队主管易犯的十个错误本文是Roy Osherove在Skills Matter的一次发言,他介绍了团队领导经常会犯的十个错误,并提出了一些解决方案。
Roy首先提出几个团队领袖可能遇到的一些问题:1.我如何说服我的团队做某件事情?2.我该拿团队里的那个专门搞事的家伙怎么办?3.我该如何做一个团队领袖呢?4.我们为什么无法远离无谓的争吵(编者注: fighting fires 译为“救火”更合适)呢?5.我会不会失去朋友呢?6.…他说这些问题其实缠绕他多年,接下来他也逐一做出解答。
他正在写一本叫《开发团队领袖手记》的书,里面也涵盖这些方面的内容。
下面就来说说这十个错误:#1 没有认识到团队的成熟度这点是首要注意的地方,因为后面谈到的问题都是提及团队的成熟度。
Roy 说,可以从3个层面来评价一个灵活团队的成熟度。
1.混乱2.学习3.自我引导混乱一个混乱的团队就是哪都觉得很忙。
可能他们总是在救火,或一直都被要求在非常有限的时间做太多的事情。
但其实结果都一样:混乱。
没有人有任何时间变得有条理,没有人有任何时间学习新的知识,因为他们一直都在忙这忙那。
如果你问我的话,这个团队明显成熟度不高。
因为所有人,要么耗尽精力,要么感到沮丧,因为缺乏机会学习,而最终好的人都会离开。
但是,Roy说这种混乱其实非常常见,而我也很赞同。
如果你是在这么一个混乱的团队里当领袖,秘诀就是要正确的行动起来,你必须自信和强势。
当船快要沉的时候,你需要的是一个发号施令的领袖,而不是开会。
一个混乱的团队里的领袖,必须坚定立场,而且可能必须要和领导层说清楚,整个团队并不能把他们要求的所有的事情都完成。
这是一个艰难的角色。
他必须坚定的做出一些艰难的决定。
管理要做得对、做得好是一件很艰难的工作。
但为什么作为一个团队领袖,你必须自己做出这些艰难的决定,而不是和团队商讨呢?答案很简单,因为没有足够的时间。
通过你自己做出这些执行上的决定,你让你的团队得到一些喘息的余地,可能也就是这些余地让他们把手上的事做完。
软件项目管理存在问题
软件项目管理存在的主要问题
1.项目过程整体上重技术,轻管理。
2.项目计划做得不够细致,往往是为了做计划而做计划,在项目过程中,往往
是实际执行与计划有所不一致;而项目监控也比较难于执行。
3.对项目中的风险、问题往往认识不足;。
4.实际工作中会出现这种情形:项目都基本完成了,而业务需求还没有正式提
出。
5.也许用户是内部人员,用户对需求不太重视,项目经理、开发人员也存在怕
麻烦的心态,对于需求变更往往管理不严格,用户说改就改了。
6.有些项目是上线时间已经明确了,才再通知要实施,这些项目的工期往往比
较短,按照正常的开发过程,是无法预期交付上线的。
这种情况该如何处理比较妥当?
7.同一个人一般情况下手头上都有好几个项目,往往是哪个项目比较紧急,就
先做哪个项目,没有一个全盘的计划。
现有的项目过程:
八大阶段:立项、功能定义、设计、开发、测试、验收、上线、结项。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
亲身体验软件项目管理中的十大误区
随着计算机硬件水平的不断提高,计算机软件的规模和复杂度也随之增加。
计算机软件开发从“个人英雄”时代向团队时代迈进,计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。
这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法,完成思想观念上的转变。
笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区,希望能够抛砖引玉,引发大家更多的思索和讨论。
误区1:在项目的需求分析阶段,开发方与客户方在各种的问题的基本轮廓上达成一致即可,具体细节可以在以后填充。
因为无论开始时有多么细致,以后对需求的修改几乎是必然的。
分析:这是一种非常危险的思想。
实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致,导致后来预算超出或者时间进度达不到要求。
正确的做法是:在项目需求分析阶段,双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。
并且,在需求分析结束以后,双方还要建立可以直接联系的渠道,以尽早地对需求变动问题进行沟通。
(范围的核实和项目验收都要根据范围基准进行。
因此前期的范围说明书和范围的基线至关重要)
误区2:软件项目的需求可以持续不断的改变,而且这些改
变可很容易地被实现。
分析:的确,在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。
随着开发进度的推进,往往会有一些需求的改变。
而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。
不过,这并不表明“软件项目的需求可以持续不断的改变,而且这些改变可很容易地被实现”。
实践表明:随着开发进度的推进,实现软件需求更改所需要的代价呈指数形式增长。
假定在需求分析阶段实现需求更改需要花费1倍的代价;那么,在系统设计和编码阶段,需要花费1.5-6倍的代价;在系统测试阶段需要花费10-20倍的代价;在软件版本发布以后,甚至可能要花费60-100倍的代价。
由此可见,在项目开展过程中,软件需求的改变应当尽量早地提出。
这样才可能花费少,容易被实现。
(不应该称为误区了,现在估计谁都不会认为需求可以持续不断改变) 误区3:软件程序主要由代码组成,因此编码阶段是整个软件项目的最重要的阶段,应该给与大量的时间,并且集中主要的资源。
分析:与以前相比,由于软件的规模和复杂度的增加,以及半自动化软件代码开发平台的出现,现代软件项目管理的中心发生了转移——不是着重编码阶段,而是着重系统总体/详细设计阶段。
一般说来,在现代软件项目管理中各种资源的合理分配比例是:项目论证、风险评估阶段3% ,项目需求分析阶段8%,系统总体/详细设计阶段45%,编码阶段10%,系统测试阶段34%。
(这个跟软件项目的规模密切相关。
对于规模小于2万行代码的,或者说采用敏捷或快速开发的,或者说架构已经确定的改进型号项目,编码时间至少要占30%;而对于
源代码规模超过50万行的大型软件项目,重点则是在需求和系统设计上面,编码时间一般为10%)
误区4:为了便于代码的维护修改,在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。
分析:通常伪码的作用是对程序的算法流程进行描述,便于人们深入了解程序的功能和实现过程。
可见,在一定程度上伪码的确有利于对程序代码的维护和修改。
但是,我们知道为了保证项目文档和程序代码的一一对应关系,维护程序代码的时候同时需要对项目文档进行维护。
伪码和程序代码是非常接近的,对伪码进行维护的话,相当于进行了2倍的程序代码维护。
工作量是很大的。
所以切合实际的方式应该是对一般的程序文档做到程序流程图即可,对于涉及了较复杂算法的才需要伪码。
(应该深刻理解源代码就是设计的一些重点观点和思路,因此详细设计输出的代码模型一般是不抛弃的,编码人员可以直接在该代码模型基础上进行编码) 误区5:既然在项目人员配置中设置了专门的测试人员,那么软件所有的内部测试工作全部应该由测试人员完成。
分析:软件程序测试可以分为“白盒法”和“黑盒法”两种方式。
由于使用“白盒法”对测试人员各方面素质的种种要求,在进行程序测试时测试人员总是先使用“黑盒法”。
他们的工作方式往往是先对程序进行“黑盒法”测试;如果测试没有通过,不得已这才考虑对程序代码进行“白盒法”测试。
显然,这种对“白盒法”有意无意的“逃避”,对软件的可靠性和稳定性构成了威胁。
如何解决这个问题?一方面需要提高对测试人员的要求,另一方面也需要程序员完成部分的“白盒法”测试(实际
上,程序员往往也是进行“白盒法”测试的人选)。
(估计很少有人这样认为,所以不应该称为误区)
误区6:软件项目管理只是相关技术部门的事情,与公司其他部门无关。
分析:在竞争日益激烈的今天,软件项目规模大、复杂度高而且时间要求紧迫。
要想提高公司的软件项目管理水平,这就需要提高公司的整体参与意识,需要公司各个部门协同作战。
例如需要会计部门协助进行项目预算,财务管理和费用控制;需要研究部门(技术委员会)指派专家协助进行各种风险评估,提供技术指导;需要后勤部门提供各种保障。
(干系人管理很重要,同时CMMI强调的集成项目管理也说明了这一点)
误区7:在开发进度滞后的情况下,可以聘请更多的程序员加入到开发团队中,通过增加人力资源来赶上进度。
分析:在注重团队开发的时代,开发方应该根据目前的软件项目管理水平慎重考虑这个做法。
如果新加入的程序员对目前软件项目的应用行业有一定了解,并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围;那么“新人”的加入是有益的。
否则,可能会“好心好意做坏事”。
因为尽管其个人能力很高,但是为了使其与大家一起协同工作,开发团队不得不分出人手对其进行与项目有关的技术/业务培训,更重要的(也是难度的)是还要引导其融入团队。
这可能需要花费开发团队许多时间和精力,很有可能使项目进度更慢。
(可以辩证的看,组织的成熟度越高,复用越高,该方法才是可能的方法)
误区8:技术骨干应该成为项目的项目经理,项目经理一定是所
有项目成员中薪水的。
分析:在“软件作坊”时代,这是一种普遍使用而且效果不错的方法;而在“软件工厂”时代,这种方法却带来各种问题,有时甚至直接导致项目失败。
究其原因这主要是因为随着现代软件开发分工的细化,对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术的掌握程度,而是其组织、领导、协调开发团队的能力(当然,可以两者均突出)。
至于项目经理的薪水问题,这和定薪制度有很大关系。
通常,项目经理执行的是管理人员的薪酬体系,而其他人员执行的是技术人员的薪酬体系。
项目经理的薪水在项目成员中是比较高的,但不一定是的。
有时候,为了激励技术人员,项目中的技术骨干得到的酬劳比项目经理要高。
(这里跟工种无关,更相关的是效率和产出,但去很难推行)
误区9:只有项目经理以及部门主管才会关心项目整体进度,程序员只关心自己的开发进度。
分析:这是一种“官僚”的想法。
实际上程序员作为团队中的一员,他不仅仅是在打一份工,更重要的是在参与一件“作品”的创作。
在体味工作的辛苦的同时,程序员更重要的是要享受创作的快感。
项目经理不应该漠视程序员对“成就感”的追求,应该向每一个人详细描述最终“作品”将会如何美妙和令人兴奋,并且在到达最终目标的路上设立一系列的里程碑。
每当项目整体推进到一个里程碑的时候,项目经理应该把这个消息告诉每一位项目成员。
实际上,这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦,还可以激发大家更大的工作热情,提高工作效率。
误区10:为了保证项目继续,为了留住核心程序员,加薪吧。
分析:加薪可以说是很多企业在挽留程序员时所使用的常用方法。
这一招可能暂时奏效,不过往往是人留下来了,但副作用也来了——加薪的人未必见得多干活,没有加薪的人却开始消极怠工了。
其实,项目的进行过多地依赖程序员的个人技术是“作坊”时代沿袭下来的“陋习”。
既然IT行业人员的流动是无法控制的,现在项目的执行应该更加注重团体的力量,应该更多的考虑公司整体技术水平和核心技术能力。
例如形成公司自己的专家知识库,类/函数库,第三方控件库,拥有自主版权的开发平台等。
另外,实际上程序员萌生去意的原因很大程度上不是薪水,而是缺少激励和尊重。
这需要项目经理使用“老土”一点的办法,找适当的时机对程序员做一做思想工作,向其描述项目的美好未来,让其感受关心和尊重。
总之,要从多方面着手保证项目的顺利开展,而不是简单地加薪。
【。