O złym zarządzaniu

Minęło półtora miesiąca odkąd poprzednia firma nie przedluzyla mi umowy.
Zastanawiałam się wtedy o co chodzi.
Dzis ucielam sobie dluzsza pogawędkę z dwoma osobami, które tam nadal pracują i pewne rzeczy wyjaśniły się.
Nie mieli nikogo na moje miejsce – pozycja jest nadal nie obsadzona i nikt nie zamierza nikogo zatrudniać. Nie bylo tez zadnego reorg ani zadnego ulepszania czy poprawiania dzialu QA. Dir of engineering, do ktorego teoretycznie teraz moi byli podwladni raportuja, zupelnie ich pracą nie interesuje się. Nie informuje ich tez co dzieje sie w dziale developers, a poniewaz nie sa zapraszani na zadne zbiorcze meetingi, to kompletnie nie wiedzą, co się dzieje, kto nad czym pracuje i jaki będzie następny projekt do testowania. W tych warunkach nawet jakby chcieli, to nie są w stanie się przygotować, o takich fanaberiach jak pisanie testkejsów już w ogole nie wspomne.
Release, nad którą pracowali w momencie mojego odejścia, była juz 3 razy opóźniana z powodu niegotowości. Nie dziwi, ze nie jest gotowa, skoro praca nad nią wyglada tak:
– chlopcy testuja, co maja odhaczone jako „fixed” bugs w systemie
– ok. 40-50% bugów jest nie poprawiona, na dodatek próby poprawek generują nowe błędy
– chłopacy wysyłają emaila do wszystkich zainteresowanych z listą problemów i wyjaśnieniem
– czekaja tydzień, nic się nie dzieje. Wysyłaja ponaglenia, nic sie nie dzieje (slowem sa kompletnie olewani)
– na 2-3 dni przed wyznaczonym terminem release odzywa sie dir of eng z pytaniem gdzie są z testowaniem
– email z listą problemów jest wysłany raz jeszcze, developery rzucają się na gwalt poprawiac, w ostatniej chwili rzucają swieżutki kod, który oczywiście znowu generuje falę nowych problemów i termin znów zostaje przesunięty.

Co bardziej przytomni developerzy widzą, że statek tonie i jak narazie dwóch już znalazło sobie nową pracę i zwolnili się.
Takie zarządzanie to jest recipe for a disaster i ona prędzej czy później się wydarzy. To tylko kwestia czasu az zdarzy się taki bug, który wywali w drobny mak serwery produkcyjne – tym bardziej, ze przeciez srodowiska testowego, będącego kopią production jak nie bylo, tak nie ma. Tempo poprawiania czegokolwiek padło na pysk – ta release, co sie opóźnia, nie zawiera żadnych nowych features, tylko bug fixes.

Zastanawiam się więc: czy są to działania wynikające z glupoty, niekompetencji i kompletnej ignorancji czy też może są to dzialania celowe? Ostatecznie obecny CEO, derehtor jeden (dzialu engineers) i drugi (marketing communications) przyszli z… firmy konkurencyjnej, która jak narazie za robotę developerską musi mojej eks-firmie placić spore pieniądze. Nie jest wykluczone, ze taki styl zarządzania jest celowy – zeby obnizyc wartosc firmy w celu jej jak najkorzystniejszego późniejszego przejęcia..słowem, czy to jeszcze głupota, czy już sabotaż…?
Cóż, czas pokaże, i to raczej czas dluższy, bo inercja w takich wypadkach bywa spora i mogą jeszcze z rok a nawet więcej pociągnąć – chyba ze coś się spektakularnie j*bnie. A szanse są duuuże…
Nie ma w tej chwili w dziale eng ani jednej osoby, która ogarniałaby codebase i wiedziała jak to wszystko dziala. Kod ma 10 lat i sklada sie z patcha na patchu patchem poganianego. Jest tak koszmarnie napisany że nawet ja, nie programująca na codzień, jak grzebałam w SVN to mi się po prostu rzygać chciało. Szkolne pieprzone błędy, żadnego pomyślunku, organizacji, dokumentacji – ot każdy następny programista tu se coś srutnął, tam se coś srutnął – a ze przy tym zepsuł dziesięć innych rzeczy – who cares? Że zrobil to tak, ze parę negative tests wywala całą funkcjnalność na ryja? Niech się support martwi, jak to odkręcać….

Ta…
A potem jak mi ktoś mówi, że upper management zarabia kupę szmalu bo ma świetne kompetencje, to jedynie ogarnia mnie pusty śmiech…

Reklamy