发布新日志

  • 项目管理-冲突管理

    abgg 发布于 2011-07-26 17:20:38

    冲突管理的五步法

      大家对刚才讲的有什么问题吗?可以随时提一下问题。那我们进入下一部分了,冲突管理的五步法,这是今天的一个重点。这个希望大家听清楚了,这五个方法对我个人工作真的是非常有帮助,但是不是强调大家每一次都要按照这五步来做,比如说那边有两个人在打架,都已经出人命了,你还要延续这样五步走可能就来不及了。也就是说你一定要做到灵活,这里面给大家讲的是从长计议。当你遇到冲突的时候怎么样可能会帮助到你,首先是时间上允许才能够采取这样的一步步的措施。

      第一步是听。听这里面我引用了中国的繁体字,是因为我觉得中国的文化是源远流长,在早期这种繁体字已经对听做了一个最深刻的一个抽象,大家可以理解,左边是一个耳朵的耳,然后是一个王,当你要去的听的时候你一定是带着一种对王者的尊敬感觉,你要用耳朵去听,但是你的心里应该是一种对他很尊敬的一种叫做聆听。我们要理解成在中国的古代大家对帝王都是非常的尊敬,帝王说的话你一定会非常小心谨慎,一定会字字都会记在心里。所以这个听左边这部分大家可以理解到听非常尊敬的听对方一些言词语句,在看右边的上半部分他是“十”、“目”,目就是眼睛,“十”不是一个具体的数字,并不是说我们有十双眼,它的意思是说你要全神贯注。你在听别人说话的时候不仅仅是用耳朵听,你还要用眼睛去观察,真的是要做到全神贯注。这个全神贯注的目的是发现在他的语言中没有表达的没有体现出来的其他一些东西。眼睛是心灵的窗口,他一定会在眼神中流露出来一些没有被语言所表达出来的内容,当你要想解决一个冲突的时候仅仅通过语言的沟通,或者他给你写一份报告你看一下这个报告你觉得就能解决这个冲突通常来说可能都不充分。你一定要观察,这个字的下半部分就是“心”,这个“心”上面还有一个“一”,就是一心一意,它其实又再一次强调你听的时候用到了你的五官还要用到你的心,用你的心调动你的五官,一心一意全神贯注去聆听,聆听这个词基本上概括了我们今天的第一步。你首先要想尽一切办法用你的心,你的耳,你的目,去搞清楚这个冲突的背景状态到底是什么。

      第二步就是想了。当你听完了放到我脑子里也理解所有的状态,但是你一定要有一个思考的过程,思考的过程实际上是避免我们作出一个过于片面的判断。我认识的很多领导人的确是这样的,大家觉得外企的白领很优秀,但是我可以告诉大家并不是每一个白领都很优秀,比如他助理告诉他我今天遇到一件什么事情太气人了,形象的来讲一下就冲出自己的办公室,跑到另外一个部门经理那里“你今天怎么样能够这样对待我的助理呢?这样我是不能接受的”。大家可以想一想,当你的助理来跟你抱怨一件事情的时候,我们要去想一个巴掌是拍不响的,如果他在抱怨,你一定要去听一下对方的。我工作上的一些领导管理人,也是多年管理经验的,这一点有时候我看真的是很可笑的。真的是一溜烟的冲出办公室跟人打架去了,但是其实最后可能都明白了,我今天弄错了,我还不了解具体的情况。但是这个很难看了,当你还没有了解,想清楚到底是什么样一个来龙去脉的时候,你就作出一个简单的判断,去告诉对方你不应该这样对待我的助理的时候其实是stupid。一定要想清楚,你一定要告诉自己,我听到那些信息以后我要给自己十分钟的时间我要去想,来龙去脉是什么,观点是什么,关键点在哪里,控制点在哪里。在这里给大家罗列了一些,其实这都是一些启发性的建议,你可以把你的收集到的信息做一些归纳整理在你的大脑里。

      第三步是辩。辩证分析,我觉得学过马克思主义的都应该知道,这个世界上不存在绝对的正确也不存在绝对的错误,永远都是一个辩证的关系。作为项目经理当你遇到冲突的时候一定要辩证分析,这个其实还是思的一个延续,我们要去辩证看待这个问题,我怎么样能够确保我将来作出的一个反应,对这个冲突的一个处理的行动计划是正确的或者说是影响最小的。这个时候你要评估我可能的几种方案,哪种方案是最有利于这个事情的解决。

      第四步就是调。这个调我是借鉴了中医的调理的调。虽然我现在医药行业,其实我并不特别欣赏西医的观念,西医的观念是把人拆分成零件来看的,这个人健康不健康,他是看他的心脏是健康的,他的血样的健康,他的胰岛素正常分泌了,他的肝功能是正常的这个让就叫健康的。但是实际上中医的理论绝对不是这样看的,他是把人作为一个整体来看,这个人也许没有任何临床性的症状,但是中医可能会告诉他这个人可能是不健康的,他会去全面的辩证看这个人到底健康在哪里。今天的医学理论还加入了心理健康,在你物理上气血上都是健康的状态下还要看这个人的心理是不是健康的。中医这种非常综合的方面看人,我们在解决冲突的时候也借鉴了中医的理念,我们要看冲突两方,一定要把他综合到一起去看,我们要结合中医的调理的概念,而不是说像西医说肺部上有一块阴影我给你切掉一块肺好了,肝脏上有一块囊肿我给你再切掉肝脏一部分,这个其实不解决问题。机体能产生这个囊肿,说明他具备这个外在条件,你只是局部的把他切除掉,短暂的来看是解决了问题,但他外在的环境没有变,他在未来某一天,条件成熟的时候这些囊肿阴影还会再现。也就是为什么有些癌症的患者你仅仅通过化疗、手术最后其实没有效果,原因在于他的外在环境没有改变。一个很简单的例子告诉大家,在国外有很多被医生宣判为死刑的人,比如说只有三个月的生命期,你随便该吃什么,该玩什么玩什么,这个时候有的人真的是绝望了,但是有一些想的开的人说我还有这么多资产怎么办?变卖资产然后我周游世界,但是三个月过去了没有事,六个月过去了也没有事,甚至好几年过去了也没有事,然后再去复查的时候就什么事情都没有了。原因就是说这个人他在的肝癌晚期的时候,原因是他在一个高强度的压力的环境下工作,当他把这个环境摆脱了以后,他其实已经从根本上摆脱了一个特定的有害环境,人体其实有一个自我免疫的功能,他被激发出来以后其实能够将他待会一个健康的障碍。目前来讲只是有一部分会这样,并不是每一个患者都这样。

      我们这里想告诉大家的是,我们在做调解处理冲突的时候,一定要用一个标本兼治的方法,不要简单说今天你的错我把你治理一下,我惩罚你一下,你交出一个罚金就可以了。这个其实并没有做到根本处理,因为他在未来这种在情绪上的不稳定的原因根本没有找到,这种冲突解决起来在简单的层面上。我们要看透彻,矛盾焦点到底在哪里,是因为管理机制的问题,还是说是因为比如说知识结构甚至是企业文化都可能造成这个。如果有可能去变更或者做一些调整适应,我们尽量去选择这些标本兼治的解决方案。

      最后一个是馈。馈这个意思就是反馈,我这里提示大家不要只看到正反馈其实也有负反馈。反馈其实是两方面的,当你处理完一个冲突以后一定要再去看一下,这个冲突是不是真的被解决了,如果是真的被解决了,我也要总结一下在这个冲突解决过程中我学到了什么了,或者我可以借鉴什么,未来在遇到类似的冲突时候你可能会处理起来驾轻就熟。也还有你要看,冲突短暂的被解决了,但是还有一些不完美的地方,持续改进也是需要的,他其实是一个巩固的过程。负反馈就是说你这个冲突之前都是做的很完善,但是有可能并没有起到作用,冲突两方表面看解决掉了,但是当你观察一下,那个冲突的根本没有解决掉,矛盾还在那里,双方还在相互抵制,这个时候我们就可以知道之前的方案是不正确的,我们应该返回到第一步,再去聆听一下到底是哪些信息遗留掉了。这个是负反馈的过程,负反馈也非常重要,我发现很多我的同事朋友他自以为我把矛盾解决掉了,过了两个月以后说怎么承包方还再说这个事情,一直没完没了的。然后我就告诉他其实这个事情一直没有解决掉。

      下面给大家大概讲一些简单的技巧,其实相信大家作为一个成年人,怎么样处理冲突都是有一些技巧的,这里只是给大家一些启发,从项目管理的角度来说我们会有一些建议,你再处理的时候可以借鉴。我想强调的最后一条是和解,和解实际上也是一个办法,在你没有办法找到一个解决方案的时候,相互妥协的确是一个最后没有办法的办法。达成和解就像哥们意气那种喝一杯酒尽释前嫌,这也是很有帮助的方法,大家不要忽略了和解这一步。我们回到前面那个案例,前面案例大家回顾一下,项目经理是A,他是QC实验室的一个负责人,项目B,经理是小白他是要引进一个QC设备,他们之间有些相关度,矛盾的焦点就说QC设备必须整体移进实验室,但是所有的门尺寸都做小了,现在其实变更已经不可避免,由此产生的额外费用谁来负担,公司如果要求总结经验教训,怎么样进行相对更好一点。如果A、B项目组开始互相指责对方的时候应该怎么样处理。

      我们第一步就是听,这个我在表述case的时候大家已经听明白了,大家主要的矛盾就是这些,来龙去脉简单的讲就是没有及时沟通。我们想一下,外因是信息滞后,设备都要快移进QC实验室的时候才提出需求,这样的话A是绝对不可以接受的。内因是项目范围不太清晰,要买一台QC设备,是一台什么样的QC设备,多大尺寸,是不是有这种要求,一开始没有明确的定义它。这两个项目之间需要一个沟通,相对来说如果B项目能够及时告诉A项目,我的设备必须整体搬进实验室,也许A项目在没有完全竣工的情况下可能做一些大门的变更。

      这个冲突的影响直接范围是这两个项目,它间接影响到新设备的供应商,实验室的工程承包商,XYZ公司在经济上受到损失。初步的趋势现状就是两个项目经理在互相指责对方,没有人愿意承担责任。最好的结果大家可以达成和解,和解以后项目继续,最坏的结果僵持不下,工期可能被拖延,因为牵扯到承包商,承包商不可能无限期支持你的工程,他一定会根据时间来要你的费用,这个时候可能双方会有一些付款上的纠纷。可能最坏的情形是到法院打官司。但是怎么样解决这些事情。第三步就进入辩证的状态,我们想哪些方法行之有效影响最小,会是各个受影响的方面都可以接受的状态。

      给大家一个简单的思路,首先看可能的解决方案是什么,效果怎么样然后评估一下。然后我会把解决方案排列一个优先级,一二三四哪一个是我最优先选择的,然后把范围比如我只考虑前三个解决方案,范围缩小以后我还会再做一次评估,这些真正会减少这些影响吗?再做方案的确定,之后还做一些风险分析,因为我采取这些措施,可能还会牵带着引入新的风险,或者新的冲突,在这里我要做一个充分的论证,是不是完全可以将影响降低到最小。当这些都想清楚了以后,或者跟你的团队论证过以后,把你的最佳方案拿出来,后边是实施。

      实施方案就是及时的调解,寻求双方都可能接受的短期方案,这里A和B的项目经理的确像我们之前讨论的那样,他们其实是通过一个充分的沟通,共同与公司的高层进行沟通,争取尽快获批这个项目变更。因为项目变更有一个变更流程,通常一个变更流程都有一个审批时间,这个时间拖的越长,影响会越大,在这里双方一定要达成共识,他们其实站在同一样的战壕,不管是谁的责任影响到两个项目,最终两个人的业绩都会受到影响。这个时候只能是并肩作战然后争取到高层的理解、支持,将变更尽快的拿下来。变更被批准以后,就可以改造门,其实不是一个很复杂的东西,我们只是做一个意思来说,再去更新一些设计的文件,然后从新验证。医药企业的QC实验室的验证是相对比较复杂的过程,因为他牵扯到无菌温湿度的要求,实际上两个项目中间经历了很长的时间。最后就是标本兼治了,因为我不仅仅是解决了一个眼前的矛盾,还要看中长期这双方项目经理A、B两个项目组是不是还会有这种互相紧张的状态,两个项目经理人应该主动和对方沟通一下,去看一看我们可不可以通过这个事情做一个总结,以避免将来还产生类似的情况。但是这个项目可能在这个门改完以后就结束了,如果这个项目还在进行中就可以避免类似的冲突在未来发生。持续改进行动计划是不是有必要,当门改造完了,设备进入到QC实验室的时候,有可能影响到温湿度的状态的变化,甚至有可能影响到无菌的状态,影响到项目A的最终验收合格,所以说双方还是要做一些充分的沟通,在每一步行动计划要充分考虑到对各方面的影响。

      有效沟通和团队建设,强调团队建设也很重要。在我的项目管理经验中,如果能干系人或者说利益相关人能够坐到一起,能够经常吃吃饭、聊聊天在一个很放松的气氛互相了解沟通,甚至是一种有益的状态建立起来,这样对项目实施过程的阻力是最小的。团队建设中,我想强调的是,在调理这方面随时都可以用,没有冲突的时候可以去防患于未然,当大家的关系都非常好的时候,冲突可能影响到最小。举个例子说,我愿意做一件事情,我可以找到一百个理由做这个事情,我不愿意做一件事情,我也同样可以找出一百个理由不做这件事情。意思就是当你的合作方跟你关系很好的时候,他愿意配合你,这个事情他一定可以找出一百个理由甚至更多来支持你,但是如果他不愿意配合你,他也同样能找出所有的理由来反对你,不支持你。平常把关系做好了,实际是项目经理应该做的一个很重要的事情。

      后面就是反馈了,这个我之前讲过了,最后如果行不通怎么办?马上就要调整,馈这个环节是尽可能使项目经理得到提升的关键地方。在过去大概五年的时间,我管了几十个项目,我认识的很多项目经理告诉我,他们的管理能力成长并不与与他做的项目数量成正比的。因为每做完一个项目,他都会在最快的时间去加入另外一个项目,几乎没有做过任何整理。我这里想讲的是,经验教训总结不仅仅是说你的教训,包括一些积极的东西,善于把他总结出来,是对自己和对项目管团队的负责任的工作,这个对公司的知识库的建立也非常有用。只有善于总结,我们才能够成长。不要惧怕冲突,不管冲突发生的时候解决了还是没有解决,适时做总结就一定会有提高。

  • 项目管理中的冲突管理

    abgg 发布于 2011-07-26 17:41:03

    项目中的冲突管理

      首先大家可以看到项目管理的组织和理念其实是经济高速发展的必然结果。也就是说,你要往前倒退200以前,其实是不存在项目管理这样一个知识体系的,即使在中国有那么大的兵马俑的工程,有那么大的长城,但是在那个时间是绝对不会有人提出来这个叫做项目管理的。那个时间会有很优秀的管理人,他会有天然的理念,他会把理念融入到真正的管理过程中,在那个时候项目管理概念远远不会像今天这么成熟。既然是一个经济高速发展的必然结果,它也会反过头来促进经济的高速发展。其实大家可以看到,中国目前其实对项目管理的重视程度已经达到了一个相对比较成熟的状态,在今天我接触到我的同行的时候我基本上不用跟他讲你一定要考一下PMP,考虑一下你有没有机会拿到PMP证书。他们其实会很自然的问到你,PMP帮我做什么,这个时间我都不用去跟他介绍PMP为什么是必须的,因为他已经从心底里接受了它。因为这的确可以帮助他在做实践工作的时候带来很大的便利。

      大家可以想没有项目管理奥运会是不是可以在短期内成功的,或者说是绝对不可能成功的。我接触到几个同行在奥组委里面做大项目管理,我很羡慕他们,因为相对来说北京奥运会可能是一个前无古人后无来者的项目,这个任务是有史以来最大的一个。也许以后还有更大的项目但是能在有生之年能遇到这样一个项目真的是让人很羡慕的事情,所以我也和他们做了一些交流,他们给我的一个反馈是假使没有项目管理知识,那么一切都无从谈起。包括上海世博会,大家也知道世博会刚刚结束,世博会相对来说在目前的一个管理水平上还是很先进很成功的盛会。它也一样会带给我们一些反思,在哪些方面可以有一些改进呢?实际上这种经验教训总结也是项目的很重要的一个部分。中国的高速铁路网在2008年金融危机爆发之后可能成为中国经济拉动的主要引擎,这个项目之大,到目前为止我也没有看到它的上限,这个高速网还在不断的扩张。我们已经体会到它的好处,也就是今天我从天津来到北京在火车上只花费了30分钟,如果没有中国高速铁路网这个项目中国的经济可能会受到很大的影响,我相信这个项目的提出适应了经济危机的背景,中国是最先摆脱经济危机困扰的国家,我觉得现在国家领导层是非常的聪明,甚至理念是超过其他先进发达国家的。所以我认为项目管理已经被我们国家领导人所接受,在这里我就不再强调它的一些重要性了。

      包括3G网络、包括全国的二氧化碳减排等等,其他很多都是非常大的项目管理。实际上落实到我们每一个人,其实我们每一个人的工作都可以看成是一些大项目或者小项目的管理,所以后边我们可能会介绍到项目中的冲突,冲突在沟通中不可避免,怎么样处理好冲突,这也是我们今天想跟大家一起分享的话题。

      PMP和PMI的一个现状我想主持人都已经介绍很多我也不在很多的解说。其实PMP证书已经成为项目管理专业人士的一个必须,这个大家有问题或者想跟我分享的话会后都可以跟大家有一个交流。现在进入今天的一个主要部分,就是项目中的冲突管理。其实一开始先给大家介绍一个案例,这是一个真实的案例。

      项目A:

      项目经理:小金

      项目范围:XYZ公司新建QC实验室

      项目B:

      项目经理:小白

      项目范围:引进一种新型的QC设备

      这两个项目之间在字面上看有一定的依赖关系,就是说A作为一个建筑物有设计图,设计图依据怎样的需求做这个设计,其实它的需求来自B项目。B项目会告诉他我的QC设备大概是一个什么样的设备,我需要一些什么样的设施,大概面积有多大,体积有多大,有什么样的噪音,会有什么温度湿度的要求。基于这样B项目提出的一些明确需求,A可以完成他的设计图。A的准时竣工和验收又同时限制到B的顺利实施,因为B作为一种新型的设备是要放到QC实验室里,如果说A延期了他意味着B也要被迫延期,由于他是进口设备,在和进口商谈判的时候供货期都是固定的,供货商一定会在他承诺的供货期将货物送达到你的单位,但是如果具体的厂房都没有建完,怎么把它放进去呢?所以说还会有一些额外的负担产生。他有其他更多的一些依赖关系,主要的依赖关系就是这两条。

      公司对于项目的考核主要是进度成本和质量。矛盾在哪里产生的呢?矛盾就是在QC实验室即将竣工时,小白指出了由于新设备为高精密的进口设备,这个设备体积非常大,但是由于他是高精密的,被校准过了,进入中国以后就不希望再把它拆成零件再搬进去,所以他要求整体搬进实验室。这个要求按理说正常的话在设施图没有确定之前或者在施工的早期提出可能还来得及改变,但是如果说这个实验室都已经要交付了,这个时候很多东西都已经固定下来,基本上都已经成型了,大家可以就像成装修,家里的装修都已经结束了,忽然间告诉你说一台家具进不去了,那怎么办?其实很简单门做小了我怎么才能把这些东西放进去。在家里一个小项目影响不是很大,但是大家可能有一点制药企业的经验,制药企业的所有的厂房实验室造价都非常高,即便是一个门,他去变更一下,在财务指标上也会有一个很大变更,这样的话一般的项目经理都不可以接受。我们现在可以看到问题在这种变更不可避免,因为你必须要把设备放进去,由此产生这种额外的费用由谁来负担,这其实是两个项目经理特别关心的一个事情。产生了额外的费用,在金融危机的情况下外企对经费的控制是非常严格的,平白无故产生了一些经费甚至还有一些延期,这个时候领导一定会说你总结一下经验教训,其实这个总结经验教训实际就是暗示谁应该承担这个责任,这个时候作为两个项目经理人他应该怎么处理会更好一点。如果说项目A和B的已经开始相互指责了,因为当大家要承担责任的时候都是说对方不好,你应该更早一点告诉我,如果说这个时候双方都在指责对方是达不成一致的。其实今天我们想探讨的就是这个话题,如果在座的对这个案例已经有一些想法不妨举手发表你的想法,你怎么去处理这个问题。没有关系在我们的课堂上永远不存在肤浅的问题,肤浅的回答,你尽管说,把你的想法告诉大家。如果没有我我们就开始往下走。

      大家可以看看,我们今天讲冲突,冲突是什么意思?我们这里给冲突一个定义,我想在座的各位对冲突都是有一些或多或少的理解,如果说你在电梯里碰了一下、擦肩而过这叫不叫冲突呢?实际上这个不能严格定义为冲突,冲突是有一个程度的问题在里面,如果是小小不言的东西我们把它可以叫摩擦,但是它没有上升到冲突这个程度。

      所以理解和正确判断是我们处理冲突的一个先决条件。没有冲突到彻底的冲突是一个级别不断上升的概念。大家看最上面,比如说我要摧毁对方,我可能在公开的场合使用暴力等,反正我会对你进行一个非常不可接受的挑战或者攻击,这样的话其实是一种非常严重的冲突。我们可以试想在一个公开场合你的一个同事跟大家讲了很多你的坏话去败坏你,这是一个非常公开的挑衅动作,是一个很严重的冲突。往下一点就是身体攻击,比如说在外边被别人打了一下,这些其实都是冲突,但是这里我只是举了一些例子,从重到轻,轻度的一些分歧误解我觉得不是今天探讨的问题,这个仅仅是一些小的矛盾。

      下面我们来看,项目A和项目B的冲突很明显了,这个有可能会牵扯到今年这两个项目经理在公司里的业绩怎么样,职位是不是可以得到提升,奖金怎么样,所以有一个很大的利益冲突在那里。所以双方都可能会为自己的利益作出一些努力,有可能会伤害到对方的一些利益。

      但是冲突是不是全都是坏的?其实也不是,我在过去的项目管理中我有时候发现善于利用冲突有时候能帮我解决一些问题,比如说竞争。这个实际上也是一种冲突,但是竞争就一定会带来一个非常积极的效果,你会让一个团队或者若干个团队为了一个目的在竞争的气氛中会把自己更多的智慧凝结到他的工作当中去。所以竞争就是一个非常好的体例,也就是说在我们处理冲突的时候其实你可以把他引向一个负面的影响,也可以把它引向一个正面的影响。

      简单讲比如说有两个团队,他们一直是工作绩效不高,这个时候他们也已经有一些矛盾,因为互相在推诿,有一些工作都不愿意承担,在这个时候你如果适当引入竞争这个理念,将两个团队冲突明显化一些,比如强调可以在年终的时候评选一个最佳团队去拉斯维加斯度假。这其实是一种竞争的引入,它的结果可能是调动两个团队的工作积极性,这就是我们引用冲突的一个积极因素到工作管理中的例子。但是今天我们不是讨论它,我可以从这个图大概总结一下,你的部门绩效是从高往低这样排下来,当冲突在这个合适的点位的时候部门的绩效其实是最高的,但是要冲突特别低或者特别高的时候,部门的绩效都不是很好,作为职业的管理人员我们怎么样能控制或者发展这个最高的点是我们工作中把握的一个很挑战的东西,因人而异。

      当冲突已经发生了再去处理他,实际上已经晚了,因为这是一个事后性的,那作为一个最聪明的处理方法,实际上是防患未然。也就是我们经常说的人无远虑必有近忧,这个人如果天天乐乐呵呵的并不见得是一件好事,也许在未来的某一天,他不可预见的某一天,就会发生对他有重大影响的事情。也就是说一个人一定要为自己的未来作出布局和规划,就像我们今天坐在这里或者未来参加项目管理的一个论坛实际上我们都是有一些危机感的,因为每一个人都是希望不断的提高自己的管理水平,如果我们安于现状,说我现在管理水平已经很先进了,我可以不客气的告诉他们在今天的社会竞争如此激烈的一个情况下很快就长江后浪推前浪,很快就看不到自己了。所以说人一定要有远虑,其实解决冲突也就是说如果你能提前预见到它,你就已经长掌握了主动权,最好的方法实际上是防患未然。

      后边我们介绍解决方案,冲突有时候是不可避免的,即便你已经预见它,也是很难做出来一些措施完全可以避免他。所以当你已经预见到一些冲突必须要发生的时候,我们还可以提前采取一些有效措施,你可以尽量回避冲突,当然不可能百分百保证你一定能回避冲突,你可以转嫁冲突。转嫁冲突我大概解释一下,有的时候冲突成为矛盾的焦点,如果你引入第三方或者第四方让大家共同承担这个责任的时候冲突可以化解一部分,至少你不会成为矛盾的焦点,所以说转嫁冲突是很好的方法。

      降低冲突级别,就像我刚才列入的冲突的程度不一样,因为我不能回避他,但是我至少可以降低他的影响。有准备地接受冲突,这个不等于艺高人胆大,艺高人胆大就是属于我很厉害,我相信我有这个能力,我不管发生什么样的冲突,我都能够随时应对,这是另外一回事,有准备地接受冲突是说你在不能够回避这个冲突的情况下,做了充分的准备,我在有准备的情况下接受这个冲突就有可能会把它的影响朝着你希望的方向引导。

  • 做好项目管理的几个关键事项

    mandy.wang 发布于 2011-09-19 11:32:02

    在项目过程中,通过观察,感觉做好PM这个角色需要做好以下几点:

      ● 对项目关键点的细节要足够了解

      虽然PM可以不参与具体的编码工作,但并不等于不需要了解具体的实现细节,特别是一些影响项目成败的关键点。有些PM离技术越来越远,远到一些功能是怎么实现的、用的是什么技术、有哪些地方需要特别注意都不清楚,这会非常影响他的决策力和判断力,特别是在处理突发事件时会手足无措。在现阶段,特别是项目规模不大的情况下,感觉PM兼任架构师比较好。

      ● 对项目各个阶段的时间点要足够清晰

      PM头脑得时刻有一个清晰的项目roadmap,并对每个时间点做好准备,比如在项目立项前,预估好工作量和资源分配,与其他团队协调好时间点和容错方案;在需求评审前得组织项目骨干了解需求并做好架构设计,与PD深入探讨,避免业务上走不通;在设计评审前,得评估出所有风险点和合作方,并完成设计文档,与合作方充分探讨合作细节,并达成一致;在提交测试前,关注各个任务的进度,特别是有风险的,并为测试准备好环境;在开发联调前,与各个参与方的接口人联系好,并准备好环境;在发布前,做好发布计划,预估出发布风险点。总之,需要对各个关键时间点有清晰的认识,提前做好准备,控制好风险。

      ● 处理好与其他团队的关系

      一个项目的成功不是只靠自己这个团队就能做到的,需要所有团队的通力合作,因此,非常有必要学会与其他团队处理好关系,而与其他团队沟通的接口人主要就是PM,PM对于团队之间的合作是否顺畅起着决定性的作用。首先需要弄清楚什么是原则性问题,什么是可以退让的,在有分歧的时候,要立即判断出是否可以出做让步。再则,一定得把问题想在前面,提前沟通,只要大家都是为了把项目做好,并在出现分歧前,就把这些可能的分歧点讨论清楚了,就没什么很难处理的关系。最后,学会与任何类型的人打交道,林子大了什么鸟都有,沟通不是为了争个输赢,而是达成一致,这方面的技巧就多了,需要学习和积累。

      ● 调动组员的积极性,尽量把事情让他人去做好

      在以前待过的一个项目里,PM非常敬业,很多事情都是自己去做,结果出现一个很不好的现象,每天晚上,他的项目成员都走光了的时候,就留下他一个孤独的身影,奋力拼搏,结果每次发布的时候问题多多,惊险不断。这说明一个问题,你不是一个人在战队,并且你不应该冲在第一线,PM的成就感不应该是你自己把事情给搞定了,而是在你的策动下,你的组员把事情搞定了,只有这样项目团队才有战斗力,并且其他成员都希望在项目过程中体现价值,你需要学会锻炼和培养其他组员,发挥他们的最大潜力,这也是为什么在发挥同样出色的情况下,纳什比科比更容易获得MVP的原因了。

      ● 处理好风险点

      PM可以把不影响项目成败的点扔给你信任的人,但对于那些会导致失败的风险点必须给予足够的重视。我以前带过一个小项目,其他什么都完成很好,事情做得很漂亮,bug也没测出几个,但没有review其中几个比较容易出错的SQL,但QA告诉我没bug的时候我也没去多看两眼,结果它隐含了一个比较深层次的bug,在线上暴露了出来,造成了不小的损失和不良影响。其实,后来总结的时候,发现这个SQL存在明显的疏漏,如果当时认真地review,并审视测试case,是应该能发现问题的。PM必须对各个风险点心里有本帐,项目可以做得不漂亮,但如果在风险点上有任何疏忽,那就是失败。

      ● 安排好任务,并清晰了解任务的进度

      PM需要对自己团队的组员深入的了解,了解他们的能力和兴趣点,把任务交给最合适的人,并保持与他们的深入沟通,了解他们面临的困难,你虽不是直接去完成任务的人,但一定是帮助别人完成任务的人。任务墙是个不错的方式,能让自己和他人清晰看到各个任务的完成情况,便与跟进

        ● 保持清晰的思路,储备应对各种突发事件的措施

      项目里最需要保持思路清晰的人是PM,别人可以乱,但PM一定不能乱,特别是在有突发事情发生时。因此,PM有必要有意识地锻炼自己抗压能力,比如多做项目发布、设计评审和数据订正的工作,并且要有意识地储备一些应急方案,比如代码回滚,紧急发布等等。另外,要清晰地弄清楚团队之间和系统之间的依赖关系,往往这种依赖性是引发事件的根源。

      ● 保持平和的心态,多站在他人立场考虑问题

      项目会进行地风风火火,项目成员之间也会争论得很激烈,往往这种时候,保持一个平和的心态很重要。不平和的心态往往会导致不平和情绪,不平和的情绪就会导致更加混乱的局面。保持平和心态的办法很多,很重要的一条是多站在他人立场考虑问题,一旦为他人体谅后,激烈的情绪会消退不少,并且在这种沟通态度的促发下,分歧方也会不由自主地为你考虑,非常有利于解决问题,达成一致。

      ● 加强项目自动化方面的能力

      项目各个细节如果全都靠人肉去完成,会极大增加控制风险,而减少风险的最大利器就是用成熟的自动化方案去完成一些工作,特别是项目构建、持续集成和发布等工作。PM应该在怎样让日常工作流程化和工具化方面多动一点脑筋,而这方面敏捷开发提供很多很好的思路和方案。

      ● 共识和决议要通过邮件发给相关人

      在项目过程中会产生很多变故,需求和设计文档里定义不了所以问题,为解决变故而形成的临时决议一定要通过邮件发给相关人,不光是知会,更重要的是为决议提供证据,这些临时的决议往往会引发问题,当问题产生追溯责任时需要用到这些证据。

      ● 注意倾听组员的意见,给他们留出足够的发挥空间

      特别是在大公司带项目,组员都算是开发的精英,都不是甘于做个机械的coder,因此学会倾听他们的想法,深入了解他们想得到的,尽量满足他们成长需求,就算是由于项目客观原因,没法采纳他们的建议,也得和他们把道理说清楚,不合适用强势方式来决断,毕竟技术人员的需求和管理不同一般。

      ● 不以个人意愿为基准,凡是以大局为重

      PM也是人,在平时工作过程中,难免会带有个人情绪,但PM应该清醒地认识到自己身后还有一个团队,大家的情绪和状态与自己息息相关,所以说话做事一定要三思而行,考虑清楚对别人的影响,切勿乱放炮,失去同仁的信任。

      小结

      项目领导者有几个特性:自身技术扎实;注意节点控制;善于和员工沟通;为人有亲和力;自己很闲,但是员工工作很充实;知人善用;深入了解项目细节,做事有计划;有创新能力;有解决突发事件的能力。

      特别是自身技术扎实这个点,软件项目的PM如果自身在技术上缺乏深入,对细节不够了解,会直接影响他的判断力和全局控制力,但同时也得把握具体工作参与的力度。

      总结的说,合格的PM应该是个有大局观、全局观的有魄力的人!

  • 转:测试经理该如何激励测试人员

    applejuzi 发布于 2011-01-03 20:45:49

    在整个测试过程中,人是最重要的因素之一。不管是多好的过程,还是多好的方法,最终都需要由人来执行和完成。好的过程就像是一条高速公路,而人就是在这条高速公路上的车,好车配合好路才能够保证行驶的速度和安全。

      测试经理在日常工作中的一个重要任务就是保持对测试团队成员的激励。一谈到激励,可能很多人下意识就会想到金钱,例如:给员工奖金,或者加工资。实际上,物质奖励只是激励方式的一种,但这并不是唯一的和最有效的方式。每个员工都有自己的梦想和目标,希望能够获得更多自主的空间,希望自己的才能得到施展,希望得到认可,希望自己的工作富有激情,因此,测试经理除了提供物质上的激励以外,更应该为员工提供一个施展他们才能的舞台,激发员工内在的自我激励和自我实现。而且每个员工的需求不一样,激励的方式也各不相同。例如:公开表扬对有的员工有明显的激励作用,但对于性格内向的员工,效果可能会大大打折;提供弹性的工作时间也是对员工的一种激励。下面介绍一些常见的激励方式。

      1)满足员工的需求

      作为团队核心的测试经理,必须针对部门内员工的不同特点“投其所好”,寻求能够激励他们的动力。每个人内心需要被激励的动机各不相同,因此,奖励杰出工作表现的方法也应因人而异。不同的人在不同时期的需求也是不一样的。员工主要的需求包括:

      ● 得到尊重和认可。

      ● 获得自我表现的机会。

      ● 在积极的团队氛围中工作。

      ● 获得一定的做决定的权力。

      ● 公平的竞争环境。

      ● 广阔的成长空间等。

      要满足员工的需求,首先需要理解员工。这就要求测试经理在日常的工作和生活中能够多倾听、多观察,还应该注意员工的一些肢体语言或者异常的情绪波动等。测试经理可以通过以下途径获得员工的具体需求:积极倾听员工的呼声、换位思考、观察员工的情绪波动并做出积极的回应等。当员工的需求获得满足时,他们的工作效率会有很大的提高,员工的内在激励会起到重要的作用,团队会处于一个积极向上的氛围,员工的聪明才智和创造性才能够得到最大的发挥。

      马斯洛需求层次理论(Maslow's hierarchy of needs),亦称“基本需求层次理论”,由美国心理学家亚伯拉罕·马斯洛提出。马斯洛是当代最伟大的心理学家之一,由于他的著作使人本心理学的观点更加丰富和清晰,所以被人们称为“人本心理学之父”。他的需求层次理论对团队激励有着很大的帮助。表1列出了根据马斯洛的需求层次理论得到的团队激励的实例。

    表1  马斯诺的需求层次理论在团队激励中的实例

    马斯诺需求层次 

    工作中的对应关系 

    自我实现的需要 

    参与挑战性的项目、创造性获得鼓励和支持、获得创新的机会 

    尊重的需要 

    获得尊重和认可、能够被委以重任 

    情感和归属的需要 

    友好的团队氛围、良好的客户关系 

    安全上的需要 

    工作的安全性、良好的工作环境 

    生理上的需要 

    基本的薪酬、工作空间、饮食 

      2)有效授权

      测试经理在安排工作的时候,应该考虑让团队成员承担更多的责任并拥有更多的权利。授权并不一定是升职。测试经理在向其测试团队成员分配工作时,也要授予他们相应的权力,否则就不算授权。测试经理应该在合适的场合让所有的相关人员知道被授权者的权责,同时需要确保授权之后应该尽量减少干涉,要给被授权员工做相应决策的权力。

      有效授权是一种很好的激励员工的方法。权力的下放同时也意味着责任的下放。员工在获得一定的决策权力的同时,也应该明白要全力以赴把事情做好,要对任务的结果负责。通过有效授权,员工的积极性和创造性能够被最大限度地调动起来,同时员工的责任感和主人翁精神会得到加强,对组织的认同感会不断提高。员工通过承担更多的责任,也获得提高自身各项技能的机会,从而获得更广阔的发展空间。但是在授权的过程中,测试经理也要注意确保授权的范围和员工的实际能力相匹配,尽量避免一开始就赋予给团队成员过多的授权和责任。在实际的授权过程中,测试经理可以以渐进的方式授予测试团队成员的权力,同时在必要的时候需要为员工提供相应的培训。

    ☆示例:有效授权

      测试经理通常需要协调整个测试过程中的所有活动,包括测试计划和控制、测试分析和设计、测试实现和执行、评估测试出口准则和报告以及测试结束活动等。但是作为测试经理,并不需要对所有的测试活动亲力亲为,而是应该将测试活动进行划分,将测试过程中的一些活动下放到测试团队成员中去。在项目中可以采用“一事经理”的方式。所谓的“一事经理”,就是对某个独立的任务或活动具有决策权力的人。测试经理可以将测试活动中的测试环境管理、测试用例配置管理以及测试度量等任务的权力授予相应的测试人员,由其负责处理相关事宜,定期向测试经理汇报。

      以测试度量为例,某个测试团队成员成为该任务的“一事经理”后,全权负责测试度量相关事宜,包括测试度量系统的设计、测试度量数据收集和测试度量数据分析等,而测试经理作为测试度量活动的一名成员而不是管理者参与到测试度量活动中。测试经理最终使用测试度量活动的分析结果作为其他活动的输入,例如:作为测试出口准则评估的输入。测试人员在“一事经理”这个方式下也得到了锻炼,自己的技能得到了增强,同时获得了整个团队的尊重和认可;测试经理也因此减少了日常的工作量,可以将更多的精力投入到其他测试管理活动中去。

      3)有效沟通

      沟通无时无地不在,测试经理每天要和各种不同角色的人以各种不同的方式进行沟通。有效地沟通能够节约测试经理的时间和工作量,同时也能帮助团队成员更好地完成任务。另外,有效地沟通还有助于构建一个开放的测试团队,最大限度地发挥团队的积极性。倾听是有效沟通的一个重要方面,尤其是对待团队成员的抱怨,测试经理更应该认真倾听,如果能做到认真倾听,大部分的抱怨都可以得到解决。很多时候,员工可能并没有期望问题得到解决,他们更看重的是测试经理或管理者的态度,通过认真的倾听,员工的问题即使没有得到解决,员工的不满意度也会得到很大的降低。此外,在沟通的过程中,测试经理要避免过于封闭而听不进员工的建议,或者只是进行有选择地倾听,例如:只听好的内容,对提及的问题视而不见,同时,测试经理必须对员工的意见及时进行反馈。

      沟通的方式有很多,例如:面对面交流、Email、电话、文档评审等。测试经理应该根据实际需要选择合适的交流方式,例如:简短的信息传递,可以通过电话的方式很快解决;对于复杂方案的讨论,需要安排专门的会议;有些事情可以先通过Email的方式传递基础信息,给员工一个准备的时间,然后通过面谈的方式做最后的沟通。以下的建议将有利于改进沟通的效果:

      ● 多听少说。

      ● 使用简单、容易理解的语句。

      ● 注意使用合适的肢体语言。

      ● 不明白的要及时提出问题。

      ● 要经常沟通以及沟通要保持热情。

      ☆示例:有效沟通

      测试经理和测试团队成员之间如果能够建立有效的沟通渠道,团队成员和测试经理之间能够有效地交换意见,将有助于测试团队成员的激励。但是在实际的测试过程中,测试团队成员很少主动找测试经理反馈意见。尤其是以技术为主的测试团队中,测试团队成员相对比较“内向”,交流不够主动。这种情况下,测试经理可以定制一个团队沟通交流计划,团队成员每个月都有一次和测试经理单独面谈的机会。测试经理会轮流和每个测试团队成员进行面对面地交流,给员工一个反馈意见的机会。这些面谈都是在一对一的情况下进行的,团队成员不会有太多的顾虑;同时面谈的时间都是提前计划好的,如果有需要反馈的问题或建议,员工在沟通之前可以做好充分的准备。测试经理在这种方式下要把面谈的气氛调节为一种非正式的交流,可以交谈任何内容,从工作到生活。

      4)提供学习和培训的机会

      现代社会,科学技术迅猛发展,信息和知识急剧增加,知识更新周期缩短,创新频率加快,各种技术方法层出不穷。如果员工不积极学习,就很难跟上时代发展的步伐,甚至会被社会淘汰。因此,每个员工自身都有危机感和紧迫感,从而自身都有学习和培训方面的需求和需要。这种情况下,为员工提供良好的学习和培训的机会,显然能够激励员工创造更大的价值。通过提供学习和培训的机会,不仅员工自身的能力得到增强,对组织的认同感提高,整个团队的能力也会得到提升,从而能够更加有效地完成相关任务,并承担更大的责任。

    学习和培训的方式有很多,可以在团队内部组织交流和学习、相互进行培训,也可以聘请外部专家进行培训;可以通过E-learning的方式,也可以通过课堂教学的方式。要开展学习和培训,必须将员工的兴趣和工作需要结合起来。在开展培训之前,首先收集员工的培训需求,然后结合项目或者团队的目标,从而在个人目标和团队目标之间实现共赢。学习或培训后,需要及时收集员工的反馈,不断改进培训的效率和有效性。

      ☆示例:提供学习和培训的机会

      “岗位轮换”是一种很好的学习方式。当测试团队成员在自己的岗位上工作了一段时间以后,相关技能已经熟练掌握,这个时候都希望能够有机会再增加一些其他方面的技能。这种情况下,可以在测试团队内部进行岗位轮换,给每个员工一个学习新知识的机会。在iBAS R1.0项目中,随着测试执行的不断进行,被测试对象中发现的问题越来越少,测试人员已经开始“审美疲劳”,觉得很难再发现新的问题。这个时候,在测试团队中进行岗位轮换,原来执行IGMP系统测试的人员开始测试DHCP功能,其他人也相应地进行轮换。通过这种方式,测试人员可以掌握原来不具备的知识,增加了对整个被测试系统的了解;同时由于相互轮换,起到了一个评审的作用,测试人员对新分配任务的功能可从自己的角度重新思考,可以对原来的测试用例进行修改或补充,这样也有利于发现更多的缺陷,提高被测试对象的质量。

      5)尊重和认可

      每个人都希望得到别人或团队的尊重和认可。尊重和认可能够使员工对自己更加自信、对工作更加热爱,能够鼓励员工提高工作效率。给员工的认可也要及时而有效,当员工工作表现很出色时,测试经理应该立即给予称赞,让员工感受到自己受到上司的赞赏和认可。测试经理可以通过各种不同的方式认可员工的工作表现,例如:口头赞赏、书面赞美、对员工一对一的赞赏、公开的表扬等,从而不断鼓舞员工士气。对于测试人员而言,当测试人员的建议被开发人员或项目团队采用、测试人员能够在项目早期介入项目开发活动、为测试团队分配足够的资源等,这些都是对测试人员的尊重和认可,可以激励测试人员更好地工作。

      ☆示例:尊重和认可

      “每周之星”是一种表扬员工的方式,通过这种方式可以使员工感受到被组织的认可,从而获得满足感和成就感。测试经理每周发掘团队中表现出色的员工进行表扬,是尊重和认可的重要表现形式。员工的出色表现可以是各种各样的,例如:需求评审过程中发现了很多问题、测试设计过程中有效地引入了测试自动化、为客户制定了良好的解决方案等。测试团队每周肯定都会有一些特别的事情发生,因此,总归可以发掘成为“每周之星”的员工。即使是测试团队处于项目的前期学习阶段,也有很多员工的行为是值得表扬的,例如:对及时总结或者分享学习成果的员工进行表扬。“每周之星”这样的形式不仅对员工的工作进行了认可和表扬,而且能够激励其他员工不断地努力。

      6)物质奖励

      上面介绍的几种激励方式更多地偏重于精神上的鼓励。实际上,除了精神激励外,物质奖励也是必不可少的,它也是日常工作中经常使用的一种方式。薪水不仅能保证员工生存,同时能者多得的薪酬机制也能有效地起到激励效果。物质奖励的多少依赖于员工能为公司带来的价值,例如:对于为公司创造出高利润、开发出赢利新项目的核心人才,通过加薪激励是必不可少的。在使用物质奖励方式的时候,一个重要的考虑因素是公平。如果某个员工的贡献突出,那么可以对这个员工进行单独的奖励。假如突出的是团队共同努力的结果,那么需要对整个团队进行奖励。同时物质奖励要有充足的理由,确保只有表现优秀的员工或者团队才能够获得物质奖励。

      ☆示例:物质奖励

      物质奖励的方式既可以是单次奖金的形式,也可以是加薪的方式。在平时的激励过程中,测试经理应该综合应用这两种形式。每个季度可以对个人或团队进行一次评比,对表现突出的优秀个人或者优秀团队进行单次的奖金激励。每年对团队成员进行综合考核,根据团队成员的年度表现,对不同贡献的员工进行不同程度的物质奖励,可以是年度的加薪,也可以是年度加薪和单次的年终奖相结合的方式。

      上面介绍了几种常见的激励方式,其实,激励的方式还有很多,例如:建立良好的团队氛围、鼓励大家注意身体健康、重视工作和生活的平衡等。在日常管理过程中,测试经理应该灵活应用各种激励方式。

      激励测试人员的方式有很多,同时也有很多方式会打击测试人员的积极性,造成消极的影响,例如:测试人员在一个几乎看不到结束期限的项目上工作;测试人员致力于保证产品的质量,并且投入了额外的时间和精力,但是由于一些外部因素影响,输出的产品仍旧没有满足计划中设定的目标;尽管测试人员尽了最大的努力,但还是没有及时完成测试任务;如果测试人员的贡献没有被理解和衡量,不管最终结果是否成功,对测试人员而言都很可能造成消极的影响。

    本文转自:http://www.51testing.com/html/02/n-226402-3.html

  • 转:谈话技巧

    applejuzi 发布于 2011-10-07 18:14:49

      最近自己的工作和管理搭上勾了,平时没注意说话技巧,给客户留下了不好的印象,被领导批了。看来真的学学,无意中看到这篇文章,觉得写的还是挺好的。如下:

    以最婉约的方式传递坏消息句型:我们似乎碰到一些状况…

      你刚刚才得知,一件非常重要的案子出了问题;如果立刻冲到上司的办公室里报告这个坏消息,就算不干你的事,也只会让上司质疑你处理危机的能力,弄不好还惹来一顿骂、把气出在你头上。

     
    2)?1:TurnAD42.visit; TurnAD42.store(); function showTurnAD42(basenum){ if (basenum==1){ document.getElementById('TurnAD42').innerHTML = "";} else{ document.getElementById('TurnAD42').innerHTML = "";} } showTurnAD42(intTurnAD42); }catch(e){}
    此时,你应该以不带情绪起伏的声调,从容不迫的说出本句型,千万别慌慌张张,也别使用「问题」或「麻烦]这一类的字眼;要让上司觉得事情并非无法解决,而「我们」听起来像是你将与上司站在同一阵线,并肩作战。

      上司传唤时责无旁贷句型:我马上处理。

      冷静、迅速的做出这样的回答,会今上司直觉的认为你是名有效率、听话的好部属;相反,犹豫不决的态度只会惹得责任本就繁重的上司不快。夜里睡不好的时候,还可能迁怒到你头上呢!

      表现出团队精神句型:安琪的主意真不错!

      安琪想出了一条连上司都赞赏的绝妙好计,你恨不得你的脑筋动得比人家快;与其拉长脸孔、暗自不爽,不如偷沾他的光。方法如下:趁著上司听得到的时刻说出本句型。在这个人人都想争著出头的社会里,一个不妒嫉同事的部属,会让上司觉得此人本性纯良、富有团队精神,因而另眼看待。

      说服同事帮忙句型:这个报告没有你不行啦!

      有件棘手的工作,你无法独力完成,非得找个人帮忙不可;于是你找上了那个对这方面工作最拿手的同事。怎麽开口才能让人家心甘情愿的助你一臂之力呢?送高帽、灌迷汤,并保证他日必定回报;而那位好心人为了不负自己在这方面的名声,通常会答应你的请求。不过,将来有功劳的时候别忘了记上人家一笔。

      巧妙闪避你不知道的事句型:让我再认真的想一想,三点以前给您答覆好吗?

      上司问了你某个与业务有关的问题,而你不知该如何做答,千万不可以说「不知道」。本句型不仅暂时为你解危。也让上司认为你在这件事情上头很用心,一时之间竟不知该如何启齿。不过,事後可得做足功课,按时交出你的答覆。

      智退性骚扰句型:这种话好像不大适合在办公室讲喔!

      如果有男同事的黄腔令你无法忍受,这句话保证让他们闭嘴。男人有时候确实喜欢开黄腔,但你很难判断他们是无心还是有意,这句话可以令无心的人明白,适可而止。如果他还没有闭嘴的意思,即构成了性骚扰,你可以向有关人士举发。

      不著痕迹的减轻工作量句型:我了解这件事根重要;我们能不能先查一查手头上的工作,把最重要的排出个优先顺序?

      不如当下就推辞。首先,强调你明白这件任务的重要性,然後请求上司的指示,为新任务与原有工作排出优先顺序不著痕迹的让上司知道你的工作量其实很重,若非你不可的话,有些事就得延后处理或转交他人。

      恰如其分的讨好句型:我很想您对某件案子的看法……

      许多时候,你与高层要人共处一室,而你不得不说点话以避免冷清尴尬的局面。不过,这也是一个让你能够赢得高层青睐的绝佳时机。但说些什么好呢?每天的例行公事,绝不适合在这个时候被搬出来讲,谈天气嘛,又根本不会让高层对你留下印象。此时,最恰当的莫过一个跟公司前景有关,而又发人深省的话题。问一个大老板关心又熟知的问题,但他滔滔不绝的诉说心得的时候,你不仅获益良多,也会让他对你的求知上进之心刮目相看。

      承认疏失但不引起上司不满句型:是我一时失察,不过幸好……

      放错在所难免,但是你陈述过失的方式,却能影响上司心目中对你的看法。勇于承认自己的疏失非常重要,因为推卸责任只会让你看起来就像个讨人厌、软弱无能、不堪重用的人,不过这不表示你就得因此对每个人道歉,诀窍在于别让所有的矛头都指到自己身上,坦承却淡化你的过失,转移众人的焦点。

      面对批评要表现冷静句型:谢谢你告诉我,我会仔细考虑你的建议。

      自己苦心的成果却遭人修正或批评时,的确是一件令人苦恼的事。不需要将不满的情绪写在脸上,但是却应该让批评你工作成果的人知道,你已接收到他传递的信息。不卑不亢的表现令你看起来更有自信、更值得人敬重,让人知道你并非一个刚愎自用、或是经不起挫折的人。

  • 转:职场说话

    applejuzi 发布于 2011-10-07 18:30:03

    提高说话技巧对每一个职场中人来说都是很重要的,一句话可能就关系到你的前程。往往每个人都有一个隐私区域,不愿意被打扰,不愿意被催促,不愿意和陌生的面孔交谈,不愿意被人指责,不愿意按照规定的时限做事,不愿意主动的去关心别人,不愿意去思考别人还有什么没有想到。在工作之后,你要极力改变这一现状。否则,你会很快因为压力而内分泌失调。特别在会议上,许多人会消极的听取领导的话语,消极的待命,很死的完成上级交给的事情,但从来不关心此事以外的任何事情,更不会想到多做一步,让接下来的别人的工作更加容易上手。而掌握说话技巧的人,敢于在适当的时候提出自己的看法和不理解,并在得到上级认可和指点之后把手头的工作尽快的完成,并随时接受别人的批评和调整。

    我们不要把好像、大概之类不确定的话放在嘴边。尤其是和上级谈论工作的时候。因为似是而非的应答往往一样会暴露出你更多的弱点:1.你之前没有想到这个工作,或者一直在拖延。2.你没有责任心,认为这些并不重要。3.你应付上级。4.你不敢说真话。5.你喜欢逞能,答应一些做不到的事情。6.你不能独立工作。

    当你的上级在以上选项中怀疑的时候,潜意识中你已经同时具备了以上所有的弱点了。

    再者不要表现得消极,仅仅因为你所做的事情不是你的兴趣所在。很显然,在学生时代,当做到自己喜欢的时候,我们会很多精力去创造,但如果是枯燥的事务,我们便懒得理睬,最好能有办法应付过去。但在工作上大部分你所做的事情都是繁琐而看似机械的,如果仅仅为此而表现的闷闷不乐,那么你会郁闷更久。要知道你的上司已经为这个项目够烦恼了,你还想让他看到你的表情吗?学会喜欢自己的工作,并把注意力放在日常工作能学到些什么上去。如果现在你努力的抱怨工作,那么接下来你就是努力的寻找工作。尽量少用“有趣”,“好奇”之类的词语来描述自己想要的工作,而是“充实”, “有成就感”,“乐意”。

    也不要推卸责任,推卸责任是害怕的条件反射。不要认为别人看不出这点。其实现在很多人面对工作也是这样,当上级责问的时候,很条件反射的就做出了推卸动作,然而这样的动作,接下来往往是无力的辩解,以及一些很粗糙的借口。这样会让上司感到你这个人很难沟通,并且很不真实。

    最后分享一些职场中人提高说话技巧的秘诀。

    1. 不要说尖酸刻薄的话,。

    2. 转移话题要尽量不着痕迹。

    3. 如果你要加入别人的交谈,先要弄清楚别人究竟在说什么。

    4. 交谈之前尽量保持中立、客观。表明自己的倾向之前先要弄清楚对方真实的倾向。

    5. 以谦卑的姿态面对身边的每一个人。

    6. 多给别人鼓励和表扬,尽量避免批评、指责和抱怨。

    7. 要学会倾听。不要说得太多,想办法让别人多说

    8. 不要因为对方是亲朋好友而不注意礼节。

    9. 尽可能谈论别人想要的,教他怎样去得到他想要的。

    10. 一定要尊重对方的隐私,不管是朋友还是夫妻。

  • 【原创】不要轻易否定自己

    applejuzi 发布于 2011-11-02 19:58:07

        自己一直都很比较自卑,平时也比较容易否定自己。记得第一次转测试的时候,自己啥都不会,和我一同进公司的同事提的bug比我多,本来心理就有点着急,一听领导表扬那个同事,我更是心急如焚。所以那段时间心情很压抑,一遍遍的在扪心自问,自己是否适合做测试,如果不适合的话自己还有退路么?有1次刚好和领导一起下班,在那短暂的几分钟内我鼓起勇气问领导,自己是否适合做测试。领导说我不适合,这个回答让我更有压力了。自己放弃了工作转测试了,现在也有几个月了。自己要不要坚持呢?挣扎了几天后我决定在测试的道路上一直走下去,我自己没有退路了。后来过了几个月我找了份新工作(之前的工作只是实习)。这是我第一份正式的测试工作。新工作压力很大,开始的一二个月我有点跟不上,我知道自己比别人笨,所以花的时间要比别人多,所谓笨鸟先飞。在工作中我很卖命,经常是项目中最后一个下班的,也是项目中最早上班的。2个月后领导跟我说我过试用期了,也得到了领导的表扬,之后我总是项目中提bug最多的一个。工作之余偶尔会想起之前领导说我不适合做测试,我想她看错了,一个人只要坚持,只要用心去观察,用心去学,再比别人多花点时间的话肯定能做好。

       这份工作干了2年后我辞职了,到了现在的公司。在新公司我的表现还可以,进公司3个月后领导主动给我涨工资了,虽然不多,我也挺开心的,至少自己的成绩被领导认可了。1年后公司的测试组长纷纷辞职,我被担任测试组长,开始带项目。由于沟通技巧、经验不足及项目时间紧张等多方面因素,自己的压力很大,有连续2个星期没睡好觉,有时候整晚都睡不着。人没休息好白天干活就没精神,一没精神人就容易很出错,一出错我就常常自责,一自责我又睡不好觉,如此恶性循环,那段时间LG也很郁闷。看着我一天天的消瘦下去,他心理也很难受,他建议我辞去这份职务,但我自己又不是特别舍得,这毕竟是自己职业规划的一大提升。这些都被领导看到眼里,不久前的一天领导找到我,很认真的跟我谈了谈现在我的状况和项目的状况,然后让一个同事代替了我的职位,也就是将我换下来了,领导说的很委婉,说我不适合做这个,但我知道意思。会后的几天里我一直都无法平静下来,因为被人换下来了面子上总觉得过不去,自尊心受到了沉重的打击,在项目组同事那总觉得抬不起头,当我向客户、向项目组内、向项目测试发出更换测试组长的邮件后,我的心情是特别的沉重,特别是当项目经理问我为啥要换的原因时,我说话的声音几乎有点哽咽。自己在沟通方面确实不太好,说话也太实在了,也不够灵活,这个也不是一天2天能提高的。所以后续自己在这方面得多学学,如何做好和其他部门的沟通协调、如何和客户之间沟通、遇到突发事件如何灵活应对等等问题是我后续学习的方向。

      领导否定我没关系,只要自己别否定自己,之前说我不适合做测试,我现在也做的挺好的,说我不适合做测试组长,我会证明给你看。相信自己,只要用心去体会、用心去学、多总结,我相信没有什么是不可能的。

  • 测试人员当代理测试LEADER

    applejuzi 发布于 2009-12-20 20:43:55

    总是希望能给手下一些机会来锻炼他们在项目中的leadership的能力,公司那边也来指示精神,要我们这些老鬼们抓大放小,放大胆子让手下的娃儿们把项目挑起来。所以那些都想当将军的士兵们个个摩拳擦掌的跃跃欲试。于是我们开始了每个人一周的代理leader的尝试,经过一个月的试运行,发现大家积极性都比往常高了,对项目的了解和关注都空前高涨,不过是运行中也发现了这样或者那样的不足,于是记录下来,总结如下。
      以下为了方便描述我们简称他们为小A。
      1. 信息乱,文档化意识不强
      项目中一些重要信息往往只是在MSN,或者口头说一下,无法跟踪分析。
      案例分析:记得小A初任代理leader一职的时候,意气风发,一会统计大家的机器配置,一会儿查看服务器的使用情况,问完了也就没消息了,事后在大伙建议下,建立文档专人负责更新。
      2. 思路不清楚,随机性强
      小A们的特点就是想到什么就说什么,没形成固定的标准。
      案例分析:我们要测试一些老的测试用例,我们的小A一开始光分配工作了,对怎么填写没做要求,经过提醒,才制定出一个标准,但是在Fail情况下是使用红色加粗还是都是黑色犹豫了很久。直到最后我按捺不住了,要她给个痛快的时候,那扭扭捏捏的说了一个标准大家执行。作为leader需要的就是给大家一个标准,一个方向,很忌讳目标不明确的任务。
      3. 出发点是好的,可惜可操作性不强
    作为新人,思维总是跳跃,我们鼓励大家思考,去改进流程,促进项目更好的管理,可能有的想法现在不成熟,或者说现在的条件不够。
    案例分析:我们的小A很喜欢开会,总结,喜欢大家一起讨论学习,这并不是坏事情,但是她的想法是在项目最忙碌的时候,而且很机械的固定每天必须要多少时间,来学习总结工作经验,当然在我们竭力反对和劝说下,小A放弃了这项计划。
      4. 自信不够或者过于自信
      这是两极端,多了少了都不好,自信来源自己的积累.别怕犯错,要善于总结.
      案例分析:做完smoke test了,需要发个报告给开发,是否接受,小A就很着急,找来sample,按理说很容易写的,不过以往都是pass,这次是fail,所以我们就告诉小A把问题描述清楚,状态就设置成reject好了,小A如临大敌,憋了多小时写了几个字,还非要我们review一下.
      5. 依葫芦画瓢,形似神非
      新人的学习能力很强,模仿性很强,只是有时候没去理解为什么,拿过来用就好了.
      案例分析:某日临近中午的时候,忽然收到今天工作的安排,甚是差异,忙呼之以明真相,果然,平时因为我们带几个新人,习惯了分配任务下去,担心他们自己不会安排,没想到我们的小A,忙完自己的事情,忽然发现小本子上记得要发工作安排,特地整理并组织了一封很正式的邮件给我们.我观察到收信时间已经临近中午。
      6. 下达任务的时候不清晰,容易误会
      因为缺乏经验以及必要的思考,所以在分配一些应变任务的时候,task很模糊,容易造成误会,花费很多人力去做无用功。
      案例分析:客户来了个更新的需求分析文档,我们的小A就马上放到共享目录下,告诉大家都去看下,语气很紧急,很重要的。我们等手下见状,不敢怠慢,草木皆兵,即刻打开文档,因为文档没更新记录,所以通读全片,发现就多了一个大家都知道的流程图,虚惊一场。大伙却白白花了很多时间。事后,小A还觉得自己很有理,其实我们拿到东西的时候都会自己先浏览一遍,看有多少价值,少的话,可以自己总结,然后share给大家,多的话,才会调整项目的schedule来进行处理。像这样劳民伤财的举动尽量避免。
      7. 缺乏解决问题的能力
      项目中总会遇到这样或者那样的问题,小A们最喜欢说的,老大,那个怎么做啊?
      案例分析:有次小A在写个新功能的测试用例。花了半天时间琢磨,后来鼓气勇气告诉我们不太会写,看不懂需求(因为事先我们已经告诉他们自己要学着去独立解决问题,尽量自己先思考了)。原来是小A要写的测试用例是我们系统和另外系统的接口的测试,所以对于一些陌生的名词,自己就迷糊了。当然这样的东西在以前培训中都讲到过了,也有相应的文档可以参考的。
      8. 缺乏判断,来什么做什么
      可能是新人的原因,比较容易被客户牵着走,因为客户是上帝啊,所以客户想要的就是我们要给的。
      案例分析:一早客户来要我们填个最新测试情况的文档,也没很着急的要,我们的代理leader小A就着急的招呼大家去填写,吩咐了最晚提交时间,还时不时的提醒大伙要记得按时填写,结果那天我们的测试进度都延误了,作为leader,需要去权衡利弊,知道什么是紧急,什么是不紧急的,而且有的事情可以一起做效率高。敢于和客户有条件的say no。当然也不是客户的什么要求都不需要接受。到时候别客户投诉了,别怪我哦。
      9. 习惯自己做事情,不会分配工作
      自从小A作了代理leader,很明显的就是平时工作忙了,加班时间长了。具体一问,很多文档需要更新,记录。其实很多时候大家都在做这些事情,自己更新自己的就好了。比如我们每天的例会就是轮流主持,轮流记录,养成了习惯,leader的工作自然会减轻很多。
      10. 缺少主见,墙头草
      项目中总少了不几个资深的,几个刺头,在一些项目细节处理的时候,我们的代理leader习惯性的墙头草,那边嗓门大就倒在那边,当然两边都有道理,或者是一些标准的制定,可有可无的,那时候就需要leader最后定下来,减少一些无谓的讨论和争论,个人觉得有时候作为leader需要专制点,来处理一些问题,否则会发现一些会议是在磨时间,无法产生了conclusion的output。这可能就是民主的悲哀。
      11. 对业务缺少深度了解,一知半解
      真没见过几个新人会把自己的精力放在学习业务知识上的,即便有时候项目有时间,给他们去看去学习,发现收获很少,这个是一个普遍的现象,所以就不举例说明,这边只是分享一些我的个人经验,对于项目需要一定的专业知识作为基础,但是通常情况下,我们可能对我们要测试的行业一无所知,所以在日常工作中我们会有针对性安排这样的学习和培训,当然很多时候是自己利用空余时间学习,在学习完或者测试前,自己会去冥想,项目的流程是什么样子的,其中的业务逻辑是什么样子,除了正常的情况,异常的情况呢,当然适当的交流,讨论可以帮我们整理思路,巩固知识。
      结束语:
      作为leader,不是一时半会可以修炼成功的,不是经历了几个项目就可以沾沾自喜了,即便我们这些在项目里摸爬滚打近十年的老鬼们,也每天在学习,每天在成长,别眼高手低,测试的基础知识不可少,再加上自己的总结,不仅仅是自己的实践经验,更多是别人的,特别是一个好的leader能让手下迅速成长起来。不过良马常有,伯乐不常有,自己多学多看多想,别怕犯错,但别总犯一样的错,明天肯定是很精彩的 ^_^。

  • 转:避免做“紧急任务”的奴隶

    applejuzi 发布于 2010-04-11 19:55:54

    避免做“紧急任务”的奴隶
     
    无论做什么事情都要有时间管理,这是我们一直关注的话题,一般时间管理可以分为四个部分,这样才能很高的提高自己的工作效率。
    1. 重要而且紧急
    2. 重要但是不紧急
    3. 不重要但是很紧急
    4. 不重要而且不紧急
    根据这个把要做的事情一一标注,哪个先做,哪个后做,并留出一定的缓冲.而且不会把自己搞得太累。
    但是最近在工作中发现其实并不是这样的 即使你想按这样做领导也不会答应你这样,在他眼里样样是紧急的事情。目前碰到一个项目 最高领导 要求要一周加4天班9月15日内完成任务,任务到达下来到我们直接领导变成9月4日完成。而且所有的任务都变成死任务非常紧急的任务,嗨没办法……一级压一级压死人咯!

         在工作时间管理中8-2原理是十分重要的,要让20%的投入产生80%的效益。只要把握一天中20%的经典时间(有些人是早上上班时间有些人
    是下午,如果是晚上只能自己认命加班),专门用于你对于关键问题的思考和准备。
      有那么多的“紧急事”和“重要事”,想把每件都做到最好是不实际的。建议你把“必须做的”和“尽量做的”分开。必须做的要做到最
    好,但是尽量做得尽力而为就可。建议用良好的态度和胸怀接受那些不能改变的事情,多关注那些你能够改变的事情。以终为始,做一个长期的蓝图规划,一步一步地向你的目标迈进。这样,就能一步步地看到进展,就会更有动力、自信地继做下去。

    本文转自:http://www.51testing.com/?uid-240349-action-viewspace-itemid-111139

  • 【原创】短暂测试组长体会

    applejuzi 发布于 2011-06-26 16:31:09

      由于测试组长有事,请假一个月,所以我有幸体会了一次测试组长的工作,感慨颇多,简单总结了,具体如下:

    1、  任务比较多时,需要根据优先级来安排任务,哪个最着急先完成哪个,且最好是记录下来排个顺序。因为有些任务是电话、开会上口头说的,有些是零散的邮件说明的,如果时间一长估计就忘了。这个我也就遇到过,当时项目经理隔三差五的给发个邮件说要完成哪些任务,我基本上都是来了任务就分配下去,未弄明白优先级,导致后来忙的团团转,一会儿要这个报告,一会儿要那个报告,结果呢要不是没完成,要不是就完成的质量不行。

    2、  任务的细节最好搞清楚。比如要专项测试时问清楚测试版本,测试时是否需要抓相应的log,对结果反馈有没有特殊要求,如果在测试期间有新版了是否需要更换新版本测试,之前旧版本测试过的是否需呀用新版本再次验证….

    3、  对任务完成的进度、bug数等相关信息要很熟悉,并能随时说出来。这个我也做的不好,记得开周会的时候被项目经理问及系统测试完成的进度如何,在规定时间是否可以完成,现在bug是否多不多,集中在哪些模块….,我当时脑袋都蒙了,不知道需要了解这些信息。当时我就说任务差不多能够完成,发现的bug都已提交到bug库了,如果想了解的话可以上那里查看。项目经理听了没说什么,我觉得自己做的很差。开完会后我就赶紧挨个问组内成员是否可以在预期的时间内完成任务。有了这一次的教训,在下次的例会上我就先做了相关方面的工作,任务分配下去了,过一段时间邮件或电话询问进度,然后也时不时的上库中查看Bug。

    4、  测试人力方面有困难要及时找测试经理。当时也是测试时又来了个很着急的任务,人力实在有限,这个任务又不能延后,我都不知道怎么办,只是跟项目经理说人力有限,要完成的话很难。项目经理还比较好,知道我是临时的,所以她直接找到测试经理说明任务,一番沟通后又支援了一人,这样任务就能完成了。不知道为啥我自己就没想到找测试经理,当时的想法就是自己加班来完成,但那段时间我都连续家加了好几次班了。

    5、  了解组内成员的能力。当时测试时人力有限,有3个人被临时支援测试。分任务前我先电话了解这个人之前测试的模块,也通过他们的领导了解到这几个人的测试水平,然后再分任务时可以有的放矢,将重要的模块分给能力强的,对于走case慢但发现Bug能力强的可以将任务少分点,让有时间做自由测试,以发现更多的bug.这方面我还是做的可以的。

    6、  适时鼓励、赞美组内成员。前段时间是比较关键的时候,任务多、重,过几个星期就要出货了,所以周末难免要加班,平时晚上也要加班,同事都有怨气了,这几个人都是临时支援的,普遍有种只是完成任务,给我的感觉就是没有那种很尽力的感觉。我也能理解,所以当人发现比较好的bug时我都会发邮件赞美一番,或者是他们的工作习惯很不错时也会适时的赞美一下,组内有个新人很久都没发现bug,在这期间突然发现了几个bug,而且个别Bug也不错,为此我也特别发邮件鼓励了一番,没想到后来发现bug的数量有所增加。我不知道是否和我的鼓励有关,但进步了总该是好事。如果能细心认真的观察组内的成员,相信多多少少有一些闪光点是值得我去学习的。

     

    目前的体会就这些了,毕竟经历的时间有限,相信如果在这个职位上工作的时间更长的话会有更多的体会,希望大家拍砖,谢谢。

  • 提升员工士气的七大法则

    xinxinxingxing 发布于 2011-10-09 18:02:15

    导读:文章选自作者MARCUS ERB的《Seven Ways to Boost Employee Morale》,文中资料摘取于国外公司的成功实例,通过分析筛选,列举出7个可以帮助改善、提高员工士气的方法方式。仁者见仁,智者见者,如何才能最有效地提升士气,都是因人而异的,方法并不千篇一律,本文供大家参考与讨论。

    以下是文章摘要:

    员工的工作进度是否一拖再拖?办公室是否很少听到欢声笑语?如果你的公司已经出现这个状况,员工士气如此低迷,那就要赶紧采取措施重振员工的士气。

    员工士气的低迷可能会导致在工作中团队合作不融洽,工作效率缓慢和营业额下降,总体来说,如此下去将会阻碍公司的发展。

    如何让员工尽快重拾士气?如何打破公司的这种僵局?领导们应该从工作中密切观察和记录并即时的想办法来改变这样的状况,让员工保持积极向上的工作态度,对公对私都有非常有利。现在分享七个可以重振员工士气的诀窍:

    1.让员工感受他们的工作不仅仅是一份工作

    每个人期盼着自己的工作能更上一层楼,但在某些时候,员工在日复一日的重复工作中就慢慢地迷失了自己的方向。

    Snagajob.com是一家在线搜索公司,分别在Glen Allen,Virginia,inspires地区通过“I Got a Job”的故事激励了126名员工,告诉他们自己的工作价值。得到帮助的员工们通过邮件发送到Snagajob公司网站,分享自己现实生活中的故事。

    2.举办庆功宴

    庆功宴为员工带来的不仅是一顿饱餐,而是从心里的感动。因为员工会明白自己的工作做出了价值,那种感觉不可言喻,在此同时,也能从中了解自己的工作情况好与坏。

    Sheboygan金融服务公司,每年每个部门都将自己团队完成的重大项目列成名单,然后,从所有名单中选出100个最杰出的项目列入“100杰出项目”名单中。最后,名单将制作成书刊并列入吉尼斯纪录,已有831名员工记录在案。

    3.让员工追求自己的个人项目

    个人项目是一个突破常规并激励员工的一种任务方式,同时可以成为公司的创新之源。

    位于悉尼的协作软件开发商Atlassian,在“FedEx Day”鼓励员工各自创新。在这期间,所有62名员工可以做任何创新的工作,只是要关系到Atlassian公司的产品或是工艺。例如,在周四下午2点到周五下午4点之间,公司会分配员工一个项目(名曰FedEx Day)。活动结束之际,由员工展示自己的项目成果。到此时,Atlassian公司已经采用了十多个成果项目。

    4.混合公司的一贯做法

    从传统例会或是沉默的工作环境作为起点出发,发展到高昂的士气的道路需要花费很长的时间。

    位于丹佛的Ehrhardt Keefe teiner & Hottman会计事务所,将387名员工安排到社区办公,每个楼层的办公室都有着不同的特色,并且公司定期举行聚会。例如,公司开全体大会的当天,公司还会举办一场篮球比赛。所有员工都可以参加并且任意组队,其中最有乐趣的是,每个员工都会绞尽脑汁为自己的球队起名,自制球衣,吉祥物和组织拉拉队等,场面极其热闹、欢快。

    5.不要忘记娱乐

    位于Rockton的折扣网站公司FatWallet定期举办集体娱乐活动,活动已经成为公司日程安排中不可缺少的一部分。在每月定期的活动当天,公司邀请55名员工来参与活动游戏,游戏包括棋盘游戏和模拟保龄球比赛。除此之外,当员工在日常工作中完成了定制的目标,公司还会额外提供娱乐项目。例如:冰球比赛,赌场或是游乐园。其中,团队集体游戏有两项,芝加哥城市寻宝游戏和屋顶Cubs游戏。

    6.培养员工积极向上的态度

    回顾2009年,位于Oshkosh的促销品制造商4Imprint,因员工士气问题,导致公司止步不前,直接成为了公司首要解决的难题。为此,公司培训团队想出决策,想方设法的提高419位员工的士气。他们采用了让员工观看像阿姆斯特朗康复于癌症的这类鼓舞人心主题的视频,从视频中让员工学习这种毅力和积极向上、永不言败的态度。

    7.偶尔离开办公室

    通过社区服务来建立员工的士气和友情也是一种方法。

    Studer Group管理咨询公司,每月提供给114位员工四个小时的时间去做慈善志愿者或是组织此类活动。而且,公司部门也会参与志愿者的活动。(张祺/编译)

    作者介绍

    Marcus Erb是研究所的高级顾问,专注于金融,制造和医疗保健行业。

  • 感受SEO篇之蜕变三季

    dnqbs105 发布于 2011-10-11 17:13:37

    感受SEO篇之蜕变三季
    一、蜕变第一季
    由于做网站已有多年,很早就了解网站优化、网站排名等概念,但都是以为在Title,keywords,description这些里面好好规划下关键字而已,再则就是做好div+css布局使之符合web2.0就好了,如果这样排名还上不去的话,那就只能花钱了。从来不去想一个页面的左侧或右侧为何老是有相关的、热门的链接,从来不去想一个文章里怎么还搞什么链接等等,不过现在想想那是多么地幼稚和无知,直到在某人才网的广告上碰到了seowhy。
    看完了大致的教程,对seo的基础做了初步的理解,关键词密度、长尾关键词、跳出率、Google沙盒、PR值等这些十分崭新的概念,另外还有一些seo工具,利用它们竟然可以获取别人网站的很多信息,包括域名的历史、关键字的密度、死链接、外链数、pr值、搜索引擎模拟抓取页面等,总总这些让我对seo发生了浓厚的兴趣,原来网站优化里还是有太多太多的东西。
    二、蜕变第二季
    但再次经过一轮的学习后,又开始发觉seo并没有多么地复杂,总结下来,seo竟然可以归结一个词——“内优外链”,内优:结构优秀、内容优秀;外链:链接站最好要有相关性,但是我们不能为了链接而链接,优秀的站点都建议站长去链接。度假村再用另外一种思路归结一个词——“有限无限”,所谓有限就是一些网站内部的页面优化工作是有限的,像关键词布局、图片加alt属性、锚文本、链接优化、404页面、robots.txt等;所谓无限就是持续地添加原创或伪原创的文章,持续地增加有质量的外链。想想原来seo也无非就这些内容吧,此乃是第二次蜕变。
    三、蜕变第三季
    然而自认为对seo了解的差不多的时候,在我上第二课讲长尾关键词的时候,老师一句盖世经典的话在我屏幕上震撼了我有点虚傲的心态,这句话就是——SEO人才三个层次,三流的SEO人才只知道做外链、二流的SEO人才考虑做内容,一流的SEO人才探索挖掘用户的力量,让网站形成自发展的生态系统。
    是啊,自己添加那是多累呀,就是雇人那成本也是不少呀,让成千上百的用户不直觉地来更新、来做那些上文我提到的“无限”,那该是多么省心的一件事,想想现在哪个熟悉的网站不是那样呀,相当多的板块都是靠广大的浏览者自己支撑起来,网站更确切地功能无非就只是一个平台而已,一些空间博客是知识共享交友谈心的平台,一些电子商务网站是买家卖家交易的平台。
    因此一个网站的成功与否并不是单看流量而已,我们seo的侧重点应该就是要先考虑提升用户的体验,然后再去考虑搜索引擎的喜好才是,毕竟我们的网站是让用户用的,我们将来的利润也来自于他们,而不是搜索引擎。
    SEO仅仅只是网络营销的一种手段,一定不要为了SEO而SEO,现在业界比较普遍的看法是UE(用户体验)第一,SEO第二,最终达到UE与SEO的统一,这点SEO协会(seo.gov.cn)和SEO淘金者(seo.tj.cn)网站上也很多相关资料,因为搜索引擎最终的意愿是尊重用户的选择,水箱也就是用户觉得好的网站排在前列!所以学习SEO的最终目的就是要忘记SEO。
    后记
    学习SEO的最终目的就是要忘记SEO,我也许就是武侠小说里的“无我”、“无招胜有招”的境界吧,这也是我对seo的第三次蜕变,有种脱胎换骨的感觉,于是把这些感觉写下来和大家分享。

  • 项目经理问:为什么总是只有我在加班–挂包袱现象(转)

    rainy1985 发布于 2011-10-19 10:49:13

    现象

      最近和一位项目经理聊天。这位PM之前是个技术大牛,没什么搞不定的东西,而且做事也认真,也卖命。领导没理由不提拔这种牛人。所以,这个项目让这哥们当PM。

      聊着聊着,这位牛人发出一声感慨,现在的员工不好带啊,每天到了晚上7点,就只剩我和另一个小组长了。项目组10多个人,都跑的精光。

      我乐了。其实这种情况,我也是碰到过的,在我带的第一个项目,也是类似的情况。我不敢武断的下决定,就跟他多聊了几句。

      问:那你大概几点下班的?

      答:每天都11点之后。

      问:任务很重吗?

      答:其实也不重。

      问:那些走了的人,你没有安排任务给他们吗?

      答:安排不了。

      问:为什么不能给他们安排任务呢?

      答:他们搞不定。

      问:为什么搞不定啊?

      答:我也不知道。我尝试给他们分配了任务,但是到头来,那些问题又到我和XXX(另一个小组长)手上了。

      后面我也不需要多问了,大概就是我估计的情况。

      我把这种情况,称之为:挂包袱现象

      分析

      为什么叫包袱现象呢?我们可以这么来描述。

      每个项目,其实是一个大包袱。一个公司有大大小小的许多包袱,每个包袱合理完整的解开了,里面就有利润。但是如果包袱解开不正确,就会减少利润,甚至破坏利润。

      那么每个包袱,都交给一个项目经理来解。项目经理带领一帮兄弟,负责把这个包袱合理的解开。而包袱是可分解的,也就是说,包袱可以分成大大小小的子包袱,如何解开子包袱,也是每个项目组成员的工作

      对于一个项目经理来说,最重要的工作,是如何把大包袱,合理的分解成小包袱,然后合理的分配给项目组成员来解,并且需要随时监控小包袱的解开情况,一旦发现有小包袱解开的步骤不合理,立即予以干预;如果发现有大包袱分解方式不合理,也必须尽早的改正。

      项目经理最重要的工作是不是,自己亲自撸袖子去解包袱呢?

      答案很容易说,当然不是。但是,一般初次做PM的人,就容易走进这个圈套。

      例子

      我们来说一个例子吧。

      项目经理甲,在项目一开始分配任务的时候,这么安排的:

      A同学,你做###1模块;B同学,你做###2模块;C同学,你做###3模块。剩下最难的###4模块和framework我来做。要求5天完成。

      OK,貌似挺合理的,ABC三位工程师就去干活了。

  • 项目经理问:为什么总是只有我在加班–挂包袱现象(2)

    rainy1985 发布于 2011-10-19 10:50:04

     A同学比较聪明,第一天就完成了50%,下班就走了。第二天就做完了,下班也走了,然后就优哉游哉的玩了三天,等着最后的时候昂首挺胸的汇报佳绩。

      B同学很卖力,但是偏偏###2模块比较麻烦。B同学第一天完成了50%,加班到8点下班了。第二天碰到一个难题,搞不定了。于是向甲求助。甲无奈去帮B同学分析了一下午,终于把这个问题解决了。这时甲延迟半天。第三天,B同学又碰到一个难题,再次请教甲,甲分析了一上午,搞不定了,于是扔下一句话:这个等我有空来看吧。于是,B同学第三天努力的分析问题,加班到10点。第四天,B同学想着反正甲答应解决的,于是在下班后就回家了,也没有加班。

      C同学是个新人,对于环境也不熟悉。第一天熟悉了一天开发环境。第二天毛毛糙糙的做了一点东西,感觉还不错。于是,第三天第四天,不用加班就把东西做出来了。第五天,C同学很开心的汇报说,工作做完了。

      第五天下班的时候,甲自己已经延迟了2天的进度,其中1天是因为帮助B同学,还有1天是因为各种会议、各种报销等闲杂事情,忙的焦头烂额。甲随便的问了下ABC的进度,发现A和C已经完成了,B的问题需要甲自己解决。

      于是,甲周末来加班了。在吃午饭的时候,随便瞄了一眼C的代码,乖乖,和自己的预期差的十万八千里。于是,只好把C的东西去掉,自己开始从头做。

      于是第二周,ABC都在等着甲。A等着甲分配任务,B等着甲帮着解决问题,C等着甲改造自己的程序。而甲还得赶紧把###4模块做出来,framework还有一堆BUG要改。

      于是,甲开始向周围的人抱怨,说自己的项目组如何不努力。在公司领导的干预下,甲公布了一条规定:每周一二三四,必须晚上9点钟下班。

      在第二周的周五,甲拖着疲惫的身躯,向大家宣布:项目进展不顺,周六加班。于是在抱怨声中,ABC只能无奈的周末来加班,陪着甲去解决问题。

      以上是个简化的描述,但是和大多数初当PM的人碰到的现象大差不差。

      对于项目经理甲来说,他分包袱的工作太随意,并且没有跟踪小组成员解包袱的进度,直接导致了最终的结果:所有的包袱都在自己的手上。这就是我所说的,挂包袱现象。

      很多技术牛人,都会不服气项目经理,认为这个人只是在分配任务,整天追着我们要工作进度,自己不做事,碰到难题就扔给我。但是一旦他自己做到了项目经理的位置,他就应该知道,分配任务,追着要进度,这就是项目经理的工作重心!

      我只是说工作重心,不是全部的工作。我也不会说,项目经理不需要写代码。项目经理适当的写些代码,对控制项目会有很大的帮助。这个我们以后再讨论。我们来分析下,项目经理如何去规避“挂包袱”的问题,让项目组成员能够一起来完成项目呢?

      改进

      1、首先,不要把组员想象的那么坏。

      很多项目经理,一旦看到项目组的组员弃自己不顾,径直就下班走了,就会大发雷霆,然后把组员定义为:坏孩子。然后,就不敢分配给组员任务了,什么东西不如自己做。就经常听到有PM抱怨,现在80后不好管,没有责任心。其实,我带过的80后,虽然个性强一点,但是责任心并没有想象的那么糟糕。虽然也有责任心不强的,但是不会一个项目组都那么差吧。出了问题,要从自己身上找原因。

      如果任务安排合理清晰,我想大多数工程师都会把任务的责任给担起来的。所以要注意以下几点:

      a)定义任务,一定要清晰明确。

      b)分配了任务,不能到最后再去检查。

      c)随时根据任务完成情况,来调整后面的工作。

      d)不要随意把任务收回来。

  • 项目经理问:为什么总是只有我在加班–挂包袱现象(3)

    rainy1985 发布于 2011-10-19 10:51:00

    2、其次,不要把组员想象的那么笨。

      很多技术牛人提拔上来的PM,都不敢相信自己下属的能力。他们一旦看到下属的代码写的不好,结构不好,用的API不对,注释不够清晰等等,就对下属的技术能力打上一个叉叉。在之后的工作中,什么都不敢放给下属做。下属一旦工作有点失误,就大发雷霆。

      记住,哪怕你的确是这个项目组里技术最牛的,你也不要这么做。为什么?

      a)公司无法给10个像你这么牛的人,让你做项目经理

      b)如果真的给了10个人让你来管,你未必管的了他们

      c)你如果太牛了,下属哪里来的机会去犯错。没有犯错的机会,怎么得到成长

      3、最后,不要把自己想象的那么神。

      这句话看上去跟前面两句差不多,其实还是有差别的。最大的意义就是:不要什么事情都自己做。记住,PM的目标是把项目做好,不是一个人的表演。你再牛,你也没法一个人做完10个人的项目。就算你做完了,也是10个人的功劳,不是你一个人的。所以,要放手给下属去做。

      改进例子

      我如果是项目经理,以上那个例子,我会这么安排。

      A去做最难的###4模块和framework。B做###2模块,C做###3模块,我自己做###1模块。

      第一天,我不会立即开始做###1模块。先看每人的工作。发现C做的代码不好,就安排B去辅导。

      第二天,B告诉我###2模块搞不定。我让他自己解决。我开始做我的###1模块。

      第三天,B还是搞不定。我帮他搞一上午,我发现了问题,然后告诉他如何解决,让B花一下午去解决。

      第四天,B还需要帮助C,所以时间不够了。我告诉B,你不要帮C了,你专心完成###2模块吧。我自己来帮C。A来向我抱怨工作太多,我说表现你的技术实力的时候到了。

      第五天,B又碰到问题了。我让他先自己解决。C已经完成了###3了,我让C帮我做###4,我同时看B的问题。

      第六天,如果项目紧张,可以加班一天。如果在BUFF的控制范围内,那可以在下周一完成。A做完了###4和framework,B的问题自己终于解决了,虽然我也解决了,但是我不告诉他,只是夸他做的很棒。C把###4也做完了,虽然我还要把###4再改进一下。

      我想,虽然工作很紧张,但是大家都加一天班(或者项目里程碑延期一天),基本上就都搞定了。每个人都有机会做出贡献,虽然忙,但是项目组的气氛还是不错的。

      挂包袱现象,是我自己提炼的,希望能给才做PM的人,以及以后希望在这方面有发展的人一些帮助。

     

  • 怎样做优秀的项目经理(转)

    rainy1985 发布于 2011-10-19 11:02:50

    如何做个好的项目经理?项目经理应该做什么?不应该做什么?这个问题涉及的范围很广,我只能就以前的一些项目经验谈谈个人的体会。难免有以偏盖全的地方,还请大家多提意见。

      1、项目经理应该做什么

      在整个项目组中,项目经理应该是整个项目的协调者和组织者,就好像是乐队的指挥,主要的职能是保证开发团队协调一致地工作

      首先,就是团队内部的沟通了。就像乐队里面有小提琴手,萨克斯手等一样,开发团队中也有开发人员,测试人员,部署配置人员,产品设计人员。如果这些人员各行其是,这个项目是肯定要失败的。项目经理的首要的职责是做好团队内的沟通,保证大家的工作协调一致,不会产生冲突。

      再有,和客户的沟通也是很重要的。因为开发团队中的大多数人是不和客户直接接触的,项目经理是团队和客户沟通的桥梁。了解客户对项目功能和进度的期望要求,并根据团队的开发情况及时给出反馈,才能保证项目进展比较顺畅。

      另外,项目资源的申请管理调配也是很重要的。项目资源包括人员,机器,网络,经费等等。合理的资源分配,可以大大加快项目的进度。

      2、项目经理不应该做什么

      有很多项目经理是技术出身,或者说是有技术背景。这当然会对开发项目有很大的帮助,但是同时也可能导致出现一些常犯的错误。

      首先是过多注重于技术细节的实现,而忽略了对项目总体节奏的把握。原则上来说,注重技术细节是件好事。但如果过分注重技术细节,就会过犹不及了。因为一个人的时间精力是有限的,在细节上花的时间太多,必然会影响对项目整体管理。所以,项目经理应该是面面俱到的,而不是只注重于某个方面。就好像乐队指挥,不会对萨克斯特别关注,除非他这方面出现了问题。

      其次是用个人能力代替了团队思考,有个人英雄的危险。很多项目经理个人经验是很强的,很多甚至是技术上的高手。但是项目经理这个角色,往往不是需要你成为个人英雄,而是成为很好的团队领导者,这两个要求是不一样的。就好像打仗勇敢的士兵,是一个好的士兵,但不一定就是一个合格的指挥官一样。与其过分依靠个人能力,不如激活团队的潜能,让每个成员都能发挥他们的最大能力,这样对项目的帮助会更大。

      另外,沟通不流畅也会存在某些项目中。为了解决这个问题,一些必要的会议还是非常有效的。但也注意会议效率,开会一定要为了解决问题而开,不能失去目标。

      3、黄金三角法则

      项目管理中有个很重要的黄金三角法则,是项目经理们要牢牢记住的,就是资源,时间,功能。这三者就像三角形的三条边,是项目管理的三要素,是互相制约的关系。如果一个项目,资源很少,时间很少,而实现的功能有很庞大,那显然是个不可能完成的任务。解决方法很简单,就是增加资源(人手,经费),延长项目时间,或者减少项目功能。当然在具体项目中,如何找到三者的最平衡点,如果达到最优化配置,有经验的项目经理会把握的很好。

      4、善于讨价还价

      我这里用讨价还价,并没有贬低的含义,正式的说法应该叫谈判能力。项目经理是项目计划的制定执行者,要和团队成员讨价还价,也要和客户讨价还价。所以这是很重要的能力,如果理解成到菜场买菜的讨价还价,也还是有点共同点的。

      5、计划要协商,执行要坚决

      简单地来说,就是项目计划制定的时候,是需要和大家沟通协商的,不然就可能是不切实际,空中楼阁了。但是一旦制定好了,大家一致认可以后,就是团队共同的承诺,进入了执行阶段。这时候,执行过程是非常坚决的,不存在讨价还价的余地的。一旦出现和计划不符的情况,需要严格查明原因,督促改进。

  • 项目级测试负责人的工作要点总结1-4(转)

    rainy1985 发布于 2011-10-19 11:32:36

      2、找到主体负责人

      如果一个测试任务分配给一个测试人员,毫无疑问,这个测试人员对这个任务、这个模块就是主体负责人。

      如果一个测试任务分配给多个测试人员,那么一定要找一个主体负责人,对这个测试任务进行负责---可能不是从测试能力的角度指定,而是从责任心的角度考虑。

      3、及时跟控

      对项目组所有的测试人员,希望对测试执行加强跟控频率。我们希望测试工程师都有主动性,如果有测试风险或测试延时都会主动站出来反馈问题。

      实际上,大多数人还是有惰性思维,总会找出一大堆借口理由拖延着不去工作。这就依赖于项目负责人的跟控程度。可能有这样的员工,你一天不过问,他就拖延着一天不做事情,而且理由还非常充分。

      实例:

      A员工测试某项目,早上版本未编译出,A员工也不向项目负责人反馈,开始在测试环境逛圈。下午项目负责人发现后,才反馈说版本未编译出。实际上,完全可以一早通知,由项目负责人重新安排工作,或者回退到上个版本执行测试。

      B员工和开发人员纠结在一起,反复的帮开发人员捕获信息,测试临时版本,对自己的测试计划造成严重冲击,也没有和项目负责人说明,导致项目测试计划延期。

      C员工测试执行一直不太好,他所负责的模块,是否需要安排人重新复测?

      项目的跟踪、控制非常考验一个项目负责人的工作能力,也是需要花费心思去做的事情。

      八、测试设备的控制

      一般的测试项目,比如增量开发、软件开发都不会触发到测试设备的变更。当然,还有一些测试项目,测试设备的变动比较大,这点就需要测试负责人注意记录设备的进出和分配情况。比如:

      ★ 新硬件项目开发,demo板卡较多

      ★ 硬件改版较多,A、B、C、D多批次硬件混杂,并分批退帐

      ★ 有外厂商设备或共用设备,在测试、硬件、开发多环节反复流转

      ★ 试验局,大批设备物资借用分配出账

      ★ 系统集成设备选型,不同厂家不同型号设备较多

      涉及到测试设备的控制,就需要对设备进入测试环境和离开测试环境进行明细的跟踪、设备和借条收据同步进行,再此不在赘述。

      九、版本发布资料的整理和准备

      在系统测试临近结束时,大体工内容如下:

      1、首先需要整理一套完整的待发布版本,此版本要包含业务程序、操作系统、boot文件、conf配置文件、debug文件以及硬件文件(如:红外文件等)。

      2、要求项目组测试人员使用此整理好的版本进行回归测试,同时完成版本发布检查表中的各项检查。

      3、对此版本的遗留问题及BUG数等数据进行统计,并提供产品测试报告和版本发布说明。

      特别要注意的是:

      第一、若所发布的是补丁版本一定要注意对版本发布维护表的更新,以便于客服、销售、生产对系统的新增功能及解决问题的了解;

      第二、若此项目的硬件存在多个版本,则需注意当前软件版本对不同硬件版本的兼容性,若出现无法同时兼容所有硬件版本时,需提供软硬件兼容列表,同时要注意及时更新。

  • 项目级测试负责人的工作要点总结1-3(转)

    rainy1985 发布于 2011-10-19 11:31:22

    六、测试用例testlab的选取

      (以TD为例)

      比如测试用例的执行约定都在TD上进行。关于testlab曾经有过讨论,如何制订统一的规范。比如部门约定的规范如下:

      TestLab修改要求:要求建立“第一轮SDV测试”、“第二轮SDV测试”、“第三轮SIT测试”、“SVT测试”、“冒烟测试”等文件夹,然后将相关测试用例分别导入。

      理论上未封闭版本不强制要求在TD上执行,但封闭版本的几轮测试在TD上必须有用例有执行记录。

      在实际的执行中,有两种习惯做法:

      1、由测试负责人统一拉去测试的testlab,在测试用例库中选择每轮次、每个功能点要执行的测试用例。

      2、由测试执行人自行拉去每个分配的功能点所要执行的测试用例。

      从测试控制和测试管理的角度,我们推荐使用第一种方式,这种方式,可以让测试负责人真正的知道测试执行和测试覆盖度,避免出现功能点已经覆盖但是漏测的现象。

      从长远来讲,在TD上为每轮测试、每个功能点的测试选择相应的测试用例,构建testlab,是测试负责人必需要完成的一项工作任务。

      七、测试任务落实和协调

      分解分配测试任务时应该注意几点:

      1、颗粒度

      对一些主动性好、测试经验丰富的人,安排任务的颗粒度可以大一些,其中一些优先级、测试任务的顺序安排也依赖自主性调控。

      对一些主动性较差,或测试经验较少的人,安排任务的颗粒度要细一些。以免出现测试人员面对一个庞大的系统,感觉无处入手,或者借口不知道怎么测试,测试什么的情况。

  • 项目级测试负责人的工作要点总结1(转)

    rainy1985 发布于 2011-10-19 11:28:29

    序:

      随着测试团队的不断增加,同时并行的项目越来越多,这就要求我们的测试人员快速的成长,要求我们每一个测试人员能够尽快培养具备基本的独立负责一个项目的整体测试及技术支持工作的能力。同时,项目并行会出现很多项目级别测试负责人的工作角色,对这个工作角色的主要工作内容进行汇总,供相关测试人员参考,给刚走向管理岗位的测试人员一些建议。

      整体而言,项目测试负责人主要承担的工作内容为:根据项目规格书制定测试策略及计划、根据项目规格书分解分配测试任务、及时了解测试进度、版本发布资料的整理和准备以及在项目后期对整个测试工作的总结,另外,对于大多数有相应试验局测试的版本,作为项目测试负责人还需要负责完成一部分试验局的工作。

      针对上述的一些工作点,以及日常工作中的一些工作重点,在下文做具体的说明:

      1、工作时间划分
      2、制定测试策略与计划
      3、构建测试用例学习规格书
      4、任务的分解分配
      5、测试进度跟控
      6、测试用例testlab的选取
      7、测试任务落实和协调
      8、测试设备的控制
      9、版本发布资料的整理和准备
      10、注意事项的填写
      11、CQ的跟控
      12、遍历每日打的bug
      13、Bug沟通
      14、每日拷机督促,上班确认拷机结果
      15、5分钟碰头会的控制
      16、未验证bug的类型和情况
      17、项目的保密和核心技术的保护意识
      18、测试工作总结
      19、版本文档备份
      20、主导试验局的实施

      正文:

      1、工作时间划分

      项目级别的测试负责人,除了项目管理、测试进度跟控之外,同时还会承担项目负责和测试工作。根据经验,项目级别测试负责人因为本身就是资深的测试人员,所以承担的测试模块往往是最核心的部分。 希望在分解分配任务时,大家能合理的分配属于自己的工作时间安排。

      因为日常的bug例会,bug的跟踪,和开发需求人员的交互,疑难问题的定位太过频繁,会影响自己本身测试工作的状态和效率。如果项目级测试负责人承担过多测试任务,肯定会成为项目测试的瓶颈点,表现结果为自己做了最多的事情,反而是测试执行最不利的一个环节。

      按照常规统计经验,建议项目整体跟控管理工作和具体测试工作的时间分配为6:4,或者5:5。

      2、制定测试策略与计划

      制定和刷新测试计划,是一个测试项目负责人最核心的工作,直观点说,就是对测试的整体把握和控制。在项目的计划阶段,测试负责人需要根据项目的计划安排(部分项目存在deadline)和规格书制定完成该项目的测试策略与计划。

      在开发阶段根据当前的项目进展情况及时进行更新。实际执行时,在BBFV阶段,新功能开发的进度往往和原定计划有出入,测试人员和测试设备可能有变动,可能有其他优先级更高的项目冲击等等情况。就需要项目测试负责人及时和SE、LPMT沟通,实时刷新计划。

      3、构建测试用例和学习规格书

      在项目初始阶段,测试用例的编写及更新是工作重点之一,因此在此阶段项目测试负责人需加强与需求、研发人员的沟通,对规格书应有一个全面深刻的了解,只有充分了解规格书的要求才能制定合理的测试策略与计划,才能编写出符合规格书的测试用例。

      关于测试用例编写的任务分配,在《由需求形成测试用例指导书》已经有相关建议:

      在学习规格书的时候需要注意对于系统原有功能的继承性、新功能的可测试性以及系统整体功能的实用性,并及时提出自己的意见和建议,从而规避当系统整体开发完成后发现系统无法实现客户的需求

  • 项目级测试负责人的工作要点总结1-2(转)

    rainy1985 发布于 2011-10-19 11:30:23

     组织相关测试人员学习系统规格书,并组织安排测试用例的编写及评审,同时在系统的整个进行过程中注意督促测试人员对测试用例的维护、更新及评审,确保测试用例与系统规格及当前的系统实现的一致性以及测试用例的正确性。

      根据目前项目特点,在SDV测试阶段、甚至包括版本发布前,都存在规格需求反复修改、增删、自相矛盾的可能性,如果动态的维护测试用例,保证测试用例的及时性、正确性和完整性,是测试负责人需要克服和解决的问题。

      因为是内嵌文件《由需求形成测试用例》,很多人容易忽略其中的内容。在分解分配测试用例,测试用例编写的阶段,很容易出现一些问题,比如:测试人员为新手,对业务不熟悉,构建测试用例时间较长,但用例适用性不大对需求规格没有达成一致,测试用例细化后,修改起来比较痛苦需求规格的变更,导致测试用例跟随变化成本太大,无法维护。

      4、任务的分解分配

      在项目进入系统测试之前,项目测试负责人需根据项目规格书分解分配测试任务并制定WBS计划,在制定WBS计划时需考虑项目的整体计划及系统发布的时间点,以及测试执行人对系统的熟悉程度。

      例如:一个功能如果交给一个对系统非常熟悉的人进行测试可能只需要一天而给一个对系统不是很熟悉的新人进行测试可能就需要两天。

      在制定WBS计划时若发现在系统发布时间点无法及时完成所有功能的测试,则需对整个系统功能的优先级进行排序,并及时提出预警信息,同时与SE和LPMT确认版本测试的基调:是调整发布时间或增加测试人员还是要求测试覆盖度到某一阀值,或对一部分优先级较低的功能只进行基本测试。

      而在测试时间充裕的情况下,则需充分考虑各项功能点的测试,特别是一些容易出问题或曾经出过问题的功能点需加强测试。

      五、测试进度跟控

      在项目的系统测试过程中,要及时了解测试进度,跟踪BUG提交、修复及验证情况以及系统的拷机情况。

      ★ 在开发初期阶段,测试组执行BBFV时,很多模块、功能点的开发完成进度和原计划会存在一定的偏差,就需要测试负责人动态的刷新WBS计划,根据实际的开发进度调整测试计划。

      ★ 在开发阶段,存在版本编译不出来导致无法测试,开发人员修复代码太随意导致版本稳定性反复,需求变更过大导致后端测试开发变更严重等现象,会导致测试工作无法正常进行。就需要测试负责人及时反馈出来,根据项目本身的特点进行对应的处理。

      ★ 当测试进度出现延期时,要及时确认问题原因,如果是问题协查导致,则需及时与研发人员进行沟通协商,看问题是否必须在测试环境进行排查,若为必现问题可与研发协商要求其在自己环境进行排查,若必须占用测试环境,则需及时调整测试计划,若因此可能影响版本的发布,则应及时与SE确认。

      ★ 若发现有较多BUG未解决,则应主动联系SE及研发人员召开BUG会确定问题的解决时间。若发现有较多BUG未验证,则应提醒项目组的测试人员及时进行验证,对于一些拷机或非必现的BUG,建议测试人员在此BUG上现做拷机标记,连续拷机一周未再复现的做关闭处理,若再次复现则继续进行排查。

      ★ 疑难问题的跟控:比较难复现的问题,怎么去尝试复现。比较难定位的问题,怎么驱动、反馈给SE,协调开发人员定位问题。比较难处理的问题,怎么跟控反馈进度等。

      ★ 每天下班前需确认拷机内容,每天上班第一件事需确认拷机结果,只有这样才能保证拷机的效果,实现拷机的真正意义。

      实际上,作为一个项目测试负责人,这部分工作是最重要和核心工作。

      很多测试的风险点,需要测试人员及时反馈出来,否则无法保证测试质量,也无法反馈产品真正的问题所在。同时,测试计划受到冲击太大的话,对测试计划和项目计划都是重大的风险,需要项目负责人及时反馈,以便解决问题,规避风险。比如:

      ★ 版本未编译通过

      ★ 版本不稳定

      ★ 版本反复崩溃,上周bug较少本周bug较多等

      ★ 开发人员占用测试环境时间太长,导致测试无法进行

      ★ 需求变更较大,测试执行无法保证

371/212>

我的存档

数据统计

  • 访问量: 751
  • 日志数: 1
  • 建立时间: 2008-05-05
  • 更新时间: 2008-05-05

RSS订阅

Open Toolbar