Rozwój zawodowy i psychologia, Wydarzenia,
16 września 2020
Dzień Porażki 2020
Sukcesy są fajne, ale to przez porażki wiedzie prawdziwe życie. I droga do sukcesów. Trzeba umieć uczyć się na błędach.
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?
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.
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 😉
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ść.
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?
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
