Usługi programistyczne - zakres prac i model rozliczenia

Usługi programistyczne różnią się od zakupu gotowego programu tym, że zamawiający płaci za pracę zespołu, a nie za licencję. Z tego powodu dwa pytania decydują o przebiegu współpracy: co dokładnie wchodzi w zakres i w jaki sposób rozliczane są godziny albo etapy. Poniżej opisany jest zakres prac SoftwareStudio w postaci aplikacji i integracji oraz raportów SQL, a także dwa podstawowe modele rozliczenia, czyli time and material i stała cena.

SoftwareStudio świadczy usługi programistyczne w zakresie aplikacji internetowych i bazodanowych, a także aplikacji na telefon i tablet z systemem Android. Wykonywane rozwiązania służą do zarządzania procesami w firmie i powstają według wymagań zamawiającego.

Usługi programistyczne - co wchodzi w zakres

Zakres usług programistycznych obejmuje kilka obszarów prac. Każdy ma inny typowy wynik i inne ryzyka, dlatego przy zamawianiu warto go nazwać wprost, a nie zapisywać ogólnie jako „wykonanie oprogramowania”.

Reguła: w umowie każdy obszar usługi dostaje osobny punkt z opisem wyniku, bo od tego zależy, co podlega odbiorowi.

Zestaw można zamówić w całości albo częściami. Wiele firm zaczyna od raportów lub integracji, bo dają szybki efekt przy niewielkim zakresie, a dopiero potem zamawia aplikację. Inne zaczynają od aplikacji, a raporty dokładają po miesiącach pracy, gdy w bazie zbierze się wystarczająco danych.

Wymagania niefunkcjonalne w zakresie

Poza funkcjami zakres opisuje wymagania niefunkcjonalne, które decydują o odbiorze równie mocno jak ekrany. Dotyczą one czasu odpowiedzi przy założonej liczbie użytkowników, modelu uprawnień, częstotliwości kopii zapasowych i wsparcia przeglądarek. Brak tych zapisów przenosi rozmowę na etap odbioru, gdy zmiana architektury jest już droga.

Dobrą praktyką jest wpisanie do umowy jednej tabeli z wartościami granicznymi. Wykonawca wie wtedy, jaką wydajność ma osiągnąć, a zamawiający ma podstawę do zgłoszenia reklamacji, jeśli aplikacja tych wartości nie spełnia.

Aplikacje internetowe i mobilne

Najczęściej zamawianym obszarem usług są aplikacje. Zamawiający opisuje proces, a wykonawca zamienia go na ekrany i reguły walidacji oraz strukturę danych. Wybór między aplikacją internetową a mobilną zależy głównie od miejsca pracy użytkowników.

Aplikacja internetowa

Aplikacja internetowa działa w przeglądarce, więc nie wymaga instalacji na stacjach i daje dostęp z każdego urządzenia z dostępem do sieci. Dane leżą na serwerze, co upraszcza kopie zapasowe i kontrolę uprawnień. Więcej o tej formie opisuje tekst o aplikacji webowej, a o samym wytwarzaniu tekst o tworzeniu aplikacji webowych.

Aplikacja na Android

Aplikacja mobilna jest potrzebna tam, gdzie użytkownik pracuje w ruchu i korzysta z aparatu lub skanera. Komunikuje się z tym samym serwerem, co aplikacja internetowa, przez interfejs REST. Przykład tego układu w magazynie opisuje tekst o aplikacji magazynowej na Androida.

• Praca przy biurku - wybór pada na aplikację internetową, bo eliminuje instalację i ułatwia aktualizacje.
• Praca w ruchu - wybór pada na aplikację na Androida, bo pozwala korzystać ze skanera i pracować przy słabym zasięgu.

Integracje między systemami

Integracja usuwa ręczne przepisywanie danych między programami. Wykonawca ustala z zamawiającym kierunek przepływu danych oraz częstotliwość synchronizacji. Osobno opisuje się reakcję na błąd. Format wymiany zależy od możliwości systemu po drugiej stronie.

Poniższy przykład pokazuje komunikat JSON, jaki aplikacja może wysłać do systemu księgowego po zatwierdzeniu dokumentu. Nazwy pól są przykładowe, a rzeczywisty format wynika z dokumentacji interfejsu po drugiej stronie.

POST /api/dokumenty HTTP/1.1
Content-Type: application/json

{
  "numer": "FZ/2026/0412",
  "kontrahentNip": "1234567890",
  "wartoscNetto": 1250.00,
  "waluta": "PLN"
}

