项目经理选择了一个过于复杂的设置，没有人有经验

最近，我启动了一个看起来并不难做的项目，这个概念是一个相当简单的应用程序，它必须不时地（也许一天10次）接受输入，并尝试对其执行一些操作并收集所有结果在末尾。然后，该应用程序将获得一个前端Web门户，供客户用来查看结果，而不是精确地了解火箭科学。

为此，我最初巧妙地使用了Python的内置并发库（ThreadPoolExecutor），并为前端使用了易于使用的库（我选择Flask是因为它对于初学者来说很容易，并且相对易于维护和测试）。

一旦我们完成了项目，项目经理表示我们必须使用第三方消息队列功能而不是线程，并且必须实现负载平衡，最终发生的事情是，我们最终开始与Celery，Redis，RabbitMQ，Nginx，uWSGI合作以及其他很多没有任何实际经验的大型第三方服务。

最终，这导致了许多意大利面条式代码，无法测试的任务（由于第三方库的复杂性，对代码进行修补甚至无法正常工作）和许多麻烦，因为没人知道这些服务的附加价值是什么。 。

在您说“是的，您应该使用那些服务”之前，请记住，除了引入竞争条件困扰的代码之外，没有人知道如何使用这些服务，甚至不知道他们的工作。

我该怎么办？在这一点上，即使现在最终产品的状况比开始时要差，恢复到原来的状态也太昂贵了，并且PM陷入了使用这些服务的僵局。与他讨论这件事还有什么用吗？我需要更多时间吗？还是苛刻的答案，我对工作太傻了吗？

一旦我们完成了项目，项目经理表示我们必须使用第三方消息队列功能而不是线程，并且必须实现负载平衡

这对于PM单方面“声明”状态是不合适的。两个原因：

1. 设计决策应由技术人员做出，并且仅应响应NFR。因此，请问您的PM是否有新的NFR，以及是否可以提供详细信息。

2. 如果NFR是在项目中途引入的，则可能应该通过变更控制来完成。从治理的角度来看，变更控制非常重要。它不仅是一种输入您的要求，同时也是一个重要的输入QA的测试用例，运行部署和支持手册，和（这里是真正重要的部分）的PM的时间表。如果新要求引入了更多的工作，则开发团队应该有机会交流新的开发估算，并且项目经理将必须决定他们是否可以接受新日期，增加更多资源还是推迟引入新项目的利益相关者的参与。 NFR。

现在，如果确实存在真正的NFR，并且没有解决办法，那么可能合适的是，请求熟悉所引入技术的新资源或其他资源，或者为您现有的一些资源申请培训预算资源。因此，还有一个成本方面。

如果您说的是项目经理的语言（进度和成本），那么我认为您比谈论开发人员对最终设计的感受会更具吸引力。这些事情具有真正的影响。

一个项目经理应该比没有管理，没有控制，也没有共识的情况下即时介绍这样的东西更好地了解。如果他们不了解，您可能需要升级到产品管理或计划管理，因为他不必要地使质量和进度受到威胁。

愚蠢的是让自己步入死亡。

您所描述的是您已经失去了批判的感觉。没有控制感，也没有明确的控制方法。

您应该做的最后一件事是努力工作，低头，安静地受苦，直到他们最终承认该项目注定要失败。

您应该做的是非常认真地思考您有权拥有的一切。

如果他们希望您使用您不了解的技术，则应该花些时间来学习它们。不要为您不知道的内容感到羞耻。用你的无知作为udge俩。当他们要求您使用某些东西时，请问为什么。不要接受“因为”。不要接受“现代最佳实践”。在获得真实，可测试的期望之前，不要接受“可扩展性”。

可测试的意思是他们必须告诉您他们希望每天/每小时/分钟可以执行多少个请求。请明确说明您打算根据这些规范构建一些东西来行使此系统。

这样，您可以使用30天的免费试用来证明他们想要的最新wiz bang东西值得，或者如果您更好地坚持自己已经知道的事情，那就值得了。

现在请记住。它不是引入竞争条件困扰代码的工具。你们做到了。您需要学习如何做到这一点，以便您可以撤消该操作。

和不。恢复到原来的状态并不太昂贵。PM不能仅凭需求就拥有他们想要的东西。您必须后退，直到可以有效地使用PM所需的内容或证明它不是项目所需的内容为止。

严重的是，仅仅屈服于此对项目来说是不专业且致命的。

