Jasny zakres usługi bez niedomówień. 10 elementów, dzięki którym klient wie, co kupuje

W aktualnych amerykańskich Federal Acquisition Regulation dla usług opartych na wynikach zaleca się opisywanie pracy przede wszystkim przez wymagane rezultaty, a nie przez narzucanie sposobu wykonania lub samej liczby godzin. Dokument wskazuje także na mierzalne standardy wykonania, a w opisie celów wymienia między innymi cel, zakres, okres i miejsce wykonania, kontekst, wymagane rezultaty oraz ograniczenia. [1]

Brytyjski Digital, Data and Technology Playbook również promuje jasne specyfikacje oparte na rezultatach. Wprost zaleca skupienie się na użytkowniku i problemie do rozwiązania, a nie na z góry narzuconym rozwiązaniu technicznym. [2]

Z kolei aktualna brytyjska nota dotycząca podziału ryzyka i modeli cenowych podkreśla, że wskaźniki wykonania powinny być mierzalne i obiektywne, a dostawca powinien odpowiadać za wyniki, na które rzeczywiście ma wpływ. [3]

To są źródła z obszaru zamówień publicznych, a nie uniwersalny wzór dla wszystkich usług. Pokazują jednak bardzo użyteczną zasadę: dobry zakres powinien nazywać oczekiwany wynik, sposób jego oceny oraz ograniczenia odpowiedzialności.

Dobry opis usługi powinien jednocześnie pomagać:

Klientowi - zrozumieć, co otrzyma, czego nie otrzyma i czego będzie się od niego wymagać.

Specjaliście - określić granice odpowiedzialności, założenia i moment, w którym dodatkowa prośba staje się zmianą zakresu.

Obu stronom - ustalić, po czym będzie można rozsądnie stwierdzić, że uzgodniona praca została wykonana.

Jeżeli opis dobrze spełnia tylko jedną z tych funkcji, nadal może pozostawiać dużo miejsca na spór lub różne interpretacje.

Najpierw wyjaśnij, po co usługa jest potrzebna.

Nie zaczynaj od listy narzędzi ani czynności, jeżeli klient jeszcze nie rozumie celu.

Zamiast:

„Konfiguracja analityki, raportu i zdarzeń.”

lepiej:

„Celem jest uzyskanie wiarygodnych danych o tym, z których etapów formularza użytkownicy najczęściej rezygnują, aby zespół mógł wskazać miejsca wymagające poprawy.”

Takie podejście jest zgodne z zasadą opisywania potrzeb i rezultatów zamiast narzucania rozwiązania, którą stosuje brytyjski Digital, Data and Technology Playbook. [2]

Cel odpowiada na pytanie „dlaczego?”, a rezultat na pytanie „co ma istnieć albo być prawdą po zakończeniu pracy?”

Rezultatem może być między innymi:

• gotowy dokument,
• działająca funkcja,
• wdrożona konfiguracja,
• wykonane badanie z wnioskami,
• zestaw przygotowanych materiałów,
• przeprowadzona sesja wraz z określonym podsumowaniem.

W FAR dla usług opartych na wynikach wymagania są opisywane przede wszystkim przez wymagane rezultaty, a nie sam sposób wykonania. [1]

Nie oznacza to, że każda usługa musi gwarantować wynik biznesowy, którego specjalista nie kontroluje. Na przykład wdrożenie kampanii można zobowiązać się wykonać, ale gwarantowany wzrost sprzedaży o 30% może zależeć od wielu czynników poza kontrolą wykonawcy.

Zakres powinien nazywać konkretne części pracy objęte uzgodnieniem.

Przykładowo przy projekcie strony mogą to być:

• analiza obecnej strony,
• przygotowanie architektury informacji,
• projekt określonej liczby widoków,
• przygotowanie wersji na urządzenia mobilne,
• wdrożenie zaakceptowanego projektu,
• podstawowa dokumentacja przekazania.

