计算机科学与技术专业学什么管理学好?
程序员做到管理层很难你如果想从编程开始,可以去做系统分析师和系统框架师专门搞技术 也算是技术上的管理层 而且工资很高再公司的威望也很高,因为你是技术上的老大。
每个公司的系统框架师比经理的工资高多了!比尔盖茨不就在首席CEO退下来 搞技术 有技术比刷嘴强多了 如果想做系统框架师 那你要学的就很多!计算机的一切知识 你必须都能熟练掌握。
软件项目管理要注意什么呢?
如何在所学的项目管理理论和实际项目实践中找到一条连接的纽带;软件项目管理的度如何把握;为什么项目协调中更多的是貌合神离;为什么自己觉得自己所管理的项目老是失败。
这一连串的问题引起了项目管理者的同感,笔者本人也曾经在项目管理中屡遭挫折,目前的项目管理中依然麻烦不断。
但是,作为一名软件项目管理者来说,在实施项目管理的过程中,笔者觉得在项目管理中,我们的大多数人常常在管理思维中留下一些空白,而这些空白正是我们公正、客观地评判和成功执行软件项目管理的必要途径。
空白1: 为效益而实施项目管理 为什么我们要实施项目管理,是为了提高项目的效益。
这里所指的项目的效益是一个综合性的指标,包括低风险、高产出等。
为此我们不难得出我们在实施项目管理应该掌握的度。
即:引入项目管理后所产生的效益减去项目管理的成本后必须大于未引入项目管理时的效益。
由于引入项目管理后所产生的效益与项目管理的复杂度(项目管理的成本)并非线性相关的,因此项目管理的复杂度必然存在一个最优值,这就是我们应该把握的度。
也许上面的说法比较抽象。
一个实际行之可效的判断项目管理的度规则就是:大家认可并且能够准确地理解和实施。
拿美国项目管理专家James P Lewis的话说就是 KISS原则(Keep it simple and stupid),拿物理学家爱因斯坦的话说就是:Keep it simple ut not too simple. 空白2: 考虑所处环境 任何系统都是建立在一个具体的系统环境中的,一般情况下受上一级系统影响最为显著,这是系统论的观点。
项目管理是企业管理的下属层次,因此在很大程度上项目管理的成功与否常常受企业管理的制度制约(比如说设备采购的批复等待会延误工期),这就是为什么常常会出现计划不如变化来的快的原因。
因为我们在制定计划时根本就没有考虑自身和客户双方的企业管理的环境,所以我们的计划在实施过程中会受到企业管理环境因素的影响。
我敢跟你打赌:在没有人事激励机制常常拖欠或故意克扣员工工资但获得CMM5认证的公司开发效率不会比一个没有实施项目管理的开发团队的效率高多少。
因为恶劣的公司人事制度扼杀了开发人员的天才和积极性。
因此,作为一个项目管理者,审视自身的项目所处的企业环境并做出准确的判断是非常有必要的。
缺少良好的项目环境,项目管理者的心血常常白费。
这往往是我们中的一些项目经理在不同的公司里项目管理表现大相径庭的原因。
此外,正是基于企业环境这样一个观点,目前美国PMI,日本ENAA等提出了项目管理成熟度模型(OPM3和P2M),改变了传统PMBOK的缺陷(忽略外部因素和自身的灵活性)。
有兴趣的项目管理者可以参看有关项目管理成熟度和企业管理方面(建议参看职业经理人方面)的资料。
空白3: 合理评判软件项目管理 我们总是把过多的项目失败归罪到项目经理的名头上。
他们的角色常常是替罪羊而不是领导者,他们拥有的更多的是责任而绝非职权。
实际上项目失败并非完全决定于项目管理,比如说信息系统过低的报价。
一个项目按时在预算范围内完成了而另外一个则没有按时完成,这不意味着第一个项目管理得比较好。
因为前者可能是项目时间和成本宽松的项目而后者根本就是不可能完成的项目。
前者项目管理的意义在于获得较高的项目效益而后者的意义在于避免更大的项目损失。
很可惜,充满了浮躁的软件企业没有诸如此类的意识,一些项目在未开始前注定就是失败的,项目经理们一上手便被扣以一责任人的镣铐。
因此,项目管理有无具体效果,需要合理地进行评判,单纯以出效益为上的观点未必有失偏颇。
空白4: 心理学的必要性 没有一个领域像软件项目管理中人的因素更为重要,在软件领域没有实现自动化之前,一切试图取代人的主要作用的机制都是收效甚微的。
人的行为是心智活动的表现。
开发人员的心理活动决定了其在开发的表现。
合适的压力能够勾起开发人员的成功欲望但是过大的压力却直接影响着项目参与者的身心健康。
特别是后者一直以来都未能引起软件开发界的重视。
很多人曾经有过不明不白的辞职经历,在没有学习《管理心理学》之前,笔者对这些人的"过激"行为有时想想都觉得奇怪。
作为一个软件项目管理者,不了解和掌握管理心理学,很难针对复杂多变的人的因素采取合理的应对措施,同时自身的心理健康也未必能够得到保证。
为此笔者建议有条件的软件企业,可以通过聘用心理顾问来处理员工的心理问题,以此缓和由于工作压力而导致的员工之间矛盾冲突和项目坍塌。
空白5: 尊重常识,系统性考虑问题 这个观点笔者在《软件项目管理原则谈》已经重申过。
就像不要指望人一秒钟跑二十米一样指望项目中有过多的奇迹出现。
可惜我们中的大多项目管理者在进行项目管理时依然实施"***"。
我们的管理者都知道自然规律不可违抗性,但是却很少有人意识到一些社会规律的不可违抗性。
他们总以为唯物的主观能动性能够替代实际,产生奇迹。
加班被认为是解决资源匮乏的唯一途径,通过开发人员"无上"的生产力来达成项目的成功。
很少有人会意识到加班造成的疲劳会再次使工作效率降低...
软件项目管理的成功法则有哪些呢?
1 平衡原则 在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了"做什么",定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义了项目的交付日期,质量定义了做出的系统好到什么程度,这四个要素之间是有制约平衡关系的。
如果需求范围很大,要在较少的资源投入下,很短的工期内,很高的质量要求来完成某个项目,那是不现实的,要么需要增加投资,要么工程延期;如果需求界定清楚了,资源固定了,对系统的质量要求很高,则可能需求延长工期。
对于上述四个要素之间的平衡关系最容易犯的一个错误,就是鼓吹"多快好省"四个字,"多快好省",多么理想的境界啊?需求越多越好,工期越短越好,质量越高越好,投入越少越好,这是用户最常用的口号。
“多”——需求越多越好吗? 软件系统实施的基本原则是"全局规划、分步实施、步步见效",需求可以多,但是需求一定要分优先级,要分清企业内的主要矛盾与次要矛盾,根据PARETO的“80-20原则”,企业中的80%的问题可以用20%的投资来解决,如果你要大而全,对不起,你那20%的次要问题是需要你花费80%的投资的!而这一点恰恰是很多软件用户所不能忍受的。
“快”——真能快起来吗? "快"是用户、软件开发商都希望的。
传统企业里强调资金的周转情况,软件企业里强调的是人员的周转情况,开发人员应尽快做完一个项目再做另外一个项目,通过快速的启动项目、结束项目来承担更多的项目,来获利。
但是"快"不是主观的拍脑袋定工期就可以完成的,工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。
软件毕竟需要一行代码一行代码的写出来,他的工作量是客观的,并非人有多大胆,地有多大产"式的精神鼓动就可以短期完成的。
“好”——什么是好软件? 软件系统的"好"字是最难定义、最难度量的。
"让用户满意"是最高目标,你可以做到,但是资金的投入与时间的投入用户能否接受? “省”——省到什么程度? "一分钱一分货",这是中国的俗话,他是符合价值规律的。
甲方希望少投入,乙方希望降低自己的生产成本,省到乙方仅能保本的时候,再省,乙方就亏损了。
正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现,否则系统的成功就失去了一块最坚实的理念基础。
企业实施IT系统的首要目标是要成功,而不是失败,企业可以容忍小的成功,但不一定容忍小的失败,所以需要真正理解上述四个要素的平衡关系,确保项目的成功。
2 高效原则 在需求、资源、工期、质量四个要素中,很多的项目决策者是将进度放在首位的,现在市场的竞争越来越激烈, "产品早上市一天,就早挣一天钱,挣的就比花的多,所以一定要多挣" ,基于这样一个理念,软件开发越来越追求开发效率,大家从技术、工具、管理上寻求更多更好的解决之道。
软件项目管理组的主要职责是什么呢?
软件项目管理的对象是软件工程项目。
它所涉及的范围覆盖了整个软件工程过程。
为使软件项目开发获得成功,关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数。
这种管理在技术工作开始之前就应开始,在软件从概念到实现的过程中继续进行,当软件工程过程最后结束时才终止软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。
而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则,方法,同时避免前人的失误。
软件项目管理的提出是在20世纪70年代中期的美国,当时美国国防部专门研究了软件开发不能按时提交,预算超支和质量达不到用户要求的原因,结果发现70%的项目是因为管理不善引起的,而非技术原因。
于是软件开发者开始逐渐重视起软件开发中的各项管理。
到了20世纪90年代中期,软件研发项目管理不善的问题仍然存在。
据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。
1995年,据统计,美国共取消了810亿美元的商业软件项目,其中31%的项目未做完就被取消,53%的软件项目进度通常要延长50%的时间,只有9%的软件项目能够及时交付并且费用也控制在预算之内。
软件项目管理和其他的项目管理相比有相当的特殊性。
首先,软件是纯知识产品,其开发进度和质量很难估计和度量,生产效率也难以预测和保证。
其次,软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。
Windows这样的操作系统有1500万行以上的代码,同时有数千个程序员在进行开发,项目经理都有上百个。
这样庞大的系统如果没有很好的管理,其软件质量是难以想象的。
软件项目管理的内容主要包括如下几个方面:人员的组织与管理,软件度量,软件项目计划,风险管理,软件质量保证,软件过程能力评估,软件配置管理等。
...
软件项目管理有哪些呢?
软件项目的目标不仅仅是进度目标和成本目标,更重要的就是质量目标,质量直接决定了软件产品能否生存已经后续的升级和维护等工作量。
这里只谈为了提高软件质量可能采取的各种活动,但前提仍然是我们在做项目计划的时候首先要根据需求确定质量目标和制定质量计划。
1.过程 要提高质量需要强调我们对产品质量的保证不是依靠的团队中一两个重要成员,而是我们有相应的过程和方法论来保证质量,保证产品质量的过程是可以持续的。
对于很多项目我们都不建议采用CMMI里面较为重量级的各种过程,但是对于产品质量提升有帮助的各种过程我们仍然需要去将其规范化和流程化。
与此相关的主要有规范类的文件,比如需求编写模板和规范,设计规范和模板,代码编写规范和模板,数据库设计的规范和模板,界面设计规范和模板,测试用例模板。
对于过程管理方面需要定义的主要有任务和工件的输入输出要求,配置管理和源代码管理,软件生命周期模型,缺陷跟踪和管理,问题和风险跟踪管理,变更管理。
2.培训 最重要的质量意识就是预防胜于检查,强调一次要事情做对,强调上游工序为下游提供合格的中间产出物,尽量减少各种缺陷的泄露。
很多时候质量问题并不复杂,更多是团队成员没有质量意识,没有负责任的工作态度。
提升质量最关键有两个方面,首先是我们都有意愿和意识来提升产品质量,其次是我们要有相应的能力和技能来保证产出物的质量。
第一点我们依靠的团队绩效规则的建立,团队建设,质量文化的组建形成,员工态度和责任感的培养等内容。
第二点我们强调的是培训,以师带徒,自我学习,个人知识管理方法,问题管理,学习型组织,读书会等各种方式来提升技能。
3.评审 评审是软件开发过程中保证质量的一个重要活动,项目软件开发往往会跟踪选择的软件生命周期模型分为多个阶段,对于较大点的项目还有严格的岗位角色划分,每个阶段都是不同的成员在进行工作。
因此如果各个阶段的产出物的质量不能够很好保证的话,将导致缺陷泄露和后续大量的返工,这些都是我们不希望看到的坏质量成本投入。
首先评审不是来检查产出物的各种低级错误的,每个人在思考问题上都有局限性和盲点。
评审是涉及到需求,设计,开发,测试等各种角色的成员共同来从不同的角度来发现工件的各种问题。
比如对于需求问题,测试人员在评审的时候重点关注的是该条需求描述和业务规则的可测试性,而设计和开发重点是可实现性。
评审涉及到正式同行评审,多人复审,单人复审,代码走查等各种方式,需要根据项目的实际情况来选择使用。
我们需要重点防止的就是需求和总体设计阶段的缺陷泄露,对于这种泄露往往都会造成大量的返工。
4.测试 测试是保证软件质量的最后一道关口,是一种迫不得已的行为,根据我们的质量意识应该要尽量做到问题不是到测试阶段才发现和暴露出来。
很多问题在测试阶段才发现返工成本都是很大的。
测试有单元测试,集成测试和系统测试,验收测试等各个阶段。
在某一个功能或模块在交付给测试人员进行测试的时候,开发人员应该根据需求和设计进行较为充分的自测。
这样的话系统测试的重点才能够真正去关注全流程的贯通和各种可能的业务场景组合和编辑,而不是关注某一个具体的实现功能点。
关于project项目管理软件
通常情况下大家讲的project就是项目管理软件,其中免费的.project管理软件用的人最多的就是微软的.project 2003或2007,这套软件主要侧重于进度管理,如果你是小范围应用的话,还是可以的。
但如果上升到一个公司全面应用时,微软的.project 就不够用了。
这时一般会使用付费的、功能全面些的项目管理软件了。
和谐万维项目管理软件采用B/S模式,应用起来非常方便,功能也全面,包含了项目立项、进度、问题、文档、材料、合同、财务、OA等与项目管理有关的模块,还提供免费试用,你可以了解一下。
...
软件项目管理的指导原则有哪些呢?
指导原则1-让项目中成员很好的搭配并各斯其职。
项目中的团队成员,具有不同的技能和经验积累,必须要能够正确识别并合理的安排他们的工作,让他们之间能够很好的互补。
关键词-技能评估,人员技能矩阵,角色岗位分工,关键资源,TOC约束理论,培训,以师带徒 指导原则2-提供一个学习环境。
确保项目中的每个人都可以在项目中进行学习,学习的方面可以是技术方面的,也可以是组织和管理方面的。
关键词-学习,培训,个人发展,技能提升,自适应团队 指导原则3-产生信任。
在团队中产生和培养信任,帮助团队成员间产生信任和信守承诺,互相尊重。
关键词-团队建设,沟通,信任,承诺,尊重,责任感,团队精神 指导原则4-允许团队成员有不同意见,并且提供一种方法以解决各种分歧。
关键词-头脑风暴,目标,冲突管理,开放,尊重,问题管理 指导原则5-做出很好组织和格式化的要求和请求,而不是简单的需求。
关键词-任务,承诺,5W+1H,问题定义,目标 指导原则6-经常和真诚的认可团队成员的成绩。
哪怕仅仅是一个谢谢。
关键词-马斯洛人的需求层次,团队激励,心理需求,沟通 指导原则7-过程首要指示是仅仅做那些能够为你的客户和干系人直接带来价值的活动和产出工件。
关键词-市场驱动,需求管理,客户价值,SIPOC,QFD,价值工程,客户满意度,质量 指导原则8-风险驱动的过程,确保你所做的活动和产生的中间工件都是为了最大限度的降低风险。
关键词-风险,危机,预测,风险驱动,全生命周期,风险意识 指导原则9-确保你的采用的过程是经过已经证明可行的实践,技术和原则。
关键词-方法论,最佳实践,原则,模式,经验,组织资产,成熟度,历史数据 指导原则10-对于每一个项目都要进行过程裁剪,不要假设过程的每一个特征都能够自动适应你所处的情况。
当你在配置过程的时候发现疑问或者不清楚是否该选择使用的时候,可以将它放到一般。
等后续项目特征清楚后再决定是否选用。
关键词-过程定义,生命周期模型,裁剪,项目特点 指导原则12-保证工具的选用能够很好的支持你选择的过程和项目中的成员。
关键词-工具,选择,效率,过程,生产率,人 指导原则13-工具有很多功能和特征,但是仅仅使用那些能够使你工作高效的特征。
关键词-学习成本,效率,过程,生产率,人 指导原则14-提供时间让团队成员能够学习工具的使用。
关键词-学习,培训,实践 指导原则15-在必要的情况下,可以开发你自己的工具,但必须考虑投入和收益情况。
【软件项目管理一般包含】项目管理都有哪些方法
《软件项目管理的内容》 软件项目管理的内容主要包括如下几个方面:人员的组织与管理,软件度量,软件项目计划,风险管理,软件质量保证,软件过程能力评估,软件配置管理等。
这几个方面都是贯穿、交织于整个软件开发过程中的,其中人员的组织与管理把注意力集中在项目组人员的构成、优化;软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值,包括过程度量和产品度量两个方面;软件项目计划主要包括工作量、成本、开发时间的估计,并根据估计值制定和调整项目组的工作;风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防;质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划,有组织的活动;软件过程能力评估是对软件开发能力的高低进行衡量;软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。
因为大家对人力资源管理和软件过程能力比较有兴趣,下面就详细的对这两方面展开讨论。
从软件工程的角度讲,软件开发主要分为六个阶段:需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。
不论是作坊式开发,还是团队协作开发,这六个阶段都是不可缺少的。
根据公司实际情况,公司在进行软件项目管理时,重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。
在20世纪80年代初,著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则,同样,在进行软件项目管理时,也应该遵循这七条原则。
它们是:1、用分阶段的生命周期计划严格管理;2、坚持进行阶段评审;3、实行严格的产品控制;4、采用现代程序设计技术;5、 结果应能够清楚地审查;6、开发小组地人员应该少而精;7、承认不断改进软件工程实践的必要性。
...