Innowacja umiera, gdy gubi człowieka

Najbardziej niebezpieczne projekty wcale nie wyglądają jak katastrofa.

Nie ma w nich zwykle wielkiej kompromitacji. Nikt nie wychodzi z sali trzaskając drzwiami. Nikt nie staje na krześle i nie krzyczy, że to wszystko nie ma sensu. Z zewnątrz wszystko bardzo długo wygląda dobrze. Są warsztaty. Jest energia. Jest roadmapa. Są kolorowe statusy. Jest zarząd, który „kibicuje zmianie”. Jest nawet język, który dobrze brzmi na slajdach: innowacja, transformacja, człowiek w centrum, projektowanie doświadczenia.

A potem mijają miesiące i okazuje się, że rozwiązanie nadal żyje głównie w prezentacjach, a ludzie, dla których miało coś uprościć, dalej robią swoje starymi obejściami, tylko z coraz mniejszą cierpliwością.

I właśnie dlatego uważam, że największy problem wielu wdrożeń nie polega na tym, że pomysł był słaby. Znacznie częściej problem polega na czymś innym:

projekt za bardzo zakochał się w sobie, a za mało w człowieku, który ma z nim potem żyć.

To jest ten moment, kiedy innowacja zaczyna mówić pięknym językiem, ale przestaje rozumieć zwykły dzień.

Widziałam to już za dużo razy, żeby traktować jako przypadek. Projekt startuje od prawdziwego bólu: za dużo ręcznej roboty, za dużo chaosu, za dużo obejść, za dużo rzeczy, które od dawna powinny być prostsze. Na początku wszyscy są naprawdę skupieni. Ludzie opowiadają, co ich męczy. Zespół projektowy słucha. Ktoś robi mapę procesu. Ktoś inny zbiera insighty. Padają ważne zdania o tym, gdzie najbardziej przecieka dzień pracy.

A potem dzieje się coś zaskakująco typowego.

Projekt oddala się od człowieka dokładnie wtedy, kiedy najbardziej potrzebowałby być przy nim blisko.

Druga pokusa: zamknąć się, dopracować i wrócić z gotowym „tadaaa”

Jest taka pokusa, którą firmy lubią mylić z profesjonalizmem.

Zamknąć się w małym gronie, wszystko dopieścić, doszlifować, poprawić, dopracować „żeby nie straszyć ludzi za wcześnie”, a potem wyjść do zespołu z gotowym rozwiązaniem. Jak po remoncie mieszkania, kiedy zapraszasz rodzinę na parapetówkę i liczysz, że wszyscy spojrzą na nowe ściany, lampy i podłogi, po czym zgodnie westchną: dokładnie o to nam chodziło.

Tylko że użytkownik nie jest gościem na parapetówce.

On tam mieszka.

I to jest różnica, której nie da się obejść żadnym warsztatem.

Bo jeśli przez trzy miesiące ktoś słyszy tylko, że „pracujemy nad czymś super”, „jeszcze chwila”, „na razie to za wcześnie”, „pokażemy, jak będzie bardziej kompletne”, to z jego perspektywy nie zmienia się nic. Nadal funkcjonuje w starym układzie. Nadal płaci cenę za obecny bałagan. Nadal ma te same utrudnienia, te same skróty, te same nieintuicyjne ruchy, ten sam ciężar na plecach. Nowe rozwiązanie istnieje wyłącznie w głowach i slajdach innych ludzi.

I właśnie wtedy projekt zaczyna rozjeżdżać się z rzeczywistością.

To jest dla mnie jeden z najważniejszych paradoksów wdrażania: im dłużej próbujesz ochronić projekt przed użytkownikiem, tym większa szansa, że później trzeba będzie chronić użytkownika przed projektem.

Dlaczego? Bo bez kontaktu z realnym dniem pracy wszystko zaczyna robić się zbyt eleganckie. Zbyt logiczne. Zbyt gładkie. Zbyt szyte na manekinie.

A człowiek nie jest manekinem.

Nie pracuje w próżni.

Nie myśli linearnie przez osiem godzin.

Nie istnieje po to, żeby spełnić założenia makiety.

Człowiek ma swoje tempo, swoją pamięć, swoje obejścia, swoje zmęczenie, swoje ograniczenia poznawcze, swój rytm dnia, swój bałagan. I właśnie dlatego tak ważne są małe, czasem nieestetyczne, nieidealne pętle.

