niedziela, 30 października 2016

Ci klienci to są jednak idioci

Ci klienci to są jednak idioci. Wymyślają niestworzone historie, wymagają, ciągle zmieniają zdanie, a na końcu i tak są niezadowoleni. A że po terminie, a że jednak chodziło o coś innego...
Czy zaskakujące jest jak często zawracają nam głowę i nie potrafią zrozumieć kilku prostych kwestii? Nie. Zaskakujące jest jak wiele osób wciąż ma właśnie takie wyobrażenie klientów. A przecież od wielu dekad autorytety, jak chociażby Peter Drucker, starają się nas nauczyć jak jest naprawdę.
Właśnie. Jak to jest naprawdę? Gdzie leży problem na linii IT - klienci?

Wiele razy spotykałem się ze stwierdzeniami wspomnianymi we wstępie. Ba! Wiele razy, jak sięgnę pamięcią, sam takie tezy wygłaszałem. Dzisiaj się z nimi zupełnie nie zgadzam, chociaż przyznać muszę, że miałem okazję w swojej karierze spotkać osoby, które delikatnie mówiąc nie były zbyt lotne. Dotyczyło to jednak zarówno klientów jak i specjalistów IT...

Skąd to się bierze?


Parę ładnych lat temu rozmawiałem z moim znajomym - początkującym deweloperem - na temat jednego z jego projektów. Narzekał wówczas na to, że po raz kolejny klient zmienił wymaganie co do pewnych funkcjonalności. Wymagało to sporej przebudowy istniejących już komponentów. Dziwił się sfrustrowany, dlaczego klient wprowadza tą zmianę, dlaczego w momencie kiedy projekt jest na ukończeniu i dlaczego project manager na to pozwala. Słowa, których wówczas używał nie nadają się do przytoczenia.

Trochę czasu upłynęło, temat przewijał się w wielu książkach, czy artykułach, które miałem okazję czytać. Uwierzyłem, że wiedza, która z nich płynęła trafiła nie tylko do mnie, ale w jakiś magiczny sposób także do innych, wszystkich doświadczonych pracowników.
Zdziwiłem się, chociaż pewnie nie powinienem, kiedy kilka dni temu na spotkaniu, którego byłem uczestnikiem, padały mniej więcej podobne tezy jak te, które wygłaszał mój kolega.
Jedna sprawa to kwestia kompetencji, z czym może być różnie u niektórych osób (klientów także). Zupełnie czym innym jednak jest sprawa "mieszania" w projektach.

Skąd się taka wroga postawa wobec decyzji klienta bierze? Moim zdaniem z dwóch prostych powodów. Sądzę, że żadna z wspomnianych osób - mój kolega, czy uczestnicy spotkania - nie zadała sobie dwóch ważnych pytań:

  1. Dlaczego klient chce coś zmieniać, jakie powody nim kierują?
  2. Dlaczego ja, developer, tworzę oprogramowanie?

Klient to jednak nie jest idiota...


Pierwsze z pytań wydaje się oczywiste, banalne. I być może z tego powodu właśnie go nie zadajemy. A jak się głębiej nad tym zastanowić, to dopiero zadanie go klientom ORAZ samemu sobie pozwoli zrozumieć gdzie leży przyczyna zmian, czy jest to widzimisię klienta czy może jednak to my zrozumieliśmy źle jego potrzebę.

Musimy mieć świadomość, że klienci mają tendencję do proszenia o coś, co w ich mniemaniu jest rozwiązaniem ich problemów. To jednak do naszych zadań, specjalistów IT, należy zaproponowanie im najlepszego możliwego rozwiązania - to my mamy kompetencje, które na to pozwalają! Za każdym razem, kiedy usłyszycie, że pan Mietek chce funkcjonalność X powinna wam się zapalić lampka ostrzegawcza, a pierwszym odruchem powinno być zadanie pytania "dobrze, ale po co pan tego chce, do czego pan tego potrzebuje, jaką potrzebę ta funkcjonalność ma spełniać?".

