Zarządzanie budową portalu internetowego (z Rebeccą Germond z FCV Interactive)

Przeczytaj transkrypcję:

Próbujemy transkrybować nasze podcasty za pomocą programu komputerowego. Wybaczcie wszelkie literówki, ponieważ bot nie jest poprawny w 100% przypadków.

Ben Aston:

Witamy w podcaście DPM, w którym wykraczamy poza teorię, aby przekazywać eksperckie porady kierownikom projektów prowadzącym lepsze projekty cyfrowe. Dziękuję za dołączenie. Nazywam się Ben Aston, jestem założycielem The Digital Project Manager.

Potrzeby klientów dojrzewają, a rola agencji cyfrowych również się zmienia i ewoluuje. Ponieważ proces projektowania i budowy stron internetowych stał się bardziej zunifikowany, rośnie zapotrzebowanie na agencje, które mogą być czymś więcej niż tylko partnerem od strony internetowej — mogą być także partnerem strategicznym i technicznym, budującym nie tylko strony, kampanie i strony docelowe. W dzisiejszym podcaście przyjrzymy się bliżej portalom: czym są, jak się je buduje oraz jakie wnioski i wyciągnięte lekcje warto znać przed rozpoczęciem takiego projektu. Słuchaj dalej, jeśli chcesz dowiedzieć się więcej o ewolucji agencji cyfrowych i podejściu do rozwoju produktu w relacjach z klientami.

Dziś dołącza do mnie Rebecca Germond. Rebecca jest dyrektorką ds. obsługi klienta w FCV. Ma solidne podstawy w zarządzaniu projektami i komunikacji medialnej. Rebecca to osoba, którą zatrudniłem kilka lat temu. Pamiętam twoją rozmowę kwalifikacyjną, kiedy zaprosiłem cię do pokoju i pomyślałem: tak, jasne, zatrudnię tę dziewczynę. Nie pamiętam dokładnie, o co cię pytałem, ale uznałem: nie muszę nawet przeprowadzać rozmowy. Zatrudniam cię. Pamiętasz tę rozmowę?

Rebecca Germond:

Pamiętam tę rozmowę. Czułam się, jakbym była przesłuchiwana. Nie, tylko żartuję. Pamiętam ją bardzo dobrze, bo pamiętam widok z biura i myślę, że to właśnie on przekonał mnie do FCV — oczywiście oprócz naszej rozmowy.

Ben Aston:

To nie byłem ja. To był widok.

Rebecca Germond:

Tak.

Ben Aston:

Rebecca, dla tych, którzy zastanawiają się, czym zajmujesz się na co dzień: na czym polega rola dyrektorki ds. obsługi klienta? To zarządzanie projektami? Zarządzanie klientami? Co to obecnie oznacza dla ciebie?

Rebecca Germond:

Tak, to trochę jedno i drugie, a dodatkowo zarządzanie samym zespołem kierowników projektów, co jest świetne. To dla mnie nowa rola od mniej więcej roku. Nie angażuję się już tak bardzo w szczegóły projektów. Jest kilka projektów, z których nie zrezygnuję, ale przede wszystkim pracuję bezpośrednio z kierownikami projektów i upewniam się, że mogą dostarczać rezultaty oraz otrzymują potrzebne wsparcie. Zarządzam również większością naszych klientów, więc mam z nimi dość bliskie relacje na poziomie obsługi kont. Właściwie zaczynałam w obsłudze klientów, zanim zostałam producentką i kierowniczką projektów, więc to trochę powrót do korzeni, co jest fajne.

Ben Aston:

Świetnie. Dla osób zainteresowanych rolą polegającą na zarządzaniu zespołem kierowników projektów: jak wygląda twój dzień? Jak nimi zarządzasz? Nie możesz cały czas zagłębiać się w szczegóły wszystkich ich projektów. Co właściwie robisz, kiedy się z nimi kontaktujesz?

Rebecca Germond:

To dobre pytanie. W większości po prostu przeglądam wiele prac lub rezultatów, które chcą wysłać. Na przykład przekazuję im informacje zwrotne na temat opisu prac albo harmonogramu. Jeśli pojawiają się eskalacje, angażuję się lub pomagam kierownikom projektów ustalić, jak odpowiedzieć na trudne sytuacje. Spotykam się z nimi indywidualnie co tydzień, ale kontaktuję się też przez Slacka i upewniam się, że każdy otrzymuje codzienne wsparcie. Czasami dołączam do ich ważniejszych spotkań z klientami. To trochę tak wygląda.

