艾伟也谈项目管理,软件研发中的冲突及解决之道

  

  深圳易方数码科技新技术研究主管,微软MVP时永安认为:

  软件项目在研发过程中牵涉到很多利益相关方,这些相关方因为关注角度的不同,会产生很多矛盾冲突。这些冲突,轻则打击士气,拖延项目的进度,重则使项目无法正常进行。在我这些年的软件项目管理工作中,遇到过各种各样的冲突,其中最常见的有:项目开发周期的冲突和团队内部人际关系的冲突。

  软件项目的研发周期,本来是应该根据项目工作量和开发人员情况来估算的。但现实中,往往会受到市场部门以及公司高层的干涉。他们从产品销售的角度考虑,希望软件产品越早发布越好,在他们眼里软件开发弹性极大,只要给的压力足够大,就可以成功地将开发周期缩短。作为开发人员,我很清楚如果按照他们的要求随意确定开发周期,就意味着无休止的加班、低沉的士气以及进度的一再拖延。这就有了冲突,因为双方都觉得自己有道理而不愿让步。出现这种情况时,互相妥协是唯一的办法。项目主管可以通过安排适量的加班,削减或者推迟部分功能的办法来做出一定的让步,但这种妥协一定要有底线,过度的妥协会导致一个无法达成的开发进度计划,对项目造成极大的伤害。

  如果说上述冲突是外患的话,那项目团队内部的人际冲突就是内忧。软件开发人员往往表面看似低调,其实内心骄傲,他们对自己的智力充满了自信,最无法容忍的就是自己的工作成果被否定。进行Code Review及Bug责任人确定时,最容易引起内部冲突。处理这种冲突有赖于项目主管的管理技巧以及公平的处事原则,同时把对事不对人的工作态度灌输给项目中的每个成员。冲突发生时,既要坚持原则,有理有据地作出分析,也要注意照顾双方的情绪,多做安抚工作。

  总之,软件研发过程中的冲突无法避免,但也不是洪水猛兽,只要积极应对,就可以将负面影响降到最低。

  

  IBM中国研发中心软件工程师崔康认为:

  软件研发团队会不可避免地遇到各种主观或客观的冲突,如何较好地解决矛盾是团队成熟与否的重要标志。我选择了两个典型案例,希望对读者有所启发。

  时区/地域冲突

  这是一种客观冲突。全球性的研发团队包含了来自不同时区和地域的工程师,在这种情况下,应该采用哪些协作方法来降低冲突带来的负面影响?处理这种冲突的关键在于提高沟通的质量,一方面要尽量不影响各地工程师的正常作息,另一方面要通过合适的安排来最大限度地利用时间差。我有以下建议。

  1. 团队例会时间由各个地区的工程师共同商议确定,选择一个大家都醒着的时间段,如果困难,则采用定期轮换的方式让大家公平地享受熬夜。开会采用视频或者电话形式,不鼓励使用文字交流,书面会议纪要由团队成员轮流记录。会议之前确定议题方案、备选方案、决策规则等,提前发给团队成员,开会时直奔主题,不延时。会议纪要必须包含下一步的行动计划,具体到每个人,得到大家认可后立即散会。

  2. 工作安排上,尽量利用时间差。换句话说,在某时区白天工作的成员要把当天的结果通过邮件等书面形式及时反馈给另一时区(稍后上班)的同事,形成良性循环,以便大家都能够在自己上班时看到前一时区同事的反馈并据此开展工作,然后在自己下班时将进展和问题反映给后面时区的同事。

  新旧势力冲突

  这是一种主观冲突。随着技术的不断发展,研发团队经常尝试引入一些技术或者方法,在这个过程中,新旧势力会发生冲突。当事一方是项目经理或者架构师,他们对新技术充满信心,并想尽快实践;另一方是团队普通成员,他们已经习惯了手头的老技术,应用自如,对新技术的实际作用存在疑问,不愿尝试。如果不能很好地解决,必然导致双方互相埋怨,新技术推广艰难。分析其中原因,除了必要的沟通,还需务实的计划和实践。我有以下建议。

  1. 引入新技术和方法前,通过学习会议等形式让所有成员对新技术有充分的了解,但不要强制他们认可并马上实践。

  2. 制订循序渐进的增量引入计划,不要立即整个抛弃老技术,请团队成员一点一滴地试用新技术,逐步习惯甚至喜欢上它。

  3. 在技术过渡阶段,团队负责人和架构师等要实践其中,不能置身事外指指点点,及时听取团队各个成员的反馈,并作出相应调整。

  4. 定期召开团队会议,让成员根据自己的实践结果对新旧技术做评价对比,培养认可新技术的氛围。时机成熟后,大规模采用新技术。

  5. 新技术引入后期阶段,团队管理层对成员表现进行肯定和奖励。

  

  趋势科技测试工程师张小明认为:

  有人的地方就有冲突和斗争,不管你在,还是不在,只要有人在,冲突就在那里,不多不少。作为一名普通的软件工程师,其实更愿意称自己是一枚程序员。我在国企、私企、外企都写过程序,编译过、运行过、调试过,可谓撒过汗、通过宵也掉过肉,在软件研发过程中自然也经历过大大小小不同类型的冲突。不同的企业有不同的文化(没有文化也是一种文化):国企的冲突往往被套上了制度的枷锁,私企的冲突往往和大当家的为人处世和经营理念有关,而外企的冲突往往不分尊卑,带有天马行空、各成一派的自由风格。

  我曾经在金融软件项目中做研发,该项目的开发模式是与客户(某大型国有银行)的开发部门共同合作,两拨人在一起办公,我们有一个项目经理,银行方面也有一个项目经理。虽然研发的主导力量在我们这边,但从理论上讲,人家是客户,我们是上门服务。冲突缘起于某次项目赶进度,对方项目经理要求加班,而我们有些成员不太情愿加班。这时对方经理要求自愿加班,而我们的项目经理带头拒绝加班,根本不给客户情面,于是导致客户非常愤怒。接着冲突升级,对方经理提出要致电我们老板要求当家的出面强制加班,结果冲突再次升级,老板的出面还是没能让我们项目经理接受加班。后来团队里抵制加班的相关同事被通报批评,并且被强制在客户面前书面道歉,而这件事的直接后果是这个项目组中的我们公司的研发人员全部跳槽。这是一次没有善终的冲突。

  作为一名普通工程师,我认为,既然从事这个行业,就应该端正自己的职业态度,你是为公司打工,更是为自己攒人品。不管当下的待遇或境遇有多差,我们可以选择其他方式解决或者高贵地离开,至少不应该把怨气发到客户的身上,但同时也必须从制度上杜绝以强凌弱的现象发生,比如违约金这种东西。

  上面举的例子比较偏激,而且我恰恰认为冲突不应该刻意去避免,优秀的团队文化应该鼓励适当的冲突,并进行引导,然后化解,而不是压抑住冲突(压抑久了就可能会导致上面的杯具再次发生)。作为一名程序员,我坚持认为良性的碰撞和冲突能产生火花和灵感,甚至是解决方案,但实现这些需要思考的前提是:如何构建和谐、优秀的团队氛围,从工程师的角度来看,我认为就是端正自己的职业态度。

