Kurs VBA – cz. 16 – Projektowanie programu

Poznaliśmy już wszystkie istotne elementy kodu. Możemy już napisać większość programów w VBA. Oczywiście dobry murarz potrzebuje nie tylko cegieł ale i umiejętności ich układania w spójną i bezpieczną całość. Poniższy tekst należy raczej traktować bardziej jako lekturę do poduszki niż ścisły kurs techniczny.

Na temat projektowania oprogramowania napisano tysiące książek i opracowano setki metodyk. Poniżej ledwie pływam po powierzchni tego problemu, mam jednak nadzieję, że po przeczytaniu tego tekstu początkujący programista VBA będzie lepiej przygotowany na to, co przyniesie przygoda z programowaniem.

Poniżej użytkownikiem nazywam osobę, która docelowo będzie używać nasz program. Często będziemy pisać program dla siebie, pewnie jednak nie zawsze. W miarę wzrostu naszych umiejętności wzrośnie ilość programów pisanych dla innych.

Zlecenie

Każdy projekt, program zaczyna się od zlecenia. Może to być szef, który rzuci jakiś pomysł mijając nas na schodach. Jakiś pracownik może przyjść do nas z problemem. Ostatecznie sami możemy na coś wpaść obserwując czyjąś pracę lub rozmyślając nad naszą. Chcemy w takiej sytuacji jak najszybciej rzucić się do VBE i zacząć pisać, pisać, pisać, jak najszybciej zobaczyć efekty. Podejdźmy jednak do sprawy metodycznie.

Poniżej zajmiemy się względnie prostym przypadkiem aplikacji do drukowania etykiet na paczki.

Początki

Pisanie programu wcale nie powinno zaczynać się od komputera. Najlepiej jest zacząć w Wordzie lub nawet z kartką papieru. Zastanów się:

  • Jaki jest główny cel programu? Określ go w jednym zdaniu w języku korzyści. Czyli nie: „Program do drukowania etykiet na paczki”, tylko „Przyspieszenie pakowania paczek”. Od tej pory każde nasze działanie, każda funkcja musi nas przybliżać do tego celu i nigdy nie można o nim zapomnieć.
  • W jaki sposób program ma zbliżyć użytkownika do tego celu? „Przyspieszenie pakowania paczek poprzez automatyczne generowanie i drukowanie etykiet”. Nasz program ma przede wszystkim przyspieszyć pakowanie paczek. Jeżeli drukowanie etykiet będzie ten proces spowalniać to poniesiemy porażkę.
  • Kim jest użytkownik? Jak reaguje na propozycję nowego rozwiązania? Czy będzie ułatwiał wprowadzenie nowego programu, czy utrudniał? Czy możesz liczyć na wsparcie przełożonych?
  • Czego użytkownik oczekuje od programu? Przyjrzyj się dokładnie jak sobie teraz radzi z tym problemem. Być może w tej chwili nasze przykładowe etykiety są tak szybko wypisywane ręcznie, że program by spowolnił ten proces zamiast go przyspieszyć. Program ma pomagać użytkownikowi a nie być samemu dla siebie, żeby proces wyglądał nowocześnie.
  • Jakie jest wejście programu? Czy dane adresowe do etykiety muszą być wpisywane ręcznie do Excela? Czy można je wyeksportować z jakiegoś innego systemu (np. sprzedażowego?)
  • Jakie jest wyjście programu? Czy nasze etykiety muszą spełniać jakieś specjalne wymagania przewoźnika? Czy ma się drukować na raz jedna etykieta, czy kilka? Czy wszystkie etykiety są od siebie niezależne?
  • Jakie są wyjątkowe sytuacje? Nic nie zastąpi obserwacji użytkownika. Być może dowiesz się, że raz w tygodniu drukowana jest etykieta o innym rozmiarze, na specjalną paczkę. Czy program będzie to uwzględniał? Może lepiej, żeby taka etykieta była dalej wypisywana ręcznie.
  • Na jakim stanowisku pracy działa użytkownik? Być może 10 pracowników wypisywało do tej pory etykiety ręcznie i teraz będą musieli się kłócić o jeden komputer z Twoją nową super aplikacją do drukowania. Jaki rodzaj drukarki jest na docelowym komputerze? Może jest tam tylko drukarka igłowa, termiczna albo jakiś dziwny egzemplarz drukarki laserowej, który nie akceptuje papieru samoprzylepnego. Czy na tych komputerach w ogóle jest zainstalowany Excel? Być może konieczny będzie zakup dodatkowych licencji.
  • Czy masz wszystkie potrzebne narzędzia? Z reguły wystarczy Ci Excel. Z czasem nauczysz się łączyć Excel z innymi programami. Może potrzebna Ci jest drukarka PDF, lub czytnik kodów kreskowych.
  • Czy masz wszystkie potrzebne umiejętności? Czy znasz wszystkie funkcje programu, które na pewno będą Ci potrzebne. Oczywiści podczas pisania programu będziesz się dużo uczył, ważne jednak, żeby z tyły głowy kiełkowały już pomysły jak zabrać się do problemu. Myśl też o sobie. Czego ciekawego możesz się nauczyć przy okazji tego projektu. Być może możesz przemycić jakąś nową ciekawą technologię.