Jestem również mocno zaangażowana w proces rozwoju biznesu w FCV. Na co dzień zajmuję się też tym, ile faktycznie zafakturujemy klientom i czy wystarczająco dobrze śledzimy proces zarządzania zmianami. Dochodzi do tego wiele innych codziennych spraw związanych z pracą z kierownikami projektów.

Ben Aston:

Opowiedz nam trochę o swojej historii. Zajmowałaś się obsługą klientów. Wiem też, że zaczynałaś karierę w Ministerstwie Pracy. Jak przeszłaś od Ministerstwa Pracy do agencji cyfrowej, obsługi klientów i zarządzania projektami? Jak to wyglądało?

Rebecca Germond:

Kiedy byłam w szkole, moja ciocia prowadziła agencję pracy tymczasowej. Pomagała mi znajdować różne zajęcia, kiedy szukałam dla siebie właściwego miejsca. Wiedziałam, że chcę pracować w agencji. Trafiłam do Ministerstwa Pracy. Była to raczej praca administracyjna dla rządu, ale była całkiem ciekawa. Pozwoliła mi poznać wiele mechanizmów działania administracji, co później pomogło mi w karierze, ponieważ większość projektów, nad którymi pracowałam w pierwszej agencji, a także wiele projektów, nad którymi pracuję teraz w FCV, jest związana z administracją publiczną. To było pomocne.

Pewnego razu ciocia znalazła mi miejsce w agencji Manifest Communications w Toronto. Miałam pracować tylko dwa tygodnie przy obsłudze recepcji, podczas gdy jedna z osób była na urlopie, ale zaproponowano mi staż, właśnie o który się starałam. Pracowałam tam trzy miesiące, a potem mnie zatrudniono i zostałam na cztery lata. Na początku byłam specjalistką ds. obsługi klienta, więc zarządzałam klientami, a nie tyle projektami cyfrowymi. Stopniowo zaczęliśmy się w tym kierunku rozwijać. Po pierwszym roku zostałam producentką. Projekty były wtedy mniej więcej w 60% cyfrowe, ale pracowałam też przy radiu, transmisjach i materiałach drukowanych, co było bardzo ciekawe.

Ben Aston:

Dobrze. Jesteśmy jeszcze w pierwszym kwartale roku. Patrząc z perspektywy twojej kariery albo rozwoju zawodowego — dziś rozmawiamy o portalach i o tym, że są pewną ewolucją — czy wyznaczyłaś sobie jakieś cele na ten rok?

Rebecca Germond:

Właściwie to zabawne. W tym roku nie chcę mieć żadnych konkretnych celów zawodowych. Brzmi dziwnie. To mój ostatni rok po dwudziestce, więc naprawdę chcę po prostu żyć jak przedstawicielka pokolenia millenialsów. Mam cele związane z podróżami. To jest teraz dla mnie najważniejsze. Jeśli chodzi o karierę, bardzo podobała mi się praca nad tym projektem portalu. Przekształciliśmy go w produkt i stale publikujemy kolejne wersje, próbując go rozwijać. Uważam, że to świetne. Chciałabym robić więcej podobnych rzeczy.

Ben Aston:

Świetnie. Rozmawialiśmy trochę o twojej roli i tym, czym się zajmujesz, ale z jakimi wyzwaniami mierzysz się teraz? Jaki jest twój największy codzienny problem, który próbujesz rozwiązać — szczególnie w związku z konkretnym projektem?

Rebecca Germond:

Myślę, że na co dzień jestem przyzwyczajona do pilnowania zespołu projektowego, jeśli wiesz, co mam na myśli. Wszyscy kierownicy projektów muszą radzić sobie z wieloma ego i różnymi typami osobowości. Teraz, kiedy skala jest większa, chodzi o to, że mniej zajmuję się pojedynczymi projektami, a cała organizacja ma różne potrzeby i priorytety. Trzeba to wszystko równoważyć, jednocześnie upewniając się, że kierownicy projektów mają wszystko, czego potrzebują, bo to bardzo ważne. To bywa trudne. Czasem angażujesz się też w rzeczy, które nie wydają się szczególnie ważne, na przykład sprawy administracyjne. Nie wiem. Samo pilnowanie własnej listy zadań jest ostatnio wyzwaniem.

