我多次目睹悲惨的悲剧。这是发生了什么：
那我该怎么办？保持“我告诉过你”的态度不会赢得朋友和影响人。有时候，岁月流逝，而第3步中的评论却被遗忘了。我绝对不想成为让世界想起麻烦的烦人的害虫。我经常坐下来，看着泰坦尼克号驶向欧洲。
看到糟糕的设计前进很令人沮丧。同样令人沮丧的是，我似乎无法说服其他人当前路径的未决危险。我在团队会议上做得很差，每个人都有不同的理解不同术语的方式。同样，自负倾向于赢得理性和思想。我正在寻找能够说服小组成员使用一些新的复杂想法的好的策略。
Answers:
如果可能，建议进行修改，这些修改不会增加项目的时间。尝试强调一下，如果现在还不做的话，那么以后重做将会更加痛苦。如果您要说服您的团队一个全新的方向更好，因为这可能会延迟项目，则将变得更加困难。
不要在会议中让人们处于防御状态，他们只会和您争夺胜利者。您不会让他们同意地球是圆形的。这是正常的政治（例如FoxNews上的任何人）
获得其他开发人员的尊重确实有帮助。如果您是团队的新成员，我认为您是SOL。因此，只要建立一些团队代表并真正尝试达到一个水平，以免您立即被解雇。当然，如果您总是比较悲观的话，那么您将被标记为“负”家伙。
对于简单的东西（即不影响进度表），请确保以最佳方式完成工作。如果您将精力投入到即时输出中（例如，构建测试用例或获得一些简单（但很酷）的功能），最终其他人会注意到您的代码可以可靠地工作并经受时间的考验。当您开始向他们展示代码的一些巧妙技巧时，他们会三思而后行将您射杀在所有人面前。
最后，我同意您不想执行“我告诉过您”的例程，但是一定要尝试在提示正确时向老板/技术负责人提供提示。也许用您的旧评论重新发送一封旧电子邮件。询问他们这是否有助于解决“新”问题。如果您不这样做，他们甚至不会记得您是第一次提出该建议的人。最终，他们会得到暗示，您不只是想在会议上炫耀。下次，他们会三思而后行，特别是如果绕过后，您的“旧”设计现在将替换当前已失效的设计。
尝试树立声誉，成为能够确定行之有效的人，而不仅仅是您认为在某些罕见用例中会遇到问题的人。当您看到这些潜在问题时，只需将它们视为一个脚注，以后可能需要解决。
人们在会众中发疯。在会议之外向关键人物提及您的问题。他们会认为这种威胁较小，可能会花一些时间来听听您的论点，而不是考虑为自己的设计辩护。他们可能还需要更多时间向您解释情况，为什么您可能有一个有效的论点，但是在v1.0中解决这个问题是不可行的。
键！完全了解您的直接主管的议程是参加会议的原因。也许他们认为这是一个较小的项目，而他们在会议上需要做的最后一件事就是反对者将时间从更重要的问题上夺走。请他们帮助您。
我看不出这种情况与拥有笨拙老板的孤独开发者有何不同。不幸的是，尽管我警告过即将来临的失败，但我仍然没有多少时间“相信”以某种方式构建项目并交付它的次数。这不仅使您可以建造建筑物，而且还可以独自将众所周知的泰坦尼克号驶入冰山。
正如您所描述的，当碎片撞到了众所周知的桶中时，我的警告早就被人们遗忘了。有时（对我来说是幸运的），在我不再参与该项目后的几个月甚至更糟的情况下。不幸的是，这让我的继任者以为我一定是疯了，因为您可以打赌老板否认有任何帮助:)
无论如何，一群“令人信服”的程序员可能像一个尖刻的上司一样笨拙，有时甚至更多，因为他们像杰夫·奥提到的那样毫无信心。发生这种情况时，您有足够的时间来解决问题。不要试图通过集体的大脑放屁来发出理性的声音。如果您能有效地做到这一点，那么您的位置就在国会中，而不是在办公桌旁编写软件的后面。
行动胜于雄辩，您可以：
显示（带有测试方案）正常情况下设计失败的原因。这可能会导致您参加的会议规模较小，并且可能只是您需要听的所有会议。
展示一个竞争产品，该产品充分解决了小组认为只是“拐角事件”的问题。例如，您会对Google预测其电子表格程序中的错误花费多长时间感到惊讶。
重申最后一个需要在交付前一周重新编写的项目。
换句话说，无论您做什么，第一步都是与一个人或一个（很小的）小组打交道。如果您的顾虑确实成立，我相信最好在开发一两个星期后再考虑。正如您指出的那样，请避免使用“我告诉过您”的立场。
如果可能，请在会议之前（或什至之后）审查设计，然后与设计师私下交谈。在所有同事面前开会时将他们击落，往往会使他们立即对您的建议感到防御和虚心，即使您认为自己有所帮助，也可能会导致“麻烦制造者”的声誉。
提出“批评”的一种好方法（但通常很困难）是提出主要问题-让其他人尝试回答您的问题并自己意识到缺陷。然后，这似乎更像他们自己的想法，他们将更有可能将其推进。同样，这在私人讨论中最有效，但在会议情况下可以是更外交，更有效的前进方式（注意：请尽量避免引起争论或长时间讨论以说服会议中的人。只是将想法传播出去，然后尝试在会议结束后放开它，然后与设计师聊天以“弄清我不太了解的内容”比“做一个简单的30分钟的人”更好。会议浪费了我整个上午”）
另一种方法是（通过外交）将您的建议通过电子邮件发送给首席设计师（或相关但很小的分发列表）。这可能有助于考虑您的想法，并且还为您提供了一个“纸本线索”，以支持将来的任何“我告诉过您”的情况（如果事情变成了梨形，您至少有证据表明您曾尝试提供帮助，但但是，如果情况变得如此糟糕，则可能是您在不合适的公司工作）
最后，请记住，有时您可能会“错”。与您交谈的人可能比您更清楚或更全面地了解他们的设计，并且有很好的理由采用他们的方法（例如，我最近被一个团队成员指责为创建“低效”设计，但是这是一个精心设计，因为我知道性能仍然可以接受，但可以将开发成本减半-这是业务决策，而不是代码质量决策。只是对其他人的想法持开放态度-有时，出于您未曾考虑的原因，对您来说似乎是个坏主意可能是个好主意。
当遇到“永远不会发生”的情况时，提醒他们过去必须修复那些“永远不会发生”的项目的所有时间。但是您必须小心不要碰到“我告诉过您”的信息。我发现提出过去的问题（以及解决这些问题的代价和痛苦如何）最有效，以讨论您为什么认为我们现在应该为该项目做些事情，作为您为什么认为在提出“永远不会发生。
我想也许您的问题是您说您随便提到一种避免问题的方法，也许您应该掌握更多信息，并向他们详细说明为什么这会对系统造成风险。有时，这意味着您有时间进行一些研究后，在第二次会议中提出该主题。为现在要做的事便宜，然后为以后做事的代价建立一个商业案例。
听起来，最好的选择是努力使自己升至团队领导地位。利用这些机会指出您所看到的这种力量，并且它本来可以避免的。您不需要这样做就卖掉当前的团队。
会议中首先将问题称为挑战。您解决问题，克服挑战。挑战是好事，问题不是。
慢慢开始，一次使用一项挑战。下次您希望老板采用您的想法之一时，请执行以下操作：
1.这是非常强大的。您正在做的是提供选择而不是最后通atum。最后通tim常常不被击倒，因为这不是他们的主意，只有一种选择。
2.您在这里的用词非常关键。“ 我需要你的帮助 ”。
3.让老板选择“ A”，“ B”或“ C”。实际上，让老板通过从“ A”，“ B”和“ C”中抽出部分来创建选项“ D”。您正在做的是让老板做出选择。
此时，您可以在乎他选择哪种选项，因为它们都是您的主意。他会认为他实际上正在解决问题，因为您让决策成为他的决定。