Zasady projektowania interfejsów HTTP zebrano w wytycznych Microsoft Learn dotyczących projektowania API. Szerzej o łączeniu systemów piszą teksty o integracji systemów informatycznych i o integracji systemów magazynowych.

Obsługa błędów w integracji

Interfejs sąsiedniego systemu bywa niedostępny, a wysłany komunikat może zostać odrzucony. Integracja odporna na takie zdarzenia zapisuje komunikaty w kolejce w bazie danych i ponawia wysyłkę w rosnących odstępach czasu. Każdy komunikat ma unikalny identyfikator, dzięki czemu ponowne wysłanie tego samego dokumentu nie tworzy duplikatu po drugiej stronie.

Błędy, których nie da się naprawić automatycznie, na przykład brak kontrahenta w systemie docelowym, trafiają na listę do ręcznej obsługi z opisem przyczyny. Bez takiej listy dokument znika po cichu, a rozbieżność wychodzi dopiero przy uzgadnianiu sald.

Raporty i zapytania SQL

Raporty zamieniają dane z bazy na zestawienia czytelne dla zarządu i kierowników. Wykonawca pisze zapytania w T-SQL i buduje wydruki oraz eksporty w SQL Server Reporting Services. Zapytanie raportowe powinno przyjmować parametry, na przykład zakres dat, a nie zawierać dat wpisanych na stałe.

CREATE PROCEDURE dbo.RaportSprzedazyMiesiac
    @Od DATE,
    @Do DATE
AS
BEGIN
    SET NOCOUNT ON;
    SELECT k.Nazwa AS Kontrahent,
           SUM(d.WartoscNetto) AS Sprzedaz
    FROM dbo.Dokumenty AS d
    JOIN dbo.Kontrahenci AS k ON k.Id = d.KontrahentId
    WHERE d.DataWystawienia >= @Od
      AND d.DataWystawienia <  @Do
    GROUP BY k.Nazwa
    ORDER BY Sprzedaz DESC;
END;

Przedział półotwarty, czyli większe lub równe od początku i mniejsze od końca, pozwala uniknąć błędów na granicy dnia przy polach z godziną. Nazwy tabel i procedury są przykładowe. Wydruk, który korzysta z takiej procedury, może powstać w SQL Report Builderze, a usługę raportową opisuje tekst o usługach SQL Server Reporting Services.

Możliwości serwera raportów, w tym raporty stronicowane i mobilne, opisuje dokumentacja Microsoft Learn o SSRS. Projekt raportu zaczyna się od pytania, jaką decyzję ma wesprzeć zestawienie, bo raport bez odbiorcy szybko przestaje być używany.

Rozliczenie time and material

W modelu time and material zamawiający płaci za faktycznie przepracowane godziny według uzgodnionych stawek, a koszty materiałowe, takie jak licencje, doliczane są osobno. Zakres pozostaje elastyczny i może się zmieniać w trakcie prac. Rozliczenie odbywa się zwykle miesięcznie na podstawie ewidencji czasu pracy.

Wzór: należność za okres = suma (godziny pracy x stawka roli) + koszty materiałowe.

Model pasuje do projektów, w których zakres nie jest znany na początku albo zmienia się wraz ze zdobywaną wiedzą. Zamawiający kontroluje budżet przez limit godzin na iterację i raport z ewidencji czasu, a wykonawca nie musi wliczać w cenę ryzyka nieznanych wymagań. Wymaga to jednak zaufania i regularnych przeglądów postępu.

• Zaleta - zakres można zmieniać bez renegocjowania umowy, więc wnioski z pierwszych wersji trafiają od razu do kolejnych prac.
• Ryzyko - całkowity koszt nie jest znany z góry, więc potrzebny jest limit godzin i regularny przegląd zaawansowania.

Ewidencja czasu i raportowanie

Rozliczenie godzinowe wymaga rzetelnej ewidencji: kto pracował oraz ile godzin poświęcił na dane zadanie. Zamawiający dostaje zestawienie miesięczne z podziałem na zadania i role, co pozwala porównać wykorzystanie budżetu z postępem prac. Poniższe zapytanie, na przykładowej tabeli ewidencji, sumuje godziny według zadania i roli.

SELECT Zadanie,
       Rola,
       SUM(Godziny) AS Godziny
FROM dbo.EwidencjaCzasu
WHERE Data >= '2026-09-01' AND Data < '2026-10-01'
GROUP BY Zadanie, Rola
ORDER BY Zadanie, Rola;

Zestawienie ułatwia rozmowę o zakresie, bo widać, które zadania pochłaniają więcej godzin, niż zakładano. Jeśli pochłania je poprawianie tej samej funkcji, przyczyną bywa niejasny opis wymagania, a nie jakość wykonania.