Ben Aston:

Jak śledzisz wszystkie sprawy? Jak wygląda twoja lista zadań? Masz jakiś system?

Rebecca Germond:

Większość listy zadań prowadzę w Evernote, ale właśnie dodaliśmy nową integrację ze Slackiem o nazwie Workast. Można w niej prowadzić listę zadań w konkretnym kanale Slacka i przypisywać zadania odpowiednim osobom. Można też po prostu zapisać sobie notatkę w Slacku, a lista zadań jest dostępna w jednym miejscu i przypomina o terminach. Dopiero zaczynamy z tego korzystać, ale jak dotąd jest całkiem interesująca.

Ben Aston:

To się nazywa Workast?

Rebecca Germond:

Workast, W-O-R-K-A-S-T.

Ben Aston:

Workast, dobrze. Dość zabawna nazwa.

Rebecca Germond:

Zdecydowanie. Jak dotąd wszystko działa dobrze. Problem polega na tym, że do listy zadań docierasz dopiero przed 9:00 albo po 17:00. Tak to odczuwam, ponieważ około 70% mojego dnia zajmują spotkania telefoniczne albo odpowiadanie na wiadomości e-mail i Slacku, co bardzo utrudnia produktywność.

Ben Aston:

Co jeszcze znajduje się w twoim zestawie narzędzi kierownika projektu? Masz system listy zadań, który pomaga ci ustalać priorytety najważniejszych spraw. Co jeszcze wykorzystujesz? Jak zarządzasz projektami?

Rebecca Germond:

Mam całkiem sporo narzędzi. W ciągu ostatnich kilku lat kilka razy zmienialiśmy podejście, ale teraz jestem zadowolona z naszego zestawu. Jak wspomniałam, korzystam z Evernote. Obecnie bardzo intensywnie używamy Jira. Wszyscy — w tym osoby od doświadczenia użytkownika, projektanci i nasi klienci — pracują w Jira, co nam ułatwia pracę, ponieważ wszystko znajduje się przynajmniej w jednym miejscu i możemy śledzić zgłoszenia. Korzystamy ze Slacka i używam go praktycznie bez przerwy.

Testujemy Microsoft Teams zamiast Skype for Business. Używamy go jako linii konferencyjnej podczas spotkań z klientami. Jak dotąd działa całkiem dobrze. Korzystam z Merlina do planowania projektów. Wcześniej używaliśmy MS Project, ale uważam, że wykorzystywaliśmy tylko 15% jego możliwości. Mamy kilka licencji MS Project na wszelki wypadek, gdyby klient ich potrzebował. Spotify zdecydowanie należy do mojego zestawu narzędzi. Potrzebuję go. Oczywiście korzystam też z Outlooka, choć poczta elektroniczna jest zmorą mojego życia.

Ben Aston:

Poza Workastem, czy ostatnio trafiłaś na inne narzędzia albo rozwiązania, które zrewolucjonizowały sposób zarządzania projektami?

Rebecca Germond:

Niespecjalnie. Myślę, że kluczowe było to, jak zaczęliśmy korzystać z Jiry i integracji w naszym kanale Slacka. Jeśli zgłoszenie zostanie zaktualizowane, zmieni się jego status albo klient doda komentarz, Jira oczywiście wysyła około 40 wiadomości e-mail na minutę. Do kanału Slacka trafiają tylko najważniejsze informacje, więc wiemy, kiedy ktoś skomentował zgłoszenie. To bardzo ułatwiło pracę, ponieważ nikt nie czyta wiadomości e-mail z Jiry. MS Teams jest naprawdę przydatny, bo większość naszych klientów nie chciała korzystać z wideo, ale po przejściu na MS Teams wiele osób zaczęło go używać.

Ben Aston:

Świetnie. Porozmawiajmy o twoim artykule i studium przypadku — pierwszym, jakie kiedykolwiek opublikowałaś. Gratulacje, Rebecca.

Rebecca Germond:

Dziękuję.

