5 idiomów popularnych w IT

Ludzie pracujący w branży technologicznej (w szczególności programiści) komunikują się ze sobą ciekawym żargonem, który dla wielu osób może być trudny do zrozumienia. Akronimy i idiomy, których używają, są pełne ukrytych znaczeń, pochodzących często ze studiów, żartów środowiskowych, znanych książek lub eksperymentów myślowych. Ludzie z branży uwielbiają ich używać, ponieważ działają one na zasadzie tajnego kodu, którym posługują się współpracownicy, co w pewnym sensie daje im poczucie przynależności.

Jeśli jesteś nowicjuszem w branży i musisz teraz rozszyfrować to, co ludzie mówią, to prawdopodobnie słyszałeś wiele z tych dziwnych, odjechanych zwrotów. Być może pytałeś swoich nowych kolegów, o co im konkretnie chodzi, lub po rozmowie szukałeś tych wyrażeń w swojej ulubionej wyszukiwarce. Lub, jeśli jesteś jak większość ludzi, prawdopodobnie po prostu uśmiechnąłeś się i pokiwałeś głową, myśląc sobie „Co to do cholery znaczy?”.

Akronimy i idiomy powinny usprawnić komunikację, ale jeśli ludzie nie używają tego samego języka, przynosi to odwrotny skutek! Jestem w tej branży od ponad dekady, więc mam nadzieję, że uda mi się zdemistyfikować niektóre z tych wyrażeń dla tych z Was, którzy chcieliby osiąść na dłużej w branży technologicznej. Oto wstępny elementarz pięciu najczęściej używanych zwrotów, o których słyszałam w trakcie mojej dotychczasowej kariery.

Bikeshedding (Bicie piany)

Bicie piany czy też bikeshedding to poświęcanie zbyt dużej ilości czasu i energii na pracę i optymalizację błahych kwestii, które często są hipotetycznymi przyszłymi problemami i w zasadzie jeszcze się nie pojawiły, zamiast skupiania się na tym, co faktycznie ważne.

Tło historyczne

Termin pochodzi z historii, w której grupa inżynierów, architektów i naukowców zostaje zatrudniona do budowy elektrowni atomowej, ale utknęła w martwym punkcie, decydując, gdzie i jak zbudować wiatę na rowery dla pracowników. Gdzie będziemy trzymać rowery? Ile rowerów powinna być w stanie pomieścić? Na jaki kolor powinna być pomalowana wiata? Cała ta uwaga poświęcona pracowniczej wiacie rowerowej skutkuje utratą funduszy i tym, że nie powstała ani wiata, ani elektrownia. Mówi się o tym również jako o prawie trywialności, co oznacza, że ludzie będą przykładać nieproporcjonalną wagę do błahych spraw. Lub w skrócie jest to też.... bicie piany!

Przykład

Powiedzmy, że za niecały miesiąc wprowadzasz swój produkt na rynek. Uczestniczysz w spotkaniu zespołu, starając się zaplanować kolejne trzy miesiące pracy. Jest tak dużo rzeczy do zrobienia, a produkt nawet jeszcze nie zadziałał! Mimo to wszyscy spierają się o to, jak pisać dokumentację: czy powinniśmy używać JS Doc? Dropbox Paper? Concourse? Wielu inżynierów poświęca swój cenny czas na tworzeniu nowych dokumentów czy stron typu wiki na swoich ulubionych platformach. Możesz zareagować np. tak: „Hej! Posłuchajcie mnie teraz wszyscy, zostawmy to na razie. W tym momencie nie ma to większego znaczenia. Po prostu wybierzcie jeden z wymienionych! To co teraz robimy to zwykłe bicie piany”.

Yak shaving

Golenie jaka oznacza pracę nad jednym zadaniem, które prowadzi do wykonania innego, a skutkuje pozornie niekończącą się kolejką zadań, które odwracają uwagę od pierwotnego celu.

Jednak w przeciwieństwie do bicia piany, to często każde z tych zadań jest ważne i w pewnym momencie musi zostać wykonane. Mogą one nawet być warunkiem wstępnym do osiągnięcia pierwotnego celu. Często pojawia się on w postaci długu technologicznego, który pojawia się, gdy próbujemy zrobić coś innego.

Tło historyczne

Termin ten został wprowadzony przez dr Carlina Vieri, absolwenta Massachusetts Institute of Technology, po tym, jak obejrzał odcinek “Rena i Stimpy” na początku lat 90. Odcinek “Yak Shaving Day” przedstawiał święto przypominające święta Bożego Narodzenia, podczas którego uczestnicy wieszają pieluchy, wypychają gumowce colesławem i wypatrują ogolonego jaka, który ma przepłynąć w swoim zaczarowanym kajaku. Zamiast zostawiać ciasteczka dla Świętego Mikołaja, dzieci zostawiają krem i maszynkę do golenia dla jaka, żeby mógł się ogolić przed wizytą w kolejnym domu.

