Oprogramowanie na zamówienie: systemy i integracje, których nie kupisz z półki

Rozstrzyga umowa i to nie jest wykręt, tylko jedyna uczciwa odpowiedź: prawa dzielą się na trzy warstwy i każda ma inny status. Kod pisany dla Was, nasze komponenty wielokrotnego użytku, których używamy też u innych klientów, oraz biblioteki zewnętrzne, do których nikt nie może przenieść praw, bo ich nie ma. Umowa nazywa każdą z tych warstw osobno i podpisujemy ją przed startem, nie po. Niezależnie od praw dostajecie od pierwszego dnia repozytorium, dokumentację techniczną i dostępy, a to jest ta część, która decyduje o tym, czy da się z nami rozstać i rozwijać system dalej z kimś innym.

Zwykle tak i zwykle o to pytamy najpierw. Jeśli macie ERP, część potrzeb da się pokryć jego modułem albo dodatkiem z katalogu producenta. Wtedy powiemy to wprost, choć znaczy to mniejsze zlecenie dla nas. Własny kod ma sens tam, gdzie standard się kończy: nietypowy proces, moduł, którego nie ma w katalogu, integracja bez gotowego konektora.

Bierzemy takie zlecenia, ale zaczynamy od audytu kodu i dokumentacji, bo dopiero on mówi, ile kosztuje utrzymanie tego, co jest. Bywa, że wychodzi z niego rekomendacja napisania modułu albo całości od nowa. Sprawdzamy pięć rzeczy: czy są testy, czy istnieje dokumentacja, czy technologia ma jeszcze wsparcie producenta, czy da się dotrzeć do autorów i czy roczny koszt utrzymania nie przekracza kosztu odtworzenia. Napisanie od nowa bywa dziś tańsze, niż było kiedyś, bo najdroższą jego częścią nie jest pisanie kodu, tylko odtworzenie logiki biznesowej z cudzego systemu, a akurat tę pracę narzędzia skracają. Ale to nie jest reguła i nie sprzedajemy jej jako reguły: rozstrzyga audyt. Mówimy o tym, choć wieloletnie utrzymanie cudzego kodu byłoby dla nas lepszym interesem.

Pracujemy w dwutygodniowych cyklach i po każdym widzicie działającą wersję, więc korekta kierunku jest wbudowana w sposób pracy, a nie awarią. Zmiana, która wychodzi poza wyceniony zakres, dostaje osobną wycenę przed wykonaniem, nie po. Elementy opcjonalne są zaznaczone już w wycenie MVP właśnie po to.

Domyślnie my, na umowie serwisowej albo na godziny, z monitoringiem i ustalonym rytmem poprawek. Ale przekazanie repozytorium i dokumentacji znaczy, że możecie to przejąć sami albo oddać komuś innemu. Aplikacja, której nie da się utrzymać bez autora, jest źle napisana.

Nie. Piszemy dla firm oprogramowanie, które pracuje z systemem ERP: moduły dodatkowe, integracje i aplikacje webowe dla zespołów. Aplikacji konsumenckich, takich jak aplikacja fitness czy gra, nie robimy. To inna specjalizacja i lepiej wyjdziecie na firmie, która robi to na co dzień.