Dość często można usłyszeć takie krzyki. Zwykle, im gorzej zorganizowany projekt, tym więcej osób chce, aby „zostawić programistów w spokoju i pozwolić im pracować”. Tak, jakby cała otoczka projektowa była zbędna i do pełnego sukcesu wystarczyłby sam kod. Nic bardziej mylnego.
Rys historyczny
Wiele lat zajmowałem się programowaniem. Brzmi to trochę jak wyznanie, ale mile wspominam tamte lata. To jednak umiejętność spojrzenia na problemy zarówno z punktu widzenia kodu jak i potrzeb biznesowych okazała się być bardziej pożądana na rynku. Równolegle z byciem Scrum Masterem i trenerem Scrum przez lata byłem więc analitykiem.
Przez ten czas miałem do czynienia z wieloma organizacjami, projektami i rozwiązaniami. Zawsze gdzieś też następował moment, w którym ktoś w końcu rzucił „Zostawcie programistów w spokoju!” lub „Pozwólcie nam po prostu pracować!”.
Czasami chodziło o Sprint Retrospective i o „ciąganie programistów na spotkania biznesowe”, ale najczęściej po prostu o jakąkolwiek metodykę prowadzenia projektów. Przecież wystarczy tylko „klepać kod”, bo „my już wiemy co mamy zrobić”.
Ale czy na pewno?
Przez programistów, dla programistów
Przez lata używałem wielu rozwiązań open source’owych. Niektóre z tych projektów są zarządzane tak sam, jak rozwiązania komercyjne, ale inne są robione „przez programistów dla programistów”. Można by rzec, że jest to raj dla ludzi, którzy chcą w spokoju programować. I to niestety widać.
Rozwiązanie stworzone przez programistów dla programistów zwykle jest nie do zaakceptowania dla szarych użytkowników. Klient nie powinien doktoryzować się z informatyki, żeby móc wygodnie korzystać z aplikacji. Nie powinien słyszeć „to oczywiste”, „domyśl się”, „przecież to jest tu i tu”, bo to sugeruje że rozwiązanie nie powstało dla niego.
Problem usability i UX jest o wiele szerszy niż tylko zapędy programistyczne, bo ten aspekt kuleje często też u analityków. Niemniej, samym programistom bardzo trudno jest wczuć się w typowego użytkownika, który o komputerach wie o wiele mniej niż ktokolwiek związany z IT.
Branża IT żyje w bańce i nietrudno jest założyć, że wszyscy na świecie mają tak samo jak my. Tymczasem dla wielu osób instalacja aplikacji na telefonie jest skomplikowana. Synchronizacja danych pomiędzy kilkoma komputerami to ogromne wyzwanie. Udostępnienie filmów z wakacji dla kilku znajomych jest praktycznie niemożliwe. Trudno jest to sobie wyobrazić, jeżeli wszyscy nasi koledzy są „z branży”.
Dlatego też nie uważam, żeby „zostawienie programistów w spokoju” to było dobre rozwiązanie, jeżeli chcemy tworzyć rozwiązania dla szerszego grona odbiorców.
Kto zadba o spójność?
Nawet jeśli doskonale wiemy co mamy do zrobienia i zadbaliśmy wewnątrz naszych zespołów o wsparcie dla UX, to nie możemy mieć pewności, że nasz klient wie czego chce.
Nie jest to też jego wina. Bardzo często po prostu wyobrażamy sobie, co nam może się przydać, ale dopiero gdy to faktycznie dostaniemy do rąk własnych okazuje się, jak to jest dla nas użyteczne (i czy w ogóle).
Pomóc w tym aspekcie może doświadczony Product Owner, który pracując z klientem poznaje jego potrzeby i, jak to się ładnie mówi, „optymalizuje wartość wytwarzanego rozwiązania” czyli sugeruje bardziej perspektywiczne drogi rozwoju. Także sam Zespół Deweloperski, w myśl Agile Manifesto, powinien ściśle współpracować z użytkownikami końcowymi, aby realizować ich najskrytsze potrzeby.
Chcemy też, żeby tworzone rozwiązania wpisywały się w ogólną wizję produktu. I tu znów odnajdziemy wartość płynącą z roli Product Ownera. Bo jeśli wszyscy jesteśmy zajęci „tylko programowaniem”, to nikt nie ustala hierarchii potrzeb, ani nie przygląda się potencjalnym szansom na zmiany zakresu.
To jest kolejna zaleta tworzenia Minimum Viable Product czyli MVP. Z jednej strony mamy klienta, który nie zawsze wie, czego potrzebuje. Z drugiej zaś programistów, którzy nie są nawet zainteresowani pomocą klientowi w uświadomieniu swoich potrzeb. Jak to pogodzić? Zróbmy działający fragment aplikacji, który oddamy do użytku klientowi.
Bardzo ważne jest, żeby nie traktować MVP jako proof-of-concept, bo wtedy nie podejdziemy do tego na poważnie. Unikajmy jak ognia prezentowania klientowi rozwiązania podczas demo czy szkolenia. On musi zacząć tego używać, żeby przekonać się czy jest to dla niego wystarczające i odpowiednie. Dopiero gdy będzie miał skin in the game i będzie używał naszego rozwiązania na co dzień, dowie się jak bardzo mu ono (nie)odpowiada.
Kto się zajmie organizacją?
Trzecim, wcale nie najmniejszym, aspektem dla którego „po prostu tworzenie oprogramowania” się nie sprawdza jest optymalizacja machiny projektowej.
Im mniejszy projekt, tym bardziej jesteśmy w stanie sami poradzić sobie z całą biurokracją, harmonogramowaniem, terminami, itp. Trzyosobowy start-up spotykający się co jakiś czas w kawiarni może nawet być zespołem rozproszonym bez związanego z tym spadku efektywność. Szczególnie, jeśli mają niezależne zadania.
Nie wyobrażam sobie natomiast żadnego większego projektu składającego się tylko i wyłącznie z „zostawionych w spokoju” programistów. Już nawet nie mówię tutaj o kwestiach formalnych i niezbędnej biurokracji, ale o samej synchronizacji pracy, zależności pomiędzy wymaganiami i wyznaczania spójnego kierunku rozwoju.
Poziom skomplikowania projektu rośnie wraz z liczbą osób i wymagań, a dzisiaj raczej nikt nie tworzy prostych aplikacji. Stąd potrzeba takiej organizacji projektu, żeby pomagała w stworzeniu i realizowaniu wspólnej wizji, a jednocześnie żeby „zostawiła programistów w spokoju”.
Do takich celów idealnie sprawdza się Scrum. Jak wspominaliśmy w tekście Artefakty, Wydarzenia, Role, narzut na spotkania scrumowe to jedynie 12%. Czas poświęcony na planowania, synchronizacje i retrospektywy zwróci się z nawiązką. I chociaż pewnie nadal będą osoby, które będą narzekały na „te wszystkie spotkania”, to musimy mieć świadomość, że bez nich tracilibyśmy o wiele więcej czasu na rozwiązywanie całej masy problemów.
Bądźmy praktyczni!
Czy są developerzy, którzy potrafią czuwać nad UX, potrzebami biznesowymi, spójnością rozwiązania i wybiegają w przyszłość, przewidując dalszy rozwój oprogramowania? Oczywiście.
Ale czy ktoś nie zna przynajmniej kilku programistów, których nawet siłą nie zaciągnie się na spotkanie z biznesem? Którzy non-stop powtarzają „powiedz mi co mam zrobić i ja to zrobię, ale nie zawracaj mi głowy tymi bzdurami”?
Jak zawsze mając do czynienia z ludźmi, napotkamy się na całe spektrum zachowań i osobowości, zgodne z rozkładem normalnym. Z mojego doświadczenia wynika, że ludzie pracujący w IT, a programiści w szczególności, częściej niż inni uwielbiają pracę zadaniową i rozwiązywanie skomplikowanych problemów. O wiele mniej radości sprawia im praca koncepcyjna nad rozwiązaniem biznesowym, a jeszcze mniej – odkrywanie prawdziwych potrzeb klienta.
Zawsze zdarzają się wyjątki, ale nie ma co budować na nich swojej strategii. Promowany przez nas empiryzm mówi jasno: sprawdź jak to wygląda w Twojej organizacji i dostosuj swoje podejście do realiów. Bo realia na pewno nie dostosują się do Ciebie.
Jeśli po przeczytaniu tego tekstu zainteresowałeś się wykorzystaniem metodyki Scrum na dużych projektach, zapraszamy na szkolenia Skalowanie Scrum.
