Faza 1: Inicjacja
Wymagania biznesowe
Wymagania biznesowe opisują, co projekt ma osiągnąć z perspektywy biznesu. Określają, jakie korzyści biznesowe ma przynieść organizacji.
Wymagania biznesowe powinny być mierzalne, konkretne i realistyczne. Powinny być też zgodne z celami organizacji.
Na etapie wyboru koncepcji zespół powinien dokładnie zrozumieć potrzeby biznesowe, na które projekt ma odpowiadać.
W tym celu zespół może:
- Spotkać się z interesariuszami biznesowymi, żeby poznać ich potrzeby i oczekiwania.
- Przeanalizować dane biznesowe, żeby znaleźć obszary do poprawy.
- Przeprowadzić analizę konkurencji, żeby zobaczyć, jak inne organizacje rozwiązują podobne problemy.
Gdy wymagania biznesowe są już jasne, zespół może przejść do wyboru technologii, podejść i harmonogramu projektu.
Wymagania użytkowników
Wymagania użytkowników to konkretne potrzeby i oczekiwania osób, które będą korzystać z efektów projektu. Bez nich trudno mówić o sukcesie projektu i odpowiedzeniu na potrzeby użytkowników.
Wymagania użytkowników można podzielić na dwie główne kategorie: wymagania funkcjonalne i niefunkcjonalne.
Wymagania funkcjonalne określają, co produkt lub system ma robić. Opisują widoczne dla użytkownika funkcje i możliwości produktu. W sklepie internetowym wymagania funkcjonalne mogłyby wyglądać tak:
- "Użytkownik powinien móc wyszukiwać produkty po słowie kluczowym."
- "Użytkownik powinien móc dodawać produkty do koszyka."
- "Użytkownik powinien móc przejść do kasy i dokonać zakupu."
Wymagania niefunkcjonalne określają, jak produkt lub system ma działać. Opisują cechy i atrybuty produktu niewidoczne bezpośrednio dla użytkownika, takie jak wydajność, niezawodność, użyteczność i bezpieczeństwo. W sklepie internetowym wymagania niefunkcjonalne mogłyby wyglądać tak:
- "Strona powinna obsługiwać 10 000 jednoczesnych użytkowników."
- "Strona powinna być dostępna przez 99,9% czasu."
- "Strona powinna być łatwa w użyciu."
- "Strona powinna być zabezpieczona przed hakerami."
Zbieranie wymagań użytkowników
Wymagania użytkowników można zbierać na wiele sposobów. Do najpopularniejszych należą:
- Wywiady z użytkownikami: Rozmowy z potencjalnymi użytkownikami, które pozwalają poznać ich potrzeby i oczekiwania.
- Ankiety: Rozsyłanie ankiet do potencjalnych użytkowników, żeby zebrać opinie o konkretnych funkcjach.
- Obserwacja użytkowników: Przyglądanie się, jak potencjalni użytkownicy korzystają z istniejących produktów lub systemów, żeby znaleźć obszary do poprawy.
- Prototypowanie: Tworzenie prototypów produktu lub systemu, żeby zebrać od potencjalnych użytkowników opinie o projekcie i użyteczności.
Dokumentowanie wymagań użytkowników
Zebrane wymagania użytkowników trzeba udokumentować w sposób jasny, zwięzły i zrozumiały zarówno dla technicznych, jak i nietechnicznych interesariuszy. Do popularnych metod dokumentowania należą:
- Historyjki użytkownika: Krótkie, zwięzłe opisy potrzeb i scenariuszy użytkowników.
- Przypadki użycia: Opis kroków, które użytkownik wykonuje, żeby zrealizować konkretne zadanie.
- Specyfikacje funkcjonalne: Szczegółowy opis tego, jak oprogramowanie ma działać: funkcje, dane wejściowe i wyjściowe oraz reguły biznesowe.
Priorytetyzacja wymagań użytkowników
Nie wszystkie wymagania użytkowników są równie ważne. Trzeba je ustawić według priorytetów, żeby projekt skupiał się na najistotniejszych potrzebach użytkowników. Można to zrobić na kilka sposobów, na przykład przez:
- Głosowanie: Interesariusze głosują nad ważnością poszczególnych wymagań.
- Punktację ważoną: Każdemu wymaganiu przypisuje się wagę zależną od jego znaczenia.
- Ocenę ekspercką: O priorytetach decydują eksperci.
Iteracyjne doskonalenie wymagań użytkowników
Wymagania użytkowników nie są statyczne i mogą się zmieniać w miarę postępów projektu. Warto wracać do nich przez cały czas jego trwania, żeby upewnić się, że wciąż są aktualne. Pomagają w tym dodatkowe badania z użytkownikami i sesje zbierania opinii.
Wymagania użytkowników to kluczowy element projektów IT. Dzięki ich dokładnemu zrozumieniu i udokumentowaniu zespół ma pewność, że tworzy produkt odpowiadający na potrzeby użytkowników.
Wybór koncepcji
Zespół projektowy analizuje różne warianty realizacji produktu, w tym technologie, podejścia, narzędzia i harmonogramy. Jedną z opcji jest proof of concept (PoC), który pozwala sprawdzić wykonalność projektu. Taki PoC może polegać na stworzeniu prototypu lub demonstracji pokazującej, jak produkt miałby działać.
Technologie
Zespół rozważa następujące technologie na frontendzie:
- React
- Angular
- Vue.js
Zespół zdecydował się na React, bo to popularny i dobrze wspierany framework, znany z wydajności i skalowalności.
Zespół rozważa następujące technologie na backendzie:
- Python
- Java
- Go
Zespół zdecydował się na Pythona, bo to język ogólnego przeznaczenia, znany z prostoty i elastyczności.
Podejścia
Zespół rozważa następujące podejścia do projektu:
- Waterfall
- Agile
Zespół zdecydował się na Agile, bo to elastyczne podejście, które pozwala dostosowywać się do zmian w trakcie projektu.
Harmonogramy
Zespół rozważa następujące harmonogramy projektu:
- 6 miesięcy
- 9 miesięcy
- 12 miesięcy
Zespół zdecydował się na 9 miesięcy, bo to termin ambitny, ale osiągalny.
Podsumowanie wyboru koncepcji:
Zespół wybiera następujące rozwiązania:
- Frontend: React
- Backend: Python
- Podejście: Agile
- Harmonogram: 9 miesięcy
Na tej podstawie zespół przygotuje szczegółowy plan projektu.
Definiowanie celów
Definiowanie celów to proces jasnego i zwięzłego określania tego, co projekt IT ma osiągnąć. To kluczowy etap zarządzania projektem, bo dzięki niemu zespół dokładnie wie, do czego dąży.
Dobrze zdefiniowane cele są niezbędne z kilku powodów:
- Pomagają zgrać zespół: Gdy wszyscy dążą do tych samych celów, łatwiej im skutecznie ze sobą współpracować.
- Pomagają mierzyć postępy: Na ich podstawie można śledzić postępy projektu i znajdować obszary do poprawy.
- Pomagają utrzymać motywację: Członkowie zespołu, którzy wiedzą, że pracują nad czymś ważnym, chętniej dają z siebie wszystko.
- Pomagają wykrywać potencjalne ryzyka: Przy jasno określonych celach łatwiej dostrzec zagrożenia, które mogłyby wykoleić projekt.
Wskazówki dotyczące definiowania celów
Definiując cele, warto pamiętać o kilku zasadach:
- Zadbaj o to, żeby cele były jasne i zwięzłe. Każdy w zespole powinien je rozumieć bez cienia wątpliwości.
- Zadbaj o to, żeby cele były ambitne, ale osiągalne. Powinny stanowić wyzwanie, ale pozostać realistyczne.
- Zadbaj o to, żeby cele były istotne dla projektu. Powinny bezpośrednio wiązać się z jego założeniami.
- Zadbaj o to, żeby cele były określone w czasie. Każdy powinien mieć konkretny termin.
Przykłady celów
Oto kilka przykładów celów projektu IT:
- Zwiększenie sprzedaży o 10% w ciągu roku.
- Skrócenie czasu odpowiedzi działu obsługi klienta o 50%.
- Obniżenie kosztów operacyjnych o 20%.
- Wdrożenie nowego systemu CRM, który poprawi satysfakcję klientów o 15%.
- Stworzenie nowej aplikacji mobilnej, która zwiększy zaangażowanie użytkowników o 20%.
Faza 2: Planowanie
Planowanie to druga faza cyklu życia projektu. To wtedy project manager i zespół przygotowują szczegółowy plan realizacji. Ta faza ma kluczowe znaczenie dla sukcesu, bo zapewnia, że projekt jest dobrze zdefiniowany, wykonalny i idzie zgodnie z planem.
Określenie zakresu projektu
Zakres projektu wyznacza granice tego, co znajdzie się w projekcie IT, a co nie. To kluczowy dokument, który pomaga utrzymać projekt na właściwym kursie i skupić zespół na najważniejszych zadaniach.
Dobrze zdefiniowany zakres projektu obejmuje:
- Produkty projektu: Listę wszystkich namacalnych rezultatów projektu.
- Działania projektowe: Listę wszystkich zadań potrzebnych do dostarczenia tych rezultatów.
- Zasoby projektu: Listę wszystkich zasobów potrzebnych do realizacji projektu.
- Ograniczenia projektu: Listę wszelkich ograniczeń, które będą miały wpływ na projekt.
Korzyści z dobrze zdefiniowanego zakresu projektu
Dobrze zdefiniowany zakres projektu daje kilka korzyści:
- Mniejsze ryzyko: Jasne zrozumienie zakresu pomaga wykrywać potencjalne ryzyka i je ograniczać.
- Lepsza komunikacja: Dobrze określony zakres ułatwia komunikację między członkami zespołu a interesariuszami.
- Większa efektywność: Dobrze określony zakres pomaga zespołowi skupić się na najważniejszych zadaniach.
- Mniej poprawek: Dobrze określony zakres ogranicza ilość pracy wykonywanej od nowa.
Definiowanie zakresu projektu
Zakres projektu należy określić na wczesnym etapie cyklu życia. Dzięki temu wszyscy interesariusze mają wspólne rozumienie projektu, a później nie pojawiają się niespodzianki.
Zakres projektu można zdefiniować na kilka sposobów. Do popularnych metod należą:
- Przegląd dokumentacji: Analiza istniejących dokumentów, takich jak wymagania biznesowe czy specyfikacje produktu, pomaga określić zakres projektu.
- Wywiady z interesariuszami: Rozmowy z interesariuszami pomagają zrozumieć ich oczekiwania i priorytety.
- Sesje zbierania wymagań: Warsztaty z interesariuszami pomagają wskazać konkretne produkty i działania projektowe.
- Planowanie projektu: Stworzenie planu projektu pomaga ugruntować jego zakres i wychwycić potencjalne ryzyka lub ograniczenia.
Iteracyjne doskonalenie zakresu projektu
Zakres projektu nie jest statyczny i może się zmieniać w miarę postępów prac. Warto wracać do niego przez cały czas trwania projektu, żeby upewnić się, że wciąż jest aktualny. Pomagają w tym dodatkowe przeglądy z interesariuszami i sesje zbierania opinii.
Zakres to kluczowy element realizacji projektu IT. Jasno go definiując i komunikując, zespół ma pewność, że dostarczy klientom właściwe produkty lub usługi na czas i w ramach budżetu.
Tworzenie zadań
Tworzenie zadań to kluczowy krok w fazie planowania projektu IT. Polega na rozbiciu celów projektu na mniejsze, łatwe do ogarnięcia zadania, które można przydzielić członkom zespołu. Zadania powinny być jasne, zwięzłe i dobrze zdefiniowane, żeby wszyscy rozumieli je tak samo i żeby projekt mógł zakończyć się sukcesem.
Kto powinien tworzyć zadania?
Zadania może tworzyć każdy członek zespołu projektowego, w tym:
- Project manager
- Liderzy zespołów
- Eksperci dziedzinowi
- Interesariusze
Osoba tworząca zadanie powinna dobrze rozumieć cele i wymagania projektu oraz umieć rozbić go na mniejsze, łatwe do ogarnięcia części.
Kiedy tworzyć zadania?
Zadania należy tworzyć przez całą fazę planowania. Dzięki temu projekt jest dobrze zdefiniowany, a zespół realizuje swoje cele zgodnie z planem. Zadania można też dodawać w fazie realizacji, gdy trzeba zareagować na zmiany lub nieprzewidziane problemy.
Na jakich spotkaniach tworzyć zadania?
Zadania można tworzyć na każdym spotkaniu, na którym zespół omawia projekt, na przykład:
- Na spotkaniach otwierających projekt (kickoff)
- Na cotygodniowych spotkaniach zespołu
- Na planowaniu sprintu
Co powinien zawierać ticket?
Każde zadanie powinno mieć ticket z następującymi informacjami:
- Nazwa zadania: Jasna i zwięzła nazwa.
- Opis: Szczegółowy opis zadania, w tym kroki do wykonania i rezultaty lub krótka lista AC (kryteriów akceptacji).
- Osoba przypisana: Osoba odpowiedzialna za zadanie.
- Szacowany czas: Szacowany czas potrzebny na wykonanie zadania.
- Status: Aktualny stan zadania (np. To Do, In Progress, Done).
- Zależności: Wszelkie zależności od innych zadań.
Czym są historyjki, zadania i podzadania?
Historyjki, zadania i podzadania to różne typy ticketów, które pomagają zarządzać pracą w projektach IT.
- Historyjki to ogólne opisy pracy do wykonania. Zazwyczaj tworzą je interesariusze i dają one wysokopoziomowy obraz pracy.
- Zadania to mniejsze, bardziej szczegółowe jednostki pracy przydzielane członkom zespołu. Zazwyczaj tworzą je liderzy zespołów lub eksperci dziedzinowi.
- Podzadania to mniejsze jednostki pracy zagnieżdżone w zadaniach. Zazwyczaj tworzą je członkowie zespołu, żeby rozbić złożone zadania na mniejsze, łatwiejsze do ogarnięcia części.
Jak korzystać z historyjek, zadań i podzadań
Historyjki, zadania i podzadania można łączyć w zarządzaniu pracą w projektach IT. Historyjki dają ogólny obraz pracy, a zadania i podzadania wnoszą szczegóły. Dzięki temu pracą można zarządzać skuteczniej i efektywniej.
Historyjka może brzmieć na przykład "Stwórz nowy interfejs użytkownika dla strony". Można ją następnie rozbić na takie zadania jak:
- Zaprojektowanie interfejsu użytkownika
- Zaimplementowanie interfejsu użytkownika
- Przetestowanie interfejsu użytkownika
Te zadania można z kolei rozbić na podzadania, takie jak:
- Przygotowanie wireframe'ów
- Przygotowanie makiet
- Zakodowanie interfejsu użytkownika
- Uruchomienie testów jednostkowych
- Przeprowadzenie testów akceptacyjnych
Zarządzanie pracą za pomocą ticketów
Tickety pomagają zarządzać pracą w projektach IT przez:
- Śledzenie postępów
- Wykrywanie wąskich gardeł
- Przydzielanie pracy członkom zespołu
- Komunikację z interesariuszami
- Zarządzanie zależnościami
Dzięki ticketom zespoły IT mają kontrolę nad swoją pracą i mogą dowozić projekty na czas i w ramach budżetu.
Faza 3: Realizacja
Intensywna praca
Realizacja to najważniejsza faza projektu IT. To wtedy zespół zamienia plan w rzeczywistość. To także faza najtrudniejsza, bo wymaga sprawnej współpracy, pokonywania przeszkód i dostarczenia projektu na czas oraz w ramach budżetu.
W fazie realizacji zespół projektowy:
- Tworzy i testuje oprogramowanie
- Dokumentuje oprogramowanie
- Szkoli użytkowników
- Wdraża oprogramowanie
- Zapewnia wsparcie oprogramowania
Programiści
W fazie realizacji programiści odpowiadają za kodowanie, testowanie i debugowanie oprogramowania. Współpracują też z pozostałymi członkami zespołu, żeby oprogramowanie spełniało wszystkie wymagania.
- Kodowanie: Programiści tworzą oprogramowanie, korzystając z różnych języków programowania i narzędzi. Muszą trzymać się planu projektu i dokumentów projektowych, żeby powstało zgodnie ze specyfikacją.
- Testowanie: Programiści piszą testy jednostkowe, integracyjne i systemowe, żeby upewnić się, że oprogramowanie działa poprawnie. Muszą też debugować wykryte defekty.
- Debugowanie: To proces wykrywania i usuwania defektów w oprogramowaniu. Programiści korzystają z różnych narzędzi do debugowania, które pomagają im znajdować i naprawiać problemy.
Testerzy
W fazie realizacji testerzy odpowiadają za sprawdzanie, czy oprogramowanie spełnia wszystkie wymagania. Współpracują też z programistami przy wykrywaniu i usuwaniu defektów.
- Testy manualne: Testerzy ręcznie sprawdzają oprogramowanie, stosując różne metody testowania. Muszą trzymać się planów i scenariuszy testowych, żeby przetestować wszystkie jego aspekty.
- Testy automatyczne: Testerzy korzystają z narzędzi do automatyzacji testów, co może poprawić wydajność i skuteczność testowania.
Pozostali członkowie zespołu
W fazie realizacji ważne role pełnią też inne osoby, między innymi:
- Project manager: Odpowiada za nadzór nad realizacją projektu. Musi pilnować, żeby zespół trzymał się planu i budżetu oraz spełniał wszystkie wymagania.
- Autorzy dokumentacji: Odpowiadają za tworzenie dokumentacji oprogramowania, z której korzystają użytkownicy, programiści i pozostali interesariusze. Dokumentację mogą pisać także programiści i QA.
- Specjaliści ds. wsparcia: Pomagają użytkownikom, którzy mają problemy z oprogramowaniem. Muszą diagnozować problemy i dostarczać rozwiązania.
Spotkania
Spotkania to nieodłączna część każdego projektu IT. Dają członkom zespołu przestrzeń do komunikacji, współpracy i podejmowania decyzji. Dobrze prowadzone pomagają utrzymać projekt na właściwym kursie i zadbać o to, żeby wszyscy mieli tę samą wiedzę.
Rodzaje spotkań
W projekcie IT można stosować wiele rodzajów spotkań. Do najpopularniejszych należą:
- Daily stand-upy: Te krótkie, codzienne spotkania to świetny sposób na rozpoczęcie dnia i wyrównanie wiedzy w zespole. Każdy krótko mówi, co zrobił poprzedniego dnia, co planuje na dziś i co go blokuje.
- Refinement backlogu: Te spotkania służą do priorytetyzacji i doprecyzowania backlogu projektu. Zespół omawia historyjki użytkownika i wymagania oraz decyduje, nad czym pracować w następnej kolejności.
- Planowanie sprintu: Odbywa się na początku każdego sprintu, żeby zaplanować pracę na jego czas. Zespół wspólnie przygotowuje backlog sprintu, który obejmuje historyjki użytkownika, zadania do wykonania i ich estymaty.
- Przegląd sprintu: Odbywa się na koniec każdego sprintu, żeby omówić wykonaną pracę. Zespół prezentuje ją interesariuszom i zbiera od nich opinie.
- Retrospektywa sprintu: Odbywa się na koniec każdego sprintu, żeby zastanowić się nad jego przebiegiem i znaleźć obszary do poprawy. Zespół omawia, co poszło dobrze, co można było zrobić lepiej i co zmieni w kolejnym sprincie.
Obowiązki na spotkaniach
Obowiązki zależą od rodzaju spotkania. Można jednak wskazać kilka ogólnych zasad:
- Project manager odpowiada za planowanie i prowadzenie spotkań.
- Członkowie zespołu odpowiadają za udział w spotkaniach i aktywne uczestnictwo w dyskusjach.
- Interesariusze odpowiadają za udział w przeglądach i retrospektywach sprintu.
Dobre praktyki prowadzenia spotkań
Oto kilka dobrych praktyk, dzięki którym spotkania będą skuteczne:
- Przygotuj jasną agendę i trzymaj się jej.
- Zaczynaj i kończ spotkanie punktualnie.
- Zachęcaj wszystkich do zabierania głosu.
- Rób notatki i pilnuj ustalonych działań.
Jeśli będziesz się tego trzymać, Twoje spotkania będą produktywne i efektywne.
- Zużycie zasobów: Korzystanie z zasobów (ludzkich, finansowych, materialnych) jest nieuniknione. Trzeba śledzić i kontrolować ich wykorzystanie względem planowanego budżetu.
- Generowanie kosztów: Wszelkie działania na tym etapie wiążą się z kosztami. Monitorowanie wydatków pomaga utrzymać projekt w ramach budżetu.
Faza 4: Zamknięcie
Dostarczenie produktu projektu
Sfinalizowanie projektu i przekazanie gotowego produktu klientowi lub użytkownikowi końcowemu.
Dokumentacja i ewaluacja
Należy przygotować szczegółową dokumentację projektu i ocenić jego przebieg. Obejmuje to analizę tego, co poszło dobrze, a co można było zrobić lepiej.
Post-mortem
Przeprowadzenie z zespołem sesji podsumowującej, żeby wyciągnąć wnioski na przyszłość.
Podsumowanie cyklu życia
Każda z tych faz wymaga starannego planowania, realizacji i oceny. Sukces projektu IT zależy nie tylko od umiejętności technicznych zespołu, ale też od skutecznego zarządzania, komunikacji i dostosowywania się do zmieniających się okoliczności.