Wiele osób myśli o problemach, które ich dotyczą, przed pójściem spać lub po przebudzeniu. Nie jestem wyjątkiem. Dziś rano wpadło mi do głowy jedno z Habra:
Kolega podzielił się historią na czacie:
Rok temu miałem niesamowitego klienta, to było wtedy, gdy zmagałem się z czystym „kryzysem”.
Klient ma w grupie deweloperskiej dwa zespoły, każdy zajmujący się własną częścią produktu (warunkowo back office i front office, czyli oprogramowanie pracujące nad tworzeniem zamówień i oprogramowanie pracujące nad realizacją zamówień), okazjonalnie integrujące się ze sobą.
Zespół back-office upadł zupełnie: sześć miesięcy ciągłych problemów, właściciele grożą wszystkim zwolnieniem, zatrudnili konsultanta, po konsultantze zatrudnili więcej niż jednego (mnie). Co więcej, drugi zespół (storfront) pracował normalnie i nadal pracował normalnie, dopiero zespół back-office, który wcześniej też pracował normalnie, zaczął szwankować. Zespoły siedzą w różnych biurach i są przyzwyczajone do wkurzania się nawzajem.Powód: sklep i powrót to jeden system, jest w nim mnóstwo zależności, zespoły w różnych biurach nie komunikowały się ze sobą. Właściciele cały czas „patrzą” na boczny przód, więc tam mają nowe funkcje, pomysły i kontrolę. Była wszechstronnym chłopakiem, połączeniem licencjata, projektanta i „przynieś nam kawę”. Ten chłopiec, niezauważony przez swój zespół, wykonywał szereg drobnych zadań, takich jak „powiadomienie drugiego zespołu o wdrożeniu”, „aktualizacja dokumentacji” itp. rutynową procedurę, aż do „wprowadzenia wszelkiego rodzaju numerów wersji i komponentów do zgłoszenia”. Chłopak nie napisał jednak żadnego kodu i w pewnym momencie właściciele postanowili go zoptymalizować i zwolnić. Dla zespołu sklepu nic się nie zmieniło, po prostu nie zrobili ani nie zaktualizowali doków, a zespół backoffice znalazł się w sytuacji, w której wydania sklepu coś im psują i to jest ich problem, a jeśli ich wydania coś psują sklep, to znowu ich problemy, bo sklep jest na widoku właścicieli :)
Co przykuło moją uwagę w tym komentarzu i co szukający znajdzie z tytułu - pod wycięciem.
Od 20 lat zajmuję się tworzeniem aplikacji internetowych, więc przód/tył to dla mnie nie tylko słowa. To są bardzo ściśle ze sobą powiązane sprawy. Nie wyobrażam sobie np. sytuacji, w której przód jest opracowany w całkowitej (lub bardzo mocnej) izolacji od tyłu. Obie strony operują na tych samych danych i wykonują bardzo podobne operacje. Z grubsza mogę sobie wyobrazić, ile informacji przepływa między programistami obu zespołów w celu koordynowania rozwoju oraz jak długo i jak często należy dokonywać tych zatwierdzeń. Zespoły nie mogą powstrzymać się od ścisłej komunikacji, nawet jeśli znajdują się w różnych strefach czasowych. Zwłaszcza jeśli masz JIRA.
Wiem, że nie ma sensu ostrzegać back-deweloperów przed rozłożeniem frontu. Nowa wersja przodu nie jest w stanie niczego zepsuć z tyłu, a wręcz przeciwnie – tak. To programiści front-endowi są zainteresowani powiadamianiem programistów back-endu o tym, że potrzebują nowej lub zmienionej funkcjonalności. Przód zależy od rozmieszczenia tyłu, a nie odwrotnie.
Jaki chłopak, który”przynieś nam kawę„, nie może być licencjata (jeśli przez BA rozumiemy „analityka biznesowego”), a licencjat nie może być „chłopcze, przynieś nam kawę". I oczywiście, "dodaj wszelkiego rodzaju numery wersji i komponenty„Ani „chłopiec”, ani BA nie mogą tego zrobić bez dyskusji z zespołami programistów. To jak wóz przed koniem.
Ponieważ „chłopiec” został zwolniony, wówczas te funkcje, od „przynieś kawę"a wcześniej"włożyć tłuszcz", powinno zostać rozdzielone pomiędzy pozostałych członków zespołu. W ustalonej grupie przepływ informacji i role są stałe; jeśli wykonawca jednej lub kilku ról zszedł ze sceny, to pozostali członkowie grupy nadal mają potrzebę otrzymania znajomych informacje ze znajomych ról. Po prostu nie mogą nie zauważyć, że informacje potrzebne do pracy przestały do nich docierać. To tak, jakby narkoman nie mógł nie zauważyć, że podaż narkotyków się skończyła. I tak jak narkoman szuka i znajduje inne kanały, więc członkowie grupy będą starali się znaleźć źródła potrzebnych informacji po „drugiej” stronie i nowych wykonawców starych ról. I na pewno znajdą przynajmniej kogoś, kto ich zdaniem powinien dać im niezbędne informacje.
Nawet jeśli założymy, że zwykłe kanały informacyjne zostały zamknięte, a ten, kto powinien, nie uważa, że powinien, to back developerzy pod groźbą zwolnienia nie będą przez dłuższy czas ukrywać przed właścicielem przyczyn własnych niepowodzeń sześciu miesięcy, wiedząc, że ich problemy wynikają z braku niezbędnych informacji. Właściciele nie będą „głupimi” przez sześć miesięcy, skoro już wcześniej potrzebowali informacji.był pokryty tłuszczem", a teraz nikt tego tam nie dodaje. A pierwszy konsultant nie zachował się na tyle nieprofesjonalnie, żeby nie porozmawiać z programistami zaplecza i nie dotrzeć do źródła problemu - braku koordynacji pomiędzy zespołami. To jest powód opisanych kłopotów, a nie zwolnienie „chłopca”.
Banalny brak komunikacji między programistami jest typową przyczyną wielu problemów w rozwoju i nie tylko. Nie musisz być świetnym konsultantem, żeby to znaleźć. Wystarczy zachować rozsądek.
Myślę, że cała ta historia jest dobrze przemyślana i pięknie opowiedziana. No nie do końca wymyślone - wszystkie elementy są wzięte z życia (przód, tył, rozwinięcie, chłopak, kawa),tłuszcz", ...). Ale są one połączone w taki sposób, że taki projekt nie występuje w życiu. Osobno to wszystko można znaleźć w otaczającym nas świecie, ale w takim połączeniu - nie. Napisałem powyżej, dlaczego .
Zostało to jednak przedstawione bardzo wiarygodnie. Czyta się ją z zainteresowaniem i wiąże się z osobistym zaangażowaniem. Współczucie dla „poręczny chłopak„, niedoceniany mały mechanizm wielkiej maszyny (to o mnie!). Protekcjonalność wobec programistów, którzy są tak mądrzy i doświadczeni, ale nie potrafią patrzeć poza własny nos (oni są wszędzie wokół mnie!). Lekka kpina z właścicieli, bogatych facetów, którzy własnoręcznie zrobili sobie „bo-bo” i nie rozumieją powodów (No cóż, okropny obraz mojego przywództwa!). Pogarda dla pierwszego „konsultanta”, któremu nie udało się znaleźć tak prostego źródła problemów (tak, ostatnio przyszedł ten facet w okularach i chodził po okolicy, wyglądając elegancko) i entuzjastyczną jedność z „prawdziwym” konsultantem, który jako jedyny potrafił docenić prawdziwą rolę specjalisty od wszystkiego (to ja!).
Czy czujesz wewnętrzną satysfakcję po przeczytaniu tego komentarza? Nasza rola jako małych trybików w dużym mechanizmie wcale nie jest taka mała! Wspaniale powiedziane, nawet jeśli to nieprawda. Ale jaki przyjemny posmak.
Nie wiem, jaki kolega i na jakim czacie podzieliłem się z kolegą tym odkryciem i dlaczego kolega mkrentowski Postanowiłem opublikować go pod artykułem „„wybitny hab-autor „a (który notabene jest w tej chwili na pierwszym miejscu w rankingu Habra!), ale przyznam, że mój kolega mkrentowski zrobił to wyjątkowo dobrze. Przesłanie komentarza i styl prezentacji są więc spójne z przekazem i stylem innych publikacji nmivan„No cóż, co myślisz, że konsultant kryzysowy z komentarzy i GG wielu publikacji nmivan„a” to ta sama osoba.
Czytałem sporo publikacji Iwana Biełokamentewa, kiedy autor rozpoczynał swoją działalność na Habré (w 2017 r.). Niektórzy nawet to lubią (, ). Ma dobry styl i ciekawą prezentację materiału. Jego historie są bardzo podobne do historii z życia wziętych, ale prawdopodobieństwo ich wystąpienia jest prawie zerowe . Tak właśnie jest z tą historią w komentarzu.
Prawdę mówiąc, osobiście nie sądzę, że Habrowi polepszyło się dzięki publikacjom Iwana. Ale jego ocena i inni mieszkańcy Habr mówią odwrotnie:
Nie rozumiem twojego marudzenia. Habr już dawno się poślizgnął, ale autor daje odrobinę iskierki i poprawia humor czytelnikom) wyciągając zasób z otchłani.
Tak, Habr nie jest organizacją charytatywną, Habr to projekt komercyjny. Habr jest lustrem, w którym odbijają się nasze pragnienia. Nie moje osobiste pragnienia i nie pragnienia każdego indywidualnego gościa, ale całość wszystkich naszych pragnień - „średnia dla szpitala”. A Iwan Belokamentsev czuje się lepiej niż ktokolwiek inny, czego wszyscy potrzebujemy wspólnie, i daje nam to.
Być może nie napisałbym tego artykułu, gdybym nie zaczął oglądać serialu”".
"Straciliśmy Boga" (Z)
To jest z serialu. I to dotyczy nas.
Nie jesteśmy już zniewoleni rzeczywistością stworzoną przez Stwórcę.
Bóg, natura, Wielki Wybuch – cokolwiek. Rzeczywistość istnieje. Wokół nas i niezależnie od nas.
Żyjemy w nim zgodnie z prawami natury (Plan Boga). Uczymy się praw (Planuj) i uczymy się wykorzystywać rzeczywistość, w której żyjemy, aby żyć jeszcze lepiej. Nasze domysły sprawdzimy w praktyce, odrzucając błędne i pozostawiając te właściwe. Wchodzimy w interakcję z rzeczywistością i ją zmieniamy.
I odnieśliśmy w tym sukces.
Na planecie jest wielu ludzi. Tak wiele. Przy obecnej wydajności pracy nie musimy już przetrwać – mniejszość może zapewnić większości wszystko, czego potrzebuje. Większość ludzi musi się czymś zająć. Historycznie rzecz biorąc, nadwyżki zasobów przeznaczonych na kreatywność trafiały do najbardziej utalentowanych (lub najbardziej destrukcyjnych, co jest również talentem). Teraz jest tak wiele darmowych zasobów, że każdy z dowolnym talentem może je zdobyć, niezależnie od poziomu. Porównaj, ile filmów ukazuje się rocznie na całym świecie i ile z nich można obejrzeć. Ile książek zostało napisanych i które z nich można przeczytać. Ile informacji jest wyrzucanych w Internecie i jakie z nich można wykorzystać.
Dlaczego zawód IT jest tak popularny? Tak, bo w IT można wlać otchłań zasobów i nikt nie mrugnie okiem (tylko przypomnijcie sobie problem roku 2000). W końcu w IT można spędzić lata tworząc aplikacje, które staną się przestarzałe jeszcze zanim zostaną uruchomione, można próbować zintegrować niekompatybilne komponenty i mimo to sprawić, by działały, można ciągle wymyślać koła na nowo lub można to zrobić już teraz zacznij wspierać programy w Fortranie, który przez kolejne 20 lat temu był porośnięty mchem. Można całe życie spędzić w IT i nie robić nic pożytecznego. A co najważniejsze, nikt tego nie zauważy! Nawet siebie.
Niewielu z nas będzie w stanie odcisnąć piętno w branży IT. A jeszcze mniej osób będzie mogło pozostawić po sobie dobrą pamięć. Wyniki naszej pracy ulegną deprecjacji w najlepszym przypadku w ciągu najbliższych 10-20 lat, a nawet wcześniej. A już na pewno za naszego życia (o ile osiągniemy wiek emerytalny). Nie będziemy mogli pokazać naszym wnukom systemów komputerowych, nad którymi pracował ich dziadek w młodości. Ludzie po prostu zapomną swoje imiona. Na początku swojej kariery budowałem stacje pocztowe pod "„. Jeszcze 20 lat do emerytury i 10 lat do posiadania wnuków, ale większość z Was nie słyszała już o „wybitnej aplikacji e-mail z połowy lat 90-tych” („najpopularniejszy pakiet oprogramowania e-mail z połowy lat 1990-tych").
Być może w rzeczywistości nie zdajemy sobie sprawy z daremności naszego IT, ale w podświadomości staramy się uciec tam, gdzie jest nam wygodnie. W fikcyjne światy, w których zastosowanie Scruma i Agile nieuchronnie prowadzi do pojawienia się produktów, które od dziesięcioleci podbijają świat swoją użytecznością. Gdzie nie jesteśmy zwykłymi małymi zębatkami dużych mechanizmów, ale zębatkami, bez których pękają duże mechanizmy. Gdzie nasze życie nie toczy się na bezsensownym wykonywaniu rutynowych czynności, ale przepełnione jest kreatywnością i twórczością, z której rezultatów możemy być dumni.
Uciekamy w te piękne, fikcyjne światy od naszej własnej bezwartościowości w świecie rzeczywistym. Szukamy u nich pocieszenia.
Szukamy pocieszenia, także na Habré. I Iwan nam to daje.
Źródło: www.habr.com