Czy w Scrumie programiści powinni rozmawiać bezpośrednio z klientami (omijając PO)?

W jaki sposób właściciel produktu w scrum powinien poradzić sobie z bardzo szczegółowymi pytaniami zespołu dotyczącymi wdrażanych przez niego funkcji, na które nie może natychmiast odpowiedzieć sam? Kiedy ewidentnie szybszym rozwiązaniem dla programisty jest bezpośrednia rozmowa z klientem?

Zastanawiam się, czy bezpośrednia komunikacja między zespołem a klientem podważa rolę właściciela produktu. Wydaje mi się, że organizacja producentów powinna reprezentować klienta i dlatego odpowiedzieć na wszystkie pytania dotyczące wymagań - nawet jeśli zajmie to więcej czasu. Ominięcie go wydaje się go osłabiać, a w końcu uczynić go zbędnym ...

Czy istnieje najlepsza praktyka w scrum?

scrum communication product-owner

— tizenegy
źródło

Zgadzam się z tobą, że właściciel powinien być jedynym punktem kontaktu między deweloperem a klientem. Nie zgadzam się z tym, że przyczyną niepotrzebnego właściciela produktu jest szybsze ominięcie roli. Ujmę to w ten sposób: w projekcie z 10 programistami nie chcesz, aby 10 osób stale rozmawiało z klientem i negocjowało funkcje. Po pierwsze, denerwuje klienta, a po drugie zajmuje dużo czasu od faktycznego rozwoju. Jeśli blokujesz wszystkie zadania, ponieważ potrzebujesz więcej informacji, musisz naprawić fazę przechwytywania wymagań i nie próbować poprawiać własności.

— Patrick Hughes,

„Kiedy byłoby to zdecydowanie szybsze rozwiązanie ...” Chcę tylko podkreślić oczywiste: szybsze niekoniecznie lepsze.

— Eric King,

Odpowiedzi:

Zawsze jest dobrym pomysłem (szczególnie w tak zwanych projektach Agile), aby nie trzymać się jakiegoś kultu ładunku lub podręcznika mówiącego „z kim (nie) rozmawiać z kim”, ale włączyć mózg i robić wszystko, co działa najlepiej w projekt.

Chociaż komunikacja między PO a klientem powinna być standardem (z powodów przedstawionych przez @PatrickHughes w jego komentarzu), możesz napotkać sytuację, w której należy wyjaśnić złożone wymagania biznesowe oraz bezpośrednią komunikację między deweloperem a ekspert biznesowy znacznie przyspieszy. W takiej sytuacji należy unikać gry „chińskim szeptem” z PO na środku i pozwolić deweloperowi i ekspertowi biznesowemu bezpośrednio ze sobą rozmawiać - w tym ograniczonym kontekście.

Jednak organizacja producentów nigdy nie powinna być omijana. Idealnie uczestniczy w tej rozmowie, prawdopodobnie jako moderator. Może sprawdzić, czy podczas rozmowy klient nie przedstawia całkowicie nowych wymagań na stole lub wymagań sprzecznych z wcześniejszymi ustaleniami.

Zależy to również od zaangażowanych osób i sytuacji. Organizacja producentów może mieć wystarczające zaufanie do konkretnego dewelopera i eksperta klienta, aby pozwolić dwóm rozmawiać samotnie na określony temat i pozwolić mu na zgłoszenie tego, co zostało powiedziane później. W innej sytuacji, z udziałem innych osób, wolałby wziąć bardziej aktywny udział. Podjęcie właściwych decyzji jest podstawą dobrego zarządzania projektami.

— Doktor Brown
źródło

„Cała idea rozwoju zwinnego polega na tym, aby nie trzymać się kultowego ładunku lub podręcznika, ale włączyć mózg i robić wszystko, co najlepiej działa w projekcie.”: To prawda, ale ta idea nie jest specyficzna dla zwinnego.

— Giorgio

+1, jeśli wykonasz scrum w zwinny sposób, to ekspert biznesowy prawdopodobnie byłby częścią zespołu i dostępny w każdym razie ...

— Marjan Venema

Dobrze. Organizacja producentów nigdy nie powinna być strażnikiem bramki. Zamiast tego OP jest ostatecznie odpowiedzialna za produkt.

— Gort the Robot

