sobota, 9 maja 2015

Jak marnuje sie pieniadze w duzych firmach.

Historyjka zainspirowana wczorajszymi nadgodzinami, a dokladnie change. Jak ktos nie wie, co to jest change, to odsylam do Wikipedii po angielsku i wklejam tlumaczenie z polskiej strony ITILa. Change Management - Wiki

"ITIL Przekazanie Usług) Dodanie, modyfikacja lub usunięcie czegokolwiek, co mogłyby mieć wpływ na usługi informatyczne. Pojęcie zmiany obejmuje swym zakresem każdą zmianę w architekturze, procesach, narzędziach, miarach i dokumentacji, jak również zmiany w usługach informatycznych i innych elementach konfiguracji (CIs)."

System zatwierdzenia zmian u mojego pracodawcy drastycznie sie zmienil w polowie marca. Generalnie zamrozono wtedy wszystkie zmiany i wprowadzono dodatkowy mechanizm ich zatwierdzania. Kiedys drobne zmiany byly zatwierdzane mailowo, wieksze byly zatwierdzane na cotygodniowym spotkaniu - CAB meeting. Typowa procedura w wielu firmach. U nas jednak wprowadzono nowe zasady, codziennie o 15.00 spotkanie i rozpatrywanie wnioskow petentow, odrzucanie z byle powodow, wymagania dopisywania nie wiadomo jakich planow, wyjasnienie, itp.

Jeden z bardziej zalosnych przypadkow odrzucenia change: bo zalaczony Install Plan byl pusty. Nie byl pusty, osoba ktora go sprawdzala nie przewinela okienka w Excelu. Wyobrazcie sobie zbulwersowanie osoby, ktora zalogowala sie o 19.00, zeby wykonac swoja prace i dowiedziala sie z jakiego powodu jej change zostal odrzucony. A pieniadze leca, bo przeciez inzynier zalogowal sie z domu i stracil czas.

Czynnosci techniczne, ktore zajmuja czasami 5 minut, wymagaly godzin pisania uzasadnien, walki o zatwierdzenie, itp. Dodatkowo wprowadzono obowiazek wykonywania wszystkich, nawet najdrobniejszych zmian miedzy 19.00, a 7.00 rano. Rowniez w weekend, gdy zwykle prace wykonywalo sie w ciagu dni, bo godziny biznesowe za pon-pt 8.00-18.00.

Kiedys maly change pisalo sie w 15 minut i przy dobrych wiatrach dostawalo zatwierdzenie w 2h. Czynnosci nie wymagajace wylaczenia serwera/uslugi, bez wiekszego wplywu na srodowisko, wykonywalo sie w ciagu godzin biznesowych.

Zadanie, ktore mielismy wykonac w piatek: przesunac 16 blades miedzy enclosures. Do tego dokonac malych zmian konfiguracyjnych, zeby dzialaly w nowym miejscu. Pisanie samego change'a zajelo co najmniej 8h przez kilka osob, zeby zaspokoic wszystkie wygorowane wymagania. Po drodze zaliczylismy kilka odrzucen, wprowadzanie poprawek, opisywanie kazdej czynnosci krok po kroku (copy - paste z instrukcji HP, itp). Po 2 tygodniach spotkan, walki z nowym systemem, wreszcie dostalismy zgode na wykonanie naszego prostego zadania.

Piatek, 19.00, 5 osob wdzwania sie na rozmowe konferencyjna, zeby potwierdzic, ze tak, mozemy zaczynac prace. Gosc w Data Centre przeklada jeden blade, ja zmieniam konfiguracje i wlaczam blade, gosc od Citrixa sprawdza, ze wszystko dziala. Informujemy 2 project managerow, ktorzy sa online, ze dziala. Dobra, to mozemy przesunac kolejne 7 blades. Cala praca wykonana w 1h, wszystko dziala. Change zaplanowana na 4h. W zwiazku z tym sugeruje, zeby moze przesunac pozostale 8 blades, skoro wszyscy juz jestesmy online, mamy czlowieka w data centre i cala czynnosc zajela tylko 1h.

Project managerowie mowia, ze absolutnie nie mozemy tego zrobic, bo Change Management nas zabije, bo change plan zaklada, ze dzisiaj przesuniemy tylko 8 maszyn, a kolejne beda przesuniete w poniedzialek. Dodam, ze te pozostale 8 serwerow jest wylaczonych juz od czwartku i pozostana wylaczone do poniedzialku wieczorem, kiedy to beda przesuniete. I tak sa juz wylaczone z uslug, ale nie, nie mozemy ich przesunac. Kiedys, przed wprowadzeniem obostrzen nikt by nawet ramionami nie wzruszyl, sprzet zostalby przesuniety, serwery wrocilyby do uzytku, manager cieszylby sie, ze trwalo to tylko 2h zamiast 8h i oszczedzi na nadgodzinach.

