Poznaj kontekst – zrozum problem

By | March 5, 2016

W ostatnim poście pobieżnie wspomniałem o tym, że wielokrotnie w mojej pracy denerwował mnie brak pewnych rozwiązań wynikający głównie z tego, że system na którym pracowałem nie był dedykowany branży, w której akurat był używany. Zanim zajmę się kwestiami technicznymi, chciałbym napisać kilka swoich spostrzeżeń dotyczących konstrukcji podstawowych obiektów(i nie tylko), a które to spostrzeżenia będę wykorzystywał przy pracy nad projektem.

Przejdźmy jednak do sedna tematu, który mam zamiar poruszyć. Która z przedstawionych poniżej klas Person jest poprawna?

Obie klasy zawierają dokładnie te same informacje. Najbardziej widoczna różnica, to długość drugiej klasy. Odpowiadając jednak na postawione wcześniej pytanie – obie klasy są poprawne, ale w pewnych kontekstach ta krótsza będzie całkowicie bezużyteczna. Idealnie nada się do wydrukowania prostej etykiety na kopertę, którą będziemy chcieli wysłać komuś jako zwykły list. A co jeśli będziemy chcieli na jej podstawie nadać komuś paczkę z drobnym upominkiem? Co jeśli paczek takich wysyłamy sporą ilość i chcąc zaoszczędzić trochę czasu chcielibyśmy skorzystać z API jakiegoś dostawcy usług kurierskich?
API w odpowiedzi na dane adresowe w formie “Ulica 1/1 15-500 Miasto” wyśle nam zapewne krótką i dosadną odpowiedź o treści powszechnie uznawanej za wulgarną. Formularze dostawców z różnych firm lubią przyjmować dane w rozmaitych formatach i zdecydowanie najlepszą opcją jest pofragmentowanie danych adresowych na jak najmniejsze kawałki, które o wiele łatwiej poskładać w elementy wymagane przez zewnętrzny system, niż parsować zlepki kilku różnych danych w postaci na przykład “AdressLine1”.

Czy jest to oczywiste? Dla niektórych pewnie tak, ale naprawdę zatrważające jest to, że istnieją komercyjne systemy przechowujące dane w formie “ulica i numer budynku” w jednym polu. Oczywiście można to zmienić. Najczęściej jednak zmiana taka następuje, gdy jest przyczyną jakiegoś problemu. Co wtedy zrobimy kilkoma setkami czy tysiącami rekordów w bazie klientów? Co z ich zapamiętanymi danymi adresowymi? Miałem prawdziwą “przyjemność” obserwować taką zmianę własnymi oczami. Z formy podanej na początku tego akapitu, ktoś przeszedł na taką jaka powinna być od początku. Oczywiście cała kolumna “ulica + numer” znalazła miejsce w kolumnie przeznaczonej teraz już tylko na ulicę. Z kolei pole na numer budynku, stało się polem obowiązkowym.

Jak zareagowali klienci? Pani mieszkająca na ulicy “Mickiewicza 1”, która robi zakupy co tydzień i dane ma zapisane w przeglądarce zauważyła drobną różnicę. Przeglądarka wymaga od niej podania numeru budynku. Mimo, że numer znajduje się już w automatycznie uzupełnionym polu Ulicy, to trzeba go wpisać w jeszcze jednym polu, w którym miejsce swoje odnajduje piękna, samotna jedyneczka. Problem rozwiązany, przeglądarka puściła zamówienie dalej i pozostaje tylko oczekiwać na dostarczenie zamówienia. Zakupy przez internet są super!

Przenieśmy się teraz na drugi koniec kraju, do siedziby firmy X, w której zasiada specjalista ds. e-commerce, który obsługuje zamówienie. Jaki adres widzi ten człowiek w panelu? Połączony string z następujących elementów: “Ulica” + “Nr. budynku” + “Nr. lokalu”. Jak on wygląda na monitorze? Dokładnie tak:  “Mickiewicza 1 1”. Co można pomyśleć widząc taki adres i wiedząc w jaki sposób klienci uzupełniają formularze na stronach? Że jest to ulica “Mickiewicza 1/1” albo “Mickiewicza 11”, albo “Mickiewicza 1”. Ktoś musi do klienta zadzwonić i dociekać prawdy.

Cały powyższy łańcuch wydarzeń zaczął się w momencie, w którym ktoś podjął decyzję o tym, że nazwa ulicy i numer budynku pasują do jednej kolumny w bazie danych. I przez jakiś czas faktycznie tak było. Problem zaczął się dopiero w momencie integracji z zewnętrznym systemem jednej z firm kurierskich.

To tylko jeden przykład, który ma Wam pokazać, że znajomość kontekstu, dla którego dedykujemy swoje rozwiązanie jest kluczowa. Każdego zachęcam do tego, żeby przez chwilę pomyślał w kategoriach “będę obsługiwał zamówienia, jakich narzędzi potrzebuję”, “robię zakupy w internecie, co jest (nie)zbędne w sklepach z których korzystam”. Jestem szczerze przekonany, że czas poświęcony na postawienie siebie na miejscu odbiorcy naszego produktu, pozwoli nam zrozumieć niektóre z istotnych problemów w danym kontekście i pomoże nam podjąć o wiele lepsze decyzje podczas tworzenia całego rozwiązania.

Dziś chciałem przedstawić swój sposób myślenia, który jest główną przyczyną niektórych rozwiązań i funkcjonalności, których realizację planuję w najbliższym czasie. A od nowego tygodnia startuję z tematami technicznymi.