Utrzymanie i rozwój Pimcore – stałe wsparcie platformy

Jednej stawki nie podajemy. Na wycenę wpływa zakres miesięcznych prac, liczba integracji i indywidualnych rozszerzeń, wersja platformy, stan techniczny projektu, zakres developmentu, liczba środowisk oraz wymagania dotyczące czasu reakcji — wszystkie osiem czynników rozpisaliśmy w sekcji o koszcie utrzymania. Konkretne warianty przekazujemy w ofercie, po audycie przejęcia.

Tak, przejęcie istniejącego projektu może być punktem rozpoczęcia współpracy. Najpierw potrzebujemy poznać kod, środowiska, integracje, wersję platformy, dokumentację oraz problemy zgłaszane przez użytkowników. Dopiero po tym można ustalić zakres stabilizacji i stałego utrzymania.

Od audytu, nie od pierwszej poprawki. Sprawdzamy wersję Pimcore i modułów, architekturę, modele danych, integracje, indywidualny kod, API, zadania cykliczne i kolejki, infrastrukturę, dokumentację oraz backlog. Cały proces, razem z artefaktami każdego etapu, opisuje sekcja o przejęciu utrzymania.

Najczęściej potrzebne są repozytorium kodu, dostęp do środowisk, logi, dokumentacja wdrożenia, opis integracji i kontakt do osób znających procesy biznesowe. Pełna lista zależy od architektury oraz podziału odpowiedzialności między dostawcami.

Tak, aktualizacje i poprawki bezpieczeństwa są częścią utrzymania, a nie osobnym projektem — o ile instalacja jest na wersji, z której da się aktualizować bez przebudowy. Jeżeli platforma stoi na wersji bez wsparcia, dojście do aktualnej bywa osobnym zakresem prac, wycenianym po ocenie kompatybilności.

Najpierw analizujemy wersję, zależności, indywidualne rozszerzenia i informacje o zmianach. Aktualizacja trafia na środowisko nieprodukcyjne, gdzie można sprawdzić procesy oraz integracje. Plan produkcyjny obejmuje sposób powrotu i obserwację działania po wydaniu. Sprawdzamy przy tym kompatybilność całego stosu, a nie tylko numer wersji core — moduły i rozszerzenia mają własne wydania.

Tak i to jest typowa część utrzymania. Dochodzą nowe klasy, pola, relacje i słowniki, migracje danych już wprowadzonych oraz zmiany w etapach przygotowania i uprawnieniach. Zakres ustalamy razem z wpływem zmiany na integracje i eksporty, bo model danych jest kontraktem także dla kanałów odbierających dane.

Usługa może łączyć bieżące utrzymanie z realizacją backlogu rozwojowego. Oba rodzaje prac mają osobne priorytety, ponieważ awaria wpływająca na dane wymaga innej obsługi niż zaplanowana funkcja.

Tak. Pojedyncze zadania — nowy eksport, dodatkowe pola w modelu, poprawka wydajności — mogą być realizowane w ramach ustalonej puli godzin albo wyceniane osobno. Przy większych zmianach architektury albo nowym connectorze wracamy do zakresu projektowego, żeby nie prowadzić przebudowy w trybie zgłoszeń.

Tak, w zakresie istniejących połączeń: diagnozujemy błędy synchronizacji, kolejki, harmonogramy i API oraz rozwijamy to, co już działa. Budowa nowego connectora albo gruntowna przebudowa wymiany danych zostaje potraktowana jako osobny zakres w ramach usługi Integracja Pimcore.

Tak. W projektach z dużą liczbą zaległości rozsądne jest rozpoczęcie od inwentaryzacji, listy ryzyk i planu stabilizacji. Stały model współpracy można ustalić po poznaniu rzeczywistego stanu platformy.

Model wynika z liczby zgłoszeń, oczekiwanego czasu obsługi, krytyczności procesów, zakresu monitoringu i planowanego rozwoju. Konkretne warianty, czasy reakcji i warunki SLA przekazujemy na etapie oferty.