YouTube: Jak (dokładniej) wyceniać zadania w projekcie IT?

Rozbieżność między planowanym, a faktycznym czasem realizacji jest przyczyną opóźnień projektów IT. Aktualne statystyki mówią, że ~80% projektów przekracza pierwotnie planowany czas realizacji lub budżet. Nagrałem wideo o tym, jak zmniejszyć ryzyko niedoszacowanych (lub przeszacowanych) zadań w twoim projekcie. Poruszałem już ten temat na moim blogu, wersję tekstową możesz znaleść w artykule na temat dokładniejszej wyceny zadań.

Czytaj dalej

Dlaczego zadania IT powinny być krótkie?

 Często z pozoru trudny problem, po rozbiciu na mniejsze kawałki staje się prostszy do rozwiązania. W teorii nie powinno to mieć znaczenia. Równie dobrze nierozbite zadania powinno zająć tyle samo czasu i być tak samo skomplikowane jak te podzielone na małe fragmenty. Czas realizacji ani poziom trudności nie uległ zmianie. O co więc tak naprawdę chodzi?

Czytaj dalej

YouTube: Ile powinno trwać zadanie w projekcie IT?

Przyjęło się, że gdy podzielimy problem na mniejsze fragmenty będzie on prostszy w realizacji. Z logicznego punktu widzenia nie powinno mieć to znaczenia – dekompozycja projektu na małe kawałki nie zmniejsza poziomu skomplikowania, ani nie redukuje zakresu – to tylko logiczny podział. Więc jak to jest z rozmiarem zadania? „Czy rozmiar ma znaczenie? ;)”

Czytaj dalej

Jakie polecam książki o zarządzaniu projektami?

Pisze do mnie wiele osób, które planują zacząć swoją przygodę z zarządzaniem projektami lub byciu team leaderem. Rozmowy z tymi osobami maja zazwyczaj wspólny mianownik, chcą się dowiedzieć „od czego zacząć zarządzanie projektami? jakie książki polecam?”. W tym wpisie postanowiłem odpowiedzieć zbiorczo na te pytanie – poznasz moją opinię co czytać, o ile czytać 🙂

Czytaj dalej

Ja w DevTalk.pl

Ukazał się 47 odcinek DevTalk.pl, do którego zostałem zaproszony przez Macieja Aniserowicza by porozmawiać o wycenie zadań, projektów IT, łańcuchu krytycznym i Estee.me. Zapraszam do odsłuchu!

Czytaj dalej

Jak wycenić projekt IT w 10 minut?

Każdy kto próbował wycenić projekt IT wie, że nie jest to proste zadanie. Zazwyczaj w podanym zakresie od klienta kryje się wiele niewiadomych i niejasności. Mimo tego, klient oczekuje widełek czasowych, w których uda się ukończyć projekt. Osoba wyceniająca spędza czas na domyślaniu się „co autor miał na myśli”. Często trzeba wysłać do klienta pytania precyzujące zakres. Czas odpowiedzi od klienta, a przede wszystkim jakość odpowiedzi bywa niezadowalająca. Może to wynikać z tego, że klient nie jest w stanie na tym etapie sprecyzować zakresu lub pytania, które przeszły przez kilka działów zniekształciły jego treść i odpowiedź (osoby techniczne i biznesowe). Wycena projektu w takim przypadku to zgadywanka, która kosztuje wiele czasu całego zespołu: architektów, programistów, handlowców.
Po całym czasochłonnym procesie nadal zakres ani cena nie są precyzyjne – mamy nadzieję, że myślimy o tym samym co klientem. Warto podkreślić, że nadal nie masz pewności (mimo poświęconych wielu godzin zespołu na wycenę), że klient wybierze właśnie twoją ofertę. Być może komuś udało się metodą zgadywanki „strzelić” niższą cenę bo np inaczej zinterpretował zakres, lub dostał brief pisany przez inna osobę.
Na tym etapie wszystko jest kwestią interpretacji, a dla klienta najczęściej (niestety) najważniejsza jest cena pomimo, że nikt nie wie do końca co trzeba zrobić (nawet klient).

Odrób pracę domową i zastanów się ile czasu poświęciłeś na wycenę ostatniego projektu, ile osób po twojej stronie było zaangażowanych w wycenę (graficy/handlowcy/programiści) i ile czasu sumarycznie spędziliście nad estymatą zapytania od klienta. Następnie odpowiedz sobie jaki procent wyceniających przez ciebie projektów kończy się podpisaniem umowy i finalizacją dzieła.
Jeśli te liczby nie są korzystne dla twojej organizacji (lub co gorsze, nie jesteś w stanie ich określić) zapraszam do dalszej lektury.

Czytaj dalej

Jak (dokładniej) wyceniać zadania IT?

Wycena czasu na realizacje zadań jest kluczowa bo wyznacza termin ukończenia projektu. Jednak wycena w jednym wymiarze (czasu) może okazać się zbyt mało miarodajna. Do wyceny warto wprowadzić dodatkowe parametry takie jak pracochłonność i skomplikowanie. Z tego wpisu dowiesz się czym różni się pracochłonność od skomplikowania w kontekście zadań IT. Zrozumiesz dlaczego poszczególne zadania się opóźniają, a przed wszystkim jak zminimalizować to ryzyko poprzez wprowadzenie dodatkowych parametrów do wyceny.

Czytaj dalej