Webtom.pl projektuje i rozwija aplikacje webowe, systemy dedykowane oraz produkty cyfrowe dla firm z Krakowa i Małopolski. Wspieramy zarówno nowe projekty, jak i rozwiązania, które już działają, ale wymagają rozbudowy, uporządkowania technologii albo przejęcia po innym zespole.
Pracę rozpoczynamy od poznania problemu, który oprogramowanie ma rozwiązać. Ustalamy użytkowników, procesy, dane, integracje, ograniczenia obecnych narzędzi oraz funkcje rzeczywiście potrzebne w pierwszej wersji.
Nie zakładamy, że cały docelowy system musi powstać od razu. W wielu projektach bezpieczniejszym podejściem jest przygotowanie pierwszej użytecznej wersji produktu, jej wdrożenie, zebranie informacji od użytkowników i rozwijanie kolejnych modułów na podstawie rzeczywistych potrzeb.
Zakres może obejmować aplikację webową, panel użytkownika, system wewnętrzny, produkt SaaS, platformę usługową, system B2B, integracje API albo zestaw współpracujących ze sobą modułów.
Webtom.pl łączy analizę biznesową, UX/UI, frontend, backend, architekturę, integracje i testy, dzięki czemu projekt nie musi być dzielony pomiędzy kilka niezależnych zespołów.
Pełny zakres współpracy przedstawiamy również na stronie Software House.
Aplikacja webowa może obsługiwać proces, którego standardowa strona internetowa lub sklep internetowy nie odwzorują w wystarczająco elastyczny sposób. Może posiadać konta użytkowników, role, formularze, dane, dokumenty, raporty, płatności, powiadomienia oraz połączenia z innymi systemami.
Projektujemy panele dla klientów, partnerów, pracowników, ekspertów lub innych grup korzystających z produktu.
Zakres może obejmować profil użytkownika, dokumenty, historię działań, statusy, formularze, płatności, dane przypisane do konta i dostęp do konkretnych funkcji.
Nie każdy użytkownik powinien widzieć i wykonywać te same operacje. Ustalamy role, poziomy dostępu oraz zależności pomiędzy nimi.
Uprawnienia powinny wynikać z rzeczywistych procesów, a nie być dodawane dopiero po zakończeniu programowania.
Aplikacja może prowadzić użytkownika przez kolejne etapy procesu: zgłoszenie, weryfikację, akceptację, realizację, zmianę statusu albo przekazanie danych kolejnej osobie.
Przed wdrożeniem opisujemy przebieg procesu oraz sytuacje wyjątkowe.
System może prezentować użytkownikowi najważniejsze informacje, statystyki, statusy i raporty.
Zakres raportowania ustalamy na podstawie decyzji, które użytkownik ma podejmować, a nie wyłącznie dostępności danych.
Gotowe narzędzie jest dobrym wyborem wtedy, gdy odpowiada procesowi firmy bez konieczności nadmiernego obchodzenia jego ograniczeń.
System dedykowany warto rozważyć, gdy proces jest nietypowy, wymaga wielu zależności, własnych ról użytkowników, specyficznych danych, integracji albo funkcji niedostępnych w standardowym oprogramowaniu.
Dedykowany system może wspierać pracę zespołu, obieg dokumentów, zgłoszenia, raportowanie, zatwierdzanie działań, komunikację i inne powtarzalne procesy.
Projekt może obejmować rejestrację, logowanie, profil, dane użytkownika, płatności, dokumenty, historię aktywności i dostęp do określonych funkcji.
System może łączyć użytkowników, ekspertów, usługodawców lub inne strony procesu i zarządzać dostępnością, zgłoszeniami, statusem realizacji oraz rozliczeniami.
Jeżeli projekt obejmuje klientów biznesowych, partnerów lub dystrybutorów, system może posiadać konta, role, dane firmy, dokumenty i indywidualne procesy.
Rozbudowane rozwiązania tego typu opisujemy również w usłudze Systemy B2B.
Nie każdy projekt wymaga stworzenia całego systemu od podstaw. Czasami właściwym rozwiązaniem jest przygotowanie pojedynczego modułu, który uzupełnia już istniejące środowisko firmy.
MVP nie oznacza przypadkowo uproszczonego produktu. Pierwsza wersja powinna zawierać funkcje potrzebne do sprawdzenia najważniejszych założeń i umożliwiać dalszy rozwój bez konieczności budowania projektu ponownie.
Na początku określamy, czego firma chce się dowiedzieć po uruchomieniu produktu oraz które funkcje są niezbędne, aby użytkownik mógł przejść podstawowy proces.
Oddzielamy funkcje konieczne do uruchomienia od elementów, które można bezpiecznie zaplanować jako kolejny etap.
Dzięki temu budżet pierwszej wersji koncentruje się na najważniejszych częściach produktu.
Przed programowaniem możemy przygotować makiety i prototyp najważniejszych przepływów. Pozwala to zweryfikować logikę działania przed rozpoczęciem kosztowniejszych prac programistycznych.
Pierwsza wersja powinna być możliwa do używania w rzeczywistym środowisku i dostarczać danych potrzebnych do decyzji o kolejnych etapach.
Po uruchomieniu analizujemy zgłoszenia, dane, nowe wymagania i priorytety. Produkt rozwijamy poprzez kolejne kontrolowane wersje zamiast jednorazowego budowania wszystkich przewidywanych funkcji.
Produkt SaaS zwykle wymaga rejestracji, logowania, odzyskiwania dostępu, profilu i mechanizmów zarządzania kontem.
Różni użytkownicy mogą korzystać z różnych funkcji albo limitów. Zasady planów powinny zostać określone w modelu produktu przed wdrożeniem mechanizmów płatności.
Pierwsze uruchomienie produktu powinno pomagać użytkownikowi zrozumieć jego możliwości i przejść najważniejszy proces.
Jeżeli produkt wykorzystuje model subskrypcyjny, określamy zasady płatności, odnowień, zmian planu i zachowania dostępu.
Produkt SaaS wymaga dalszej pracy również po uruchomieniu. Nowe funkcje, poprawki UX, integracje i zmiany technologiczne powinny wynikać z planu rozwoju produktu oraz aktualnych priorytetów.
Określenia firma programistyczna i software house są często używane zamiennie, ale zakres odpowiedzialności może być różny.
Firma programistyczna może realizować konkretne zadania programistyczne: rozwój funkcji, integracje, poprawki, refaktoryzację lub rozbudowę istniejącego systemu.
Software house może przejąć szerszy zakres: analizę problemu, architekturę rozwiązania, UX/UI, programowanie, integracje, testy, wdrożenie i dalszy rozwój.
Webtom.pl realizuje oba modele współpracy. Możemy przejąć cały projekt albo pracować nad konkretnym, dobrze określonym fragmentem istniejącego rozwiązania.
Szczegółowo ten model opisujemy również na stronie Firma programistyczna.
Rozpoczynamy od zrozumienia procesu, użytkowników, danych i ograniczeń obecnego rozwiązania.
Nie zaczynamy od wyboru frameworka ani deklarowania konkretnej technologii.
Określamy funkcje, priorytety, integracje, role użytkowników oraz zależności pomiędzy poszczególnymi elementami.
Projektujemy sposób podziału systemu, dane, API, autoryzację oraz relacje z usługami zewnętrznymi.
Zakres architektury powinien odpowiadać skali projektu, a nie przewidywaniom dotyczącym hipotetycznego rozwoju za wiele lat.
Przygotowujemy przepływy użytkowników i makiety najważniejszych widoków.
Tworzymy warstwę wizualną oraz komponenty interfejsu.
Programujemy uzgodniony zakres i prowadzimy kod w repozytorium.
Sprawdzamy scenariusze użytkowników, uprawnienia, dane, integracje, błędy oraz przypadki brzegowe wynikające z zakresu.
Przygotowujemy uruchomienie rozwiązania w uzgodnionym środowisku.
Po publikacji produkt może być rozwijany poprzez kolejne wersje, moduły i integracje.
Aplikacja może pobierać albo przekazywać dane do innych systemów poprzez dostępne interfejsy API.
Przed integracją analizujemy dokumentację, autoryzację, zakres danych, limity oraz sposób obsługi błędów.
Produkt może współpracować między innymi z CRM, ERP, systemem płatności, usługą mailingową, narzędziem analitycznym lub innym systemem wykorzystywanym przez firmę.
Określamy, które rozwiązanie jest odpowiedzialne za konkretne dane. Zapobiega to sytuacji, w której kilka systemów niezależnie próbuje zarządzać tą samą informacją.
Integracja musi uwzględniać brak odpowiedzi systemu zewnętrznego, błędne dane, duplikaty i pozostałe sytuacje odbiegające od standardowego przebiegu.
W zależności od zakresu projektu wdrażamy mechanizmy logowania i monitorowania potrzebne do ustalenia przebiegu operacji oraz diagnozowania problemów.
Bardziej rozbudowane połączenia z systemami firmowymi opisujemy również w usłudze Integracje z systemami ERP.
Przed rozpoczęciem zmian sprawdzamy strukturę projektu, technologie, zależności, jakość kodu oraz obszary istotne dla planowanego zakresu.
Weryfikujemy sposób prowadzenia kodu, strukturę gałęzi, historię zmian i możliwość bezpiecznego przygotowywania kolejnych wersji.
Sprawdzamy sposób działania środowiska developerskiego, testowego i produkcyjnego.
Analizujemy istniejącą dokumentację techniczną i biznesową oraz ustalamy, których informacji brakuje do dalszego rozwoju.
Porządkujemy zgłoszenia, oczekiwane funkcje, problemy techniczne i priorytety biznesowe.
Nie zakładamy automatycznie, że istniejący projekt trzeba przepisać od zera. Ustalamy, które elementy można rozwijać, które wymagają refaktoryzacji, a które faktycznie powinny zostać zastąpione.
Przejęcie projektu warto rozpocząć od ograniczonego zakresu pozwalającego poznać system i zweryfikować sposób współpracy przed większą rozbudową.
Opis funkcji jest mniej wartościowy bez informacji o tym, jaki proces lub potrzebę użytkownika dana funkcja ma obsłużyć.
Ustalamy typy użytkowników, role i najważniejsze działania wykonywane przez każdą grupę.
Oddzielamy funkcje konieczne od elementów, które można wdrożyć później.
Określamy dane tworzone w systemie, dane zewnętrzne oraz ich źródła.
Lista usług zewnętrznych powinna być znana możliwie wcześnie, ponieważ może wpływać na architekturę.
Ustalamy, kto dostarcza dane, dokumenty, materiały, regulaminy, tłumaczenia i pozostałe elementy wymagane do uruchomienia.
Przed wdrożeniem warto określić, jakie działania użytkowników, efekty biznesowe lub parametry procesu pozwolą ocenić pierwszą wersję.
Najpierw określamy problem i zakres, dopiero później rekomendujemy technologię.
Możemy połączyć analizę, projekt interfejsu, frontend, backend, integracje i testy.
Projekt może rozpocząć się od pierwszej użytecznej wersji produktu i być rozwijany wraz z kolejnymi potrzebami.
Możemy rozwijać rozwiązania stworzone wcześniej przez inny zespół po wcześniejszej analizie ich stanu.
Od ponad 20 lat projektujemy i rozwijamy rozwiązania internetowe dla firm i organizacji.
Nie narzucamy jednej platformy wszystkim projektom. Architektura i technologia powinny odpowiadać wymaganiom, skali i planom dalszego rozwoju.
Software house projektuje, programuje i rozwija rozwiązania cyfrowe, takie jak aplikacje webowe, systemy dedykowane, produkty SaaS, panele użytkowników i integracje. Zakres może obejmować również analizę, UX/UI, testy, wdrożenie i dalszy rozwój.
Firma programistyczna jest często kojarzona głównie z realizacją konkretnych prac developerskich. Software house może przejąć szerszą odpowiedzialność obejmującą analizę biznesową, architekturę, UX/UI, development, testy i rozwój produktu. W praktyce zakres obu modeli może się częściowo pokrywać.
Koszt zależy od liczby funkcji, typów użytkowników, ekranów, integracji, wymagań dotyczących danych, bezpieczeństwa oraz zakresu UX/UI. Dlatego wycenę poprzedzamy analizą wymagań i określeniem zakresu pierwszej wersji.
Termin zależy od zakresu MVP, liczby kluczowych procesów, integracji, dostępności osób decyzyjnych i procesu akceptacji. Najpierw określamy funkcje niezbędne do uruchomienia pierwszej użytecznej wersji.
Rozpoczynamy od ustalenia najważniejszego problemu użytkownika i celu biznesowego pierwszej wersji. Następnie oddzielamy funkcje konieczne do przejścia podstawowego procesu od elementów, które można rozwijać później.
Tak. Projekt może obejmować konta użytkowników, role, plany, płatności, onboarding, dashboardy, powiadomienia, integracje i pozostałe funkcje wynikające z modelu produktu.
Tak. Aplikacja może wspierać istniejący proces firmy, zastępować arkusze lub kilka niezależnych narzędzi, udostępniać panel klienta albo automatyzować pracę zespołu.
Tak. Przed rozpoczęciem zmian analizujemy kod, technologie, zależności, repozytorium, środowiska i zakres planowanych prac.
Tak, ale najpierw potrzebujemy poznać stan techniczny rozwiązania. Dopiero po analizie możemy odpowiedzialnie określić zakres zmian, ryzyka oraz sposób dalszej współpracy.
Nie. Często bardziej racjonalne jest stopniowe porządkowanie kodu, refaktoryzacja wybranych elementów i dalszy rozwój działającego systemu. Decyzja powinna wynikać z analizy technicznej i biznesowej.
Tak. Możemy tworzyć integracje z systemami posiadającymi odpowiednie możliwości techniczne. Zakres zależy od dostępnego API, dokumentacji, modelu danych i ograniczeń dostawcy.
Tak. W wielu projektach etapowanie pozwala szybciej uruchomić najważniejszą część rozwiązania, a kolejne funkcje rozwijać na podstawie danych i nowych priorytetów.
Tak. Możemy przygotować architekturę informacji, przepływy użytkowników, makiety, prototypy oraz indywidualny projekt interfejsu.
Tak. Możemy realizować rozwój funkcji, poprawki, integracje i pozostałe prace techniczne. Zakres, priorytety i czasy reakcji zależą od uzgodnionego modelu współpracy oraz ewentualnego SLA.
Jeżeli projekt dotyczy przede wszystkim strony, sklepu albo konkretnej technologii, zobacz również wyspecjalizowane usługi Webtom.pl:
Opisz użytkowników, najważniejszy proces, obecne narzędzia oraz funkcje, które powinny znaleźć się w pierwszej wersji.
Na tej podstawie określimy, czy kolejnym krokiem powinna być analiza produktu, zakres MVP, projekt UX/UI, architektura techniczna, przejęcie obecnego systemu czy estymacja pierwszego etapu.
Porozmawiajmy o Twoim projekcie
Sławomir Woźniak
New Business | PL
Zastanawiasz się wg jakich kryteriów wybrać software house do współpracy? Poznaj istotne kryteria.
Software House, agencja interaktywna czy freelancer? Poznaj kluczowe różnice i sprawdź kogo wybrać.
