如果大三学生没有采纳您的建议，该怎么办？[关闭]

我正在领导一个由3-4个初级开发人员组成的团队。除编写代码外，我的工作是为大三学生提供监督和指导。

但是，我完全理解有多少开发人员会珍惜他们的工作自主权，并且我不想通过用我的思想和算法来喂他们来破坏他们的内在动力。我希望他们以自己的方式探索问题，自己思考，只有在他们真正面临无法解决的问题时才来找我。

当他们来找我时，有时我不得不提出一种完全不同的算法来解决该问题，因为他们的算法不够健壮（请记住，我是大四学生，而且看到的不止于此）。当然，我会以一种很好的方式来解释这一点，以免伤害他们的感受，并且我会轻轻地概述一下我的解决方案比他们的解决方案优越得多，没有屈尊的语气或谴责的词语。

但是，尽管如此，他们有时还是不愿意接受我的建议，部分是因为他们在自己的算法上投入了很多，或者部分是因为担心使用新方法会花费更多的学习时间，并使他们看起来像是在管理层无处可去。但是我内心深处非常清楚，我的算法比他们的算法好得多，他们应该采用它。

如果他们不采纳我的建议该怎么办？我应该只是要求他们按照我的方式走，还是应该让他们的头撞在墙上很多次，等他们回来？前者会使我成为独裁者，而后者则会花费我们宝贵的开发时间，并导致错误修复成本。我真的在两难中。

帮助他们了解为什么他们应该做出建议的更改。如果他们有充分的理由不进行更改，请听取他们的意见。进行讨论，并根据最佳做法达成协议。

由于以下原因，此方法很重要：

• 您希望他们基于可靠的业务/技术原因进行更改。弄清楚这些是什么很重要（任何人都请记住，您也可能错了，所以要谦虚...。）。
• 您真的想传达出建议背后的原因-这样，接收者将来会学会解决类似的问题。如果您的大三学生觉得他们正在向您学习一些很好的见解，那么您与您之间的关系也会更好。
• 如果您使用自己的资历并且不会证明您确实有充分的理由，那么您将不会受到尊重。
• 您的老板可能想相信您将大三的时间有效地用于创造真正价值的事情上，而不仅仅是为了做到这一点。

如果您很聪明，也可以通过提出问题来让他们得到答案。如果做得对，您的下级将自己得出正确的结论（因此，更愿意实施该结论）。问题示例：

• 您的代码假定访问生产数据库。我们如何改变它，使其仍然可以工作，并且可以在断开连接的开发环境中由JUnit进行正确的测试？（潜在答案：啊！我们应该使用依赖注入...。）
• 如果攻击者故意在您的在线数据输入表单中发送了一些巧妙构造的SQL，该怎么办？（可能的答案：啊！也许我们不应该通过连接来自互联网的未验证文本来构造SQL语句）

编辑：如果您成功说服了大三学生，正确的做法是听从您的建议，但他们仍然不愿意，不过这里还有一些其他建议：

• 探索为什么他们不愿意。他们有可能需要个人认识到，只要得到结果，就扔掉代码也没关系。或者可能是由于某个截止日期，他们感到自己受到时间压力。您需要知道，否则您将无法帮助他们.....
• 您可以指出他们可以将更改视为提高他们的重构技能的一种方式。一旦重构技能足够好，您就应该能够相对快速地重新利用甚至相当大和复杂的代码库。
• 您应该强调，所有内容都将在源代码控制中，因此如果需要，它们始终可以恢复为旧版本。

我讨厌我的上一个团队负责人的傲慢态度，但是我尊重他，因为他拥有卓越的技术知识，并且在不讲授我的情况下教给了我很多知识。最重要的是，他从未强迫我遵守他的计划。他会在我的计划中扮演魔鬼的拥护者，迫使我证明我的计划是完美无缺的。他会寻找漏洞，并等待我解释为什么它不是漏洞或成本更低的解决方案。他会问我是否有其他解决方案，如果我没有其他解决方案，请提出一些想法。我将不得不评估他的想法，并且他的计划不是最优的；或者，如果他确信我的计划是正确的，或者至少与他的风险回报率相同，那么他会批准。如果我的想法失败了，我将不得不尝试他的解决方案。