Jak widać zaniedbanie któregoś z elementów może doprowadzić do katastrofy. O każdej przeszkodzie należy dowiedzieć się jak najwcześniej. Nie zabieraj się za program, który z góry jest skazany na porażkę.

Budżet i czas

Każdy projekt ma jakiś budżet, jeżeli nie dotyczy bezpośrednio pieniędzy, to poświęcony lub zaoszczędzony czas też jest wartością.

  • Czy będą potrzebne nowe komputery, drukarki, licencje, nowi pracownicy do obsługi programu?
  • Jakie będą oszczędności? Czy będzie się teraz używać mniej papieru? Ile czasu zaoszczędzą pracownicy?
  • Czy nie tworzysz programu, który nikt nie będzie miał czasu używać?

Czas Twój i użytkownika to też pieniądz, zastanów się w co go zainwestujesz.

Dodatkowe korzyści

Skoro już poświęcisz czas na napisanie programu realizującego główny cel („Przyspieszenie pakowania paczek”) to zastanów się jakie dodatkowe cele możesz łatwo osiągnąć. W naszym przypadku możemy wygenerować zestawienie miast, do których wysyłane są paczki wraz z wagami. Takie zestawienie może być używane do optymalizacji kosztów wysyłek.Pomyśl też o przyszłości procesu. Jakie elementy odłożysz na później? W naszym przypadku możemy za jakiś czas rozszerzyć program o dziennik wysyłek, lub logowanie pracowników, dzięki któremu będziemy wiedzieć, który pracownik zapakował ile paczek.

Określ koniec projektu

Określ jasno i uzgodnij z użytkownikiem datę przekazania programu. Ciebie zmotywuje to do pracy a użytkownik będzie się czuł bardziej komfortowo w obliczu zmian, które zawsze są trudne. Jeżeli programowanie będzie trwać długo, możesz określi różne daty pośrednie, na które będziesz miał przygotowane poszczególne części aplikacji.
Kiedy planujesz zakończyć projekt? Najczęściej tym punktem jest moment przekazania programu użytkownikowi do działania „na żywo” w codziennej pracy. Wtedy najczęściej otwiera się szampana i kierownicy dostają premie. Jest to potworny błąd!
Pamiętaj! Projekt nie kończy się w momencie przekazania oprogramowania użytkownikowi, tylko dużo później. Co mam na myśli?
Określ koniec projektu na miesiąc po przekazaniu programu, zaplanuj sobie wtedy czas na ocenę sukcesu.
Wyznacz sobie wskaźniki, które pozwolą określić, że twój projekt odniósł sukces. W naszym przykładzie mogę teraz zmierzyć ile trwa średnio tworzenie jednej etykiety czy pakowanie całej paczki. Taki sam pomiar mogę dokonać miesiąc po wdrożeniu oprogramowania. Z taką oceną można śmiało iść po premię lub zastanowić się, co poszło nie tak.

Ostateczne decyzje

Kiedy już wszystko sobie spiszesz, nie rzucaj się do programowana! Prześpij się z tym. Spójrz na swoje notatki dzień później, przejrzyj je jeszcze raz z użytkownikiem/kolegą/koleżanką.

Na tym etapie spędziłeś już sporo czasu z użytkownikiem. Może zauważyłeś, że problem naszych pracowników magazynu jest w zupełnie innym miejscu. Co z tego, że zaoszczędzisz czas przy tworzeniu etykiet, skoro najwięcej wysiłku poświęcają na poszukiwanie towarów na magazynie. Być może lepiej napisać aplikację inwentaryzującą towar? Myśl o firmie jako o całości, problem z obsługą zamówienia może leżeć w dziale sprzedaży a magazyn ma jeszcze dużo wolnych zasobów. Projekt musi zawsze celować w najsłabszy punkt procesu, bo ten punkt definiuje przepustowość całej ścieżki.

Jeżeli na jakimkolwiek etapie pisania programu uznasz, że nie jest on już potrzebny lub nie będzie realizował celu to przerwij jego pisanie! Lepiej wyrzucić kod, który pisaliśmy miesiąc niż stracić chociaż dzień na coś, co już nie jest nikomu potrzebne.

Na koniec

Cały czas ściśle współpracuj z użytkownikiem. Nie ma nic gorszego niż program, który stworzył informatyk, który myśli, że wie więcej o procesie niż użytkownik. który wykonuje go na co dzień.

Powyższa ścieżka może wydawać się długa i łatwo pokusić się o jej ominięcie. Zawsze kierujmy się rozsądkiem. W przypadku prostych programów możemy na projekt poświęcić 15 minut, w przypadku bardziej skomplikowanych parę dni, tydzień, miesiąc. Każde 10 minut przygotowań do tworzenia programu zaoszczędzi Ci godzinę podczas jego pisania.

Jeszcze raz powtórzę: Projekt musi celować w wąskie gardło, czyli najsłabszy punkt. Ten punkt definiuje przepustowość całego procesu, czyli u nas ilość obsługiwanych dziennie zamówień. Projekt, który nie zajmuje się wąskim gardłem to nie projekt tylko marnowanie czasu i pieniędzy. Nawet największe korporacje popełniają błąd inwestowania ogromnych zasobów w elementy, które nie poprawiają jej całkowitej wydajności.

Subskrybuj RSS, lub polub blog na Facebooku aby otrzymywać najnowsze informacje o rozwoju kursu.

Zapraszam do zadawania pytań w komentarzach.

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *