Ostatnio śledzę ogłoszenia o pracę na głównych portalach w internecie. Robię to ponieważ, szukam nowych możliwości i sposobów na rozwój swojej kariery zawodowej. Zwróciło moją uwagę, że jest bardzo dużo ogłoszeń dla stanowisk wykorzystywanych w procesie wytwórczym oprogramowania. Natomiast pojawia się mało dla osób, które miałyby to oprogramowanie i systemy, na których ono działa, utrzymywać. Skąd taka dysproporcja? Czy taka sytuacja jest naturalna?
Kierownika projektów IT zatrudnię
Wśród ogłoszeń z branży IT, występuje bardzo dużo ogłoszeń o pracę dla kierowników projektów, delivery managerów, programistów Java oraz innych języków programowania, testerów, architektów, analityków. To bardzo dobrze, bo oznacza że firmy tworzą nowe rozwiązania IT, aplikacje i systemy. Jest to siła napędowa rozwoju branży IT oraz całej gospodarki, która dzięki informatyzacji staje się nowoczesna, innowacyjna i konkurencyjna.
Nowe oprogramowanie i aplikacje, ułatwiają nam życie, pomagają w codziennych sprawach, zmieniają nasze postrzeganie świata i dają szansę na lepszą przyszłość.
Co dalej?
Wytworzenie dobrego oprogramowania i uruchomienie go na infrastrukturze, aby działało niezawodnie to bardzo żmudny proces. Wymaga on zaangażowania wszystkich osób z działów IT w tym zespołów developerskich, analitycznych, testowych i zarządzających infrastrukturą sprzętowo-software’ową. Kiedyś jednak oprogramowanie zostanie wytworzone i wdrożone na środowisko produkcyjne i co dalej?
Gdzie ci specjaliści, specjalistki?
Skoro wytworzenie jakiegoś oprogramowania i uruchomienie go na produkcji wymaga zaangażowania tylu różnych specjalistów, to czy jego utrzymanie jest prostsze i nie nastręcza tylu problemów?
We wspomnianych ogłoszeniach o pracę, jak na lekarstwo można znaleźć oferty dla takich ról jak: manager incydentów, manager problemów, manager zmian, manager poziomu usług. Częściej występują role związane z Service Desk, administrowaniem infrastrukturą, aplikacjami czy bazami danych.
Czy jednak bez odpowiednich specjalistów od utrzymania można świadczyć usługi IT na wysokim poziomie? Według mnie nie!
Specjaliści a poziom usług IT
Poniższe pytania, oczywiście retoryczne, powinny dać dużo do myślenia:
- Czy bez managera poziomu usług, można poprawnie zdefiniować dobry katalog usług? Czy jego brak pozwoli nam na właściwe zdefiniowanie wymaganego poziomu usług SLA?
- Czy nie posiadanie managera incydentów, umożliwi rozwiązywanie zgłoszeń w wymaganych czasach reakcji i rozwiązania, wynikających z SLA?
- Czy nieobecność managera problemów, będzie pomocna w znajdowaniu przyczyn źródłowych błędów i awarii oraz pozwoli na zmniejszenie liczby incydentów od użytkowników?
- Czy nie zatrudnienie managera zmian, pozwoli efektywnie zarządzać i wprowadzać zmiany w systemach informatyczny?
U nas bez zmian
Dlaczego tak mnie to dziwi i nawet irytuje? Czy to jest nowe zjawisko?
Po pierwsze dlatego, że od początku swojej przygody z zarządzaniem usługami IT, widzę tą dysproporcję pomiędzy procesem wytwarzania oprogramowania i późniejszym jego utrzymaniem. Zainteresowanie projektów, odpowiedzialnych za wytworzenie, dostarczenie i wdrożenie rozwiązania informatycznego, kończy się po jego uruchomieniu na produkcji. Większość organizacji wychodzi z założenia, że najważniejsze jest uruchomić aplikację/system na produkcji, a później jakoś to będzie.
Po drugie większość mojego życia zawodowego spędziłem po stronie zespołów utrzymania i często czułem, że nie są one wystarczająco doceniane i wynagradzane, za wykonywanie swojej ciężkiej pracy. Często zespoły utrzymania muszą naprawić to, co nie zostało wystarczająco dobrze przygotowane i sprawdzone w zespole wytwórczym, a w zamian nie otrzymują nawet dobrego słowa.
Niech nie dziwi nas, że użytkownicy narzekają na wdrożone nowe rozwiązania IT, które mają dużo błędów i niedoróbek, których zespoły utrzymania, nie są w stanie na bieżąco i sprawnie rozwiązywać.
Bez inwestycji w dobrze działającą organizację utrzymania, nie można świadczyć usług IT na wysokim poziomie, bo za wymagany poziom usług odpowiadają nie tylko hardware i software ale przede wszystkim ludzie, tworzący sprawnie funkcjonującą organizację utrzymania!
Pytanie: Co byś poprawił w Twojej organizacji utrzymania?
Permalink
Rynek weryfikuje potrzebę danych specjalistów. Skoro nie ma zapotrzebowania na specjalistów takich jak: manager incydentów, manager problemów, manager zmian, manager poziomu usług – to widocznie są niepotrzebni 95% projektach.
Bo jaka jest różnica pomiędzy: manager incydentów a manager problemów? Czy w projekcie powinny być dwa takie stanowiska czy jedno, które łączy oba problemy? I w ogóle czym taki człowiek miałby się zajmować? Na czym ma niby polegać zarządzanie incydentami i problemami? Są do tego odpowiednie narzędzia – bug trackery. Dla mnie taki manager incydentów/problemów w dotychczasowych projektach to był taki człowiek, który się interesował tymi zagadnieniami, jak zbliżał się termin realizacji to pytał zespół developerski czy wszystko już zrobione albo na kiedy będzie? Czasami zrobił jakiś wykres żeby pokazać ile mamy incydentów i problemów i jak to się zmienia w czasie. Ale jak pisałem to samo robią narzędzia. Można mieć piękne wykresy, przypomnienia o zbliżających się terminach, śledzić postęp i realizację zadań. Manager incydentów/problemów nie miał wpływu na czas i realizację zadań. Moim zdaniem jeżeli zespół analityków/developerów/testerów wie co ma robić i czuje się odpowiedzialny za dany projekt to 'poganiacz’ który będzie chodził i pytał kiedy, kiedy, kiedy? oraz od czasu do czasu przygotuje jakieś zestawienie dla project managera lub zarządu jest zbędny – traktuję go jako dodatkowy koszt dla projektu.
Podobnie myślę o managerze poziomu usług. Jeżeli jest zapotrzebowanie na określenie katalogu usług, SLA itp to przeważnie zajmuje się tym analityk i nie poświęca więcej niż 80% czasu w projekcie tylko mniej. Więc w mojej opinii definiowanie takiego stanowiska mija się z celem.
Permalink
Alek dziękuję za bardzo obszerny komentarz.
Pozwolę się nie zgodzić z Twoją opinią. Jeżeli chodzi o projekt to może i faktycznie takie role nie są kluczowe. Każdy jednak projekt kiedyś się kończy a rozwiązanie informatyczne pozostaje i działa na produkcji. Jeżeli chcemy aby działało niezawodnie, to musimy mieć specjalistów od utrzymania, bo specjaliści od wytwarzania już realizują inny projekt i nie interesuje ich co się dzieje z poprzednim systemem informatycznym, który stworzyli.
Czyli obaj mamy rację 🙂
Permalink
Mariusz napisz proszę, z którą częścią mojej wypowiedzi się nie zgadzasz i dlaczego? Czy Twoim zdaniem specjaliści których wymieniłem: manager incydentów, manager problemów, manager zmian, manager poziomu usług są potrzebni w fazie utrzymania? Szczerze to nie spotkałem się z dużym projektem, który by wszedł w tak zwaną 'fazę utrzymania’ i nie byli już potrzebni do niego np developerzy? W dużych projektach faza utrzymania to tak naprawdę – zakończenie głównej fazy wytwarzania.
Permalink
Alek, zarówno zespoły developerskie jak i utrzymaniowe są potrzebne w fazie utrzymania systemu informatycznego. Ja nie uważam, że developerzy są niepotrzebni, tylko żeby utrzymywać usługi IT na wymaganym poziomie usług SLA np. czas rozwiązania incydentu wynosi 4 godziny, potrzebne są role, które będą za to odpowiadać. Jak nie ma żadnego SLA, a tak jest bardzo rzadko lub nigdy, to managerowi utrzymania nie są potrzebni.
Permalink
Mariusz w Twoim artykule nie ma mowy o managerze utrzymania są za to inne role do których się odniosłem. Czy to ma być nowy wątek w dyskusji? Proponuję abyśmy na początek zamknęli poprzednie. Odnieś się proszę do moich pytań z drugiego komentarza.
Permalink
Alek, managerowie utrzymania to manager incydentów, problemów, zmian i poziomu usług. Taki skrót myślowy. Tak, uważam, że są bardzo ważnymi rolami w utrzymaniu i są potrzebni. Nie muszą występować wszystkie podane role. To był przykład. Szanuję bardzo Twoją opinię ale nie muszę mieć takiej samej.
Permalink
>Rynek weryfikuje potrzebę danych specjalistów
Poważnie? Mi się wydaje że obecny rynek działa w oparciu o cenę i dlatego na rynku jest 90% softu który nie bójmy się tego słowa jest po prostu zwykłym badziewiem. Naprawdę rzadko zdarza mi się widzieć czy to kod czy aplikację która jest porządnie zrobiona. Obecnie mamy do czynienia z aplikacjami na poziomie chińskich podróbek produktów – większość to tandeta. Czy skoro Chińska tandeta się sprzedaje to znaczy że to jest właściwy kierunek? Nie wydaje mi się… Podczas budowy dróg czy mostów gdybyśmy mieli 100% warunek cena – to droga i most zawaliły by się dwa dni po upływającej gwarancji – to się nazywa optymalizacja kosztów. Marka? Nie ma czegoś takiego jak dobra marka wśród firm piszących oprogramowanie…jeszcze nie ma…ale to się wkrótce zmieni bo nikt na dłuższą metę nie jest w stanie otaczać się takim badziewiem. Wiele lat temu kiedy rodziła się motoryzacja motocykle i samochody powstawały w co drugiej szopie – producentów była cała masa – tak jak obecnie na rynku oprogramowania – ALE w końcu liczba producentów zmniejszała się i pozostały najsilniejsze – te które producenci mogli zaoferować JAKOŚĆ za rozsądną dla klienta cenę…
>…widocznie są niepotrzebni 95% projektach.
Dokładnie bo te 95% projektów to wypluwanie tandety i gwarancja do przysłowiowej furtki.
>Bo jaka jest różnica pomiędzy: manager incydentów a manager problemów?
>Czy w projekcie powinny być dwa takie stanowiska czy jedno, które łączy oba problemy?
>I w ogóle czym taki człowiek miałby się zajmować?
>Na czym ma niby polegać zarządzanie incydentami i problemami?
Przede wszystkim ludzie w 95% projektach nie rozróżniają w.w… wiec jak może być mowa o jakości aplikacji.
Tu masz wyjaśnione czym różni się jeden od drugiego:
https://en.wikipedia.org/wiki/Incident_management_(ITSM)
Powiem w skrócie różnica jest jak po między załataniem dziury (incydent) w jezdni a przeprojektowaniem geometrii zjazdu z autostrady na którym zdarza się duża ilość wypadków(problem).
>Są do tego odpowiednie narzędzia – bug trackery
Do czego? Poproszę o nazwę narzędzia która przekaże zespołowi deweloperskiemu że przy obciążeniu ilością klientów X o godzinie Z następuje
wysycenie kolejki zapytań na bazie , przez co wydłuża się czas odpowiedzi o wartość A? W przypadku znalezienia takiego w.w „problemu” ktoś z zespołu może to przekazać managerowi problemów i ten ma za zadanie uruchomić PROCES usunięcia tej sytuacji w kolejnych iteracjach kodu. Kiedy nie ma managera który się tym zajmuje gdzie ma to zgłosić admin który się tym zajmuje? Do PM? Ma to gdzieś…klient jeszcze nie narzeka…oficjalnie.
>Można mieć piękne wykresy, przypomnienia o zbliżających się terminach, śledzić postęp i realizację zadań.
>Manager incydentów/problemów nie miał wpływu na czas i realizację zadań.
Jeżeli w zespole nie ma osoby odpowiedzialnej za takie sytuacje to NIKT ich nie usunie. Zespół dev będzie sie zasłaniał brakiem czasu a po za tym to co zrobili jest zgodne z analizą a analitycy że to wina arch a ci że w szczegóły to oni nie wchodzą… itd. Musi być ktoś kto to ogarnie i zorganizuje drogę do osiągnięcia celu jakim jest pozbycie się problemu.
>Moim zdaniem jeżeli zespół analityków/developerów/testerów wie co ma robić i czuje się odpowiedzialny za dany projekt
>to ‚poganiacz’ który będzie chodził i pytał kiedy, kiedy, kiedy?
Tyle że w realnym życiu to nie działa…
Permalink
„Mi się wydaje że obecny rynek działa w oparciu o cenę i dlatego na rynku jest 90% softu który nie bójmy się tego słowa jest po prostu zwykłym badziewiem.”
Obecnie rynek oprogramowania nie działa wyłącznie o cenę. Na rynku jest wiele przetargów gdzie jednym z kryteriów oceny: są doświadczenie firmy w tworzeniu podobnego programowania, zespół z doświadczeniem w odpowiednich projektach, ludzie w zespole o określonych kwalifikacjach. Nie zgadzam się, że 90% softu to badziewie. Porównywanie produkcji oprogramowania do budowy drogi, mostu czy produkcji samochodu to zwykłe nadużycie. Produkcja oprogramowania to 'ciągła’ zmiana wymagań, często popularne 'never ending story’. To nie jest tak jak w budownictwie drogowym/mostowym gdzie często w przetargu widzisz konkretny projekt wg którego masz coś wybudować, nawet w przetargach projektuj i buduj większość rzeczy masz określone. Tu po zbudowaniu danego elementu infrastruktury klient nie stwierdza, że mu chodziło o coś innego i musisz zbudować coś od nowa, zupełnie inaczej niż na początku i inaczej niż było w wymaganiach. Tu w czasie projektu nie zmienia się prawo do którego nagle musisz przeorać połowę projektu żeby go dostosować do nadchodzących wymagań prawnych a w projektach IT często się tak zdarza. Produkcja oprogramowania to ciągła zmiana: wymagań, kodu, technologii, narzędzi.
W takim cyklu trudno ustrzec się błędów – to nie wygląda jak powielanie raz dobrze zaprojektowanego i skonstruowanego samochodu.
„Marka? Nie ma czegoś takiego jak dobra marka wśród firm piszących oprogramowanie…jeszcze nie ma…ale to się wkrótce zmieni bo nikt na dłuższą metę nie jest w stanie otaczać się takim badziewiem.”
Ja znam kilka dobrych marek, które piszą soft wykorzystywany przez miliony użytkowników: Apple, Facebook, Microsoft, Google, Amazon. Pytanie czy dobre oprogramowanie to oprogramowanie bezbłędne? Moim zdaniem nie – to by był produkt prawie idealny. Poza tym jako użytkownik nigdy nie wiesz co zawiodło. Mógł paść serwer, system robi pod siebie, padła połowa ramu, koparka do kryptowalut obciąża 99% procesora – użytkownik końcowy i tak obwini oprogramowanie, na którym pracuje bo nie widzi niczego pod spodem.
„Powiem w skrócie różnica jest jak po między załataniem dziury (incydent) w jezdni a przeprojektowaniem geometrii zjazdu z autostrady na którym zdarza się duża ilość wypadków(problem).”
To w takim razie w czym ma mi pomóc ten manager incydentów/problemów w projekcie? ZAŁATA DZIURĘ? PRZEPROJEKTUJE ZJAZD? JakA będzie jego rola? Ja widzę tu kolejną 'funkcyjną’ rolę, która nie wniesie żadnej wartości dodanej w projekcie. Jeżeli masz narzędzie np Jira i do szefa programistów trafia incydent albo problem to taki człowiek znając projekt (czasy realizacji itp) dokładnie wie co ma zrobić. Jeżeli, są problemy z realizacją idzie do kierownika projektu i ustalają jakie działania dodatkowe trzeba podjąć, co trzeba zmienić, kogo przesunąć, co się opóźni ew inne konsekwencje. Często trzeba powiadomić klienta i poczynić z nim dodatkowe ustalenia.
Gdzie tu jest rola tego super człowieka – managera incydentów/problemów? Będzie się przyglądał? Jaki ma wpływ? Może powiedzieć że to jest super ważne? Albo powie że już w tym miesiącu mieliśmy 5 incydentów i ten jest 6 więc mogą być kary? Za to ma obciążać projekt dodatkowymi kosztami? Tyle postów i nikt mi nie wyjaśnił jak jest wartość i dodana tego 'managera’ – tylko że jest zajebiście potrzebny i bez niego to projekt nie ma. Ale dlaczego?
?>Są do tego odpowiednie narzędzia – bug trackery
Do czego??
Bug truckery to takie narzędzia do obsługi błędów/incydentów/problemów w projektach.
https://pl.wikipedia.org/wiki/Bugtracker
„Poproszę o nazwę narzędzia która przekaże zespołowi deweloperskiemu że przy obciążeniu ilością klientów X o godzinie Z następuje
wysycenie kolejki zapytań na bazie , przez co wydłuża się czas odpowiedzi o wartość A?”
Takie narzędzie to np. Jira. Jeżeli administratorzy systemu stwierdzą wymienioną przez Ciebie sytuację to tworzysz w Jira zgłoszenie,
opisujesz sytuację, podajesz przybliżone czas jej wystąpienia, dołączasz logi jeżeli są dostępne i przekazujesz zespołowi developerskiemu.
Jeżeli są potrzebne dodatkowe informacje zespół developerski może zawsze poprosić o uszczegółowienie. oczywiście widzę tu miejsca dla managera incydentów, który przejmie takie zgłoszenie i przekaże dalej tylko po co?. Chyba tylko dlatego, że jest potrzeba skomplikowania procesu. Każdy z zespołów: administratorzy, developerzy, testerzy, analitycy ma swoich managerów, do których w razie potrzeby można się udać.
„Jeżeli w zespole nie ma osoby odpowiedzialnej za takie sytuacje to NIKT ich nie usunie.”
Może masz złe doświadczenie, ja pracowałem w takich zespołach gdzie problemy były rozwiązywane, incydenty naprawiane i mimo że było w projekcie stanowisko managera incydentów/problemów to nie brał on czynnego udziału w ich rozwiązywaniu. Jego rola zaczynała się i kończyła na przekazywaniu informacji że jest taki błąd i trzeba go naprawić ale to może moje złe doświadczenia 🙂
„Zespół dev będzie sie zasłaniał brakiem czasu a po za tym to co zrobili jest zgodne z analizą a analitycy że to wina arch a ci że w szczegóły to oni nie wchodzą… itd. Musi być ktoś kto to ogarnie i zorganizuje drogę do osiągnięcia celu jakim jest pozbycie się problemu.”
Pracowałem w kilku projektach gdzie byli managerowie incydentów/problemów i nigdy nie spotkałem się z sytuacją żeby ten człowiek TOROWAŁ drogę do jego usunięcia. Mam wrażenie że próbujesz ukazać managera incydentów jako niezbędną osobę w projekcie IT bez której projekt nie ma szans powodzenia.
Oczywiście że developerzy chodzą i mówią że mają taki zapierdol że z pustymi taczkami latają bo nie ma czasu ich załadować, wiadomo że analiza dała ciała i tak na prawdę to do końca nikt nie wie czego klient chciał a architektura jak architektura – zawsze mogłoby być lepiej.
Ale to nie zmienia faktu że koniec końców incydent ma być rozwiązany, problem wyjaśniony i zaimplementowany. Wszyscy w projekcie znają swoje role, czasy realizacji i za to mają płacone żeby się do nich dostosować i żeby wszystko na koniec dnia grało a PM mógł spać spokojnie.
„>Moim zdaniem jeżeli zespół analityków/developerów/testerów wie co ma robić i czuje się odpowiedzialny za dany projekt
>to ‚poganiacz’ który będzie chodził i pytał kiedy, kiedy, kiedy?
Tyle że w realnym życiu to nie działa…”
Z mojego doświadczenia działa. Są różni ludzie i różne sposoby zarządzania. Rolą dobrych managerów w projekcie jest budowa takiego zespołu i stworzenie takiej atmosfery w zespole, żeby ludzie czuli się odpowiedzialni za swoją pracę i sami rozwiązywali powstające problemy, mieli chęć do działania i satysfakcję na koniec dnia. Może na swojej drodze poznałeś słabych managerów, którzy stosowali złe sposoby zarządzania.
Permalink
Alek, Rafał,
Zagadnienie, na którego temat ta fantastycznie dyskutujecie jest wielowątkowe i złożone. Dodatkowo na to nakłada się Wasze doświadczenie, które każdy ma inne. Dlatego tak trudno znaleźć wspólny mianownik.
Jeżeli mamy jeden, projekt, jednego dostawcę i jeden system to, może managerowie utrzymania (incydentów, problemów, zmian i poziomu usług) nie są wartością dodaną.
Jednak, gdy spojrzymy z innej perspektywy, że mamy kilka do kilkunastu jednoczesnych projektów, kilku do kilkunastu dostawców i kilkadziesiąt różnych systemów informatycznych. Te projekty są ze sobą powiązane i zależą od siebie. Te kilkadziesiąt systemów informatycznych, to nie samodzielne wyspy ale sieć powiązań i zależności pomiędzy nimi. Wtedy zobaczymy, że bez dobrze przygotowanej organizacji IT i managerów utrzymania, trudno będzie zapanować nad tym wszystkich i dotrzymać wszystkich SLA z dostawcami wewnętrznymi i zewnętrznymi.
Permalink
Mariusz , podziwiam Twoje starania w promowaniu SLA i tematów z nim związanych, ale mam odmienny punkt widzenia. Jak masz słaby zespół wytwarzania to żaden manager incydentów (..) nie pomoże, a jak masz dobry zespół to taki menager również jest zbędny a generuje dodatkowe koszty. Czy nam się to podoba czy nie to wszyscy wiemy, że koszty w projektach są najważniejsze – szczególnie na etapie utrzymania. Stąd lepiej mieć lepszy zespół który zrobi dobry sof i który w momencie incydentu będzie wiedział co robić, niż mieć wielu menagerów, którzy poza rubryczkami w exelu projektu/zmian w projekcie do przodu nie posuną.
Permalink
Asia,
Pełna zgoda. Każdy manager, nie ważne czego, bez zespołu bardzo dobrych lub przynajmniej dobrych specjalistów nic nie znaczy. Jednak i w drugą stronę jak mamy dużą grupę 20-50 specjalistów to muszą być osoby do zarządzania zarówno ludźmi jak i procesami, np. takimi jak zarządzanie incydentami i poziomem usług.
Dziękuję za bardzo ciekawe komentarze. Widzę, że będę musiał rozwinąć ten temat w kolejnej publikacji 🙂
Permalink
ODP: JPL…
Nie ma czegoś takiego jak „dobry soft” który działa i już. To jest możliwe jak projekt jest skrajnie prosty do wdrożenia. Kiedy ktoś ma czynienia z projektem w postaci strony internetowej to na pewno nie są tu potrzebni managerowie SLA …ale Mariuszowi chodziło o projekty a nie projekciki… Podczas mojego doświadczenia przy wdrażaniu wielu dużych projektów wykonanych przez rożne teamy deweloperów mogę powiedzieć że te są tylko mniej i bardziej pełne bugów. Błędy pojawiają się od projektu przed analizę, deweloperkę aż po wdrożenie – na każdym z tych etapów mamy do czynienia z błędami. Później zespół wdrożeniowy/utrzymaniowy poprawia część tych błędów lub zgłasza ja do deweloperów i architektów. Oczywiście większość wychwycą testerzy ale oni odpowiadają za to co widzi użytkownik (zwykle) a nie za techniczną część projektu. Zasadą jest że to co zaprojektował architekt ma się w ogólnym założeniu do tego co zostało wdrożone ale w szczegółach to często zupełnie inna rzeczywistość.