开发软件是一个非常情绪化的工作，团队中的每一个人都希望这个软件可以获得成功，而有的时候这种情绪会在团队中制造紧张气氛。软件团队中流行着这样一句话：“你必须要挑选你自己的战斗。”那么问题来了，如何做这样的决定？你要跟谁干仗？
胜利和失败
团队在协作的时候，他们其实也在时刻彼此“斗争”中。在我看来，所谓的“胜利”只有一种情况：就是你成功说服另外一方，让他们接受你的想法，认同你的想法，让他们相信你的想法能让软
件变得更好。但是，“失败”却有着多种情况。如果你让团队中的某一个人觉得他的贡献没有价值，团队就会经历失败。还有产品本身也存在失败，例如在产品初期没有看到一些有价值的评论，或是错失了以更低的成本开发新功能的机会。
胜利剧本：
在策划会议上，一个开发人员指出，他找到了一个开发前制图工具，这个工具可以迅速绘制大多数产品功能图。然后产品团队表示他们愿意采纳这个开发人员的建议。
失败剧本：
在编码审核会议上，审核人员给编程人员施压，要他们立刻做出改变，短时间内显著提升软件的性能，但是审核人员并没有做出任何解释，没有告诉开发人员这样做会给团队带来什么好处。于是开发人员拒绝了审核人员要他们加班加点的要求。
在和团队中的其他人打口水仗之前，问问你自己下面几个问题：
你能胜利吗？
如果你反对产品的发展方向，但是这个问题团队成员之前已经讨论了多次，而且你此前已经阐述了自己的担心，那么你或许应该冷静一下。因为在这个问题上你很可能无法获得胜利。
如果你是技术团队负责人，而某个编码审核人员并没有按照你给项目定下的标准来对软件编码进行审核，那么这个时候你就应该勇敢的和对方开战——但是要小心。和对方针锋相对的“互撕”并不能起到作用，一次心平气和的谈话效果会更好。
值得吗？
这个问题对你的产品影响严重吗？如果你想推迟商务计划，优先解决产品功能问题，你要先想一想你能为公司在日后节省多少时间。如果只是几个小时，那么这不足以整个团队为你而改变。如果你能为公司节省一周的时间，那么这个问题绝对值得你摆到桌面上和大家一起分享。
假设你是一位编码审核人员，在一次编码审核会议上，另一位开发人员提出了一个新的不错的PR，但是它在风格上与你的风格不符，于是你想要和他争辩。
在这个时候，你应该问自己下面几个问题：
你的反馈能否成为编码库最好的选择？
你的想法能否给软件带来巨大的提升？
编码的可读性是否存在问题？
如果上面所有的问题，你的回答都是no，那么你最好不要在这个时候去争辩。这样做可以让开发人员觉得自己活得了应有的尊重，他们会觉得自己写出了优秀的代码。
挑战别人的工作方式能否给你的产品带来明显的好处？
在每一场优秀的战役中，参与方都在为了一些比自身更重要的东西而奋斗。在你挑战队友的时候，你应该有着足够好的理由，值得你去和队友争辩的理由。
在商业层明上，当你挑战同事的时候，你的目标应该是给产品的可读性和可行性带来更多的价值。在挑战其他开发人员的时候，你的目标应该是提高编码的质量，让产品更稳定、更可控。
选择失败的战役
虽然我鼓励你去参加那些把握性更高的战役，但是有的时候，选择一场注定失败的战役也是很重要的事情。这让你可以更进一步，加强团队成员之间的理解，让所有人都看到产品中需要改进的地方。
例如，在面对产品团队的时候，你可以故意提出一个你其实觉得很难用的UI设计。虽然你的建议不会被接受，但是在这个过程中，你的团队成员将会各抒己见，提出自己对现有UI的想法，从而完善产品现在的UI，让产品UI变得更好用。
当你在和另一位开发人员讨论的时候，选择一场失败的战役，给你带来的好处，就是让你们双方都获得宝贵的学习机会。你可能觉得你的代码已经很完美，但是其他开发人员总是能给你提出值得改进的地方。在一些情况下，这种讨论和研究甚至有可能会让你们之间找到一个更好的解决方式。
两败俱伤的战役
我们都见过那些两败俱伤的争论。通常情况下，当双方开始人身攻击，不再就事论事的时候，两败俱伤就无可避免了。在这种情况下，双方最常见的话语就是：“我不喜欢你的代码/设计/工作方式。”
甚至你自己也经历过这样的事情，尤其是当你某一天心情不好，而你的同事又来挑战你的时候。我们都会这样。当你意识到这种情况即将发生的时候，你就应该先后退一步，在平复心情之后，在找到对方进行一次没有相互攻击的对话，用这样的方式来解决问题。
如果是对方先开始攻击你，你可以先允许自己生气一会儿。当你冷静下来之后，然后和对方进行一次对话，客观的阐述自己的想法和担心。
打磨你的“战斗技能”
没 有任何一个人会永远胜利，理解何时应该挑战同时，何时应该控制自己，这是一个技巧，一个只能在实践中学习的技巧。我曾经在很多次争论中失败，有的是因为准 备不足，有的是因为我提出了一个并不重要的问题。还有的时候，我本应该马上提出自己的想法，但是却在当时忍了下来（这也是我写这篇文章的原因之一）。
情况越紧张，争论的价值越大，我发现在这种情况下，我们总是能将产品和团队打磨的更好。你是否也有这样的策略，用来决定自己何时应该质疑别人，何时应该沉默不语？
文章转载自 开源中国社区[http://www.oschina.net]
