Jak zbierać wymagania projektowe od nietechnicznych kontrahentów

Myślę, że każdy, kto jest związany zawodowo z rozwojem oprogramowania oraz ma kontakt z klientami „z biznesu”, spotkał się z trudnościami, jakie niesie ze sobą zbieranie wymagań od nietechnicznych osób. Postaram się dzisiaj opowiedzieć, jak dobrze przygotować się do warsztatów, na których tego typu wymagania będą zbierane. Jakie pytania zadawać, by ułatwić komunikację i w efekcie dostarczyć produkt spełniający oczekiwania klientów? Jak rozwiązywać potencjalne konflikty?

Po pierwsze

Pierwszym, najważniejszym krokiem, jest według mnie zmiana nastawienia, z jakim podchodzimy do naszych klientów. W przeszłości często myślałem, że osoby próbujące wdrożyć dziwaczne z mojej perspektywy funkcjonalności, jedynie przeszkadzają w całym procesie. Jednak uświadomiłem sobie, że  firmy, które zajmują się oprogramowaniem biorą udział w projektach po to, żeby przynosić klientom wymierne korzyści, często związane z uproszczeniem istniejących już procesów.

Podczas wdrożenia pokazanie właściwych rozwiązań i dążenie do wspólnego celu – czyli zbudowania produktu - staje się jednym z priorytetów. Ta świadomość jest kluczowa, pozwala często przejść od irytacji związanej z koniecznością wysłuchania klienta, do sytuacji, w której każda informacja może okazać się pomocna.

Po drugie

Kolejną rzeczą którą trzeba wziąć pod uwagę, jest fakt, że najczęściej osoby będące tzw. SME (Subject Matter Expert) często oprócz zaangażowania w projekt IT mają także własne obowiązki z nim nie związane; skupienie ich uwagi w odpowiednich momentach na przykład podczas trwania samych warsztatów, będzie miało ogromny wpływ na efekty. Zauważyłem, że zwykle nie wystarczy zwyczajowa prośba o wyłączenie telefonów. Przed rozpoczęciem warsztatów staram się o to, by zostały one uwzględnione w kalendarzach osób, które będą brały w nich udział, aby były o nich poinformowane z dużym wyprzedzeniem. Często proszę o przesłanie tego typu informacji jeszcze przed „kick-offem” projektu; jeśli tylko klient się na to zgodzi.

Po trzecie

Czas trwania sesji również ma duże znaczenie. Stosuję prostą zasadę – całodniowe sesje zbierania wymagań według mnie mogą odbywać się jedynie w formie spotkań "facility". Jeżeli organizuję sesję online, zawsze staram się ją dzielić na dwugodzinne bloki. Przy dłuższych spotkaniach zauważyłem spadek zainteresowania słuchaczy. Jednego dnia możliwe są do przeprowadzenia maksymalnie dwie tego typu sesje -  jedna rano, jedna w godzinach popołudniowych.

Dodatkowo dbam o to, żeby sesje po podziale na bloki, zostały zgrupowane tematycznie, tak, aby uniknąć częstych zmian tematu. Przy spotkaniach online, już w zaproszeniach i wstępnej komunikacji proszę uczestników o włączanie kamer podczas ich trwania. Znacząco zmienia to nastawienie uczestników, komunikacja w której można przypisać głos do twarzy jest łatwiejsza i skuteczniejsza.

Po czwarte

Kolejną rzeczą ułatwiającą współpracę jest transparentność, jeśli chodzi o dokumentację wymagań. Nie tylko karty wymagań (po angielsku tzw ,,user stories,,) z nich wynikające powinny być udostępnione klientom do wglądu, ale sama dokumentacja wniosków, które wynieśliśmy z warsztatów, również. Wiele razy uratowało mnie to przed nieporozumieniami a w efekcie - przed zmarnowaną pracą.

Zwykle staram się o dostęp do narzędzi, w których dokumentuję wyniki analiz dla przedstawicieli ze strony klienta. W sytuacji, kiedy nie jest to możliwe (zwykle ze względu na ograniczenia dotyczące bezpieczeństwa po którejś ze stron), tworzę podsumowania, gdzie w punktach podaję szczegółowo moje wnioski, o które mam zamiar oprzeć techniczne zadania wewnątrz projektu.

Kiedy wymagania zostaną nie tylko zapisane, ale również przedstawione do weryfikacji, będzie możliwe wykonanie najważniejszej zasady, powtarzanej jak mantra przez każdego kierownika projektu: „Potwierdzaj wymagania, potwierdzaj wymagania, potwierdzaj wymagania!”. Przedstawiciele klienta będą mogli po zakończonych warsztatach powrócić do wniosków i spokojnie je przeanalizować. Wprowadzanie zmian bez wcześniejszej konsultacji z przedstawicielem klienta, zwykle prowadzi jedynie do błędnych założeń lub konfliktu. Nie mówię tu, że powinniśmy robić jedynie to, co sugerują nam procesowi eksperci, jednak sugestie rozwiązań z naszej strony muszą być zawsze odpowiednio przedstawione, tak, by klient wiedział, jakie korzyści ono ze sobą niesie.

Po piąte

Umiejętność słuchania drugiej osoby również ma spory wpływ na wyniki dokumentowania wymagań - dlatego warto nad nią pracować. Jeśli któraś ze stron przedstawia wymagania niedoskonałe z technicznego punktu widzenia (nieoptymalne, trudne do implementacji), zamiast przerywać jej wystąpienie natychmiast, często warto je zanotować. Możemy stworzyć tzw. „parking” wymagań, które mogą być wzięte pod uwagę w późniejszych fazach projektowych lub odrzucone całkowicie podczas priorytetyzacji.

Bezpośrednia krytyka pomysłów klienta, już na początku pracy nad projektem, może wywoływać niepotrzebne konflikty i przekreślić już na wstępie owocną współpracę. Stworzenie konceptu tzw. MVP (Minimum-Viable-Product) i określenie go jasno jako minimum funkcjonalności, które wyczerpują założenia projektowe, znacząco to ułatwia. Jeśli wiemy, co jest naszym minimum i zawsze możemy powiedzieć, że dodatkowe funkcje znajdą się w produkcie, jeżeli zostanie czas na ich wprowadzenie. Tego typu wymagania mogą uzyskać niski priorytet, jednocześnie będąc odnotowanym - fakt ten znacząco poprawia samopoczucie przedstawiającej je osoby. 

Last but not least

Na koniec pamiętajmy, że ważne jest również poczucie humoru! Nikt nie chce się mieć do czynienia ze „sztywniakiem z IT” podczas wielogodzinnych dyskusji na temat parametrów procesu w aplikacji. Zawsze staram się przemycić do moich spotkań odrobinę uśmiechu, co jakiś czas starając się odejść choćby na kilka minut od technicznych aspektów i pozwolić uczestnikom na lekkie rozluźnienie. Ważne jest nadanie projektom ludzkiej twarzy -  ludzie stają się wtedy bardziej zaangażowani, chcą uczestniczyć w  spotkaniach, przestają traktować je jako nudny i czasochłonny obowiązek.

Mam nadzieję, że ta krótka lista porad przyczyni się do tego, że również Wasze warsztaty będą przeprowadzane z większą łatwością i w bardziej przyjaznej atmosferze!