Czego AI nie wyczyta z transkryptu warsztatu – o ukrytych wymaganiach klientów

Transkrypt z warsztatu discovery wygląda imponująco. Kilkadziesiąt stron, wszystko podzielone na wątki, tematy, potrzeby. Model językowy podsumowuje to w kilka minut, grupuje wymagania, wyciąga funkcjonalności. Można odnieść wrażenie, że analiza jest gotowa.

Nie jest.

Projekty wdrożeniowe rzadko sypią się dlatego, że coś zostało źle zapisane. Sypią się dlatego, że coś zostało źle odczytane – albo w ogóle nie zostało dostrzeżone. A to, co najważniejsze, często nie pada na warsztacie wprost.

Co AI robi dobrze – i dlaczego to dopiero początek

Nie ma sensu udawać, że narzędzia językowe nie wnoszą wartości w procesie discovery. Automatyczna transkrypcja, ekstrakcja wymagań funkcjonalnych, wstępna kategoryzacja tematów – to realna oszczędność czasu. Model bez problemu wyciągnie z nagrania listę systemów, które klient chce zintegrować, liczbę użytkowników, których wymieniono, czy terminy, które powtarzały się najczęściej.

Problem pojawia się, gdy traktujemy tę warstwę jako analizę, a nie jako surowy materiał do analizy. To, co AI przetwarza sprawnie, to treść wypowiedziana wprost. Tymczasem rzeczywiste wymagania klientów – te, które decydują o powodzeniu projektu – często nie są wypowiadane wprost.

Pięć sygnałów, których nie ma w transkrypcie

1. Napięcie między uczestnikami

Kto mówi, a kto milczy? Kto wchodzi w słowo, gdy pada konkretny temat? Kto cofa się, gdy przy stole pojawia się określona osoba?

Doświadczony konsultant zauważa, że kierownik działu sprzedaży za każdym razem, gdy ktoś wspomina raporty zarządcze, spogląda na dyrektora finansowego i czeka na jego reakcję, zanim cokolwiek powie. To nie jest wymaganie funkcjonalne. To informacja o tym, kto realnie decyduje o zakresie projektu i gdzie leży centrum władzy w organizacji. AI tego nie zobaczy, bo tego w transkrypcie nie ma.

2. Zmiana języka

Kiedy klient przechodzi z „my chcemy” na „zostało nam powiedziane, żebyśmy…”, to nie jest przypadkowa zamiana słów. To sygnał, że wymaganie nie pochodzi od osoby, która je artykułuje – ktoś wyżej w hierarchii narzucił kierunek, a rozmówca go tylko przekazuje. Prawdopodobnie bez przekonania i bez głębokiego rozumienia, dlaczego.

Podobnie działa przejście z precyzyjnego języka technicznego na ogólniki. Kiedy analityk, który przez godzinę mówił konkretnie o strukturze danych i logice procesów, nagle zaczyna używać rozmytych sformułowań – „no to zależy”, „to trzeba by doprecyzować” – to zazwyczaj oznacza, że trafiliśmy na temat politycznie wrażliwy albo nierozstrzygnięty wewnętrznie.

3. Pytania, które nie padły

To jeden z najtrudniejszych sygnałów do wychwycenia, bo wymaga myślenia o tym, czego nie ma, nie o tym, co jest.

Jeśli na warsztacie poświęconym wdrożeniu CRM nikt – przez trzy godziny – nie pyta o to, jak dane będą migrowane ze starego systemu, są dwie możliwości: albo wszyscy uznają to za oczywiste (i mają różne wyobrażenia, co to oznacza w praktyce), albo temat jest tak drażliwy, że nikt nie chce go ruszyć. Obie sytuacje są kłopotliwe. Żadna z nich nie wynika z analizy transkryptu.

4. Emocja przy z pozoru błahym wymaganiu

„No i żebyśmy mogli sami edytować te pola bez angażowania IT” – brzmi jak drobny szczegół techniczny. Ale sposób, w jaki to powiedziano – z wyraźną frustracją, z naciskiem na „sami” – mówi coś zupełnie innego. Za tym zdaniem kryje się historia: prawdopodobnie poprzedni system albo poprzedni dostawca sprawił, że każda zmiana była blokowana na miesiące, a dział IT był wąskim gardłem, na które ktoś czekał zbyt długo.

To nie jest wymaganie dotyczące uprawnień w systemie. To wymaganie dotyczące autonomii i zaufania. Jeśli tego nie zrozumiemy, możemy technicznie zrealizować funkcjonalność i zupełnie nie trafić w oczekiwania.

5. To, co pada poza salą

Rozmowa przy kawie przed warsztatem. Komentarz w korytarzu po nim. Wiadomość na Teamsach od jednego z uczestników, który „zapomniał powiedzieć coś ważnego.”

