Czy dobrym pomysłem jest wyznaczenie jednego z członków zespołu scrum lub mistrza scrum jako właściciela produktu?

Ostatnio mieliśmy projekt, w którym klient był zajęty zwiedzaniem. Jak zwykle powstał zespół scrum, zarząd postanowił wyznaczyć naszego analityka na właściciela produktu, ponieważ klient nie będzie mógł brać aktywnego udziału. Analityk ściśle współpracował z klientem przy analizie wymagań i opracowywaniu specyfikacji.

Klient nie ma czasu na sprawdzenie pierwszych dwóch wydań. Wszystko poszło gładko, dopóki klient nie zobaczył trzeciego wydania; nie był zadowolony z niektórych funkcjonalności, które zostały wprowadzone przez make shift Product Owner (naszego analityka).

Kazano nam czekać, aż zespół projektowy zakończy makietę wszystkich stron, a klient sprawdzi każdą z nich i wyrazi zgodę na kontynuowanie pracy. Zespół Scrum jest obecny, ale bez sprintu - zakończyliśmy pracę prawie jak klasyczna metoda wodospadu.

Czy warto wyznaczyć członka lub mistrza zespołu scrum na właściciela produktu? Czy musimy śledzić scrum przy braku udziału klienta / właściciela produktu?

Dopiero kilka tygodni temu Mike Cohn napisał na swoim blogu o połączeniu ról mistrza scrum i właściciela produktu. Nie sądzę, żebym mógł to powiedzieć lepiej niż on, ale moje krótkie streszczenie jego postu jest następujące:

• to zły pomysł
• SM i PO wykonują bardzo różne rodzaje zadań („zadania gwiezdne” i „zadania opiekuńcze” słowami Cohna)
• osoba łącząca obie role raczej nie będzie dobrze dopasowana do wszystkich zadań związanych z obiema rolami
• zespół może ucierpieć z powodu połączonego SM / PO zaniedbującego zadania, w których nie są najlepsi.

Myślę, że nie ma w sobie nic złego w zabraniu członka zespołu scrumowego i przeniesieniu go do właściciela produktu. Ale musisz zdać sobie sprawę, że to jest jak promocja lub przelew wewnętrzny; tworzy dziurę w drużynie i dziura musi zostać wypełniona. Być może zespół może się „samoorganizować”, aby wypełnić dziurę; może musi zatrudnić nowego pracownika, aby obsadzić wolne stanowisko.

Twój proces wydaje mi się w porządku. Nie opisałeś tego szczegółowo, ale role są respektowane (to ważne).

Jednak z kilkoma szczegółami, które mam, widzę jakiś problem na poziomie właściciela produktu.

Powinien upewnić się, że klient został odpowiednio powiadomiony o postępach. Wygląda na to, że robi „wodospad” zewnętrznie z klientem i „scrum” wewnętrznie z tobą.

Wynik : wodospad wygrywa, ponieważ klient jest królem. Nawet jeśli w tym przypadku klient ponosi odpowiedzialność ...

Twój obecny zespół (w tym Scrum Master) powinien skupić się na dostarczeniu zaległości sprintu. Jednak właściciel produktu (analityk) powinien upewnić się, że to, co znajduje się w jego zaległościach, odzwierciedla to, czego chce klient. Powinien także upewnić się, że komunikacja jest dobra i że klient bierze udział.

Możliwe rozwiązanie : wyślij właściciela produktu (analityka) na kurs właściciela produktu Scrum lub zmuś go do przeczytania (i zrozumienia) tej książki: Agile Product Management with Scrum .

Scrum działa najlepiej z prawdziwym klientem. Jest kilka prawdziwych wyzwań w kontaktach z klientami, którzy nie są przyzwyczajeni do iteracyjnego projektowania produktu.

• Zespół pustego arkusza
• Zespół przestraszonego klienta

Etapy projektowania z pustym arkuszem mają tendencję do bardzo szybkiego wchodzenia w niebo i zwykle pogłębiają się w kilku kwestiach ubocznych, a wymagana podstawowa funkcjonalność jest niewystarczająca. Naprawdę potrzebujesz słomkowego klienta, aby klient mógł rozdzielić spotkania projektowe, aby przebiegły pomyślnie. Koncentrując się tylko na jednym aspekcie, pomagasz klientowi w nauce projektowania iteracyjnego.

