Spis treści
Pewnego dnia siedziałem na spotkaniu między firmą a zespołem IT. Klient tłumaczył, że chce prosty system do obsługi zamówień. Programiści notowali coś w skupieniu, kiwali głowami, a po chwili jeden z nich powiedział:
„To możemy zrobić przez API z integracją po REST, z webhookiem i autoryzacją OAuth 2.0.”
Po drugiej stronie stołu zapadła cisza.
Klient spojrzał na mnie z miną, która mówiła: czy my w ogóle mówimy o tym samym?
I wtedy przypomniało mi się, że kiedyś ktoś zapytał mnie, czym właściwie się zajmuję. Odpowiedziałem wtedy pół żartem, pół serio:
„Jestem tłumaczem. Z języka IT na język ludzki.”
Dwa języki, jeden projekt
Świat biznesu i świat IT mają ze sobą wiele wspólnego, ale używają zupełnie innych słowników.
Kiedy właściciel firmy mówi: „chcę system, który uprości mi pracę”, to dla niego znaczy: ma być szybciej, prościej i bez nerwów.
Kiedy programista to słyszy, myśli: muszę zdefiniować proces, stworzyć logikę biznesową, zaprojektować interfejs i napisać backend.
Obaj mają rację. Problem w tym, że mówią różnymi językami.
To trochę jak spotkanie architekta i inwestora. Jeden myśli w metrach kwadratowych i konstrukcjach nośnych, drugi w kolorach ścian i przestrzeni do życia.
Język IT – fascynujący, ale niebezpieczny
Programiści są jak poeci – mają własny rytm, logikę, skróty myślowe i metafory. Tyle że zamiast pisać wiersze, piszą kod.
Dla nich naturalne są słowa takie jak framework, sprint, backlog, deploy, integracja, commit, merge conflict.
Problem w tym, że dla większości przedsiębiorców brzmi to jak czarna magia.
I tu właśnie zaczynają się problemy – bo każda strona uważa, że mówi jasno.
Programista mówi: „to zajmie 3 sprinty”.
Klient słyszy: „czyli za dwa tygodnie będzie gotowe”.
Rzeczywistość: „to dopiero początek prac koncepcyjnych”.
To nie zła wola. To językowy paradoks.
Kiedy tłumacz jest potrzebny
Pamiętam projekt, w którym klient był przekonany, że system nie działa, bo „nie widzi danych”. Zespół IT tłumaczył, że „to tylko brak indeksu w tabeli relacyjnej”.
Spotkaliśmy się, przetłumaczyłem na ludzki:
– Czyli dane są, tylko ich nie widać, bo trzeba otworzyć okno w innym miejscu.
Klient się uśmiechnął, programiści odetchnęli. I nagle wszystko zadziałało – nie tylko system, ale i komunikacja.
Bo to nie technologia była problemem. Tylko język.
Tłumacz nie musi wiedzieć wszystkiego
Nie trzeba być geniuszem kodowania, żeby rozumieć, co jest istotą komunikacji między klientem a zespołem IT. Trzeba tylko rozumieć obie strony.
Świat IT to systemy, logika, architektura, testy, wydajność.
Świat biznesu to ludzie, procesy, cele, czas, pieniądze.
A pomiędzy nimi jest przestrzeń, w której rodzą się nieporozumienia.
Tłumacz w tym kontekście nie jest ekspertem od jednego języka, ale mostem między dwoma światami.
To ktoś, kto potrafi wyjaśnić programistom, że „prosty przycisk” w rzeczywistości oznacza złożoną logikę biznesową, a jednocześnie wytłumaczyć klientowi, że „drobna zmiana” może oznaczać dwa tygodnie pracy.
Kiedy IT mówi „tak”, a my słyszymy „jutro”
Jednym z najczęstszych błędów w komunikacji jest interpretacja słowa tak.
– Czy da się to zrobić?
– Tak.
W świecie IT to znaczy: technicznie to możliwe, jeśli dostaniemy dane, dostęp i budżet.
W świecie biznesu znaczy: super, to pewnie za tydzień będzie gotowe.
Między tymi dwoma „tak” mieści się cała przepaść nieporozumień, stresu i wzajemnych pretensji.
I właśnie dlatego tłumacz bywa ważniejszy niż projektant systemu. Bo tłumaczy nie tylko słowa, ale i intencje.
Język, który uspokaja projekty
Kiedy pojawia się ktoś, kto rozumie oba światy, napięcie znika.
Nagle okazuje się, że programiści nie są aroganccy – po prostu skrupulatni.
Że klient nie jest roszczeniowy – tylko zdezorientowany.
Że większość „awantur” wynika z braku zrozumienia, a nie z braku kompetencji.
Wtedy projekty zaczynają się toczyć płynnie.
Nie dlatego, że wszystko idzie idealnie, ale dlatego, że ludzie zaczynają rozumieć, o co chodzi.
Tłumaczenie w biznesie to nie kwestia języka, tylko empatii.
Nie każdy mówi tym samym kodem
Każdy z nas ma swój „język roboczy”.
Programiści mają kod.
Handlowcy mają liczby.
Menedżerowie mają procesy.
Pracownicy mają doświadczenia.
To, że mówimy po polsku, nie znaczy, że się rozumiemy.
I może właśnie dlatego współczesne firmy potrzebują nie tylko technologii, ale też ludzi, którzy potrafią tłumaczyć. Nie tylko „co system robi”, ale „po co to wszystko robimy”.
Bo oprogramowanie to nie linijki kodu. To narzędzie, które ma pomóc ludziom lepiej działać.
A żeby tak się stało, ktoś musi dopilnować, by język IT nie zagłuszył ludzkiego sensu.
Podsumowanie – zrozumienie to najlepszy interfejs
Kiedyś myślałem, że kluczem do udanych projektów IT jest dobra technologia.
Dziś wiem, że jest nim dobre zrozumienie.
Bo nawet najlepszy kod nie pomoże, jeśli ludzie po dwóch stronach nie rozumieją, o czym rozmawiają.
A czasem wystarczy jedno tłumaczenie, żeby projekt, który utknął, ruszył do przodu.
I może właśnie dlatego tak bardzo lubię myśleć o sobie jako o tłumaczu – z języka IT na język ludzki.
Bo w tym zawodzie najwięcej mówi się wtedy, gdy potrafi się dobrze słuchać.
