Wstęp

W poprzednim wpisie opisałem przypadek, w którym przy użyciu dobrze zadanych pytań udało mi się uniknąć pisania kodu dla klienta, który tego nie potrzebował. Mogłoby się wydawać, że jest to sytuacja jedna na milion - w praktyce, tego typu sytuacje zdarzały mi się częściej niż mogłoby się wydawać. Dziś przedstawie drugi problem oraz w jaki sposób rozwiązaliśmy ten problem przy użyciu inżynierii. 

Pozwólcie, że przedstawię Wam inny bardzo ciekawy przypadek. Klient miał problem z bardzo wolno –  jego zdaniem – działającym oprogramowaniem. Dodatkowo było ono bardzo wadliwe. Chciał, by powstało lepsze rozwiązanie. Coś szybszego i mniej zawodnego.

Oprogramowanie dotyczyło zamawiania jedzenia, a następnie naliczania opłat przy odbiorze.

Niby nic trudnego. Integracja z zewnętrznym systemem płatności. Brak dostępu do obecnego kodu źródłowego, ale za to dostęp do aplikacji.

Najpierw należało zrozumieć, gdzie leży problem. Co oznaczają takie pojęcia jak:

  • lepszy,
  • szybszy,
  • mniej zawodny.

Lepszy => to buzzword, który ukrywa istnienie innych potrzeb,

Szybszy => klient chciał, aby wpłaty były księgowane od razu po tym, jak dostawcy przyjeżdżają na miejsce.

Mniej zawodny => klient chciał, aby ilość ręcznych wpłat była mniejsza od tych, które były opłacone kartą.

Na pierwszy rzut oka wydawało się, że są to problemy związane z zewnętrznym systemem płatniczym lub z integracją tego systemu.

Analiza

Wstępnie badania nic nie wykazały. Integracja działała sprawnie. Oczywiście, można było optymalizować - ale nie wyglądało na to, że tu był problem. Podejrzenia padły na interfejs użytkownika - być może był nieintuicyjny dla kurierów.

Analityk biznesowy postanowił więc pojechać na miejsce razem z kurierem i zobaczyć jak i gdzie ci kurierzy pracują. Mogło się okazać, że jest to kwestia trudnego interfejsu do obsługi.

Problem okazał się jeszcze bardziej ciekawy niż z początku na to wskazywało. Kompletnie nie był powiązany z aplikacją.

Terminal kuriera był tak nieporęczny, że czasami kurier zapominał go ze sobą zabrać. W niektórych wypadkach dostarczyciel albo wracał po niego do samochodu albo zabierał gotówkę ze sobą i księgował płatność w terminalu w momencie, w którym skończył już wszystkie dostawy.

To wpływało negatywnie zarówno na czas transakcji jak i na niezawodność.

Wprowadzanie ręcznie sprawiało, że zdarzało się, że w systemie były księgowane błędne kwoty, przez co trzeba było je ręcznie później poprawiać. Kolejna nieefektywność.

Klient, który obserwował system z zewnątrz, nie wiedząc jak wyglądała praca kuriera, całą winą obarczył nieszczęsną aplikację.

Rozwiązanie, które zostało zaproponowane, było dla klienta nieoczekiwane: niech kurierzy otrzymają gadżet, dzięki któremu mogą przypinać sobie terminal do paska :).

Wpłynęło to pozytywnie na całość systemu zamówień.

Zaproponowane rozwiązanie kosztowało +/- 30 euro per terminal i nie wymagało napisania ani jednej linijki kodu. Wymagało natomiast dogłębnego zidentyfikowania problemu.

Prawdziwa Inżyniera

W innym artykule opisałem przypadek tworzenia fotobudki, gdzie z punktu widzenia klienta dopóki urządzenie robi to co ma robić, to co się dzieje w urządzeniu jest nieistotne. Dokładnie tak samo było w tym wypadku.

Dopóki nasze rozwiązanie robi to co powinno to jest to nasz sukces, niezależnie od użytych środków.

W inżynierii liczy się to, by problem zniknął. Nie chodzi o to, by napisać kod. Napisanie kodu było jedną z dróg do rozwiązania tego problemu. Mogło powstać nowe rozwiązanie, którego całkowity koszt pewnie wyniósłby więcej niż rok pracy 3-5 osobowego zespołu.

Istnieje duże prawdopodobieństwo, że i wtedy prawdziwy problem nie zostałby rozwiązany, albo  zostałby rozwiązany przypadkowo. Klient byłby niezadowolony z efektu, nie przedłużyłby współpracy z naszą firmą, nie poleciłby naszej firmy innym firmom.

Gdyby jednak podjęto decyzję o wprowadzeniu aplikacji mobilnej, to podejrzewam, że przypadkowo rozwiązalibyśmy tamten problem.

Zmiana terminalu na telefon komórkowy sprawia, że łatwiej kurierowi ze sobą taki przedmiot zabrać. Z perspektywy klienta wszystko działa lepiej, więc to by był sukces aplikacji – w rzeczywistości jednak po prostu kurier nie zapomniałby terminala.

W ten sposób moglibyśmy  przypadkowo rozwiązać problem, którego nie byliśmy świadomi. Od tamtej pory często zastanawiam się , czy pęd w kierunku na aplikacje mobilne nie jest w jakimś stopniu powiązany z ukrytymi trudnościami .

Podsumowanie

Jak już pisałem wcześniej, inżynieria systemów wymaga zrozumienia problemu, nie pisania kodu. Jeśli zrobimy inaczej, możemy skończyć z dużą ilością niepotrzebnego kodu, który rozwiązuje nie ten problem, który powinien.

Zrozumienie problemu jest istotnym etapem procesu. Bez tego, co my tak naprawdę rozwiązujemy? Czy jako inżynierowie możemy wtedy udowodnić co zrobiliśmy?

W poprzednim artykule pokazałem dlaczego takie podejście jest ważne. Problem może być maskowany pod wieloma nic nie tłumaczącymi słowami: np. lepszy, szybszy. Może okazać się, że da się go rozwiązać na wiele sposobów, spośród których najbardziej naturalnym dla programisty jest pisanie kodu, Jednak piszmy ten kod świadomie, dzięki temu będziemy wiedzieć na czym polega jego sukces i będziemy znali kryterium tego sukcesu.. I to właśnie jest, moim zdaniem, inżynieria oprogramowania.