自由与期限之间必须权衡。您没有足够的时间来延长期限，也不能让您的下属违反期限。您必须有礼貌，但要与他们保持坚定，一旦他们尝试了算法并没有使它起作用，他们就有责任听您的话。以身作则证明您了解自己的东西。但是，同样重要的是让他们学习，不要教他们。

如果需要，请注意这一点。如您所述，如果这只是一个建议，那么他们应该可以自由地这样做。我会问一些问题：

• 您有权推动特定的解决方案吗？
• 该权限的范围是多少？
• 解决方案不好还是只是有所不同？

我敢肯定，您可以提出更多要求，但是前两个问题集中在您的权威上，最后一个问题是关于该问题是否真的值得推广。

以下答案还有很多其他要点，在这里我要补充一点，您需要将其更多地视为一个协作过程，在此过程中，您至少要与“团队”一起完成其中的一些工作，而不仅仅是向他们发布命令。他们将在与您一起解决问题时学习到更多，而不仅仅是被告知“考虑以这种方式做”。

学习实际上只发生在失败发生的地方，因为失败是一种动机，并且为将来的回忆提供记忆线索。这基本上就是我们所说的经验，在工作场所中的良好经验将来自失败并从失败中汲取经验。如果您的大三学生能够在第一时间使所有内容正确无误，那么他们要么什么都不会学，要么就不会大三。

如果您有太多的初级人员搞砸了事情，也许您的公司人员配置不正确，初级人员太多，时间紧迫需要经验丰富的人员来最大程度地降低您的风险，但是即使这样，您也会遇到问题和延误，因为高级开发人员会犯错从中学习。

您的大三学生将需要学习并获得经验，以便能够在期限紧迫的环境中应对。作为团队领导者，您要树立榜样并激励大三辈们高效地工作，但是现实是，如果您希望大三辈们真正学习一些东西，就必须抛开对个人自豪感的关注和对日程安排的关注。 ，因此您需要允许它们失败。因此，打电话是您的工作。有时，您需要给初中生留出一定的失败空间，然后耐心地带领他们进行审核，以向他们展示他们可以在何处改善他们的想法。在其他时候，您需要放下脚步，但是这样做的方式要让您证明这样做是出于真正的需要，而这并不能很好地反映出您的初中生的能力。

关于期限紧迫的问题，您需要在这里根据团队中相对的优势和劣势安排和分配工作。最终，钱不再随您而去。当您负责其他人时，您就不会遇到每个人的朋友，您就会在困难的环境中完成艰巨的工作。如何使每个人都站在一边，这取决于与他人讨论您的顾虑和问题，从而为您为什么需要团队成员以特定方式做某事提供了合理的理由。

根据我自己的亲身经历，您需要与大三学生留出一定的时间来讨论这两种想法的优点和缺点，然后共同寻找可以解决当前问题的最佳解决方案，甚至冒着使自己陷入困境的风险。被证明是错误的-然后继续前进。如果双方都无法在分配的时间之前达成共识，那么此时您需要在总结会议时总结一下所讨论的问题，并指出尚未达成共识。无论会议的结果如何，您都要感谢下级同学所花的时间，并表示您将以自己的决定回来不久。在仔细考虑了您的讨论之后，您可以选择分配额外的时间进行进一步的讨论，或者指示初中生根据会议的结果决定制定的计划。

是的，时间有时是宝贵的，但是当您选择接受初级人才时，您需要接受您负有投资并培养其专业发展的责任，因此您需要接受一段时间至少会花费您时间。

我想问一下您是否实际上在以一种不屈尊的方式提出您的建议。当您使用以下短语时：

我的解决方案比他们的解决方案优越得多

和

我深深地知道，我的算法比他们的算法好得多，他们应该采用它。

