何时面对一个好的项目负责人或老板

我们的项目负责人是一位天才的软件架构师，总体上是一个温柔体贴的人，天生怪胎，声音细腻。但是，有时，我们（我和我的队友）对我们的领导者有不同的看法，尤其是在软件体系结构问题，系统设计问题，UI问题等方面。

我们应何时，如何（如有）表达意见分歧？

假设您认为老板错了。您有三个选择

• 照他说的去做，最后沮丧地想到你做某件事是愚蠢的-长期不是很好
• 告诉他他是个白痴-他会忽略它，否则您会遇到交流问题-一无所获或伤害您。
• 告诉他您对他提出的想法有特定的担忧并解释这些担忧 -任何优秀的老板都会解释他的职位，然后您就可以做出对企业有利的决定。您很可能会发现他的想法比您的想法更好，并且您一直在忽略一些非常重要的事情。

总是想想结果。在大多数情况下，您并不想为了正确而做对，而只是做好工作。第三种选择有助于实现这一目标。

以同样的方式对待他-在表达反对意见时要轻柔而恭敬。

成为专业人士意味着要尊重您的同辈和上级，但这并不意味着您不能不同意它，而是意味着它本质上应该礼貌和尊重。

当我的团队对我的方向有疑问或反对意见时，我会将其视为自己和团队成员接受教育的机会。

这不是旧的攻击性或被动谬论的例子吗？

经典的第三个选择是自信，它允许建设性的批评和礼貌的分歧。

同样重要的是- 接受建设性的批评（不一定同意），并接受合理的分歧（不要迷恋谁是对谁错）。

http://en.wikipedia.org/wiki/断言

归根结底，总是需要一种被动性-服从上级。他是对决策负有最终责任的人-能力，权威和责任不是一回事，但至少它们应该并存。

顺便说一句，罗伯特·博尔顿（Robert Bolton）撰写的《人际技巧》是一本不错的书（而且相当便宜），它涉及诸如听力技巧，自信等方面的事情。

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

由于您似乎尊重他并且他看起来很聪明，所以为什么不通过以下方式问他：

“您的方法/方式/架构如何处理x问题？” 如果没有，请说出类似的内容：“那么，这样处理x问题又如何呢？”

这样，您可以了解他是否已经想到了“ x问题”，以及他是否学到了一些东西。或者，如果他没有，他会考虑一下，也许使用您的解决方案或想到另一个解决方案（也许您会一起解决）。

我希望我能提出一个更具体的例子，但我认为您应该能够理解。

我认为您不会先去找老板，特别是如果他不是程序员或类似的人。

不必说他的方法是不好的，但是通过询问它如何处理某些情况，他可能会意识到一个问题，或者能够告诉您为什么它不是问题。

我希望这有帮助。

使用单词CONFRONT表示您没有以正确的思维方式解决问题。

这不是对抗。这不是敌对的。这不是好战或生气。这是对不同方法以及成本和收益的讨论。

不要带着六把枪燃烧。只是告诉他您想到的事情。“如果我们要这样做怎么办？” 谁知道，您可能会说服他。

而且，如果您不这样做，有时甚至不会，请记住，他可能很了解您不了解的事情，例如预算，进度，要求，其他优先事项等等。他不一定是白痴，只是因为他不同意你的看法。

质疑任何决定或给定的设计/软件体系结构是没有错的。除非当你刚开始你的第一份工作，在这种情况下，你会因为你缺乏的某些部分是时间错误的99％大局观。

当您（和/或团队）意见分歧时，请问项目负责人是否有时间讨论，甚至计划召开一次小型会议（15-30分钟）。用尊重的方式表达自己的观点，并听他为什么做出其他决定。如果我看到您对他的描述，他将很乐意讨论和分享他对该问题的见解。他不会说“因为我这么说”（这样的人可悲地存在）。在这种情况下，如果您想保留自己的工作，或者忽略它而辞职去另一份工作，因为您会感到不高兴，请忽略您的意见。

一个好的讨论可能以几种方式结束：

• 项目负责人将接受您的解决方案，以作为解决问题的更好方法（他可能已经学会了一种新技术，新模式，……他还没有太多的经验）。
• 您和团队可以看到更大的图片部分，或者得到很好的解释，为什么要使用这种方式。您将学到一些新知识，并了解最初的解决方案是正确的解决方案，或者甚至可以找到一种利用新信息进行改进的方法（尽管在某些时候您必须同意）。
• 讨论没有帮助，您仍然不同意。整理并实施他的解决方案（因为他很可能会拥有更多经验），否则就离开。

无论如何，您应该将其视为学习的机会，并且只要保持文明和尊重，您将在这些讨论中拥有丰富的经验。

只是把它！

我通常会以最温和和切肉的方式说：“我关心这方面，您对这个潜在问题有何看法？”

我把球传到他的球场上教育我。

