Tradycyjny sposób prowadzenia projektów informatycznych zgodnie z rygorystycznymi założeniami sprawia, że trudno nadążyć za zmieniającymi się oczekiwaniami klientów. Rozwiązaniem może być zarządzanie zwinne.
Ze względu na nieustanną zmienność współczesnych rynków firmy powinny szybko reagować na ewoluujące potrzeby swoich klientów, dlatego coraz częściej projekty informatyczne rozpoczęte przed rokiem lub nawet kilkoma miesiącami są w momencie finalizacji przestarzałe. Nie dziwi więc, że coraz popularniejszą metodą realizacji projektów biznesowo‑technologicznych staje się zarządzanie zwinne (agile management), polegające między innymi na rozwoju produktów i usług w formie niewielkich i częstych zmian, z których każda dostarcza wartość klientom i użytkownikom. Dzięki takiemu sposobowi organizacji pracy firma może nie tylko szybciej dostarczać wartość użytkownikom, ale w procesie tworzenia produktu uwzględniać płynące od nich sygnały zwrotne. Zaletą takiego podejścia jest też organizacja pracy usprawniająca komunikację i oddająca zespołowi dużo większą odpowiedzialność, co nie tylko stanowi silny czynnik motywacyjny, ale przekłada się na znacząco lepsze rezultaty.
Zwinną metodę zarządzania projektami technologicznymi z powodzeniem wykorzystuje GoldenLine, działający od 2005 roku polski serwis rekrutacyjny, w którym ponad 2,3 miliona użytkowników ma już swoje profile, a każdego miesiąca odwiedza go około 3 milionów osób.
GoldenLine dostarcza kandydatom oferty pracy, informacje o ocenach pracodawców i umożliwia założenie profilu zawodowego. Pracodawcom oferuje rozbudowane usługi rekrutacyjne, zarówno dostęp do wyszukiwarki kandydatów, jak i możliwość dodania ofert pracy. GoldenLine wspiera organizacje w obszarze employer branding poprzez doradztwo, szkolenia, możliwość założenia profilu pracodawcy oraz realizację kampanii marketingu rekrutacyjnego.
W GoldenLine zaczęliśmy dostrzegać, że realizowanie projektów technologicznych tradycyjnie nie spełniało oczekiwań użytkowników i klientów. Praca w dotychczasowym modelu wymagała długotrwałego opracowywania szczegółowych założeń projektu, a samo pisanie oprogramowania zajmowało wiele miesięcy. Zdarzały nam się projekty, które po wdrożeniu w odczuciu użytkowników i klientów zupełnie nie osiągały zamierzonych efektów. Dodatkowo ich jakość od strony technicznej również pozostawiała wiele do życzenia. Na ten stan rzeczy złożyło się kilka czynników.
Zwinne zarządzanie projektami i związane z nim przekazanie władzy pracownikom pozwala znacząco zwiększyć zaangażowanie zespołu w zakres realizowanych działań i ostateczny kształt produktu.
Pierwszy z nich to błędne założenia i brak możliwości ich częstej weryfikacji. Planując zmiany oraz usprawnienia w serwisie, badaliśmy klientów i użytkowników, pytaliśmy ich o wymagania i preferencje. Na tej podstawie wypracowywaliśmy pomysły, które do tych potrzeb miały się odnieść. Po kilku miesiącach prac okazywało się, że nasze rozwiązania nie były skuteczne. Użytkownicy w rzeczywistości zachowywali się nieco inaczej, niż się spodziewaliśmy. Przez to, że czas realizacji projektu był tak długi, nie mieliśmy możliwości zweryfikować naszych założeń i wprowadzić ewentualnych poprawek. Drugi czynnik to szybko zmieniający się rynek, zarówno rekrutacyjny, jak i internetowy. Z powodu bardzo długiego okresu planowania i długiego cyklu tworzenia oprogramowania trzeba było bardzo długo czekać na efekty pracy nad pomysłem. W tym czasie zmieniała się sytuacja na rynku (na przykład za sprawą rozwiązań konkurencji), a także preferencje naszych użytkowników. Trzeci powód niepowodzeń to olbrzymi rozmiar zmian programistycznych, jakie za jednym razem trzeba wprowadzić przy takim stylu pracy. Komplikuje to proces wdrożenia nowych funkcji, bardzo spowalnia pracę oraz zwiększa możliwość pojawienia się błędów. Czwarty, wcale nie najmniej ważny, czynnik to długi czas oczekiwania na sukces. Przy tradycyjnym modelu zarządzania projektami prace trwające miesiącami czy latami sprawiają, że zespół bardzo długo musi utrzymywać silną motywację, zanim efekt jego pracy ujrzy światło dzienne. To nie zawsze się udaje. Jeśli po zakończeniu prac projekt nie okazuje się sukcesem, konieczne staje się gruntowne przebudowanie produktu i poświęcenie na to kolejnych kilku miesięcy pracy, podczas których zostaną popełnione te same błędy. W skrajnych przypadkach może się zdarzyć, że projekt nigdy nie zrealizuje oczekiwań rynku i efekty przynajmniej kilkumiesięcznej pracy lądują w koszu.
Aby wydostać się z tego błędnego koła, zdecydowaliśmy się wprowadzić zarządzanie zwinne (agile management). Pojęcie agile jest wieloznaczne, w definiowaniu go najlepiej odwołać się do Agile Manifesto. Twórcy Manifestu Programowania Zwinnego, czyli amerykańscy programiści, ogólny przekaz sformułowali w postaci czterech zasad:
Ludzie i interakcje są ważniejsi od procesów i narzędzi;
Działające oprogramowanie jest ważniejsze od szczegółowej dokumentacji;
Współpraca z klientem jest ważniejsza od negocjowania umowy;
Reagowanie na zmiany jest ważniejsze od realizacji założonego planu.
Te ramowe zasady są uzupełnione dwunastoma założeniami Manifestu Programowania Zwinnego, o których często się zapomina (zobacz ramkę 12 założeń Manifestu Programowania Zwinnego).
Udany eksperyment
W zespole GoldenLine wszystkie zasady i założenia agile mają ogromne znaczenie, ale najważniejsza jest idea kładąca nacisk na zadowolenie klienta i dostarczenie mu w możliwie krótkim terminie jak najlepszego produktu. Doszliśmy do tego stopniowo, budując w firmie świadomość, że zarządzanie zwinne może usprawnić nasze działanie. Poszczególne elementy filozofii agile wdrażaliśmy w ciągu ostatnich czterech lat. Pierwszy duży projekt, w którym udało się wprowadzić je w życie, ruszył w listopadzie 2013 roku. Chcieliśmy zrealizować dwa usprawnienia dotyczące tego, w jaki sposób klienci korzystali z naszych usług. Po pierwsze, z tradycyjnych ofert pracy, po drugie z – będącej naszym flagowym produktem – wyszukiwarki kandydatów.
Dzięki wyszukiwarce pracodawcy mogą szybko skontaktować się z kandydatami, którzy spełniają zdefiniowane kryteria. Pozwala to w krótkim czasie dotrzeć do właściwych osób. Problem polegał na tym, że wszystkie konwersacje prowadzone z kandydatami trafiały do tej samej skrzynki co rozmowy prywatne z innymi użytkownikami GoldenLine. Ponadto wiadomości dotyczące jednej rekrutacji mieszały się z tymi dotyczącymi innej. To wydłużało czas potrzebny na zrekrutowanie kandydata i było dużym utrudnieniem dla klientów, z których wielu prowadzi w GoldenLine kilka projektów rekrutacyjnych równocześnie. Poza tym, po zdefiniowaniu kryteriów wyszukiwania, chcieliśmy dać pracodawcom możliwość opublikowania szybkiego ogłoszenia w ramach tego samego projektu rekrutacyjnego. Jego forma miała nawiązywać do krótkich notek publikowanych przez pracodawców w rozmaitych mediach. Oferta ta nie wymagała przesyłania pełnego CV (wiele osób, które obecnie poszukują pracy, po prostu go nie ma). Osoba zainteresowana współpracą mogła wyrazić chęć dalszej rozmowy. Ta operacja dawała pracodawcom możliwość nawiązania kontaktu z potencjalnymi kandydatami za pomocą wiadomości rekrutacyjnych, tak samo jak w przypadku wyszukiwarki.
W tradycyjnym podejściu realizacja tego przedsięwzięcia zajęłaby dziesięciu osobom cztery, pięć miesięcy. Nie chcieliśmy, aby klienci tyle czekali. Dodatkowo, bazując na poprzednich doświadczeniach, nie mogliśmy mieć pewności, że nasze rozwiązania będą spełniać potrzeby klientów. Dlatego właśnie postanowiliśmy stworzyć produkt z podstawowymi funkcjami (minimal viable product), który relatywnie szybko bylibyśmy w stanie przekazać klientom. Było to nasze pierwsze podejście do zarządzania zwinnego i powiedzieliśmy sobie, że będziemy mogli mówić o powodzeniu tej metody, gdy pracodawcy w niedługim czasie dodadzą tysiąc nowych ogłoszeń. Następnie, zbierając opinie zwrotne od użytkowników, chcieliśmy udoskonalać produkt krok po kroku.
Rozpoczęliśmy realizację projektu na początku kwartału. Chcieliśmy jak najszybciej skończyć fazę tworzenia nowego narzędzia i do końca kwartału „dowieźć” te tysiąc ogłoszeń, a w następnym kwartale ewentualnie rozpocząć drugą część projektu. Okazało się, że stworzenie działającego produktu zajęło nam zaledwie dwa tygodnie, a w trakcie następnych dwóch tygodni rekruterzy faktycznie dodali tysiąc nowych ogłoszeń. Znacznie szybciej, niż się spodziewaliśmy. To doświadczenie pokazało, że można szybko przeprowadzić ważny projekt, wnoszący nową wartość. Co więcej, byliśmy w stanie zaobserwować, jak rekruterzy korzystają z naszego narzędzia, następnie przedefiniować niektóre założenia projektu i usprawnić funkcjonalność produktu. To usprawnianie, niestety, nie było już tak szybkie, jak byśmy sobie tego życzyli, ale przynajmniej mieliśmy pewność, że idziemy w dobrym kierunku i dostosowujemy się do konkretnych potrzeb wyrażonych przez użytkowników. Nie tylko skróciliśmy czas realizacji całego projektu, ale przede wszystkim okres oczekiwania klienta na nowe rozwiązanie. I właśnie to ma kluczowe znaczenie w podejściu agile. Dzięki temu, że produkt trafia do klienta już po dwóch tygodniach, klient ma powód do zadowolenia, jego satysfakcja przekłada się na satysfakcję zespołu wdrożeniowego. Ta z kolei sprawia, że pracuje on na wyższych obrotach.
Co ciekawe, z perspektywy czasu, opierając się na opiniach klientów i użytkowników, widzimy, jak wiele w opisanych usprawnieniach mogliśmy zrobić lepiej. Pracujemy właśnie nad kolejną iteracją ogłoszeń w GoldenLine, które zupełnie odmienią ich formę. Kolejne wersje wdrażamy jeszcze szybciej, w jeszcze mniejszych kawałkach. To daje nam możliwość jeszcze częstszego weryfikowania naszego kierunku. Mamy już pierwszych zadowolonych klientów, a to najlepszy dowód na to, że idziemy dobrą drogą.
12 założeń Manifestu Programowania Zwinnego
Najwyższy priorytet ma zadowolenie klienta osiągane dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
Zespoły biznesowe i deweloperskie muszą ściśle współpracować w codziennej pracy przez cały czas trwania projektu.
Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
Działające oprogramowanie jest podstawową miarą postępu.
Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
W regularnych odstępach czasu zespół analizuje możliwości poprawy wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.
Oddanie władzy zespołowi
Obok satysfakcji klienta z dostarczonej mu wartości i szybkiego tempa wdrożenia niezwykle ważnym elementem zarządzania zwinnego jest zmiana organizacji pracy i motywacji zespołu. W konwencjonalnie przeprowadzonym procesie kierownik projektu zakomunikowałby członkom zespołu, jakie dokładnie zadania mają wykonywać, kontrolowałby ich wykonanie i rozliczał z efektów.
Agile stawia na zespół. Tak naprawdę, osoby wykonujące konkretne zadania są w stanie najlepiej stwierdzić, w jaki sposób mogą je usprawnić. Oddając pewne zadania w ręce zespołu, jesteśmy w stanie doprowadzić do dużo lepszych rezultatów niż w momencie, gdy zespołem kieruje jeden przełożony. Powinniśmy doprowadzić zespół do momentu, w którym jest on wstanie sam się organizować. Warto jednak zdać sobie sprawę z tego, że nie każda grupa pracujących ze sobą osób może stać się samoorganizującym zespołem. Model, który trafia do mnie, przedstawia Roy Osherove w prezentacji Team Leadership in the Age of Agile. Autor wskazuje w niej trzy fazy rozwoju zespołu: chaosu, nauki i samoorganizacji. W pierwszej fazie zespół ma małą wiedzę i doświadczenie, nie potrafi rozwijać produktu w taki sposób, aby klient lub użytkownik był zadowolony z osiąganych efektów. Na tym etapie lider musi wskazywać i niemal wymuszać dobre praktyki. Dopiero gdy zespół jest w stanie dostarczyć jakąkolwiek wartość, może pojawić się miejsce na eksperymenty, wprowadzanie nowych praktyk i narzędzi już przez sam zespół. W ostatniej fazie menedżer staje się jeszcze mniej potrzebny. Zespół jest w stanie sam podejmować dojrzałe decyzje dotyczące czy to sposobu pracy, czy architektury rozwiązań. Wiedza oraz doświadczenie poszczególnych członków zespołu zdecydowanie przewyższają umiejętności pojedynczego menedżera. Powinien on więc ustawić zespołowi tylko pewne ograniczenia i pozwolić dostarczać wartość w dowolny sposób w ramach tych ograniczeń.
Agile maksymalizuje wartość wnoszoną nie tyle przez poszczególne osoby, co przez zespół jako całość. Dlatego w przypadku przechodzenia zespołu z tradycyjnego modelu prowadzenia projektów na model zwinnego zarządzania część osób może mieć problemy z odnalezieniem się w nowej sytuacji. Dotyczy to przede wszystkim osób, które są przyzwyczajone do tego, że ich dotychczasowe doświadczenie zawodowe albo stanowisko nadaje im wyższy status lub prawo podejmowania decyzji, które nie są przez nikogo kwestionowane. Oddając władzę zespołowi i pozwalając mu na podejmowanie decyzji, osiągniemy jednak znacznie więcej. Dlatego też część osób początkowo nastawionych sceptycznie do nowego modelu, dostrzegając jego efekty, zdecyduje się pozostać w zespole i pracować z nim na nowych zasadach. Rekrutując pracowników, warto więc zwrócić uwagę na to, czy potrafią pracować w zespole oraz czy są nastawieni na wartość dostarczaną przez zespół.
Rozpoczynając wdrożenia zarządzania zwinnego, firmy zwykle decydują się na jeden z dwóch najpopularniejszych modeli – scrum lub kanban. Scrum wprowadza więcej zasad niż kanban, przez co wydaje się trudniejszy do wdrożenia. Z drugiej jednak strony już na starcie daje więcej wskazówek i praktyk, które możemy wdrożyć i które powinny nam pomóc mierzyć się z problemami. Scrum definiuje m.in. rolę właściciela produktu (product owner), którego zadaniem jest maksymalizowanie wartości dostarczanej przez cały zespół. Właściciel produktu jest też jedyną osobą, która odpowiada – w dużym uproszczeniu – za to, jakie zadania będzie realizował zespół. Ta zasada musi być respektowana przez całą organizację, a to nie zawsze jest proste i oczywiste. Okazuje się, że wiele osób musi zrezygnować ze zlecania zespołowi dodatkowych prac do zrealizowania w międzyczasie. Dodatkowo scrum wymaga, żeby praca była realizowana w tzw. sprintach (porcjach). To wymusza podzielenie pracy w taki sposób, który pozwala dostarczyć pewną wartość w maksymalnie jeden miesiąc (zwykle krócej). To kolejna zasada, która dla wielu firm nie jest łatwa do zaakceptowania. Wydaje im się, że ich projekty są dużą całością, która na przykład wymaga pół roku pracy. Wiele organizacji obawia się takiego rygoru i twierdzi, że scrum nie jest dla nich, bo ich projekt jest wyjątkowy. Po nieco bardziej wnikliwym przyjrzeniu się tym problemom okazuje się, że są dokładnie takie same jak w innych firmach.
W przypadku tych zespołów, które na początku nie chcą wprowadzać tak wielu zasad (lub na przykład nie mają pozwolenia organizacji na oficjalne wprowadzenie scrum), jako startowy model lepiej może sprawdzić się kanban. Ma mniej sztywnych reguł, co nie oznacza jednak, że nie ma ich wcale. Jedna z nich mówi, że powinniśmy ograniczyć ilość pracy, która jest „w trakcie realizacji”. Duża liczba rozpoczętych, ale nie zakończonych zadań sprawia, że jesteśmy m.in. zmuszeni do wielozadaniowości i częstej zmiany kontekstu. To natomiast oznacza, że poświęcamy coraz więcej czasu na przełączanie się między zadaniami i ich koordynację, a nie na samo wykonywanie tych zadań. Kanban pozwala też zwizualizować przepływ pracy, bardzo szybko wskazując zatory, wąskie gardła i wiele innych problemów, którymi trzeba się zająć, żeby przyspieszyć przepływ pracy.
W GoldenLine najczęściej stosujemy model pośredni, nazywany czasami „scrumban”. Dzięki temu wykorzystujemy zalety obu modeli. Dodatkowo, znając wartości leżące u podstaw tych modeli, zespół sam, w ramach cyklicznych spotkań (tzw. retrospektyw), usprawnia proces pracy, wprowadzając w nim pewne, czasami odważne i eksperymentalne, zmiany. Oddając władzę zespołowi, pozwalamy, żeby o procesie decydowały te osoby, które faktycznie w nim uczestniczą. Ponadto sprawia to, że zespół angażuje się w zmiany, sam je wprowadza i sam chce dokonywać ewentualnych korekt, jeśli eksperyment się nie powiedzie. Gdy członkowie zespołu są włączeni w proces tworzenia, od razu zauważają, jeśli jakieś rozwiązanie sprowadza cały projekt na manowce. Oprócz zaangażowania zespołu w sam proces zwinne podejście i przekazanie władzy zespołowi pozwala też znacząco zwiększyć jego zaangażowanie w zakres realizowanych działań i ostateczny kształt produktu. Dowodem na skuteczność takiego podejścia jest projekt przebudowy procesu zakładania konta w serwisie GoldenLine, który realizowaliśmy od marca do czerwca 2015 roku.
PRZECZYTAJ TAKŻE: Użytkownicy takich portali jak GoldenLine czy LinkedIn rejestrują się, aby szukać pracy w sposób pasywny »
Bezpieczny sposób na szukanie pracy
Mikołaj Jan Piskorski , Paweł Korzyński PLUżytkownicy takich portali jak Golden- Line czy LinkedIn rejestrują się, aby szukać pracy w sposób pasywny, bez ryzyka narażenia się obecnemu pracodawcy, które towarzyszy aktywnemu aplikowaniu do innych firm.
W trakcie procesu rejestracji na stronach GoldenLine.pl użytkownicy mogą wysłać zaproszenia na skrzynki mailowe znajomych, pisząc na przykład: „Cześć, tu Tomek, zapraszam Cię do GoldenLine”. Użytkownik musi się oczywiście zgodzić na wysyłanie takich powiadomień, dając dostęp do kontaktów i potwierdzając zaproszenie znajomych. Byliśmy przekonani, że ten element działa bez zarzutu. Statystyki pokazywały, że zaproszenia są wysyłane na poziomie pięciu tysięcy na tydzień.
W czerwcu 2015 roku daliśmy programistom dostęp do narzędzia, które umożliwia oglądanie procesu rejestracji. Zazwyczaj zajmował się tym właściciel produktu lub specjalista od user experience, a nie programiści, którzy są często sprowadzani do poziomu osób odpowiadających tylko i wyłącznie za kodowanie. Kiedy jednak członkowie zespołu programistów otrzymali wgląd w proces rejestracji, jeden z nich tak długo mu się przyglądał, aż stwierdził, że coś tu nie działa. I rzeczywiście – duża część użytkowników nie przechodziła przez drugi krok procesu, na którym następowała wysyłka zaproszeń do znajomych. Szybko udało się tę usterkę naprawić i w rezultacie liczba zaproszeń wzrosła pięciokrotnie, z pięciu do dwudziestu pięciu tysięcy tygodniowo. Najciekawsze było właśnie to, że osoba, która dostrzegła ten problem, była „tylko” programistą. Jest to warte podkreślenia, ponieważ problem nie leżał w błędnie napisanym kodzie, tylko w tym, jak był zaprojektowany proces rejestracji w serwisie. Gdyby nie zwinne podejście i przekazanie władzy w ręce zespołu, prawdopodobnie nigdy byśmy się o tym problemie nie dowiedzieli, choć przynosiłby on firmie realne szkody.
Zaraz po uporaniu się z problemem zbyt małej liczby zaproszeń wysyłanych przez użytkowników do swoich znajomych w trakcie rejestrowania się w GoldenLine naszym kolejnym celem było przekonanie użytkowników do zostawiania większej ilości informacji na swój temat i taki cel postawiliśmy zespołowi. Dzięki pracy w modelu agile już po tygodniu byliśmy w stanie zweryfikować, jak wygląda proces rejestracji w serwisie GoldenLine, wprowadzić modyfikacje i udostępnić udoskonalony produkt użytkownikom.
Zgodnie ze zwinnym podejściem, po wprowadzeniu szybkich poprawek postanowiliśmy sprawdzić reakcje internautów na zmiany i w tym celu rejestrowaliśmy ich zachowania. Zazwyczaj analizą tych nagrań zajmuje się właściciel produktu albo specjalista od user experience, ale tym razem w proces oceny skuteczności naszego rozwiązania postanowiliśmy zaangażować cały zespół, w tym programistów. Wszyscy mogli zobaczyć, z jakimi problemami borykają się użytkownicy, jak przechodzą z jednego pola na inne, jaką trudność sprawia im wpisywanie nazw miejscowości czy kliknięcie we właściwy obszar. Gdybym sam to oglądał i arbitralnie wskazał, co trzeba zmienić, wówczas programiści mieliby do mnie pretensję, że zlecam im dodatkową pracę. Ale kiedy wszyscy to zobaczyli, obudziło się w nich poczucie odpowiedzialności. Od razu zdali sobie sprawę z tego, co mają robić, aby poprawić doświadczenie użytkownika.
Upoważnienie do działania
Zachęceni sukcesami zarządzania zwinnego zaczęliśmy stosować to rozwiązanie w wielu obszarach w firmie. Zauważyliśmy też, że wraz z upowszechnieniem tego modelu nasza kultura organizacyjna zaczęła zmieniać się na taką, która bardziej angażuje cały zespół. Najlepszym tego przykładem jest jeden z naszych najnowszych projektów. Jego celem było zwiększenie liczby osób, które składają aplikacje w odpowiedzi na ofertę pracy. Był to ważny cel, dlatego postanowiliśmy zaangażować w niego całą firmę, zmniejszając priorytet innych zadań. Inspirując się książką The Advantage Patricka Lencioniego, chcieliśmy przyspieszyć moment dostarczenia wartości użytkownikowi oraz zwiększyć zaangażowanie zespołu pracującego nad produktem.
Zwinne zarządzanie projektami i związane z nim przekazanie władzy pracownikom pozwala znacząco zwiększyć zaangażowanie zespołu w zakres realizowanych działań i ostateczny kształt produktu.
Tak właśnie stało się w przypadku opisywanego projektu. Postanowiliśmy zaangażować wszystkich pracowników w generowanie pomysłów, które mogłyby przyczynić się do zwiększenia efektywności publikowanych u nas ogłoszeń, mierzonej liczbą i jakością CV nadsyłanych w odpowiedzi na daną ofertę pracy. Wyszliśmy z założenia, że aby odnieść sukces w realizacji celu istotnego dla naszej organizacji, powinniśmy pozwolić osobom z całej firmy zgłaszać pomysły.
Główny cel podzieliliśmy na cztery podstawowe obszary – udoskonalenie jakości ofert pracy, wzrost skuteczności mailowych rekomendacji ofert pracy, które wysyłamy użytkownikom, zwiększenie ruchu na ofertach oraz sprawienie, aby użytkownik składał więcej aplikacji w ciągu jednej wizyty. Każdy z tych obszarów miał opiekuna, do którego zatrudnione w firmie osoby mogły zgłaszać pomysły. Efekt był piorunujący – nasi pracownicy w ciągu miesiąca zgłosili 148 projektów. Spośród 110 osób zatrudnionych w firmie ponad połowa przyszła z własnymi pomysłami. Były one bardzo różnorodne i obejmowały zarówno drobne zmiany, jak i duże projekty, a niektóre zakwestionowały dotychczasowy sposób myślenia o naszych produktach, co pozwoliło spojrzeć na nie z całkiem nowej perspektywy. W pierwszej kolejności realizowaliśmy te projekty, które według pracowników nadzorujących poszczególne obszary w największym stopniu przyczyniały się do wzrostu efektywności ogłoszeń.
W ciągu 5 miesięcy liczba zrealizowanych projektów wyniosła 37, a średnia liczba CV dostarczanych w odpowiedzi na oferty pracy wzrosła 3‑krotnie. Wspólne działania całej firmy w krótkim czasie zapewniły znaczący wzrost efektywności ofert pracy, co przekłada się nie tylko na zadowolenie klientów, ale i naszą satysfakcję z osiągania wspólnych sukcesów. Nowy model wyraźnie poprawił współpracę między zespołami z różnych działów, które dzięki wspólnym projektom konsultowały się i łączyły w grupy projektowe. Kolejnym ciekawym elementem nowego modelu pracy były eksperymenty, którymi poprzedzaliśmy wprowadzenie w życie każdego projektu – to także element filozofii agile. W ciągu maksymalnie 1–2 tygodni sprawdzaliśmy, czy rozwiązanie faktycznie działa. To pozwoliło na szybkie odrzucanie nietrafionych pomysłów i koncentrowanie się tylko na realizacji tych, które przekładały się na efekty.
Zaangażowanie zespołu pozwoliło na wprowadzenie modyfikacji zarówno zmieniających to, jak wygląda serwis, ale także jak działa jego „silnik” – oprogramowanie, które go napędza. Jedna z osób zaproponowała, w jaki sposób możemy rozszerzyć zasięg powiadomień o dopasowanych ofertach pracy, które wysyłamy użytkownikom. Realizacja tego pomysłu sprawiła, że te powiadomienia przynoszą trzy razy więcej aplikacji na oferty pracy. To ogromna zmiana; bezpośrednio przełożyła się na to, jakie efekty dostarczamy klientom. Co ciekawe, osoba, która zgłaszała pomysł, nie przerywała swojego udziału w jego realizacji na etapie samego zgłoszenia. Chcieliśmy, aby pomysłodawca angażował się w dalsze etapy zbierania informacji, oceny przydatności projektu, jego kosztu, a także w przedstawienie pomysłu zespołowi. W efekcie osoby z inicjatywą miały większe poczucie sprawczości i wpływu na rozwój firmy. Mogły korygować projekt na każdym etapie i być świadkiem tego, jak ich pomysł przeradza się w działające rozwiązanie, które przynosi wartość produktowi i firmie. Taki model organizacji pracy w jeszcze większym stopniu pozwolił zwiększyć zaangażowanie zespołu.
Zgłaszane pomysły były weryfikowane w trakcie eksperymentów, dlatego nikt nie obrażał się, jeśli jego pomysł został odrzucony lub zrealizowany zupełnie inaczej, niż pierwotnie zakładano. To jeszcze bardziej przyczyniało się do poprawy atmosfery w zespole i zachęcało do zaangażowania.
Stosowane przez nas metody zarządzania zwinnego ograniczały się początkowo do projektów technologicznych, ale z czasem objęły również inne obszary całej organizacji. Zastosowanie modelu agile pomogło w budowaniu zaangażowania i pozwoliło na szybkie dostarczanie klientom wartości, co jest niezwykle istotne dla wszystkich firm funkcjonujących na zmiennych i nieprzewidywalnych rynkach. Upoważnienie pracowników do eksperymentowania, a nawet popełniania błędów, przyniosło w naszym przypadku doskonałe efekty.