这使我认为您可能会遇到“我的方式是优越的”态度。没有人喜欢这种态度。过去收到此邮件后，我就积极地尝试使用其他算法来证明此人是错误的。可能您的大三学生也在做同样的事情。

更好的方法应该是与人坐下来讨论他们的算法。指出为什么您认为它不起作用，并以开放的心态聆听他们给您的答案。查看是否可以修改其算法以使其正常工作。

如果您大三的东西肯定行不通，请向他们解释为什么行不通。哪些部分不正确，或者以后会涉及重写，或者不适合业务模型。确保他们对您的原因有很好的了解。然后向他们解释您的算法，指出在什么地方可行，而他们的代码将失败。

首先，您知道大三未采纳您建议的真正原因吗？

有时候，您知道，由于新的观点和较新的CS教育，大三生实际上可能会比大四生写的更好。尽管作为高年级学生，您可能已经看到了更多真实的例子。但是我经常看到我的前辈有时会陷入的一个糟糕陷阱，就是忘记最佳实践会随着时间而改变。我确定这不适用于您，因为您已经在此类网站上进行了自我更新。;）

我建议尝试在没有任何（或很少）大四学生的“光环”的情况下与您的初中接触，尝试与他们进行水平交谈，对他们编写的代码表现出好奇心。提出问题，听听他们的回答。请勿以如下方式提出要求：

“您的代码非常不灵活，您需要将其更改为此。。。”

相反问

“我只是想知道，如果有人要...您的代码能处理这个吗？...我认为策略模式可能会在这里有所帮助。您怎么看？”

我相信这将帮助您与他们进行更健康的对话，而不像像教授/讲师那样一无所知地低头看着他们。它还将帮助您更好地了解他们的推理和观点。

您控制对存储库的推送访问吗？

在开源中，推送访问始终由负责执行质量的网守控制。如果您正在积极监视他们正在推动的提交，则应该敏锐地意识到他们可以改进的地方。

他们是否可以破解或改进您的代码。如果他们有机会了解有关代码工作方式的内部信息，他们可能会学习如何更好地适应您的样式。如果您在提出建议时没有开阔的胸怀接受建议，那么他们将不太愿意听取您的意见。

在某些情况下，没有正确的答案（例如，编码样式首选项）。在这种情况下，请尝试建立（或执行）公司范围内的政策，以便他们理解代码的风格应与主要代码库保持一致。使用已经建立的样式指南（例如Microsoft的C＃样式指南）是最好的方法，特别是对于团队中的新开发人员而言。

如果您对他们的编码技术发表笼统的声明，则很有可能您不完全了解他们选择的原因。只是您的问题语气会让您听起来很自大。通过向年轻的开发人员推广您的方法，您会获得/牺牲什么？

您需要问自己的关键问题是，您的建议是否旨在维护/提高代码库的质量或主张您对同级的优势/优势？前者是简单的质量控制，因此可以证明其合理性，无论您的权利是否正确，阶梯都是不利于团队动力的。

无论哪种方式，如果您想将解决方案推向同行，您都应有具体的证据证明它确实是优越的。大幅提高性能应该足够容易地进行改进，少做任何事情都不值得（除了对性能至关重要的应用程序之外）。强迫您与他人合作以证明您个人的优越感会以“钩针编织的老头”被挑出来而告终。

注意：多年来，我遇到的最优秀，最有才华的程序员似乎总是愿意停止并解释其产生方法背后背后的故事。

嗯，这看起来很有趣，而且很自然，因为年轻的程序员非常喜欢他们编写的代码，也许他们花了很多时间才达到目标，或者他们是从某个不错的网站上选出来的（所以，确实，Hey Jon skeet编写了这篇文章。男人 ！ ！）。

尽管如此，这里附加的基本字符串还是代码的附件，您需要集中精力，我认为您需要付出一些努力才能使他们理解执行和预期结果比它们的名字更重要。蚀刻在源代码库中以推送此代码。您将不得不划清界限，这是为什么您的代码更好，并且在为将来的工作对其进行维护方面也很好。

