如何应对定制开发的恐惧

Question

我正在与我现在的雇主处理一个问题，这个问题严重让我考虑在其他地方寻找工作。它们的印象是100％的自定义开发应该被淘汰并替换为COTS产品，例如SharePoint。虽然我意识到这不是一个现实的期望，但我发现不可能与管理层中的人分享这些观点。他们的论点通常涉及SharePoint中已存在的功能，其中包含功能X，因此涉及的风险较小，并且不必对其进行测试。

例如，我们的情况是，SharePoint列表完全无法满足客户期望和要求。但是，将此数据保存在SQL数据库中很容易满足要求。然而，只要我们的开发团队建议超出SharePoint的界限，管理层就会对每行代码如何增加项目的复杂性并增加风险感到震惊。虽然在某些情况下肯定是这样，但情况并非总是如此。然而，他们的论点是，由于SharePoint提供了一种存储数据的机制，我们应该百分之百地使用它。无论是否满足客户要求。

我已经到了我讨厌上班的地步，因为我经常被迫做我认识的事情（100％肯定）是不对的，这可以通过自定义开发来做到。然而，这只是我工作的一个不可能的论点。

你们有没有遇到过类似的情况？如果是这样，你做了什么来应对这些挑战？

Answer 1

如果您不同意公司的愿景，如果您无法启发他们，那么确定，现在是开始寻找的好时机。

您是否指出在客户端强制“解决方案”存在风险，这种解决方案对他们没有帮助或缺少功能或无法使用？

或许想出解决和减轻其感知风险的计划。

Answer 2

您记录您的疑虑并让您上面的人了解他们，然后您按照他们的要求行事。如果它不起作用，您有文档，您提出了问题。但是试着让它按照自己的方式运作，所以看起来你并没有试图破坏他们的计划。他们承担了更大的风险，因此他们承担了更大的责任。尽力让它按照自己的方式工作，并放弃担心它。

Answer 3

这可能听起来很糟糕，可能不是你想要的答案。在我的办公室里有一个鲜为人知的部门叫做“臭鼬工程”。人们自愿（通常在午休时间或编译时间）决定编写一些帮助公司的小程序。有趣的是，结果不会给公司带来任何“成本”。

谈话通常是这样的：

“我们需要购买此软件”-Boss

“但是，我们已经持续了好几个月了。约翰，当天写回来了”-Programmer

“？” -Boss

很多时候，开发人员认为决定是坏事，只是创建一个自动发生的并行流程。然后，当东西撞到风扇并且客户感到沮丧时，替代解决方案已经到位。

我有一个自动释放机器的例子。开发人员过去常常创建这些自定义报告。随着客户的增加，开发人员的工作量也在增加。问题是“为了让客户得到自定义报告，开发人员必须参与进来。”因此，虽然该公司正在考虑聘请某人全职报告或寻找方法让客户这样做，但我写了一个自动发布机器，它会查找报告更改并将其直接发布给客户。我还编写了一个实用程序，允许任何人对报表进行更改，这些报表比开发人员更容易使用。当Boss宣布试图寻找解决方案时，我告诉他它已经到位，即使他可以对报告进行更改并让它们被释放。现在，每个人都可以更改报告，通常是进行这些更改的管理和客户支持。有趣的一面是开发人员不再参与其中。

做吧。如果你要退出，不妨试试。

Answer 4

管理层中有人拥有SharePoint中的股票吗？该系统是由CEO的弟弟开发的吗？

如果他们能够适应变化，你应该在尝试与他们争论之前找出真正的理由。他们可能会声称存在增加的复杂性，测试难度等等，但是如果你能用一个表明他们的立场，充分尊重，被误导，他们仍然不会讨论，那么你可能会争论错误的一点。

如果由于非技术原因而被锁定在技术中，例如有人曾经读过SharePoint在任何技术情况下都是最终的（当然，不知道文章除了SharePoint之外的其他内容） =好）然后你不应该费心争辩并节省你的精力。寻找工作。

Answer 5

向他们证明。当需求要求列表可以处理具有多列排序的100,000个项目时 - 编写一个脚本，将100,000个测试项目添加到共享点列表中并让他们尝试，最好是“客户”请求列表观看。 ： - ）

Answer 6

如果我是你，我一定会把我的简历拿到公开场合。您目前的体验不仅令人沮丧，而且从长远来看，这可能会严重影响您的职业发展。考虑一下。当你现在的雇主处于目前的职位时，其他开发人员正在采用新技术并扩展他们的经验。

