Zarządzanie projektami w e-commerce

• Dziś opowiem o zarządzaniu projektami w e-commerce. Będzie o Agile, o skalowaniu Agile, o połączeniu świata IT ze wszystkim co się dzieje wokół, o dynamicznej zmianie na poziomie międzynarodowej organizacji.

Sytuacja firmy e-commerce

Case dotyczy firmy e-commerce działającej na dużą skalę. Zacznijmy od sytuacji:

•  firma to pośrednik usług, nie wytwarza własnej usługi, której sprzedaje, tylko pozyskuje je z zewnątrz
• bardzo silne IT – kilka zespołów Scrumowych, działających na złożonym produkcie
• międzynarodowy zasięg działania
• rozbudowane działy wsparcia – oprócz silnego zespołu IT na którym wszystko bazuje jest wiele rosnących działów wsparcia. Call center, marketing, finanse…
• rosnące zatrudnienie poza IT – to jest ciekawe, jak firma e-commerce zaczyna to ma mocno wbite, że IT jest kluczem. Później jak firma zaczyna się rozrastać, to rośnie zatrudnienie ludzi poza IT

Problemy firmy e-commerce

Jakie problemy zostały zdiagnozowane:

• bardzo silne podejście z perspektywy IT – “My nie działamy projektowo, działamy produktowo”. Firma założyła, że idzie w Agile. Scrum jest podejściem produktowym, to działamy produktowo. Nie ma w tym nic złego, problem polega na tym, że odcinamy się od pewnej rzeczy, która może być przydatna. Super to działało dla IT, do pewnego poziomu… Poza IT okazało się, że to nie działa.
• zgubione wymagania biznesowe – zaczęło się tak dziać, ponieważ projekty dziejące się poza IT, które wymagały zaangażowania partnerów trafiały do kilku zespołów Scrumowych. Każdy niezależnie od siebie wrzucał to na swój backlog, nie synchronizując nic ze sobą, w różnej częstotliwości nad tym pracując. W różnych sprintach było to oddawane, część po drodze się gubiła.
• pomysły zarządu idą szybko – generalnie w każdej firmie tak jest, jak góra mówi, że “to” się ma zadziać to się zadzieje. To prowadzi do sytuacji, że Twój projekt musi się “przepchnąć”
• przeciążone IT – pozostałe działy potrzebowały dowieźć swoje wyniki, co powodowało,  że IT zaczęło się przeciążać. Nie tylko dlatego, że biznes rósł, ale dlatego też, że coraz więcej czasu trzeba było poświęcać na utrzymanie gotowych już rzeczy. Nagle nie ma 100% mocy wytwórczych, a np. 60%, bo pozostałe 40% idzie na support tego, co się zadziało.

Kluczowe punkty

Na czym się skupiliśmy:

• transparentność – okazało się, że biznes nie do końca widzi wszystko co się dzieje, backlogi nie były do końca przejrzyste, rozproszone pomiędzy kilka zespołów. Osoba, która np w marketingu zlecała coś IT nie miała pojęcia co się dzieje. Od pewnego poziomu skomplikowania nie jest łatwe zsynchronizowanie tego wszystkiego, gdy masz kilka- kilkanaście zespołów scrumowych pracujących jednocześnie
• więcej Agile – idea jest taka, jeśli firma powstała w podejściu o zwinne działanie, to trzeba zrobić tego więcej. Moje zarządzanie projektami oznacza – bierz wszystkie rzeczy, które działają i postaraj się, żeby działały dalej i lepiej
• podejście projektowe poza IT – doszliśmy do wniosku, że produktowo w IT, poza IT są projekty, do których trzeba podejść inaczej
• portfel “inicjatywy” – wszystkie tematy, które dzieją się w firmie powinny być przejrzyste, ponieważ nie było takiego jednego miejsca, to nie było do końca wiadomo co jest priorytetem biznesowym.
• backlogi dostępne dla biznesu –  nie były do końca widoczne, zespoły deweloperskie i product owner wiedzieli jak nad tym działać, ale biznes owner, który zlecał inicjatywę, nie do końca widział co i jak.
• zaangażowanie biznesu w retrospekcje – jak mamy sytuację, że zaczynamy robić inicjatywę, jest kilka zespołów deweloperskich i główne wymaganie ląduje na kilku różnych backlogach to w pewnym momencie może się rozjechać. Każdy optymalizuje swoje backlogi pod kątem swojej wartości dla swojego produktu. To powoduje sytuację jakby każdy działał wg. innego priorytetu. Nie maksymalizujemy globalnej wartości biznesowej, tylko taką powiedzmy lokalną. Możesz albo próbować synchronizować te działania bardzo mocne (to powoduje, że Agile przestaje działać do końca, bo wchodzimy w Waterfallowe podejście) albo robić więcej Agile. Pierwszym elementem było zaangażowanie biznesu w retrospekcje. Kolejne – zaangażowanie biznesu w backlog grooming. Praca na backlogach przy małych zespołach jest łatwiejsza i szybsza. Gdy jest ich kilkanaście to procesy, zaczynają mieć mega znaczenie i to jak jesteś w nich dobry. Retrospekcja zaczyna być jeszcze bardziej znacząca, backlog grooming jeszcze ważniejszy. Jak zaczyna się coś przytykać  w podejściu na którym działacie warto jeszcze raz przeczytać podejście, bo być może jakiś element umknął.  Trzeci ważny element to wyskalowanie tego wszystkiego. Rekomendowałem wykorzystanie LeSS i Nexus, to są dwa modele skalowania Agile.

Wnioski

• Brak transparentności sprzyja uprawianiu “polityki” – im mniej transparentną organizację budujesz, tym więcej polityki będzie się w niej działo. Będą wygrywać nie projekty, które mają wartość biznesową, ale projekty managerów, którzy potrafią “ugadać” temat
• Product owner musi uważać, żeby nie przejmować roli Business ownera – product owner decyduje co będzie wytwarzał zespół Scrumowy. Warto poświęcić tutaj czas na określenie, gdzie kończy się odpowiedzialność jednego, a zaczyna drugiego.
• Przy skalowaniu Agile nie można zamykać się na jeden model – każdy model jest błędny. One mogą być użyteczne. Bazują na ograniczonej liczbie caseów. Modele, które próbują wszystko uporządkować, uważam, że są sprzeczne z podejściem Agile. Takie, które dają większą swobodę są moim zdaniem lepsze.

Jeżeli zarządzasz firmą e-commerce, albo inną i chcesz dopracować taki proces dla siebie to zostawiam link do audytu projektowego: https://leadership-center.pl/audyt/

Przyjdę i wypracujemy coś co działa :)

Video