Ben Aston:

Porozmawiajmy o portalu. Czy portal to po prostu strona internetowa, czy coś innego? Jeśli coś innego, to dlaczego i czym się różni?

Rebecca Germond:

Moim zdaniem portale są dość złożone, ponieważ zazwyczaj są dopasowane do wielu różnych użytkowników, a każda z tych grup może mieć wiele działań, funkcji i ścieżek. W przypadku tego konkretnego portalu musieliśmy uwzględnić trzy różne poziomy użytkowników, a wpływ jednego poziomu na pozostałe początkowo zdecydowanie niedoszacowaliśmy. Ogólnie portale mogą być skomplikowane ze względu na wszystkie zależności i mechanizmy, których nie ma na zwykłej stronie internetowej, którą po prostu otwierasz i przeglądasz stronę główną.

Ben Aston:

Mówimy więc o czymś, co oferuje bogatszą interakcję i funkcje zależne od roli, włączane albo wyłączane w zależności od tego, co robisz w portalu.

Rebecca Germond:

Dokładnie. W przypadku naszego portalu bez logowania niewiele można zrobić na stronie głównej. Istnieją pewne bariery i rozpoczęcie korzystania z portalu przez nowych klientów nie jest szczególnie łatwe. Trzeba uwzględnić wiele rzeczy, które nie dotyczą zwykłej strony internetowej.

Ben Aston:

Interesujące. Nie mówimy więc abstrakcyjnie — przedstaw nam krótki opis funkcji tego portalu.

Rebecca Germond:

Nasz klient jest sprzedawcą elektroniki i ma klientów biznesowych, którzy zamawiają produkty hurtowo. Zanim powstał portal, klienci musieli dzwonić do opiekuna konta i składać zamówienia bardzo, bardzo ręcznie. Wszyscy mieli tego dość. Klienci również, bo dziś nikt nie chce już podnosić telefonu. Potrzebowali portalu, do którego można się zalogować, zobaczyć przypisany katalog produktów i kupować wyłącznie te produkty. Do tego dochodzi skomplikowany mechanizm rabatowy. Ponieważ klienci kupują hurtowo, otrzymują dopasowane rabaty zależne od ilości zakupów i rodzaju działalności.

Mamy również koszyk i proces składania zamówienia. Na pulpicie użytkownicy widzą najczęściej zamawiane produkty, otwarte zamówienia oraz wszystko, co zostało zamówione w ciągu ostatnich 30 dni. Pulpit zawiera kilka przydatnych narzędzi pomagających zorientować się, co dzieje się w ich obszarze portalu.

Istnieje też kilka poziomów użytkowników. Większość klientów może wejść do portalu i złożyć zamówienie, ale w zależności od organizacji musi je zatwierdzić administrator klienta. Przed realizacją zamówienia ktoś musi móc je zaakceptować albo poinformować użytkownika, że przekroczył budżet i zamówienie nie może zostać zrealizowane. Jest tu wiele zależności.

Ben Aston:

Czyli jeśli jestem dużą organizacją, na przykład firmą Telus, i chcę zamówić 2000 nowych monitorów, loguję się do systemu, kupuję monitory, a następnie przechodzę przez proces zatwierdzenia zamówienia i mogę je śledzić.

Rebecca Germond:

Tak, dokładnie.

Ben Aston:

To handel elektroniczny na dużą skalę.

Rebecca Germond:

Dokładnie.

Ben Aston:

W artykule wspomniałaś o interesujących technologiach. Czy możesz krótko opisać stos technologiczny, architekturę i rozwiązanie — jak właściwie zbudowaliście ten portal? Co było w nim interesującego?

Rebecca Germond:

Nasi programiści mogliby opowiedzieć o tym dokładniej, ale mogę przedstawić ogólny zarys.

Ben Aston:

Wersję dla kierownika projektu.

Rebecca Germond:

