Zdarza się, że pracuję nad projektem dla klienta już sporo czasu. Czuje się całkiem pewnie w jego domenie, dogaduję się z nim dobrze i czuję się odpowiedzialny za jego sukces. Zależy mi na tym, aby robić dobrą robotę, nie klepać na ślepo kolejnych linijek kodu.

W pewnym momencie pojawia się wymaganie, które burzy mój cały pogląd na problem. Jest mocno niespójne z tym, co wierzyłem, że jest celem istnienia projektu. Jego implementacja jest bardzo kosztowna czasowo, a jednocześnie wydaje się nie mieć wymiernej korzyści. Wymaganie to, jak się wydaje, może pochodzić z nieznanego dotąd źródła.

Spotkałeś się z podobną sytuacją? Możliwe, że kiedyś klient poprosił Cię o dodanie funkcji bez szerszego kontekstu, która wydała Ci się niepotrzebna, a jednocześnie bardzo czasochłonna.

Co powinieneś zrobić?

Zawsze możesz wybrać opcję siedzenia cicho i posłuszną implementację. Jednocześnie przymknąć oko na to, że tym razem nie widzisz ani korzyści, ani korzyściobiorcy tego rozwiązania.

Jeśli jednak zależy Ci na powodzeniu projektu tak jak mi, nie sądzę, abyś od razu zgodził się z powyższym podejściem. Nie znając problemu, który rozwiązujesz, nigdy nie możesz być pewien, że to, co robisz, odniesie jakikolwiek pozytywny skutek.

Lepszym rozwiązaniem może być postawienie się i próba wytłumaczenia klientowi, że to zły pomysł. Możesz wspomnieć, że ta funkcja będzie go dużo kosztować i nie jesteś pewien, czy przynosi jakąkolwiek korzyść. Mógłbyś poprosić o wyjaśnienie, jaki problem biznesowy kryje się za tym wymaganiem. Czy to lepsza droga?

Oczywiście, że tak. Co jeśli nadal nie potrafisz zrozumieć odpowiedzi na zadanie pytania? Możesz zacząć zastanawiać się, czy problem nie leży przypadkiem w Twoich umiejętnościach komunikacyjnych. Możliwe też, że to klient nie potrafi dobrze wyjaśnić swojego problemu.

Często odpowiedzią może być właśnie to, że wymaganie przyszło z innego źródła niż dotychczas. Źródła, które pomimo że niewidoczne, ma znaczny wpływ na kształt projektu. Co to jest i jak sobie z tym poradzić? Jak zadbać o interesariusza, którego nie widać, a jednocześnie pogodzić jego potrzeby z interesami reszty podmiotów wpływających na projekt?

A komu to potrzebne?

źródło: pixabay.com

Jako inżynierowie wypracowaliśmy sobie szereg mechanizmów obronnych i zabezpieczeń przed takimi sytuacjami. Mamy swój święty proces, swoje narzędzia planowania i mur ludzi stojący pomiędzy nami a klientem. Mamy środki, którymi zazwyczaj staramy się bronić przed wymaganiami, które w naszej ocenie są szkodliwe lub kosztowne. Nie zawsze skutecznie, ale stosowane w dobrej wierze.

Te wszystkie mechanizmy obronne istnieją po to, w teorii, żeby zapewnić jakość produktu, który tworzymy. Ani ja, ani Ty przecież nie chcemy zaszkodzić projektowi.

Co jeśli działając zgodnie z tymi mechanizmami obronnymi znacząco odsuniemy w czasie lub całkiem odrzucimy wymaganie, które może zaważyć o losie projektu? Co jeśli działając w dobrej wierze sprowadzimy negatywne konsekwencje na nas i nasz zespół?

A co, jeśli pójdziemy w odwrotnym kierunku i bez większego zrozumienia spełnimy wymaganie, które ostatecznie okaże się bardzo kosztowne i zbyteczne? Wiem, przecież to klient sam tego chciał. W ostatnim artykule pisałem jednak, że w ostateczności wina często spada na inżyniera.

Czy jest jakiekolwiek rozwiązanie tej sytuacji, które nie polega na liczeniu na szczęście?

Asymetria informacji w tworzeniu oprogramowania dla klienta