开发人员之间存在着意识形态差异，以及公司对开发人员角色的看法。如果公开讨论和坦率让你无处可去，你就不会因为缺乏努力而受到指责。对公司的忠诚是一件好事，但这种关系需要成为一条双向的道路。

可悲的是，遗嘱最终可能会意识到他们的假设是错误的 - 但你不能等到那一天到来。有时它永远不会到来。特别是（并且不要误解我，我喜欢SharePoint用于它的目的），SharePoint成为下一个Access，因为阅读管理杂志的人看到了足够多的东西被称为弥赛亚。

Answer 7

我发现通过单独谈话通常无法“赢得”这些辩论。许多管理者通过阅读管理导向的文章形成产品或解决方案的意见。看看你是否能找到一些反文章。

如果您可以举出SharePoint无法做到的事情的示例，并展示如何经济有效地通过自定义开发解决这些问题的示例，那么您就可以顺利完成。

错误在于尝试将这个与技术进行对话，而不是关于效率，成本效益和可维护性的讨论 - 这些都是将非技术管理人员用于考虑替代方案的咒语和指标。

如果您可以将这些问题的概念证明放在一起，那么眼睛糖果真的有助于在技术团队之外销售。

最后，祝你好运：）

Answer 8

我在目前的工作中做同样的事情，没有简单的方法来处理这种情况。我所能做的只是吞下我的论点，因为他们没有把我弄到任何地方，并按照我的管理层的要求行事。这个过程将违背你的基本程序员性质，使用最好的解决方案来完成手头的任务，并且可能在这个过程中构建一些很酷的东西，但是因为他们是老板，所以它真的是你唯一的解决方案。您可以尝试使用证据来定位案例，使用自定义解决方案更有意义。但如果你的老板和我的一样，那么在尖叫的比赛开始之前它就不会走得太远。唯一的另一个解决方案就是清理这个简历并找到一份新工作。

Answer 9

从第一天起，我就面临着同样的挑战。管理层自然不愿意在解决方案中添加自定义代码。但是在大多数情况下，可以解释为客户提供的正确解决方案包括一些自定义代码。

请记住，如果您认为可以在公共代码库中包含自定义代码，那么老板可能会批准这个想法。

Answer 10

我真的感受到了你的痛苦。

如果是我，我会利用业余时间收集证明我的观点并以易于理解的方式记录的信息。

如果他们只懂钱，谈钱，如果他们只了解恐惧（做“这个”，因为他们害怕“那个”），使用恐惧，在“他们的”解决方案中为他们找到可怕的东西。

记录每个新实施，产生的时间，金钱和问题。并记录您的解决方案。

他们可能没有在他们的解决方案中看到问题，因为他们专注于“你的”解决方案中没有问题。

Answer 11

我曾经在一个管理层没有建设性的地方工作，不像你描述的那么糟糕，但还不够糟糕。

有几种选择。一个是继续前进，为客户做最好的“物有所值”选项。你可能不得不让开发人员团结在一起，使这种“公民不服从”工作。

一个更有力的方法，真正让这个蠢货击中粉丝就是去客户端（如果是外部客户端或者如果你想保住你的工作，不要这样做）并列出要做什么如果是X和Y，这个项目就会发生在这个项目上。这几乎是讲故事的故事而且会变坏，但很有趣。

稍微好一点的方法就是上链并找到一个可以为你做出蠢事的赞助商。基本上回到你的老板身后。这可能会奏效，但它会为您与管理层的关系带来可预测的结果。

最后也是最困难的是确定持有任何自定义代码不良的观点的人并让他们参与对话，以找出他们获得信仰的地方，并通过示例来反驳。强调谈话，因为你必须倾听并理解他们潜在的顾虑（这不是关于自定义代码本身），只有在你获得那些人信任之后才能解决它们。

我无法告诉你哪种做事方式最有效，因为它在很大程度上取决于所涉人员。我所知道的是，你无法改变人们，根据我的经验，迄今为止解决问题的最佳方法是离开并与不是这样的人一起工作......

Answer 12

如何不调用自定义代码。相反，如果你将其称为“预期的SharePoint用户扩展”或其他东西，它可能会缓解围绕特定术语的误解。

另外，正如已经说过的，可能还有其他隐藏的原因，管理层正在推动这个议程。最好不要过早地猜测这些，因为很多都是有效的。

最后，还有很多地方需要发展。寻找更好的比赛并没有什么坏处。

祝你好运。