Używamy .NET Core do obsługi mikrousług, a następnie Reacta po stronie interfejsu, aby udostępniać funkcje tych mikrousług. Mikrousługi są po prostu punktami końcowymi, więc można je wykorzystywać w dowolny sposób. Na przykład pobieramy dane o liczbie zamówień. Ponieważ mamy te informacje, możemy wyświetlić je na pulpicie albo przetwarzać na wiele różnych sposobów. To bardzo ciekawe. React jest oczywiście ekscytujący dla naszych programistów interfejsu i lubią z nim pracować. Stworzyliśmy bibliotekę komponentów, którą można było wykorzystywać w różnych obszarach strony, dzięki czemu nie trzeba było za każdym razem budować tych samych elementów od początku. Chcieliśmy też zachować spójny wygląd całej strony i zgodność z marką klienta, aby portal nie różnił się zbytnio od jego strony konsumenckiej.

Ben Aston:

Nie ma systemu zarządzania treścią. Jak wyglądał ten proces? W ramach .NET stworzyliście funkcje umożliwiające sprzedawcy dodawanie i edytowanie produktów. Czy po tej stronie istnieje jakiś system zarządzania treścią?

Rebecca Germond:

Nie. Całe informacje o produktach pochodzą z interfejsu API udostępnionego przez klienta, którego używa on na swoich stronach konsumenckich. Informacje są stale aktualizowane. Mamy skrypt, który uruchamia się raz dziennie i upewnia się, że pobieramy najnowsze ceny oraz aktualne dane o produktach i ich specyfikacjach. Dodawanie nowego produktu jest więc całkowicie zautomatyzowane, co jest bardzo wygodne.

Ben Aston:

To ciekawe. Był to projekt rozwoju produktu — budowa portalu. Jak zaplanowaliście projekt i rozwój produktu? Jaki proces zastosowaliście?

Rebecca Germond:

Zdecydowanie przyjęliśmy podejście MVP, czyli minimalnego produktu opłacalnego. Zadziałało ono i nie zadziałało, ponieważ w miarę postępu projektu zakres MVP stale się powiększał. W końcu wcale nie był minimalny. Na początku, gdy szczegółowo planowaliśmy harmonogram i wycenę, podejście MVP bardzo nam pomogło. Mieliśmy dość jasno określony rejestr prac, więc od razu przeszliśmy do sprintów programistycznych. Nie poświęciliśmy zbyt dużo czasu na zbieranie wymagań. Omawialiśmy wymagania podczas spotkania planowania sprintu dotyczącego funkcji, które chcieliśmy ukończyć w danym sprincie.

Ben Aston:

Czy dla MVP istniał budżet i termin? Mieliście rejestr elementów do zbudowania. Jak ustalaliście, co mieści się w budżecie, a co go przekracza? Kiedy zdefiniowaliście budżet?

Rebecca Germond:

To było trudne. Największym problemem pracy zwinnej w agencji jest to, że klienci chcą znać cenę wszystkiego. Prawdziwy model zwinny może polegać na koszcie za sprint. Pod koniec sprintu funkcja może nie być jeszcze kompletna. Próbowaliśmy więc wyceniać funkcje osobno, aby klient dokładnie wiedział, ile kosztuje każda z nich i mógł sam ustalać priorytety. Niektóre funkcje zależały od innych. Kiedy ustaliliśmy, co dokładnie wchodzi do MVP, określiliśmy koszt i zakres prac koniecznych do spełnienia wszystkich zależności. Następnie pogrupowaliśmy elementy, aby można było realizować je w modelu sprintowym. Mieliśmy pięć miesięcy na ukończenie projektu i miesiąc testów akceptacyjnych użytkownika na końcu. Dwa tygodnie przeznaczyliśmy na konfigurację środowiska. Łącznie mieliśmy około sześciu lub siedmiu sprintów.

Ben Aston:

W studium przypadku wspomniałaś, że poważnie niedoszacowaliście niektórych obowiązkowych funkcji, ale powiedziałaś, że to właśnie uczyniło projekt interesującym. Czy dobrze rozumiem, że niedoszacowaliście niektórych funkcji wycenianych osobno?

Rebecca Germond:

Najbardziej niedoszacowaliśmy budowy katalogu i późniejszego zastosowania rabatów. Początkowo myśleliśmy: „po prostu dodamy rabat do konkretnych produktów”. Kiedy zagłębiliśmy się w API i różne kategorie produktów, okazało się, że każda z nich ma wiele cech. Połączenie tej logiki z rabatami stało się bardzo skomplikowane. Dodatkowo klient chciał wykluczać niektóre produkty. Na przykład na produktach Apple nie miał dużej marży, więc nie chciał ich przeceniać. Musieliśmy dopilnować, aby po wykluczeniu marki Apple wyświetlane były tylko produkty spełniające określone kryteria, z pominięciem Apple, a następnie aby został zastosowany rabat. Stało się to naprawdę zagmatwane.

