Przejdź do treści

Dlaczego programiści nie chcą uczestniczyć w spotkaniach analitycznych?

Tak się złożyło, że trafiłem ostatnio na prezentację Jakuba Szczepanika pod tytułem „Nie ma miejsca dla analityka w agile – a może jest?” zorganizowaną przez Trójmiejską Grupę Analityczną. I na marginesie notatek z tej prezentacji powstał ten wpis.

Ideałem promowanym przez Scrum jest praca całego zespołu deweloperskiego nad dekompozycją wymagań. W charakterystyce zespołu przeczytamy:

Niezależnie od rodzaju wykonywanych zadań — na przykład testowania czy analizy biznesowej – Scrum nie uznaje podzespołów w Zespole Deweloperskim i od tej reguły nie ma wyjątków.

W praktyce wiele zespołów ma tendencje do przekazywania pracy między podzespołami. „Ania i Basia zrobią teraz analizę, potem Cela i Daria zaprogramują, a na końcu Ewa i Frania to przetestują”. I jeżeli mamy takie podejście, to czasami – nawet przy pracy w krótkich iteracjach – przekazujemy sobie elementy backlogu między nieformalnymi podzespołami. Niby nie mamy podzespołów, a jednak…

Scrum Guide mówi: nie. Fajnie, że macie różne kompetencje, ale spróbujcie pracować wspólnie nad wszystkimi fazami rozwoju waszego produktu. I tutaj często pojawia się takie stwierdzenie: „to piękna teoria, ale programiści z mojego zespołu nie chcą uczestniczyć w analizie i wykręcają się jak mogą od spotkań z klientem”.

Przyznam szczerze – sam przez długi czas miałem w głowie taki obraz. Miałem obraz programistów, którzy wolą zakopać się w kodzie, rozwiązywać problemy techniczne i tworzyć nowe komponenty. Miałem w głowie obraz programistów, którzy zakładają słuchawki z muzyką i unikają spotkań analitycznych. Miałem w głowie obraz programistów, którzy czekają aż dostaną gotowe wytyczne do implementacji.

Aż wreszcie uświadomiłem sobie, że nie zauważyłem jednej istotnej rzeczy. To nie jest tak, że programiści nie chcą uczestniczyć w spotkaniach analitycznych. Programiści nie chcą uczestniczyć w ZŁYCH spotkaniach analitycznych. Nie chcą uczestniczyć w spotkaniach, które nie wnoszą dla nich wartości.

Większość programistów, których znam, to bardzo racjonalni i pragmatyczni ludzie. Uczestniczą w tych aktywnościach, które pomagają im w wykonywaniu zadań. I uciekają od tych aktywności, które nie dają im żadnej wartości.

Dlatego programiści często unikają spotkań, które są przegadane, zbyt ogólne lub nie mają większego wpływu na zadania do implementacji. Ale jeżeli zaczniemy rozmawiać rzeczach, które mają wpływ na implementowany system i jeżeli pokażemy, że ich głos ma rzeczywisty wpływ na budowane rozwiązanie – wtedy sytuacja może zmienić się diametralnie.

Oczywiście bywają sytuacje szczególne, kiedy merytoryka biznesowa jest tak skomplikowana i zawiła, że najłatwiej jest posadzić jednego człowieka, żeby się w nią zanurzył i spróbował ją zrozumieć. Możemy wtedy wydelegować jakąś osobę do tego zadania – ale pod warunkiem, że za jakiś czas opowie ona reszcie zespołu o tym, co odkryła. W zespole implementującym system bankowy nie wszyscy znają się na schematach księgowych. Ale wszyscy wiedzą, czym są te schematy, wszyscy współtworzą rozwiązanie i wiedzą, do kogo zwracać się z pytaniami o szczegóły.

A czy programiści z Twojego zespołu uczestniczą w spotkaniach z klientem, na których wypracowywane jest rozwiązanie?

2 komentarze do “Dlaczego programiści nie chcą uczestniczyć w spotkaniach analitycznych?”

  1. Niestety, ale tak jest, że nie każdy chce być analitykiem, definiować problem, proponować rozwiązania. Tak samo nie każdy analityk ma kompetencje programisty czy testera. Nie ma uniwersalnych żołnierzy.

    Praca, często w niedoczasie powoduje, że ludzie bez zacięcia takiego czy innego czują jakby marnowały czas nie zajmując się czymś w zakresie ich kompetencji, dlatego warto realnie określać kto do jakich zadań jest potrzebny, kiedy się będzie uczył nowych kompetencji, itp.

    Trzeba dzielić się wynikami prac, żeby podnosić ich jakość poprzez konstruktywną krytykę i jednocześnie podnosić morale, że coś udało się zrobić, natomiast to, że przy każdym etapie rozwiązania problemu musi uczestniczyć cały zespół jest bzdurą.

  2. Kilka lat temu pracowałem w zespole, który wytwarzał produkt dla ,,klienta wewnętrznego” i bywałem na spotkaniach bezpośrednio z odbiorcami oprogramowania. Inni programiści też bywali. Jednak nie zawsze wspominali to dobrze. Zdarzało się usłyszeć „według mnie to dwie godziny pracy, zróbcie to”, „zrobiliście to bez sensu”. albo ,,okej, ale nie bedziemy tego używać”.  Żeby nie było, że zawsze było źle. Nawet mieliśmy luksus na jeden dzień pójść i poużywać naszego oprogramowania tak jak normalni użytkownicy. Bardzo ciekawe doświadczenie siedzieć obok kogoś dla kogo robisz oprogramowanie i widzieć jak wiele rzeczy jest nie tak jak użytkownik oczekuje. Ile ,,oddolnej inicjatywy” po czymś takim powstaje i programista sam chce naprawić bolączki użytkownika.

    Teraz gdy jestem członkiem zespołu, który wytwarza produkt dla kompletnie innego klienta i użytkownika programiści też chcą rozmawiać o problemie, rozwiązaniu i skutkach. Na ostatniej retrospektywie pojawił się nawet postulat by PO przedstawił jakie są wyniki naszej pracy, jak zmieniły się KPI itp.

    Pamiętam również programistów, którzy bardzo chcieli zaangażować się w pracę z klientem, proponowali możliwe rozwiązania, jednak nikt nie chciał ich słuchać. W takim wypadku zapał szybko mija i zakłada się słuchawki, zakpuje w kodzie i tworzy nowe komponenty.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.