Dzisiaj raczej nie nawiązujemy do serialu “Ren i Stimpy”, ale zastanawiamy się nad tym, co trzeba zrobić, aby ogolić jaka. Możesz podejść do jaka z nożycami, ale zdajesz sobie sprawę, że te nożyce są zardzewiałe, więc idziesz je naostrzyć. Kiedy jesteś już na zewnątrz, zdajesz sobie sprawę, że potrzebujesz nowego wiadra, aby umieścić w nim futro jaka, więc kupujesz nowe wiadro. I tak dalej, i tak dalej. Cały ten proces nazywany jest “goleniem jaka”, ponieważ golenie jaka to tak skomplikowane przedsięwzięcie.

Alternatywnie, termin ten mówi o tym, że golenie jaka jest jedną z wielu misji pobocznych, odciągających od pierwotnego celu. Być może ktoś, gdzieś tam, zaczął sobie dzień od wymiany żarówki, a skończył na goleniu jaka. Czasami ktoś korzystający z tej definicji może nawet wykrzyknąć: „Cokolwiek robisz, nie gól jaka!” do kogoś, kto robi coś na skróty.

Tutaj znajdziesz świetny klip ze "Zwariowanego świata Malcolma", gdzie zobaczysz, o co dokładnie chodzi w goleniu jaka.

Przykład

Być może przydzielono ci bug do naprawienia i zaczynasz go naprawiać, ale zdajesz sobie sprawę, że funkcja użytkowa, w której się znajduje, używa przestarzałej wersji pakietu. Tak więc aktualizujesz pakiet, po czym zdajesz sobie sprawę, że cała funkcja musi być refaktoryzowana. Więc robisz to, wyciągasz to do swojego własnego pliku i wkrótce twoja jednolinijkowa poprawka bugu rośnie jak balon. Rozpocząłeś swoją podróż, próbując naprawić jeden mały błąd, a skończyłeś na goleniu jaka.

Wszystkie te rzeczy, które zrobiłeś, były warte wykonania; naprawa długu technologicznego to zawsze ważna sprawa! Ale ważne jest również, jeśli to tylko możliwe, aby nadać priorytet temu, co naprawdę ważne i zanotować inne kwestie, jako błędy do naprawienia w przyszłości, niż opóźniać swoje zadanie w tym momencie.

Kaczka debugaczka 

Gumowa kaczka, czy też kaczka debugaczka polega na wyjaśnieniu kodu lub problemu na głos w nadziei, że proces opisujący sytuację oraz usłyszenie jej pomoże ci zdiagnozować problem. I często tak właśnie się dzieje!

Tło historyczne

W latach 90. pojawiła się słynna dzisiaj książka Pragmatyczny programista, która na wielu uniwersytetach jest nawet używana jako podręcznik. Znajduje się w niej historia o programiście, który nosił przy sobie gumową kaczkę i debugował swój kod, zmuszając się do wyjaśniania go, linijka po linijce, kaczce. Chodziło o to, że słuchanie siebie mówiącego na głos pomaga wyłapać błędy logiczne. I tym sposobem nie potrzebujesz już kolegi do wygadania się. Masz kaczkę.

Pomysł stał się tak popularny, że istnieje nawet naukowe podejście do „metody gumowej kaczki”.

Przykład

Usłyszenie na głos własnego wyjaśnienia tego, co się dzieje, może pomóc w szybszym usuwaniu problemów. Kanoniczną fikcyjną postacią jest gumowa kaczka, ale możesz użyć czegokolwiek. Możesz powiedzieć:  „Hej, czy pomożesz mi z tym problemem? Będę musiał skorzystać z metody gumowej kaczki”. Albo może poprosisz kolegę o pomoc w debugowaniu, a w połowie wyjaśniania problemu zdasz sobie sprawę, na czym polega problem i podziękujesz mu za bycie Twoją gumową kaczką.

Bus factor/lottery factor

Bus factor jest miarą poziomu odpowiedzialności i wiedzy, jaką posiada dana osoba lub zespół. Im niższy współczynnik, tym bardziej ryzykowne jest odejście tej osoby z zespołu.

Aktualizacja: Po opublikowaniu tego artykułu, zostałam poinformowana, że istnieje wiele sposobów na użycie tego terminu w zależności od lokalizacji. Porozmawiajmy o dwóch!

Tło historyczne

Termin ten jest również wczesnym terminem inżynierii oprogramowania z lat 90., którego dokładne pochodzenie jest trudne do ustalenia. Zamysł tego pojęcia jest następujący: jeśli jedna osoba z zespołu lub cały zespół, zostanie jutro potrącony przez autobus, czy firma będzie w stanie kontynuować pracę bez nich? Czy ktoś oprócz zespołu wie, co robią? Co w przypadku, jeśli to oni posiadali całą wiedzę na temat bazy kodu lub produktu? Co, jeśli nie napisali żadnej dokumentacji, nikomu nie mówili o tym, nad czym pracują, albo nawet szyfrowali swoją pracę?

