Koniec pandemii? A jeśli tak, to co dalej?

Dawno nie miałem tak ciekawej rozmowy jak wczoraj. Do pewnego stopnia była to rozmowa przełomowa, gdyż może wskazywać, że powoli kończy się trwająca od lat pandemia. Oczywiście pojawiają się pytania, jak duże mamy straty i czy uda się odbudować świat po pandemii? A jeśli się uda, jak długo to będzie trwało. Ale, od początku…

Wczorajsze popołudnie rozpoczęło się od odebrania telefonu od nieznajomej osoby. W pierwszych słowach rozmówca przedstawił się jako lider zespołu wytwarzającego oprogramowanie dla bardzo wymagającego Klienta. Zespół jest dość spory – łącznie, kilkadziesiąt osób podzielonych na mniejsze grupy. System także jest spory. Rozwijany w dużych przyrostach, przez lata. Z jednej strony, ciągle dodawane są do niego nowe obszary funkcjonalne. Z drugiej – do istniejących funkcjonalności wprowadzane są zmiany.

Sytuacja, wydawałoby się, dość jasna i powszechna. W czym więc problem? Otóż, zespół doszedł do wniosku, że powoli przestaje panować nad całą złożonością, a dalszy rozwój oraz utrzymanie zaczynają być na tyle uciążliwe, że skutkuje to zauważalnym spadkiem efektywności i skuteczności prac, a co za tym idzie, rosnącą frustracją członków zespołu. Na tyle dużą, że część z nich postanowiła opuścić zespół z tego właśnie powodu. Ponieważ problem nie jest nowy, więc, jak mi powiedziano, był wielokrotnie dyskutowany. Efektem tych dyskusji było spostrzeżenie, iż aktualny sposób prowadzenia prac, oparty o historyjki i epiki, pomimo ‚dokręcania’ ich zgodnie z rekomendowanymi technikami, bardzo utrudnia prace analityczne. Jednym z objawów tych trudności jest poświęcanie coraz większej ilości czasu na przeszukiwanie narzędzia wykorzystywanego do zarządzania specyfikacją, w celu znalezienia opisu aktualnej funkcjonalności systemu oraz wprowadzanie zmian do niej. Spostrzeżeń, oczywiście było więcej, bo i problem jest niemały.

Szukając metod poprawy sytuacji, członkowie zespołu, uczestniczyli w wielu szkoleniach, spotkaniach branżowych oraz, jak mi powiedziano, przeczytali cały Internet dwa razy. I stwierdzili, że w zasadzie, niewiele nowego się dowiedzieli. Wprawdzie doczytali o nowych technikach, możliwych zmianach w sposobie zapisu, nowych narzędziach. Wiele z takich zaleceń wprowadzili do swojej pracy, ale jakościowej zmiany nie zaobserwowali.

Szczerze mówiąc, usłyszawszy to, mocno się zdziwiłem. Internet jest bowiem pełen opisów technik , które pozwalają na usprawnienie prac nad tego typu przedsięwzięciem, czym podzieliłem się z rozmówcą. I w tym momencie rozpoczął się kolejny interesujący wątek.

Wszystkie dotychczasowe poszukiwania metod mogących usprawnić prace były skoncentrowane na podejściu agile’owym. Na pytanie dlaczego, padła odpowiedź, że tylko takie znają. Cały zespół jest bowiem z pokolenia, które weszło na rynek, na którym niepodzielnie panuje agile. Odruch, by szukać tylko wśród technik agile’owych był tak naturalny, że nikt przez dłuższy czas nie myślał, by sięgnąć gdzie indziej. Bo czym jest gdzie indziej? Historią, jak stwierdził z uśmiechem rozmówca.

Rany, jaki ja jestem stary, pomyślałem.

W końcu, ktoś z zespołu otworzył pozycję historyczną. W Internecie, oczywiście. Usłyszałem, że to było o UMLu. Pozycję znam, więc bynajmniej nie dotyczy tylko UMLa. Kilka osób z zespołu stwierdziło wówczas, że miało jakieś zajęcia z UMLa na studiach, ale nikt jakoś poważnie tego nie traktował. Raczej na zasadzie, nauczyć się, by zaliczyć. Pomimo tego, zespół postanowił temat podrążyć. Stworzono nawet malutki projekt pilotażowy, którego celem było wypróbowanie nowopoznawanych technik do realizacji prac projektowych. Dwie osoby równolegle z resztą zespołu, po nowemu i na boku, opisywało analizę. Wniosków z tego ćwiczenia było wiele. Te ważniejsze, to:

  • początkowo, dwuosobowy zespół gros czasu poświęcał na opisanie tego, jak jest aktualnie, by w ogóle móc myśleć o opisaniu nowej funkcjonalności,
  • zespół eksperymentatorów stwierdził po jakimś czasie, że to nie jest takie proste, a potwierdzeniem tych słów była informacja o czasie, jaki był poświęcany na poprawę tego, co zrobili,
  • doczytywanie w Internecie o stosowanych technikach skutkowało wnioskami w stylu a tutaj robią to trochę inaczej, choć niby to to samo,
  • wykorzystywane narzędzie do modelowania sprawiało na początku wiele problemów wynikających z jego złożoności.