Istnieje co najmniej jeden sposób, jak poradzić sobie w takiej sytuacji. Ten, z którego ja korzystam, wymaga trochę pracy „detektywistycznej” i zgłębienia informacji, często wykraczających poza specyfikację techniczną.

Projekt nigdy nie jest zawieszony w próżni. Nawet jeśli wydaje nam się, że w doskonały sposób określiliśmy jego beneficjentów i spełniamy wszystkie ich potrzeby, może brakować nam wielu elementów do pełnego zrozumienia środowiska, w którym projekt istnieje.

Często zdarza się, że w środowisku czai się jeszcze „ukryty” interesariusz lub interesariusze.

Co to jest i czy jesteśmy w stanie zawrzeć takiego beneficjenta w specyfikacji projektu, jednocześnie dostarczając mu korzyści?

Częstą sytuacją jest, że przedstawiciel klienta, z którym współpracujemy, nie jest faktycznym właścicielem interesu. Jest po prostu pracownikiem firmy, z którą współpracujemy. Co się dzieje w tej firmie? Jakie panują w niej relacje pomiędzy człowiekiem, z którym rozmawiamy na co dzień, a resztą organizacji? Jakie decyzje zapadają i w jaki sposób? Często odpowiedzi na te pytania są dla nas niewidoczne.

Jest to jeden z przykładów asymetrii informacji, która ma pośredni wpływ na los i przebieg projektu, nad którym pracujemy. Rzeczy, które dzieją się poza zasięgiem naszego wzroku i osoby, z którymi nie mamy bezpośrednio kontaktu, wpływają na to, czego się od nas wymaga. Czasem ten „ukryty interesariusz” bywa kluczowy dla projektu i nawet jeśli cała reszta beneficjentów otrzymuje z niego korzyści, to projekt może upaść.

Jak odkryć coś, czego nie widać?

[caption id=“attachment_648” align=“aligncenter” width=“900”] źródło: pixabay.com[/caption]

Aby uzupełnić swoją wiedzę o brakującego, ukrytego interesariusza zazwyczaj postępuję wg poniższego schematu:

1.      Poszukiwanie sygnałów

Zaczynam od poszukiwania sygnałów, czyli analizy przeszłych i obecnych zachowań klienta, które mogą dostarczyć dodatkowej wiedzy na temat projektu. Sygnalizowanie to termin zaczerpnięty od Michaela Spence’a i jest jednym ze sposobów na modelowanie niepełnej informacji – w tym kontekście przychodzi od klienta.

Pośrednio lub bezpośrednio daje on znaki (sygnały), że są osoby, z którymi bezpośrednio nie mam kontaktu, a które oceniają moją pracę. Może to być przełożony mojego klienta. Może klient po review ze mną ma swoje własne review z zarządem firmy, z managerem, czy swoim największym klientem? Może zasięga opinii żony/męża, których zdanie ma duży wpływ na jego wizję produktu?

Takie osoby są dodatkowymi interesariuszami projektu i należy ich korzyści uwzględniać w pracy nad nim. Może się zdarzyć, że takie osoby nie wyrażają bezpośrednio swojej potrzeby, a starają się przemycić gotowe pomysły, które wspierają ich korzyść. Bez kontekstu nie zawsze jesteśmy w stanie zrealizować ich wizję, więc jak dojść do tego jakiej korzyści oczekują?

2.      Prześwietlanie

Tutaj wkracza prześwietlanie – proces zdobywania informacji o nowo odkrytych interesariuszach. Wszelka komunikacja w mediach społecznościowych, mailach, czy innych kanałach komunikacji, do których mam dostęp, może mi dać wskazówki dotyczące korzyści, których dany podmiot oczekuje od produktu. Czasem może być tych informacji mnóstwo, np. w długich konwersacjach mailowych przekazanych nam przez przedstawiciela klienta. Czasem będziemy szukać poszlak w internecie. Nie zawsze tych informacji jest dużo, ale warto znaleźć ich jak najwięcej, aby mieć podstawę do następnego kroku.

3.      Kawa na ławę – bezpośrednia komunikacja

Dopiero, gdy posiadam te wstępne zebrane dane, choćby w minimalnym stopniu, przychodzi czas, by wyłożyć kawę na ławę i porozmawiać z klientem na temat brakujących informacji. Muszę zweryfikować, czy wymaganie przyszło z tego źródła, które założyłem i czy jego celem jest uzyskanie takiej korzyści, jak założyłem.

