Pracując u klienta, otrzymałem ostatnio pytanie od osoby z biznesu: “W jaki sposób my — czyli biznes — możemy wspierać Zespoły Deweloperskie?”. Jest to moim zdaniem bardzo dobre pytanie, bo łatwo mówić ogólnie o współpracy, a trudniej jest wskazać konkretnie, jak może to wyglądać w praktyce. W tym wpisie podzielę się kilkoma przykładami, co moim zdaniem może zrobić biznes, aby wesprzeć zespoły wytwarzające.
Zaraz zaraz — jaki biznes, jakie IT?
Zanim przejdę do konkretów, słowo komentarza. Istotny jest bowiem kontekst tego pytania. Firma, w której pracuje osoba, która zadała wspomniane pytanie, jest w trakcie zmian, mających na celu usprawnienie procesu wytwarzania produktów. Stąd, pomimo, iż odległość pomiędzy biznesem oraz IT jest systematycznie skracana, nadal jest wiele do zrobienia, aby przekształcić aktualne zespoły biznesowe i zespoły IT w multidyscyplinarne zespoły produktowe, odpowiedzialne za wyniki biznesowe konkretnych obszarów budowanych produktu.
Na potrzeby tego artykułu będę pisał “biznes”, przy czym robię to wyłącznie po to, aby wyraźnie i klarownie zaadresować pytanie, które otrzymałem. Osobiście bowiem, w swojej codziennej pracy, skupiam się na wspieraniu procesu tworzenia zespołów, które całościowo są odpowiedzialne za produkt, bez wymówek w stylu “biznes o tym zapomniał” czy “IT znowu nie dowiozło”.
Wracając więc do pierwotnego pytania – w jaki sposób biznes może wspierać Zespoły Deweloperskie? Oto pięć sposobów, które przychodzą mi do głowy w pierwszej kolejności.
Dostarcz wizję produktu i kontekst biznesowy
Brak znajomości wizji produktu oraz kontekstu biznesowego w Zespole Deweloperskim powoduje, że zespół pracuje jak dziecko we mgle. Potencjał drzemiący w różnorodnym Zespole Deweloperskim nie jest w pełni wykorzystywany, jeśli nie wiedzą oni istotnych rzeczy, takich jak przykładowo:
- Jakie problemy biznesowe chcemy rozwiązać?
- Kto jest użytkownikiem końcowym?
- Jakie firmy są naszą konkurencją?
- W jaki sposób budowany produkt będzie wykorzystywany na co dzień?
- Jak chcemy zarabiać na tym produkcie?
Kilka sprawdzonych przeze mnie sposobów dostarczania wizji produktu i kontekstu biznesowego, to:
- Wspólne budowanie wizji produktu przez biznes z Zespołem Deweloperskim, stosując na przykład technikę Product Vision Board
- Rozpoczynanie dyskusji na temat funkcjonalności produktu od odpowiedzi na pytanie, dlaczego to jest ważne w kontekście całego produktu
- Wracanie do wizji produktu podczas sesji doskonalenia Backlogu Produktu
- Wspominanie o wizji produktu podczas Przeglądów Sprintu, na zasadzie omówienia, jak właśnie wyprodukowany Przyrost ma się do całościowej wizji
- Wspólna, wysokopoziomowa i obejmująca całość produktu praca nad jego funkcjonalnościami, na przykład używając Story Mappingu
- Przedstawianie zespołowi szerszego kontekstu produktu, na przykładów dalszych planów rozwoju, aktualnie trwających kampanii marketingowych czy wyników analizy konkurencji
Dziel się informacją zwrotną
Im szybciej Zespół Deweloperski otrzyma informację zwrotną na temat produktu od biznesu (idealnie – od klienta końcowego), tym lepiej, ponieważ koszt ewentualnych zmian będzie niższy. Nie wszystko można przewidzieć na papierze, stąd możliwość empirycznego doświadczenia, jak działa konkretna funkcjonalność, może okazać się bardzo wartościową lekcją.
Czym jest w takim przypadku wspominana informacja zwrotna? Może przybierać różnorodną formę – od prostych sformułowań (“podoba mi się, jak to działa”), poprzez dzielenie się wątpliwościami (“czy jak będziemy mieć więcej produktów, to czy wyszukiwarka będzie nadal tak szybko działać”), nad dłuższych wywodach na temat tego, dlaczego konkretna funkcjonalność powinna (lub nie powinna) działać w konkretny sposób, kończąc.
Formalnym miejscem w Scrumie, podczas którego biznes dzieli się informacją zwrotną, jest Przegląd Sprintu. Zwykle spotkanie takie jest okazją do zobaczenia większego zestawu funkcjonalności oraz aktualnych zmian w produkcie. Przegląd Sprintu odbywa się — w zależności od długości Sprintu zespołu — najczęściej raz na tydzień lub raz na dwa tygodnie. Warto przy tej okazji wspomnieć, że biznes nie musi czekać na Przegląd Sprintu, żeby zobaczyć efekty pracy Zespołu Deweloperskiego. Oczywiście opcja ta zależy od dojrzałości Zespołu Deweloperskiego i jego umiejętności iteracyjnego oraz przyrostowego wytwarzania produktu w krótkich Sprintach.
Zaangażuj zespół w rozwiązywanie problemów
Bardzo często obserwuję następujący scenariusz: biznes spisuje precyzyjnie wymagania, dokładnie określa jak mają działać funkcjonalności a Zespół Deweloperski odpowiada wyłącznie za zamianę tych wymagań w działające oprogramowanie.
Podejście takie ma zasadnicze wady:
- Zespół jest sprowadzony do roli podwykonawcy i najemnika
- Potencjał kreatywny, jaki drzemie w Zespole Deweloperskim, nie jest wykorzystywany
- Zwykle wymagania opisują co zrealizować, a nie dlaczego, stąd praca wykonywana przez zespół staje się bez kontekstowa
Trudno oczekiwać, że Zespół Deweloperski będzie brał nie wiadomo jak dużą odpowiedzialność za produkt, skoro w tak niedużym stopniu są zaangażowani w proces jego kreacji. I nie chodzi mi tutaj o zmianę o 180 stopni, w której Zespół Deweloperski w całości rzuca się w obszar odkrywania produktu, a raczej sytuację, w której mają wpływ na to, jak konkretna potrzeba użytkownika zostanie zaspokojona.
Jak więc zaangażować zespół? Bardzo prosto: wystarczy od strony biznesowej pokazywać problem, wyzwanie, temat do rozgryzienia. Bez gotowych rozwiązań, wielostronicowych analizy, kilkudziesięciu gotowych kryteriów akceptacji. To wszystko możemy (i powinniśmy) wypracować z Zespołem Deweloperskim, zyskując wspólne zrozumienie tematu i zaangażowanie zespołu. Sensownym wydarzeniem w Scrumie, podczas którego mogą się toczyć takie rozmowy, są spotkania mające na celu doskonalenie Backlogu Produktu.
Dostarczaj liczby
Ciekawym aspektem wspierania Zespołów Deweloperskich, oprócz angażowania ich w kształtowanie rozwiązań, jest dostarczanie danych, które pomagają zbudować pełniejszy obraz produktu.
W jednym z zespołów, z którym pracowałem, zespół napisał licznik pokazujący na żywo zarabiane pieniądze przez produkt. W innym zespole na bieżąco wyświetlały się dane z Google Analitycs, m.in. aktualna liczba użytkowników na stronie. Takie informacje pokazują, że produkt żyje i ktoś z niego korzysta. Dają kontekst wykraczający poza precyzyjnie spisane wymagania biznesowe.
Innym aspektem znajomości przez zespół liczb jest możliwość dobrania technologii. Będziemy mieć 1 zapytanie do bazy na sekundę czy 10000? Chcemy aktualizować rekomendacje na stronie co odświeżenie strony czy raz na tydzień? Spodziewamy się mieć 100 tys klientów czy 3 miliony? Dobrze, jeśli takie pytania padają, bo mogą okazać się pomocne w uniknięciu problemów związanych z niedopasowaniem rozwiązania od strony technologicznej.
Bądź dostępny
Brzmi prozaicznie, jednak często spotykam się komentarzami Zespołów Deweloperskich, że “biznes nie ma dla nich czasu”. Może się to objawiać w osobie Właściciela Produktu, który ma tyle dodatkowych zadań na głowie, że brakuje mu czasu dla zespołu. Innym przykładem mogą być interesariusze, którzy nie docierają na Przeglądy Sprintu, bo “mają spotkanie za spotkaniem”.
Oczywiście temat nie jest czarno-biały. Być może Właściciel Produktu miałby więcej czasu, gdyby zespół aktywniej uczestniczył w rozmowach podczas sesji doskonalenia Backlogu Produktu. Z kolei gdyby podczas Przeglądu Sprintu zespół pokazywał działający produkt zamiast logów z bazy danych, być może wtedy interesariusze czuli by większą wartość ze swojej obecności na tego typu wydarzeniach.
Wracając do meritum – dostępność czasowa jest ważna, żeby zespół miał dostęp do osób, które są w stanie odpowiedzieć na ich pytania. Przy czym ważna jest jakość tej dostępności – 2 godziny dziennie z osobą, która ma wizję i jest decyzyjna są lepsze niż 8 godzin z osobą, która nie zna produktu i została wyznaczona do pełnienia tej roli z niezapowiedzianej łapanki korytarzowej.
Podsumowanie
Wsparcie Zespołów Deweloperskich przez osoby z biznesu może przybierać różną formę i jest to prostsze, niż mogłoby się wydawać. Nie ma szans na udaną zwinną współpracę, jeśli obie strony nie są zaangażowane. Zachęcam więc do eksperymentowania i pokonywania barier pomiędzy “biznesem” oraz “IT”, stosując jedna z powyższych rad lub implementując swoje własne.
Photo by Cory Schadt on Unsplash