Rozliczenie stałą ceną

Stała cena oznacza wynagrodzenie za zdefiniowany zakres, niezależnie od liczby przepracowanych godzin. Ryzyko przekroczenia pracochłonności ponosi wykonawca, dlatego wycena zawiera zapas na niepewność. Model wymaga szczegółowej specyfikacji przed startem, bo tylko wtedy odbiór ma jasne kryteria.

Specyfikacja jako warunek stałej ceny

Stała cena działa dobrze, gdy specyfikacja jest wystarczająco szczegółowa, aby dwie niezależne osoby zrozumiały ją tak samo. Dla raportu oznacza to listę kolumn oraz filtrów i reguł sortowania, a dla integracji opis pól komunikatu i sposobu obsługi błędów. Im mniej miejsca na interpretację, tym rzadziej pojawiają się spory przy odbiorze.

Zmiany zakresu w trakcie prac przechodzą przez procedurę zmian. Zamawiający zgłasza zmianę, wykonawca ją wycenia i wskazuje wpływ na termin, a po akceptacji zmiana trafia do zakresu jako aneks. Bez tej procedury stała cena kończy się sporem o to, co było w zakresie od początku.

Odbiór i wsparcie po wdrożeniu

Odbiór kończy etap wytwarzania, ale nie kończy współpracy. Protokół odbioru potwierdza, że wynik spełnia kryteria z umowy, a od jego podpisania biegnie okres gwarancji na błędy. Zmiany wymagań zgłoszone po odbiorze nie należą do gwarancji i są rozliczane osobno, zwykle według czasu pracy.

Wsparcie po wdrożeniu opisuje się w osobnej umowie serwisowej: czas reakcji na zgłoszenie oraz kanały kontaktu, a także sposób rozliczania godzin. Dobrze jest ustalić, kto po stronie zamawiającego przyjmuje zgłoszenia od użytkowników i przekazuje je wykonawcy, bo wiele zgłoszeń dotyczy szkolenia, a nie błędu.

Reguła: zgłoszenie powinno zawierać kroki odtworzenia i oczekiwany wynik, bo skraca to czas diagnozy.

Koszty okresu po odbiorze i sposób ich szacowania opisuje tekst o tworzeniu programów dla firm. Warto porównać te założenia z ofertą, zanim wybierze się model rozliczenia dla wytwarzania, bo część kosztów pojawia się dopiero po wdrożeniu.

Jak wybrać model rozliczenia

Wybór zależy od tego, jak dobrze znany jest zakres. Jeśli specyfikacja jest gotowa, na przykład raport o zdefiniowanych kolumnach albo integracja z opisanym interfejsem, stała cena daje przewidywalny budżet. Jeśli zakres dopiero się wyłania, lepiej sprawdza się time and material z limitem godzin.

Sygnałem do zmiany modelu jest wzrost liczby zgłoszeń zmian w projekcie o stałej cenie. Jeśli zmiany dotyczą już więcej niż kilku pozycji, rozliczenie za czas pracy bywa uczciwsze wobec obu stron, bo nie wymaga ciągłego aneksowania umowy. Odwrotnie, gdy w projekcie godzinowym zakres stabilizuje się, można przejść na stałą cenę za pozostałe etapy.

Model mieszany

Często stosuje się połączenie obu modeli. Analizę i projekt rozlicza się stałą ceną za etap, a wytwarzanie w iteracjach według czasu. Na początku zamawiający dostaje dokument, który pozwala potem oszacować pozostałe prace, a wykonawca nie ponosi ryzyka niezdefiniowanych wymagań. Sposób prowadzenia analizy przed wdrożeniem opisuje tekst o analizie przedwdrożeniowej.

Co powinna zawierać umowa

Niezależnie od modelu umowa opisuje kilka elementów, które ograniczają spory. Poniższa lista zbiera te, które najczęściej brakują w krótkich zleceniach.

• Zakres i wynik - opis każdego obszaru usługi oraz kryteria odbioru, sprawdzalne bez subiektywnej oceny.
• Własność kodu - wskazanie, komu przysługują prawa do kodu źródłowego i w jakim terminie wykonawca go przekazuje.
• Procedura zmian - sposób zgłaszania zmian zakresu oraz ich wyceny i akceptacji.
• Wsparcie po odbiorze - okres gwarancji na błędy oraz zasady rozliczania dalszych prac.

Ofertę usług programistycznych SoftwareStudio można porównać z opisem na stronie aplikacji SoftwareStudio. Ogólny opis współpracy z zamawiającym zawiera tekst o usługach programistycznych dla firm, a wybór wykonawcy ułatwia zestawienie z tekstem o software house.