1. Wstęp

“Ile to zajmie?” - to pytanie, które każdy developer bez względu na staż usłyszał setki razy. Za każdym razem, na usta ciśnie się to samo stwierdzenie - to zależy…

Z wykształcenia, jestem inżynierem Mechatroniki na Wydziale Mechanicznym Politechniki Białostockiej. Niejednokrotnie, miałem okazję projektować bądź wytwarzać jakąś rzecz za pomocą obrabiarek, zarówno tych manualnych jak i tych sterowanych numerycznie. Celem zwizualizowania sobie procesu wytwarzania elementu w inżynierii mechanicznej, wyobraźmy sobie wytwarzanie Łącznika ciesielskiego płaskiego z 10 otworami.

Na początku konstruktor projektuje element. Dobiera rodzaj materiału, wymiary elementu, rozstaw i wielkość otworów. Następnie, operator obrabiarek sterowanych numerycznie (CNC) bądź operator klasycznej frezarki, w oparciu o dokumentację, dobiera odpowiednie narzędzia, posuwy i inne istotne w tym procesie elementy po to by mieć możliwość wytworzenia tego elementu. Obrabiarka wykrawa element z kawałka ustalonej blachy, wierci otwory oraz wykańcza krawędzie. Na koniec tego procesu, operator wyciąga gotowy przedmiot i zabiera się za wykonywanie drugiego. Dodatkowo, obrabiarki sterowane numerycznie, są w stanie wytwarzać kilka bądź kilkanaście takich elementów na raz a cały proces może być zautomatyzowany. W jednym i drugim przypadku zawsze możemy mieć pewność bądź przypuszczać z dużym prawdopodobieństwem, że proces ten zajmie (przy zastosowaniu tych samych warunków: materiał, ustawienia obrabiarki) tyle samo czasu. Dodatkowo, nowoczesne obrabiarki CNC pokazują, jak długo będą wytwarzać element, którego program właśnie został wybrany.

Właśnie dlatego, estymacja projektów IT to jedna z najtrudniejszych umiejętności w branży, ponieważ diametralnie różni się od wymienionego wyżej przykładu. Nie ma dwóch identycznych aplikacji. Każdy projekt jest unikalny, z indywidualnym designem, oparty na innych założeniach i celach biznesowych. Często nie ma gotowych szablonów a każda, nawet najprostsza funkcjonalność, może być ciężka do implementacji w danym środowisku.

Różnice między systemami Android i iOS często komplikują pracę deweloperów. Warto też pamiętać, że React Native umożliwia tworzenie nie tylko aplikacji mobilnych, ale również webowych, a także tych przeznaczonych na Apple Watch czy TV.

W takim razie, ktoś mógłby stwierdzić, że estymacje są bez sensu albo, że estymacja to loteria; ale nie jest to do końca prawda.

Ten artykuł to pierwszy z serii, w której pokażę, jak ja – React Native Developer z kilkuletnim doświadczeniem – podchodzę do estymacji. Niezależnie od tego, czy jesteś deweloperem, który musi oszacować lub wycenić zadanie, czy CEO próbującym zrozumieć, dlaczego "prosty" projekt trwa trzy miesiące – mam nadzieję, że przedstawione tu informacje rzucą nowe światło na cały proces estymacji.

Zaczniemy od poznania podstawowych pojęć i podstaw estymacji. Dowiemy się, co w tym takiego trudnego oraz jak spróbować połączyć świat techniczny, ze światem biznesowym - co moim zdaniem jest kluczowym aspektem każdego projektu w IT.

2. Podstawowe definicje

Tutaj będzie troszkę suchych regułek ale mam nadzieję, że w zrozumiałej formie 🙂

2.1 Estymata

To proces szacowania czasu, wysiłku i zasobów potrzebnych do wykonania danego zadania lub projektu. Jest kluczowym elementem planowania i zarządzania projektem, pozwalającym na określenie realistycznych celów i efektywne alokowanie zasobów.

Zazwyczaj, estymata nie jest jednorazowym działaniem, a procesem, który ewoluuje w miarę postępu projektu. Dzięki niej możemy stworzyć realistyczne harmonogramy, stworzyć odpowiednie priorytety oraz monitorować postęp. Pomaga również w określaniu ryzyka i zarządzaniu oczekiwaniami.

Tworzona jest zazwyczaj przez developerów bądź zespół techniczny. Określana najczęściej w Story Pointach, rzadziej w godzinach.

Czy wiesz, że?

Prawo Hofstadtera - Wykonanie zadania zawsze trwa dłużej, niż zakładasz, nawet jeśli weźmiesz pod uwagę prawo Hofstadtera.

2.2 Wycena

To przeliczenie estymat na konkretną kwotę pieniężną. Składa się na nią: estymata + stawka + marża + ryzyko i ma charakter zewnętrzny, kontraktowy. Jest przedstawiana klientowi oraz podlega negocjacjom. Jeśli estymacja została przeprowadzona w godzinach, przeliczenie jej na czas trwania projektu jest stosunkowo proste. W przypadku estymacji w Storypointach, konieczne jest jednak uwzględnienie velocity zespołu — czyli średniej liczby punktów realizowanej w jednym sprincie. Jeśli pracujesz nad nowym projektem lub z nowym zespołem i nie dysponujesz takimi danymi, musisz założyć przybliżone velocity na podstawie dostępnych informacji lub doświadczenia.

2.3 Task

To pojedyncza jednostka pracy, którą trzeba wykonać w ramach większego projektu. Jest konkretny i mierzalny, np. "Zrób białe tło na ekranie logowania" - jesteśmy w stanie wywnioskować o co w nim chodzi, oraz jesteśmy w stanie zweryfikować jego wykonanie.

Często wyposaża się go w dodatkowe informacje jak osobę odpowiedzialną za jego wykonanie, priorytet czy status. Wykorzystywany powszechnie w życiu codziennym (podział dużego zadania na mniejsze) oraz w narzędziach jak Jira, Asana, Trello czy Basecamp.

Jest podstawowym elementem w zarządzaniu pracą.

Epic: Logowanie użytkownika
User Story: “Jako użytkownik chce się zalogować, żeby mieć dostęp do mojego konta”
Tasks:
1. Stwórz formularz logowania (frontend)
2. Obsłuż zapytanie (backend)
3. Dodaj walidację
4. Stwórz testy jednostkowe
5. Sprawdź poprawność UX

2.4 Epic

To duży, wysokopoziomowy element pracy, ciężki do realizacji w ramach jednego sprintu (ale nie niemożliwy). Reprezentuje cel biznesowy, np. logowanie użytkownika do aplikacji. Dzieli się na mniejsze taski i user stories.

2.5 Project

To ogólne przedsięwzięcie mające na celu stworzenie konkretnego rozwiązania, np. aplikacji mobilnej. Charakteryzuje się tym, że ma swój początek i koniec, realizuje konkretny cel biznesowy, wymaga współpracy różnych ról, składa się z wielu epików.

Może trwać tygodnie, miesiąca a nawet lata. W nowoczesnych zespołach, często zarządzany metodą jedną z metod Agile (Scrum lub Kanban).

2.6 Złożoność

To stopień trudności technicznej związany z wykonaniem zadania, funkcji bądź projektu. Nie oznacza czasu, ale wpływa na ryzyko, podnosi koszt oraz zwiększa prawdopodobieństwo błędów lub zmian.

Częstymi przykładami czynników wpływających na złożoność są: nietypowa architektura, skomplikowane designy, edge-casey, brak jasnych wymagań biznesowych lub technologicznych, nowe technologie, czy też skala.

Czy złożoność wpływa na pracę? Zdecydowanie tak. Taski tej samej długości czasowej mogą mieć różną złożoność. Zbyt dużo złożonych tasków w jednym sprincie znacząco wpływa na ryzyko opóźnień a co za tym idzie, zwiększa stawki i bufory bezpieczeństwa. Ocena złożoności danego zadania odbywa się najczęściej za pomocą story points bądź innych metod punktowych (t-shirt sizing, fibonacci). Dopiero po określeniu złożoności zadania, możemy przewidywać, ile czasu zajmie to zadanie konkretnej osobie. Na czas wpływają umiejętności developera oraz znajomość projektu czy technologii. Na przykład ten sam task junior zrobi w 5 dni a senior w 2 dni. Na tej podstawie, licząc koszt czyli czas * stawka + bufor + marża możemy określić swoje oczekiwania, i oddelegować jego wykonanie odpowiedniej osobie.

Task: "Dodaj logowanie przez Google"
Złożoność: 5/6 (wymaga OAuth, obsługi tokenów, integracji)
Czas: 3 dni dla senior developera, 6 dni dla junior developera
Koszt: 2400€ (senior) vs. 1800€ (junior) - ale senior wykona go 2x szybciej

2.7 Storypoint

Do oszacowania złożoności, wysiłku i niepewności zadań lub user stories służą storypointy. NIE SĄ to godziny, dni ani żadna inna jednostka czasu.

Do ich określenia, najczęściej używa się ciągu Fibonacciego: 0.5, 1, 2, 3, 5, 8, 13, 20, ... , ponieważ w większości przypadków, różnice są trudne do oceny a zespołowi prościej jest ocenić zadanie w skali 5 czy aż 8, niż 5 czy 6.

