重組軟件公司：如何改變其技術概況並在 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 條建議？

有遠見。 知道你為什麼要這樣做，並讓你的團隊清楚你要去哪里以及為什麼。

與你的團隊合作。 與人交談，根據聽到的內容調整行動，並考慮他們的能力。 凡事與人為伍。

儘管有猶豫的時刻，但始終如一地做每一件事。