Deliverable – co to znaczy i jak go opisać?

Deliverable to konkretny, mierzalny rezultat projektu – na przykład raport, moduł oprogramowania, projekt architektoniczny albo gotowa strona internetowa. Można go sprawdzić, odebrać i zatwierdzić. Zadanie opisuje czynność prowadzącą do powstania rezultatu, a deliverable jest jej wynikiem.

Co to jest deliverable?

W zarządzaniu projektami deliverable oznacza produkt, usługę lub inny wynik pracy, który należy dostarczyć po zakończeniu określonego etapu albo całego projektu. Może mieć formę materialną, taką jak budynek lub wydrukowany raport, albo cyfrową, jak kod źródłowy, dokumentacja czy działająca strona internetowa.

Najprościej odróżnić deliverable od zadania, patrząc na formę opisu. Zadanie jest czynnością, zwykle wyrażoną czasownikiem, na przykład „zaprojektować stronę główną” albo „napisać kod”. Deliverable jest rezultatem, czyli czymś, co można obejrzeć, przetestować i formalnie zaakceptować, na przykład „strona główna w HTML i CSS z formularzem kontaktowym”.

W projekcie strony internetowej pisanie kodu, przygotowanie makiety i konfiguracja serwera są zadaniami. Ich wynikiem mogą być osobne deliverables: zaakceptowana makieta, działający moduł logowania, dokumentacja techniczna i opublikowana wersja serwisu.

Przykłady deliverables w różnych branżach

Rezultat projektu zależy od branży, ale zawsze powinien dać się odróżnić od samej pracy wykonywanej przez zespół. Przykłady obejmują:

• IT – gotowy moduł aplikacji, baza danych, dokumentacja techniczna, działająca strona internetowa.
• Budownictwo – projekt architektoniczny, pozwolenie na budowę, stan surowy budynku, protokół odbioru.
• Marketing – strategia komunikacji, projekt graficzny, uruchomiona kampania, raport wyników kampanii.

W większych przedsięwzięciach deliverables mogą powstawać etapami. Dla strony internetowej jednym rezultatem będzie makieta zaakceptowana przez klienta, kolejnym gotowy interfejs, a następnie wdrożona i przetestowana wersja serwisu.

Jak opisać deliverable?

Dobry opis powinien być na tyle konkretny, aby zespół, klient i osoba odbierająca pracę rozumieli go tak samo. Pomaga w tym podejście SMART. Rezultat powinien być konkretny, mierzalny, uzgodniony z odbiorcą, możliwy do wykonania i określony w czasie. Nie chodzi o tworzenie rozbudowanego dokumentu dla każdego drobnego elementu, lecz o usunięcie niejasności tam, gdzie mogą pojawić się różne interpretacje.

Opis deliverable możesz przygotować w pięciu krokach:

1. Nadaj nazwę – użyj rzeczownika opisującego wynik, na przykład „strona główna serwisu”, a nie „przygotowanie strony głównej”.
2. Opisz zawartość – wskaż, co dokładnie obejmuje rezultat, w jakiej formie ma zostać dostarczony i jakie elementy musi zawierać.
3. Ustal kryteria akceptacji – zapisz, po czym poznacie, że deliverable jest gotowy. W przypadku strony mogą to być działanie formularza, poprawne wyświetlanie na urządzeniach mobilnych i zgodność z uzgodnionymi wymaganiami dostępności.
4. Wskaż właściciela – określ osobę lub zespół odpowiedzialny za przygotowanie rezultatu i doprowadzenie go do odbioru.
5. Dodaj termin – określ, kiedy rezultat ma być gotowy do weryfikacji lub formalnego przekazania.

Najważniejszą częścią opisu są kryteria akceptacji. To konkretne warunki odbioru, a nie ogólne stwierdzenie, że rezultat ma być „dobry”, „nowoczesny” albo „wysokiej jakości”. Dla strony głównej kryteria mogą obejmować zaakceptowany projekt graficzny, działające odnośniki, poprawne wyświetlanie w ustalonych przeglądarkach i przekazanie plików źródłowych.

Warto też zachować proporcję. Zbyt ogólny opis powoduje spory i poprawki, ale nadmiernie szczegółowy może spowolnić planowanie. Poziom szczegółowości powinien zależeć od złożoności projektu, ryzyka i doświadczenia zespołu.

Dobry i słaby opis deliverable – porównanie

Poniższy przykład pokazuje, jak zmiana kilku elementów wpływa na możliwość planowania i odbioru rezultatu:

Dobry zapis pozwala określić, co rzeczywiście ma zostać dostarczone, kto może to odebrać i jakie testy należy wykonać. Nie przesądza przy tym, jak zespół ma realizować każde zadanie. Opisuje rezultat, a nie wszystkie czynności potrzebne do jego powstania.

Dlaczego precyzyjne deliverables mają znaczenie?

Jasno zdefiniowane rezultaty porządkują zakres projektu. Na ich podstawie można rozbić pracę w strukturze podziału pracy, czyli WBS, przypisać zadania i odpowiedzialności oraz zaplanować terminy. WBS pokazuje, jakie czynności prowadzą do dostarczenia poszczególnych wyników, ale nie zastępuje samego opisu deliverable.

Precyzyjne rezultaty ograniczają ryzyko scope creep, czyli niekontrolowanego rozszerzania zakresu. Gdy klient prosi o dodatkową funkcję strony, łatwiej ocenić, czy mieści się ona w uzgodnionym deliverable, czy wymaga osobnej decyzji. Można wtedy sprawdzić wpływ zmiany na czas, koszt i jakość, zamiast dodawać ją do projektu bez analizy.

Opis pomaga także w komunikacji z interesariuszami. Każda strona może odwołać się do tych samych kryteriów, zamiast opierać odbiór na własnych oczekiwaniach. Zespół wie, kiedy rezultat jest ukończony, a osoba odbierająca ma podstawę do zgłoszenia konkretnej uwagi.

Najlepszy opis deliverable odpowiada na pięć pytań: co powstaje, co zawiera, po czym poznamy gotowość, kto za niego odpowiada i kiedy ma zostać dostarczony. Taki zapis łączy mierzalność z użytecznością i ułatwia kontrolę projektu od planowania do odbioru.