Wiele osób myśli o swoich palących problemach przed snem lub po przebudzeniu. Nie jestem wyjątkiem. Dzisiaj rano w mojej głowie pojawiła się jedna z Habr:
Kolega w czacie podzielił się historią:
Miałem w zeszłym roku fantastycznego klienta, to jeszcze kiedy brałem czysty "kryzys".
U klienta w grupie deweloperskiej są dwie drużyny, każda zajmuje się swoją częścią produktu (umownie, back office i front store, czyli oprogramowanie pracujące nad tworzeniem zamówienia oraz oprogramowanie, które zajmuje się realizacją zamówienia), sporadycznie integrując się ze sobą.
Zespół back office naprawdę mocno wpadł w dołek: sześć miesięcy ciągłych błędów, właściciele grożą wszystkim zwolnieniem, zatrudnili konsultanta, a po konsultancie zatrudnili mnie. Przy czym drugi zespół (front store) pracował normalnie i nadal pracował normalnie, to właśnie back office, który wcześniej także działał poprawnie, zaczął mieć problemy. Zespoły siedzą w różnych biurach i przyzwyczaiły się do psucia sobie nawzajem.Przyczyna: front i back to jeden system, w którym istnieje mnóstwo zależności, zespoły w różnych biurach, między sobą nie rozmawiały. Właściciele cały czas "patrzyli" na front store, w związku z czym mieli tam nowe funkcje, pomysły i kontrolę. W tym był chłopak od wszystkiego, taka kombinacja BA, projektanta i "przynieś nam kawę". Ten chłopak, niezauważony przez swój zespół, wykonywał mnóstwo drobnych zadań typu "ostrzeganie drugiego zespołu o wdrożeniu", "aktualizacja dokumentacji" itp. rutynę, aż po "wprowadzenie w JIRA różnych numerów wersji i komponentów". Ale kodu chłopak nie pisał i w pewnym momencie właściciele postanowili go zredukować, zwalniając go. Dla zespołu front store nic się nie zmieniło, po prostu nie wprowadzali i nie aktualizowali dokumentów, a zespół back office znalazł się w sytuacji, w której wydania front store łamią im coś, i to ich problemy, a jeśli ich wydania łamią coś w front store, to znów ich problemy, ponieważ front jest na widoku właścicieli 🙂
Co mnie zaintrygowało w tym komentarzu i co odnajdzie poszukujący z tytułu — pod katem.
Zajmuję się tworzeniem aplikacji webowych od około 20 lat, więc front i back-end to dla mnie nie tylko słowa. To są ze sobą ściśle powiązane aspekty. Nie potrafię sobie wyobrazić sytuacji, w której front jest rozwijany w pełnym (lub bardzo silnym) oderwaniu od back-endu. Po obu stronach operuje tymi samymi danymi, wykonują bardzo podobne operacje. Mniej więcej wiem, jak ogromna ilość informacji przepływa między programistami obu zespołów w celu uzgodnienia rozwoju, i jak często takie uzgodnienia muszą być przeprowadzane. Zespoły muszą ze sobą blisko współpracować, nawet jeśli znajdują się w różnych strefach czasowych. Tym bardziej, gdy mamy JIRA.
Wiem, że ostrzeganie back-endowych programistów o wdrożeniu frontu jest bezsensowne. Nowa wersja frontu nie może złamać niczego w back-endzie, ale na odwrót — już tak. To programiści frontu są zainteresowani informowaniem programistów back-endu, że potrzebują nowego lub zmodyfikowanego funkcjonalności. Front zależy od wdrożeń back-endu, a nie odwrotnie.
Co chłopiec, który "przynieś nam kawę", nie może być BA (jeśli przez BA rozumie się "analityka biznesowego"), a BA nie może być "chłopiec, przynieś nam kawę". I z pewnością, "wprowadzać do JIRA różne numery wersji i komponenty" bez konsultacji z zespołami deweloperów ani "chłopiec", ani BA nie mogą. To jak wóz przed koniem.
Skoro "chłopiec" został zwolniony, to dane funkcje, od "przynieś kawę" do "wprowadź do JIRA", powinny były zostać rozdzielone pomiędzy innych członków zespołów. W ugruntowanej grupie przepływy informacji i role są ustalone, jeśli wykonawca jednej lub kilku ról opuścił scenę, to pozostali członkowie grupy pozostają w potrzebie otrzymania przyzwyczajonej informacji od znanych ról. Po prostu nie mogą nie zauważyć, że informacje niezbędne do pracy przestały do nich docierać. To tak, jak narkoman nie może nie zauważyć faktu zaprzestania dostarczania narkotyków. I tak jak narkoman szuka i znajduje inne kanały, tak i członkowie grupy będą próbować znaleźć źródła potrzebnych im informacji po "tamtej" stronie i nowych wykonawców starych ról. I na pewno znajdą. Przynajmniej kogoś, kto ich zdaniem powinien dać im potrzebne informacje.
Nawet jeśli założyć, że przyzwyczajone kanały informacji się załamały, a ten, kto powinien, nie uważa, że powinien, to deweloperzy backendu pod groźbą zwolnienia nie będą przez pół roku ukrywać przyczyn własnych niepowodzeń przed właścicielem, wiedząc, że ich błędy wynikają z braku potrzebnych informacji. Właściciele nie będą "głupieć" przez pół roku, widząc, że wcześniej potrzebne informacje "były w zapisie", a teraz nikt ich tam nie wprowadza. I pierwszy konsultant raczej nie był na tyle nieprofesjonalny, żeby nie porozmawiać z deweloperami backendu i nie dotrzeć do źródła problemu — braku uzgodnienia między zespołami. To właśnie w tym tkwi przyczyna opisywanych nieszczęść, a nie w zwolnieniu "chłopca".
Banalny brak komunikacji między programistami to typowy powód wielu problemów w rozwoju i nie tylko. Nie trzeba być wybitnym doradcą, aby to dostrzec. Wystarczy być po prostu rozsądnym.
Uważam, że cała ta historia jest wymyślona i pięknie przedstawiona. Cóż, nie całkowicie wymyślona — wszystkie elementy wzięte są z życia (frontend, backend, rozwój, chłopiec, kawa, "zapis", ...). Ale są połączone w taki sposób, że w życiu taka konstrukcja się nie zdarza. Osobno można to spotkać w otaczającym świecie, ale w takiej kombinacji — nie. Napisałem wcześniej dlaczego.
Niemniej jednak, jest opisana bardzo wiarygodnie. Czyta się z zainteresowaniem i jest obecna osobista zaangażowanie. Współczucie dla "chłopca od wszystkiego", niedocenianego małego mechanizmu wielkiej maszyny (to o mnie!). Pobłażliwość dla programistów, takich mądrych i doświadczonych, ale nie widzących dalej własnego nosa (oni są wokół mnie!). Lekka kpiną z właścicieli, bogatych panów, którzy sami zrobili sobie "bobo" i nie rozumieją powodów (jakbym opisywał moje kierownictwo!). Lekceważenie pierwszego "konsultanta", który nie potrafił znaleźć tak prostego źródła problemów (tak, przychodził ostatnio taki w okularach, chodził z mądrą miną), i entuzjastyczne zjednoczenie z "prawdziwym" konsultantem, który jako jedyny potrafił ocenić prawdziwą rolę chłopca do wszystkiego (a więc mnie!).
Czy czujesz wewnętrzną satysfakcję po przeczytaniu tego komentarza? Nasza rola małych trybików w wielkim mechanizmie w rzeczywistości wcale nie jest taka mała! Doskonale przedstawione, choć nieprawdziwe. Ale jakie przyjemne posmak.
Nie wiem, kim jest ten kolega i w jakim czacie podzielił się tym odkryciem z innym kolegą. i dlaczego kolega mkrentovskiy postanowił go opublikować pod artykułem "" znakomitego autora z Habr-a ‘a (który jest zresztą obecnie na pierwszym miejscu w rankingu Habr!), ale przyznaję, że kolega mkrentovskiy zrobił to wyjątkowo dobrze. Przesłanie komentarza i styl wyrażenia są tak zbieżne z przesłaniem i stylem innych publikacji nmivan‘a, że można pomyśleć, że kryzysowy konsultant z komentarza i główny bohater wielu publikacji nmivan‘a — to ta sama osoba.
Czytałem sporo publikacji Iwana Białokamieńca, kiedy autor rozpoczął swoją działalność na Habrze (w 2017 roku). Niektóre nawet z przyjemnością (, ). Ma dobry styl i interesującą prezentację materiału. Jego historie są bardzo podobne do historii z życia, ale praktycznie nie mają szans na wydarzenie się w rzeczywistości, w . Oto jak z tą historią w komentarzu.
Szczerze mówiąc, osobiście nie uważam, że publikacje Iwana poprawiły Habr. Jednak jego ranking i innych mieszkańców Habr mówią coś przeciwnego:
Nie rozumiem Twojego narzekania. Habr już dawno zszedł na psy, a autor daje trochę iskierki i podnosi nastrój czytelnikom) wyciągając zasoby z otchłani.
Tak, Habr to nie charytatywność, Habr to projekt komercyjny. Habr to lustro, które odzwierciedla nasze pragnienia. Nie moje osobiste pragnienia i nie pragnienia każdego pojedynczego odwiedzającego, ale suma wszystkich naszych pragnień — "średnia w szpitalu". A Iwan Białokamiencow najlepiej czuje, czego nam wszystkim wspólnie potrzeba, i dostarcza to nam.
Może nie napisałbym tego artykułu, gdybym nie zaczął oglądać serialu "".
"Straciliśmy Boga" (c)
To z serialu. I to o nas.
Przestaliśmy być zainteresowani rzeczywistością stworzoną przez Twórcę.
Bogiem, Naturą, Wielkim Wybuchem — jak wolisz. Rzeczywistość jest. Wokół nas i niezależnie od nas.
Żyjemy w niej zgodnie z prawami natury (zamysłem Bożym). Poznajemy te prawa (zamysł) i uczymy się wykorzystywać rzeczywistość, w której żyjemy, aby żyć jeszcze lepiej. Praktyką weryfikujemy nasze hipotezy, odrzucając błędne i zostawiając aktualne. Wchodzimy w interakcję z rzeczywistością i zmieniamy ją.
I naprawdę bardzo nam to wychodzi.
Ludzi na planecie jest wielu. Bardzo wielu. Przy obecnej wydajności pracy nie musimy już tylko przetrwać — mniejszość może zapewnić większości wszystko, czego potrzebują. Większość z nas musi się czymś zająć. Historycznie nadwyżka zasobów przeznaczona na twórczość trafiała do najbardziej utalentowanych (lub najsprawniejszych, co również jest talentem). Obecnie jest tyle wolnych zasobów, że trafiają one do wszystkich w miarę uzdolnionych, niezależnie od ich poziomu. Porównaj, ile filmów powstaje rocznie na całym świecie i ile z nich da się oglądać. Ile książek jest pisanych i które z nich warto przeczytać. Ile informacji zalewa Internet i co z tego ma jakąkolwiek wartość.
Dlaczego zawód informatyka jest tak popularny? Ponieważ w IT można wydawać nieograniczone zasoby i nikt nawet nie mrugnie (przypomnijcie sobie chociażby o problemie roku 2000). W IT można przez lata rozwijać aplikacje, które zdążą się zestarzeć zanim zostaną uruchomione, można próbować integrować niekompatybilne komponenty i jakoś je uruchomić, można za każdym razem wymyślać własne rowery, a można również teraz zająć się wsparciem programów napisanych w Fortran'e, który porósł mchem 20 lat temu. W IT można spędzić całe życie i nic nie zrobić użytecznego. I co najważniejsze — nikt tego nie zauważy! Nawet ty sam.
Niewielu z nas uda się pozostawić ślad w branży IT. A jeszcze mniejszej liczbie osób uda się pozostawić po sobie miłe wspomnienie. Wyniki naszej pracy stracą swoją wartość w ciągu najbliższych 10-20 lat w najlepszym przypadku, a nawet wcześniej. I z pewnością za naszego życia (jeśli dożyjemy wieku emerytalnego). Nie będziemy mogli pokazać naszym wnukom systemów komputerowych, nad którymi w młodości pracował ich dziadek. Ludzie po prostu zapomną ich nazwy. Na początku swojej kariery zajmowałem się stacjami pocztowymi. pod "". Mam jeszcze 20 lat do emerytury i 10 lat do wnuków, ale już teraz większość z was nic nie słyszała o "znakomitej aplikacji pocztowej z połowy lat 90-tych" ("najlepszym pakiecie oprogramowania pocztowego z połowy lat 90.").
Może w rzeczywistości mało zdajemy sobie sprawę z bezsensowności naszego IT-owego brzemienia, ale podświadomie dążymy do ucieczki tam, gdzie czujemy się komfortowo. Do wymyślonych światów, gdzie stosowanie Scrum i Agile z pewnością prowadzi do powstania produktów, które przez dekady podbijają świat swoją użytecznością. Gdzie nie jesteśmy tylko małymi trybikami dużych mechanizmów, lecz trybikami, bez których te mechanizmy się psują. Gdzie nasze życie nie przebiega w bezsensownym wykonywaniu rutynowych działań, lecz jest pełne kreatywności i twórczości, z której możemy być dumni.
Uciekamy w te piękne, wymyślone przez kogoś światy od naszej własnej bezsensowności w realnym świecie. Szukamy w nich pocieszenia.
Szukamy pocieszenia również na Habrze. A Ivan daje nam je tutaj.
Źródło: habr.com