Niestety był to projekt rozliczany według stałej ceny. Odzyskanie czasu i kosztów było możliwe dzięki wielu zleceniom zmian dodawanym po drodze, także zmianom dotyczącym funkcji ujętych w pierwotnej wycenie. Staraliśmy się dobrze prowadzić proces zarządzania zmianami. Kiedy sami niedoszacujemy pracy, bardzo trudno powiedzieć klientowi: „Przepraszamy, nie wykonaliśmy właściwie swojej pracy”.

Ben Aston:

Część problemu wynikała jednak z tego, że wymagania — zwłaszcza dotyczące złożoności rabatów — nie były od początku jasne, prawda?

Rebecca Germond:

Dokładnie. Początkowo mechanizm rabatowy miał być znacznie prostszy. Kiedy zaczęliśmy analizować szczegóły, okazało się, że jest dużo bardziej złożony.

Ben Aston:

Tak często wygląda to w projektach zwinnych. Sens podejścia zwinnego polega na tym, że pasuje ono do sytuacji, w których sprawy nie są całkowicie jednoznaczne, ale model kosztowy musi to odzwierciedlać. Tutaj mieliście stałą cenę i niejasne wymagania. Jak zaplanowałabyś ten projekt inaczej, mając dzisiejszą wiedzę?

Rebecca Germond:

Myślę, że dobrze poradziliśmy sobie z wymaganiami, które mieliśmy. Chciałabym jednak spróbować z tym klientem przejść na model kosztu za sprint. Mamy teraz świetną relację. Jest właściwie przedłużeniem naszego zespołu, co bardzo pomaga. Nie udało nam się jeszcze całkowicie przejść na taki model, ale mamy dużą elastyczność w zakresie harmonogramu, a klient jest bardzo wyrozumiały. Gdybyśmy zaczynali od nowa, być może na początku przedstawilibyśmy przybliżony przedział cenowy, ponieważ klient potrzebuje uzyskać zgodę na określoną kwotę.

Jeśli przedstawilibyśmy dobry przedział, a następnie w każdym sprincie dokładniej określali zakres prac i podawali cenę zależną od liczby potrzebnych osób oraz planowanych rezultatów, mogłoby to działać lepiej. Poza tym niewiele zmieniłabym w sposobie pracy zespołu. Podobało mi się, że byliśmy niewielkim zespołem. Trudniej jest, gdy po stronie klienta zaangażowanych jest wiele osób. Tutaj był właściwie tylko on i odpowiedni interesariusz potrzebny przy danej funkcji. To było bardzo dobre.

Ben Aston:

Mówisz o małym zespole i to było jednym z elementów, które dobrze zadziałały. W artykule wspomniałaś o hybrydowym podejściu zwinnym do tworzenia i projektowania. Jak wyglądał zespół? Jak sprawiliście, że współpraca projektantów i programistów działała?

Rebecca Germond:

To trudne. W agencji pełne podejście zwinne jest naprawdę trudne, ponieważ klienci nie zawsze chcą płacić za cały zespół przez pięć miesięcy. Chcą wiedzieć, ile kosztuje funkcja. Jeśli pracujesz wewnątrz organizacji i tworzysz własny produkt, mając osoby poświęcające mu osiem godzin dziennie przez pięć dni w tygodniu, sytuacja wygląda inaczej. Przy wielu projektach bardzo trudno pracować zwinnie.

Nasz zespół składał się z dwóch programistów zaplecza, dwóch programistów interfejsu, osoby zajmującej się doświadczeniem użytkownika w połowie etatu, projektanta pojawiającego się od czasu do czasu w celu oceny koncepcji i funkcji oraz jednej osoby odpowiedzialnej za zapewnienie jakości, również zwykle pracującej podczas sprintu w połowie wymiaru. Nie mieliśmy analityka biznesowego i nadal uważam, że było to w porządku. Wiedzieliśmy, co budujemy. Analityk nie byłby w stanie wyjaśnić szczegółów API klienta ani pomóc w procesie wyceny. Nie angażowaliśmy też stratega, ponieważ produkt był jasno określony, klient miał dobrze zdefiniowaną wizję MVP, a za projektem stał silny przypadek użycia. Oczywiście w zespole byłam też ja.