Doskonale opisuje to Michał Bartyzel w książce "Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie czego chce". Proponuje on przyjąć następujące stwierdzenia:

  • "Klient zawsze wie, czego chce — wie, że chce rozwiązać jakiś problem, osiągnąć jakiś cel, coś usprawnić.
  • Klient nie zawsze wie, czego potrzebuje — ponieważ jest skupiony przede wszystkim na swoich procesach biznesowych.
  • Klient często nie zdaje sobie sprawy z konsekwencji swoich oczekiwań — gdyż jest ekspertem w obrębie swojej działalności biznesowej, a nie w obszarze technologii informatycznych." *

Dołączam się do jego prośby - przyjmijmy te stwierdzenia za pewnik.

Programista jako superbohater


Pamiętam rozmowę z moim znajomym, Scrum Masterem, który akurat był świeżo po konferencji agile'owej. Zabijcie mnie, ale nie jej pamiętam nazwy. Opowiadał wówczas o wystąpieniu jednego z gości, który podczas prelekcji zadał pytanie "po co tworzymy oprogramowanie?". Odpowiedź powinna być jeszcze prostsza niż na wcześniejsze z kluczowych dla nas pytań. Ale właśnie, po co? Prawda jest być może brutalna, ale trzeba ją sobie uzmysłowić.

Nie implementujemy dla siebie. Nie kodujemy, żeby sobie pokodować. Nie przychodzimy do pracy, żeby usiąść, wypić kawkę i poprogramować fajne rzeczy. Pomimo, że dla wielu z nas, jeśli nie wszystkich, programowanie to hobby, musimy sobie uświadomić, że tworzymy oprogramowanie dla naszych klientów. Nie robimy tego dla siebie! Być może trzeba czasami pracować z kiepskim kodem, w technologiach sprzed kilkunastu lat, z systemem, który wymaga wprowadzenia wielu usprawnień, żeby w ogóle praca szła płynnie. Ale robimy to, pokazując przy okazji nasz kunszt, żeby pomóc innym ludziom rozwiązać ich problemy!

Następnym razem, kiedy najdzie Cię ochota na stwierdzenie "ten gość znowu miesza w projekcie", przypomnij sobie dlaczego jesteś specjalistą i jak możesz swoje umiejętności wykorzystać i wciel się w role mentora. Zrozum potrzeby klienta i zaproponuj lepsze rozwiązanie. Bądź bohaterem! Niech klienci i współpracownicy widzą w Tobie mędrca, którego można obdarzyć zaufaniem i szacunkiem.

Częściowo z pomocą przychodzą nam metodyki agile, w których ciągłe zmiany, brak szczegółowych wymagań co do całego systemu są naturalne. Często się o tym zapomina, ale właśnie ta ich cecha sprawia, że przyzwyczajamy się do zmian "widzimisię" klienta. Mało tego, bierzemy to za rzecz oczywistą i nie powoduje to w nas niepotrzebnej frustracji i stresu.

My, profesjonaliści


Jeśli chcemy się uważać za profesjonalistów, musimy zdać sobie sprawę z tego po co tworzymy oprogramowanie i jak ten proces (w tym jego cel) widzi klient. Nie mając tego świadomości będziemy implementować nie to, czego tak naprawdę oczekuje, bo tak naprawdę nawet nie zadamy sobie trudu, żeby zrozumieć jego potrzeby. A zrozumienie ich pozwoli nam uniknąć frustracji i pracować wydajniej, a klientowi osiągnąć satysfakcję zarówno z końcowego produktu jak i ze współpracy z nami. W praktyce oznacza to również, że będzie o nas pamiętał, kiedy następnym razem będzie potrzebował developera.
Z tych wszystkich powodów uważam, że już na początku kariery ważne jest, żeby juniorzy uzmysłowili sobie, że dla klientów (czy to bezpośrednio ich, czy ich firmy) są partnerami i takie mieli nastawienie. To jest oznaka dojrzałości i profesjonalizmu w tym zawodzie.

* M. Bartyzel, "Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce.", Wyd. Helion

Brak komentarzy:

Prześlij komentarz