Jeśli dzięki tym trzem krokom uda mi się dojść do faktycznego interesariusza i korzyści, której oczekuje, jestem w stanie racjonalnie ocenić wymaganie, które od niego przyszło. Może tę samą korzyść da się dostarczyć mniejszym nakładem pracy i szybciej? A może faktycznie to wymaganie jest mało istotne i spokojnie można odsunąć je w czasie?

Jak to zrobić w praktyce?

Najważniejszym elementem rozwiązania, jak zawsze, jest odpowiednia komunikacja. Zanim niespodziewane i dziwne wymaganie odrzucimy lub zaczniemy je bezrefleksyjnie implementować, warto problem poznać bliżej. Zobaczcie na przykład powyższego działania, który oparty jest na moich doświadczeniach.

Kiedyś pracowałem nad aplikacją dla firmy, zajmującej się wyceną dzieł sztuki u bardzo bogatych klientów. Jej głównym celem było ułatwienie procesu wprowadzania danych na temat wycenianych dzieł do systemu informatycznego.

W trakcie tworzenia aplikacji pojawiło się niezrozumiałe dla mnie wymaganie. Według niego, aplikacja POWINNA po zapisaniu danych kontaktować się z serwerem, przesyłając na bieżąco informacje, a POWINNA generować plik w starym formacie MS Access, który może potem zostać ręcznie zaimportowany do bazy danych.

Dlaczego? Podobno wygodniej użytkownikom w ten sposób uzupełniać informacje. Brakowało mi szerszego kontekstu, a klient nie był w stanie mi go zapewnić. Nie mogłem uwierzyć, że takie rozwiązanie będzie wygodniejsze dla nietechnicznych osób. Z kolei na pewno dodawanie do prostego CRUDa eksportu do pliku kompatybilnego ze starym MS Accessem podwyższa poziom skomplikowania aplikacji i czas pracy nad nią.

Jak w praktyce zastosować moje rady w takiej sytuacji?

Obserwuj uważnie

Jak wspomniałem wyżej, rozpoznanie rozpoczynam od poszukiwania odpowiednich sygnałów, które pojawiały się w komunikacji z klientem. Często okazuje się, że sygnały są bardzo wyraźne, ale z różnych powodów zostały zaniedbane.

Podczas wielu rozmów projektowych często padała informacja, że produkt dyskutowany jest na bieżąco z grupą użytkowników, którzy jeżdżą do klientów estymować dzieła sztuki. Nie rozmawiałem z tymi ludźmi bezpośrednio, nie wiedziałem kim dokładnie są. Jednak po uwzględnieniu tych sygnałów, uświadomiłem sobie, że mają oni silny wpływ na moją pracę.

Gdy rozpocząłem etap prześwietlania, wystarczyło w zasadzie parę minut w Google i na LinkedIn, aby odnaleźć osoby, które zajmują się w firmie odwiedzaniem klientów i wprowadzaniem danych na temat dzieł sztuki do estymacji. Całkiem przypadkiem natknąłem się na posty publiczne jednej z takich osób, w których prezentowała piękne widoki z wyspy nad Pacyfikiem, gdzie ostatnio odwiedzała klienta. Z posta dowiedziałem się, że wyspa jest cudowna, aczkolwiek prześwietlana osoba była odcięta od świat na parę godzin, gdyż nie ma tam dostępu do internetu. Dlaczego taka informacja była ważna?

Dało mi to dużo do myślenia w kontekście niezrozumiałego dla mnie wymagania.

Po szybkiej rozmowie z klientem udało się ustalić, że klienci, których dzieła sztuki są estymowane, często mają rezydencje w bardzo dziwnych miejscach, w których zazwyczaj nie ma dostępu do sieci.

[caption id=“attachment_649” align=“aligncenter” width=“450”] źródło: tenor.com/view/lol-wolf-of-wall-street-gif-5271430[/caption]

Ten problem spowodował, że jedna z osób zaangażowanych w ocenę projektu próbowała znaleźć  jego rozwiązanie. Oczywiście sam pomysł eksportu do pliku nie był idealny, ale po dojściu do faktycznej korzyści, której ten ukryty interesariusz oczekuje (możliwość pracy bez dostępu do internetu), wystarczyło zaproponować coś łatwiejszego i tańszego.

