Tak, to jest możliwe ????. Zacznijmy od tego, że gdy rozmawiasz z klientem bądź innymi interesariuszami na temat ich oczekiwań, to każda ze stron coś sobie wyobraża. Każda ze stron wyobraża sobie to, co na samym końcu współpracy zostanie dostarczone. Niestety nie masz żadnego wpływu na to, co sobie Twoi rozmówcy wyobrażają. To się zwyczajnie dzieje samo przez się.

Czasem owe wyobrażenia przybierają skrajną formę czytania w myślach. Zerknij na artykuł Mindreading w praktyce, gdzie na przykładzie twitterowej dyskusji ilustruję, jak działa dopowiadanie sobie różnych rzeczy, do tego co powiedzieli rozmówcy. Potocznie nazywamy to zjawisko mindreadingiem.

Wspomniany artykuł opisuje "doczytywanie" w myślach, jako błąd komunikacyjny. W kilku poniższych akapitach podpowiadam, w jaki sposób możesz czytać (no, powiedzmy:)) klientowi w myślach po to, aby usuwać błędy komunikacyjne. Tak, jak wspomniałem na początku błędy te powstają, ponieważ każde z Was wyobraża sobie różne rzeczy na temat tego, co zostanie dostarczone w wyniku współpracy.

Powiedz, czego nie będzie

Definiując oczekiwania, skupiamy się mocno na tym, co ma być. Definiowanie tego, co ma być, skupia rozmowę na precyzowaniu oczekiwań, które zostały wyrażone i wypowiedziane na głos. Jednak bezwiednie uruchamiający się proces "wyobrażania sobie" końcowego efektu sprawia, że rozmówcy mają sporo oczekiwań nie ujawnionych, nigdy nie wypowiedzianych na głos. Co z nimi?

Zaraz po tym, gdy określisz "co zostanie dostarczone", skup się na oczekiwaniach, które "nie zostaną" dostarczone. Definiujemy zatem dwie części oczekiwań in scope / out of scope.

Przykład

Przypuśćmy, że ustaliłeś oczekiwanie:

  • Aby skorzystać z funkcjonalności X, użytkownik musi się zalogować
    • Logowanie będzie odbywać się za pomocą loginu i hasła
    • Hasło można zresetować za pomocą linku resetującego hasło

Powyższe wyspecyfikowanie dotyczy tego, co zostanie dostarczone (in scope). Koniecznie dodaj następnie specyfikację tego, co nie zostanie dostarczone (out of scope). Możesz na przykład napisać tak,:

  • Poza zakresem są:
    • 2FA,
    • blokowanie konta przy wielokrotnej próbie błędnego zalogowania się,
    • odzyskiwanie hasła za pomocą innego kanału niż email,
    • weryfikacja miejsc i urządzeń, z których nastąpiła próba logowania,
    • zbieranie historii logowań.

Jak widzisz w sekcji out of scope wypisujesz te rzeczy, którego według Twojego doświadczenia, mogłby jeszcze się tam znaleźć. Na przykład inni klienci o nie prosili.

Część out of scope możesz opisać od razu. Chociaż ja polecam nie robić tego w trakcie jednego spotkania. Robiąc analizę prawdopodobnie masz ustalone cykliczne spotkania z klientem. Zatem spisz oczekiwania, potem przeanalizuj je w cichości własnego biurka, a na kolejnym spotkaniu przedstaw zarówno in scope jak i out of scope.

[mailerlite_form form_id=1]

Ujawnij swoje założenia

Gdy przedstawiasz klientowi specyfikację, zwłaszcza gdy przedstawiasz ją do akceptacji i zwłaszcza, gdy zawierają wyceny lub szacowania, dołącz do niej założenia. Założenia to odpowiedź na pytanie Co muszę przyjąć za pewnik, aby to co przedstawiłem klientowi, doszło pomyślnie do skutku?

Przykład

Załóżmy, że in scope oraz out of scope zostało określone, jak poprzednio. Do tej specyfikacji można by dodać na przykład takie założenia:

  • Możemy integrować się tylko Google ID,
  • Serwer, z którego mamy pobierać dane posiada API, którego możemy używać,
  • Prace rozpoczniemy najpóźniej w dniu XYZ.

Ponownie chodzi o to, aby możliwie wcześnie porozmawiać o sprawach, które mogą się nie udać.

Poproś o przykład użycia

Hipotetyczne problemy mają hipotetyczne rozwiązania, konkretne problemy mają konkretne rozwiązania. Najprostszym sposobem na sprowadzenie rozmówcy od problemu hipotetycznego do konkretnego, jest zapytanie lub poproszenie:

  • Podaj przykład użycia tej funkcjonalności,
  • W jakich sytuacjach zamierzasz skorzystać z tej funkcjonalności?
  • Jak często występują sytuacje, które sprawiają, że potrzebujesz tej funkcjonalności?
  • Jak długo trwają sytuacje, które sprawiają, że potrzebujesz tej funkcjonalności?

Tego typu pytania i prośby stawiają rozmówcę w realnej sytuacji, w której zastanawia się nad swoimi oczekiwaniami z perspektywy konkretnych przypadków użycia. Nie stara się rozważać wyższości Świąt Wielkiej Nocy nad innymi. Jego uwaga skupiona jest na rozwiązywaniu konkretnych problemów. Garbage in, garbage out :)

Z mojego doświadczenia wynika, że zadając te pytania, bardzo często klient sam dochodzi do wniosku, że dana funkcjonalność nie jest mu do niczego potrzebna.

Podsumowując

Uprzedzam pytanie: w opisanych przykładach, nie chodzi o tworzenie tzw. d*pochronu. Zdecydowanie nie chodzi o to, aby powiedzieć klientowi: tego nie było w wymaganiach. Celem jest tu możliwe wczesne porozmawianie o sprawach, które staną kwestiami spornym przy okazji podpisywania protokołu odbioru. A że się staną, to więcej niż pewne :)

Zwróć uwagę, że opisane metody:

  • Powiedz, czego nie będzie,
  • Ujawnij swoje założenia,
  • Poproś o przykład użycia,

sprawiają, że wyciągasz na wierzch to, co klient pomyślał, ale nie powiedział na głos. Jak nic czytanie w myślach! :)

.