Interesujące było to, że swoimi doświadczeniami zespół postanowił podzielić się w trakcie jednego z branżowych spotkań. I okazało się, że nie są sami z problemem. Co więcej, ich wystąpienie spotkało się z bardzo pozytywnym odbiorem a kilka osób stwierdziło, że spróbuje u siebie porozmawiać o możliwości wdrożenia tego typu metod pracy. Ale, jak to stwierdził rozmówca, na sali, pomimo ponad sześćdziesięciu osób, nikt (sic!) nie miał praktycznego doświadczenia z metodami pracy opartymi o modelowanie.

Pod koniec rozmowy przeszliśmy do tematu praktycznego wdrożenia takiego podejścia w zespole. Poruszyliśmy temat metodyki – pojęcia które wywołało od razu reakcję ale nie takiej sztywnej! Więc zapytałem, skąd obawa, że będzie sztywna? Odpowiedź, bo stare metodyki były sztywne. To sobie chwilę i o tym porozmawialiśmy. A na koniec padło pytanie, o szacunkowy czas wdrożenia takiego podejścia w całym zespole (kilkadziesiąt osób, przypomnę).

Tiaaaa, i dotknęliśmy trudnego tematu. Oczekiwania były takie, by zaspół zaczął pracować opierając się o modelowanie po miesiącu, maksymalnie dwóch. Ja stwierdziłem, że to niemożliwe, gdyż z tego co słyszę, wdrożenie ma dotyczyć zarówno opisywania procesów jak i całej analizy systemowe. Zespół bowiem doszedł do wniosku, że albo zrobią wszystko, albo nie zaczynają, bo to nie ma sensu. Chwilę o tym porozmawialiśmy i na koniec pojawił się jednak pomysł, jak do tematu podejść przyrostowo. Rozmówca zrozumiał wówczas, dlaczego myślenie w perspektywie miesiąca nie jest zbyt użyteczne. Że to bardziej temat na lata, by w pełni wypracować i wdrożyć metodykę ( w tym, narzędzia do pracy zespołowej). Natomiast podzielenie tego procesu na przyrosty, opracowywane w sposób uwzględniający stan docelowy, zostało uznane za słuszne.

A jak zabezpieczyć się przed ryzykiem pójścia w maliny, padło pytanie na koniec. Odrzekłem, że trzeba mieć w zespole doświadczoną osobę, która będzie mistrzem dla czeladników. A skąd ją wziąć, padło kolejne.

Hmmmm, dobre pytanie, pomyślałem. Pandemia agile’owa spowodowała, że wytworzyła nam się luka pokoleniowa. Osoby, które mają takie doświadczenie, to moim zdaniem ludzie w wieku 45+ (oczywiście z wyjątkami). Sam znam kilkadziesiąt takich osób. Z szeroką wiedzą, dużym doświadczeniem w konsekwentnym stosowaniu procesów wytwórczych opartych o modelowanie w różnego typu przedsięwzięciach. Część z nich…jest już na emeryturze. Ci, którzy nie są, pracują w firmach i raczej nie wspomogą innych firm. I taka mnie tkła myśl, że jeśli rzeczywiście pandemia ma się ku początkowi końca i firmy zdecydują się na to, by usprawniać swoją pracę posiłkując się zdroworozsądkowo technikami, które lata temu zostały uznane za niewłaściwe, to pojawi się problem kompetencyjny. Bo zabraknie mistrzów, którzy mogliby przez dłuższy okres zabezpieczać pracę wdrażających się zespołów. A bez nich, firmy staną przed dylematem, wymyślać koło od nowa, czy nie? A jeśli nie, to co? Bo same książki (jakie by nie były dobre) i szkolenia (jakie by nie były dobre) to za mało.

To była ta mało optymistyczna część naszej rozmowy.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Grafika: House photo created by master1305 – www.freepik.com