Kazda z osob online potwierdzila, ze zgodnie z planem liczymy 4h nadgodzin kazdy, mail do change management zostaje wyslany pare godzin pozniej, zeby nie bylo, ze za szybko cos zrobilismy i nasz plan byl zly i musimy znowu wprowadzic poprawki do poniedzialkowego zajecia. I w ten sposob poszlo 20h nadgodzin, zamiast 5h (dla wszystkich).  Do tego godzina kazdego z nas ma inna cene.

Caly ten cyrk jest jednym z powodow, dla ktorych chce ewakuowac sie jak najszybciej od tego pracodawcy, dwie osoby juz odeszly/nie przedluzyly kontraktow. Jest tez problem z rekrutacja nowych, bo nie pala sie do pracowania po godzinach pare wieczorow w tygodniu. Pracownicy, managerowie, klienci, wszyscy sa sfrustrowani i nikt nie dostaje wyjasnien ile to ma jeszcze trwac i czy w ogole w czyms to pomoglo, bo nikt nie widzi nic pozytywnego w nowym procesie.

To tyle narzekania i wgladu w zycie korporacji.

12 komentarzy:

  1. Fajnie się to czyta, kto popracował w kilku korporacjach wie jak jest. Papiery, papierologia i na dodatek biurokracja. Na przykład pracując w jednym z amerykanskich bankow aby zalogować się na serwer i sprawdzić czy proces bazy danych działa (login, haslo, i polecenie unixowe ps - calosc max 5 sekund przy użyciu putty) należało wypełniać papiery, winoski itd co zajmowało +- 15 minut. I skonczyło się na tym, że kiedy monitoring informował, że baza nie odpowiada, to nikt się nie logował aby to sprawdzić... Dopiero jak po godzinie przyszedł kolejny alert, ludzie wypełniali papiery, logowali się na serwer i sprawdzali co i jak ;))))

    OdpowiedzUsuń
  2. Ale to chyba dobrze, że możesz dorobić, prawda? Myślałem, że na kontrakt się idzie głównie dla większych zarobków?

    OdpowiedzUsuń
    Odpowiedzi
    1. Marnotrastwo i brak efektywnosci razi. Nadgodziny sa plusem finansowym, ale jak moge zrobic cos w 2h i miec zglowy albo tracic dwa wieczory, to wole zrobic wszystko od razu.

      Na brak samych nadgodzin nie moge narzekac, nie mniej zawsze staram sie zrobic wszystko jak najbardziej efektywnie. Jesli moge napisac skrypt, zeby cos przyspieszyc, to tak zrobie. Jesli jest inna metoda automatyzacji, to wyprobuje. Nie jestem milosnikiem klikania i recznego klepania.

      Usuń
  3. Change management ogolnie jest dobry - ale w UK to totalna porazka. Po pierwsze wiekszosc change managerow jest nie techniczna wiec ich rola ogranicza sie do forwardowania emaili, zatwierdzaja cos o czym nie maja pojecia. Pozatym w wielu firmach nie maja w ogole pojecia co powinno wchodzic do change a co powinno byc omijane ze zwyklym approvalem. Jak u siebie w firmie ostatnio widzialem change requesty typu "wymiana zepsutej klawiatury" czy "restart serwera" to myslalem ze zejde, a na koniec jak change managerka zapyala mnie czy "dodanie wirtualnego dysku do VM" wiaze sie z jakimis dodatkowymi kosztami to zwatpilem...

    Pozdrawiam,
    a co do rynku i ofert faktycznie jakas hossa...

    OdpowiedzUsuń
  4. A czy np. w pracy jak masz cos do zrobienia o czym nie masz zielonego pojecia, technologia ktorej na oczy nie widzialas (zakladmy hipotetycznie) to masz czas zeby sie tego nauczyc w kilka dni czy od razu na bruk? Ciezka jest taka praca kontraktora?

    OdpowiedzUsuń
    Odpowiedzi
    1. Takie sytuacje sie nie zdarzaja, chyba ze ktos klamal, ze zna sie na czyms, a nie ma pojecia. Wtedy szybciutko korzystasz z internetu i uczysz sie tego czego nie wiesz.

      Jak nie klamales, to szef/project manager wie, ze nie wiesz i daje Ci czas, zeby przyswoic wiedze.

      Jeden z moich projektow, byl taki, ze nikt tak naprawde nie robil tego wczesniej i ja bylam pionierem. Nasz pseudo architekt mial swoje teorie, ktore byly rozbiezne z praktyka i testowalismy wszystko od zera i uczylismy sie w czasie projektu. Nawet przed tym changem, ktory zainspirowal powyzszy wpis, dowiedzielismy sie nowej rzeczy i robilismy to pierwszy raz na zywym srodowisku.

      Usuń
    2. "Wtedy szybciutko korzystasz z internetu i uczysz sie tego czego nie wiesz."

      I to jest Szanowni Panstwo ku przestrodze wszystkim, ktorzy chca byc inzynierami a nie isc w droge IT.
      Jakby mnie zobaczyli na fabryce / elektrowni / platformie wiertniczej / rafinerii, ze cos takiego robie, to od razu wypad z baru i zwolnienie z pracy / kasowaniu kontraktu w najlzejszym wypadku zla opinia w srodowisku inzynierskim. Bo kolejny przestoj produkcji / procesu / batch lub wybicie (trip) lub PSD/ESD (Process/Emergency Shut Down) jest to ewakuacja calego personelu i straty warte setki tysiecy GBP / kazda godzine.

      Widac, bylem niezlym frajerem, ze wybralem studia inzynierskie, a nie stricte IT. Reszcie radze sie dobrze zastanowic. Inzynieria to nie IT, i nie znajdziesz wszystkiego w Wujku Google (a raczej malo co znajdziesz na temat konkretnego obiektu)

      Usuń
    3. Podaj przykład takiej technologi co nie ma w Google. A jest na potrzeby / elektrowni / platformie wiertniczej / rafinerii i nie jest tajną wiedzą na poziomie jakiejś technologi dopiero opracowywanej w jakiejś komórce badawczej.

      W IT nowe technologie pojawiają się tak szybko, że jest główną zaletą jak ktoś szybko jest w stanie na bazie wcześniejszych doświadczeń opanować nowe umiejętności, i nie ma znaczenia czy czy to będzie Google.

      Nie mam na myśli ludzi którzy tworzą nowe technologie w IT, które mają faktyczny wpływ na kierunki rozwoju IT, to jest promil wszystkich pracujących w IT.

      Usuń
  5. nie chce bys szorstki ale to typowe polskie myslenie... byl plan zrobic to w 4godziny a ja zrobilam w godzine. Nie ma roznicy jaka branza, po prostu lubimy sie zapracowywac. W fabrykach jak poliaki zaczeli pracowac to normy tez podskakiwaly diametralnie bo poliak robil wiecej szybciej i za mniej. W sklepach, restauracjach reddukcja stafu bo poliak robi za trzech za miske ryzu.
    Przy 6cio miesiecznym projekcie w firmie medycznej wzieto do teamu poliaka i jak sie dowiedzial ze tyle to ma trwac to sie za glowe zlapal, powiedzial ze zrobi im to w miesiac albo dwa wiec sie go pozbyto i bardzo dobrze! Takich przykladow jest w nieskonczonoscm, sami jestesmy sobie winni.

    OdpowiedzUsuń
    Odpowiedzi
    1. Chyba nie zakapałeś sensu tego posta. Change plan byl nienaturalnie rozciągnięty w czasie do 4h, ze względu na opisanie kazdej czynności, 4 z 5 osob wykonywujących change nie bylo Polakami, a change jakos dziwnie zrobił,się w godzinę.

      Usuń
  6. Dlaczego tak jest to wiadomo - ktoś kogoś przy wódeczce przekonał, że tylko dzięki takiemu podejściu będzie ład i porządek, "traceability" etc. I jak raz na 30 change'y to "coś" się przyda jako czysty dupochron to będzie chodził dumny jak paw z wdrożenia jakże efektywnego procesu. A to że, jak piszesz, klienci, pracownicy, menadżerowie są sfrustrowani - tego nikt nie mierzy. Nieomylności nie ma potrzeby mierzyć ;-)

    OdpowiedzUsuń
  7. Ten przypadek nie jest ekstremalny. Proszę, wyobraź sobie IT managera odpowiedzialnego dodatkowo za CM, którego ambicją było odrzucać większość rq bo się na tym nie znał. Po prostu wykształcenie humanistyczne i przekonanie graniczące z pewnością, że jak się zna Excela, PowerPointa i Worda, dodatkowo obsługa klienta poczty, to się zna na tym czym się zarządza. A jeśli coś było zbyt skomplikowane to jak nie znalazł się ktoś w EU, kto zweryfikowałby CM, to rq był odrzucany. Później już działał automat, WAIT(5WD); REJECT(rq). Dzięki temu wypisałem się z tego IT. Miałem trochę czasu, wykonałem certyfikowany upgrade wiedzy na wysoki poziom, nawet jak na UK.

    OdpowiedzUsuń