Wersja 0.1.Coś, co można kliknąć.

Coś, co można skrytykować.

Coś, co można obejść.

Coś, co pozwala usłyszeć: tu się gubię, tu mi to pomaga, tu skraca mi dzień, tu dokładacie mi roboty.

Ja naprawdę wolę brzydki prototyp, który przeżył spotkanie z rzeczywistością, niż dopracowane rozwiązanie, które zbyt długo dojrzewało bez ludzi. Bo wtedy projekt jeszcze się uczy. A nie tylko siebie utwierdza.

Mikro-protokół nr 1: trzy pytania po każdym etapie

Po każdym etapie dobrze jest zadać sobie trzy pytania. Nie dla rytuału. Dla uczciwości.

Co dokładnie zmieni się w dniu użytkownika po tym kawałku?

Nie w modelu. Nie w diagramie. W dniu.

Czego dowiedzieliśmy się od ludzi, a nie tylko o ludziach?

To nie jest detal językowy. To jest różnica między relacją a ekstrakcją.

Czy to upraszcza pracę, czy tylko przesuwa wąskie gardło gdzie indziej?

Bo bardzo dużo projektów niczego nie upraszcza. One tylko przenoszą koszt w mniej widoczne miejsce.

Jeśli nie umiesz odpowiedzieć na te pytania bez dymu, bardzo możliwe, że projekt już odpłynął.

Sukces projektu nie kończy się na dashboardzie

Na slajdach sukces wygląda prawie zawsze podobnie.

Krótszy czas.

Mniej błędów.

Lepsza jakość danych.

Szybszy obieg.

Wyższa efektywność.

To wszystko jest ważne. Oczywiście.

Tylko że prawdziwy problem zaczyna się wtedy, gdy definicja sukcesu kończy się dokładnie tam, gdzie kończy się to, co łatwo zmierzyć. Bo innowacja nie dzieje się w sterylnej przestrzeni. Dzieje się w zespole, który już ma swoje tempo, swoją pojemność, swoje niedopowiedziane konflikty, swoje stare zmęczenie i kalendarz pełny po brzegi, zanim jeszcze dorzucisz do niego „udział w projekcie”.

Jeśli tego nie bierzesz pod uwagę, projekt nie jest ambitny. Projekt jest pasożytniczy.

Tak, używam tego słowa celowo.

Bo jeśli nowe rozwiązanie jest budowane dzięki temu, że ludzie uczą się go po godzinach, między spotkaniami, na resztkach uwagi, w trybie „jakoś damy radę”, to nie mamy do czynienia z zaangażowaniem. Mamy do czynienia z kredytem branym na czyjejś pojemności.

Na papierze wdrożenie postępuje.

W praktyce człowiek dopłaca do tego własnym układem nerwowym.

I właśnie tutaj kończy się dla mnie romantyczna opowieść o innowacyjności. Nie interesuje mnie już, czy projekt „dobrze rokuje”. Interesuje mnie, ile energii zjada po drodze i kto za ten koszt płaci.

Mikro-protokół nr 2: licz godzinami, nie entuzjazmem

Nie pytaj tylko: czy damy radę to dorzucić?

To pytanie brzmi energicznie, ale jest fatalne. Bo bardzo łatwo odpowiada na nie entuzjazm, a nie rzeczywistość.

Lepiej pytaj:

Ile realnych godzin to zabiera?

Nie na warsztacie. W prawdziwym tygodniu.

Z czyjej pracy to jest wyjmowane?

Bo coś zawsze wypada. Tylko zwykle nie nazywamy tego wprost.

Co przestanie być zrobione, jeśli to dołożymy?

Każde nowe „tak” ma swoją ukrytą cenę.

Gdzie potrzebne jest buforowanie, zanim system wejdzie ludziom na klatkę piersiową?

Bo przeciążenie nie pojawia się dopiero wtedy, kiedy ktoś bierze L4. Ono dużo wcześniej pokazuje się w drobnych pęknięciach.

To nie jest brak elastyczności.

To jest uczciwość operacyjna.

Użytkownik nie jest dawcą insightu. Jest współautorem

Bardzo dużo projektów zaczyna od ludzi i kończy bez ludzi.

Najpierw wywiady, warsztaty, ankiety, mapowanie bólu, zbieranie historii. Ludzie opowiadają, co im przeszkadza, gdzie tracą czas, gdzie system przecieka, co ich męczy. Zespół projektowy wszystko zapisuje, grupuje, koloruje, syntetyzuje. Wszyscy wychodzą z poczuciem, że człowiek został uwzględniony.

