Praca programisty bardzo mocno różni się od pracy konsultanta IT. Pisząc kolejne linie kodu bardziej się skupiamy na wzorcach projektowych niż na realnym wykorzystaniu naszego kodu przez użytkowników. Każdy z nas wiele razy kłócił się z kolegami o wykorzystaniu tej czy tamtej biblioteki, bo jest przystępniejsza w testowaniu jednostkowym, ma bogatsze API lub jest polecana przez naszego ulubionego blogera. Traktujemy nasz projekt jak piaskownicę, tylko zamiast łopatek i hałd piasku mamy nowe bazy danych i frameworki. Zapominamy, że nasz projekt ma działać i dawać wartość klientowi, a dopiero później ma spełniać nasze programistyczne ego.
Takie zachowanie jest niemożliwe, gdy pracuje się jako konsultant IT i tworzy się rozwiązanie bezpośrednio z klientem. Wtedy trzeba zrozumieć jak rozwiązywać jego problemy, a szarże programistyczne odstawić na drugi plan. Bardzo ważne jest pełne zrozumienie procesów biznesowych klienta i odpowiednia praca z nim.
Jako programista wchodzący w rolę konsultanta popełniałem błędy typowe dla osoby, które o powyższych rzeczach dopiero się uczy. Zebrałem je by pokazać w jaki sposób lepiej zrozumieć naszych klientów i wypełniać naszą pracę.
Zrozumienie języka klienta
Warto się wsłuchać dokładnie w język, jakiego używa klient podczas rozmów z nami. Może on wykorzystywać specjalistyczne, branżowe słownictwo, które może nam się na początek wydawać dziwne i odpychające. Nie starajmy się jednak narzucać mu własnego języka. Rzeczy, które wydają nam się synonimami, bardzo często wcale nimi nie są. Klient może mieć szczegółową nomenklaturę słów opisującą jego proces biznesowy, która zakłada minimalną rozbieżność. Próba zamiany zwrotów będzie się wtedy kończyła niepotrzebnymi nieporozumieniami. W naszych rozmowach możemy nawet spróbować użyć tych samych zwrotów po kilka razy, by mieć 100-procentową pewność, że prawidłowo rozumiemy to, co klient ma na myśli. Tylko wtedy będziemy w stanie dojść do jedności językowej i w pełni zrozumieć jaki cel biznesowy ma nasz klient.
Kontynuacja aktualnego procesu
Bardzo często pisana przez nas aplikacja nie jest pierwszym systemem jakiego używa klient. Może on mieć stworzony system, który aktualnie z różnych powodów przepisujemy na nowy. Czasami klient działa na obszernych arkuszach Excela wysyłanych tylko w jedną lub drugą stronę, lub wszystko opiera się na zwykłych kartkach papieru, które dzień w dzień zapisywane są tuszem długopisów. Ważne jest, by aktualne procesy dobrze zrozumieć aby potem poprawnie przełożyć je na naszą nową aplikację. Zmiana będzie tym łatwiejsza, im bardziej nasz nowy system będzie odwzorowywał aktualne zachowania klienta. Jeśli znamy już domenę na tyle, by móc narzucać pewne rozwiązania, postarajmy się to dobrze wyjaśnić użytkownikom systemu, by zrozumieli jakie zmiany za tym szły i co chcemy ulepszyć w ich procesie.
Rozpoczęcie od małych kroków
Duża ilość projektów upadła, ponieważ chciała od zera reorganizować pracę całych działów. Często lepszym rozwiązaniem jest stopniowe dostosowywanie aplikacji do wymagań klienta, gdyż będzie on nam w stanie dostarczać informacji czy rozwój idzie w dobrą stronę czy nie. Dzięki temu będziemy mieli szybką odpowiedź, czy nie powinniśmy zmienić kierunku naszego rozwoju i skupić się na innych fragmentach. Dodatkowo, użytkownicy systemu będą mieć do nas większe zaufanie i chętniej będą się dzielili z nami kolejnymi uwagami. Zobaczą, że nasza praca przynosi im wymierną korzyść i nie muszą czekać na kolejne wdrożenia kilku miesięcy.
Zrozumienie obaw użytkowników
Każdy nowy program przynosi zmiany. Ludzie z zasady nie lubią zmian. Każdy ma swoją strefę komfortu, w której się czuje dobrze. Wdrażając nasz program pozbawiamy ich tej strefy, przez co nie zawsze mogą podchodzić entuzjastycznie do naszego systemu. Ważne by nie traktować tego negatywnie - każde obawy mają swoje przyczyny i ich zrozumienie pozwoli nam na lepszy rozwój systemu przez rozprawienie się z nimi w zarodku. Pracownicy, widząc że staramy się zrozumieć ich argumenty i je rozwiązywać, będą dla nas bardziej przychylni. W przeciwnym wypadku może dość nawet do sabotowania projektu - pracownicy, których stale pomijamy mogą starać się, by projekt został anulowany, ponieważ nie przynosi im żadnej korzyści, a jedynie dokłada niepotrzebnej pracy.
Wyważenie kolejności funkcjonalności
Planując aplikację warto się dobrze zastanowić, które elementy dadzą użytkownikom największą wartość, a które są tylko opcjonalne. Łatwo jest wpaść w pewną domenę biznesową, w której czujemy się dobrze i dodajemy kolejne funkcjonalności jedna po drugiej. Jednak w tym samym czasie inne działy firmy mogą cierpieć, ponieważ ich część nie jest tak szybko rozwijana. Warto wtedy przypomnieć sobie zasadę Pareta, która mówi, że 20% czasu zajmie nam funkcjonalność dająca 80% wartości. Równowaga pomiędzy działami implementowanych funkcjonalności jest ważna, by program mógł pracować jako całość. Jest naturalne, że dział przynoszący największą korzyść firmie będzie najbardziej rozwijany, ale bardzo często niewielkie zmiany w dziale wspierającym mogą realnie podnieść wydajność korzystania z aplikacji i przez to wspomóc cały proces. Jako że często nasz klient może nie mieć dużej wiedzy jaka powinna być kolejność nowych funkcjonalności i to my w pewnym sensie narzucamy kolejne kroki rozwoju, warto się skupić na tych, które będzie dopełniać MVP projektu, a następnie przejść w detale.
To tylko kilka z przemyśleń, które wpadły mi do głowy podczas ostatnich prac nad projektem. Jeśli chcielibyście do tego tematu coś dodać, lub się na coś nie zgadzacie, to z chęcią przeczytam waszą opinię na ten temat.
Comments:
Kilka porad o pracy bezpośrednio z klientem | RadBlog
Dziękujemy za dodanie artykułu - Trackback z dotnetomaniak.pl