Ponieważ zaczynaliśmy od zera, nie mieliśmy gotowych komponentów. Mieliśmy jedynie wytyczne marki i funkcje, które trzeba było zbudować. Projektanci i osoby od doświadczenia użytkownika pracowali o sprint do przodu względem zespołu programistów. W prawdziwym podejściu zwinnym zwykle dostarcza się funkcję wspólnie, ale klient wcześniej nie widział żadnego naszego rozwiązania, więc potrzebowaliśmy przewagi czasowej, aby upewnić się, że pod względem wyglądu i stylu zmierzamy we właściwym kierunku.

W pierwszym sprincie projektanci i osoby od doświadczenia użytkownika pracowali z wyprzedzeniem nad konfiguracją środowiska i innymi elementami potrzebnymi do uruchomienia nowego procesu wdrożeniowego. Organizacja klienta również pracowała zwinnie albo przynajmniej próbowała robić to wewnętrznie, więc łatwo było jej zrozumieć ten sposób pracy. Podobał jej się ten model. Wszystkie ceremonie zwinne — codzienne spotkania, przeglądy w połowie sprintu, prezentacje i retrospektywy — traktowaliśmy poważnie, a klient uczestniczył we wszystkich lub większości z nich.

Ben Aston:

Porozmawiajmy o kliencie. W tym scenariuszu świetne było to, że klient był właściwie właścicielem produktu. Nie mieliście wielu interesariuszy, tylko jednego. Wspomniałaś, że był świetny, ale także że po drodze wymyślał nowe funkcje i zadania. Jak zarządzaliście tym przy stałym budżecie i zwinnym podejściu?

Rebecca Germond:

To było trudne, ale za każdym razem, gdy wymyślał nową funkcję, rozumiał, że jest to zlecenie zmiany i trzeba je wycenić. Problem polegał na tym, że trudno było przerwać pracę w bieżącym sprincie, przygotować wycenę i uzyskać zatwierdzenie, ponieważ klient potrzebował wyceny, aby zaakceptować funkcję. To komplikowało pracę. Był właścicielem produktu, a jego zespół dał mu pełną autonomię w zakresie prowadzenia projektu. Planowali go przez dłuższy czas, zanim dołączyliśmy. Dobrze, że zaangażowali nas w odpowiednim momencie, ponieważ mogliśmy przekazać informacje zwrotne i pomysły na nowe funkcje.

Miał kilka ciekawych pomysłów pojawiających się zupełnie niespodziewanie, ale wszystkie były bardzo ważne. Przed rozpoczęciem budowy planowali ręcznie wdrażać klientów, wysyłając im PDF z informacjami o rejestracji. Po około trzecim sprincie zdecydowaliśmy się stworzyć kreator konfiguracji, dzięki któremu użytkownicy mogli otrzymać login i hasło z wiadomości e-mail, zresetować hasło, pobrać formularze do wypełnienia i ponownie przesłać je do systemu. Ułatwiło to pracę ich zespołu. Nie planowaliśmy tego od początku, ale dzięki temu produkt stał się znacznie lepszy.

Ben Aston:

Wspomniałaś o wyciągniętych lekcjach. Jedna z nich brzmiała: utrzymuj zaangażowanie zespołu i klienta. Klient był bardzo zaangażowany. Jakie masz wskazówki dotyczące budowania i utrzymywania takiego zaangażowania?

Rebecca Germond:

Dla FCV ten sposób pracy był nowy, ponieważ wielu naszych klientów to klienci wieloletni albo instytucje publiczne. Współpracują z nami od wielu lat, ale są przyzwyczajeni do swoich metod. Sposób, w jaki zaangażowaliśmy klienta, przyniósł bardzo dobre rezultaty, ponieważ zobaczyliśmy, że klienci naprawdę chcą uczestniczyć w pracy na takim poziomie. Chcieliśmy też, aby klient był zaangażowany, ponieważ planowaliśmy drugą fazę projektu. Portal nie jest zwykłą stroną, która kończy się wraz z końcem cyklu życia. To żywy, stale rozwijany produkt. Utrzymywanie jego zaangażowania było więc bardzo ważne.

