Wskazówka dla menedżerów produktu: połącz rejestry produktów z wizją produktu

Jednym z nieustannych wyzwań dla zespołu programistów Agile opartego na produktach jest mapowanie tego, co robią „w tej chwili”, do tego, co produkt ma ukształtować za, powiedzmy, 2-3 lata od teraz.

Nie chodzi o to, by zespoły nie wiedziały, nad czym pracują, ale bardziej o to, że mogą zbytnio koncentrować się na swoich codziennych zadaniach, niezmiennie podważając wrażliwość na wpływ swojej „obecnej” pracy na szerszy obraz . Decyzje lub wybory dokonane dzisiaj podczas realizacji mogą mieć duży wpływ na przyszłość, zwłaszcza gdy produkt ewoluuje.

Weźmy przykład z życia.

Byłem częścią zwinnego zespołu, który próbował wprowadzić usługę tłumaczenia tekstu dla treści witryny . Podjęto decyzję i wykorzystano narzędzie do tłumaczenia maszynowego innej firmy. Jednak w planie działania produktu w końcu wspomniano, że w przyszłości użytkownicy powinni być w stanie poprawić i zapewnić własne tłumaczenie kontekstowe, co oznaczało, że zdolność tłumaczenia powinna mieć sztuczną inteligencję , aby mogła uczyć się samodzielnie, na podstawie informacji zwrotnych.
Biorąc pod uwagę ten rozwój, dokonany wybór nie był trafny i dlatego wymagał sporego stopnia przeróbek, ponieważ ogólny obraz nie był powiązany z tym, co zwinny zespół miał za zadanie w sprincie.

Można argumentować, że zespoły mogą podjąć świadomy wysiłek, aby uzyskać te informacje, ale chodzi o to, dlaczego tych „długoterminowych” celów nie można uchwycić w istniejących zwinnych narzędziach i pulpitach nawigacyjnych?

Zespoły zwinne wykonują dobrze zdefiniowane i konkretne zadania w cyklu rozwojowym, ale czy to oznacza, że ​​musi to odbywać się kosztem obojętności na ewolucję produktu? Nie, nie sądzę.

Z tego, co wiem, nie ma szybkiego narzędzia lub frameworka, które popierałyby lub rekomendowałyby te informacje zwinnemu zespołowi w ich codziennym funkcjonowaniu, ale czy taki widok można stworzyć w widoku istniejącym? Warte spróbowania? Zobaczmy, jak możemy to zrobić.

Zaczniemy od najczęstszego artefaktu w agile – backlogu produktu.
Według Instytutu SCRUM backlog produktowy to lista rzeczy, które należy zrobić w projekcie. Te rzeczy mogą obejmować ulepszenia i/lub błędy. Lista numerowana nie jest pomocna, chyba że zespół wie, jaka jest struktura priorytetów elementów. W tym miejscu pojawia się Właściciel Produktu , który ponosi ogólną odpowiedzialność za współpracę z interesariuszami w celu uzyskania jasnych wymagań, rozwiązania współzależności i uzyskania listy priorytetów dla elementów zaległości produktu.

Możliwe, że w trakcie tego procesu większy i zależny element pracy zostanie dalej rozłożony na mniejsze części, aby zespół mógł go łatwo rozwijać. Te pozycje zaległości produktu są dzielone na mniejsze części i wykonywane w cyklach sprintu trwających od dwóch do czterech tygodni, odpowiadając na komponent „jak” rozwoju produktu.

Z drugiej strony, pozycje zaległości produktu są również mapowane na „prawdziwą północ” produktu, często określaną jako wizja produktu. Jest to pożądany stan produktu, który często jest osiągany dzięki wielu wydaniom wersji i jest ściśle powiązany z tym, czego chcą docelowi odbiorcy lub klienci, oraz wartością, jaką im przynosi.

Ten łańcuch elementów łączący zwinny zespół z klientami (w tym zaległości produktowe i wizję) można przedstawić jako:

Odległy związek między zwinnym zespołem a tym, czego potrzebuje klient…

Z powodu braku widoku, który wyraźnie łączy sprinty z wizją produktu, właściciele produktów często narażają się na zbytnie skupienie się na części „jak” i tracą z oczu większy i ważny cel „co”, co może prowadzić do błędnych priorytetów.

Podejście, które tutaj omawiam, polega na stworzeniu prostego, ale potężnego widoku, który łączy oba komponenty. Jest to znane jako Matryca Wizji Produktu (PVM). Celem jest powiązanie wizji produktu z szczegółowymi elementami rozwoju. Ta matryca staje się kluczowym czynnikiem w analizie postępów zespołu w zakresie rozwoju produktu. Służy również jako pulpit nawigacyjny produktu dla wyższego kierownictwa organizacji i informuje o możliwości osiągnięcia celów produktu.

Jak sama nazwa wskazuje, PVM to macierz, w której kolumny reprezentują przechwycone wymiary (od mikro do makro). Zrozummy PVM za pomocą aplikacji do zamawiania jedzenia, w której wizją jest zapewnienie użytkownikom doświadczeń związanych z jedzeniem, a punktem wyjścia jest zamawianie jedzenia. Przykładowa macierz wygląda tak:

Matryca wizji produktu może zawierać następujące pola:

• Wersja produktu: jest to wersja produktu, która jest oficjalnym kamieniem milowym w wydaniu i często jest tym, co otrzymuje klient.
• Element Big Rock: Jest to kategoria lub motyw, do którego należy również funkcja. Te elementy mogą być również obszarami długoterminowego zapotrzebowania na produkt w wizji produktu.
• Funkcja: jest to funkcja produktu, która jest opracowywana. Cecha może należeć do jednego lub wielu tematów (duże elementy skalne).
• Identyfikator sprintu: jest to numer sprintu, w którym opracowywana jest funkcja.
• Stan rozwoju: To pole wskazuje postęp prac rozwojowych (planowane, ukończone, ukończone, przetestowane i wydane).

Zauważ, że struktura macierzy jest tutaj orientacyjna. Można być bardziej kreatywnym w identyfikowaniu kolumn, które mogą uchwycić wizję produktu.

Zaletą tego podejścia jest wyraźny wgląd każdego członka zespołu w ogólne cele produktu. W przypadku ewoluującego produktu członkowie zespołu powinni lepiej rozumieć szerszy obraz. To nie tylko pozwala im skutecznie wnosić swój wkład, ale także umożliwia im wzięcie większej odpowiedzialności. Rezultatem jest bardziej skoncentrowany i adaptacyjny zespół, który zawsze trzyma rękę na pulsie swoich klientów i dostrzega różnicę, jaką mogą wnieść ich sprinty, przyczyniając się do wizji i ostatecznego sukcesu produktu.

Ucz się kursów zarządzania produktami online na najlepszych światowych uniwersytetach. Zdobywaj programy Masters, Executive PGP lub Advanced Certificate Programy, aby przyspieszyć swoją karierę.

Polecany program dla Ciebie: Program certyfikacji Design Thinking od Duke CE