时间: 2024-07-29 17:03:52

艾伟也谈项目管理,软件研发中的冲突及解决之道的相关文章

艾伟也谈项目管理,产品版本改造中的项目管理

近段时间,一直在负责一个产品版本改造(C/S系统进行B/S改造)的研发项目管理,在任务紧.时间短.团队成员又没有相关技术(Silverlight)背景的恶劣情况下,我带领包含我在内只有6个人员(5个研发人员,1个产品经理,产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了)的超小型项目团队,终于在公司给定的时间范围内完成了整个产品的版本改造.这其中经历了需求变更.技术风险.人员变动等诸多问题,项目任然取得了成功,这种使用新技术的试验项目能够取得成功不得不说有几分侥幸,更多的还是团队

艾伟也谈项目管理,项目管理的十大挑战

公司项目中的项目管理挑战 1. 不明确的目标:当目标不明确时,开发团队是不可能达到客户要求的.而且,由于上级管理层不会同意也不会支持不明确的目标,该项目成功的几率微乎其微.因而,项目经理应当通过询问恰当的问题,从一开始就建立并传达清晰的目标. 2. 范围变更:也称作"范围蔓延",当项目管理层允许项目的范围延伸到原始目标以外时,就会发生这种现象.当然,客户和项目监管员会要求修改项目,但一个优秀的项目经理会评估每一个请求.决定是否及如何实施,并且与每个利益相关人交流决策对预算与期限的影响.

艾伟也谈项目管理,谈谈如何说“不”

