• – Może po prostu na początku mówmy im szczerze jak to wygląda, żeby nie mieli złudzeń i się nie rozczarowywali.
  • – Ale no, czekajcie, przecież to nie jest taka zła praca!
  • – Tylko, wiesz, tu są proste zadania, rzeczy mało rozwijające. I na pewno nie ma tej ekscytacji jak przy tworzeniu czegoś nowego od początku.
  • – Może nie jest to to samo, ale też nie przesadzajmy. Ludzie mogą się tu wiele nauczyć.

Czy faktycznie praca w „mejntenensie” (maintenance, nad utrzymaniem aplikacji) jest najgorszym, najnudniejszym i najmniej ekscytującym scenariuszem ze wszystkich? A może praca w „utrzymaniówce” ma jednak jakieś zalety?

Słowo wyjaśnienia dla zielonych i nowych w branży – o co chodzi z tym maintenance’em, defektami, CRami, itp.

 

Czego uczy praca w maintenanc’ie?

Jak robią to inni?

Zastanawiasz się jak wyglądają dokumenty/modele/kod, które tworzą inni? Jakie stosują metody i jak Twoje umiejętności wypadają na tym tle? Jeśli wskoczysz w sam środek tego, co wytworzyli i zaczniesz tam wprowadzać zmiany, przekonasz się na własne oczy i to bardzo szybko. Analizując bardziej poważne zmiany, musisz dokładnie przejrzeć jedną lub kilka specyfikacji, modeli danych, makiet, żeby zlokalizować miejsca, które trzeba będzie zmienić i oszacować nakład pracy. Czasem stwierdzasz, że najchętniej zaorałbyś wszystko i napisałbyś to lepiej od zera. Punkt dla Ciebie. Czasem dojdziesz do wniosku, że jakiś sposób zapisu jest fajny, ma sens albo jest tak intuicyjny, że nie dało się tego zrobić lepiej. Również punkt dla Ciebie, bo wszystkie te lekcje wyniesiesz w doświadczeniach do kolejnych projektów.

Specyfikacje, modele i kod to jedno. Poza tymi namacalnymi formami wytwarzanej pracy, zbierasz także inne lekcje. O organizacji. Naturalne, że każdy, kto ma do Ciebie interes powinien się do Ciebie zgłosić. W większych aplikacjach, przy większej liczbie osób zakopałbyś się jednak w szumie komunikacji, miotając się od zadania do jeszcze pilniejszego zadania, pod nawałem próśb, poleceń i żądań. Wchodząc do zespołu utrzymania aplikacji uczysz się też jego sposobu pracy – struktur, procesów, organizacji. Kto komu przekazuje zlecenia, kiedy, w jakiej formie, kto zatwierdza, kto sprawdza, komu, kiedy i jakie informacje przekazywać. Czasem stwierdzasz, że to bzdura i biurokracja, a czasem, że faktycznie, bez tych zasad praca byłaby nie do zniesienia.

Poza zasadami organizacji pracy czerpiesz też umiejętności wykorzystywania narzędzi. Enterprise Architect/Visual Paradigm ze współdzielonym modelem aplikacji, SVN do wersjonowania dokumentacji, SQL Developer do przeglądania baz danych, Axure do makiet, JIRA do zadań. Wszystkie one, nie dość, że stają się dla Ciebie dostępne, to jeszcze w zespole uczą Cię jak chodzić przetartymi ścieżkami – korzystać z gotowych już modeli, konwencji, workflowów. Dowiadujesz się nie tylko tego, że narzędzie jest i generalnie coś może robić, ale jak dokładnie z niego korzystać na konkretnych przykładach.

Jesteś dobry w tym, co robisz? Sprawdźmy