Wystarczyło dodać funkcję synchronizacji danych na żądanie i operować na danych lokalnych, dopóki użytkownik nie zechce ich wysłać do systemu.

Dlaczego to działa?

Żaden projekt, nad którym pracujemy, nie jest odizolowany od środowiska, w którym istnieje. Projekt posiada wielu interesariuszy, a część z nich może być niewidoczna na pierwszy rzut oka. Czasem dostarczenie im wartości może być konieczne z perspektywy przyszłości projektu.

Jako specjaliści w wytwarzaniu oprogramowania, wiemy, które akcje są opłacalne w kontekście technicznym w naszej pracy. Wiemy też, że często projekty upadają przez to, że powstawały w oderwaniu od faktycznych potrzeb jego odbiorców.

Dziwne wymagania nie biorą się z powietrza, często wyrażają jakąś potrzebę, która może być zaspokojona na wiele sposobów.

Dotarcie do sedna poprzez zdefiniowanie „ukrytego interesariusza” i określenie jego korzyści pomoże Ci zwiększyć szansę powodzenia projektu. Dzięki temu zmniejszysz prawdopodobieństwo poświęcenia czasu na spełnienie wymagania, które jest zbyt kosztowne lub sprzeczne z perspektywy istniejącego systemu.

Zamiast frustrować siebie, zespół, czy beneficjentów naszego projektu – opisaną prostą techniką możesz upewnić się, że produkt, który tworzysz, robi to, czego się od niego oczekuje.

Co z tego wziąć ze sobą jutro do pracy?

Kiedy następnym razem pojawi się niezrozumiałe wymaganie, które burzy Twoje wyobrażenie o projekcie i sprawia, że nie wiesz jak należy postąpić, pamiętaj o trzech krokach, które przybliżą Cię do rozwiązania problemu.

  1. Szukaj sygnałów. Pamiętaj, że nie masz pełni informacji na temat tego, co się dzieje po stronie klienta i dalej – zwróć uwagę na sygnały od niego, szukaj informacji na temat dodatkowych źródeł wymagań. Zadaj sobie pytania: czy klient wspominał o prezentacjach, które robi w firmie lub innym osobom? Czy wspominał osobę lub instytucję, która już wyrażała swoje zdanie o projekcie w przeszłości? Jaka jest struktura organizacyjna firmy Twojego klienta i przed kim bezpośrednio odpowiada? Czy projekt obraca się w domenie, która jest mocno uregulowana prawnie? Jeśli w odpowiedzi na te pytania pojawia się ktoś, kto nie był do tej pory brany pod uwagę w projekcie – możliwe, że znalazłeś swojego „ukrytego” interesariusza.
  2. Prześwietlaj. Warto pogłębić wiedzę na temat osób i podmiotów mających wpływ na nasz projekt – taki kontekst sytuacyjny często pozwala nam wejść w buty tej drugiej strony i zrozumieć skąd zrodziła się ta niezrozumiała potrzeba. Linkedin i inne portale społecznościowe są przydatne w zakresie poszukiwania takich informacji, ale często okazuje się, że wiele z nich jest w mailach i wcale nie musimy tak daleko szukać. Przejrzyj dokładnie te długie konwersacje, przekazywane od jednego odbiorcy do drugiego. Gdzieś wystarczająco głęboko może być podmiot, którego wcześniej nie brałeś pod uwagę. Dodatkowymi źródłami wiedzy jest też oficjalna strona firmy klienta, która może pomóc poznać nam strukturę organizacyjną.
  3. Zweryfikuj swoje założenia bezpośrednio ze swoim klientem. Zapytaj o osobę, którą wytypowałeś, o to jakie jest jej zadanie i jaki wpływ ma na projekt. Zweryfikuj problem, który dana osoba może chcieć rozwiązać swoim wymaganiem. Jeśli Twój klient nie będzie w stanie Ci tego wyjaśnić, może po prostu umówi Cię na spotkanie z osobami, które pośrednio wpływają na Twoją pracę. Ten krok pozwoli Ci upewnić się kto i jaki ma problem, a następnie opracować dla niego optymalne rozwiązanie.

Nie patrz wrogo na każde niezrozumiałe wymaganie, ale też nie ulegaj im od razu. Poświęć chwilę na przenalizowanie sytuacji, a wówczas masz realną szansę na ulepszenie produktu, nad którym pracujesz.