Dziś wracamy do fundamentów – będzie trochę o budowie zespołów, trochę o wymaganiach, ale przede wszystkim – o zwinności. Oraz o przekazywaniu pracy z rąk do rąk, oczywiście.
Za co nam płacą?
Cofnijmy się na chwilę do przeszłości. W wielu waterfallowych projektach, poszczególne etapy prac były nie tylko akceptowane przez klientów, ale i opłacane. To znaczy, zdarzały się sytuacje, gdzie klient odbierał i płacił za np. specyfikację wymagań. Powodowało to błędne przekonanie, że ’robimy dla klienta analizę’ – w końcu za nią płaci! A to, że analitycy robili sobie, architekci sobie, a programiści sobie powodowało, że nikt tak naprawdę nie dostarczał rozwiązań. Każdy ’robił swoje’.
Jeżeli zaś cały projekt przebiegał etapami, to bardzo często klient płacił za zrealizowanie poszczególnych modułów czy części systemu. Robiliśmy sprzedaż, potem zabieraliśmy się za księgowość. Jaka więc jest różnica w stosunku do podejścia zwinnego? Klient płacił, ale i tak nie mógł niczego używać. System sprzedażowy bez rozliczeń nie miał sensu. Za to zapłata po każdym etapie była potrzebna dostawcy, żeby z kolei mógł zapłacić swoim ludziom.
Jeśli nie przekazujemy gotowego (nawet częściowo) rozwiązania do użytku, to sami sobie generujemy ryzyko. Niestety, wiąże się to z tak zwanym ’(Definition of) Done Schrödingera’. Niby coś zrobiliśmy, ale ponieważ nikt tego jeszcze nie używał, to system był w superpozycji dwóch stanów: zarówno działał idealnie, jak i miał pełno błędów. Niestety, dopiero w momencie rozpoczęcia użytkowania jeden stan się zmaterializuje. Zwykle ten z błędami.
Zwinna zmiana
Agile przyniósł powiew świeżości do tego skostniałego świata IT, mówiąc: ’róbmy małe, działające kawałki, które da się używać i przynoszą jakąś wartość. Za te kawałki spokojnie możemy się nawet rozliczać, bo przecież są, działają i klienci na nich skorzystają. Co więcej, przez to, że są one w ciągłym użyciu, mamy informacje zwrotne i możemy kolejne kawałki robić lepiej albo nawet przerobić te stare.’
Podstawową różnicą było to, że nikt nie 'robił analizy’, nikt nie 'robił architektury’, tylko robiło się albo całe rozwiązanie (iteracyjnie i przyrostowo), albo poszczególne funkcjonalności. Klientowi nie zależało na analizie fakturowania, tylko na szybszym księgowaniu faktur. A to jest coś, za co z chęcią płacił.
Back to the future
Mamy rok 2024. Gdzie nie trafiam, tam widzę najgorsze antywzorce z budowy zespołów i dzielenia wymagań. Z jednej strony znowu pojawiają się 'zespoły analityczne’, 'zespoły deweloperskie’, gdzie analitycy robią analizy, a programiści – kod. Znów nikt nie robi produktu, nikt nie robi funkcjonalności, nikt nie robi 'lepiej’ klientom.
Z drugiej zaś strony często mamy inny podział – na warstwy. 'Zespół frontend’, 'zespół backend’ i te same problemy. Nikt nie robi rozwiązania, nikt nie czuje się za nie odpowiedzialny. 'Backend działa.’ A skąd wiemy? 'Przetestowaliśmy.’ Tylko sam fakt, że działa backend nie znaczy jeszcze, że produkt jako całość jest użyteczny i wartościowy.
Inna sprawa, to czy ktoś w ogóle testuje zadowolenie klienta i to, czy wszystko zebrane razem działa? Często jest to biedny 'zespół testerski’, który jako jedyny rozumie, co właściwie budujemy. Przekazywanie pracy z rąk do rąk do najgorszy wzorzec budowy zespołów. Nie tylko powoduje opóźnienia i nieporozumienia, ale przede wszystkim rozmywa odpowiedzialność za efekt końcowy. ’My robiliśmy tylko backend’, 'a my tylko architekturę’.
Zarówno podział funkcjonalny jak i na warstwy często widać w samej konstrukcji zespołów, ale też w backlogach. Jak widzę 'User Story Analityczne’ i 'User Story Testerskie’, to ręce mi opadają. Podobnie jak podział na 'Storno Backend’ i 'Storno Frontend’.
No to za co nam płacą?
Czy jakiś klient gdziekolwiek i kiedykolwiek przychodzi i mówi ’chciałbym analizę do wyliczania odsetek ustawowych’ albo ’poproszę backend do korekty faktury do zera’? Jeśli tak, to oczywiście możemy to zrobić i zgarnąć za to pieniądze. Ale jeśli nie, przestańmy takie bzdury umieszczać w backlogach! Prosty test na Element Backlogu Produktu (PBI) to pytanie ’Czy klient byłby zadowolony, gdyby nazwa naszego PBI to była pozycja na fakturze?’
Jeśli nasze zespoły nie pozwalają nam na zrobienie czegoś od A do Z, to zajmijmy się takim ich przebudowaniem, żeby dały radę. A jeśli brakuje nam kompetencji, to zacznijmy się nimi wymieniać! Niech ten nieszczęsny programista frontend nauczy się podstawowych rzeczy z backendu i niech razem zrobią jedno rozwiązanie. ’Ja robię tylko frontend, nie umiem dodać kolumny w tabeli w bazie danych’ brzmi jak jakiś słaby żart.
Ale dobrze, jeśli się nie chcemy wymieniać kompetencjami, ale nieszczęsny 'frontend’ ciągle jest z tyłu, to zatrudnijmy więcej frontendowców! Najczęstszym uzasadnieniem takiego właśnie podziału jest obawa o to, że nie będziemy mieli równego obłożenia pracą. Tzn. tworząc zespoły kross-funkcjonalne, stworzymy sytuację w której np. backendowcy czekają na frontend i się nudzą. Proste rozwiązanie: niech się nie nudzą, tylko realizują prace na rzecz produktu. Niech sie uczą i zdobywają kompetencje w innych obszarach tak, żeby praca szła równo.
To wszystko są proste problemy z trudnymi rozwiązaniami. Ale naprawdę da się to zrobić! Był taki złoty okres w mojej zawodowej karierze, gdzie zespoły faktycznie robiły produkty i/lub funkcjonalności. W Sprintach. Całościowo albo przynajmniej biznesowo. A jak ktoś uważa, że ’niektórych wymagań nie da się podzielić biznesowo na mniejsze’, to zachęcam do zorganizowania u siebie w firmie szkolenia z (między innymi) dzielenia wymagań. Pokażemy, że się da.
Niniejszy tekst pierwotnie został opublikowany na naszej liście mailingowej, gdzie raz w tygodniu rozsyłamy tego typu wiadomości prosto do Twojej skrzynki. Zapraszamy do darmowej subskrypcji!