W tych momentach ludzie mówią rzeczy, których nie powiedzieliby przy stole z przełożonymi albo z zewnętrznym dostawcą. Że poprzednie wdrożenie skończyło się źle i wszyscy się tego boją. Że jeden z kluczowych użytkowników już teraz mówi, że i tak tego nie będzie używał. Że termin jest nierealny, ale nikt nie odważy się tego powiedzieć głośno na spotkaniu.

Żaden model językowy nie przetworzy rozmowy, która nigdy nie trafiła do nagrania.

Kiedy pominięty sygnał kosztuje projekt

Wyobraźmy sobie typowy scenariusz: warsztat z działem obsługi klienta przed wdrożeniem nowego systemu ticketowego. Transkrypt jest kompletny, wymagania zebrane, analiza gotowa. W transkrypcie pojawia się zdanie: „ważne, żeby system był prosty, bo nasze panie nie są zbyt techniczne.”

AI wyekstrahuje: wymaganie dotyczące prostoty interfejsu. Słuszne.

Ale konsultant obecny na sali zapamiętał coś innego: że zdanie to padło z wyraźnym zniecierpliwieniem jednej z kierowniczek, a kilka „pań” wymieniło między sobą spojrzenia. I że po warsztacie jedna z nich podeszła i powiedziała nieoficjalnie, że „szkolenia z poprzedniego systemu były fatalne i nikt nam niczego porządnie nie wytłumaczył.”

Problem nie leżał w interfejsie. Leżał w braku zaufania do procesu wdrożenia i w doświadczeniu złego onboardingu. Uproszczony interfejs tego nie naprawił. Solidny plan wdrożenia i zmiana sposobu prowadzenia szkoleń – tak.

Różnica między tymi dwiema diagnozami to różnica między wdrożeniem, które działa, a wdrożeniem, które działa technicznie, ale nie jest używane.

Na czym polega discovery prowadzone przez doświadczonego konsultanta?

To nie jest kwestia metodyki ani listy kroków. To kwestia postawy i kontekstu.

Doświadczony konsultant prowadzi warsztat tak, żeby napięcia i sprzeczności wyszły na wierzch – zadaje pytania, które trochę niewygodnie milczą po sobie, obserwuje dynamikę grupy, celowo wraca do tematów, przy których atmosfera się zmieniła. Po warsztacie weryfikuje rozumienie nie przez „czy zapisaliśmy wszystko poprawnie?”, ale przez „oto, co usłyszeliśmy – co w tym jest nie tak?” Ta różnica w sformułowaniu zmienia odpowiedzi, jakie dostaje.

Dochodzą do tego wiedza branżowa i doświadczenie z poprzednich projektów: umiejętność rozpoznania, że „chcemy integrację z ERP” oznacza zwykle trzy miesiące dodatkowej pracy, albo że konkretny układ sił w organizacji zazwyczaj prowadzi do zmiany zakresu w połowie projektu.

AI może wspierać ten proces – transkrybować, kategoryzować, wyszukiwać powtarzające się wątki, przygotowywać pierwszą wersję dokumentacji wymagań. To realna pomoc. Ale interpretacja kontekstu, relacji i tego, co przemilczane, wciąż wymaga człowieka z doświadczeniem w terenie.

Granica, której nie warto przesuwać za wcześnie

Modele językowe są coraz lepsze w rozumieniu tekstu. Być może za kilka lat narzędzia AI będą analizować nagrania wideo z warsztatów, wychwytywać mowę ciała, ton głosu, przerwy w mówieniu. Może.

Dziś jednak granica jest wyraźna: AI przetwarza to, co zostało wyrażone. Konsultant interpretuje to, co zostało wyrażone, w kontekście tego, co nie zostało powiedziane. I to drugie jest często ważniejsze.

W projektach wdrożeniowych koszt błędnie zrozumianego wymagania rośnie wykładniczo wraz z etapem projektu. Discovery to moment, w którym ten koszt jest najniższy. Warto go nie oszczędzać na narzędziu, które nie widzi całego obrazu.

Jesteś gotowy na prowadzenie dużego projektu wdrożeniowego w Twojej firmie?

Wiesz, o co zapytać dostawcę? Jak przygotować własny zespół? Jak stworzyć skuteczne zapytanie ofertowe? Jaką metodykę wybrać? Na co zwrócić uwagę negocjując umowę wdrożeniową i serwisową?

Specjalnie dla Ciebie stworzyliśmy darmowy kurs mailowy przygotowujący do prowadzenia wdrożeń.

Codziennie przez dwa tygodnie otrzymasz od nas na swoją skrzynkę kolejną dawkę wiedzy, która pozwoli odnaleźć Ci się w tym skomplikowanym procesie.

dowiedz się więcej o kursie

Darmowy kurs mailowy