重组软件公司：如何改变其技术概况并在 IT 市场上选择专业化？

每个软件公司都有自己的技术概况。 通常情况下，对于技术人员来说，这比公司的域名资料更重要。 这是因为 IT 开发人员宁愿通过他们工作的技术的棱镜来看待自己，例如，我是用 C# 构建的系统的程序员。 然而，他们是否正在为处理培训或生产盒子的公司做项目是次要的。 当然，领域知识对程序员总是有用的，但它不会通过技术维度改变他们对自己的看法——FINGO 的联合创始人兼首席技术官 Robert Marek 说。

FINGO是一家波兰软件公司，提供编程服务已有 20 多年。 2022 年，该组织成功改变了其技术形象。 除了提供 Java 和 .NET 技术的编程服务外，它还添加了 Node.js 并完成了迄今为止在 PHP 中创建的所有项目。

为什么要这样做？ 自组织变革的过程是什么样的？ 结果如何？ 阅读我们对罗伯特·马雷克 (Robert Marek) 的采访，找出答案。

在我们开始谈论改变技术概况本身的过程之前，您能告诉我们重组前公司的情况吗？

如果你关注FINGO 20年的投资组合，你会发现金融、房地产、汽车、电子商务等诸多领域的项目，或多或少都相互关联。 这有点巧合——多年来出现了这样的项目，我们一直在发展我们的团队。 但这种情况在很大程度上受到我们的技术概况（Java、.NET、PHP）的影响，我们正在根据这些概况寻找更多订单。

但是，我觉得这对我们的业务不利。 对于像 FINGO 这样规模的软件公司来说，大规模的技术传播通常是不利的。 找项目可能更容易，但更难保证人的可交换性。 我给你举个例子。 假设您的项目需要 5 名开发人员。 板凳上坐着6个人，但只有2个人知道项目中需要的技术。 这种情况意味着仍有 4 名高薪专家失业，您需要为他们提供工作。 最重要的是，您需要让 3 人熟悉所需的技术，以确保为项目配备人员。

然而，拥有运作良好的业务所带来的舒适感阻止了我们实施这些变革。 我们有项目、固定的长期客户和经验丰富的程序员。 在这样的环境下，很难下定决心开始改变一些东西。

那么是什么让您决定改变 FINGO 的技术概况？

在大流行开始时，市场冻结了。 不知道接下来会发生什么的公司没有继续当前的项目或开始新的项目。 那是一个连程序员都害怕失去工作的时代。 我们不知道该怎么办。 我们不想裁员，但另一方面，我们需要一些能让我们脱颖而出的东西。

2020年5月左右，作为公司的所有者，我们发现如果不做出大胆的决定，情况可能会恶化。 我们在金融领域拥有最多的项目，因此也拥有最多的经验。 此外，我们有一个产品部分提供了能够在银行业实施强制报告的软件。 金融部门是我们的自然选择。

当时，在我看来，FinTech 和金融部门不太可能在他们的项目中使用 PHP。 所以我假设通过专注于这个领域，我们将摆脱 PHP 而只保留 Java 和 .NET。 有了这些信息，我们在公司的股东大会上就去团队了。

所以是疫情的爆发迫使你决定改变 FINGO 的技术形象？

是和不是。 在共享有关专业化的信息后，我们任命了一个由几位经验丰富且具有商业天赋的程序员组成的工作团队。 它的任务是检查各个国家/地区在金融领域的趋势、技术和流行解决方案。 他们的分析证实了我早先的假设，即 PHP 在金融项目中很少见。 同时，他们建议培养 Node.js 的能力，这在初创企业的世界中也很有价值。

在我们公司，我们珍视绿松石管理的概念，除其他事项外，我们与整个团队公开协商对组织具有重要意义的项目。 正因为如此，人们感受到了对公司发展的影响，同时也感受到了对所做决策的共同责任。

因此，自下而上的转向 Node.js 的倡议仍然需要得到 FINGO 团队其他成员的批准。 然而，很快就发现有强烈的向这个方向发展的愿望。 也许那是一个特殊的时期，我们都在各个方面（经济和健康方面等）对未来感到恐惧。 矛盾的是，这增加了接受挑战的决定的接受度。

有多少人必须获得新技术能力？

此次变革总共涉及 15 人。 他们必须决定是要作为前端开发人员进行开发，还是继续作为后端开发人员并使用 Java、.NET 或 Node.js 创建解决方案。

其中一个人是一名全栈开发人员，他已经宣称自己是一名前端开发人员，所以对他来说，这个决定很容易。 因此，2 人选择了 Java，其余 10 人选择了 Node.js。

两名测试人员也参与了重组，他们也必须学习新技术。 我们公司的政策是使用与制造产品相同的技术编写测试。 当测试人员暂时不可用时，这种方式给了我们安全感； 编写测试可以暂时由程序员接管。