A potem ci sami ludzie znikają z procesu na kilka miesięcy i wracają dopiero wtedy, kiedy mogą co najwyżej zgłosić buga.

To nie jest współpraca.

To jest ekstrakcja danych.

Prawdziwy czynnik ludzki nie polega na tym, że pytasz człowieka na początku, a potem zamykasz drzwi. Polega na tym, że człowiek zostaje w środku procesu także wtedy, gdy robi się niewygodnie: przy pierwszym prototypie, przy poprawkach, przy tarciach, przy zmianie decyzji, przy pytaniu „czy na pewno to, co budujemy, dalej ma sens?”.

Najlepsze projekty, jakie widziałam, miały jedną wspólną cechę: realni użytkownicy byli w środku, nie obok.

Nie jako dekoracja.

Nie jako „grupa do konsultacji”.

Nie jako przypis do people first.

Tylko jako partnerzy, których głos realnie wpływał na kontrakt decyzyjny projektu.

I to naprawdę zmienia wszystko.

Bo wtedy nie projektujesz czegoś dla ludzi.

Projektujesz z nimi.

A to zmienia jakość decyzji, tempo akceptacji, poziom oporu i w ogóle sens całego wdrożenia.

„Go-live” to nie koniec. To chwila prawdy

Jest taki moment, który pięknie wygląda w harmonogramie.

Uruchomienie.

Go-live.

Komunikat.

Newsletter.

Kropka nad i.

Z perspektywy planu koniec projektu. Z perspektywy człowieka dopiero początek.

Bo dopiero wtedy nowe rozwiązanie zderza się z prawdziwym dniem pracy. Nie z demo. Nie z warsztatem. Nie z optymistycznym use casem. Tylko z realnym poniedziałkiem, przerywanym przez telefony, zebrania, awarie, pośpiech, chore dziecko, zmęczenie i wszystkie inne rzeczy, których nikt nie wpisuje do roadmapy.

Jeśli po uruchomieniu nie ma już miejsca na słuchanie, drobne korekty i uczciwe przyznanie „tu to nie siadło”, ludzie bardzo szybko uczą się jednego: nieważne, co powiem, i tak już jest po wszystkim.

I wtedy nie masz buntu.

Nie masz wielkiego oporu.

Masz coś dużo gorszego.

Bierne klikanie.

Obejścia.

Minimalną zgodność.

System działa, ale nikt mu nie ufa.

To jest właśnie ten rodzaj wdrożenia, który z zewnątrz wygląda na sukces, a od środka już dawno stracił kontakt z człowiekiem.

Dobry projekt nie kończy się w dniu startu. Dobry projekt zakłada, że wdrożenie dalej jest fazą uczenia się. Że użytkownik po uruchomieniu mówi rzeczy jeszcze ważniejsze niż na początku, bo nie opowiada już o wyobrażeniu pracy, tylko o zderzeniu narzędzia z codziennością.

I właśnie wtedy trzeba słuchać najmocniej.

Na końcu i tak chodzi o czyjś zwykły dzień

Kiedy myślę o innowacji, która naprawdę działa, nie widzę dashboardu.

Widzę poranek.

Ktoś siada do pracy.

Otwiera narzędzie.

I pierwszy raz od dawna nie musi kombinować.

Nie musi obchodzić systemu bokiem.

Nie musi dopłacać sobą do czegoś, co miało pomagać.

Nie musi brać oddechu przed wejściem.

To jest dla mnie prawdziwa miara jakości.

Nie to, czy makieta robi wrażenie.

Nie to, czy backlog się zgadza.

Nie to, czy go-live poszedł zgodnie z planem.

Tylko to, czy człowiekowi robi się choć trochę lżej.

Bo użytkownik nie jest końcem procesu.

Jest miejscem, w którym ten proces codziennie ląduje.

I jeśli naprawdę jest w centrum nie jako hasło, tylko jako żywy system zaangażowania nie trzeba pompować prezentacją. Ono rośnie samo, bo ludzie czują, że tym razem ktoś nie projektuje ich pod narzędzie, tylko narzędzie pod ich pracę.

I dopiero wtedy innowacja przestaje być ładnym słowem.

Zaczyna być czymś, co naprawdę ma sens.