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

Snapstorm#2 – jak wyceniać zadania IT w wielu płaszczyznach?

To drugi wpis zawierający snapstorm. Pierwszy był o buforach bezpieczeństwa w zadaniach IT. W tym snapstormie opowiadam o tym jak wyceniać zadania w projektach IT by być bardziej dokładnym, a ryzyko opóźnienia było zminimalizowane. Zapraszam do odsłuchu!

Czytaj dalej

Gdy klient mówi „chciałbym elastyczny system…” – czyli analiza przedwykonawcza

W ostatnim czasie sporą część dnia pracy zajmuje mi robienie analiz IT. Zazwyczaj uczestniczę w całym procesie powstawania produktu: spisanie wymagań klienta => opracowanie dokumentu analitycznego => development. Dzięki temu, że jestem obecny we wszystkich procesach, jestem świadkiem wielu „zabawnych” (z perspektywy czasu 😉 ) sytuacji o tym jak mimo ustaleń, oczekiwania i wyobrażenia klienta o finalnym produkcie mogą odbiegać od wcześniejszych założeń – to będzie tematem dzisiejszego wpisu. Zapraszam do lektury.

Czytaj dalej

Snapstorm#1 – bufory (nie) bezpieczeństwa w zadaniach IT

Powoli zaczynam swoją przygodę z YouTube. Będę wrzucał (nieregularnie) snapstormy ze swojego konta Snapchat. Czym jest snapstorm? Jest to zlepek krótkich filmików (maksymalnie 10 sekundowych), kręconych przednią kamerą telefonu – stąd też jakość nagrania 🙂 W tym snapstormie będę mówił o buforach (nie) bezpieczeństwa w zadaniach IT.

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