Empiryzm, komunikacja i praca zespołowa

Przyczynkiem do powstania tego bloga była moja dyskusja z przyjacielem, który w branży IT siedzi od ponad dwóch dekad. W międzyczasie był programistą, architektem systemów, analitykiem biznesowym, PM-em, a wreszcie przedsiębiorcą. Pewnie jeszcze coś by dodał. Przy jego doświadczeniach moje 4 lata w roli Scrum Mastera to pierwszy pryszcz nastolatka.

Nasza rozmowa dotyczyła faktu, że następuje coraz większe rozdrobnienie specjalizacji w branży IT. Co oczywiście jest wypadkową rozwoju technologii informatycznych, ale poniekąd komplikuje realizowanie projektów, rozwijanie produktów i usług.

Człowiek od wszystkiego

Kiedyś programista był istnym omnibusem IT: architektem, projektantem, grafikiem, frontendowcem, backendowcem, testerem, devopsem, project managerem – szumnie nazywał sam siebie panem Informatykiem. Można powiedzieć, że z łatwością dało się osiągnąć tę interdyscyplinarność, o którą teraz tak zacięcie, w postaci ukierunkowania na tzw. T-shaped skills, walczymy w zespołach produktowych. Powrót do źródeł? Domyślam się, że poza plusami takiego podejścia, miało ono też swoje minusy. Notoryczny brak czasu, przemęczenie, a co za tym idzie – spadek jakości dostarczanego rozwiązania. Jako były redaktor wiem, jak ciężko jest poprawiać samego siebie. Nie widzi się błędów we własnym tekście, w tym wypadku – w kodzie. Ciężko też wpaść na alternatywne rozwiązanie bez bodźca, jakim często jest rozmowa z drugą osobą.

Takiego omnibusa informatyka przyrównałabym do nauczyciela bez określonej specjalizacji (poza tym, że jego dziedziną jest IT), posiadającego wiedzę ogólną. Im jednak uczeń starszy, tym coraz więcej wokół niego nauczycieli o określonych specjalizacjach, aby mógł poszerzać swoją wiedzę w różnych dziedzinach, aż w końcu zdecyduje się, którą z nich pogłębi. Tak też było i jest z rozwojem technologii informatycznych. Najpierw wszyscy mieli wiedzę ogólną, teraz każdy jest w czymś wyspecjalizowany.

Wysyp specjalizacji

Dawniej jednak technologie informatyczne nie rozwijały się w takim tempie, jak teraz. Można było ogarniać dobre praktyki z każdego zakresu w dziedzinie IT. Obecnie, gdyby jedna osoba miała znać nowinki ze wszystkich obszarów, nie miałaby czasu na pracę. W każdej specjalizacji istnieje wiele alternatyw, z którymi należy być na bieżąco, aby nie wypaść z obiegu oraz aby programować rozwiązania bezpieczne i dobrej jakości. Oliwy do ognia dolewają sami wymyślający i rozwijający poszczególne frameworki (takie pudełka z gotowymi szablonami rozwiązania), co tylko pogłębia podział na specjalizacje oraz rozleniwia co poniektórych programujących. Co bardziej zajęci mają tendencje do sięgania po framework, bo nie chce im się szukać rozwiązania dla określonego problemu. Zwiększa to tym samym tworzoną aplikację o całą zależność, nawet jeżeli programista potrzebuje tylko ułamka jej dostępnych funkcji. Czy to optymalne? Czy mnogość frameworków jest w ogóle optymalna? Mam czasami wrażenie, że wąż zjada własny ogon.

W efekcie, teraz na rynku nie szuka się już ani informatyków, ani programistów. Teraz szuka się programistów na przykład od samego frontendu (specjalizacja). Co więcej, teraz szuka się programistów od frontendu specjalizujących się w określonym frameworku JavaScript: React, Angular, Vue.js (podspecjalizacja), itd. Zamiast inżyniera devopsa (specjalizacja) coraz częściej szuka się eksperta od kubernetesów czy dockerów albo eksperta do utrzymania konkretnej platformy (podspecjalizacja). Technologie już nawet nie idą do przodu, one biegną. Granulacja postępuje. Każdy finalnie specjalizuje się tylko w jakimś wycinku programistycznego ekosystemu, w jakiejś podspecjalizacji. Wszystko świetnie, tyle że na koniec dnia żadna z tych osób samodzielnie nie jest w stanie dostarczyć wartości klientowi.

Konieczna jest praca zespołowa.

Jak pracować?

W toku tych zmian ludzie z branży IT szukali optymalnego rozwiązania, jak realizować potrzeby klientów, dbać o jakośćbrać odpowiedzialność za produkt. Szukali metod na zwiększenie prawdopodobieństwa, kontrolowanie ryzyka i dostarczanie szybciej i częściej tego, czego potrzebuje klient.

The nature of the beast is that software requirements rarely change; what changes is our awareness of them, and our grasp of their implications.

Jesse Watson

Zauważyli też, że notorycznie przerywa się im w pracy, co nie pozwala interdyscyplinarnym zespołom wytwórczym skupić się na konkretnej robocie. Programiści mieli też dosyć mikrozarządzania, niekompletnych i niejasnych wymagań, nierealistycznych harmonogramów, ciągłych statusów postępu prac i bezproduktywnych spotkań oraz bycia koordynowanymi przez managera. Jak wiemy – koordynacja wygląda czasami jak zabawa w głuchy telefon. Chcieli jako eksperci mieć przypisanego do produktu jednego przedstawiciela biznesu oraz samemu decydować o tym, jak projektować rozwiązania, aby były lepiej dostosowane do potrzeb danego klienta.

Empiryczny Scrum

Z tego tytułu w 1995 roku zebrali sprawdzone praktyki i przedstawili Scruma. Pozwala on wytwarzać, dostarczać i utrzymywać złożone produkty i usługi w oparciu o ciągłe usprawnianie zarówno rozwijanego produktu, jak i samego procesu wytwarzania oprogramowania. Scrum odciążył zespoły programistyczne od bycia w ciągłym kontakcie z interesariuszami (osobami, które w jakimś sensie wpływają na produkt lub produkt ma wpływ na nie), których nadmierna aktywność istotnie zaburzała prace zespołu. Chaotyczne uszczegóławianie wymagań w toku prac zmniejszało efektywność procesu wytwórczego, co finalnie wpływało na niezadowolenie samych klientów.

Od tego też miejsca swój początek ma ten blog (brzmi jak scena z „Było sobie życie”). Pojawiła się wtedy rola Scrum Mastera, który wspiera zespół w dostarczeniu oczekiwanego wyniku, nie przyjmując funkcji kontrolno-dyrektywnej. Rola ta od początku istnienia (Scrum kończy w tym roku 25 lat!) przeszła znaczną ewolucję. Budzi wiele kontrowersji i niejasności, bywa też z tego powodu różnie rozumiana.

Jako że 4 lata w branży to niewiele, będę głośno myśleć, zadawać wiele pytań i szukać rozwiązań na zadane i napotkane przypadki. Postaram się pokazywać mój punkt widzenia. Będę też odnosić się do wypowiedzi innych osób i postaram się raczej wchodzić w dyskusję, niż ferować wyroki. Do czego zachęcam również Ciebie.

4.5 2 votes
Ocena artykułu
Subskrybuj
Powiadom o
0 komentarzy
Inline Feedbacks
Zobacz wszystkie komentarze