我去过这里 然后再一次。这确实会让您感到愚蠢。真的不是那样。你只是迷路了。

与PM交谈。老实说 布置全部。表明您愿意学习，但不想被带走。永远不要基于信念进行设计或编码。使PM向您展示如何做他们想要的事情。不假装不懂的话。不要说当它不会的时候会完成。如果您要相信某事，请相信自己。您必须愿意拒绝。

如果这样不起作用，请完善简历，因为您很快就会需要它。不管怎样。

这应该确实在Workshop.stackexchange.com上，因为问题实际上不是软件开发问题，而是关于工作场所关系的问题。

如果您确定您的简单方法会很快奏效并产生工作结果，那么您的PM是您公司中的破坏力量，应予以淘汰。弄清楚如何将消息传递到他之上：您的团队有一个简单而有效的解决方案，并取得了良好的进展，并且由于没人能解释您的PM的原因，您不得不使用多种方法尝试更复杂的解决方案没人知道，没人理解，没人知道它们是否有用的工具，而PM的深不可测的决定给您带来了所有麻烦，并导致项目延迟和无法正常工作。

不知道您的管理层所追求的背景和产品策略，很难客观地回答您的问题。

这里有一些客观的论点。但是，这可能不是您所期望的：

• “ 请记住，没有人知道如何使用这些产品还没有 ”。
• 仅使用众所周知的工具和技术将确保高生产率。但这将大大限制创新能力。在某些市场上，这可能对您的产品致命。例如，大约30年前，我提议使用Windows 3.0来开发在MS-DOS下成功的CAD产品的新版本。产品经理反对说，这不是一个经过验证的环境，对于团队来说这太复杂了，学习起来也太困难了，无论如何，“ Windows永远不会成为主流环境 ” ...我想让您猜猜它的成功2年后，他的产品问世。
• 这都是成本和收益的问题。实验的成本与可扩展性和可部署性的好处，以及具有大量安装和繁重工作量的第三方所确保的优势。
• 添加新技术的弊端可以通过适当的培训来解决，或者由经验丰富的顾问提供初步支持/指导。

最终，经济选择是产品经理的责任。与他讨论其优缺点，以确保他做出明智的决定并且不会低估所增加的复杂性。而且，如果他继续前进，请努力做到最好：您没有什么可以松懈的，而且在最坏的情况下，您的简历上会有一项新技术。

第三方库（和其他组件）有两种方法：

1. 尽可能多地使用它们
2. 尽可能少使用

我的方法是（2）。听起来您的方法也是如此（2），但是项目经理喜欢这种方法（1）。

您可以通过三种方式处理这种情况。您要么让PM执行PM想要的任何事情，要么尝试说服PM更改第三方库的方法，或者用脚投票并选择其他工作。

如果要说服PM更改方法，请考虑以下参数：