W idealnej sytuacji informacje są przydzielane i delegowane do wielu osób w zespole, więc jeśli jedna osoba lub jej zespół zginie pewnego dnia, firma może działać dalej bez niej.

W popularniejszej wersji tego terminu, współczynnik bus factor jest obliczany na podstawie wymaganej liczby osób, które posiadają daną wiedzę. Tak więc, jeśli w firmie pracuje 100 osób i tylko 4 z nich wiedzą jak coś zrobić, współczynnik bus factor tego czegoś wynosi “4”, ponieważ są to 4 osoby, które zostały potrącone przez autobus. W tej wersji tego terminu najlepiej jest mieć wysoki współczynnik; im wyższy, tym mniejsze ryzyko. Najgorszym współczynnikiem bus factor w tym przypadku byłaby liczba 1, co oznacza, że gdyby jedna osoba zginęła, cały projekt zostałby wstrzymany.

W innej (rzadszej) wersji tego terminu współczynnik bus factor jest obliczany na podstawie liczby osób, które są niezbędne dla projektu. W idealnej wersji tej sytuacji nie chciałbyś mieć w zespole nikogo niezastąpionego i chciałbyś mieć współczynnik bus factor na poziomie nieskończoności, dlatego 0 to liczba idealna, ponieważ oznacza to, że nie ma żadnego pojedynczego punktu awarii.

Istnieje również wiele innych wariacji tego terminu, które są mniej brutalne niż potrącenie przez autobus. Jednym z bardziej popularnych, przyjemniejszych wersji współczynnika bus factor jest współczynnik lottery factor. Mówi nam o tym, że jeśli osoba wygra jutro na loterii i zdecyduje się przejść na wcześniejszą emeryturę, a następnie przeprowadzić się na wyspę, gdzie nie ma zasięgu, to jakie mamy tutaj ryzyko?

Przykład

Podczas rozwoju produktu możesz zauważyć pewne interesujące zachowania związane z organizacją pracy. Niektórzy ludzie biorą na siebie więcej pracy niż inni, niektórzy nie dokumentują tak dobrze jak inni, a jeszcze niektórzy nie rozmawiają zbyt często ze swoimi współpracownikami. Być może spotkałeś kiedyś taką osobę, do której udaje się każdy, gdy potrzebuje pomocy, a gdy jest na wakacjach, postęp staje w miejscu. Możesz powiedzieć: „Musimy zmniejszyć współczynnik bus factor tej informacji” lub nawet „Musimy zmniejszyć współczynnik bus factor tej osoby” i wdrożyć nowe procesy, które wymagają, aby nowy kod posiadał dokumentację lub zatrudnić więcej osób itp.

Dogfooding 

Określenie eating your own dog food (jeść karmę swojego psa) oznacza posiadanie zespołu, który stworzył produkt i jednocześnie jest jego użytkownikiem, jeszcze przed udostępnieniem go publicznie.

Tło historyczne

Pochodzenie tego wyrażenia jest nieco bardziej dyskusyjne. Najbardziej podoba mi się wyjaśnienie, że wywodzi się od reklamy karmy dla psów z lat 70, gdzie rzecznik Alpo, firmy produkującej karmę dla psów, powiedział, że jeśli ufa karmie na tyle, aby karmić nią swoje psy, to Ty też powinieneś. Wyrażenie „eat your own dog food” powstało prawdopodobnie właśnie z tej sytuacji i zostało użyte w mailu w latach 80. w Microsofcie, zachęcającym wszystkich do wewnętrznego testowania swoich produktów. Od tego czasu nazwa została skrócona do “dogfooding”.

Przykład

Jeśli pracujesz nad produktem przeznaczonym dla osób podobnych do pracowników Twojej firmy, możesz zasugerować, że “sam zjesz karmę dla psa” lub karmisz produkt karmą dla psów. Pomoże to nie tylko wyłapać bugi i problemy z przepływem produktu, ale także przyczyni się do wyższego poziomu empatii na linii pracownik-użytkownik i polepszy emocjonalny wkład pracownika w produkt. Koniec końców, jeśli sam używasz produktu swojej firmy, poczujesz się bardziej zachęcony do pracy nad nim. Zazwyczaj sprawdza się to najlepiej w przypadku firm B2B, gdzie docelowa baza użytkowników jest podobna do bazy osób pracujących nad projektem. Pomyśl tylko! Pracujesz nad Slackiem i jednocześnie rozmawiasz z zespołem na Slacku!

Mam nadzieję, że artykuł był dla Ciebie pomocny i pomoże ci rozszyfrować niektóre często używane wyrażenia w branży technologicznej.

Jeśli masz jeszcze jakieś inne ulubione, proszę skomentuj i podziel się nimi!

Oryginał tekstu w języku angielskim przeczytasz tutaj.