„Potrzebuję liczb!”

Załóżmy, że to zdanie, zdecydowanie mieszczące się w granicach „niemożliwego do wymyślenia na poczekaniu”, wypowiada szef działu inżynieryjnego. Wyobraźmy sobie też, że chce on w ten sposób uzyskać dane liczbowe dotyczące wydajności wyszukiwarki danych, aby móc określić, czy kod związany z obsługą baz danych działa zgodnie z wymogami specyfikacji.

Taka prośba brzmiałaby rozsądnie, gdyby nie pewien mały szkopuł: kod związany z obsługą baz danych generuje nieprawidłowe wyniki. Kwestia wydajności ma stosunkowo niewielkie znaczenie, biorąc pod uwagę fakt, że szybkie uzyskiwanie nieprawidłowych odpowiedzi niekoniecznie się przydaje, choć na pewno jest mniej irytujące niż konieczność długiego czekania na rezultaty. To trochę jak jazda z prędkością 200 km/h, gdy kierowca zgubił drogę – niekoniecznie wiemy, gdzie jesteśmy lub dokąd zmierzamy, ale wydaje się, że szybciej dotrzemy do celu.

Wyobraźmy też sobie drugą sytuację: inżynierowie pracujący nad rozwojem pakietu służącego do analizy danych bioinformatycznych spędzają godziny na dyskusjach nad prawidłowym sposobem określenia elementów GUI. Problem polega jednak na tym, że podczas wykonywania obliczeń program się zawiesza. Każdy zapewnia, że program „potrzebuje po prostu więcej czasu na wykonanie obliczeń”. Ile? No, może kilka tygodni.

Dla tych nielicznych osób, które nigdy nie korzystały z komputera, taka odpowiedź może być szokująca. Ale kilka tygodni w zupełności wystarczy na to, aby doszło do jakiejś awarii. Co więcej, brak odpowiedzi ze strony programu zazwyczaj jest dla użytkowników wystarczającym dowodem na to, że nastąpiło uszkodzenie programu. Ale opracowujący go inżynierowie z reguły nie chcą zamieścić żadnego wizualnego wskaźnika postępu w obliczeniach, bo ich zdaniem nie wyglądałoby to ładnie. Odmawiają też usunięcia wprowadzonego do programu modułu do obliczeń, ponieważ „ktoś inny mógłby wprowadzić takie rozwiązanie”. Ostatecznie, niechętnie zgadzają się na umieszczenie ostrzeżenia dla użytkowników przed „bardzo długim działaniem programu”.

W obu przypadkach rozstrzygany jest niewłaściwy problem. Mimo zdecydowanie wielu skarg dotyczących powolnego działania programu, prędkość stanowi kwestię drugorzędną, dopóki baza danych generuje prawidłowe wyniki. I chociaż decyzje dotyczące interfejsu użytkownika są na pewno kluczowe, to projektowanie eleganckiego widoku bez funkcji informującej użytkownika o tym, że program działa prawidłowo lub nie, na pewno nie jest dobrym rozwiązaniem. Obrazowym przykładem jest przestawianie leżaków na Titanicu, które w obliczy katastrofy było tylko stratą czasu i nie miało żadnego wpływu na zatonięcie statku.

Dlaczego więc tak uporczywie próbujemy rozwiązywać niewłaściwe problemy? Otóż, jeśli dajemy komuś zadanie, które można wykonać w prosty sposób, ale ten ktoś nie wie, jak do niego podejść, będzie koncentrować się na niewłaściwym aspekcie tego zdania. Taka osoba wyznaczy sobie cel, który stanie się jej priorytetem i na którym skupi całą swoją uwagę, a jego osiągnięcie będzie wymagało sporo wysiłku. To właśnie najlepszy i, jednocześnie, najgorszy aspekt wyznaczania celów.