Agile of Agile. Stałe i zmienne elementy procesu realizacji produktów cyfrowych.
Rok 2020. Na dobre odeszły już z góry zdefiniowane wymagania projektowe i nastał czas nowoczesnych, bardziej elastycznych metodologii rozwoju oprogramowania. Aktualnie jedyną stałą w projekcie jest budżet lub/oraz deadline. Pozostałe elementy ewoluują wraz z postępami prac produktowych.
Dlatego też droga do sukcesu usiana jest masą niewiadomych lub nawet nieznanych nam niewiadomych. To, w połączeniu z dynamicznym charakterem dzisiejszych projektów cyfrowych oraz subiektywnością decyzji produktowych tworzy z zarządzania nie lada wyzwanie. Właśnie dlatego powstał Agile, a później, gdy okazało się, że są problemy z jego skalowaniem w ogromnych korporacjach, powstał Scaled Agile Framework- w skrócie SAFE.
Każdy jednak wie, że ile zespołów tyle implementacji owych metodologii co prowadzi do próżnych poszukiwań złotego środka, jakim byłaby uniwersalna metodologia aplikowana do wszystkich, dużych i małych, korporacyjnych i start-upowych, projektów cyfrowych. I tu wkraczam ja, błędny rycerzy na krucjacie po jakość, przejrzystość oraz prostotę. W trakcie moich wędrówek niejednokrotnie napotykałem szereg wyzwań i problemów na drodze ku dostarczeniu satysfakcjonującego produktu końcowego, co pozwoliło mi wyrobić sobie osobisty pogląd na charakterystykę i potencjalne rozwiązania trapiących nas problemów.
Warto więc zacząć od podzielenia wspomnianych czynników zmiennych na kategorie. Pierwsza z nich to czynniki technologiczne, czyli te wynikające z decyzji lub wymagań projektowych mających bezpośredni wpływ na nasz stack technologiczny (inaczej używane technologie), który może znajdować się w chmurze lub in-house czy też być native mobile, czy web. Ważna jest tu również kompatybilność z komponentami zewnętrznymi (third-party), a także zmieniające się wymagania. Natomiast czynniki procesowe materializują się głównie w postaci ciężko przebijanych murów proceduralnych lub powtarzających się, uciążliwych czynności niezwiązanych bezpośrednio z projektem.
To między innymi ograniczenia w wykorzystywaniu otwartego oprogramowania czy ograniczenia licencyjne komponentów, a także wszelkiego rodzaju procesy walidujące używalność elementów stacku technologicznego pod względem bezpieczeństwa czy wydajności. Wymagania czysto administracyjne, czyli projektowy overhead niemający bezpośredniego związku z naszym przedsięwzięciem, lecz z jego egzystencją w szerszym ekosystemie.
Jest to problem raczej spotykany w korporacjach i innych dużych organizacjach niż start-upach. Wyzwaniem jest także raportowanie poziome i pionowe. Niezwykle ważny jest również czynnik ludzki, gdyż łatwo jest zapobiec potencjalnym problemom, a jednocześnie najtrudniej jest rozwiązać te, które już powstały. Mianowicie, wystarczy zatrudniać odpowiednich ludzi. Jednak każdy, kto pracował w projektach rozproszonych wie, jak mało wpływu ma się na ogólną organizacyjną politykę rekrutacyjną. I tak lądujemy w sytuacjach, w których poszczególne jednostki grają na swoją korzyść, a nie na korzyść projektu. Przykładowo kontraktorzy, którzy albo chcą, aby trwał on jak najdłużej, albo interesuje ich tylko dowiezienie pierwszego kamienia milowego, którym mogliby się pochwalić na kolejnej rozmowie rekrutacyjnej, bez zastanowienia się nad długoterminowymi konsekwencjami swoich decyzji względem projektu.
Równie negatywny wpływ ma brak ustandaryzowanej semantyki techniczno- produktowej, co prowadzi do braku zrozumienia pomiędzy osobami pracującymi nad różnymi aspektami projektu, przykładowo deweloperami a Product Ownerem. Brak wiedzy technicznej pozwalającej na zrozumienie charakteru napotykanych problemów i wyzwań prowadzi do konfliktów i odgórnie podejmowanych decyzji lub błędnie implementowanych rozwiązań technicznych. Często to ego wygrywa nad rozsądkiem i dobrem naszej idei, a rotacja na stanowiskach decyzyjnych może prowadzić do częściowej lub całkowitej zmiany kierunku w projekcie. Powyżej przytoczone sytuacje są oczywiście tylko przykładami, które każdy z nas w tej lub innej postaci, prędzej czy później, napotka na swojej drodze. Niemniej patrząc na powyższą listę potencjalnych wyzwań, można by się zacząć zastanawiać, jakim cudem dowożone są jakiekolwiek projekty cyfrowe.
Na szczęście sytuacje, w których projekt napotyka całościowy kataklizm są ekstremalnie rzadkie, aczkolwiek nie niespotykane. W większości przypadków mamy do czynienia z maksymalnie kilkoma ze wspomnianych problemów, mamy więc pełne pole do popisu w kwestii ich rozwiązywania. Chciałbym się jednak skupić na jednym podstawowym aspekcie wszystkich tych problemów, jakim jest semantyka wewnątrz projektowa. Każdy z członków zespołu czy interesariuszy ma swój indywidualny sposób patrzenia na świat technologii cyfrowej. Pomimo zalet tak szerokiej perspektywy, może to prowadzić do patologii komunikacyjnych już na wczesnych etapach projektu.
Wszyscy przywykliśmy do pewnych truizmów w naszych poszczególnych dziedzinach i często zapominamy, że osoby pełniące inne role mogą nie być świadome niuansów semantycznych naszych wypowiedzi. Dlatego też imperatywne jest stworzenie już na samym początku jednoznacznie rozumianego leksykonu krytycznych pojęć projektowych oraz jego wdrożenie i zweryfikowanie w praktyce. Ma to na celu standaryzacje komunikacji wewnątrz projektowej na wszystkich jej płaszczyznach tak, aby uniknąć najbardziej podstawowych błędów komunikacyjnych wynikających czy to z różnych poziomów wiedzy technicznej lub domenowej czy nawet barier językowych. Kolejnym etapem analizy semantycznej powinna być analiza celów projektowych. Ma ona za zadanie ujednolicenie kryteriów sukcesu projektowego w formie przejrzystej i jednoznacznej listy. Gdy już będziemy takową posiadać, powinno być to równoznaczne z tym, że każdy w projekcie rozumie jej treść w ten sam sposób i ją akceptuje.
Dzięki temu już na wstępie mamy solidne podwaliny pod wspólną pracę and projektem. Wielu z Was może zadawać sobie w tej chwili pytanie odnośnie do istotności powyższych dywagacji w odniesieniu do wcześniej wspomnianych i skategoryzowanych problemów. Odpowiedź jest bardzo prosta, elementy semantyczne są nierozerwalnie złączone z innymi czynnikami procesowymi. O ile pominiemy problem ludzkiego ego, to wszelkie dyskusje na ten temat powinny być merytoryczne i dążyć do osiągnięcia racjonalnego konsensusu.
Zakładając oczywiście, że każda z zaangażowanych stron jest w stanie przedstawić i uargumentować swój pogląd na dane zagadnienie w sposób jasny i zrozumiały dla wszystkich pozostałych uczestników dyskusji. Źródło najczęstszych frustracji pracowników korporacji posiada też drugie dno, którego często nie widzimy z powodu ograniczenia naszej percepcji wewnątrz organizacyjnej. Formalności, które dla nas wydają się bezsensowne, mogą być jedyną rzeczą dzielącą nas od kompletnego chaosu. Być może wystarczy, aby ktoś nam to wytłumaczył?
Czynniki personalne to kategoria najbardziej podatna na problemy natury semantycznej, gdyż jest bezpośrednio związana z ludzkimi umiejętnościami komunikacyjnymi lub ich brakiem, a wszyscy dobrze wiemy do czego potrafią doprowadzić konflikty interpersonalne w projekcie. Nietrudno zatem dostrzec, jak ważna jest ta spójność wewnątrz projektu, a także zespołu nad nim pracującego. Powyższą analizę chciałbym jeszcze uzupełnić o jedno spostrzeżenie. Szerokie spektrum potencjalnych problemów na drodze ku dostarczeniu satysfakcjonującego jakościowo produktu cyfrowego prowadzi do pewnego rodzaju paradoksu.
Mianowicie, próbując rozwiązać jeden z problemów semantycznych tworzymy inny, np. chęć ustandaryzowania procesów wewnątrz projektu, może prowadzić do niekończących się dyskusji na temat owych standardów i tego kto ma o nich decydować. W praktyce sytuacja ta jest bardzo często spotykana w przypadku rotacji na stanowiskach seniorskich lub produktowych. Z kolei zmiana na stanowisku Delivery Leada/Managera może poskutkować wywróceniem do góry nogami procesów raportowania pionowego oraz zakwestionowaniem wszystkich wcześniej ustalonych procesów dostarczania oprogramowania.
W świetle powyższych przemyśleń oraz wobec faktu relatywności semantyki w relacjach interpersonalnych, błędem jest myślenie, że jakakolwiek pojedyncza jednostka jest w stanie rozwiązać wszystkie wyżej wspomniane problemy. Jedynym światełkiem w tunelu na drodze ku wydajności i przejrzystości jest świadoma transformacja kulturowa całej organizacji lub jej fragmentu, a co za tym idzie jej wewnętrznej semantyki, a tej nie osiągnie się ogłaszając coraz to nowsze polityki wewnętrzne czy publikując manifesty usiane new age’owymi sloganami z dziedziny IT. Można ją jedynie osiągnąć, rekrutując odpowiednich ludzi na odpowiednie stanowiska oraz propagując pozytywne wzorce kulturowe, a zarazem walcząc z przejawami jakiejkolwiek patologii w zakresie zarówno technicznym, procesowym jak i personalnym. Bo w odróżnieniu od zbiorowego wysiłku pozytywnej transformacji, do zniszczenia kultury pracy w firmie, dziale czy zespole wystarczy jedno zepsute jabłko, od którego zacznie się lawinowe gnicie poszczególnym elementów procesu dostarczania produktów cyfrowych. Dbajmy więc o semantykę wewnątrz projektową.
