Wstęp

Jedną z moich ulubionych pułapek, w które często wpadałem i czasami nadal daję się złapać, jest chęć pisania kodu. Nawet, gdy nie w pełni rozumiem problem poznania nowego lepszego języka, frameworka i znalezienia sposobności, by go użyć. To takie szukanie gwoździ do wbicia, gdy już się kupiło młotek.

Powiedzmy, że pojawia się klient, który wie, że perfekcyjnie władamy owym młotkiem i zwraca się do nas z prośbą o wbicie kilku gwoździ. Na co oczywiście ochoczo przystajemy. Jedziemy do niego do firmy i wbijamy bez słowa gwoździe. Nasza praca jest skończona, bierzemy pieniądze i jedziemy do domu zadowoleni ze swojej pracy.

To jest ten moment, w którym jedno dobrze zadane pytanie może sprawić, że przestajemy być programistą skupiającym się na pisaniu kodu, a stajemy się inżynierami, zaczynającymi rozwiązywać problem.

Na początku mojej programistycznej drogi liczył się przede wszystkim kod. Brakowało mi tak zwanego bigger picture. Dostawałem zadania na poziomie kodu.

Dwa lata później dostałem swój pierwszy samodzielny projekt, który wymagał ode mnie bardzo szybkiego przejścia z “kodowania” na współpracę z klientem, zbierania wymagań, zrozumienia problemu i rozwiązania problemu. Wtedy zrozumiałem dlaczego, gdybym został na poziomie pisania kodu, to ten projekt zakończyłby się kompletną klapą.

Pozornie zadanie było proste. Klient oczekiwał ode mnie projektu bazy danych. Z taką prośbą zwrócił się do firmy, w której pracowałem. Trzeba było zrozumieć, co ma być przechowywane i w jaki sposób to będzie potem wykorzystywane. Pozornie, zwykły projekt encji i napisanie skryptów.

Na miejscu, po około godzinie rozmowy zauważyłem, że coś mi kompletnie nie pasuje w tym wszystkim i zadałem serię pytań:

  • Ale po co to mam robić?
  • Jaki jest cel tego projektu bazy danych?
  • Gdzie jest ten problem, który chcecie rozwiązać?

Ku mojemu zaskoczeniu odpowiedzią nie było “bo chcemy przechowywać dane” tylko “chcemy ulepszyć proces projektowania katalogów wycieczkowych”.

Spodziewałem się prostoliniowego zadania na poziomie przechowywania danych, a otrzymałem informacje o tym, że problem znajduje się w zupełnie innym miejscu.

Zidentyfikować problem

Zrozumiałem, że moje dalsze poczynania będą związane z próbą rozwiązania faktycznego problemu przedłużającego się procesu projektowania katalogów wycieczkowych, a nie z projektowaniem struktur baz danych.

Ich aktualny proces był manualny. Polegał na przekazywaniu sobie exceli. Mailowo pisali, kto nad czym pracuje, z adnotacją “nie ruszać”. Sporo problemów pojawiało się przy łączeniu efektów ich pracy, a potem przy przeliczaniu danych. Wyniki pracy różnych działów wpływały na siebie wzajemnie w różny sposób.

Pracę dodatkowo utrudniał fakt, że statki wycieczkowe zmieniały swoje marszruty i np. udawały się do suchego doku na renowację.

Bardzo pomocne było to, że klient precyzyjnie wiedział, czego nie chce. Nie chciał mieć tych samych problemów, które miał wcześniej.

Klient precyzyjnie określił, że nie chce, by to tak długo trwało. Obecnie trwało to 4-6 miesięcy, co wynikało z dużej ilości problemów między ludźmi.

Jako programista C#, znający TSQL, zapytałem, czy może to być napisane w tych językach. Uzyskałem od nich niespodziewaną odpowiedź, że nie chcą żadnych 3rd Party Application. Zapytałem ich: dlaczego?

Odpowiedź była równie zaskakująca: mieli dużą ilość osób, które wymasterowały formułki w excelu. To musi być aplikacja napisana w excelu.