Przestraszeni klienci (podobnie jak ty z doświadczeniem) nie zdają sobie sprawy, że zwinne projekty przewidują pewną (kontrolowaną) ilość przeróbek w ramach tego procesu. Trudno im pojąć, że wraz z rozwojem produktu będzie mniej momentów „O mój boże”. Co ważniejsze, większość klientów ma trudności z tym, że momenty „O mój boże” nie wymagają ogromnej ilości pieniędzy do naprawienia z powodu krótkiego czasu między cyklami przeglądu / planowania.

Zarządzanie oczekiwaniami klientów jest bardzo trudne. To świetna równowaga w edukacji klientów, umiejscowieniu, a nawet nauce mówienia „nie”. Klient nie zawsze może przychodzić co tydzień lub co dwa tygodnie. Czasami mogą przychodzić tylko raz w miesiącu. W porządku. Tak długo, jak pokażesz im, co zrobiłeś, aby odpowiedzieć na ich obawy w poprzednim miesiącu, a następnie skoncentrować się na pracy w tym miesiącu, znacznie przyczyni się do sprawniejszego przebiegu projektu. Najważniejsze jest to, że pod nieobecność klienta masz kogoś, kto może wydać uzasadnione zalecenia dotyczące niektórych pytań. To musi być ktoś, kto zna cele, które klient stara się osiągnąć.

Idealnie właściciel produktu ma pewien poziom uprawnień i wiedzy na temat projektu. To samo mogłoby się zdarzyć, gdyby klient wyznaczył pracownika niższego poziomu, który został następnie obalony na późniejszym etapie, wymagając od ciebie prawie rozpoczęcia od nowa.

Dzięki za twój post. Zdaję sobie sprawę, że jest stary, ale myślę, że podniosłeś świetną sprawę i oto moje 0,02 $:

Problem 1: Wyznaczenie analityka na PO w twoim przypadku poważnie zwiera strukturę scrum. Dlaczego? Ponieważ tylko organizacja producentów może dokonywać oceny wartości, oceny zwrotu z inwestycji, ustalania priorytetów i decydujących wyborów, które wynikają z działalności firmy, a nie z technologii, a nawet znajomości produktu. Jestem pewien, że twój sr. analityk wykonał fantastyczną robotę naśladując PO, ale ostatecznie musiał odgadnąć potrzeby, wartości, wybory, które wynikną z Twojego PO. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . Jeśli Twój analityk nie otrzyma POA od klienta (mało prawdopodobne), nie będzie w stanie zaakceptować ani odrzucić niczego podczas przeglądu sprintu.

Czy to podejście może zadziałać? Tak, ale musiałby nastąpić całkowity transfer obowiązków, gdy klient był nieobecny. Szef twojego klienta musiałby zgodzić się na surogat i że żadne rozsądne decyzje nie zostaną cofnięte. Brzmi prawdopodobnie? Bardziej prawdopodobne, że dostaniesz tymczasowe zamówienie od organizacji klienta (co z pewnością nie jest bez jego wad!) Ale jeśli twój sr. analityk współpracował z tymczasowym PO, wszelkie niepoprawne decyzje byłyby podejmowane przez firmę, utrzymując w ten sposób role twojego zespołu w czystości.

Problem 2: „klient nie ma czasu na sprawdzenie”. Duży problem (i taki, na który ostatnio też wpadłem). Zamówienie musi być obecne, aby zaakceptować produkt. Nikt inny nie może „podpisać czeku”. Nieobecność PO oznacza niezadowolenie później, potencjalnie więcej przeróbek i utratę zaufania. Zasadniczo wyczuwam, że klient nie jest aktywnie zaangażowany w Twój projekt: nie ma czasu na codzienne wstawanie, nie ma czasu na odpowiadanie na pytania itp.

Problem 3: „kazano nam czekać, aż zespół projektowy skończy makietę”. A teraz są całkowicie wyłączone. Ludzie wykonujący makietę powinni należeć do zespołu interdyscyplinarnego. Nie mogę powiedzieć, czy jest to spowodowane brakiem zrozumienia zarządzania scrumem lub reakcją szokową na twoje trzecie wydanie.

Pytanie: Gdzie był w tym wszystkim twój mistrz scrum? SM zwykle uznaje niebezpieczeństwo konfliktu ról i braku uczestnictwa PO, które to przeszkody / niebezpieczeństwa należy usunąć.