Cześć!

“Przynieś mi rozwiązania, a nie problemy!” - słyszałem ten tekst od biznesu i managementu nie raz - Ty pewnie też, nie?

“Przynieś mi problemy, a nie rozwiązania!” - powinniśmy odkrzyknąć.

Wyobraź sobie, że robisz system kadrowy - urlopy, umowy, te sprawy. Przychodzi do Ciebie “biznes” i mówi:

“Słuchaj, zróbmy taką apkę webową gdzie pracownicy będą wpisywać swoje godziny pracy. Ostatnio gadaliśmy w kuchni o tych waszych “redaktorach” i “angolach”. To zrobimy w nich, żeby to ładnie wyglądało?”

No i zaczyna się planowanie. Poważne dyskusje, czy to może taki folmularz, czy taki grid. Zażarte negocjacje z backendem, o tym czy robimy API restowe czy też może GraphQL. Czy kontrakt taki czy sraki.

Po bojach, na koniec okazuje się, że nawet zmieściliśmy się w czasie. Co więcej - z wymaganiami w Jira (hoho!). System ma wyjątkowo mało błędów. Sprintów kilka poleciało, ale robota skończona!

Skoro jest tak pięknie, to czemu jest tak źle?

Okazuje się, że użytkownicy systemu wcale nie są szczęśliwi, że muszą ręcznie wklepywać codziennie godziny pracy. Wcześniej zapisywali sobie w Excelu i wysyłali raz w tygodniu do przełożonego. Przełożony to potem sklejał w jeden duży excel i wysyłał do działu kadr.

Ludzie Ci suszą głowę, żeby coś dorobić czy poprawić. Ty już kolejny sprint nie możesz wrócić do swojej właściwej pracy tylko dorabiasz ficzery, a i tak każdy niezadowolony.

W takiej sytuacji gdzieś następuje prędzej czy później konfrontacja. Tutaj okazało się, że wcale problemem do rozwiązania nie było to, że użytkownicy powinni móc sami wprowadzać dane do systemu.

To było rozwiązaniem problemu. Właściwym problemem było to, że kadry muszą wiedzieć w jakie dni i ile ludzie pracowali, aby móc potem poweryfikować harmonogramy, wyliczyć opłaty.

Poprzedni system oczywiście nie był idealny. Liderzy zespołów zawaleni swoją inną robotą spóźniali się ze sklejaniem tych exceli. Plus traktowali to jako przykry obowiązek popełniali dużo błędów kopiuj/wklej. Dodatkowo kadry też traciły czas na weryfikacji tych danych i ściganiu tych osób potem, żeby poprawiły błędy we wpisach.

Gdybyśmy się na początku dopytali co jest właściwym problemem, to moglibyśmy dojść do wniosku, że może nie trzeba robić nowej aplikacji webowej. Może nie trzeba robić nowych API. Może wystarczyłoby:

• zrobić zbiorcze konto mailowe na excele,
• podpiąć pod nie system, który będzie odbierał maile, importował załączniki i je parsował,
• jeśli excel nie zawierał błędów to zapisywał dane do systemu kadrowego i odsyłał odpowiedź z potwierdzeniem do pracownika,
• jeśli mail był błędny (nie zawierał załącznika, nie dało się go sparsować czy wpisy były niepoprawne) to odsyłał maila z prośbą o poprawe i wysłanie nowego maila.

Mogłoby się okazać, że jest to dużo łatwiejsze, szybsze do wykonania i dla każdej ze stron wygodniejsze.

My programiści mamy zwykle dwie postawy:

1. “Nie będzie nam biznes mówił jak pisać aplikacje” - my jesteśmy Programiści przez wielkie P i znamy się na wszystkim najlepiej.
2. Biznes wie jak ma system działać, więc nie będę się pytał. Ja tam sobie wolę poprogramować.

Obydwie postawy można uznać za nieodpowiedzialne i prowadzące do katastrofy.

Faktycznie my się znamy na technologii - za to nam płacą. Dlatego nie powinno być tak, że przychodzi “biznes” i mówi jakiego mamy użyć frameworka, albo jak robić endpointy w API. Oczywiście przy założeniu, że aplikacja z naszym design:

• robi co powina,
• wykonanie mieści w czasie,
• utrzymanie kosztuje z grubsza podobnie co alternatywne rozwiązanie,
• nie zwiększa ryzyk projektowych (np. większe koszty rozwoju).

Decyzje techniczne powinny być w pełni nasze. Oczywiście też konsekwencje naszych decyzji powinny być też nasze.

Jednakże musimy pamiętać, nawet jeśli jesteśmy zawodem zarabiającym naprawdę nieźle, to nie my jesteśmy specjalistami od biznesu. Umówmy się - my jesteśmy dobrze opłacanymi rzemieślnikami. Nie ma co tutaj robić mesjanizmu naszego zawodu. My mamy zrobić tak, żeby pomóc biznesowi zarabiać pieniądze. To nie my jesteśmy specjalistami od procesów biznesowych w danej dziedzinie.

Ale! Nie możemy zakładać, że biznes zna się na wszystkim. Jeśli naszą domeną biznesową są kadry i płace, to czy biznes będzie wiedział jak powinien wyglądać panel administracyjny uprawnień? Albo czy będzie wiedział jakie mamy możliwości integracji między systemami? Czy będzie wiedział jak powinien wyglądać ekran logowania? Albo która formatka będzie ładniejsza?

Może będzie wiedział, ale najprawdopodobniej po prostu nie będzie się na tym znał, bo nie jest to jego “core’owa” domena biznesowa. Biznes jest specjalistą w kadrach i płacach, a te inne rzeczy to po prostu sobie wyobraża jak powinno działać.

Często jest tak, że biznes chce nam pomóc rozwiązać problem i z automatu podsuwa rozwiązanie. Gdy się zapytamy “a dlaczego to ma tak być?” to często uzyskamy odpowiedź - “a nie wiem, myślałem, że Ci to ułatwi”.

Sam miałem tak niedawno gdy moja Product Owner chciała, żebyśmy blokowali użycie rekordu dla wszystkich użytkowników, gdy dzieje się na nim jakaś operacja w tle.

My musimy być proaktywni i pytać, dowiadywać się co jest faktycznym problemem, a co właśnie podpowiedzią - potencjalnym rozwiązaniem, które nam biznes przynosi. To nie jest tak, że próbując zrozumieć proces biznesowy kwestionujemy jego zasadność. To jest de facto nasz obowiązek, żeby pomóc biznesowi w rozwiązaniu problemu. Biorąc wymagania na ślepo wcale mu nie pomagamy - wręcz przecieniw!

Przewiduję, że niedługo czasy, gdy były firmy programistyczne i firmy biznesowe, czy też nawet dział kadrowy i dział IT miną w niebyt. To jest relikt przeszłości gdzie systemy informatyczne po prostu powielały to co robią ludzie, żeby zrobić to szybciej. Teraz systemy informatyczne są biznesem. Dlatego bliska współpraca biznesu z IT nie jest już “nice to have” - jest “must have”. Henry Ford powiedział kiedyś:

“If I had asked people what they wanted, they would have said faster horses.”

Na koniec zadanie domowe dla Ciebie. Zastanów się czy poniższe hasła to problem czy rozwiązanie?

• system licencjonowania w systemach SASS,
• panel administracyjny użytkowników,
• uwierzytelnianie i autoryzacja,
• unikalny numeru faktury,
• zrobienie systemu obsługi przesyłek.

Daj znać co Ci z tego wyszło i jakie są Twoje przemyślenia!

Pozdrawiam!

Oskar