Jak zapewnić stabilny proces Delivery

29 marca 2024

  • Autor: Aleksander Kononenko

  • Złożoność: łatwo

  • Czas: 6 min

Tworzenie produktu informatycznego to połączenie twórczej energii zespołu i wiedzy technicznej z umiejętnościami organizacyjnymi menedżera. Jednocześnie to, jak wygodny i efektywny będzie proces Delivery, w dużej mierze zależy od działań PM. W artykule szczegółowo omówimy etapy i na co dokładnie Product Manager powinien zwrócić maksymalną uwagę.

Jak wygląda Delivery Process

Delivery Process — zestaw działań, obejmujących tworzenie, debugowanie, testowanie i uruchomienie produktu z dalszym wsparciem i wprowadzeniem zmian, jeśli to konieczne.

Rozważmy proces Delivery, który składa się z 5 etapów:

  1. Definition of Requirements (Need Help);
  2. Delivery Definition;
  3. Development;
  4. Delivery Event;
  5. Maintenance (Feedback and Support).

W praktyce Delivery Process można powtarzać wielokrotnie, jeśli na produkt istnieje zapotrzebowanie. W tym celu ważne jest, aby na etapach Definition of requirements i Delivery Definition poprawnie zdefiniować dla kogo i jak to robimy – czyli sformułować podstawowe wymagania dla rozwiązania informatycznego. Głównymi dostawcami pomysłów są użytkownicy i interesariusze, zespół programistów, działy marketingu i sprzedaży.

Definition of requirements

Przede wszystkim należy znaleźć odpowiedź na pytanie: „Kto będzie wchodzić w interakcję z produktem i jakie korzyści odniesie z tego użytkownik?” Aplikacja może na przykład usprawnić procesy biznesowe, obniżyć koszty i przyspieszyć pracę. Prawidłowe zdefiniowanie potencjalnych użytkowników i ich potrzeb stanowi podstawę do opracowania planu technicznej realizacji projektu oraz strategii dalszej promocji. Szczególnie istotne dla MVP.

W przypadku istniejącej aplikacji tworzenie wymagań zwykle rozpoczyna się od analizy tego, co można poprawić w aktualnej wersji produktu IT: jakie feature dodać, a co pozostawić bez zmian lub całkowicie usunąć. Wszystko to odbywa się na podstawie danych uzyskanych po przetestowaniu aktualnej wersji oraz opinii użytkowników. Szukając wymagań dla rozwiązania IT, pamiętajmy o uwzględnieniu opinii i rekomendacji działów sprzedaży i marketingu – od tego często zależy skuteczność promocji i szybkość sprzedaży produktów.

Delivery Definition

Po zidentyfikowaniu potencjalnych użytkowników rozwiązania IT i wstępnym zrozumieniu, czym ono powinno być, rozpoczyna się Delivery Definition. Na tym etapie ustala się, czy realizacja projektu jest możliwa. Solution Architect sprawdza wszystkie żądania: czy na rynku jest coś podobnego, czy jest to coś nowego, czy można to zintegrować z aktualną wersją aplikacji itp.

Zasadniczo potencjalna trwałość produktu jest analizowana w oparciu o Delivery Definition:

  • określają podstawowe wymagania funkcjonalne i cele biznesowe;
  • przygotowują wstępny plan pracy;
  • obliczają przybliżony koszt i warunki.

W praktyce często zdarzają się sytuacje, gdy po Delivery Definition rozpoczęcie prac deweloperskich zostaje odroczone, koncepcja zostaje całkowicie zweryfikowana lub całkowicie porzucono projekt. Jeśli wszystko jest w porządku, planowane jest przejście do Development.

Development

Jak zapewnić stabilny proces Delivery

Proces rozwoju każdego zespołu budowany jest indywidualnie, jednak w dużej mierze zależy od stosowanej metodologii i technik zarządzania projektami. Na przykład Scrum narzuca obowiązkowe demo, które jest bardzo ważne dla Delivery. Jeśli chcesz, aby Twój produkt trafił na rynek w odpowiedniej formie, pamiętaj o podsumowaniu wyników pośrednich i, jeśli to konieczne, dokonaniu korekt.

