Zasady przewodnie zamiast strategii w szufladzie

Zasady przewodnie ITIL 4 to zalecenia, które działają w każdych okolicznościach. Jak zamienić je w filtr backlogu, zanim strategia zbierze kurz w slajdach.

Zasady przewodnie (ang. guiding principles) to zalecenia, które kierują organizacją w każdych okolicznościach — niezależnie od zmiany celów, strategii czy struktury. W ITIL 4 stanowią jądro biblioteki: siedem zasad, które da się stosować także poza klasycznym zarządzaniem usługami IT. Definicja jest prosta. Problem zaczyna się, gdy strategia biznesowa leży w slajdach, a sprinty i tak realizują życzenia z backlogu.

Dla zespołu product-tech w startupie albo firmie rosnącej to pytanie praktyczne: czy macie wspólny filtr decyzji, który łączy wizję z backlogiem i długiem technologicznym? Czy każdy kwartał zaczynacie od nowej prezentacji, bo poprzednia „już nie działa”?

Co widać w źródłach wokół zasad przewodnich

Materiał o ITIL 4 wymienia siedem zasad: Focus on Value, Start Where You Are, Progress Iteratively with Feedback, Collaborate and Promote Visibility, Think and Work Holistically, Keep it Simple and Practical, Optimize and Automate. Działają razem — nie wybieracie jednej „ulubionej” i nie wdrażacie ich w oderwaniu od kultury pracy zespołu.

Obok definicji w wynikach wyszukiwania wraca wątek operacjonalizacji strategii: jak połączyć wizję z codziennością, żeby strategia nie zbierała kurzu w szufladzie. Szkolenia o kaskadowaniu celów i wdrożeniu strategii mówią o naturze celów, roli projektów i procesów oraz o tym, kto realnie realizuje strategię. Dla nas to jedno: zasady przewodnie to język decyzji na refinementcie, nie slajd z definicjami.

Gdzie zespół product-tech płaci koszt teraz

Typowy obraz: cele na ścianie, backlog w narzędziu, dług technologiczny „na później”. Product i tech czytają o zarządzaniu produktem, ale na refinementcie nie ma wspólnej reguły wejścia do sprintu. Pierwsza głośna prośba wygrywa miejsce w kolejce. Strategia wraca co kwartał w nowej prezentacji — to koszt braku operacjonalizacji.

Drugi koszt: start od zera przy każdej zmianie. Zespół chce „przebudować wszystko”, bo stary proces „nie działa” — i traci to, co już działa: ludzi, dane, praktyki, które dało się przenieść. Trzeci: automatyzacja przed optymalizacją. Budujecie automatyzację pod proces, który nadal produkuje hałas w backlogu. Przy skalowaniu rośnie liczba zadań, nie jasność decyzji.

Ruch warsztatowy — siedem filtrów na jedną sesję

Metoda na 90–120 minut, bez certyfikacji ITIL:

1. Jedna tablica, siedem pytań. Dla każdej pozycji z top 10 backlogu (albo listy „pilnych” inicjatyw) zespół odpowiada krótko na siedem filtrów. Nie esej — jedna linia na filtr. Facylitator pilnuje tempa.

• Wartość: czyja konkretnie i jak ją zmierzycie w tym miesiącu?
• Zacznij od tego, co masz: co już działa i zostaje, zamiast budować od zera?
• Iteracja i informacja zwrotna: jaki najmniejszy krok w 1–2 tygodnie i skąd wróci sygnał z rynku albo z zespołu?
• Widoczność: kto musi widzieć decyzję (product, tech, biznes) — i gdzie to wisi publicznie?
• Całość: który dział ucierpi albo zyska, jeśli to zrobicie?
• Prostota: ile kroków da się wyciąć, zanim coś zbudujecie?
• Najpierw optymalizacja, potem automatyzacja: czy automatyzujecie już sensowny proces, czy tylko chaos?

2. Reguła wejścia do sprintu. Pozycja bez odpowiedzi na „wartość + iteracja” nie wchodzi do bieżącego sprintu. Ląduje na liście odłożonych z datą rewizji i jednym właścicielem decyzji — nie w wiecznym zawieszeniu.

3. Dług technologiczny pod tym samym filtrem. Spłata długu też przechodzi przez „wartość / prostota / optymalizacja”. Jeśli nie da się wskazać, jaki wynik biznesowy albo wolne moce zespołu odblokuje — nie dostaje miejsca „bo inżynierowie chcą”. Dostaje miejsce dopiero z uzasadnieniem, które product i tech wspólnie podpiszą.

4. Jedna decyzja na wyjściu. Po sesji zostaje lista: 3–5 rzeczy „budujemy w tym cyklu”, lista „świadomie nie” oraz zasady, które zespół zgadza się powtórzyć na następnym refinementcie. Strategia przestaje być prezentacją — staje się zestawem pytań przy każdej karteczce.

Na jakie pytanie odpowiada ten tekst

Jeśli szukacie „czym są zasady przewodnie w ITIL 4” albo „jak operacjonalizować strategię w zespole produktowym”, krótka odpowiedź: to uniwersalne zalecenia decyzyjne (siedem zasad), które da się użyć jako filtr backlogu i długu technologicznego — pod warunkiem, że zamienicie je w pytania na warsztacie, a nie w definicje na slajdzie.

Przetestuj filtr na własnym backlogu

Weźcie dziesięć pozycji z kolejki i przepuśćcie je przez siedem pytań. Jeżeli chcecie zrobić to z facylitatorem i wyjść z decyzją product–tech–biznes, a nie tylko z notatkami — zobacz warsztaty NBB.