W uproszczeniu, zadanie wycenione na 5 Storypointów (SP) jest około dwa razy bardziej złożone niż takie, które ma 2SP. Po pewnym czasie stosowania tej metody można zacząć mierzyć velocity zespołu, czyli liczbę Storypointów realizowanych w trakcie jednego sprintu — na przykład 30SP na sprint.

Storypoint to narzędzie do planowania, a nie mikro zarządzania!

Poniżej znajdziesz podstawowe różnice pomiędzy storypointami a godzinami.

	Storypoint	Godzina
Czym jest?	Jednostka względna złożoności	Jednostka czasu
Kto estymuje?	Zespół deweloperski, developer (np. na planningu)	Zespół developerski bądź developer we współpracy z managerem
Do czego?	Planowanie sprintów, mierzenie velocity	Wycena, planowanie kalendarza, roadmapy.
Po co?	Porównanie zadań, przewidywanie wydajności, określenie trudności zadań a następnie ich prawidłowe zaplanowanie	Wycena kosztu wykonania taska, projektu, funkcjonalności. Rozdysponowanie czasu developerów.
Dokładność	Przybliżona, odporna na różnice umiejętności pomiędzy developerami	Pozornie dokładna – ale może być myląca bez danych
Kiedy NIE?	Nie używane do wyceny lub umów (np. fixed-price), bo SP ≠ godziny	Nie wyceniaj samodzielnie bez udziału osób technicznych

3. Dlaczego IT tak bardzo różni się od produkcji?

Podstawową różnicą pomiędzy IT a tradycyjną produkcją jest unikalność każdego projektu. W produkcji seryjnej, jesteśmy przyzwyczajeni do powtarzalnego procesu wytwarzania serii produktów, a sam ten proces jest ściśle ustandaryzowany.

W procesie wytwarzania aplikacji IT, są znaczące różnice klientów, ich oczekiwań oraz specyficzne wymagania danych technologii, przez co możemy cały proces jedynie ustandaryzować, natomiast nigdy to nie będzie powtarzalny proces wytwarzania serii aplikacji ponieważ każda z nich jest inna.

Nie bez przyczyny wspominam o istocie klienta, ponieważ to klient, odgrywa jedną z kluczowych ról w branży IT. Jest on nie tylko odbiorcą końcowym ale i aktywnym uczestnikiem procesu tworzenia. To jego potrzeby definiują kształt aplikacji, a jego decyzje (często w trakcie procesu developmentu) wpływają na przebieg prac. Programista musi być gotowy na dostosowanie się do wymagań klienta, które mogą zmieniać się w trakcie całego procesu.

