Najpierw jest ekscytacja.

Warsztat w sali konferencyjnej albo na Miro. Na ścianach kolorowe karteczki, w głowach wizja: „zrobimy coś swojego, skrojonego pod nasz zespół”. Nie kolejne pudełko z półki, tylko rozwiązanie, które naprawdę odpowiada na konkretne potrzeby. Projekt na kilka miesięcy, etapami: odkrywanie, prototyp, testy, doszlifowanie.

Ludzie są zaciekawieni, trochę onieśmieleni. Wszyscy czują, że to ważne.

Po drodze jednak często dzieje się coś takiego, że zamiast rosnąć zaangażowanie, zaczyna ono cichutko opadać.

Nie dlatego, że innowacja jest „zła”.

Dlatego, że po drodze gubimy człowieka.

Pierwszy błąd pojawia się wtedy, gdy zakochujemy się w pomyśle bardziej niż w użytkowniku.

Na początku jest insight: „to nas boli, tu się męczymy, tu tracimy czas”. Potem rodzi się koncepcja rozwiązania. Łatwo wtedy przeskoczyć od „co naprawdę chcemy zmienić w pracy ludzi?” do „zobaczcie, jaki mamy świetny feature, jak to elegancko można zmapować”.

Zamiast wracać wciąż do pytania: „jak będzie wyglądał dzień użytkownika, kiedy to już zadziała?”, zespół projektowy zaczyna dyskutować o architekturze, integracjach, backlogu zadań. Użytkownik staje się abstrakcyjną figurką w prezentacji – „nasz user” – a nie konkretną osobą, która wieczorem kładzie się do łóżka zmęczona tym, jak wygląda jej praca.

Jeśli w innowacyjnym projekcie człowiek zamienia się w „aktor procesu”, zaangażowanie znika bardzo szybko. Ludzie czują, że system znów robi się ważniejszy niż ci, którzy mają z niego korzystać.

Drugi błąd to budowanie „w piwnicy”, a potem spektakularne odsłonięcie.

Kiedy tworzymy coś od zera, bardzo kusi, żeby najpierw wszystko wymyślić, poukładać, dopracować „w wąskim gronie”, a dopiero na końcu pokazać ludziom gotowy efekt. Trochę jak remont mieszkania, po którym zapraszasz rodzinę na wielkie „tadaaa”.

Problem w tym, że użytkownik nie jest gościem na parapetówce. Jest współwłaścicielem tego mieszkania. Jeśli przez kilka miesięcy słyszy tylko: „pracujemy nad czymś super, jeszcze nie możemy pokazać”, to w jego doświadczeniu nic się nie zmienia. Zmęczenie starym sposobem pracy rośnie, a nowy jest abstrakcją.

Innowacja, która ma służyć konkretnym ludziom, nie może być jak niespodzianka. Ona potrzebuje wspólnego, czasem nieidealnego, etapowego budowania: wersja 0.1, feedback, poprawki. Prototyp, który nie jest perfekcyjny, ale można go już dotknąć i powiedzieć: „tu jest nieintuicyjnie, tu mi pomaga, tu się gubię”.

Bez tych małych pętli sprzężenia zwrotnego wdrożenie staje się „zadańcem z góry”. A zaangażowanie znów się zwija.

Trzeci błąd to pomijanie czynnika ludzkiego w samej definicji „sukcesu projektu”.

Na slajdach zwykle jest: skrócenie czasu, wzrost efektywności, mniej błędów, lepsza jakość danych. To ważne. Ale jeśli nie pojawia się też pytanie: „co będzie się działo z ludźmi po drodze?”, system może zadziałać na papierze, a w praktyce wypalić zespół.

Projektowanie etapowe powinno dotyczyć nie tylko funkcji, lecz także energii.

Co ten etap robi z użytkownikami?

Czy mają przestrzeń, by się uczyć, czy doklejamy im to „po godzinach”?Czy są momenty na zatrzymanie się i powiedzenie: „to nas przerasta, potrzebujemy inaczej”?

Innowacja nie dzieje się w próżni. Dzieje się w konkretnym zespole, który już ma swoje obciążenia, swoje napięcia, swoje niewypowiedziane lęki. Jeżeli tego nie uwzględnimy, nawet najlepsze rozwiązanie stanie się kolejnym ciężarem na plecach.

Czwarty błąd to „użytkownik jako dawca danych”, a nie partner.

Na początku projektu zapraszamy ludzi na wywiady, warsztaty, ankiety. Pytamy: „co wam przeszkadza, jak pracujecie dziś, co byście zmienili?”.

Zbieramy opowieści, insighty, doświadczenia.

Potem bywa tak, że zespół projektowy znika na kilka miesięcy i wraca z rozwiązaniem, w którym użytkownicy już nie mają głosu – poza tym, że mogą zgłosić buga na specjalnym kanale.

Czynnik ludzki nie polega tylko na tym, żeby „wysłuchać na początku”. Chodzi o to, żeby człowiek był obecny na każdym etapie: od nazywania problemu, przez prototyp, aż po moment, w którym narzędzie zaczyna żyć w realnej pracy.

Idealnie, jeśli w zespole projektowym są faktyczni użytkownicy, a nie tylko ich wyobrażenia. Jeśli ich zdanie ma realną wagę, a nie status „miło, że to mówisz, ale my już wiemy lepiej”. Wtedy innowacja nie jest „robiona dla ludzi”. Jest robiona z ludźmi. To ogromna różnica dla zaangażowania.

Piąty błąd to zakończenie projektu w momencie uruchomienia rozwiązania.

Z perspektywy harmonogramu „go-live” to ładna kropka nad i.

Z perspektywy człowieka – dopiero początek.

To właśnie wtedy użytkownik zderza się z nowym rozwiązaniem w swoim prawdziwym dniu: z przerwami na zebrania, z telefonem od klienta, z dzieckiem chorym w domu, z własnym zmęczeniem.

Jeśli po uruchomieniu nie ma przestrzeni na słuchanie, na dostrajanie etapami, na małe poprawki wynikające z realnego użycia, ludzie uczą się jednego: „nie warto się starać, i tak już jest pozamiatane”. Zaangażowanie zamienia się w bierne „klikam, bo muszę”.

Tymczasem dobry, etapowy projekt innowacyjny zakłada, że faza wdrożenia to wciąż część nauki. Że w tym czasie słyszymy użytkownika może nawet głośniej niż na początku. Że jego doświadczenie – frustracja, ulga, pomysły – są tak samo ważnym wskaźnikiem, jak KPI z dashboardu.

Gdy myślę o innowacji, która rzeczywiście działa, widzę przed oczami nie interfejs ani backlog, tylko czyjś zwykły dzień. Ktoś siada do pracy, otwiera system i czuje, że jest mu choć trochę lżej. Że rozwiązanie jest budowane „pod człowieka”, a nie człowiek pod rozwiązanie.

Użytkownik to nie „końcowy odbiorca”. To żywy system, z którym nasz pomysł będzie się stykał każdego dnia.

Jeśli jest w centrum projektu naprawdę, a nie tylko w prezentacji, zaangażowanie nie musi być wymuszane. Po prostu rośnie, bo ludzie czują: „to narzędzie widzi mnie i moją pracę”.

A to jest najważniejsza innowacja, jaką możemy sobie zafundować.