谈谈在项目过程中的发生争论与争吵

    有一句古话说的好， “ 有人的地方就有江湖”。

      与瀑布模式相比， 敏捷开发  更注重人与人的交流。 所以在开发过程中更有 可能会发生 各种争论、争吵。

    首先说为什么会吵起来？个人原因咱就不说了，只说说项目过程中时引起的争论甚至是争吵吧。

    1. 对于同一个问题，2个人有不同的观点，谁也说服不了谁

    2. 自己的想法或设计被多次否定，自己说不出来哪好，对方说不出来哪差

     3. 双 方理解不一致，导致结果偏离太大

    以上三条是我认为在项目开发过程中经常遇到的情景。

      咱们逐条分析一下。

      第一种，对于同一个问题的解决方案，有不同的观点是经常的事儿。如果2个人的设计预期结果一致，只是实现方式不一致，那么大家可以讨论一下谁的方案更优，如果没有明确结果，可以2个方案都做，用实践来证明。当然现实的开发过程中，由于时间有限等各种原因，我们必须做出取舍，可以选择投票表决。但是如果2个人的设计方案导致最终结果差异很大，那么就必须需要认真讨论一下了，这是不可避免的。根据业务需求来定主调，用户习惯和体验度为基准进行评判。实在评判不出来，还是推荐使用投票表决的方式去解决，“失利”的童鞋需要尊重结果。

      第二 种 ，这种情况多发生在开发人员与项目经理之间。开发人员接到任务，突破重重难关， 然后 提出某个想法或设计，项目经理觉得 如果用这种设计可能导致很大的问题  ，但一时又说不上来理由。而开发人员只是用这种方式可以实现需求，自己也说不上来哪好哪不好。谁也无法反驳谁，所以想法或设计就暂时被毙掉了。对于这种问题，我觉得首先是项目经理的经验不足所致，他要尽可能的说出来有可能产生什么问题，那么大家才能根据问题去探讨，开发人员也可以据此去优化。而开发人员必须能说出这么设计的出发点与好处。才有可能说服项目经理肯定你的想法或设计。

     第三 种 ，双方理解不一致导致争吵的现象是最常见的，也是最让人头疼的。 开发人员会认为当初按项目经理说的去开发，结果最后项目经理说开发人员 做的与他说的不一样，会认为项目经理是故意跟他过意不去。 如果导致出了大问题，还有推卸责任的嫌疑。双方的矛盾也可能会扩散到项目以外去。这是大家都不愿意看到的。如何解决这个问题？我觉得文档是最好的解决途径。敏捷开发中是需要有必要的文档的。需求和需求更改都需要简要的文档，出了问题就查文档，这就是最好的证据。

     其实我觉得项目中的争论是很有必要的。

      争论可以让大家更深刻的理解需求，可以集大家的知识与智慧快速提出合理的解决方案 ，可以使得大家的相互了解 ，还可以活跃开发气氛。这些都是非常有益于项目开发的。

     但是争论不是争吵，争论的有意义的，争吵是无谓的，如何控制争论的节奏，不至于升级到争吵，是作为项目经理要做的重要工作。