该帖子同步发自：(john7634的博客  访问该博客)

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

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

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

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

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

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

　　时区/地域冲突

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

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

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

　　新旧势力冲突

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

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

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

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

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

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

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

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

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

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

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