Refaktoring to słowo, które często budzi niepokój po stronie biznesu. Kojarzy się z kosztami, opóźnieniami i „widzimisię” programistów. Jak więc rozmawiać o nim skutecznie? Ten przewodnik powstał na podstawie rozmowy „Architekt vs Biznes”, w której wzięli udział instruktorzy Drogi Nowoczesnego Architekta: Jakub Kubryński, Jakub Pilimon i Łukasz Szydło, oraz Andrzej Krzywda, CEO Arkency. Znajdziesz tu konkretne strategie, które działają: w startupach, produktach legacy i dużych organizacjach.
1. Zacznij od zbudowania pozycji zaufanego eksperta
→ Dowożenie to najskuteczniejsza strategia techniczna
Rozmowa o refaktoringu to nie kwestia tego, co mówisz, ale kto mówi. Jeśli masz reputację osoby, która dowozi, biznes nie będzie kwestionował każdej twojej decyzji technicznej. I odwrotnie: jeśli masz opinię „tego, co wszystko komplikował” albo „tego, co kiedyś zepsuł PDF-y”, to każde kolejne podejście do refaktoringu może skończyć się ścianą milczenia.
Zaufanie techniczne w oczach biznesu budujesz tak, jak buduje się zaufanie w każdej relacji: dowożąc to, co obiecałeś, w czasie, który obiecałeś, i bez niespodzianek po drodze. Budowanie zaufania nie oznacza jednak, że musisz od razu brać na siebie najtrudniejsze transformacje systemu. Wręcz przeciwnie: warto zaczynać od prostych rzeczy, które można szybko zakończyć. Regularne dowożenie prostych zadań daje znacznie lepszy efekt wizerunkowy niż jedno duże, rozgrzebane przedsięwzięcie, nawet jeśli ma ono „większą wartość techniczną”.
Dobrym przykładem budowania takiej pozycji jest historia Andrzeja Krzywdy z początków jego pracy w dużej korporacji. Bez żadnej formalnej władzy ani autorytetu, postanowił przekonać zespół i zarząd do zastosowania nowej, świeżej wtedy technologii Ruby on Rails. W ciągu jednej nocy przygotował prototyp systemu, który na spotkaniu zaprezentował w formie live codingu. W zaledwie 30 minut pokazał działającą wersję aplikacji, nad którą formalnie planowano pół roku pracy. Efekt? Uznanie biznesu, zaufanie decydentów i przestrzeń na rozwój technologii, ale także niechęć kolegów z zespołu, których wysiłek i metody zostały w tym momencie nieświadomie podważone. Ta anegdota świetnie obrazuje, że pozycję siły można zbudować nie tylko przez tytuł, ale przez realną demonstrację wartości.
Zaufanie można też budować językiem i dopasowaniem się do sposobu myślenia klienta (patrz punkt 4).
W projektach, gdzie relacja z biznesem jest napięta, każdy błąd, szczególnie na początku współpracy, może ciągnąć się latami. Z tego powodu, zwłaszcza w pierwszych tygodniach, lepiej jest nie być zbyt ambitnym. Lepiej zrobić coś niewielkiego, ale dobrze, niż spalić temat większych inicjatyw na starcie.
2. Traktuj refaktoring jako element codziennej pracy
→ Nie pytaj o pozwolenie — działaj mądrze i ciągle
Jednym z najskuteczniejszych sposobów na refaktoring jest jego… niesprzedawanie. Zamiast ogłaszać duże przedsięwzięcie „Refaktoring Modułu A”, lepiej potraktować go jako serię małych, bieżących transformacji kodu. Takie podejście nazywa się często ongoing refactoringiem.
Dobry architekt potrafi rozbić duży plan na mniejsze etapy. Każdy członek zespołu może wtedy, przy okazji innej zmiany, wprowadzać niewielkie ulepszenia. Refaktoring staje się częścią kultury technicznej, a nie osobnym projektem wymagającym osobnej zgody.
Zamiast prosić biznes o pozwolenie na „czyszczenie kodu”, robisz to przy okazji pracy nad danym komponentem. Takie działania często nie wymagają formalnych ustaleń z biznesem, chyba że panuje silna kultura mikrozarządzania i każda zmiana musi być autoryzowana. W przeciwnym razie można działać w ramach bieżących zadań, tak długo, jak nie zmieniają one funkcjonalności widocznej z zewnątrz.
Taki styl pracy wymaga odpowiedzialności i spójności w zespole. Każdy musi rozumieć, co jest akceptowalne jako refaktoring lokalny, a co wymaga już szerszego omówienia. Wymaga to pewnej dojrzałości, ale organizacyjnie jest dużo łatwiejsze niż przekonywanie do dużych, osobnych inicjatyw technicznych.
3. Mów językiem biznesu, nie żargonem IT
→ Zamień „adaptery” na „korzyści” i „ryzyka”
Jedną z największych przeszkód we współpracy między IT a biznesem jest język. Techniczne słownictwo, którego używamy na co dzień, dla wielu osób spoza branży brzmi jak czarna magia. Co gorsza, niektórzy programiści używają go z premedytacją, by zbudować swoją pozycję.
To powoduje efekt „milczącego przytakiwania”: biznes nie rozumie, ale nie chce wyjść na niekompetentny. A skoro nie rozumie, to trudno mu się zgodzić na coś, co brzmi jak niepotrzebny koszt.
Czasem jest jeszcze gorzej: źle zrozumiana decyzja techniczna zostaje zapamiętana jako „porażka IT” i utrudnia każdą kolejną rozmowę.
Dlatego zamiast mówić o klasach, refaktorze, adapterach czy sygnaturach metod, lepiej skupić się na korzyściach. Zamiast „przepiszemy to na CQRS”, powiedz: „Dzięki temu szybciej wdrożymy zmiany i ograniczymy ryzyko błędów.” Zamiast „wydzielimy bounded context”, powiedz: „Będziemy mogli łatwiej rozwijać tę część systemu niezależnie od reszty.”
To nie oznacza upraszczania, lecz dopasowanie komunikatu do kontekstu i celu rozmowy. Dobra rozmowa z biznesem nie polega na tym, by się popisać techniczną precyzją, tylko by ułatwić decyzję i zbudować zaufanie. Im mniej niezrozumiałych skrótów, tym większa szansa, że refaktoring nie zostanie z góry odrzucony.
4. Używaj trafnych metafor dopasowanych do odbiorcy
→ Dzięki metaforze refaktoring przestaje być straszny
Metafora to potężne narzędzie. Pozwala przekazać skomplikowany techniczny koncept w sposób zrozumiały i zapadający w pamięć. Jedna z najczęściej używanych to metafora floty samochodowej: możesz co roku wymieniać kilka aut i utrzymywać flotę w dobrym stanie albo olać temat na 5 lat i potem mieć kosztowny, trudny do zaplanowania generalny remont.
Andrzej opowiadał o klientach, którzy widzieli swój biznes jako grę RPG (gdzie zdobywa się punkty many), albo jako park rozrywki, w którym nowe atrakcje wymagają sprawnej „instalacji elektrycznej”. Inni myśleli o swoim systemie jak o radarze wojskowym albo narzędziu do zwiększania świadomości sytuacyjnej. Te metafory nie tylko ułatwiały zrozumienie, ale pomagały też klientom odnaleźć wartość proponowanych zmian.
Kluczowy jest dobór metafory do odbiorcy. Dla finansisty użyj porównań do Excela lub inwestycji. Dla marketingowca — do kampanii lub sprzętu foto. Dla CEO startupu — do rekrutacji albo pociągów high-speed, które trzeba czasem serwisować, zanim się wykoleją.
5. Powiąż refaktoring z nową wartością
→ Gdy pojawia się nowy feature, to idealny moment na zmiany w kodzie
Najłatwiej przekonać biznes do refaktoringu wtedy, gdy system przestaje wspierać nowe potrzeby. Jeśli nowa funkcja biznesowa w ogóle nie pasuje do obecnego modelu, bo jest „przeciwieństwem” tego, co budowaliśmy do tej pory, to naturalny moment, by zmienić strukturę.
Nie trzeba używać słowa „refaktoring”. Wystarczy pokazać, że obecna struktura nie pozwala efektywnie dodać nowej funkcji. A skoro zmiana i tak musi nastąpić, to można ją zaprojektować w sposób, który dodatkowo porządkuje kod.
Takie działania można nawet „przemycić” jako lokalny rewrite: przepisujemy tylko jedną część systemu, a zachowanie na zewnątrz się nie zmienia. Efekt? Biznes dostaje, czego chce, a my robimy techniczne usprawnienia, które ułatwią przyszłą pracę.
6. Korzystaj z momentu i kontekstu organizacyjnego
→ Refaktoring to szansa, gdy organizacja się zmienia
Nie każdy dzień jest dobry na rozmowę o refaktoringu. Ale są momenty, które wyjątkowo sprzyjają zmianom: reorganizacja firmy, wymiana osoby kontaktowej po stronie biznesu, cięcie budżetów, zmiana etapu życia produktu (np. przejście ze wzrostu w fazę utrzymania).
Warto wykorzystać takie „szczeliny decyzyjne”, zanim wróci tryb pełnego operacyjnego biegu. W okresach niepewności, takich jak kryzys, zmiany rynkowe czy transformacja cyfrowa, wiele zespołów robi pauzę w rozwoju. To doskonały moment, by „naostrzyć piłę”, zamiast bezwładnie czekać.
Nie chodzi o spiskowanie. Chodzi o empatyczne zrozumienie, kiedy druga strona może być otwarta na nowe propozycje. I o umiejętność pokazania, że to, co proponujesz, nie jest kaprysem IT, ale realnym wsparciem dla przyszłego działania firmy.
Podsumowanie: Kiedy refaktoring wspiera cele biznesowe
Refaktoring ma sens, gdy jest osadzony w realnym kontekście biznesowym: nowej funkcjonalności, zmieniającej się struktury organizacyjnej, potrzeby zwiększenia szybkości wdrażania lub ograniczenia ryzyka. Najbardziej skuteczne podejścia to te, które integrują refaktoring z codzienną pracą zespołu, tłumaczą go językiem korzyści i odpowiadają na realne potrzeby firmy.
Zamiast pytać „czy możemy coś poprawić w kodzie?”, warto zapytać: „jak szybciej i bezpieczniej dowieziemy to, czego potrzebuje klient?”, a następnie tak zaprojektować techniczne rozwiązanie, by refaktoring był jego naturalną częścią.
