Przez 6 tygodni budowaliśmy niewłaściwy produkt
Przez sześć tygodni budowaliśmy coś zupełnie innego, niż było potrzebne. Klient nigdy nie narzekał. I to był właśnie problem.
To nie jest tekst o narzędziach czy trikach zwiększających produktywność. Chodzi o bolesną prawdę.
Klient z branży medycznej poprosił nas o system rezerwacji wizyt dla pacjentów. Zadawaliśmy pytania. Potakiwaliśmy. Zaczęliśmy budować.
W szóstym tygodniu pokazaliśmy im demo. Klient zamilkł.
Powiedzieli: „To jest świetne. Ale pielęgniarki nie rezerwują wizyt. Robią to koordynatorzy ubezpieczeń. Ich proces pracy wygląda inaczej”.
Nikt nie kłamał. Nie doszło do błędnej komunikacji. Po prostu zapomnieliśmy zapytać, kto będzie używał tego oprogramowania na co dzień.
Najdroższy kod to taki, który rozwiązuje niewłaściwy problem. Najgorszy kod to nie ten, który się zawiesza. To ten, który działa idealnie, ale nie rozwiązuje niczego.
Oto nasze największe błędy:
- Pominięcie persony użytkownika. Budowaliśmy produkt dla osoby podejmującej decyzje, a nie dla faktycznego użytkownika.
- Mylenie akceptacji z poprawnością. To, że klient mówi „tak”, nie oznacza, że produkt jest właściwy.
- Traktowanie akceptacji jako tarczy. Jeśli nie pokazałbyś swojej pracy komuś, kogo szanujesz, nie używaj akceptacji klienta jako wymówki.
- Traktowanie wdrożenia jako linii mety. Sukces następuje po uruchomieniu produktu.
Jak to naprawić:
Bądź jednoznaczny, gdy się nie zgadzasz. Powiedz klientowi: „Zbudujemy to, ponieważ o to prosicie. Jednak uważamy, że X spowoduje Y. Odnotujmy to na piśmie”.
To zdanie zapobiega późniejszemu szukaniu winnych.
Przestań traktować wdrożenie jako koniec. Potrzebujesz śledzenia błędów, alertów dotyczących dostępności (uptime) oraz jednego dashboardu do monitorowania współczynnika błędów i opóźnień (latency). Potrzebujesz także dokumentacji dla samego siebie w przyszłości.
Jaki błąd wciąż popełnia Twój zespół?