9 największych błędów w wycenie projektu IT – Jak ich uniknąć?

Przed nami arcyważny etap tworzenia aplikacji. Wycena projektu IT niesie jednak ze sobą duże ryzyko popełnienia błędów, które obciążą całe nasze przedsięwzięcie. Co to za błędy i jak można ich uniknąć?

Wiemy już jak ważne jest odrobienie pracy domowej przed naszym pierwszym spotkaniem z agencją sotware house i określenie wyraźnych priorytetów. Dzisiaj obnażymy dziewięć najczęstszych błędów popełnianych podczas wyceny projektów IT.

Błąd nr 1: Niech software house określi budżet za nas

Uciekamy od jasnego określenia naszego budżetu na samym początku projektu. Wpadamy w pułapkę mglistego pytania z kategorii „Ile kosztuje samochód?”. Mimo że tak naprawdę zdajemy sobie sprawę, że podobnie jak ceny aut, tak i ceny projektów IT mogą różnić się o kilkadziesiąt tysięcy złotych, unikamy oszacowania, ile możemy przeznaczyć pieniędzy na nasz projekt.
Przeciwnie, liczymy, że nasza firma informatyczna przedstawi budżet za nas. Software house oczywiście może to zrobić, ale widełki cenowe będą w tej sytuacji bardzo szerokie. Możemy poczuć się zbici z tropu, jeśli zobaczymy rozstrzał cenowy między 25 tysięcy a 75 tysięcy złotych. Sporo czasu stracimy na dotarcie się z naszą firmą i uzmysłowienie sobie czynników wpływających na wycenę. Wydłużymy cały proces o rozmowy wyjaśniające, jaki model współpracy i jakie cele możliwe są przy cenie 25, a jakie przy 75 tysięcy złotych.

Rozwiązanie: Bądźmy konkretni. Oto nasz budżet na projekt IT

Najlepsze co możemy zrobić to konkretne określenie budżetu już na starcie i chwycenie byka za rogi. Stawka pomoże nam i naszej agencji IT sprecyzować czy inwestujemy w kreację MVP, czy też stawiamy na długofalowy cel w postaci finalnego produktu o wysokiej jakości. Niesamowitą wartością są w tej sytuacji warsztaty Product Design Workshop, które otwierają nam drzwi do prawidłowego nazwania produktu, który będzie dla nas najlepszy i najbardziej będzie wpisywał się w nasz budżet. Nasz software house bez problemu opowie nam o swoich stawkach i oszacuje czas i nakład pracy związany z naszym projektem. Może okazać się, że 25 tysięcy wyniesie stworzenie samego produktu, a kolejne 25 tysięcy, które zostanie nam z naszego budżetu, możemy przeznaczyć na niezbędny marketing i konwersję leadów w przyszłych klientów.

Błąd nr 2: Pomijamy czas na prace organizacyjne

Praca włożona w projekt to nie tylko kodowanie i późniejsze testowanie produktu. Przy wycenie zapominamy o uwzględnieniu czas niezbędnego na kwestie organizacyjne.

Rozwiązanie: Poznajmy specyfikę pracy przy projekcie

Rysowanie road mapy, planowanie sprintów, oraz ewaluacja poszczególnych etapów również pochłaniają godziny pracy członków zespołu. Im szybciej zdamy sobie sprawę ze specyfiki życia projektu, tym lepiej dla jego prawidłowej wyceny i sprawnego przebiegu.

Błąd nr 3: Przeskakujemy etap analizy i zaprojektowania

Umyka nam szeroki plan i dalsza perspektywa zaprojektowania naszego rozwiązania. Przy wycenie pomijamy czas niezbędny na opracowanie architektury naszej aplikacji.

Rozwiązanie: Przyjmijmy założenia technologiczne

Projekty IT mogą być bardzo efektywne i dynamiczne dzięki wybraniu model scrum. Mimo zwinności wpisanej w styl tej pracy musimy pamiętać, żeby już przy planowaniu budżetu przyjąć konkretne założenia technologiczne projektu. Wracamy tutaj do konieczności poprawnego sformułowania naszego celu oraz priorytetów produktu.

Błąd nr 4: Zbyt optymistycznie podchodzimy do wyceny

Innymi słowy szacujemy pracę programistyczną, nie biorąc pod uwagę czynników, które mogą ją spowolnić. Doskonałym przykładem sytuacji, która wydłuży czas pracy programistów, jest dodanie funkcji usuwania rekordów z bazy danych. W większości przypadków nie można ich usuwać, a należy je „zamazać”, ale w taki sposób, żeby nie można było zidentyfikować, czego dotyczyły. W praktyce zadanie, które powinno zająć naszej firmie IT trzydzieści minut pracy, rozrasta się do dwóch godzin.

Rozwiązanie: Analizujmy i pamiętajmy o jakości

