我在一家为各种银行和一些较小的电子商店提供Web应用程序的公司里工作。我们雇用大约20名开发人员，并且任何时候都在开发4-5个项目。我们的开发团队互动不多，许多相同的问题以不同的方式解决（好坏）。
我想知道，对于一家公司来说，拥有一个对当前框架进行研究并持续改进通用功能库和通用框架以更快，更高效地构建当前和未来项目的程序员团队是否是一个好主意。
这样的团队应该有多大？
它还应该有训练别人的常任理事国还是应该轮换人员？
更新：我正在考虑一个人们可以从事的有趣的普通项目，这可能会引起人们的兴趣。看起来，当人们面临工作压力时，他们想出的解决方案并不是最好的。
Answers:
重要的一点是，不可能完全隔离地开发一个好的框架。好的框架是有机增长的：当程序员注意到他需要一些特定的功能时，他将其添加到框架中，因此框架逐渐增长了-与预先构造一个“完美的框架”（这是行不通的）相反，因为架构师无法知道所有最终出现的用例。
当然，有机地增长框架的缺点是其内部完整性可能不太好，并且变成了意大利面条。如果您的团队保持良好的内部沟通，那么您也许可以结合两个方面的优点：一个独立的架构师团队保持框架的完整性，但要满足最终用户（开发人员）的实际需求。
我的感觉不是。
我怀疑您是否会发现，是因为不是让单个团队生产该团队以外没有人使用的库，而是让一个专业团队生产团队以外没有人使用的库（并且这样做费用较高）。
您描述的这种团队存在各种各样的问题，但是对我来说，主要的问题是它无法解决您实际遇到的问题。
您遇到的问题不是由谁来生成库的（从事实的角度来看，您已经对这些问题有了很多解决方案，那么还有什么要帮忙的呢？），这是团队之间没有交谈和互动。
有充分的理由说明为什么团队不重用彼此的代码（例如，虽然表面上相似的问题细微地不同，或者项目的时间安排不允许额外地依赖共同开发某些东西），但是您需要研究如何在可能的情况下使他们互动。
我建议：
我怀疑，图书馆团队将是无用的管理费用。
从开发人员的兴趣来看，这是一个普通的项目-任何公司都不应依赖程序员在自己的时间内从事工作。那只是无偿的加班费，在任何情况下都不是可靠的，因为在很长一段时间内，没人愿意从事任何工作。
如果您说的是在项目之间在公司工作的人，那么也许它可以工作，但我仍然不认为这是真正的问题。您仍然需要弄清楚如何使人们使用这些库。就像我说的那样，您已经有针对每个项目正在开发的这些问题的解决方案，您的问题是为什么不共享它们。
那是建筑师的工作。
软件架构师的主要职责包括：
我玩游戏有点迟了，但是我觉得没人在解决这个问题：
您的以不同方式解决不同问题的各个团队一定会从共享功能中受益，并且有多种方式可以实现这一目的，而这种方式不会使单个团队致力于开发它，但是我已经看到了很多的地方。
在大多数情况下，我认为这被称为您产品线的“核心”，有时会有一个团队负责维护它，由一位建筑师领导（正如Amir所建议）。通常，这是您能够找到方法来利用或创建遵循您在组织中设置的最严格标准但仅提供最裸露功能的方法，这些功能可能会或可能不需要扩展到成熟的应用程序中您的个人产品团队提供的。这样，您可以通过在使用每个核心的地方实现核心代码来“养狗”您的核心代码，然后分支到可能具有完全不同的实现的不同产品中。这样一来，您的所有团队就可以为核心库做出贡献，而不必为仅他们需要的功能而烦恼。
我认为这不是一个好主意，因为要使库有用，它们必须帮助您解决实际的项目问题，而且您只能通过在实际项目中工作来了解它们。
否则，您可以以“理论上”非常好的库结束！
在那家我工作过的公司中，确实有类似的事情，但效果似乎不太好。内部团队的成员会想出一个整洁的想法，并想出一个最有效的原型，然后将其推翻，我们期望将其变成产品。
我期望发生的事情是该工具组最终会继续执行自己的小程序，产生的功能实际上并没有那么有用，但是会弄乱API并充分利用它们，因此它们不容易被使用删除。他们没有足够的文件证明。
如果工具组在与真正使用工具的人员保持持续联系的系统架构师的领导下，它可能会起作用。如果工具组频繁旋转（这将妨碍进行大量外部研究），则它可能会起作用。但是，我担心会与从事付费工作的人失去联系。