Artykuł przygotował: Radosław Zieliński

Tytułowe “małe aplikacje”

Są to zwykle narzędzia, które mają usprawniać pracę w biurze i w firmie.

Ich niewątpliwymi zaletami są:

• czas developmentu (czas, jaki programista poświęca na stworzenie programu)
• spełnianie potrzeb (robią dokładnie to, do czego zostały zaprojektowane i nic więcej)

Podczas swojej kariery stworzyłem wiele aplikacji. Jeszcze więcej takich gotowych programów spotkałem, robiąc projekty dla różnych firm. Bardzo często firmy prosiły o przerobienie, zaktualizowanie, naprawienie czy odświeżenie. Nauczyłem się wtedy, że z jednej strony dla programisty taka aplikacja to łatwy kąsek chleba, z drugiej dla firmy może wiązać się z problemami w przyszłości. Co mam dokładnie na myśli i dlaczego tak bardzo nie lubię “małych aplikacji”:

• firma z czasem ma całą masę niezależnych od siebie aplikacji. Może nawet dochodzić do sytuacji, gdy zaczynają sobie wchodzić w drogę i zmieniać dane, które leżą w gestii innych aplikacji
• bardzo często z powodu niskiego budżetu ich development nie uwzględniał odpowiednich testów, więc błędy w działaniu zdarzają się dość często. I równie często pracownicy firmy, nie mogąc nic zrobić, uczą się z tym żyć na zasadzie “no ona ma tu błąd, ale jak zrobię tak i tak to mogę go naprawić/ominąć”
• niski budżet (w końcu to tylko “mała aplikacja” i tylko do użytku wewnętrznego) nie uwzględnia prac grafika czy, co ważniejsze, UX Designera (UX – User Experience, czyli osoby odpowiedzialnej za to, aby aplikacja była łatwa w użyciu i intuicyjna), więc nie dość że aplikacje są dość “brzydkie” i nieintuicyjne, to jeszcze różnią się od siebie pod względem wizualnym
• jeśli chodzi o bezpieczeństwo to raczej ono nie istnieje lub jest na poziomie, o którym lepiej nie mówić (no ale były też projektowane na użytek wewnętrzny, więc w zaufanym środowisku)
• jeśli aplikacje przetwarzają dane osobowe, to na 100% nie są zgodne z RODO (chociażby dlatego, że weszło niedawno)
• posiadają redundantne (nadmiarowe) dane, czyli  często aplikacje o sobie nic nie wiedzą i nie mają wspólnej bazy danych, więc dane muszą być ręcznie aktualizowane w wielu miejscach (np. baza użytkowników)

Podsumowując,  “małe aplikacje” są:

• rozproszone
• niskiej jakości
• najczęściej brzydkie i graficznie niespójne
• niezabezpieczone
• niezgodne z normami prawnymi
• ciężkie w utrzymaniu przy zmianach

To jak w takim razie rozwiązać ten problem?

Przede wszystkim chcę Cię uświadomić, że nie ma czegoś takiego jak “mała aplikacja”, bo jeśli naprawdę potrzebujesz czegoś małego, to istnieje wiele gotowych narzędzi (pakiet biurowy, narzędzia online, wbudowane programy i funkcje systemu operacyjnego) i  nie potrzebujesz mnie zatrudniać.

Kroki, które podejmuję (wraz z Tobą!), aby poprawnie przygotować się do stworzenia aplikacji:

1. Uzyskanie jak najwięcej informacji o celach biznesowych, które ta aplikacja ma realizować. Cel biznesowy to inaczej problem, który aplikacja ma rozwiązać (np. ujednolicić i usprawnić drukowanie ankiet z zachowaniem identycznego formatowania i papieru firmowego). Jeśli nie ma takiego problemu/potrzeby, to aplikacja jest zbędna .

Ustalenie flow aplikacji (flow aplikacji to stany aplikacji, kolejne ekrany, przez które nawiguje użytkownik), który reprezentowane są przez tzw. wireframe’y (graficzne przedstawienie tego jak aplikacja działa).

Wireframe

Flow aplikacji

1. Teraz następuje dopiero krok, w którym ustala się ważne szczegóły techniczne, takie jak:
   1. Czy aplikacja będzie częścią istniejącego systemu czy będzie jego zalążkiem
   2. Czy istnieje jakaś scentralizowana baza użytkowników, z której będzie korzystać Twoja aplikacja, czy również musimy taką bazę stworzyć
   3. Czy aplikacja będzie dostępna spoza firmy czy tylko na potrzeby wewnętrzne (intranet)
   4. Czy przewidujemy rangi uprawnień/dostępów
   5. Kwestie bezpieczeństwa danych
   6. Wybór technologii (ma to wpływ na koszty utrzymania aplikacji)
2. Mając te powyższe kroki załatwione, można przystąpić do tworzenia projektu aplikacji, który składa się z:
   1. Projektu graficznego
   2. Opisu wymagań funkcjonalnych
   3. Opisu technicznego
   4. Harmonogramu zadań

To jest moment, którym nawet jeszcze nie rozpoczęliśmy prac programistycznych. Na pozór wygląda to strasznie i wydaje się pasować do powiedzenia “nie kupujesz krowy, jeśli chcesz wypić szklankę mleka”. Bardzo cenię sobie długofalową współpracę z klientami, a tworzenie czegoś na szybko ma krótkie nogi. Albo odbije się źle na mnie albo na kliencie (więc znów na mnie). Rzadko kiedy pierwsze podejście do tematu zdąży przebrnąć przez te wszystkie punkty. Wtedy zwykle zdarza się, że:

• klient uświadomi sobie, że nie potrzebuje dedykowanej aplikacji, ma już zestaw potrzebnych narzędzi do realizacji celu biznesowego, a jej stworzenie to trochę strata pieniędzy
• następuje chwila zadumy, konsultacje z biznesem (czyli osobami, które będą używać tej aplikacji), a w efekcie decyzja, że w sumie to nie potrzebują “małej aplikacji” tylko o wiele bardziej rozbudowany system, ponieważ właśnie narodziło się wiele nowych pomysłów, które warto przy okazji wdrożyć

Moja refleksja, którą chciałbym się z Tobą podzielić: dobrze przygotuj się do wdrożenia aplikacji i pamiętaj o krokach, które wpisałem powyżej. Odpowiednie przygotowanie do stworzenia aplikacji nie jest stratą pieniędzy, ponieważ:

• pozwoli uniknąć dużo większych kosztów związanych z budową i utrzymaniem zbędnej i kłopotliwej aplikacji
• może zostać stworzony i wdrożony pełnowartościowy system pokrywający Twoje potrzeby jak i spełniający normy jakościowe i bezpieczeństwa