Nie chodzi o tworzenie jak najdłuższej listy. Chodzi o to, aby najważniejsze elementy wpływające na pracochłonność i oczekiwania były nazwane przed rozpoczęciem pracy.

Zakres opisuje pracę, a elementy dostawy opisują co klient faktycznie otrzyma.

Może to być na przykład:

• plik źródłowy,
• raport w określonym formacie,
• działający moduł,
• repozytorium z kodem,
• zestaw grafik,
• nagranie,
• dokumentacja,
• lista rekomendacji,
• dostęp do skonfigurowanego środowiska.

Jeżeli forma rezultatu ma znaczenie, nazwij ją. „Raport” może oznaczać dwie strony tekstu albo rozbudowany dokument z analizą, priorytetami i przykładami. Sama nazwa nie zawsze wystarcza.

Kryteria akceptacji odpowiadają na pytanie: po czym można stwierdzić, że uzgodniony rezultat został dostarczony zgodnie z wymaganiem?

Mogą dotyczyć na przykład:

• kompletności,
• zgodności z uzgodnioną specyfikacją,
• określonego formatu,
• działania na wskazanych urządzeniach lub środowiskach,
• maksymalnej liczby błędów określonej kategorii,
• czasu realizacji,
• określonych parametrów jakościowych.

FAR wymaga, aby standardy wykonania w opartych na wynikach kontraktach usługowych były mierzalne i pozwalały oceniać wykonanie. [1]

Brytyjska nota dotycząca ryzyka dodatkowo wskazuje, że mierniki powinny być obiektywne i odnosić się do rezultatów, na które dostawca ma wpływ. [3]

Dlatego kryterium „klient będzie zadowolony” jest znacznie mniej użyteczne niż kryterium odnoszące się do konkretnego, obserwowalnego rezultatu.

Usługa często zależy od działań drugiej strony.

Warto wskazać, czy klient ma zapewnić:

• dostęp do systemów,
• treści lub materiały,
• dane,
• informacje o marce,
• decyzje i akceptacje,
• osobę kontaktową,
• środowisko testowe,
• odpowiedzi w określonym czasie.

Jeżeli brak materiałów po stronie klienta może zatrzymać pracę, powinno być to jasne.

Odpowiedzialność za termin nie powinna być opisywana tak, jakby specjalista kontrolował działania, których faktycznie nie kontroluje.

Cena i termin często są poprawne tylko przy określonych założeniach.

Przykłady:

• istniejąca baza danych jest dostępna i poprawnie działa,
• klient posiada prawa do dostarczonych materiałów,
• integracja z systemem zewnętrznym ma działający interfejs,
• projekt nie wymaga migracji historycznych danych,
• liczba wersji językowych jest z góry określona,
• decyzje będą podejmowane przez jedną wskazaną osobę.

GAO w przewodniku dotyczącym wiarygodnego szacowania kosztów traktuje jasne określenie zakresu, podstaw technicznych, reguł i założeń oraz analizę ryzyka i niepewności jako elementy dobrego procesu estymacji. [4]

W mniejszej usłudze nie trzeba kopiować procesu przeznaczonego dla dużych programów. Warto jednak stosować samą zasadę: jeżeli wycena zależy od czegoś, co może okazać się nieprawdą, nazwij to.

Wyłączenia nie są oznaką słabej oferty. Często są oznaką dobrze zdefiniowanego zobowiązania.

Jeżeli coś łatwo można pomylić z elementem objętym usługą, warto napisać wprost, że nie jest w cenie.

Przykładowo:

• zakup licencji,
• tworzenie treści,
• płatne zdjęcia,
• tłumaczenia,
• utrzymanie po wdrożeniu,
• prace nad innym systemem,
• nieograniczona liczba poprawek,
• koszty usług zewnętrznych.

