Znajdź inspirację i skuteczne narzędzia, które pomogą Ci w zarządzaniu projektami oraz zespołami. Nasze materiały dostarczą Ci wiedzy nie tylko na temat efektywnego planowania i realizacji zadań, ale także dotyczącej budowania silnych relacji w zespole.
Manager IT sam sobie nie wystarczy – i dobrze o tym wiesz
Manager IT dostaje priorytety z góry i odpowiada za wyniki na dole – a przestrzeń między tymi dwoma warstwami jest często dość wąska i dość samotna. Standish Group od lat pokazuje, że większość projektów IT nie kończy się tak, jak planowano. Warto się zastanowić, ile z tych niepowodzeń zaczyna się nie od złej metodologii, ale od managera, który przez pół roku nie miał z kim porozmawiać o trudnych decyzjach.
Backlog po polsku – zaległości, rejestr czy po prostu lista?
“Backlog” to jedno z tych słów, które polskie środowisko IT przyjęło bez tłumaczenia i udało, że problem nie istnieje. A problem istnieje – i objawia się zwykle przy raportowaniu do zarządu, kiedy 200 zaplanowanych funkcjonalności brzmi nagle jak 200 zaległości, za które ktoś powinien odpowiedzieć. Jak to słowo działa naprawdę i dlaczego niejednoznaczność terminologii kosztuje więcej niż się wydaje.
Iteracja – dlaczego projekty, które nigdy nie kończą, często kończą najlepiej
Projekt, który co dwa tygodnie pokazuje działający kawałek produktu, wygląda wolniejszy od tego, który obiecuje wszystko po osiemnastu miesiącach. Rzadko jest. Czym naprawdę jest iteracja i dlaczego jej brak to nie oszczędność czasu, lecz odroczony rachunek za błędy, których nikt nie zobaczył wystarczająco wcześnie?
Grooming w Agile – skąd się wzięło słowo, które Scrum porzucił w 2013 roku
“Grooming” brzmiało niewinnie – dopóki twórcy Scruma nie zmienili go oficjalnie na “refinement” w 2013 roku. Większość polskich zespołów IT wciąż używa starego słowa, nie zawsze wiedząc, co tak naprawdę kryje się za tą aktywnością. I czy w ogóle robią to dobrze.
Backlog spółki: ta sama nazwa, dwa zupełnie różne światy
Analitycy giełdowi mówią o backlogu Asseco wycenianym na 13,5 mld zł. Product Ownerzy mówią o backlogu w Jirze z 200 pozycjami, których połowa nie ma już sensu. To samo słowo, dwa zupełnie różne problemy i zadziwiająco rzadkie rozmowy między tymi dwoma światami.
CSF, czyli co tak naprawdę musi się udać
W 1979 roku John F. Rockart opublikował w Harvard Business Review artykuł, który miał rozwiązać jeden z klasycznych problemów zarządzania: skąd wiadomo, na czym naprawdę zależy sukces projektu. Czterdzieści kilka lat później większość organizacji wciąż odpowiada na to pytanie listą dwudziestu siedmiu punktów. CSF to coś innego niż KPI, coś innego niż lista ryzyk i coś innego niż cele strategiczne – choć wszystkie trzy lubią się z nim mylić.
CSF, czyli kilka rzeczy, których zawalenie położy cały projekt
W 1979 roku John Rockart opublikował w Harvard Business Review artykuł, który przez ponad cztery dekady będzie cytowany przez badaczy, project managerów i konsultantów na całym świecie. Nie dlatego, że był trudny, lecz dlatego, że opisał coś, co większość organizacji robiła źle, nie wiedząc nawet, że w ogóle to robi. CSF, czyli Critical Success Factors, to raczej nie kolejny framework do wdrożenia, lecz pytanie, na które wiele projektów IT nigdy nie znajdzie odpowiedzi na czas.
IT governance: kto naprawdę decyduje o technologii w twojej firmie
W 1996 roku ISACA opublikowała pierwszą wersję COBIT nie dla CIO ani architektów systemów, lecz dla audytorów finansowych, którzy nie mogli rozgryźć, kto właściwie odpowiada za decyzje technologiczne w dużych korporacjach. To chyba najuczciwsze wprowadzenie do tematu IT governance: zanim zapytasz, czym jest, zapytaj, dlaczego w ogóle powstało. I dlaczego większość firm odkrywa jego brak dopiero przy okazji jakiegoś spektakularnego fakapu.
Kamień milowy, czyli punkt na mapie, którego nikt nie widzi, dopóki projekt nie zaczyna się sypać
W harmonogramie wyglądają identycznie: data, nazwa, kolor w Jirze. Ale kamień milowy to albo punkt decyzji, który naprawdę coś zmienia, albo dekoracja, która pozwala raportować zielone statusy przy czerwonym projekcie. Fred Brooks opisał ten mechanizm w 1975 roku i od tamtej pory projekty IT wciąż popełniają ten sam błąd.
Proces iteracyjny: dlaczego najlepsze projekty IT wyglądają jak spirala, nie strzałka
Projekt IT zaplanowany od A do Z na samym początku brzmi jak marzenie każdego zarządu. Rzeczywistość wygląda jednak tak, że wymagania zmieniają się w trakcie pracy, a błędy odkryte po osiemnastu miesiącach kosztują wielokrotnie więcej niż te wykryte po dwóch tygodniach. Właśnie tu zaczyna się rozmowa o procesie iteracyjnym.