Początki projektów są piękne. Obiecujemy sobie wiele rzeczy, klient cieszy się swoją wizją a zespół wierzy, że jest w stanie ją zrealizować w zakładanym budżecie i czasie, bez większych problemów. Zespół ufa, że klient wie, czego chce, a jeśli coś mówi, to zdania nie zmieni, a jeśli nawet zmieni, to naturalnie zrozumie konsekwencje i będzie na końcu zadowolony. Klient wierzy, że ma do czynienia z profesjonalistami, którzy zrobią dla niego wszystko, czego i na kiedy tylko będzie potrzebował, szybko, tanio i w dobrej jakości, a ewentualne błędy i problemy rozwiąże ASAP i bez fuckupów.

A życie swoje.

Jeśli pracujemy w modelu „zrobić, wypchnąć, zapomnieć” (czyli sama realizacja/wdrożenie bez utrzymania) nigdy nie odczujemy, co tak naprawdę sprzedaliśmy klientowi i jak mu to pomogło (i czy w ogóle). No, chyba, że zadowala nas odpowiedź „dostał to, co zamówił”. Mam jednak nadzieję, że analitycy pracują po coś więcej, niż tylko po to, żeby aplikację „wypchnąć” i uciec z miejsca zbrodni ;)

Tak, jasne, kiedy klient widzi już część działającej aplikacji, przychodzi do akceptacji i odbiorów, to także zdarzają się kwasy i bolesne porównywanie obiecanek i wyobrażeń z rzeczywistością. Boje wdrożenia to jednak pestka w porównaniu z tym, czego doświadcza się w pracy w utrzymaniu. Nazwałabym to pełną odpowiedzialnością.

Jeśli wyczułeś, że coś gdzieś się nie spina, coś nie gra, ale nie chciało Ci się już analizować, opóźniać i zawracać gitary, to poczekaj – to wróci do Ciebie z produkcji. Jeśli czegoś nie dopilnowałeś, zamiotłeś pod dywan, zrobiłeś na odwal – pamiętaj, znają Twojego maila, telefon i wiedzą, gdzie siedzisz ;)

Po drugie, Ty i Twój fantastyczny pomysł na rozwiązanie to nie wszystko. Kiedy majsterkujesz na żywym organizmie, spoczywa na Tobie odpowiedzialność, żeby nie zepsuć przy okazji tego, co teraz działa. Czyli musisz to działanie bardzo dobrze ROZUMIEĆ. Praca nad utrzymaniem to prawdziwy test tego, czy wiesz, co robisz – na poziomie spójności wymagań, działania aplikacji i funkcjonowania biznesu. Coś, co z wąskiej perspektywy wydaje się dobrym wyjściem może sparaliżować inne systemy, utrudnić życie pośrednio zależnych użytkowników czy nawet wstrzymać realizację zamówień.

Pokaż, jak jesteś dobry ;)

Ważne i niepilne kontra presja czasu

Praca w utrzymaniu jest jak pływanie w rzece (nie mylić z praniem). Ogarnia Cię spokój – masz czas na poprawki i usprawnienia, to znowu porywa Cię nurt nagłych incydentów i zmian na wczoraj. Są chwile, kiedy możesz w spokoju poprawiać specyfikacje i modele na lepsze. Przerywają je jednak nagłe pilniejsze sprawy.

W utrzymaniu uczysz się sprawnie podejmować decyzje.

To kolejny sprawdzian dla Twoich umiejętności – jak szybko jesteś w stanie odnaleźć źródło problemu w dokumentacji, modelu, w kodzie? To test myślenia, kojarzenia faktów i wyciągania wniosków z niepozornych przesłanek (trochę jak praca detektywa, jeśli wierzyć w to, co napisał sir A.C.Doyle). Jeśli będziesz długo zwlekać, narazisz użytkowników na czekanie – nie będą mogli pracować lub zostaną zmuszeni do karkołomnych czy pracochłonnych obejść.

Z perspektywy

A to odpowiedź kolegi – lidera developerów z zespołu utrzymaniowego (dziękuję :) na pytanie jak wygląda praca w utrzymaniu :)

