Masz pomysł na własne narzędzie?

Przeszlismy przez serię artykułów dotyczących aplikacji dedykowanych. W poprzednich artykułach rozmawialiśmy o tym

• Ile kosztuje dedykowana aplikacja internetowa?
• Automatyzacja procesów w firmie czy aplikacja dedykowana?
• Jak wygląda tworzenie aplikacji dedykowanej

No i podaliśmy sobie kilka przykładów kiedy tworzyć aplikację dedykowaną i jakie mogą mieć zastosowania. W związku z tym dzisiaj przejdziemy wspólnie przez przykładowy proces tworzenia aplikacji dedykowanej.

Zauważyłem, że bardzo lubicie wpisy dotyczące darmowych CRM dla firm. Dlatego jako nasz przykładowy projekt dedykowanej aplikacji weźmiemy właśnie CRM dla firm, który być może udostępnimy za darmo.

Napisał do nas klient – bezpłatna konsultacja

Od tego wszystko się zaczyna. Dostaliśmy od Ciebie wiadomość:

Dzień dobry,

piszę do Państwa w sprawie przygotowania dedykowanego systemu do zarządzania firmą (takiego prostego, spersonalizowanego CRM).

Obecnie mierzymy się z dużym chaosem organizacyjnym. Posiadamy handlowców pracujących w terenie, którzy zapisują ustalenia w notesach, a oferty wysyłają z prywatnych skrzynek. Dodatkowo prowadzimy aktywne działania marketingowe – mamy stronę www z formularzem kontaktowym oraz profil na Facebooku. Chcielibyśmy, aby wszystkie zapytania ofertowe i leady z tych kanałów spływały automatycznie w jedno miejsce, właśnie do tego systemu.

Na start potrzebujemy prostego narzędzia, które będzie zawierać:

• Wspólny kalendarz z przypomnieniami – aby handlowcy mogli planować spotkania z klientami i nie zapominali o kontaktach (follow-upach).
• Przejrzystą listę wniosków / szans sprzedażowych – chcemy widzieć, na jakim etapie jest każda rozmowa (np. kontakt, oferta, negocjacje).
• Bazę kontrahentów – jedno centralne miejsce z historią kontaktu, danymi firm i podpiętymi dokumentami.

Zależy nam na rozwiązaniu szytym na miarę, ponieważ gotowe programy CRM są dla nas zbyt skomplikowane i przeładowane funkcjami, z których i tak nie skorzystamy. Chcemy zacząć od wersji MVP (minimum viable product), ale system musi być elastyczny. W przyszłości planujemy rozbudowę o dedykowaną aplikację mobilną dla pracowników w terenie oraz automatyczne wysyłanie przypomnień SMS/e-mail do naszych klientów.

Czy realizowali Państwo podobne wdrożenia i jak wygląda u Państwa proces wyceny oraz przygotowania takiego oprogramowania dedykowanego?

Pozdrawiam,

Jan Kowalski

Dyrektor Handlowy

Tym razem nasz klient jest świadomym klientem i doskonale wie co potrzebuje. No i świetnie. Wysłalismy Panu Janowi odpowiedź i umówilismy się na szybkie spotkanie na Google Meet. W między czasie robimy research jak można Panu Janowi pomóc. Przejrzeliśmy jego stronę, konkurencje, dopytaliśmy w między czasie czego do tej pory używali. Zebraliśmy wszystkie dane do wyceny.

Także czas przygotować dokument. W takim dokumentacie zawieramy wszystkie zebrane informacje czyli:

• Proponowaną technologię
• Rozpisane moduły
• Szacunkową wycenę i termin realizacji

W wypadku tego projektu wybraliśmy dla naszych projektów klasycznie: Symfony oraz React. Zaproponowaliśmy od razu przygotowanie API do integracji z zewnętrznymi dostawcami. Na końcu tego artykułu znajdziesz paczkę do pobrania z przykładową ofertą.

Wysłaliśmy Janowi ofertę i zaproponowaliśmy spotkanie, jakby coś było niejasne. Pan Jan zaakceptował ofertę i przechodzimy do kolejnego etapu. Przy okazji ze swoim zespołem zdecydował się, że na początek potrzebuje precyzyjniejszej wyceny, a nie elasycznego systemu rozliczenia. Dlatego przy okazji drugiego etapu przygotowujemy fajną tabelkę.

