Zwinne tworzenie voicebota – studium przypadku czy relacja z pola bitwy?

Krótka historia o tym jak stworzyć konwersacyjne narzędzie o transakcyjnej roli w nowoczesny sposób.

W pracy każdego Project Managera dobór odpowiedniej metodyki do prowadzenia projektu ma kluczowe znaczenie. I każdy, kto kiedykolwiek mierzył się z prowadzeniem projektu, zawsze stawał przed wyborem odpowiedniego sposobu jego prowadzenia – a wybór nie jest banalny. 

Agile i AI?

Każdy projekt związany z tworzeniem narzędzi AI jest inny, każdy ma inne założenia zarówno czasowe jak i te związane z jego zakresem, współpracujemy z różnymi zespołami wewnątrz własnej organizacji i po stronie klienta. A jeśli do tego mamy stworzyć nowoczesne konwersacyjne narzędzie transakcyjne i to w rekordowo krótkim czasie dodając do tego fakt, że jakość tworzonego rozwiązania musi stać na odpowiednim poziomie i nie będziemy szukać na tej płaszczyźnie dróg na skróty to ból głowy PM-a jest gwarantowany.
Co pozostaje nam w takiej sytuacji – oczywiście zwinność, zwinność i jeszcze raz AGILE. Szybki wgląd w wartości wynikające z Manifestu Agile, przegląd dostępnych metod zwinnych, oszacowanie czasu pozostałego do „GO LIVE”, zgrubny przegląd funkcjonalności i wybór pozostaje tylko jeden – będziemy robić SCRUM.

OK. Idea wydaje się bardzo dobra – wszak to jedna z lekkich metodyk z parasola AGILE. Dodatkowo jak twierdzi przewodnik po metodzie – jest łatwy do zrozumienia. Niestety pierwszą pułapkę twórcy metody zawarli już w kolejnej linijce podręcznika „jest trudny do opanowania”. Tak jest i co do tego nie można mieć wątpliwości. Scrum idealnie nadaje się do tego typu projektów, jest lekki, pozwala na szybką adaptację tworzonego rozwiązania do zmieniających się warunków, reagowania na pojawiające się nowe wyzwania oraz tworzenia rozwiązania, o którym na starcie wiemy stosunkowo niewiele w sposób iteracyjny, ale jest bardzo trudny.

Udało się nam? Zdecydowanie!

Na początek kilka założeń brzegowych. Klient zwrócił się do nas z zamówieniem na PoC (Proof of Concept) narzędzia voicebotowego z założeniami:

• Budujemy rozwiązanie głosowe. Na starcie projektu wiemy jednak tylko tyle, że ma obsłużyć ruch przychodzący i wychodzący (dialer) oraz ma dać użytkownikowi możliwość złożenia zamówienia z szerokiej palety produktów,

• Rozwiązanie ma być w maksymalnym stopniu przyjazne dla użytkownika końcowego,

• W kwestii jakości poprzeczka jest zawieszona naprawdę wysoko – wszak miernikiem naszej jakości jest żywy doradca handlowy, 

• Rozwiązanie musi być transakcyjne – jednak na etapie wdrożenia PoC nie zakładamy czasochłonnych integracji,

• Nie znamy finalnej koncepcji rozwiązania poza tym „co ma to zrobić”,
• Na budowę, testy, szkolenie i tworzenie dokumentacji mamy miesiąc. Tylko.

Zaczynamy!

Krok 1. 
Omawiamy z klientem koncepcję rozwiązania. Nie możemy poświęcić na warsztaty wiele czasu, jesteśmy rozproszeni – wspólne spotkanie stacjonarne nie wchodzi w grę – czas, czas i inne ograniczenia. Umawiamy spotkanie online. Materiał do przepracowania dzielimy na bloki tematyczne i ruszamy z niemal ośmiogodzinną sesją warsztatową, w której trakcie zmieniają się uczestnicy odpowiedzialni za wszystkie domeny związane z projektem. Pracujemy intensywnie: 10-minutowe przerwy na odświeżenie umysłu, zmiana części uczestników i kolejny blok do przepracowania – monitory się grzeją, notatniki puchną od treści. Udaje się nam porozmawiać z biznesem, sprzedażą, wsparciem sprzedaży, administratorami, „bezpiecznikami” – kilkanaście osób opowiada nam koncepcję procesu biznesowego ze swojej perspektywy. Storming zakończony! Mamy spisany koncept – proces zmapowany.  Ruszamy dalej.

