Co naprawdę znaczy SLA na otwartym stacku

Umowa wsparcia na oprogramowanie, które dostawca sam napisał, to prosta obietnica: kod jest jego, więc może naprawić wszystko. Umowa na oprogramowanie open source to obietnica innego rodzaju, a udawanie, że jest inaczej, to najczęstsza nieuczciwość w tej branży. Użyteczna wersja zaczyna się od jasnego rozdzielenia tego, co da się zadeklarować, od tego, czego się nie da.

Co można uczciwie obiecać

Czas reakcji. Kompetentna osoba patrzy na Twój problem w zdefiniowanym oknie, zależnym od priorytetu. To leży całkowicie po stronie dostawcy i to jest rdzeń tego, co kupujesz.

Diagnoza. Informacja, co jest nie tak — czy to Twoja konfiguracja, Twoja infrastruktura, czy oprogramowanie — i jakie są opcje. W praktyce to większość wartości: większość incydentów to konfiguracja albo środowisko, a wiedza o tym w ciągu godziny powstrzymuje zły dzień przed staniem się złym tygodniem.

Obejście. Przywrócenie działania, co zwykle nie jest tym samym co usunięcie przyczyny. Wycofanie zmiany, przekonfigurowanie, dołożenie mocy, czasowe przełączenie na inną ścieżkę.

Poprawka albo upstream. Tam, gdzie defekt jest w oprogramowaniu — albo łatamy go dla Ciebie, albo niesiemy zmianę do projektu. Obie rzeczy to realna praca i obie da się zadeklarować.

Czego nie można uczciwie obiecać

Naprawy w konkretnym czasie, dla dowolnego błędu. Nikt nie może tego obiecać — nawet dostawca będący właścicielem kodu, choć on chętniej to zasugeruje. Obiecać można wysiłek, eskalację i obejście, a dostawca deklarujący więcej albo jest niedoświadczony, albo liczy na to, że nie przeczytasz wyłączeń.

Przyjęcia zmiany w upstreamie. Patch zaniesiony do projektu może zostać odrzucony, przeprojektowany albo leżeć rok. Zobowiązaniem może być utrzymywanie go dla Ciebie w międzyczasie, a nie kontrola nad społecznością, której nie prowadzisz.

Zachowania modelu. Szczególnie istotne tutaj. „Prognoza wyglądała źle” nie jest defektem, dopóki nie zostanie scharakteryzowana, a proces zamiany tego w defekt wygląda inaczej niż przy awarii. To powinno być w umowie wprost, a nie odkrywane przy pierwszym sporze.

Części, których nikt nie czyta, a mają największe znaczenie

Definicje priorytetów. Czyja definicja słowa „krytyczny”? Jeśli priorytet nadaje dostawca, każdy incydent jest negocjacją. Zapisz kryteria w kategoriach wpływu na biznes — magazyn stoi, zamknięcie miesiąca się nie kończy — a spór znika.

Zegar. Kiedy zaczyna biec czas reakcji: gdy wysyłasz maila, gdy człowiek go czyta, czy gdy zgłoszenie zostaje przypisane? Czy biegnie w nocy? Drobny druk o dużych konsekwencjach.

Granice zakresu. Które komponenty, które wersje, które integracje. Umowa obejmująca stack, ale nie integrację z Twoim ERP, obejmuje akurat tę część, która rzadko się psuje.

Eskalacja. Do kogo docierasz, gdy pierwsza reakcja nie działa, i jak szybko. Osoba z imienia bije kolejkę, a kolejka bije formularz.

Dlaczego klauzula wyjścia należy do tej samej rozmowy

Niewygodna prawda o umowach wsparcia jest taka, że dostawca ma interes w tym, żebyś go dalej potrzebował. Przy oprogramowaniu zamkniętym masz mały wybór. Przy open source masz — i liczy się to tylko wtedy, gdy praktyczne wyjście naprawdę istnieje.

Umowa powinna więc mówić, co się dzieje przy odejściu: konfiguracja przekazana w używalnej formie, dokumentacja tego, co i dlaczego zmieniono, zdefiniowany okres przejściowy. Ustalone na starcie, kiedy masz siłę negocjacyjną.

Dostawca, który nie chce tego zapisać, właśnie powiedział Ci, na czym opiera swoją retencję.