Kolejnym istotnym czynnikiem jest dynamika technologii. W IT, a szczególnie w branży aplikacji mobilnych - nowe narzędzia, biblioteki czy całe architektury pojawiają się z tygodnia na tydzień. Idealnym przykładem jest React Native - technologia, która w ostatnich latach nabrała niesamowitego wiatru w żagle i praktycznie każdy update, wprowadza coś innowacyjnego. Całkiem niedawno, mierzyłem się z updatem stacka w jednej z aplikacji nad którą pracuję. Okazało się, że w tym czasie, React Native przeszedł na nową architekturę (https://reactnative.dev/architecture/landing-page). Update środowiska i przejście na nową architekturę spowodowało brak wstecznej kompatybilności z wieloma bibliotekami, które były użyte w projekcie, co zmusiło mnie do szukania nowych rozwiązań, szybkiego przyswajania wiedzy i implementacji tych rozwiązań w istniejące oraz rozwinięte środowisko. Coś co trwa zazwyczaj kilka godzin, trwało kilka dni 🙂

Tworzenie między platformowych aplikacji mobilnych ma jeszcze jedno istotne wyzwanie. Są to różnice pomiędzy platformami - iOS i Android rozwijają się niezależnie, mają odmienne wymagania, inne rozwiązania na te same kwestie oraz mogą powodować ciężkie do przewidzenia problemy. Z pozoru proste zadania, mogą ulec ogromnemu opóźnieniu przez specyfikę danej platformy, nieoczekiwane błędy lub konieczność znalezienia alternatywnych rozwiązań. Weźmy np. zablokowanie możliwości robienia screenshotów w aplikacji. Na Androidzie sprawa jest bardzo prosta - wystarczy dodać FLAG_SECURE w MainActivity. iOS natywnie nie daje takiej możliwości, więc albo używamy jakiegoś rozwiązania z Githuba, albo musimy sami napisać metodę, która podczas życia aplikacji, podmieni zrobiony screenshot bądź nagranie na czarne tło. Brzmi prosto? A czy nadal brzmi tak samo prosto, jak wyobrazisz sobie, że dostajesz to zadanie bez żadnego kontekstu gdy byłeś Junior React Native Developerem z 3 miesięcznym stażem? 🙂

W efekcie, praca w IT to nieustanna nauka, adaptacja i elastyczność. To branża, w której trudno bazować na stałych schematach i korzystać z wydeptanych ścieżek. Zdolność reagowania na zmiany i rozwiązywania problemów zanim staną się krytyczne, jest jedną z najważniejszych cech zarówno developerów ale i firm.

4. Popularne mity

4.1 “2 developerów = 2x szybciej”

Nie zawsze da się łatwo podzielić zadania – wiele z nich musi być realizowanych sekwencyjnie. Doskonałym przykładem jest tworzenie aplikacji mobilnej od zera. Trudno pracować nad ekranem filtrów gości, jeśli lista gości jeszcze nie istnieje lub jest w trakcie tworzenia przez innego developera. 🙂

Do tego dochodzą konflikty podczas mergowania kodu, code review, problemy z synchronizacją pracy... A to dopiero początek. Najważniejszym (i często niedocenianym) aspektem jest komunikacja, której złożoność rośnie wykładniczo: przy 2 osobach mamy 1 połączenie, ale przy 4 osobach już 6 – i z każdym kolejnym członkiem zespołu robi się tylko trudniej.

4.2 “Już to robiłeś, więc szybko zrobisz”

W punkcie 3. przedstawiłem różnicę między projektem IT a produkcją łączników ciesielskich. Podobnie można to ująć tutaj. Każdy projekt jest inny — ma swoją architekturę, inne wymagania, technologie ciągle się zmieniają, a do tego klient i kontakt biznesowy też bywają różni.

Dla porównania — gdy byłem juniorem, implementowałem autoryzację przez Okta OAuth. W kolejnym projekcie wymogiem było użycie Azure. Myślałem, że będzie to bardzo podobne, ale… szybko się przekonałem, że się myliłem. Azure miało swoje specyficzne wymagania dotyczące klienta, a na tamten moment w React Native były z tym problemy. Musiałem więc napisać własne rozwiązanie, co oznaczało konieczność dokładnego poznania całego procesu dołączania tokenów i ich przechwytywania, żeby Azure to w ogóle zaakceptowało.

Różnice czasowe to ok. 1 tydzień do 1 miesiąca.

4.3 “To tylko frontend”

Sam możesz sobie odpowiedzieć na pytanie jak często to słyszałeś 🙂. “Tylko frontend” to często: responsywność na różnych urządzeniach, różnice między platformowe lub między przeglądarkowe, customowe animacje i komponenty oraz różne API.

5. Podsumowanie

Pamiętaj o tych rzeczach a zmienisz swoje podejście do estymat ale i całej branży o 180 stopni

- Estymacja to sztuka

Pamiętaj, że nie ma wzoru matematycznego na perfekcyjną estymację. Głównym czynnikiem mającym ogromny wpływ na jej dokładność jest doświadczenie. Jako zespoły, developerzy, ale i osoby zarządzające ludźmi, musimy zaakceptować, że błędy wystąpią. Ważne jest, aby wyciągać z nich wnioski i nie popełniać ich w przyszłości.

- Niepewność jest normalna

To naturalne, że nie jesteś pewny swojej estymaty. Dlatego moim zdaniem najlepszym sposobem komunikacji są zakresy czasowe, a nie sztywne liczby — lepiej powiedzieć „1-2 tygodnie” niż „8 dni”. Unknown unknowns zawsze się pojawią, więc warto zostawić sobie bufor na nieprzewidziane sytuacje, który choć trochę ochroni zespół lub dewelopera przed negatywnymi konsekwencjami.

- Komunikacja dev-biznes jest kluczowa

Developerzy to eksperci techniczni, a biznes zna kontekst i priorytety. Transparentna komunikacja o ryzykach i założeniach oraz zrozumienie celów biznesowych pomaga w lepszych estymacjach.

- Dokumentuj swoje estymaty

Pomoże ci to w przyszłości, a po pewnym czasie zauważysz, jakie błędy udało się wyeliminować.

- Nie bój się być konserwatywny

Lepiej dostarczyć coś wcześniej niż później. Staraj się zawsze dokładać bufory do swoich estymacji. Pamiętaj, że klient będzie dużo bardziej zadowolony, gdy zrobisz coś w 2 dni przy estymacie 3 dni, niż gdy zrobisz to w 3 dni, mając obiecaną 2-dniową realizację.

Dlaczego estymacje w software developmencie są trudne?