Nie trzeba wypisywać wszystkiego, czego specjalista nie zrobi. Najbardziej użyteczne są wyłączenia realistycznie mogące zostać uznane przez klienta za część usługi.

Termin powinien mówić więcej niż „około dwóch tygodni”, jeżeli przebieg zależy od akceptacji i materiałów klienta.

Warto ustalić:

• od czego liczy się rozpoczęcie,
• czy są etapy pośrednie,
• jakie decyzje zamykają kolejne etapy,
• ile czasu klient ma na odpowiedź, jeżeli wpływa to na harmonogram,
• jak komunikowane są opóźnienia,
• jak wygląda odbiór końcowy.

W prostej usłudze wystarczy kilka zdań. W większej współpracy etapy pomagają obu stronom rozumieć, co już zostało wykonane i co musi wydarzyć się dalej.

Dobry opis usługi powinien wyjaśniać, co dzieje się, gdy po rozpoczęciu pracy pojawia się nowe wymaganie.

Praktyczny mechanizm może być bardzo prosty:

„Prace wykraczające poza opisany zakres wymagają potwierdzenia nowego zakresu, wpływu na termin i ewentualnej dodatkowej ceny przed rozpoczęciem ich realizacji.”

Warto również jasno podać:

• model rozliczenia,
• cenę albo sposób jej obliczania,
• zasady płatności,
• dodatkowe koszty, jeżeli mogą wystąpić,
• reguły dotyczące dodatkowych rund poprawek.

To nie eliminuje zmian. Sprawia tylko, że zmiana jest świadomą decyzją, a nie ukrytym rozszerzeniem pierwotnego zobowiązania.

Jasny zakres nie oznacza konieczności narzucenia wykonawcy każdego kroku.

Brytyjski Digital, Data and Technology Playbook ostrzega przed nadmiernym określaniem rozwiązania i wskazuje, że specyfikacje oparte na rezultatach mogą pozostawiać wykonawcy przestrzeń na zaproponowanie skuteczniejszego sposobu rozwiązania problemu. [2]

FAR podobnie preferuje opis wymaganych rezultatów zamiast wskazywania dokładnie, jak praca ma zostać wykonana. [1]

Dlatego:

„strona ma poprawnie obsługiwać uzgodnione scenariusze na wskazanych urządzeniach”

może być lepszym wymaganiem niż szczegółowe narzucanie implementacji, jeżeli technologia sama w sobie nie jest istotnym ograniczeniem.

Oczywiście w niektórych usługach metoda ma znaczenie ze względu na bezpieczeństwo, zgodność, integrację lub standard techniczny. Wtedy powinna zostać opisana.

Przy tworzeniu zakresu ważne jest rozróżnienie między:

rezultatem pracy specjalisty a wynikiem biznesowym zależnym również od innych czynników.

Specjalista może zobowiązać się do:

• przygotowania i uruchomienia kampanii zgodnie z uzgodnionym zakresem,
• wykonania analizy,
• dostarczenia określonej liczby materiałów,
• wdrożenia funkcji spełniającej zdefiniowane kryteria.

Znacznie ostrożniej należy traktować gwarancje dotyczące sprzedaży, liczby klientów, pozycji w wyszukiwarce czy innych wyników zależnych od rynku, budżetu, produktu, działań klienta albo systemów zewnętrznych.

Aktualna brytyjska nota o podziale ryzyka mówi wprost, że dostawca powinien odpowiadać za rezultaty, na które może wpływać. [3]

Dobry opis nie osłabia zobowiązania. Przypisuje odpowiedzialność tam, gdzie rzeczywiście istnieje kontrola.

Nie każda usługa wymaga wielostronicowego dokumentu.

Przy prostym zadaniu można zamknąć wszystkie istotne informacje w kilku akapitach. Przy większym projekcie ten sam sposób myślenia może rozwinąć się w szczegółową specyfikację, harmonogram, kryteria odbioru i formalny proces zmian.