„Maintenance wymaga perfekcjonizmu. Nie wybacza błędów i niechlujstwa, nic się tu nie ukryje. Działasz na aplikacji, z której korzystają użytkownicy – często twoja zmiana pojawia się na produkcji tego samego dnia. Ma to swoje zalety: nie jesteś anonimowy dla użytkowników – czasami można usłyszeć „Dziękuję”, chociaż słowa, które słyszysz najczęściej to „kiedy?” i „dlaczego?”. Dowiadujesz się, co jest najważniejsze dla klientów (w końcu to oni płacą) i nie jest to na pewno clean code.”

 

A to opinia kolegi, który przez kilka lat odpowiadał za wyniki całego zespołu utrzymania (dziękuję :) :

„Klient wychodzi z założenia, że wszystko powinno było działać od początku i to jest zasrany obowiązek maintenance’u, żeby znów zadziałało. Klienta nie interesuje, że zawalił ktoś, kogo nie ma już w projekcie, że to problem na styku dwóch modułów, że ktoś kiedyś nie przewidział czegoś na drugim końcu systemu, jemu się wywala w tym, na czym pracuje i w tym momencie, z jego perspektywy, winny/a jesteś Ty.

Wejście do maintenance’u to przyspieszony kurs wdrożeniowy w wiedzę biznesową i techniczną danej części systemu. Tu nie ma czasu na planowanie, na długie uczenie się, na R&D. Tu trzeba wejść i działać.”

 

Banał i nudy? Czy nauka i wyzwanie?

Czego Ciebie uczy praca w maintenance’ie?

 

Hania Tomaszewska
8 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Pracuję na etacie, prowadzę bloga, tworzę kursy, prowadzę szkolenia i konsultacje. Pomagam analitykom doskonalić warsztat pracy i rozwijać się, managerom układać procesy i rozwijać pracowników oraz przedsiębiorcom, aby rozwiązania IT wspierały ich działalność.

5 KOMENTARZE

  1. Hej Haniu!
    Świetny pomysł na artykuł, szkoda, że nie poszłaś dalej z tematem bo to źródło niezłych historii. Developrzy trafnie uchwycili o co w majtnensie chodzi, ale sytuacji jest bardzo wiele.

    Z punktu widzenia analityka, który może pracować z zespołem jednocześnie utrzymującym produkcje i budującym nowe featury to trzeba nastawić się, szczególnie w teamach agile’owych na ogromną dynamikę, częste podejmowanie decyzji, zmieniający się scope i na to, że utrzymanie w ryzach wymagań i ich priorytetów względem bugów i innego robactwa z produkcji potrafi doprawić siwych włosów :) Szczególnie, gdy klient wymagający jest i nie do końca rozumie, ze nie da się zrobić obu rzeczy, czyli naprawić wszystkich bieżących zgłoszeń i zrobić wszystkich storiesów (planowanych na cały sprint), w jednym sprincie :).

    Także zdecydowanie to wyzwanie – ale trzeba to lubić i radzić sobie z presją zarówno od ludzi jak i przez czas.

    • Tak, to kolejne wyzwania 🙂 dzięki za uzupełnienie. U mnie się też powtarzają wyzwania „zróbmy to szybko” vs. „zróbmy to dobrze” i tłumaczenie czemu szybko będzie niedobrze 😜 a potem łatanie łat i inne uroki.

  2. Biorąc udział jako analityk w projekcie od zera, dużo łatwiej jest analizować pewne zależności pomiędzy funkcjonalnościami, w utrzymaniówce nie jest to już takie oczywiste (zwłaszcza czując oddech pospieszaczy na swoich plecach). Także zdecydowanie jest to wyzwanie :)

  3. Na pewno zgłębienie działania aplikacji w trakcie wsparcia po wdrożeniowego przydaje się w perspektywie późniejszych zmian, w końcu znamy produkt jak nikt inny. Ale co jeśli tych CR jest bardzo mało, a utrzymanie sprowadza się do ciągłej poprawy tych samych błędów, wtedy może pojawić się monotonia :)

ZOSTAW ODPOWIEDŹ