@StevenBurnap oznaczałoby to, że organizacja producentów od samego początku musi być ekspertem w tej dziedzinie ... z mojego doświadczenia wynika, że nie zawsze tak jest.

— tizenegy

@Giorgio: absolutnie, IMHO „Agile development” to tylko modne hasło, które zawiera pewne dobre nawyki, które są znacznie starsze niż termin i nie ograniczają się do siebie.

— Doc Brown

Musisz pamiętać, że klient firmy, która zatrudnia cię jako programistę, ma inne cele niż firma, która cię zatrudnia.

Właściciel produktu musi reprezentować cele Twojej firmy, a nie klienta. Jeśli więc deweloperzy udadzą się bezpośrednio do klienta, mogą podważyć własną firmę.

— Ewan
źródło

celem dla wszystkich powinno być dostarczenie możliwie najlepszego produktu w ramach budżetu i zgodnie z celem. Tylko sposób na zrobienie tego jest potencjalnym źródłem dyskusji.

— jwenting

nie bądźmy jednak naiwni. Firma może preferować wykonanie minimalnie zakontraktowanej specyfikacji i przejście na przykład na bardziej dochodowy projekt. Lub bardziej prawdopodobne z mojego doświadczenia, że klient będzie chciał dodać funkcje i rozszerzyć zakres, jednocześnie utrzymując tę samą cenę

— Ewan

Dla programistów właścicielem produktu jest klient. Idealnie (i wiem, że nie zawsze jest to możliwe) właściciel produktu powinien być bezpośrednim przedstawicielem klienta, ekspertem domeny i przyszłym użytkownikiem systemu.
Jest to najlepszy sposób na zapewnienie bezpośrednich i poprawnych informacji oraz możliwie najkrótszych linii w ich procesach.

Idealnym przykładem jest prawdopodobnie zespół, z którym obecnie pracuję. Właściciel produktu jest starszym użytkownikiem końcowym i ekspertem w dziedzinie domeny, który ma pełne uprawnienia do autoryzowania decyzji projektowych na miejscu (oraz chęci i możliwości, aby to zrobić). Jest integralną częścią zespołu i bezpośrednio pomaga analitykowi i projektantowi w pisaniu historii użytkowników, a także programistom i testerom w tworzeniu produktu, zapewniając niemal natychmiastową informację zwrotną na temat pytań dotyczących implementacji i scenariuszy testowych.
Linie nie mogą być naprawdę krótsze niż to, że Twój przyszły użytkownik siedzi obok ciebie podczas kodowania :)

— jwenting
źródło

„Linie nie mogą być naprawdę krótsze niż to, że twój przyszły użytkownik siedzi obok ciebie podczas kodowania :)”: To, czy zawsze jest to dobre, jest wątpliwe.

— Giorgio

@Giorgio oczywiście zależy od zaangażowanych osób. Ale to właśnie promuje SCRUM (i ogólnie zwinne praktyki), krótkie linie, szybkie podejmowanie decyzji. W naszym przypadku działa to, ponieważ klient jest naprawdę entuzjastyczny i chce, aby produkt odniósł sukces, ale są one również wystarczająco realistyczne, aby zdać sobie sprawę, że nie wszystko jest możliwe (na pewno nie w granicach budżetowych i technicznych, z którymi musimy współpracować).

— jwenting

Jasne i myślę, że zależy to również od rodzaju projektu. Niektóre projekty wymagają opinii częściej niż inne. Ponadto w niektórych projektach / produktach chcesz zachować pewne informacje dla siebie. Ale tak, w przypadku niektórych projektów klient siedzący z tobą w tym samym biurze i śledzący rozwój jest prawdopodobnie najlepszym z możliwych ustawień.

— Giorgio

@Giorgio: „Właściciel produktu jest starszym użytkownikiem końcowym i ekspertem od domeny, który ma pełne uprawnienia do autoryzowania decyzji projektowych na miejscu”. Brzmi to tak, jakby Twoje zamówienie mogło odpowiedzieć na każde pytanie, jakie mogą mieć programiści. Odniosłem się do innej sytuacji: organizacja producentów, która wciąż nie jest na tym samym poziomie wiedzy, co sami klienci, i dlatego musi regularnie do nich wracać, aby odpowiedzieć na trudniejsze pytania.

— tizenegy