成熟的开发人员和经理的＃1标志是，他们能够承认自己做错了。首先向您的老板证明，所有人都非常愿意承认自己错了，并向老板明确表示您希望他们也给予同样的礼貌。

如果您有一个好老板（并且您说可以），那么这通常根本不是问题！您将看到您可以进行富有建设性的讨论，并为所有人提供最佳解决方案。

您需要注意的一件事：确保大多数时候您有实际的技术依据，有充分的理由对建议的设计表示怀疑。通常，“感觉错了”是远远不够的，并且不会有助于进行建设性的讨论。如果这种情况经常发生，那么您的老板别无选择，只能将“讨论”（这是事实，不要真正讨论）短路，然后说“对不起，但您会按照我的建议做，直到可以为止。事实证明为什么其他一些想法明显更好。”

这就是您的老板是老板的原因-做出开发人员可能难以做出的决定。

在我看来以及我与上司的一般行为：

当话题很热时，请务必给出您的意见并尽快处理。理想情况下，当您对新问题或新项目有争执时，而不是在集结勇气和决策已经确定之后再进行时。

您应该公开地提出您的意见，疑虑和问题，并确保它们作为建议或疑虑而出现，而不是强加必须以这种方式进行。

养成习惯，成为更好的沟通者，团队成员，进而成为更好的团队。一个好的团队会公开谈论负面和正面的事情。一个好的团队领导者将听取他/她的团队的意见，并在考虑所提供的信息的基础上做出决定。

祝好运。

如果他是您所描述的优秀建筑师，请以受过教育的方式与他联系，并提出合理而具体的担忧理由。

如果您有时间/资源，请尝试对可能证明您是正确的方案进行一些测试，那么拥有一些数据将是一大优势。

与他交谈后，他只能：

a）与您同意：问题已解决！

b）拒绝他们并向您解释原因：也许毕竟您是错的人。

c）无缘无故拒绝他们：如果他不合理并且您完全确定，请对负责的项目表示关注，在这种情况下，您确实需要最新数据，如果可以的话，还需要团队其他成员的支持。这不会使建筑师感到非常高兴，但是要做的是符合道德的事情（想象您正在设计建筑物时看到结构上的缺陷...）

我的问题是：何时以及如何（是否？）表达意见分歧。

答案是肯定的。除非您遇到一些无法控制的罕见情况，甚至动荡或因工作而失去工作的可能性如此之大，否则您应该在遇到不同意见时与他人面对。

真正的关键是何时和如何。

第一个“何时”：每个环境都不尽相同，但有些地方每周举行会议或召开公开/圆桌讨论会，提出某些主题是进行此操作的合适场所。您不希望做的主要事情是使它像您在轻描淡写或公开一些您与其他1或2个人之间的个人设计论点。您正在挑战的人不会感到被挑战甚至在公开场合感到尴尬。对于这些情况，请尝试与相关人员安排1对1的会议以详细说明您的想法。

第二个“方法”：如果您要去找高级人士，请确保您一连串的鸭子都支持您的想法。您不能随便说说“必须停止所有Web表单，我们必须做MVC！”。当被问到“为什么？” 而且您说：“这就是每个人都在做的事，在所有杂志中都是这样”，这不会太远。准备进行反复的讨论，并被要求就您对体系结构，编码，设计，最佳实践等方面的想法进行辩护。如果您有一些可用的工作代码示例来进行辩证（即，使用一些测试工具来证明思想），则可能以及帮助。这里重要的是不要陷入自我战斗或让情绪上升。

最后，如果您有可靠，合理且合乎逻辑的建议，则应将其考虑在内。但是，也要准备好，这个世界上只有一些不讲理的人，除了自己之外，不想听别人的话。希望您不会因为这种个性而陷入困境。

祝好运！

我不确定您如何在不犯错误和不被错误质疑的情况下成为一名出色的软件架构师。我认为可以断定他以前曾处于这种情况。

聪明，成熟，专业的人无法忍受更好的想法的诱惑。即使一开始他因提出自己的想法而感到不高兴，但最后他还是应该走来走去，您将对此予以尊重。如果他既不成熟也不专业，那么您将面临更大的问题，也许这会给您带来启发。

如果他是一名专业建筑师，他将尊重并接受第二意见。但是，无论如何，您都需要根据事实/专业知识充分准备替代方案，并加以介绍。还请记住，关于体系结构，对于此类问题基本上存在两种不同的可能性：

1. 一种方法/设计可能是对是错，就像数学2 + 2 = 4而不是5。万一有错误，您需要根据事实异议尽快提出正确的解决方案。
2. 到目前为止，系统设计中最多的主题是可能的方法，这些方法不是唯一的。还有其他选择也可以使用，这些选择可以根据经验，口味，偏见，总体情况等进行选择。为了不对可能更好的方法进行监督，通常会进行演讲和讨论，鼓励开发人员大声疾呼并分享自己的观点。但也要记住，在敏捷编程中，有一些讨论阶段和实施阶段，这些阶段是明确定义的。