Zbieramy dane

W dużych korpo mówi się, że to proces discovery. Ja z swoim podejściem wole powiedzieć, że zbieramy i analizujemy dostępne dane. Robimy wywiady o tym jak pracujesz i czy masz już jakieś procedury. Z tego wyciągam odpowiednie moduły i historyjki użytkownika. Przygotowuje wykresy jeśli są potrzebne.

Przyznaj, że to brzmi o wiele lepiej niż:

W ramach fazy Discovery przeprowadzimy ustrukturyzowany audyt przedwdrożeniowy oraz zmapujemy operacyjne procesy biznesowe (As-Is). Przeanalizujemy standardowe procedury operacyjne (SOP) podczas dedykowanych warsztatów z kluczowymi interesariuszami, a następnie dokonamy dekompozycji wymagań na granularne moduły systemowe i precyzyjne User Stories. Całość zamkniemy w diagramach przepływu danych (Data Flow Diagrams) oraz modelach BPMN w celu optymalizacji workflow

Dzięki temu klienci piszą o nas:

Dzięki za szybką wycenę i analizę przyjmuje warunki współpracy. Cieszę
się że należysz do programistów „mówiących ludzkim głosem” – bez
zawodowego żargonu 🙂  Dzięki temu mam poczucie że rozumiem o czym było
spotkanie. Owocnej współpracy

No dobrze mamy zebrane dane. Zrobiliśmy sobie Excela z etapem1 i wypisanymi storkami użytkownika, przy okazji pojedyncze wykresy. Dla przykładu uznałem, że proces automatycznego tworzenia leada będzie u nas tym bardziej skomplikowanym procesem, który trzeba przedstawić na wykresie.

Gdy potrzeba przygotować diagram to wykorzystujemy mermaid.

graph TD
    %% 1. Źródła Leadów
    A[Formularz na stronie WWW] -->|API webhook| C(System CRM)
    B[Facebook Lead Ads] -->|API webhook| C
    
    %% 2. Obsługa w CRM
    C -->|Automatyczne tworzenie| D[Nowa Szansa Sprzedażowa <br> status: NOWY]
    D -->|Powiadomienie e-mail/in-app| E[Handlowiec przejmuje lead]
    
    %% 3. Praca Handlowca
    E --> F[Karta Kontrahenta <br> Tworzenie historii kontaktu i notatek]
    F --> G[Kalendarz <br> Zaplanowanie spotkania/telefonu]
    G -->|Przypomnienie systemowe| H[Kontakt z klientem]
    
    %% 4. Proces Sprzedaży (Kanban)
    H --> I{Czy klient zainteresowany?}
    I -->|Tak| J[Przesunięcie szansy do statusu: OFERTA / NEGOCJACJE]
    I -->|Nie| K[Oznaczenie szansy jako: PRZEGRANA]
    
    %% 5. Finał
    J --> L[Wysyłka oferty i domknięcie sprzedaży]
    L --> M[Oznaczenie szansy jako: SUKCES <br> Stały klient w bazie]
    
    %% Style wizualne
    style C fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style D fill:#fff9c4,stroke:#fbc02d,stroke-width:2px
    style M fill:#c8e6c9,stroke:#388e3c,stroke-width:2px
    style K fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px

Wygląda to całkiem przyjemnie i czytelnie dla mnie, dla klienta i dla reszty zespołu. Do tego wyżej wspomniany excel, którego screen przedstawiam poniżej.

Pilotaż i wdrożenie

No i w sumie to tyle. Mamy rozpisane storki, mamy diagramy przypadków dla miejsc, które tego wymagają. Uznajmy, że projekt wymaga projektowania UX. Także jestesmy w kolejnym etapie pracy. Grafik zapoznaje się z wykresami oraz przygotowanymi przeze mnie user stories i zaczyna projektować. W razie większych pytań to ona kontaktuje się bezpośrednio z klientem, ponieważ stawiamy na przejrzysty kontakt. Ja natomiast cały czas czuwam nad tym, aby projekt szedł w poprawnym kierunku i żebyśmy trzymali się wyznaczonych zadań.

Grafiki/mockupy są już przygotowane w figmie. Dzięki czemu Jan może przeklikać sobie mockup i zobaczyć jak to wygląda. Po kliku poprawkach dostaliśmy akceptację projektu.