Zapamiętałem kilka bardzo ciekawych wymagań, które ukrywały się pod tym, co klient zasygnalizował na początku. Przypomnę - klient zgłosił się po zaprojektowanie bazy danych.

  • Przyspieszenie działania procesu tworzenia katalogu wycieczkowego - z tego, co pamiętam - oznaczało, że jeśli doszlibyśmy do 2 miesięcy, to byłoby super.
  • Sprawienie, by ludzie nadal mogli korzystać z narzędzi, które znają - czyli z excela i jego formułek.

Zrozumieć problem

Następnym etapem, który musiałem przejść, to było zrozumienie, jak ludzie klienta obecnie pracują, co im przeszkadza i jak chcieliby pracować.

Zrozumienie tego wszystkiego nie nastąpiło od razu, zajęło z grubsza rok. Bycie BA, Devem i QA w jednym miało swoje zalety, jak i wady.

Rozwiązanie, które udało mi się stworzyć sprawiło, że proces skrócił się z miesięcy do tygodni, ale nie byłoby to możliwe, gdybym nie zadał odpowiednich pytań.

Przyznam, że wtedy te pytania by dla mnie nieintuicyjne. Przecież klient chce projektu bazy danych - to zrobię mu projekt. W końcu dostanie to, o co prosi.

I w tym miejscu jest różnica pomiędzy tym, co klient mówi, że potrzebuje (pragnienie), a tym, czego rzeczywiście potrzebuje (potrzeba). Te dwa światy często się ze sobą nie połączą bez naszej pomocy, bez zadawania pytań i próby zrozumienia problemu.

Mogłem nalegać na to, by rozwiązanie było napisane w językach, które znam, ale bardziej logiczne było stworzenie aplikacji, która spełniała oczekiwania klienta i dzięki której klient będzie miał pełnię możliwości w krótszym czasie.

Zaprojektowanie nowego UI i nauczenie ludzi pracy z nowym narzędziem kosztuje sporo czasu i pieniędzy. Jedyną zaletą wykorzystania C# i TSQL było to, że dobrze znam te języki - co niekoniecznie było najważniejszą rzeczą dla klienta. Więcej korzyści dało klientowi to, że nauczyłem się VBA (języka pozwalającego tworzyć rozwiązania w obrębie excela) i stworzyłem sobie własne zautomatyzowane środowisko pracy.

Projektowanie wszystkiego od nowa ma sens wtedy i tylko wtedy, gdy są ku temu logiczne przesłanki. Gdy klient otrzyma korzyści w stosunku do inwestycji. W tym wypadku tego nie było.

Podsumowanie

Wracając do metafory z początku, klient tak naprawdę nie chce mieć dziury w ścianie. Tak samo jak nie kupujemy wiertła dla samego jego posiadania lub posiadania dziury w ścianie. Mamy precyzyjnie określoną potrzebę. Chcemy np. powiesić obrazek.

Gdyby istniał inny sposób na wieszanie obrazów, który nie wymagałby niszczenia ściany, a spełniałby oczekiwania klienta, to czemu po niego nie sięgnąć?

Jeśli jesteśmy programistami, to możemy czuć potrzebę rozwiązania każdego problemu za pomocą kodu. Jeśli znamy jeden język programowania, to możemy wszędzie widzieć okazję do użycia tego języka - jak owego młotka szukającego gwoździ.

Przy rozwiązywaniu problemów należy jednak zrozumieć, gdzie leży istota problemu i jakie ograniczenia i wymagania nakłada ów problem, zanim przystąpimy do rozwiązywania.

Zaprojektowanie bazy danych samo w sobie rozwiązuje jedynie problem braku projektu bazy danych. Gdybym nie zadał odpowiednich pytań, dostalibyśmy gratyfikację pieniężną za wykonanie pracy, a faktyczny problem nie zostałby rozwiązany. Klient nadal byłby nieszczęśliwy i nadal bujałby się z procesem, który zajmuje miesiące i wymaga dużej cierpliwości oraz liczenia, że ludzie się nie pomylą, np. dwie osoby nie modyfikują tej samej ceny za miejsca z balkonem.

Gdy rozumiemy już problem, możemy wybrać rozwiązanie/rozwiązania odpowiednie dla niego. Może okazać się, że kupienie gotowego narzędzia daje nam więcej korzyści w stosunku do kosztów, niż pisanie go od nowa.

Bez zrozumienia tego, jaki jest faktyczny problem, możemy go rozwiązać lub też nie, licząc na czysty przypadek. A to już odbiega od mojej definicji inżyniera systemów.