也有离职，但这些都是个人决定。 有一个人很快就从 FINGO 辞职了，但这是因为他在弗罗茨瓦夫开发 PHP 社区。 我们对合作的期望开始出现分歧是很自然的。 在此过程中，由于种种原因，又有2人离职。

做出决定只是道路的开始。公司是否以某种方式帮助程序员获得新的能力？

创建了一个战略项目，以支持开发人员准备在商业项目中以最快的速度提供服务。 一开始，我们要求他们主观确定他们需要多少时间来获得必要的知识，这样他们才能自信地为外部客户承担工作，假设有 2 个场景。 第一个是在更有经验的同事的支持下，第二个是没有这样的支持。 作为回应，我们获得了各种估计。

一些人宣称，在有经验的 Node.js 开发人员的支持下，他们甚至可以在一个月后加入商业项目，而另一些人则需要几个月后。 这完全取决于您以前的（私人或专业）经历以及您自己有多少勇气。 同样值得注意的是，我们在 FINGO 也有过这种环境的体验。 所以我们有一个基础。

然而，我们并没有强加给他们一种获取知识的方式。 所有这些人都是经验丰富的程序员，他们想要不断学习。 他们有自己喜欢的学习方式。 一般来说，不断获取知识在某种程度上被铭刻在新技术产业中。 因此，我们决定最合理的解决方案是简单地为他们提供学习资源和时间。

我们还重组了公司。 自组织行会应运而生，从事特定技术工作但不一定从事相同项目的人们可以在这里交流获得的知识。 作为 Node 公会的一部分，还创建了一个内部项目，人们可以在其中测试新获得的知识。 为志愿者组织了外部课程。

不过，给的最多的还是快速加入项目的机会。 最好的例子就是我们正在处理的订单之一，我们需要所有可能的人手。 在获得客户的同意后，一位经验丰富的 PHP 开发人员加入了该项目，他也从事 JavaScript 工作，但他本身并没有使用 Node.js 的经验。 但是，该项目中已经有经验丰富的程序员能够支持同事并确保代码质量。

让我们多谈谈你的客户。他们对您放弃 PHP 的决定有何反应？

我们遇到的最大的内部阻力和悲伤是为一个拥有 10 年历史的客户创建的项目。 这很有趣，因为我们的一位程序员从一开始就致力于此。 自然，他比那家公司的许多管理人员更了解这个系统。 我们很难向他们解释我们的决定。 尽管我们提前一个月通知，但我们还是想好好照顾这位客户。 我们同意再为他们服务六个月。 有趣的是，3个月后，由于公司内部重组，客户自己终止了合作。 这也表明你不应该在事情​​上纠缠太久。 他们应该完成，仅此而已。

其他项目更容易。 像其他事件一样，它发生得很自然。 例如，我们有一个客户端在 Node.js 中开发系统的一部分。 我们同意我们的程序员，他们以前在 PHP 技术方面支持该项目，将在头几个月以较低的价格提供他们的服务。 在某种程度上，这是对最近更改技术的团队假设效率较低的补偿。

您认为开发人员现在如何看待这一变化？

我觉得他们很幸福。 这个行业的人喜欢学习。 那时，他们有时间和金钱去学习。 他们全日制学习，领取全额工资，并可以享受助学金。 这无疑对他们的感情产生了积极影响。

Node.js 比 PHP 好吗？ 这当然值得商榷。 当然，现在这个技术很流行，所以我们进入了一个上升趋势的时期。

有些人最初对离开一个长期的 PHP 项目感到遗憾。 但不久之后，他们承认他们已经摆脱了某种停滞。 他们感受到了新挑战带来的激动人心的微风。 总的来说，我认为它进行得很顺利。

变化持续了多长时间？

整个过程随着时间的推移而拖延。 市场验证需要相当长的时间。 重组公司和与客户分道扬镳也花费了很多时间。 总的来说，自从在 Jira 中创建任务到关闭已经过去了将近 2 年。

然而，值得注意的是，开发人员从 PHP 项目过渡到 Node.js 的最长间隔只有 3 个月。 这与他宣布需要与更有经验的同事一起加入该项目的时间有关。

最困难的方面是什么？

我认为只是做出决定，是时候改变一些事情了。 然而，意识到如果我们现在不改变，一两年后将不会有任何改变，这极大地帮助我们更快地做出决定。

当地平线上没有明显可见的替代方案并且经济形势不稳定时，也很难与客户分开。

在整个过程中，我们想照顾我们的长期客户，让他们冷静地寻找替代方案，同时也要照顾好我们自己。 确保程序员做好准备并准备好快速接受新技术的命令。

如果另一家公司的 CTO 来找你，说他也在考虑改变公司的技术状况，你会给他哪 3 条建议？

有远见。 知道你为什么要这样做，并让你的团队清楚你要去哪里以及为什么。

与你的团队合作。 与人交谈，根据听到的内容调整行动，并考虑他们的能力。 凡事与人为伍。

尽管有犹豫的时刻，但始终如一地做每一件事。