Rozpoczęcie Development zwykle rozpoczyna się od stworzenia historii użytkownika. Następnie sporządzany jest jasny plan pracy z obowiązkowym wskazaniem głównych punktów kontrolnych — milestones, które dotyczą wyłącznie procesu rozwoju. Od tego momentu rozpoczyna się techniczne wdrożenie produktu od obowiązkowych dem pośrednich i po nich informacji zwrotnej, z dalszym przejściem do etapu Delivery Event.

Delivery Event

Na tym etapie tworzona jest ostateczna wersja demonstracyjna, prezentowana i testowana w celu uzyskania szerszej opinii. Faktem jest, że na etapie Development produkt najprawdopodobniej przetestuje niewielka liczba lojalnych użytkowników. W takich warunkach trudno o obiektywny obraz, dlatego istotne jest prawidłowe przeprowadzenie Delivery Event.

W tym procesie bardzo pomagają prezentacje wideo, organizacja szkoleń z obsługi produktu, wskazówki w samej aplikacji. Celem wszystkich tych działań jest uruchomienie jak najbardziej gotowego produktu w postaci MVP lub zaktualizowanej wersji istniejącej aplikacji dla wszystkich użytkowników i przejście do etapu Maintenance.

Maintenance

Delivery nie kończy się w momencie wprowadzenia produktu na rynek – trwa ciągły proces otrzymywania i analizowania informacji zwrotnych od użytkowników, a także informacji o wadach. Na podstawie tych danych dokonywane są korekty technicznej części produktu, strategii marketingowych i sprzedażowych.

Ogólnie rzecz biorąc, prawidłowy Delivery Process zawsze obejmuje przetwarzanie informacji zwrotnej na wszystkich etapach:

  • Tworząc demo, przetestuj pomysł i dostosuj go, jeśli to konieczne, aby uzyskać jak najdokładniejszy w danym momencie wynik.
  • Pamiętaj o monitorowaniu wydajności, aby Delivery nie było wadliwe na przykład z powodu problemów z serwerem.
  • Zwracaj szczególną uwagę na opinie użytkowników i zgłoszenia błędów aplikacji, ponieważ mogą one prowadzić do ciekawych pomysłów i ujawniać nowych dostawców wymagań.

W praktyce często zdarza się, że w odpowiednim czasie informacja zwrotna pozwala zidentyfikować krytyczną podatność lub rozszerzyć potencjał aplikacji. Najważniejsze jest to, żeby w procesie Delivery wszyscy uczestnicy jasno znali swoje role i rozumieli, co muszą zrobić na każdym etapie.

Uczestnicy w Delivery

Jak zapewnić stabilny proces Delivery

Z tabeli wynika, że ​​w idealnym przypadku na wszystkich etapach powinien uczestniczyć kierownik produktu, kierownik projektu i analityk biznesowy. W praktyce Product i Project Manager to często ta sama osoba, zwłaszcza przy małych projektach. Analityk biznesowy odgrywa główną rolę w określaniu wymagań dotyczących produktu i formułowaniu zadań technicznych dla zespołu programistów.

Stakeholder jest bazą do zbierania informacji, a bez Solution Architect trudno sobie wyobrazić kompetentne feasibility wykonalności na etapie Definition. O roli produktu można rozmawiać dużo, ale proces tworzenia w dużej mierze spoczywa „na barkach” Development Tech Lead. Na etapie Delivery Event warto podłączyć Support Lead, aby zapoznać się z funkcjonalnością gotowej aplikacji i jej logiką biznesową – przyda mu się to w przyszłości podczas Maintenance.

Jeśli mówimy o czasie trwania i stopniu ważności etapów, to zbiór wymagań z pewnością zajmie pierwsze miejsce. Ty i Twój zespół możecie stworzyć aplikację idealną z punktu widzenia logiki biznesowej i technicznej implementacji, jednak błąd w zdefiniowaniu tej samej grupy docelowej i jej ból mogą zniweczyć wszelkie wysiłki – na produkt po prostu nie będzie popytu. W rezultacie firma straci czas, pieniądze i prawdopodobnie straci reputację. Dlatego doświadczeni Product Managers radzą zwrócić maksymalną uwagę na wymagania przyszłej aplikacji.

