测试技术经过这么多年的发展,在大学已经有软件测试的专业,在很多年前就有软件测试研究方向。我读硕士研究生时的研究方向就是网络协议的一致性测试。在这里只是介绍测试职位在实际工作中的具体工作是什么。一个测试工程师的工作大致上是在完全理解软件的业务需求后根据每个功能点和它的分类;编写功能测试例,将测试例分组归类成测试套件。测试例是测试文档中最基础的组成部门,测试工程师根据测试例去测试软件,测试的软件是在经过开发部门单元测试后提交给测试部门用来做集成测试和系统测试。随后咱们介绍一下测试工作的种类:单元测试、集成测试、系统测试、回归测试、性能测试、安全测试。测试软件可以是人工操作通过鼠标点击键盘录入来实现,也可以编写测试脚本,或者在人工操作测试的过程中通过专业测试软件录制测试脚本,然后再手工修改部分代码,以后就可以自动执行测试,不用再手工测试。提高了测试效率和测试的准确性。因为一个软件的测试例在编写的时候软件业务需求、技术需求等文档基本都已定稿,所以测试文档确定以后是很少修改或变更。测试脚本或测试程序也变化不大,每次的回归测试如果都是手工测试那么工作量可想而知,回归测试一般都是由测试脚本来自动测试。因为编写的测试脚本最终运行后要给出测试结果,一般的测试结果分三类:通过、失败、未决。
关于测试的分类一般分为以下:单元测试、集成测试、系统测试、回归测试、性能测试、安全测试。单位测试一般有开发部门自己完成,主要测试自己编写的代码实现的功能、组件接口是否符合设计文档,输入输出是否正确。在完成单元测试后提交给测试部门。管理规范的公司或者通过CMM3级的组织都会有代码管理工具如StarTeam SourceSafe等。测试部门会在开发部门提交代码后下载最新版的代码,集中编译上传到测试环境中,进行集成测试。集成测试用来测试软件的各组成部分是否能按设计要求组合在一起实现预定的功能,做各模块联调测试,检查各模块的接口是否一致、各模块间的数据流和控制硫是否按照设计实现其功能、以及结果的正确性验证,可以是整个产品的集成测试,也可以是大模块的集成测试。集成测试之后就是系统测试:它是针对整个产品的全面测试,既包含各模块的验证性测试(验证前两个阶段测试的正确性)和功能性(产品提交个用户的功能)测试,又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。回归测试是当软件需求发生变化,程序代码也完成更新,这时要测试一下修改或新增的代码对已有未变化的功能是否有影响。防止修改了旧bug增加了新bug。或者增加了新功能原有的功能却不能用了!性能测试一般会测试软件并发用户数,响应时间,大数据的处理,长交易处理能力,宕机恢复能力等一般会使用LoadRunner。安全测试主要基于工具分析和扫描,检查是否存在危险如:注入攻击、拒绝服务、配置操纵、访问控制、日志伪造等等。
产品测试经理
属于测试工程师的老板或上级,具有丰富的产品测试经验和需求领悟能力。曾经的一个测试事故让我对产品测试经理的能力有了非常深的印象。有一次系统新增加了一项与之前功能相关且名称相似,测试工程师没有理解业务需求编写出来的测试例几乎没有覆盖新增加的功能,被产品测试经理检查出并纠正。敏锐的洞察力和良好的分析、研判能力来分析市场发展趋势,可以提出软件的发展或进步方向。把握用户需求,完成需求分析到测试转变,对产品设计的生机和改进要能提出关键的意见。负责或配合其他部门,持续改善产品。负责测试团队的日常管理工作。
测试类职位的特点
职位的重要性和地位在稳步上升,与开发类平分秋色。在前些年人们往往看不起测试职位,一方面它位于整个项目的下游,如果没有开发就没有测试,测试总是跟在开发后面。另一方面软件系统的复杂性和应用环境简单,测试在项目起的作用较小。但是这两方面随着开发技术的发展尤其测试驱动开发TDD,还有是人们对软件质量的关注使得测试逐渐和开发地位基本持平。我原来在的单位技术性的员工有100多,开发技术部的有40人,项目部30人,测试部30人。
且职业寿命在积累中逐渐增长类似医师。自动化测试、一致性测试、互操作测试等等技术的发展使测试工程师在工作中不断积累了经验,不像开发类的技术和工具都不断更新。而测试类的工程越来越值钱,越老对软件的理解越丰富。
在软件业技术是非常重要的,在从事技术类高级职位的工程师,不仅有非常好的技术,还能带领一支技术队伍,像导师一样帮助他们给于技术支持和指导,确定工作方法,指明工作方向,解决队伍在项目过程中遇到各种技术问题。同时还要具备领导能力。我在读研究生的时候老师让我给本科生带辅导,我对这样工作一点不重视,觉得不就是看着他们做实验出错的时候去给调试一下,但是我的老师很严肃的对我说:你要给别人一滴水,你自己要有一桶水,我有又了一句,如果你只有一滴水,你只会给别人一头雾水。
售后工程师和系统集成工程师:
都属于技术支持工程师,当客户把软件买下了,在使用的时候总会出现各种故障,不单是小软件公司的售后要经常跑到客户那去解决软件运行报错,安装故障,误操作错误,数据恢复等等问题。越是大公司它的售后技术支持力量越大,因为他们的软件承载的业务非常重要,一点异常或是错误都会给客户带来巨大的损失也会让自己在业内蒙受羞辱。售后工程师首先是要对自己负责的产品非常精通,熟悉每个组件的运行情况,产品的安装环境,客户的业务运行状态等等。在出现问题及时赶赴现场为客户解决故障,挽回损失。系统集成工程师的技术特点与售后工程师类似,在客户把软件买下后分析客户的业务需求完成产品的实施,最终满足客户的要求。
为什么将销售放在第一个讲,不仅是销售类的薪酬高、技术要求高,另一个原因是我的个人观点:软件业经过这么多年的发展,正在转变为传统行业,传统行业的一个特点是销售非常重要。
1、传统行业的特点2:8 ,20%的企业占有市场的80%份额,软件业的大公司逐渐分化分别控制不同行业的软件需求,如金碟、用友在国内财务软件类的巨头,东软则是医疗类软件巨头,数据库类的有ORACLE MySQL、 SQL SERVER、DB2分别属于ORACLE、MS、IBM公司三家公司的数据库产品几乎瓜分数据库产品的销售市场。在桌面操作系统类XP,VISTA,WIN7和Ubuntu RedHat 雪豹;服务器类的WebLogic、WebSphere、IIS、Glassfish;随着虚拟化,云计算技术的发展未来的软件业的格局可能会更加集中,将为客户提供更加专业的服务。
2、需求推动技术发展到技术引领需求发展的转变,在软件业的初期都是有这样那样的业务需求,比如图像处理、三D建模软件,都是有着很多的需求,哪个软件能率先满足这些需求,他的公司就能迅速发展。在大家的软件都实现了用户的需求时,哪个软件实现的效果好运行的稳定操作人性化那么它的公司就会淘汰那些不向前发展的公司。比如:netAnts flashGet xunLei 现在各家公司做软件都做得不错价钱也都公道,怎么才能让客户信赖自己的产品和公司呢,那就是引导客户的需求,这时就是技术引领需求发展了。比如现在的主数据、元数据管理,SOA等。
3、咨询服务在软件业的比重越来越大,IBM有很多业务都是咨询服务一份报告30页,一个月时间60万。软件业的售前活动非常像咨询服务,售前工程师通过拜访客户,与客户交谈了解业务情形和特点,发现并理解目前存在的问题,提出针对的解决方案,并将自己的解决方案与别的公司做技术和经济性的对比。
职业规划是对职业生涯乃至人生计划的过程,职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《软件业职位总结5 开发类[2]》内容,职场资讯网小编向您推荐一些职业规划知识,欢迎参考,希望能帮到你。
开发工程师
俗称程序员,流传一句话恭喜,你选择开发工程师做为自已的职业;悲哀,你选择开发工程师做为自已的职业。这句话真的是非常有意思,好的开发工程师,可能从写代码做起,掌握了丰富的开发技术(c,c#,java)很快的做到系统分析师,架构师,产品设计师,走向管理层作部门主管或是CIO。辛苦的工程师可能从c到c++,再到java,开发使用的工具也是经常变化。技术在不断进步,工程师也得不断学习,从COM,DCOM,COM+,.netRemoting,WebServices,WCF等等,总是跟着技术跑。在日常工作中也是废寝忘食,非常疲惫,而且还经常让测试人员呼来喊去,偶尔还会被老板教育。我曾经的一个同事做了7、8年开发,非常优秀有一次出差回来,发现他不在了,辞职走人,以为跳槽到大公司去了,后来同事告诉我他出去开了家陕西面馆。软件开发工程师有一般来分:.net、java。我本人做.net开发,属于微软阵营。本人不太喜欢讨论哪个阵营好哪个有前途,之所以没有做java一直在微软的.net阵营混,完全偶然,工作和项目上的需要。目前也没有计划去做java。但是会经常关注java的发展,了解一些新技术。
日常工作包括:
1、根据项目具体要求,承担开发任务,按计划完成任务目标。
2、独立完成软件系统及模块的编码。
3、负责编制与项目相关的技术文档。
4、配合系统分析人员完成软件系统及模块的需求调研与需求分析。
5、配合系统分析人员完成软件系统及模块的设计。
6、协助测试试人员完成软件系统及模块的测试。
一个公司内的开发工程师都会分等级,高级开发工程师、开发工程师、助理开发工程师。一个正常运行的软件公司不是那种从零开始的,都会有自己的技术积累、成熟的开发框架、公共开发组件。一般的工作都是在此基础做开展。新项目开发了,高级开发工程师可能分到的任务都是系统技术核心部分,如开发框架,公共代码,数据库设计,数据字典管理等;开发工程师会做一些一般功能的实现,比如系统中的几个模块;助理开发工程师等级较低,会在前辈的基础上使用公司的技术基础开发一些简单功能或模块,一般是照着前辈的代码抄。高级开发工程师为公司的技术打下坚实的基础,写一些公共组件和代码。或是应用新技术作些示范,教大家如何使用。开发工程师能够独立的完成自己的任务,提出一些好的想法。助理工程师会好好学习,融入到整体技术环境中。
开发工程师是系统最终实现的实施者,工作有很强的成就感。他掌握的开发技术很多,掌握数据库系统Oracle、MySql、MS SqlServer,基础开发语言C、C++,JAVA,C# ,系统建模语言UML,XML,开发环境VS、ECLIPSE、JDEVELOPER、NetBeans,服务器环境Win2003、Redhad、Unix等,应用服务环境IIS、Websphere、weblogic,开发框架。net framework、java容器、Hibernate、Spring,流行的实现技术设计模式、三层结构、COM+、webServices、WCF、WPF,SLIVELIGHT。实事求是的将说开发工程师是一种中间职业状态,原因很简单谁也不原意每天爬在键盘上废寝忘食狂敲代码。在项目经理的不断催促下赶进度,不断的接到测试工程师的错误报告,惭愧的说不小心做错了,马上改。偶尔还会和不懂事的客户纠缠如何操作。但是不是所有人都能突破开发工程师晋升到高级职位。但是反过来说开发工程师是系统实现的最直接的工程师,就像一个宏伟的建筑,设计者只是在纸上画画,但是需要施工方辛苦的劳作,最终拔地而起。可想在你的辛苦劳动下一点一滴完成的了这项工程,成就感是非常大的。而且在编写代码作开发的阶段会积累很多很多的经验,需要不断的学习新的技术,在有的时候高级职位还需要向你请教。所以另外一方面开发工程师可能是很多高级职位必须经历的过程,几乎所有的软件高级职位的招聘都有几年的开发工作经历,丰富的开发和实施经验才能使你在高级职位上,在系统还没有开发时,就能预见和分析出系统的技术需要等等问题,带领大家成功的完成任务。
高级项目经理
同他的名字,就是比项目经理更厉害的项目经理。有时高级项目经理是老板对跟随自己多年的老功臣的安慰,有时只是为了让薪水拉开距离,有时是只有高级项目经理去做大项目,也有的时候高级项目经理来管理项目经理,它是项目经理的老板。总之具体的工作还是那些只不过更高级了,就像有些人的职务前加个资深。我在公司做的就是高级架构师但是做的就是架构师的工作,给个高架的职位是老板对你安慰,而且他还不让你写代码,如果不做开发时间长了很多东西就会逐渐流失落后。
我们来说说项目管理类的职位会用到哪些工具,最基础的就是Word和Excel,不要小看这两样,他为项目管理提供了最基础的数据,每份统一了格式的文档,每份精心设计的Excel都是项目的重要成果,包括各个项目周报,个人周报等等。然后就是专门用于项目管理的软件如MS Project。软件生产是智力密集型的活动,其产品无物理外形,生产状态也不可见,因而难于检查和驾驭。如何管理项目的计划、调度、通信、费用估算、资源分配以及质量控制等。软件项目管理工具就是要使这种生产过程成为可见、可控的过程。使用它能帮助进行成本估算、作业调度和任务分配,并制定出成本较低、风险较小的项目开发计划;同时能设法在预计工期和经费之内适当调整项目的安排,以节省时间和人力,从而对软件生产的各个环节进行严格、科学的管理,使项目开发活动获得最佳的进程。 使用专业的项目管理工具不仅有效的帮助项目管理,而且它还能规范你的管理过程。
QA工程师
如果一个软件企业正在实施CMMI或者已经建立了研发管理体系都会在项目组中加入一名QA工程师。在我的工作经验中只有到达软件企业的公司,组织规模在300人以上,才可能去实施CMMI,就算去实施CMMI,最后也只不过是为了拿个CMMI的证书,QA工程师很多时候都是为了CMMI才存在的。不知道是咱们的软件公司不重视研发管理还是CMM和CMMI不适用于中国人。CMMI标准文件说,QA是高级经理的ears and eyes。研发人员眼中的QA往往也是警察,QA的作在于发现和报告项目的问题。一个合格的QA在项目中会充当三种角色:
角色1-老师,具备学习和培训的能力。
角色2-医生,通过度量数据对项目过程进行诊断,帮助分析原因,开处方。
角色3-警察,以企业流程为依据,但要告诉大家流程背后的原因;如果和项目组针对某些问题意见相左,可以直接汇报高层。
但在我的工作经验中却没有看到过这样的QA,虽然我的项目组也有为QA,但是主要为了实施CMMI而设置的,她是一位女性,不参与我们的讨论,只是默默地看着听着,然后回去写她的文档,只有在项目组研究去哪里吃饭庆祝阶段成果时就是看到她积极踊跃发言。
5.工程
最狭义的工程,是描述做什么和做到什么.
也就是说,是对目标的描述和成果的检测。至于这个工程目标的实现,是过程和方法的事;而有效、快速地实现过程和方法所需的,就是工具.
这种软件工程体系层次(SoftwareEngineeringArchitecturalLayers)被描述成一张图。
过程伴随工程而出现,解决的是工程中步调一致的协作问题。那么工程是因为什么而出现的?
很显然,软件规模的不断增大是导致软件工程出现的根本原因。所以你会看到在几年前,开发一个小工具可以不讲工程;或者现在在你的Word中,为了将半角替换成全角字符而写的那个宏,也不需要工程。
接下来,即使软件规模增大,如果有一个牛人中的超牛人,愿意用20年来写一个任意庞大和复杂的操作系统,他也是能做到的。然而现实中不会有软件公司给他这样的机会。
项目的复杂可能要求不同知识领域的角色参与,而庞大则要求更多(人力、技术与管理)资源。团队作为开发行为的模式,是软件规模和复杂度渐次累积的结果。
团队必将越来越庞大,因为(与工程对应的)软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程化、通晓方法理论、拥有大量工具的集团军面前一触即溃。
6.组织
工程理论其实是包含组织学的。然而我在上面的那张图中,将组织与工程分离开来,并在二者之间画下了一道纵向的线。
如果说工程关心的是需求、配置和文档等等这些要素,那么这样的工程还是停留在技术层面:关注的仍是工程实现细节,而非目标。从角色角度来看,这是项目经理和技术经理共同关注的那一部分。
然而项目经理还必须关注于人力资源、项目资金以及多个项目之间的协调等问题。这些问题与工程本身并没有直接关系,而是组织方面的内容。
所以在工程环节里,文档管理和配置管理等词汇中的那个管理,是管理的具体技术和方法;而在组织这个环节中的管理,才是真正的管理学上的用词。
在这张图上,我试图从这个角度上来说明:作为项目经理,你必须有一部分的工作是非技术性的。甚至,你可能绝大部分的工作是非技术性的。因为与技术相关的管理技能(需求、配置、过程管理等)可以由开发经理来做,或者公司对于这一方面有较统一且成熟的规范,因而无需投入过多的精力。
你必须更关注于对这个(或这些)工程的组织与计划。站在组织者这个角色上,你现在要考虑的内容可能会是:
为项目的各个阶段建立计划,并逐渐地细化计划内容,以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度;
确立项目或者产品阶段目标,成果的准确描述、定位,以及整个项目的质量目标及其考核办法;
对团队中的不同角色展开培训,以指导并协调角色间的工作,从而消除因为工作习惯的差异带来的影响;
为每一个人准备他所需要的资源,这不单单是把一套shareware变成正式版或者把512M内存变成2G,还包括准确地评估他的工作量,以及决定是否为他增加一个(能协同工作的)副手;
职业规划是对职业生涯乃至人生计划的过程,职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《IT行业的职业细分 软件研发和硬件研发[2]》内容,职场资讯网小编向您推荐一些职业规划知识,欢迎参考,希望能帮到你。
2、市场,这大约是最多的,往低里说,电脑城的谈单员,就是市场,往高里说,华为、Cisco的地区总裁,其实也是市场角色。市场根据个人经验,又分为Sales和Marketing,前者是简单的客户成交服务者,即客户准备购买,完成买卖手续,协助送货什么的,Dell那边的电话销售小姐,大约就是这个角色,由于Dell是定制,因此她们还需要下订单。后者就是属于较高层级的销售人员了,可以引导市场,引导客户,促成交易。
一般说来,市场其实也是个技术活,很少有朋友是天才,上来就可以做到Marketing的,都是从Sales先入手,慢慢练,这个过程,可能比一个程序员走到架构师还难,很多销售人员,做一辈子,都做不到Marketing的,不信,去商场看看售货员,公交车的售票员,都是Sales.
这里说说广告,广告我的理解,就是Marketing的一个分支,吸引眼球,吸引客户,促成交易。
我们经常说,每个行业都有英雄,其实市场中,Marketing就是英雄,一般说来,走到这一步,就可以站在这个行业的巅峰,出去讲课,拿最高的佣金,享受猎头挖角的快感等等。不过,很难的,有句话请大家注意,这个世界上,99%的销售人员,都不知道自己在干什么,说的就是这个问题,那1%才是Marketing.
通常情况下,开发人员瞧不起市场人员,总觉得对方是耍嘴皮子的,但市场人员同样也瞧不起开发人员,总觉得这帮书呆子不创造价值。呵呵,大家别生气,大多数公司,把研发单位,看做最大的成本单位,只花钱,不创造价值的,虽然我们设计了产品,但公司的财务上,这部分是没有价值的,产品价值是在销售出去以后才体现出来,因此,财务上看,研发部门总是赤字一片。
其实,真正厉害的市场人员,我们研发人员还是要尊重的,要知道,一个研发人员要成名成家,其实很容易,随便什么东西,攻克一个难点,出几篇论文,出一个产品,这个研发人员就可以在公司里面牛起来了,一个研究院,至少20%~30%都是这种牛人。但是,市场要能做到Marketing,前面说过,1%,可能都不到,你说这帮人算不算精英?
职业规划怎么写,相信很多朋友们对这个问题很感兴趣,下面给大家介绍一下。第一部分,前言即总论;第二部分,自我分析,包括业余爱好、性格、价值观、专业技能等;
二、 跨领域的强势竞争力。
信息科技瞬息万变,每个产业都变的越来越复杂,因此越来越需要专业分工,某种角度来说,每个人都需要花更多的时间与精力来加强自己的专业,要谈跨领域的能力,其实谈何容易。
但是请记住,就是因为很难,所以更值得去做。跨领域专长的培养也可直接反应在你的不可取代性上面。
三、 弹性再弹性,请让自己有最好的适应能力。
对于大部分工程师来说,这也会是个难题,然而却不可逃避。二十年前那个一份工作做到退休的美好时代已然远离,现在与未来迎接我们的,是一个信息平台不断变化,技术不断演进的时代,请记得随时保持你的弹性,乐于接收新的知识与观念。
对于生涯规划这件事情我其实抱持着非常怀疑的态度,人生其实怎么计划都比不上老天爷在背后给你来一刀阴的。不要抱着你现在所拥有的一切不放,要有心理准备,你所拥有的专业职能随时都可能被现实的职场一脚踢开,保持敏锐的观察力,并且拥抱变化。
一旦你察觉所懂得的专业即将被时代的潮流所淹没了,千万别怀疑,你不是在疑神疑鬼,赶紧学习新的专业技能。五年前复兴美工毕业的人也没想到五年后一个不是专科毕业的人也能靠书本以及网络来学习使用PhotoShop来跟他抢饭吃。大部分的工程师前一天晚上都还在网络上抓美女图,隔天就突然迸出个什么CMMI来要把他的工作变成工厂里生产线的一个配装员。
四、 全球化竞争,你的定位在哪里?
老实说,成也全球化,败也全球化。
如果不是网络的蓬勃发展,信息科技不会在短短几年内如此跃进,进而增加这么多就业机会来。然而,全球化到了一个极致后,信息从业人员要面对的除了日新月异的科技之外,还得与全世界的程序员竞争。
在这样的洪流中,不论是软件工程师还是其他产业的知识工作者皆然,我们都不可避免的要去思考自己在职场中的定位。BLOG、Skype、eBay这些东西在十年前都还不存在,当这些新东西出现时,势必造就了新的就业机会,相对的也必定剥夺了某些旧有的工作。
当我们面对如此竞争的职场时,要不断的思考自己的核心价值何在,找到自己对于工作的热情所在。再怎么不景气的产业都会有赚钱的公司与大鸣大放的成功者,再怎么热门的产业也会有经营不善关门大吉的公司与不求长进被请回家吃自己的员工。
只有找到自己的定位,才能立于不败之地,祝福大家。
职业规划怎么写,相信很多朋友们对这个问题很感兴趣,下面给大家介绍一下。第一部分,前言即总论;第二部分,自我分析,包括业余爱好、性格、价值观、专业技能等;
优秀的心理素质:
心理素质对一个项目经理太重要了。当然,如果你的心理素质很好,也许你不会感到这是什么问题。让我感觉,心理素质的一个重要表现是:面对重大的项目压力时,你的心理承受情况如何?
项目的压力来源很多,包括你的客户、你的领导,还有你的组员。你需要具有承受这种压力的巨大潜力,否则,你会手忙脚乱。
除此之外,心理素质还表现在你的思维、你的个性以及你的创新意识等等。想想吧,作为项目经理的你,太多需要承受了,太多需要思维了。
坚实的知识积累:
佛洛伊德著过《欲望决定命运》,我很喜欢。我暂时窃取一下,说知识决定命运,好像也挺有道理的。
中国是一个重视学历教育的国家,至少我的项目经理和程序员最低都是专科学历,事实是,绝大部分是本科学历。拥有了标志着知识的学历,我们有了选择的机会,确切的说,是被选择的机会。
我的项目经理在努力学习PM-BOK,我的程序员在努力学习各种编程技术。他们都在努力改变命运,我真的很佩服很喜欢他们。
知识决定命运,同样决定着项目经理的命运。坚实的知识积累,当然我更多指跟项目经理职业相关的知识,会成为你项目经理职业生涯的坚实后盾。
丰富的经验:
我们在招聘项目经理时,常常关注工作经验。那是因为我们常想把培养的成本抛给别人,但我更喜欢培养,我认为这样更符合中国人特有的人情味,而且更让人放心。凭什么辛辛苦苦跟你打拼之后,你却不给他发展机会,非要让他到别人那里找机会呢?
有丰富的经验注定重要,没有人会反对这一点。但我想说的是,如果你没有经验,不要气馁,谁生下来就做过项目经理呢。
更重要的是把握获取和积累经验的机会。一旦你有机会,不要轻易放弃,而要抓住机会,努力为自己积累经验。如果你恰好刚刚抓住这个机会,我建议你,仔细检查一下自己从事这一职业尚需修炼的内容。
领导能力:
我的老师曾经说过一句话经理需要领导,经理正在领导。我之所以没有彻底的问一问这句话的真正含义,我觉得自己来琢磨更有意思,而且随着时间越长,琢磨出来的意思越多。
我觉得意思应该是这样吧,项目经理需要领导能力,而作为项目经理也正在运用着领导能力从事领导工作。可见领导能力是项目经理必备的能力之一。
到底领导能力是什么?绝对不是管管人那么简单,我看过一本非常有趣的项目管理书籍《最后期限》(《The Deadline》),作者迪克马对管理描述的一段话很适合回答这个问题,大意如下。
项目经理做好领导工作,关键做好如下四件事情:1)选择正确的人;2)为他们分配正确的工作;3)保持他们的积极性;4)帮助团队凝聚起来并保持团队的凝聚力。
作为项目经理,能做好这四件事情,至少能保证你的领导能力有了不错的发挥。希望你与我一样,能细细体会。
人际沟通技巧对一个人有很大的影响,尤其是在工作场所。有良好的沟通技巧,你会有一个良好的人际关系,这样你就可以赢得同事的心,使你的工作更加顺利,并为晋升打下良好的基础。那么,如何改善办公室同事之间的关系呢?
职场老手教你搞好同事的关系
1.平等。无论你的职位如何,平等是和同事一起工作的第一步。在工作中,感到傲慢和优越是同事们的禁忌。
2.理解。同事们应该懂得宽容、体贴和关心同事,这样他们才能在需要帮助的时候伸出援手,帮助自己度过难关。
3.公平竞争。在工作中,每个人都应该相互学习,不要做损害同事利益的事情。面对晋升和加薪,我们必须开辟一些分散注意力的思想,不要专心工作,专心工作,与同事公平竞争。
4.不要做小圈子。与每个同事保持友好关系,不要以自我为中心,不要搞小圈子,这会影响你的沟通范围,不利于工作。只有学会与不同的人打交道,用真诚的心与他人交流,才能赢得他人的青睐。
5.微笑。世界上最美丽的人就是懂得微笑的人。在职场中更应该多向人展示灿烂的微笑。微笑会让人感觉很亲切,从而让同事关系更加亲和,这就事业发展可以起到很大帮助。
小编温馨提示:以上是如何做好同事相关知识,相信大家一定也有所了解了。一个和谐的同事关系将使你的职业生涯一步地提升,并对你自己的发展有很大的帮助。
职业规划就是对职业生涯乃至人生进行持续的系统的计划的过程。一个完整的职业规划由职业定位、目标设定和通道设计三个要素构成。
角色二:技术的把关者。
不过话说回来,并不是说CIO在软件选型的时候,一点反对或者赞成权利都没有。笔者认为CIO至少要在技术层面对软件选型进行把关。具体来说,对于以下内容CIO还是具有一票否定权的。
一是软件性能问题。若其他业务部门的负责人参与项目软件选型,主要的目的是让他们解决一些业务上的问题。而对于技术层面的内容,CIO还是需要把关的。如软件性能问题,就需要CIO把关。不同软件的实现方式与开发平台,甚至数据库的设计都会影响到应用程序的性能。而软件性能是否满足企业的需求,这个问题恐怕只有CIO能够给出一个结论。在遇到这些问题的时候,CIO就要好好使用手中的权力。如果换作是我,笔者就会对软件性能进行测试,特别是对于软件的并发性访问的性能进行测试。如笔者先会预测一下,企业在高峰时期,同时使用信息化管理软件的用户有多少。然后笔者就会召集同样的人数,来测试软件并发性访问的性能。看看这款信息化管理软件是否会随着访问人数的增加,性能成直线下降。如果并发性访问的性能无法满足企业需求的,则笔者会见决定投上自己的反对票。
二是软件对平台的支持问题。现在的信息化管理软件,对于其运行的平台也是蛮挑剔的。若神州数码的易飞ERP系统,只能够在微软2000以上的操作系统中进行。可是,CIO需要注意的一个问题是,在财务部门,可能还存在一些比较多的98操作系统。因为早期的增值税发票认证系统等官方的财务管理软件,是基于DOS版本的。而微软2000以上的操作系统,其内容不是基于DOS的,故无法运行。如果企业用有类似情况的,则CIO在选型的时候,就需要把好这一关卡。还有,现在不少企业中,可能不单单只有微软的操作系统。如笔者企业,现在就是微软、Linux、苹果等多种操作系统并存。在这种情况下,在软件选型过程中,就需要考虑,我们所选择的信息化管理软件能否运行在这些操作系统平台上。就拿笔者企业来说,一些应用软件服务器都是采用Linux操作系统,因为其稳定性与安全性要比微软服务器操作系统要高。所以,笔者在选型的时候,就比较关注,这款软件其服务器系统能否跑在Linux操作系统上。若不行的话,则笔者就会投上反对票。
等等。
对于以上这些技术层面的问题,笔者认为CIO应该充分行使自己的一票否决权。毕竟技术方面的内容,如对于跨平台操作系统的支持或者软件并发访问性能,是一些很难克服的矛盾。CIO此时就需要站出来,为技术层面的内容把关。而不能够在充当联络人的角色。
角色三:虚心学习者。
虽然说,CIO在选型过程中,若涉及到业务层面的内容,CIO没有决定权。但是,CIO仍然需要虚心学习业务层面的内容。
一方面,在后续软件管理中,需要用到业务层面的内容。CIO在项目上线后,还需要负责软件的排错、新员工的培训等工作。而这些工作的话,都要求CIO必须在了解企业业务逻辑的情况下才能够进行。若CIO对于软件所涉及到的业务一窍不通的话,则软件上上线后的工作都将无从做起。新员工的培训等工作都无从做起。
另一方面,CIO在项目管理中,另外一项任务就是对已经上线的信息化管理软件进行优化。在有必要的情况下,还需要把新上的信息化管理软件跟已有的管理软件进行集成。要完成这些任务,CIO若没有一点业务逻辑的基础,能够完成吗?答案当然是否定的。
所以,无论从什么层面说,CIO在项目过程中,都要努力学习软件所涉及到的业务逻辑。为后续软件优化、员工培训、系统集成等工作奠定业务基础。
通过以上的分析可以看出,CIO在软件选型上虽然有一定的话语权。但是,CIO不能够做看门人。而要把这个角色交给更具有权威的业务专家。毕竟在选型过程中,业务层面的需求比技术层面的需求重要的多。所以,此时CIO应该退居二线,做个联络人、做个求学者;最多就是对技术层面的关键内容把把关。在必要的情况时,也可以行使一下一票否决权(这只仅限于技术层面的内容)。总之一句话,不能够充当软件选型的看门人,即决策者。不然的话,无论是企业,还是CIO个人,都会承受比较大的风险。
以上《软件老手带新人的经验总结[2]》一文,由编辑精心撰写而成,希望对您的职业规划有所帮助,更多精彩请访问“有经验的求职面试技巧”专题!
相关文章
最新更新