Programowanie

Ja jako programista nie próżnuje i w tym czasie zabieram się już do pracy nad architekturą naszej aplikacji dedykowanej. Z poprzedniej cześci wiemy, że musimy przygotować:

• docker
• konfiguracje backendu – symfony
• konfiguracje frontendu – react
• środowisko testowe
• przygotować repozytorium na gitlabie, automatyczne teskty

Pracy sporo.

Milestony, sprinty, weekly – czyli cykle życia podczas pracy.

To też jest jedna z ważniejszych rzeczy, jaką trzeba opisać. Zobacz ile pracy już wykonaliśmy, a na dobrą sprawę nie ma jeszcze gotowej żadnej faktycznej funkcjonalności. Dobrze, to teraz mamy już taką faktyczną programistyczną prace. Wracamy teraz do naszego excela, który jest podzielony na moduły.

W zależności od tego jak bardzo Jan chce być zaangażowany w proces tworzenia aplikacji dedykowanej dostaje inne narzędzia (a raczej do nich dostęp). Jednak nasz Jan jest zapracowany, woli mieć efekty. W związku z tym nie dajemy mu dostępu do jiry i discorda, aby rozmawiał z całym zespołem. Wysyłamy mu tylko etapami notatkę o tym jak idzie praca. Chyba, że potrzebujemy coś pilnie, bo umkneło podczass przygotowywania architektury (tak zdaża się). No i sam artykuł byłby wyszedłby minitomikiem. Dlatego przejdziemy do prostszej i przyjemniejszej wersji.

Wszystko kręci się wokół naszego excela z modułami. Dlatego tak ważne jest, ab go wypełnić sumiennie i dlatego ta nasza bezpłatna konsultacja jest fundamentem całej aplikacji. Także rozpisaliśmy sobie moduły na poszczególne zadania w systemie do zarzązadznia zadaniami.

Zrobiliśmy pierwszy moduł – moduł klientów. I co dalej? Czas na testy naszej aplikacji dedykowanej. Dokładnie sprawdzamy czy zadania pokrywają się z podanym zakresem, testujemy czy wszystko działa poprawnie. Na sam koniec publikujemy aplikację na serwerze testowym. Tutaj oczywiście też robimy testy. Gdy wszystko jest gotowe to oddajemy moduł aplikacji dedykowanej do testów przez klienta.

W tym momencie dostajemy drobne poprawki lub modyfikacje. Wykonujemy niezbedne poprawki. W zależności od tego jaki format współpracy wybierzemy często tutaj pojawia się rozliczenie za etap pracy. Aplikacje dedkowane często są na tyle obszernymi aplikacjami, że nie da rady pracować przy nich bez zaliczek. Jesteśmy małym butikowym softwarehouse, a nie wielką korporacją, która potrafi utrzymać cały zespół przez cały rok pracy. Jednak za to za mniejszą kwotę wykonujemy taką samą (a czem lepszą robotę) niż korporacje gdzie najważniejszy jest excel.

No akurat w wypadku takiego CRM, nie mówimy o roku pracy i prawdodpobnie skończyłoby się na dwóch płatnościach, ale skoro przykłąd wymaga to uznajmy, że się rozliczamy co moduł.

Jeśli jesteś ciekaw jak wygląda faktycznie praca na tym etapie to na dole jest link do dema takiego modułu. Oczywiście celowo daje tylko pierwszy moduł, aby pokazać Ci jak to wygląda w praktyce.

Iteracyjna praca nad modułami

No dobrze pierwszy moduł mamy za sobą. Zostały jeszcze:

• moduł kalendarza
• moduł zadań i projektów
• moduł ofert
• moduł raportów
• moduł wiadomości

Sporo, ale klient chciałby powoli korzystać z naszej aplikacji dedykowanej oraz fajnie by było gdyśmy w tym momencie przygotowali mu moduł ofertowania. Dla nas nie ma problemu.

Dlatego wdrażamy gotowy kod na serwer demo i produkcyjny. Serwer demo jest potrzebny dla pracowników, aby zapoznali się dokładnie z systemem i nie bali się go „popsuć”. Jednak co ma to wszystko wspólnego z iteracyną pracą nad modułami? Otóż tyle, że wpadliśmy w cykl powtarzalnej pracy. My wdrażamy nowe funkcjonalności (cały moduł), następnie klient go zatwierdza i przechodzimy do kolejnego modułu.