Krok 2.
Budujemy zespół. Po stronie klienta angażujemy do współpracy sprzedaż, wsparcie sprzedaży i IT. Po naszej stronie zespół developerski: programiści, zespół inżynierów bazy wiedzy, w prace włącza się nawet nasz CTO (klient oczekuje kilku nowych funkcjonalności, które wymagają zaadresowania na wyższym poziomie). Team jest interdyscyplinarny. Ustalamy zasady współpracy – zbiórka poranna budzi początkowo opór… każdy jest zajęty, mamy złe doświadczenia ze zwinnym podejściem, zbiórki to „przepalanie czasu” i niepotrzebna komunikacja… standardowe mechanizmy obronne. Po tygodniu pracy nad rozwiązaniem dostrzegamy ich wartość. Feedback jest natychmiastowy, sprawdzamy kolejne prototypy, dodajemy nowe funkcjonalności na backendzie i na froncie, zmiany wprowadzamy na bieżąco, komunikacja mailowa ogranicza się do przesyłania załączników z dokumentacją. Przejrzystość – Inspekcja – Adaptacja… WOW TO DZIAŁA!

Forming – Storming – Norming – Performing, oczywiście w ekspresowym tempie przechodzimy przez wszystkie fazy – mamy różne charaktery i ich zetknięcie wywołuje wszystkie możliwe reakcje – od entuzjazmu po rezygnację i nieporozumienia – to całkowicie normalne. Opanowujemy to, bo mamy wspólny cel. Teraz już tylko wzrost.

Krok 3.
„Buduj przyrostowo od solidnych podstaw”. Osiem godzin poświęcone na warsztaty stormingowe i ustalenie procesu dla rozwiązania przynosi efekty. Trzymamy się celu, dodajemy kolejne funkcjonalności, sprawdzamy prototypy, reagujemy na zmiany i tak bez końca. Start – Daily – Zmiany – Testy – Zmiany i tak w kółko. Nasze rozwiązanie ewoluuje, ale jeszcze nie jest doskonałe, kilka rzeczy jednak trzeba zmienić, coś przestaje działać… Drzewo dialogowe ciągle nie jest według nas doskonałe, voicebot po raz kolejny źle odmienił liczebniki – horror… Przychodzi kryzys. Mamy dość!!! Dość ciągłego poprawiania i zmian, dość testów, dość zbiórek, dość siebie nawzajem, na głos naszego voicebota reagujemy złością. Prosimy o testy na zewnątrz – następnego dnia przychodzi feedback od zespołu sprzedażowego i kilku klientów zaangażowanych w testy – jest bardzo pozytywny. Rozwiązanie się podoba, działa i jest intuicyjne, jest kilka uwag co poprawić, ale jest naprawdę dobrze! Taka mała dawka pozytywnej energii daje nam potężnego „kopa” – dosłownie w kilka dni kończymy developerkę. W międzyczasie nasz CTO podrzuca kilka nowych funkcjonalności tak zupełnie poza projektem – ale inspirują nas one do przebudowania dialogu – robimy refaktoring kodu. Przechodzimy testy – kończy się tydzień – kończy się ostatni sprint. Dowieźliśmy! W poniedziałek idziemy na produkcję.

Krok 4.
Zadbaj o użytkownika końcowego! Ruszamy na produkcję – zwinne tworzenie voicebota jest niezwykłym doświadczeniem dla zespołu naszego klienta. Testując i budując z nami narzędzie, dostrzegają, z jak dużą zmianą w nowym zautomatyzowanym procesie będą musieli zmierzyć się klienci – nasi końcowi użytkownicy. Oswajanie nowej technologii nie jest łatwe – nie do końca wiadomo jak porozmawiać z maszyną. Dobrze poprowadzony onboarding jest jednym z najistotniejszych elementów całej układanki. Pomijając doświadczenie zespołu developerskiego w tworzeniu tego typu narzędzi oraz wysoką jakość stworzonego rozwiązania to właśnie ten etap projektu, w którym onboarding użytkowników na swoje barki wzięli przedstawiciele handlowi zadecyduje jak finalnie zostanie odebrany nasz voicebot.

Jak dotąd idzie nam naprawdę obiecująco… Team work = dream work. A TEAM mamy bardzo dobry.