Zespół chciał pracować nad tym projektem, ponieważ mógł wybrać stos technologiczny, zrobić coś nowego i dobrać własne narzędzia. Podobała mu się również możliwość bezpośredniej komunikacji z klientem. Mamy klienta w Slacku, więc może wymieniać pomysły z programistą interfejsu albo dowolną inną potrzebną osobą. To działa dobrze. Zespół był zaangażowany, bo budował coś, na czym naprawdę mu zależało.

Ben Aston:

Jedną z lekcji było także odrzucanie niepotrzebnych procesów i stosowanie tych, które są potrzebne. Mówiłaś, że projekt pomógł udoskonalić procesy projektowe w agencji. Czy możesz opowiedzieć o procesach, z których zrezygnowaliście, albo o usprawnieniach, które udało się wdrożyć w innych projektach?

Rebecca Germond:

Po drugiej retrospektywie sprintu zdecydowaliśmy, że nie będziemy ich dalej przeprowadzać. Uznaliśmy, że wiemy, co robimy dobrze i co wymaga poprawy, a poświęcanie na to czasu nie pomagało. Zabierało czas programistom, czego nie chcieliśmy. Ponieważ klient był bardzo zaangażowany, mógł na bieżąco przekazywać informacje zwrotne, gdy coś mu nie odpowiadało, i sugerować zmiany procesu na kolejny sprint. Z tego procesu zrezygnowaliśmy dość wcześnie.

Trudne były też codzienne spotkania, ponieważ połowa zespołu była w Toronto, a połowa w Vancouver. Staraliśmy się jednak pamiętać, że aby odblokować pracę, lepiej zorganizować krótkie, 15-minutowe spotkanie niż przez godzinę próbować wyjaśniać wszystko na Slacku.

Ben Aston:

Czyli spotkania były organizowane losowo, a nie codziennie o 9:00 albo 12:00 jako stała ceremonia? Były doraźne.

Rebecca Germond:

Tak, próbowaliśmy organizować je o 9:30, ale kiedy weszliśmy w rytm pracy, odbywały się doraźnie albo po prostu zadawaliśmy pytania na Slacku. Przez trzy sprinty organizowaliśmy je codziennie, a później co drugi dzień albo za pośrednictwem Slacka.

Ben Aston:

Czy był jakiś proces, z którego zrezygnowaliście, uznając, że nie jest potrzebny, a następnie przywróciliście go po stwierdzeniu, że była to zła decyzja?

Rebecca Germond:

Nie, ale żałowaliśmy, że nie włączyliśmy wcześniej osoby odpowiedzialnej za zapewnienie jakości. Do trzeciego sprintu właściwie nie mieliśmy niczego gotowego do testów i powinniśmy byli rozpocząć ten etap wcześniej. Pamiętam kilka prezentacji, przed którymi pracowaliśmy do ostatnich pięciu minut, zatwierdzaliśmy kod i liczyliśmy, że wszystko zadziała. Pod koniec pracowaliśmy trochę jak kowboje, ale było naprawdę ciekawie.

Ben Aston:

Świetnie. Rebecca, dziękuję za udział. Wspaniale było cię gościć.

Rebecca Germond:

Dziękuję. Zawsze chętnie.

Ben Aston:

To była przyjemność. Jeśli interesuje cię budowa portali, zajrzyj do studium przypadku przygotowanego przez Rebeccę. Znajdziesz tam wiele przydatnych informacji. Jeśli chcesz porozmawiać o budowie portali, dołącz do naszego zespołu na Slacku. Wejdź na stronę digitalprojectmanager.com/slack, gdzie znajdziesz ciekawe rozmowy na wszystkie tematy związane z cyfrowym zarządzaniem projektami. Jeśli podobał ci się dzisiejszy odcinek, odwiedź Apple Podcasts, wcześniej znane jako iTunes, i zostaw recenzję. Bardzo zależy nam na twojej opinii. Oceny i recenzje są niezwykle pomocne i wspierają nasz program. Do usłyszenia następnym razem. Dziękuję za słuchanie.