Jak skonfigurować proces Delivery

Jak zapewnić stabilny proces Delivery

Zasadniczo w Delivery Process uczestniczą 2 zespoły — produktowy i rozwojowy. Konwencjonalnie mogą być od siebie niezależne, jednak w praktyce często nakładają się na siebie na etapie określania wymagań funkcjonalnych i opracowywania specyfikacji technicznych. Product i Project Managers są głównymi ogniwami łączącymi pomiędzy nimi, a organizacją procesów pracy w ich obszarze odpowiedzialności.

Co wziąć pod uwagę na początku projektu

  • Omów format interakcji między uczestnikami, tak aby wszyscy czuli się komfortowo.
  • Uzgodnijcie, jaki powinien być efekt pracy, aby nie było przykrych niespodzianek typu „nie omawialiśmy tego”, „nie było tego w zadaniu technicznym”.
  • Omów pokazywanie wczesnych prototypów: w jakiej formie, jak często.
  • Wyjaśnij terminologię i obszary odpowiedzialności, aby zmniejszyć chaos w pracy.
  • Poznaj osobiście prawdziwych ludzi na danym stanowisku i w razie potrzeby omów z każdym listę zobowiązań – zmniejszy to odsetek nieporozumień.

Na co zwrócić uwagę na etapie wdrożenia

  • Zrób listę możliwych zagrożeń i działań mających na celu ich wyeliminowanie. Na przykład, jak zapobiegać zakłóceniom terminów.
  • Zorganizuj wczesne informowanie uczestników na temat ważnych kwestii.
  • Zdefiniuj działania obowiązkowe i opcjonalne, ich priorytet i częstotliwość.

Jak postępować zgodnie z procesem Delivery

Jak zapewnić stabilny proces Delivery

Załóżmy, że nawiązałeś współpracę zespołową i interakcję z interesariuszami, przeszedłeś wszystkie etapy i pomyślnie uruchomiłeś projekt. Świetnie – teraz trzeba to cały czas powtarzać. Takie podejście pozwoli uzyskać oczekiwane rezultaty, poprawić jakość wykonywanej pracy i obniżyć koszty wsparcia procesu.

Bardzo ważnym punktem skutecznej pracy menedżera jest dopełnienie formalności:

  • Zbieraj określone artefakty po ukończeniu dowolnego etapu, na przykład zaprojektowane feature.
  • Zaplanuj wszystkie spotkania/wydarzenia.
  • Bądź świadomy zmian osób na stanowiskach w projekcie, od razu omawiaj listę zobowiązań z tymi, którzy przybyli.

Listę zawsze można rozszerzyć, jednak wdrożenie nawet tych punktów znacznie upraszcza pracę PM i jego interakcję z zespołem. Przestrzegając formalności unikniesz chaosu w projekcie i zmniejszysz ryzyko.

Zamiast wniosków

Stabilny Delivery Process jest kluczem do pomyślnego wprowadzenia na rynek produktu, który ma dużą szansę zyskać popularność na rynku. Najważniejsze w tym procesie jest prawidłowe zdefiniowanie celów biznesowych, wymagań aplikacji i prawidłowe budowanie interakcji uczestników na wszystkich etapach. W tym celu istotny jest dobór odpowiedniego zespołu specjalistów, zdefiniowanie wśród nich ról i obszarów odpowiedzialności, kontrola priorytetowości zadań i postępu prac. Pamiętaj też, że powtarzalność i dotrzymanie formalności to klucz do lepszych wyników.

Aleksander Kononenko

Marketingowy copywriter z wykształceniem technicznym oraz doświadczeniem w sprzedaży i marketingu. Zawsze poszukuje najlepszych rozwiązań do osiągnięcia swoich celów i uważa, że tworzenie tekstów to symbioza sztuki i nauki.