Szkolenie było, umiejętności nie ma
Dwie godziny prezentacji i nagranie, do którego nikt nie wróci. Ludzie wiedzą, że narzędzie istnieje, ale nie wiedzą, co kliknąć we wtorek rano.
Zbudowanie systemu to połowa roboty. Druga połowa to doprowadzenie do momentu, w którym ludzie używają go bez przypominania — i ta połowa decyduje, czy projekt był inwestycją czy kosztem.
Najdroższy system to ten, który działa poprawnie i z którego nikt nie korzysta.
Dwie godziny prezentacji i nagranie, do którego nikt nie wróci. Ludzie wiedzą, że narzędzie istnieje, ale nie wiedzą, co kliknąć we wtorek rano.
Przy pierwszej sytuacji nietypowej ktoś otwiera stary plik, bo tak jest szybciej. Po miesiącu firma pracuje w dwóch systemach naraz.
Zaprojektowany przy stole, z osobami, które procesu nie wykonują. Detale, które decydują o użyteczności, wychodzą dopiero w terenie.
Nikt nie mówi, że nie chce. Po prostu wypełnianie danych schodzi na koniec dnia, a potem na jutro. Efektu nie widać w harmonogramie, widać w pustych rekordach.
Wykonawca zamknął projekt i zniknął. Pierwszy nietypowy przypadek trafia w próżnię, a zaufanie do narzędzia spada z każdym takim dniem.
Dopóki nikt nie powie wprost, po co to robimy i co się zmieni w ich pracy, wyobraźnia wypełni lukę najgorszą wersją.
Buduję po to, żeby oddać. To jest jedyny sposób, żeby system przetrwał odejście wykonawcy.
Ludzie uczą się na własnych zleceniach i własnych klientach. Przykładowe dane produkują poczucie, że wszystko zrozumiałe, aż do pierwszego prawdziwego przypadku.
Zespół potrzebuje wiedzieć, co robić w konkretnej sytuacji. Osoba zarządzająca potrzebuje wiedzieć, co system pokazuje i czego nie pokaże. To są dwie różne rozmowy.
Pytanie „czy to mnie zastąpi” pada zawsze, tylko nie zawsze na głos. Lepiej odpowiedzieć na nie na początku niż tłumaczyć potem, dlaczego nikt nie wypełnia danych.
Krótkie instrukcje dla realnych sytuacji, nie stustronicowy podręcznik. Coś, co nowa osoba przeczyta pierwszego dnia i będzie umiała zacząć.
Najwięcej uczy się w tygodniach po starcie, gdy pojawia się to, czego nikt nie przewidział. Zamykanie projektu w dniu uruchomienia to zostawianie klienta w najtrudniejszym momencie.
Osoby nietechniczne, praca z telefonu
Definicję poprawnej odpowiedzi ustalał mechanik
Codzienna praktyka czytania kodu prowadzona publicznie
Pełne opisy wdrożeń z decyzjami i odrzuconymi alternatywami →
Sama nauka obsługi to zwykle jedna lub dwie sesje. Realne wdrożenie liczy się w tygodniach po starcie, bo dopiero wtedy pojawiają się sytuacje, których nikt nie przewidział — i to one decydują, czy zespół zaufa narzędziu.
Tak, jeśli chodzi o pracę z AI i automatyzacją w codziennych zadaniach. Szkolenie z konkretnego systemu zewnętrznego ma sens tylko wtedy, gdy najpierw go poznam — inaczej byłoby czytaniem cudzej dokumentacji na głos.
To najczęstszy powód, dla którego wdrożenia się nie udają, i trzeba się nim zająć wprost. Zwykle za oporem stoi konkretna obawa: o pracę, o kontrolę albo o to, że nowe narzędzie doda roboty zamiast ją zdjąć. Każda z nich ma inną odpowiedź.
Działający system, dokumentacja pisana pod realne sytuacje, przeszkolony zespół i dostęp do wszystkiego po Waszej stronie. Celem jest to, żebyście mnie nie potrzebowali — a nie żebyście dzwonili przy każdej zmianie.
Opisz proces w dwóch zdaniach. Jeśli nie ma tu czego automatyzować, powiem to wprost — ta odpowiedź jest darmowa i oszczędza czas nam obu.
hello@kamiljan.com