Szacując prace przy projekcie, musimy pamiętać o zachowaniu jakości rozwiązań. Kroki, które trzeba podjąć to:
Analiza pełnego zakresu zadań
Zaprojektowanie rozwiązania
Przygotowanie testów automatycznych dla aplikacji
Wdrożenie i utrzymanie

W sukurs przyjdą nam tutaj dobre założenia technologiczne. Już na starcie nasz software house może nam zaprojektować odpowiednie algorytmy, które potem będzie można wykorzystać w różnych modułach aplikacji.

Błąd nr 5: Nie myślimy o kosztach wdrożenia i utrzymania

Zaprojektowanie i napisanie aplikacji to jedno, ale jeśli przy wycenie projektu pominiemy koszty jej wdrożenia i późniejszego utrzymania, to po upływie 3 lat będziemy musieli zmierzyć się z problemem długu technologicznego.

Rozwiązanie: Odpowiedni zakres prac

W budżet projektu musimy wliczyć:
zapewnienie jakości całego produktu (Quality Assurance) czyli np. stworzenie testów automatycznych dla kluczowych elementów systemu
utrzymanie infrastruktury serwerowej
aktualizacje bibliotek i pluginów w celu np. zminimalizowania podatności na ataki

Błąd nr 6: Nie sprawdzamy jak pracuje software house

Błędy pojawiają się też po drugiej stronie barykady. Przy wycenie projektu kluczowe jest szacowanie zakresu zadań. Jeśli w agencji programistycznej za task estimation odpowiada tylko jedna osoba, to możemy być niemal pewni, że każda niedokładność popełniona na tym wczesnym etapie wyjdzie na światło dzienne w trakcie projektu.

Rozwiązanie: Zapoznanie z organizacją pracy naszego partnera

Estymacja zadań projektu powinna się odbyć na przykład w formie planning pokera. Dzięki takiemu modelowi pracy cały zespół programistów czuwa nad tym czy wszystko jest prawidłowo rozpisane. Wszelkie wątpliwości i potencjalne ryzyko można w ten sposób wyeliminować już podczas sesji z Product Ownerem.
Upewnijmy się – zapytajmy ile osób z agencji brało udział w task estimation. Jeśli okaże się, że tylko jedna, to powinniśmy poważnie zastanowić się czy dobrze wybraliśmy nasz software house.

Błąd nr 7: Taka była wycena i się jej trzymajmy

Zbyt sztywno trzymamy się ustalonej ceny projektu i nie bierzemy pod uwagę zwinnego podejścia do jego realizacji. Jest więcej niż pewne, że w trakcie trwania projektu IT pojawią się zmiany. Jeśli nie jesteśmy na nie przygotowani organizacyjnie i finansowo, to będą nam one wstrzymywać postępy pracy, marnować czas i generować dodatkowe koszty.

Rozwiązanie: Przygotujmy się na zmiany

Zamiast powodować przestoje rozpisywaniem specyfikacji dla każdej pojawiającej się zmiany w tworzeniu aplikacji, przygotujmy się na nie zawczasu. Zmiany w projekcie są nieuniknione, jednak prawdziwą sztuką jest rozsądnie na nie reagować, pamiętając o tym co najważniejsze w projekcie. O priorytetach.

Błąd nr 8: Nierealne deadline’y

Ten błąd to obosieczny miecz, którym oberwiemy zarówno my jako zleceniodawca, jak i realizujący projekt software house. Jeśli postawimy nierealny deadline, to ryzykujemy, że firma informatyczna zwiększy nam stawkę, licząc na to, że uda jej się dzięki temu zwiększyć zespół, aby wykonać projekt w terminie. Po drodze jednak muszą zatrudnić i wdrożyć nowych programistów, co zwiększa ryzyko, że i tak przekroczą deadline. My zostaniemy z produktem, za który zapłaciliśmy więcej, niż powinniśmy, i w dodatku nie otrzymaliśmy go na czas.

Rozwiązanie: Twardo stąpajmy po ziemi

Nie szarżujmy. Realnie określmy deadline wspólnie z naszym partnerem IT.

Błąd nr 9: Chcemy mieć wszystko

Jako klient mamy zbyt szerokie oczekiwania co do naszego produktu. Nie potrafimy zdecydować się na konkretne funkcje i chcemy złapać kilka srok za ogon. Nasza mglista wizja aplikacji, którą chcemy stworzyć nie tylko niepotrzebnie przedłuży rozmowy z agencją programistyczną, ale też znacznie zwiększyć koszty.

Rozwiązanie: Wybierzmy co najważniejsze

Podejmijmy kluczową decyzję i wybierzmy najważniejsze funkcje, które mają wyróżnić naszą aplikację na rynku. Dzięki temu software house efektywnie określi czas realizacji i finalnie dopniemy budżet naszego projektu.

Napisz komentarz

Your email address will not be published. Required fields are marked *