W trakcie kariery każdego developera przychodzi moment, w którym stajemy przed wyzwaniem określenia nakładu pracy jakiego przewidujemy by skończyć przedstawione przed nami zadanie.
Zadanie to może przybierać różne formy, od małej zmiany, implementacji nowego feature czy kończąc na stworzeniu pełnoprawnej aplikacji.
Estymacje, bo o tym będziemy dzisiaj trochę szerzej rozmawiać to bardzo skomplikowany temat, na tyle skomplikowany, że coraz częściej się mówi o tym, że człowiek nigdy nie będzie ich w stanie dobrze wykonać. Jeśli spojrzymy na wielkie inwestycje, czy to budowlane, czy game development to można wręcz wysunąć wnioski, że są one standardem.
Czym są estymacje?
Na estymacje wolę patrzeć bardziej jako pewnego rodzaju szacowanie ryzyka. Zastanawiania się nad tym co może pójść nie tak. Gdyby wziąć pod uwagę idealny scenariusz – dostajemy specyfikację rozpisaną w każdym najmniejszym szczególe – to bardzo łatwo przyszłoby nam ustalić dokładną listę kroków do wykonania, dzięki czemu znając swoje umiejętności moglibyśmy z łatwością podać ramy czasowe potrzebne do realizacji. Jest to niestety idealny scenariusz i w rzeczywistości (o ile w ogóle) bardzo rzadko przyjdzie nam mieć z nim do czynienia.
Jak sobie radzić kiedy wiemy, że nie wiemy?
Podchodząc do takich przypadków zawsze staram rozpisać sobie całkowite minimum, które jest potrzebne do wykonania zadania. Mając już taką listę, weryfikuję czy posiadam komplet informacji dotyczących tych podstawowych prac. Jeżeli już w tym momencie zauważymy, że mamy co do pewnych aspektów wątpliwości powinna nam się zapalić czerwona lampka. Niezwłocznie powinniśmy zakomunikować brak kluczowych instrukcji.
Kiedy mamy już solidny fundament, przychodzi czas na to by drążyć temat dalej, im bardziej dociekliwi będziemy tym dla nas lepiej. Z własnych doświadczeń zauważyłem, że gdy pojawiają się dodatkowe pytania najlepiej jest im nadawać priorytety, pewnego rodzaju wagi. W końcu czy duże znaczenia będzie dla nas miało, że przycisk do pobierania danych z zewnetrznego API będzie szary zamiast czarnego? Jest to element, który bardzo łatwo idzie skorygować w razie potrzeby. Czy po naciśnięciu tego przycisku zapytanie ma się wykonać w pełni asynchronicznie czy może z przeładowaniem strony? Cóż, z pewnością jest to dużo ważniejsze pytanie ponieważ może mieć drastyczny wpływ na to jak będziemy musieli zaplanować architekturę naszej aplikacji.
Jeżeli tak kluczowe pytania nadal się pojawiają to powinniśmy utrzymywać ciągły kontakt i starać się wyjaśnić jak najwiecej aspektów. Niestety zdarza się czasem tak, że nie jesteśmy w stanie dowiedzieć się niczego więcej – w takich sytuacjach w zależności od ustalonej przez nas wcześniej wagi powinniśmy doliczać dodatkowy bufor na nieprzewidziane przez nas rzeczy. Ważnym elementem jest by zawsze komunikować to, że jakieś zadanie nadal pozostawia u nas wątpliwości. Jeśli klient wie o tym, że gdzieś może skrócić czas potrzebny na realizacje, to wtedy z pewnością chętniej udzieli nam odpowiedzi.
Słowem zakończenia
Wszystko to co dzisiaj przeczytaliście można sprowadzić do jednego. Minimalizacja ryzyka. Tak jak wsiadając do auta minimalizujemy ryzyko uszczerbku na zdrowiu tak estymacja może również zostać potraktowana, jako dobre pasy bezpieczeństwa, które będą nam towarzyszyć w przejażdżce. Przejażdżce, która jest nieprzewidywalna, ale dzięki nim będziemy się czuć dużo lepiej.
Dodaj komentarz