Jak przyspieszyć wdrażanie nowych funkcjonalności do Twojego produktu?

Dodawanie nowych funkcji do systemu wydaje się być pozornie prostą sprawą. Poprostu, pojawia się pomysł i trzeba wszystko zaprogramować tak, żeby to działało. W rzeczywistości jednak bardzo rzadko jest tak, że pojawia się zapotrzebowanie na nową funkcję i prace programistyczne mogą się rozpocząć od zaraz. Jeśli od samego początku początku nie zaangażujemy zespołu do prac koncepcyjnych oraz określenia zakresu możemy skończyć z nieodpowiednio przygotowanym produktem, który nijak ma się w sosunku do naszego pierwotnego założenia.

Jeśli nie zaplanujemy odpowiednio naszej pracy, nie przygotujemy wszystkich elementów w sposób odpowiedni, to bardziej niż pewne, że doprowadzimy do frustracji programistów związanej z brakiem jasnych wytycznych dotyczących zadania. Frustracja ta najczęściej wynika z:

• Nieskończona ilość pytań i spotkań doprecyzowujących szczegóły
• Prace wydłużające się w nieskończoność
• Efekt końcowy nie spełniający kryteriów jakościowych
• Efekt końcowy nie wpisujących się we wstępne wyobrażenia i potrzeby

Oczywistym jest, że w obecnych czasach im szybciej dostarczymy nową funkcjonalność do naszej aplikacji, tym lepiej dla nas, ponieważ możemy wprowadzić coś innowacyjnego przed naszą konkurencją. Jeśli jednak nie zadbamy o to, żeby odpowiednio przygotować plan działania, cała nowa inicjatywa może okazać się fiaskiem i nie dostarczymy naszym klientom zamierzonego efektu w odpowiednim czasie lub w odpowiedniej jakości.

Żeby zapobiec takim sytuacjom musimy poświęcić odpowiednią ilość czasu na zebranie wytycznych dotyczących naszej nowej funkcji.

Więc jak to zrobić? Pozwoliłem sobie na to by podzielić ten proces na cztery kroki:

1. Pojawia się nowe zapotrzebowanie na funkcjonalność
   
   jeśli jest to coś co musimy zrobić, to osoba odpowiedzialna za projekt (Product Owner), powinien zacząć prace koncepcyjne. Dobrze byłoby, żeby określił wstępnie jakie są cele nowej funkcjonalności, gdzie ma się ona pojawić w aplikacji, jaki ma być wynik prac i jakie są kryteria akceptacyjne.
   
2. Konfrontacja pomysłu z zespołem
   
   w tym kroku PO powinien spotkać się z zespołem, aby porozmawiać o możliwościach. Jeśli w zespole poza programistami, znajdują się również designerzy i osoby odpowiedzialne za kontrolę jakości, to dobrze jest zebrać na takim spotkaniu wszystkich, aby poznać spojrzenie z każdej strony.
   
   Podczas takiego spotkania można przegadać odpowiednio możliwości systemu i poznać potencjalne punkty newralgiczne, które mogłby wydłużyć development. Dzięki spojrzeniu z innych stron jesteśmy w stanie dostosować lepiej opis wymagań do systemu w którym pracujemy. Na tym etapie można również wstępnie ocenić ile zajmie praca nad funkcją (i oczywiście to może się jeszcze zmienić w przyszłości, natomiast taka estymata rzuci nam światło na to ile czasu może nam zająć implementacja)
   
3. Rozpoczęcie pracy designera
   
   Po skonsultowaniu opcji z zespołem swoją prace może rozpocząć designer, który przygotowuje naszą aplikację od strony wizualnej. Nie będę opisywał całego procesu designerskiego i tego w jaki sposób praca ta powinna być włączona do harmonogramu prac, ponieważ temat ten świetnie adresuje Ola, która na blogu Czas na design opisuje wszelkie aspekty pracy designera w zespołach scrumowych (link do bloga w opisie)
   
4. Koniec prac designera - konfrontacja designu z developerami
   
   Gdy po pierwszym spotkaniu udało się dopasować wymagania do naszego systemu, designer miał czas na przygotowanie projektu od strony wizualnej, czas aby zespół developerski odpowiednio przygotował zadania do wykonania i oszacował ile dokładnie czasu zajmie przygotowanie poszczególnych kawałków, jak i całości zadania. Na tym etapie programiści mogą odpowiedni podzielić zadania, zdecydować jakie będą kryteria jakościowe i co dokładnie trzeba z ich strony wykonać aby doprowadzić do ukończenia prac

Po tak przepracowanym zadaniu wszelkie prace powinny iść gładko, a ewentualne rzeczy do doprecyzowania powinny być relatywnie małe. Jeśli chcemy żeby wszystko szło zawsze zgodnie z planem, to musimy zaangażować cały zespół i skorzystać z doświadczenia, umiejętności i kreatywności jego członków. Jeśli z tego nie skorzystamy, a PO będzie przydzielał zadania zgodnie ze swoim przeczuciem, ustalał że prace będą trwały zdefiniowany przez niego czas, to sytuacje o których mówiłem na początku mogą się zdarzać bardzo często. PO nie zna wszystkich zależności projektowych, nie jest w stanie przewidzieć co jest problematyczne dla systemu i musi korzystać z wiedzy domenowej innych, żeby jak najlepiej planować prace i wydania wersji.

Materiał dostępny również na Spotify: