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.

„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.

>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…

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ść.

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 🙂

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.

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.

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.

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.