„Klient tkwi w szczegółach” – podsumowanie styczniowego Poznan Agile User Group

paug

50 uczestników, jeden prelegent, rzadki temat i wielotorowe dyskusje – tak w skrócie można zapamiętać styczniowe spotkanie poznańskiej grupy agilowej. Paweł Ziemba przygotował swoje ujęcie tematu roli Product Ownera i podszedł do sprawy metodycznie, analizując i wyliczając przypadki projektów, w których brał udział. Można zarzucać trochę akademickie podejście do podziału projektów pod wieloma względami na typy, których nazwy czasami wzbudzały kontrowersje, ale tym podziałem Paweł pokazał uczestnikom ważną rzecz – dyskutując o roli Product Ownera, a w szczególności sypiąc jak z rękawa dobrymi radami, jak PO powinien się zachowywać, albo kto nim powinien być, warto najpierw sprawdzić, o jakim kontekście projektu mówimy. Czym innym będzie projekt unijny pisany wg ustalonej z góry specyfikacji dla zewnętrznej firmy na podstawie zamkniętego kontraktu, a czym innym wewnętrzny projekt rozwoju produktu własnej firmy. A jeszcze kompletnie inną specyfikę może mieć projekt na zamówienie po wygranym przetargu, pisany przez dostawcę dla urzędu administracji publicznej.

Głosy uczestników spotkania były podzielone już w momencie, gdy ktoś stwierdził, że agile sprawdza się dobrze tylko wtedy, gdy zespół i zamawiający system znajdują się w obrębie jednej firmy, a każda umowa wiążąca firmę wykonawczą powoduje zamianę manifestu agile w coraz większą fikcję. Paweł przedstawił kilka przykładów projektów z perspektywy dostawcy, w których agile funkcjonował mimo tego, że wiązał go i jego firmę kontrakt.

Praktyczną poradą jak sprzedać kontrakt agilowy było złożenie obietnicy realizacji pierwszego sprintu i zapłaty za niego w momencie, gdy odbiorca będzie zadowolony lub wprowadzanie poprawek na koszt firmy realizującej. Paweł uczestniczył w podobnej relacji w 3 projektach, z których udały się dwa. Trzeci był nieudany, ale w gruncie rzeczy prelegent ocenił taki rozwój sytuacji jako korzystny, ponieważ szybko ujawniło się niezdecydowanie klienta, w konsekwencji szybko mogli się rozstać, a nie brnąć w nieudanym i wyczerpującym projekcie, który na kłopoty prawdopodobnie i tak był skazany.

Drugi ciekawy przykład to problem projektu unijnego z zamkniętym, dokładnie określonym przed rozpoczęciem realizacji zakresem. Pomysł wydawał się dobry, a projekt miał trwać 5 miesięcy, jednak już po realizacji pierwszych fragmentów i pokazaniu docelowym użytkownikom do testów, okazało się, że osoba kreująca wizję niezupełnie trafiła w potrzeby klienta – mówiąc bardziej dosadnie, rozwiązywała teoretycznie problem, który w praktyce klienci obsługują kompletnie inaczej. W tym projekcie agile również okazał się udaną drogą, ponieważ w obrębie istniejącego kontraktu i istniejącego zakresu z wniosku Product Owner z zespołem znaleźli rozwiązanie, jak w minimalnym stopniu wypełnić wymagania zapisane w warunkach dofinansowania unijnego i jednocześnie udało im się tak dopasować produkt, by lepiej odpowiadał na potrzeby rynku.

Ostatnim praktycznym przykładem wartym zapamiętania był projekt dla urzędu administracji, który cechował się tym, że wszyscy interesariusze mieli kompletnie wycinkowe pojęcie o systemie, nikt nie czuwał nad całością, wymagania często się wykluczały albo były enigmatyczne, a sami urzędnicy nie mieli najmniejszej ochoty na bliską współpracę z zespołem deweloperskim. Ćwiczeniem, które przekonało partnerów do realizacji agilowej, było zrealizowanie „marshmallow challenge”, którego szczegóły opiszemy wkrótce na łamach agile247.pl.

Spotkanie zakończyło się luźniejszą dyskusją na tematy wyborów odnośnie roli PO – lepiej decyzyjny, czy blisko zespołu? Lepszy kompetentny dziedzinowo po stronie klienta, ale niedostępny, czy dostępny dla zespołu, ale znający produkt tylko na podstawie zebranej analizy biznesowej? Trudno było o konsensus w tych tematach, a pytania te zasługują na odrębny felieton, który niebawem.

Spotkanie grupy poznańskiej zakończyło się tradycyjnie częścią nieoficjalną w pobliskim barze, gdzie oprócz rozmów wszelakich część uczestników wzięła udział w betatestach niniejszego portalu.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x