Metodyki Agile zyskały znaczną popularność w ostatnich latach dzięki swojej zdolności szybkiego dostarczania produktów oraz dostosowania się do zmieniających się wymagań. Jednak nie wszystkie projekty są realizowalne, a więc kluczowe jest podejmowanie świadomych decyzji, czy kontynuować projekt, czy nie. Lista kontrolna Go/No-Go w połączeniu z podejściem opartym na ważeniu ocen może stanowić ramy do oceny realizowalności projektu Agile. W tym artykule omówimy znaczenie listy kontrolnej Go/No-Go oraz sposób, w jaki podejście oparte na ważeniu ocen może pomóc w podejmowaniu świadomych decyzji.
Dlaczego lista kontrolna Go/No-Go dla projektów Agile
Badania realizowalności są kluczowym elementem procesu rozwoju projektów Agile. Badania te przeprowadza się w celu oceny praktycznej realizowalności zaproponowanego projektu oraz ustalenia, czy projekt jest realistyczny pod względem zakresu, budżetu i harmonogramu. Jednym z kluczowych elementów badania realizowalności jest lista kontrolna Go/No-Go, która służy do ustalenia, czy projekt powinien zostać uruchomiony, zawieszony czy zakończony. W tym artykule omówimy proces przed i po zastosowaniu listy kontrolnej Go/No-Go w badaniu realizowalności projektu Agile.
Przed badaniem realizowalności
Zanim rozpoczniesz badanie realizowalności, kluczowe jest posiadanie jasnego zrozumienia celów projektu, jego zakresu oraz wymagań stakeholderów. Badanie realizowalności projektu zwykle obejmuje ocenę realizowalności technicznej, finansowej, operacyjnej i rynkowej projektu. Ważne jest posiadanie szczegółowego planu badania realizowalności oraz zaangażowanie wszystkich istotnych stakeholderów w ten proces.
Lista kontrolna Go/No-Go to istotny narzędzie stosowane podczas badania realizowalności. Określa kryteria, które muszą zostać spełnione, aby projekt mógł kontynuować się dalej. Kryteria obejmują zazwyczaj realizowalność techniczną, realność finansową, popyt rynkowy oraz dostępność zasobów. Lista kontrolna Go/No-Go pomaga zapewnić, że wszystkie kluczowe czynniki są rozważone, a potencjalny sukces projektu oceniony przed jego rozpoczęciem.
Po badaniu realizowalności
Po zakończeniu badania realizowalności lista kontrolna Go/No-Go służy do ustalenia, czy projekt powinien zostać uruchomiony, zawieszony czy zakończony. Jeśli projekt spełnia wszystkie kryteria wymienione na liście, uznaje się go za realizowalny i może kontynuować się dalej. Jeśli projekt nie spełnia żadnego z kryteriów, może być konieczne zawieszenie lub zakończenie projektu, aż do rozwiązania problemu.
Lista kontrolna Go/No-Go to cenny narzędzie zapewniające szczegółową ocenę realizowalności projektu przed jego rozpoczęciem. Pomaga w identyfikacji potencjalnych ryzyk i problemów, które mogą wpłynąć na sukces projektu. Korzystając z listy, stakeholderzy mogą podejmować świadome decyzje, czy kontynuować projekt.
Zalety stosowania listy kontrolnej Go/No-Go
Istnieje kilka zalet stosowania listy kontrolnej Go/No-Go w badaniu realizowalności projektu Agile. Są to m.in.:
- Jasne kryteria: lista kontrolna określa jasne kryteria, które muszą zostać spełnione, aby projekt mógł kontynuować się dalej. Zapewnia to, że wszyscy stakeholderzy mają jasne zrozumienie celów projektu oraz kryteriów sukcesu.
- Zarządzanie ryzykiem: lista kontrolna pomaga w identyfikacji potencjalnych ryzyk i problemów, które mogą wpłynąć na sukces projektu. Pozwala stakeholderom podjąć odpowiednie kroki w celu ograniczenia ryzyka przed uruchomieniem projektu.
- Świadome decyzje: lista kontrolna pomaga stakeholderom podejmować świadome decyzje, czy kontynuować projekt. Ocena realizowalności projektu na podstawie jasnych kryteriów pozwala na podejmowanie bardziej świadomych decyzji dotyczących potencjalnego sukcesu projektu.
Przykłady
Oto kilka przykładów elementów, które mogą być zawarte w liście kontrolnej Go/No-Go w badaniu realizowalności projektu Agile:
- Realizowalność techniczna:
- Czy technologia wymagana do realizacji projektu jest dostępna?
- Czy projekt może zostać zrealizowany w ramach podanych ograniczeń technicznych?
- Czy zespół rozwojowy posiada wymagane umiejętności i doświadczenie, aby ukończyć projekt?
- Realizowalność finansowa:
- Czy projekt jest realizowalny pod względem finansowym?
- Czy szacowany budżet odpowiada celom i celom projektu?
- Czy istnieją potencjalne przekroczenia kosztów, które mogłyby wpłynąć na realizowalność projektu?
- Popyt rynkowy:
- Czy na rynku istnieje popyt na projekt?
- Czy na rynku już istnieją podobne projekty?
- Czy projekt jest zgodny z obecnymi trendami i wymaganiami rynkowymi?
- Dostępność zasobów:
- Czy dostępne są zasoby wymagane dla projektu?
- Czy projekt można zakończyć w wyznaczonym terminie przy dostępnych zasobach?
- Czy istnieją potencjalne ograniczenia zasobowe, które mogą wpłynąć na realizowalność projektu?
Jeśli projekt spełnia wszystkie kryteria wymienione w liście kontrolnej Go/No-Go, może przejść do kolejnego etapu rozwoju. Jeśli nie spełnia któregokolwiek z kryteriów, projekt może wymagać zawieszenia lub zatrzymania, aż do rozwiązania problemów.
Przykłady z życia
Na podstawie tej listy kontrolnej Go/No-Go projekt wydaje się realizowalny i może przejść do kolejnego etapu rozwoju. Jednak zespół rozwojowy będzie musiał ścisłe monitorować projekt, aby zapewnić, że pozostaje w ustalonych ograniczeniach, a wszelkie potencjalne problemy są szybko rozwiązane.
W kolumnach „Tak” i „Nie” możesz zaznaczyć, czy projekt spełnia kryteria czy nie. W kolumnie „Uwagi” możesz podać dodatkowe informacje lub notatki dotyczące każdego kryterium, takie jak potencjalne problemy lub obawy, które należy rozwiązać.
Oto szablon listy kontrolnej Go/No-Go w formie tabeli do badania realizowalności projektu Agile:
| Kryteria | Tak | Nie | Uwagi |
|---|---|---|---|
| Realizowalność techniczna | |||
| Czy technologia wymagana do realizacji projektu jest dostępna? | Tak | Firma ma doświadczenie w projektowaniu aplikacji internetowych i jest zapoznana z technologiami wymaganymi dla projektu. | |
| Czy projekt można zrealizować w ramach podanych ograniczeń technicznych? | Tak | Wymagania techniczne projektu mieszczą się w możliwościach zespołu rozwojowego. | |
| Czy zespół rozwojowy posiada wymagane umiejętności i doświadczenie, aby zakończyć projekt? | Tak | Zespół ma doświadczenie w tworzeniu podobnych projektów i posiada niezbędne umiejętności do ich zakończenia. | |
| Realizowalność finansowa | |||
| Czy projekt jest realizowalny pod kątem finansowym? | Tak | Przewidywane przychody z projektu powinny przekroczyć koszty jego realizacji. | |
| Czy szacowany budżet jest zgodny z celami i celami projektu? | Tak | Budżet projektu jest zgodny z zasobami finansowymi i celami firmy. | |
| Czy istnieją potencjalne przekroczenia kosztów, które mogą wpłynąć na realizowalność projektu? | Nie | Zespół rozwojowy zidentyfikował potencjalne przekroczenia kosztów i podjął kroki w celu ich ograniczenia. | |
| Popyt rynkowy | |||
| Czy na rynku istnieje popyt na projekt? | Tak | Badania rynkowe wykazały, że istnieje potrzeba narzędzia do zarządzania projektami dla małych firm. | |
| Czy na rynku istnieją już podobne projekty? | Tak | Na rynku dostępnych jest kilka narzędzi do zarządzania projektami, ale żadne nie spełnia specyficznych potrzeb małych firm. | |
| Czy projekt jest zgodny z obecnymi trendami i wymaganiami rynkowymi? | Tak | Projekt jest zgodny z obecnymi trendami i wymaganiami rynkowymi w zakresie rozwiązań oprogramowania opartego na chmurze. | |
| Dostępność zasobów | |||
| Czy dostępne są wymagane zasoby dla projektu? | Tak | Dostępne są niezbędne sprzęt, oprogramowanie i inne zasoby dla projektu. | |
| Czy projekt można zakończyć w wyznaczonym terminie przy dostępnych zasobach? | Tak | Terminarz projektu jest realistyczny i osiągalny przy dostępnych zasobach. | |
| Czy istnieją potencjalne ograniczenia zasobowe, które mogą wpłynąć na realizowalność projektu? | Nie | Zespół rozwojowy zidentyfikował potencjalne ograniczenia zasobowe i podjął kroki w celu ich ograniczenia. |
Korzystanie z tego szablonu tabeli może pomóc w dokumentowaniu procesu podejmowania decyzji i zapewnieniu jasnego zapisu powodów, dla których projekt został albo zatwierdzony do realizacji, albo zawieszony.
Prosta ocena dla listy kontrolnej do decyzji ‘idź’/’nie idź’
W tym przykładzie punktacja 1 przypisuje się do każdego kryterium spełniającego wymagania projektu, a punktacja 0,5 — do kryterium częściowo spełnionego. Ostateczna punktacja obliczana jest przez zsumowanie punktów dla każdego kryterium, a projekt uznaje się za realizowalny, jeśli punktacja przekracza określony próg (np. 8/11).
| Kryteria | Tak | Nie | Punktacja | Uwagi |
|---|---|---|---|---|
| Możliwość techniczna | ||||
| Czy technologia wymagana do opracowania projektu jest dostępna? | Tak | 1 | Firma ma doświadczenie w tworzeniu aplikacji internetowych i jest zapoznana z technologiami wymaganymi do projektu. | |
| Czy projekt można opracować w ramach podanych ograniczeń technicznych? | Tak | 1 | Wymagania techniczne projektu mieszczą się w możliwościach zespołu developerskiego. | |
| Czy zespół developerski posiada wymagane umiejętności i doświadczenie, aby ukończyć projekt? | Tak | 1 | Zespół ma doświadczenie w tworzeniu podobnych projektów i posiada niezbędne umiejętności do ich ukończenia. | |
| Wydajność finansowa | ||||
| Czy projekt jest wydajny finansowo? | Tak | 1 | Przewidywane przychody z projektu przewidywane są na poziomie wyższym niż koszty jego realizacji. | |
| Czy szacowany budżet jest zgodny z celami i celami projektu? | Tak | 1 | Budżet projektu jest zgodny z zasobami finansowymi i celami firmy. | |
| Czy istnieją potencjalne przekroczenia kosztów, które mogłyby wpłynąć na wykonalność projektu? | Nie | 1 | Zespół developerski zidentyfikował potencjalne przekroczenia kosztów i podjął kroki w celu ich ograniczenia. | |
| Popyt rynkowy | ||||
| Czy na rynku istnieje popyt na projekt? | Tak | 1 | Badania rynku wykazały, że istnieje potrzeba narzędzia do zarządzania projektami dla małych firm. | |
| Czy na rynku są już dostępne podobne projekty? | Tak | 0.5 | Na rynku dostępnych jest kilka narzędzi do zarządzania projektami, ale żadne nie spełnia specyficznych potrzeb małych firm. | |
| Czy projekt jest zgodny z obecnymi trendami i zapotrzebowaniem rynkowym? | Tak | 1 | Projekt jest zgodny z obecnymi trendami rynkowymi i zapotrzebowaniem na rozwiązania oprogramowania oparte na chmurze. | |
| Dostępność zasobów | ||||
| Czy dostępne są wymagane zasoby dla projektu? | Tak | 1 | Dostępne są niezbędne sprzęt, oprogramowanie i inne zasoby dla projektu. | |
| Czy projekt można zrealizować w podanym terminie przy dostępnych zasobach? | Tak | 1 | Termin realizacji projektu jest realistyczny i możliwy do osiągnięcia przy dostępnych zasobach. | |
| Czy istnieją potencjalne ograniczenia zasobowe, które mogą wpłynąć na realizowalność projektu? | Nie | 1 | Zespół rozwojowy zidentyfikował potencjalne ograniczenia zasobowe i podjął kroki w celu ich ograniczenia. | |
| Razem | 9.5/11 |
Jednak ważne jest, aby zaznaczyć, że przypisywanie punktów do każdego kryterium może być subiektywne i nie zawsze precyzyjnie odzwierciedla realizowalność projektu. Ważne jest, aby brać pod uwagę kontekst i unikalne cechy każdego projektu podczas używania systemu punktowego do oceny jego realizowalności.
System oceniania z wagami z listą kontrolną Go/No-Go
System oceniania i wartości z wagami są ważnymi elementami listy kontrolnej Go/No-Go i pozwalają na ilościową ocenę realizowalności projektu na podstawie zestawu zdefiniowanych kryteriów.
System oceniania przypisuje wartość Yes lub No do każdego kryterium na liście kontrolnej, w zależności od tego, czy kryterium jest spełnione, czy nie. Na przykład kryterium dotyczące realizowalności technicznej może pytać, czy technologia wymagana do realizacji projektu jest dostępna. Jeśli technologia jest dostępna, odpowiedzią na kryterium będzie Tak, a jeśli nie jest dostępna – Nie.
Po ocenie i przypisaniu punktów do każdego kryterium wchodzą w grę wartości z wagami. Każdemu kryterium przypisuje się wagę, która odzwierciedla jego względną ważność w ogólnej ocenie realizowalności projektu. Waga jest zazwyczaj wyrażana w procentach, a suma wszystkich wag wynosi 100%.
Przykład
Oto przykład listy kontrolnej Go/No-Go z przypisanymi wagami:
| Kryteria | Waga | Tak | Nie | Wynik | Uwagi |
|---|---|---|---|---|---|
| Możliwość techniczna | 40% | ||||
| Czy technologia wymagana do realizacji projektu jest dostępna? | 20% | Tak | 0.2 | Firma ma doświadczenie w tworzeniu aplikacji internetowych i jest zapoznana z technologiami wymaganymi do projektu. | |
| Czy projekt można zrealizować w ramach podanych ograniczeń technicznych? | 10% | Tak | 0.1 | Wymagania techniczne projektu mieszczą się w możliwościach zespołu programistycznego. | |
| Czy zespół programistyczny posiada wymagane umiejętności i doświadczenie, aby zakończyć projekt? | 10% | Tak | 0.1 | Zespół ma doświadczenie w tworzeniu podobnych projektów i posiada niezbędne umiejętności do ich zakończenia. | |
| Odpowiedniość finansowa | 30% | ||||
| Czy projekt jest odpowiednio finansowo? | 20% | Tak | 0.2 | Szacowane przychody z projektu przewidziane są na przekroczenie kosztów jego rozwoju. | |
| Czy szacowany budżet jest zgodny z celami i celami projektu? | 5% | Tak | 0.05 | Budżet projektu jest zgodny z zasobami finansowymi i celami firmy. | |
| Czy istnieją potencjalne przekroczenia kosztów, które mogłyby wpłynąć na realizowalność projektu? | 5% | Nie | 0.05 | Zespół rozwojowy zidentyfikował potencjalne przekroczenia kosztów i podjął kroki w celu ich ograniczenia. | |
| Popyt rynkowy | 20% | ||||
| Czy istnieje popyt na projekt na rynku? | 10% | Tak | 0.1 | Badania rynkowe wykazały, że istnieje potrzeba narzędzia do zarządzania projektami dla małych firm. | |
| Czy na rynku są już dostępne podobne projekty? | 5% | Tak | 0.025 | Na rynku dostępnych jest kilka narzędzi do zarządzania projektami, ale żadne nie spełnia specyficznych potrzeb małych firm. | |
| Czy projekt jest zgodny z obecnymi trendami i wymaganiami rynkowymi? | 5% | Tak | 0.025 | Projekt jest zgodny z obecnymi trendami i wymaganiami rynku w zakresie rozwiązań oprogramowania opartego na chmurze. | |
| Dostępność zasobów | 10% | ||||
| Czy dostępne są zasoby wymagane dla projektu? | 5% | Tak | 0.05 | Dostępne są niezbędne zasoby sprzętowe, programowe i inne zasoby dla projektu. | |
| Czy projekt można zakończyć w wyznaczonym terminie przy dostępnych zasobach? | 3% | Tak | 0.03 | Termin projektu jest realistyczny i osiągalny przy dostępnych zasobach. | |
| Czy istnieją potencjalne ograniczenia zasobowe, które mogą wpłynąć na realność projektu? | 2% | Nie | 0.02 | Zespół rozwojowy zidentyfikował potencjalne ograniczenia zasobowe i podjął kroki w celu ich ograniczenia. | |
| Razem | 100% | 0.605 |
W tym przykładzie wagę każdej kryterium ustala się na podstawie specyficznych wymagań i priorytetów projektu. Ostateczny wynik oblicza się mnożąc wynik każdego kryterium przez jego wagę, a następnie dodając wszystkie wagi. Ostateczny wynik jest miarą ilościową realności projektu opartą na kryteriach ocenionych w sprawdzianie.
Warto zaznaczyć, że waga przypisana do każdego kryterium jest subiektywna i może się różnić w zależności od konkretnego kontekstu projektu. Dlatego bardzo ważne jest skonsultowanie się z odpowiednimi stakeholderami i ekspertami w zakresie tematycznym w celu ustalenia odpowiedniej wagi dla każdego kryterium.
Po obliczeniu ostatecznego wyniku może on służyć jako podstawa do podjęcia decyzji typu Go/No-Go. Na przykład, jeśli ostateczny wynik przekracza ustalony próg, projekt może zostać zatwierdzony do realizacji, natomiast jeśli wynik jest poniżej progu, projekt może zostać uznany za nierealny i porzucony.
W podsumowaniu, system ocen z wagami może zapewnić bardziej subtelne i dostosowane do kontekstu ocenę realności projektu poprzez przypisanie różnych wag różnym kryteriom. Sprawdzian Go/No-Go w połączeniu z systemem ocen z wagami może być wartościowym narzędziem wspomagającym podejmowanie świadomych decyzji o kontynuacji projektu Agile.
Podsumowanie
Sprawdzian Go/No-Go to przydatne narzędzie do oceny realności projektów Agile. Przypisanie wag do każdego kryterium w sprawdzianie pozwala na bardziej subtelne i dostosowane do kontekstu ocenę. System ocen przypisuje wartość Tak lub Nie do każdego kryterium w zależności od tego, czy kryterium jest spełnione, a wartość z wagą reprezentuje względną ważność danego kryterium w ogólnej ocenie. Po obliczeniu oceny z wagą dla każdego kryterium otrzymuje się ostateczny wynik, sumując wszystkie oceny z wagami. Ostateczny wynik jest miarą ilościową realności projektu i może służyć jako podstawa do podejmowania świadomych decyzji o kontynuacji projektu Agile. Dzięki sprawdzianowi Go/No-Go i podejściu opartemu na ocenach z wagami organizacje mogą podejmować świadome decyzje i zwiększać szanse na sukces projektu.