考虑到会有一些失败的发生（任何依恋都需要一些心碎），但我会逐渐努力，相信他们会来临的，并且能够更好地欣赏您的努力。我认为您需要一点时间和很少的失败。将其强加给他们，将是围绕一些成功的故事，然后是世界末日和起义。

每个人都有不同的风格。如果您找到10个不同的人，并向他们提出一个不小的问题，他们将使用10种不同的“编码标准”样式为您提供10种不同的方法。

重点是：选择重要的东西。如果某位初级人员向您提供了一些东西，但没有给出正确的解决方案，那么它的效率是否会非常低下（+1个数量级，而不是此处或此处的说明），或者造成安全漏洞，请解释您的问题及其原因。如果是“我会做这个”评论，那太好了，您会做“那个”，而她做了“其他事情”，但问题仍然得到了充分解决（请参阅以上几点）。移至下一个功能或修复。

学会做一个好的领导者的一部分是要学会认识真正重要的事情和真正不重要的事情。另外，如果他们必须审核您的所有事务，则您会成为自己团队绩效的潜在瓶颈。

编辑：确保您的建议是真实的，没有蒙蔽的要求。一个建议就是这样-一个可以自由遵循或不遵循的建议。如果有要求，请说明。

正如其他一些人指出的那样，如果您真的只是在向初级开发人员提供建议，并且他们被这样说，那么您真的没有太多理由惹恼他们，如果他们不跟随他们的话，因为他们可能没有太多理由这样做。同样，您真的不能因为不遵循您的建议而be责他们，因为他们并不是以某种方式做事的实际方向。

关于尝试让初级开发人员按照您希望的方式进行操作：

• 控制您的术语，提出建议与提出建议并不相同，而提出建议与提供指导肯定不同。相应地使用术语来阐明您的观点，如果您认为做某事的方式是更好的做事方式，请告诉他们这样做是您的建议。同样，如果一定要以给定的方式完成事情（即不能承受时间延迟）绝对至关重要，那么请直言不讳，并为他们提供指导方法。
• 初级开发人员仍然在学习过程中，不管您如何措辞，除非有特定原因，否则始终在您告诉他们的内容后面提供某种推理。即使在那种情况下，大多数人也会理解，如果您说出这样的话：“必须这样做，我自己不在乎，但决定已经做出。” 他们往往是相当合理的。
• 如果确实是一个建议，那么请确保您的想法实际上比它的想法要好。如果您不这样认为，请与开发人员坐下来进行代码和概念审查，以便他们证明其解决方案的合理性。可能是一旦他们开始向其他人解释它-并且您提出了正确的问题-他们将看到更好的方法，并希望自己重新编码。
• 如果他们的解决方案与您最初建议的解决方案相似，请不要怀疑细节，这可能是因为他们考虑了您告诉他们的内容，并做了一些稍有不同的事情，或者根据您的建议更改了其原始概念。

这是对单元测试的完美介绍。如果您的初级开发人员有解决方案，那么它应该是可测试的。让他们进行单元测试以强调他们的代码。然后查看单元测试。如果您可以在测试中看到孔洞，那么很容易让它们重新运行测试并查看其溶液在压力下破裂。

这使您可以向他们展示为什么您的解决方案会更好，为您提供可以在代码更改时重用的单元测试，并为初级开发人员提供宝贵的学习经验。谁知道呢，您可能会发现他们的解决方案很好。

在某些时候，您必须负责。您听起来好像在努力让他们发表意见。您的建议可能并不完美。其他开发人员可能不了解/不同意您。他们可能彼此不同意。如果您负责，那不是民主。他们知道，当他们接受这份工作。

如果在任何情况下他们都必须跟随您，那么您就不应担任他们的老板，也没有任何目的。如果您不打算使用它，请将您在团队中的角色更改为资源而不是权限。在某些时候，您必须在可用的时间限制下交付最好的代码，并且在时间结束之前不能辩论，研究和辩论每一行代码。

发出命令。承受后果。从经验中学习。尊重是一条两条路。您正在演示，而事实并非如此。