Dzięki temu wiesz, że praca z nami jest powtarzalna i przewidywalna. Do tego stopnia, że sam nawet wykres wygląda jakbty dziecko go rysowało 😉

flowchart TD
    %% Stylizacja komponentów
    classDef init fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;
    classDef process fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
    classDef success fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    
    A([Inicjalizacja Modułu]):::init --> B
    
    subgraph Petla[Pętla Iteracyjna]
        B[Prace deweloperskie i architektura]:::process --> C[Wewnętrzne testy jakościowe - QA]:::process
        C --> D[Wdrożenie na środowisko Staging]:::process
        D --> E[Testy akceptacyjne użytkownika - UAT]:::process
        E --> F[Rozliczenie etapu prac]:::process
        F --> G[Wdrożenie produkcyjne - Go-Live]:::process
    end
    
    G --> B
    G --> H([Kompletny i stabilny system]):::success

Opieka i rozwój

Projekt się zakończył (tutaj masz live demo) i co dalej? Aplikacja działa produkcyjnie, kody źródłowe przekazane. Gwarancja na kod została udzielona. Tutaj oczywiście gwarancja działa na tej zasadzie, że posiadamy kod u siebie i jeśli nie ma żadnych ingerencji to przez 12 miesięcy błedy naprawiamy za darmo. Chociaż po tylu testach – małokiedy się zdażają. Dlatego przechodzimy do przyjemniejszej części – czyli rozwoju aplikacji dedykowanej.

Naszą aplikację dykowaną traktujemy tak samo jak każdą inną aplikację. Nie robimy wyjątków. Przykładem niech będą proste automatyzacje. Klient zgłaszał wcześniej kilka dodatkowych potrzeb. Niech to będzie powiadomienie SMS o wysłanej ofercie dla klienta. Specjalnie przygotowaliśmy API do integracji zewnętrznych narzędzi – dlatego, aby zaoszczędzić czas i budżet w tym wypadku Janowi zaproponujemy automatyzację w n8n zamiast rozszerzenia aplikacji dedykowanej. Dlaczego?

Mamy kod i produkt przygotowany na to, aby w prosty sposób go rozszerzać. Dodanie w tym wypadku powiadomienia kanałem SMS poprzez dopisanie dedykowanego kodu pod konkretną bramkę SMS jest dużo droższe niż odebranie webhooka i wysłanie przygotowanego SMS przez n8n.

Narzędzie n8n czy make posiadają bardzo dużo wbudowanych modułów w tym właśnie komunikacje z bramkami API. Dzięki temu jeśli uznamy, że chcemy zmienić dostawcę usługi wysyłki SMS to kończy się to na zmianie jednego kafelka w workflow

Zobacz na poniższym obrazku (w bardzo dużym uproszczeniu) jak wygląda taki workflow, który przyjmuje dane i po prostu wysyła je dalej, a ile kodu trzeba byłoby dodatkowo napisać.

Oczywiście to rozwiązanie ma także swoje minusy. Jednak w wypadku Jana to jest wystarczające rozwiązanie. Dzięki czemu możemy przykładowo zająć się innym większym modułem naszej dedykowanej aplikacji.

Prezent na koniec – zobacz wszystko krok po kroku.

Taki CRM to jednak fajne narzędzie, bo patrząc po ilości wyszukiwań bardzo intensywnie potrzebujecie takich narzędzi, które nie są drogie, a są bardzo proste. Tak samo widzę dużo wyszukiwań jak wygląda wspołrapca z software house przy tworzeniu aplikacji dedykowanej. Z tego powodu jeśli jesteś zainteresowany takim dedykowanym systemem CRM lub chcesz zobaczyć przygotowane pliki podaj w formularzu poniżej swój adres e-mail. W prezencie wyslemy Ci:

• jak wygląda przygotowana przez nas oferta
• Nasz dokłdany kosztorys w formie PDF
• link do demo aplikacji
• kawałek kodu, abyś mógł ocenić jak wygląda nasza praca

Jeśli spodoba Ci się nasz CRM to wdrożymy go u Ciebie. Bez żadnych miesięcznych subskrybcji.