Przykładowe Terms of Reference udostępnione przez Bank Światowy podkreślają, że dokument powinien jasno przedstawiać wymagania dotyczące usług i oczekiwania zamawiającego oraz musi być dostosowany do konkretnego projektu i lokalnych uwarunkowań. [4]

Najważniejsza nie jest długość. Najważniejsze jest to, czy brakująca informacja może realistycznie zmienić cenę, termin, odpowiedzialność albo oczekiwany rezultat.

Opis usługi na stronie lub w profilu może być tylko jednym z elementów procesu zawarcia umowy. Konkretne obowiązki prawne zależą od kraju, rodzaju transakcji, statusu stron oraz sposobu sprzedaży.

W relacjach przedsiębiorca-konsument w UE oficjalny portal Your Europe wskazuje między innymi obowiązek przekazania przed zakupem jasnych informacji o głównych cechach usługi, całkowitej cenie z opłatami, sposobie płatności i wykonania oraz, jeżeli ma zastosowanie, czasie trwania umowy. [5]

Unijne materiały dla firm wskazują również, że standardowe warunki umów konsumenckich muszą być uczciwe i sformułowane prostym, zrozumiałym językiem, tak aby konsument mógł zrozumieć również ich skutki ekonomiczne. [6]

Te wymogi dotyczą określonych relacji konsumenckich w UE. Nie należy automatycznie przenosić ich na wszystkie transakcje między firmami ani na inne jurysdykcje.

Ten artykuł jest przewodnikiem redakcyjnym dotyczącym opisywania usług, a nie wzorem umowy ani poradą prawną.

1. Czy klient rozumie, jaki problem lub cel ma rozwiązać usługa?
2. Czy rezultat końcowy jest nazwany?
3. Czy wiadomo, co dokładnie znajduje się w zakresie?
4. Czy klient wie, jakie konkretne elementy otrzyma?
5. Czy istnieje rozsądny sposób oceny wykonania?
6. Czy wiadomo, czego klient musi dostarczyć lub dopilnować?
7. Czy najważniejsze założenia są jawne?
8. Czy oczywiste, potencjalnie mylące wyłączenia są opisane?
9. Czy termin i etapy uwzględniają zależności po obu stronach?
10. Czy wiadomo, co dzieje się przy zmianie zakresu?
11. Czy cena, model rozliczenia i dodatkowe koszty są przedstawione na właściwym etapie?
12. Czy opis nie obiecuje wyniku, którego specjalista nie kontroluje?

Najlepszy test dobrego opisu jest prosty.

Po jego przeczytaniu klient i specjalista powinni w podobny sposób odpowiedzieć na pytania:

Co ma zostać osiągnięte? Co zostanie wykonane? Co otrzyma klient? Czego usługa nie obejmuje? Co musi zrobić klient? Po czym poznamy, że praca została wykonana? Co stanie się, jeżeli zakres się zmieni?

Jeżeli odpowiedzi są spójne, cena i termin mają znacznie lepszy kontekst.

Jeżeli odpowiedzi są różne, problem często nie zaczyna się podczas realizacji. Zaczyna się już w opisie usługi.

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Przejdź do źródła

[2] UK Government - The Digital, Data and Technology Playbook
Przejdź do źródła

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Przejdź do źródła

[4] World Bank - Sample Consultants Terms of Reference
Przejdź do źródła

[5] Your Europe - Contract information: what you should know before buying
Przejdź do źródła

[6] Your Europe - Contracts with consumers
Przejdź do źródła

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Przejdź do źródła

Nota metodologiczna: źródła mają różny zakres i nie tworzą jednego wspólnego standardu opisu usług. Artykuł wykorzystuje z nich wyłącznie zasady, które rzeczywiście wspierają: koncentrację na rezultacie, mierzalność, jasny zakres, założenia, odpowiedzialność za czynniki pod kontrolą wykonawcy oraz przejrzystość informacji dla klienta.