我曾所在的两个项目组,如果处理不好"不",则会给自己和团队带来很多问题,发生在我身上也有好几次. 项目组A:在不看好项目组开发方法的情况下仍旧敬业工作. 我在项目组A曾经担任过开发人员.开发经理和项目经理,我也在这个项目组投入了很多精力,它给了我很多成长环境,包括现在看到的OpenExpressApp 的思路以及对架构方法的兴趣也都是从那里一点一滴积累思考而来的.由于我调到总体部做平台去了就暂时离开了,但是我思考的大部分仍旧是如何解决以前发现的问题.后来项目组开发新版本时,我毅然过去支

艾伟也谈项目管理,假如我是一个项目总监/经理

就国内中小民营企业而言,项目总监/经理的角色最为尴尬.项目总监/经理不是一个行政上的title,所以没有行政.财务.人力上的权力:项目总监/经理也很少有项目提成或项目奖金:项目总监/经理更多的被视为因政治因素而临时授命的一个暂时性的英雄人物,一个能够带领一群初级工程师完成某项任务的高级技术工程师.简而言之,只有义务而缺乏权利. 在绝大多数中小民营企业中,抛开强烈的政治斗争不说,还缺乏完善的公司管理制度,缺乏正规的项目管理流程,缺乏足够的技术储备力量.所以身处民营企业这个漩涡中,需要考虑的不仅仅是

html文件中jquery与velocity变量中的$冲突的解决方法_jquery

问题描述: 在使用velocity模版引擎的环境下,使用jquery时,如:$.fullCalendar.gcalFeed('http://www.google.com/calendar/feeds/sfzc1%40realintelligence.com/public/basic') 其中$与velocity变量中的$冲突. 解决方案: 定义一个velocity变量:#set($jquery="$.") 然后:${jquery}fullCalendar.gcalFeed('http:

谢国忠:人民币升值非中美贸易不平衡解决之道

连锁效应 人民币升值并非中美贸易不平衡的终极解决之道 <环球企业家>专栏 谢国忠专栏 近来,美国政府和国会对人民币汇率的指责之声甚嚣尘上.最主要动机还是为了应对国内的就业压力:在即将于今年十一月进行的中期选举中,就业问题肯定是最重要的议题.在野的共和党可以借此指责民主党,而民主党想要把责任推到中国身上,作为政治上的权宜之计,这是意料之中的.尽管现在美国国会通过贸易保护措施的危险越来越大,我还是不相信他们会在年内采取实质性举措.如果国会真通过了某种重大提案,国际股市会重挫,迫使美国国会妥协. 今

艾伟也谈项目管理,敏捷实施中的常见错误

一些评论员写下了敏捷实施中一些常见错误和反模式.他们贴出了"Top X"列表,列出了需要避免的事项和他们曾在各种组织实现敏捷时见过的错误. Target Process的Michael Dubakov写了两篇博文:"10个敏捷实施中最常见的错误"(Part 1; Part 2 ).他认为"许多公司在敏捷实施中再三犯同样的错误." 他的常见错误列表如下: 1. 从一个工具开始敏捷开发是不同的.一个工具不会立刻产生影响,不会由于这一工具的存在而解决多

艾伟也谈项目管理,克服在企业中应用敏捷方法的技术挑战

在企业中应用敏捷方法是一项具有挑战性的任务.实现敏捷不像安装软件那样能在一天内完成.而是需要适应企业环境,其中包括:文化.技术和组织方面.本文将探讨面临的一些挑战,这些挑战与建立开发环境.自动化测试.持续集成相关,并且同在企业环境中明确完成的定义(DoD)相关. 建立开发环境 每位技术负责人和开发经理都想缩减团队成员建立开发环境的时间.然而,为了在项目中获得较高的产出,开发人员要持续投入许多精力,让事情变得有条不紊.缺乏文档,是建立开发环境时间过长的关键原因.第二个关键原因是建立过程中包含多少手

艾伟也谈项目管理,找出软件开发过程中的BUG,你需要火眼金睛

1)Bug大都出现在程序员的编码过程中.测试人员工作之一就是找出Bug,面对那些难以被人发现的Bug,测试人员通常会采取哪些手段?以您的经验,对广大测试人员有什么好的建议?对于开发人员,您有什么建议让他们减少Bug的产生? 之所以难以发现,大多是测试案例不够完整,检查测试案例是否全面覆盖了需求,等价类划得是不是够细有助于发现更多的问题. 如果已经发现的问题大多是猜测法发现的,那么惨了,这是一个天马行空的测试,所有的BUG都将是难以发现的BUG,碰运气吧.如果你真的是在这个不幸的团队,别伤心,你有