• 该学习了。每个外部库都需要时间来学习，在这段时间内，合格的程序员可以编写所需的功能，尤其是如果选择一个巨大的库只是为了完成可以用几百行代码完成的非常简单的事情。
• 可替换性。如果您有一个外部库，如何确保停止开发，可以用另一个类似的库替换它？我的解决方案是在可能的情况下，尽可能地避免使用外部库，我编写了一个简单的包装程序来抽象出所需的编程接口部分。通常，我想要的接口比库提供的接口简单得多。然后，我的代码仅通过此包装器访问外部库，从而使替换变得容易。在某个框架上构建整个应用程序是一个很大的禁忌。Servlet？是的，他们已经在这里呆了很长一段时间，并且在可预见的将来会继续在这里。模板引擎？是的，尽管它们并不是完全可替换的（您通常会选择其中一个并坚持使用），但是它们带来的价值却是巨大的，因此，请谨慎选择-并记住切换模板引擎时，您可以在同一应用程序中拥有两个模板引擎，但通常在同一应用程序中不能拥有两个框架。Apache Struts？不，框架很快就流行起来，过时了，通常在同一应用程序中不能有两个框架。
• 版本地狱。通过选择一个外部库，您必须对其进行更新以避免安全漏洞，并且更新它可能会导致问题。设计良好的组件（例如Java JRE）可与不同版本兼容，但我的经验是，由于施加了巨大的版本地狱，大多数库都被废弃了。此外，组件X可能需要Z版本1，而组件Y可能需要Z版本2，并且您可能不一定能够在同一应用程序中链接Z版本1和Z版本2。
• 安全漏洞。通过选择外部库，针对您的应用程序的易于利用的安全漏洞数量将增加。有些人可能会说内部开发的代码通过隐蔽性类似于安全性，但是我还是要说它仍然是一种安全性。
• 许可问题。每个外部库都将自己的许可证强加给程序的某些部分。例如，GPL库不能在非GPL程序中使用，LGPL库也需要分发源代码和二进制文件，这可能会占用大量带宽。
• 应用程序启动时间。每个大型外部库都会减慢应用程序的启动时间。通过内部编写一个简单的精益库，可以使应用程序的启动时间更快。
• 内存占用量。通过让X要求Y要求X要求Z要求A要求B，您需要同时在存储器中需要X + Y + Z + A + B。通过仅实现X的等效项，在内部将其称为X'，您只需在内存中使用X'。通常，X'的内存占用空间小于X的内存占用空间。
• 错误风险。外部组件中的行越多，由于需要理解大量的代码，您将遇到难以修复的错误的风险就越高。如果您是在内部执行此操作，则通常只需较少的代码行（仅执行所需的操作，无需执行其他操作），从而减少了发生错误的风险。
• 可定制性。如果我自己编写SQL查询，则知道查询的外观以及在给定的数据库引擎和给定的索引集下查询的性能如何。另一方面，如果SQL查询是由外部组件编写的，那么我对它的性能一无所知。我曾经在一家公司工作，每个网页都花了几秒钟来获取。我怀疑原因是当您需要的只是一个项目而不是与该特定项目相关的所有项目时，他们使用的Hibernate库自动从数据库中获取了太多数据。在发现速度缓慢的真正原因之前，我离开了公司，因为我不喜欢使用大量现有库的方法。

特别要注意如果库将自己称为框架。这意味着该库要求您围绕自身构建整个应用程序。通常，您在同一应用程序中不能有两个框架。他们将在没有和平共处的情况下相互斗争。Web开发实用程序库？是的，请问这些东西太少了。如果找到比现在更好的库，则可以在新代码中使用新找到的库，同时继续在旧代码中使用旧库。Web开发框架？鸣谢不！

我认为您的PM的目标是建立一个易于管理的系统，该系统在运行中会产生很多维护工作，因此可以确保您的收入。

就个人而言，您似乎迷上了python，只是暂时忘了python，一年不使用python编写代码，学习新知识，您会发现还有其他语言可以做到这一点，并且可能会更好。

正如其他人所述，在开始使用工具进行编码之前，请先学习它们。也许建议基于对适合该任务的不同工具的研究，一起评估必要的堆栈将是不错的选择。或者问他如何提出这份清单，他本可以从最新的人那里得到帮助。

开发人员不应该害怕学习使用新的库，框架，技术等。这是开发人员工作说明的核心部分，对于有人建议团队与任何人都没有的第三方合作是非常合理的。如果他们有能力为团队做出权威的技术决策，则需要有经验，甚至要求团队这样做。

但是，指望您可以采用一种新技术是不合理的（更不用说一次使用几种新技术了））放入堆栈中，并不断取得进步。应该安排大量的时间来学习新方法的来龙去脉，并找出一个好的设计来结合新的产品，在此期间，不会期望实际产​​品的真正进步（来自从事这项学习/设计工作的人） ，这可能是整个团队，也可能不是整个团队，尽管如果不是这样，则可能需要更多的计划时间供那些学习将知识转移到团队其他成员的人使用。这就是进行此类重大更改的成本。学习新技术是开发人员工作的一部分，但这并不是零成本的事情。

听起来好像不是这个问题。人们确实在尝试以自己不了解的技术为基础构建良好的实现，这是正确的。当然，产生的代码是可怕的。

尝试说服您的PM，公司将需要在此上花费更多的时间。它要么以现在停止，学习和评估新技术，找出好的设计并清理当前的实施混乱的形式出现。否则将以更多时间浪费在错误，维护，昂贵的开发等方面。

无法说出问题中描述的技术选择（负载平衡，消息队列等）是否真正合适。我不认为“团队中没有人以前有过处理此事的经验”是绝对排除决定的一个很好的理由，但确实会增加做出该决定的短期成本（这可能会改变“最佳”的决定），如果您的项目经理不考虑这一点，并希望团队立即像有经验的人一样变得富有生产力，那么您应该基于这些理由退缩；他们将制定非常不切实际的项目进度，这并不符合任何人的最大利益。