W tym odcinku poznasz pięć łatwych do wdrożenia reguł, które pozwolą Ci lepiej szacować czasochłonność projektów i zadań – niekoniecznie tylko tych związanych z IT!

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 18, 5 zachowań, które sprawią, że twoje estymacje czasowe będą dokładne.

W tym odcinku poznasz 5 łatwych do wdrożenia reguł, sugestii, które pozwolą ci lepiej szacować czasochłonność projektów i zadań i myślę co ważne, nie konieczne dotyczy to tylko projektów związanych z branżą IT. Błędne estymacje projektowe, czyli szacunki dotyczące czasu realizacji jakiegoś projektu, jakiegoś zakresu zadań, często leżą u podnóża problemów związanych z realizacją tychże projektów, tych zadań, w określonym czasie i budżecie. Pozornie drobne błędy, błędne założenia potrafią zadziałać niczym taka kula śnieżna i zniszczyć sukces projektu nawet, jeżeli w trakcie samej realizacji nie popełniono istotnych błędów. Przedstawione w tym odcinku sugestie, porady można oczywiście zastosować także w projektach nieinformatycznych, przy czym ta nasza kochana branża IT jest o tyle specyficzna, że technologie, realia zmieniają się tak niezwykle szybko, że trudno jest za nimi nieraz nadążyć i stąd też być może właśnie w naszej branży te problemy związane z estymacjami zadań są tak istotne i tak często się pojawiają.

Przejdźmy do meritum, zacznę od znanej z pewnością niektórym, ale bardzo istotnej z punktu widzenia szacowania zadań grze o nazwie planning poker. Pozwala ona na ustalenie planowanej czasochłonności zadań w ramach jakiegoś zespołu, który projekt realizuje. Polega ona na tym, w uproszczeniu oczywiście, iż każda user story, każda historyjka użytkownika jest poddawana głosowaniu przez członków zespołu. Każdy członek korzysta z jednej z kart reprezentujących czasochłonność od takich wartości jak 0,5 czy 1 aż chociażby 20, 30 takich jednostek. Tutaj często korzysta się, przy wyznaczaniu tych konkretnych wartości, z ciągów Fibonacciego, czyli mamy 1, 2, 3, 5, 8, 13, 21 itd. I tutaj w głosowaniu te osoby, które przedstawiły wartości skrajne mają możliwość wyjaśnienia swojego toku myślenia. Czemu ich zdaniem dana funkcja, dane zadanie zajmie tyle i tyle czasu. Po złożeniu wyjaśnień, można powiedzieć, ten proces się powtarza, aż zespół ustali pewien konsensus dla danej historyjki. Metoda ta jest niezwykle interesująca i jest stosowana przez wiele zespołów, natomiast warto się zastanowić z czego to wynika. Karty czy dokładna treść tego procesu, tej procedury to tak naprawdę detale. Najważniejsze jest to, iż w tym procesie skupiamy się na estymacji wykonywanej przez cały zespół. Każdy może wypowiedzieć się na temat każdej historyjki, nie tylko te osoby, które będą daną historyjkę, dane zadanie realizować, ale także inne potencjalnie zaangażowane osoby, inni interesariusze w zespole mogą coś powiedzieć. Jednocześnie określenie pewnych sztywnych ram pewnej procedury, która ma bardzo konkretny przebieg, pozwala zachować kontrolę nad spotkaniem, bo nie da się ukryć, że bardzo łatwo popłynąć z dyskusją na temat złożoności, stopnia trudności jakiejś funkcji i w ten sposób zakłócić sprawny przebieg spotkania.

Druga porada, którą chce omówić to myśl budżetem a nie wymaganiami. Think budget, think schedule ale nie koniecznie think scope. Przy estymowaniu projektów można rozważyć trzy zasadnicze kryteria: czas realizacji, budżet jaki możemy spożytkować na realizację projektu i jego zakres. W IT niestety często przyjmuje się, że zakres projektu to rzecz święta, bo klient może po prostu pójść gdzieś indziej, jeżeli zaczniemy negocjować kwestie zakresu, kwestie scope. I w związku z tym tak naprawdę estymacjom podlega właśnie czas realizacji i oczywiście budżet. I choć te dwa pojęcia są ze sobą powiązane, siłą rzeczy dłuższe, bardziej intensywne projekty z reguły więcej kosztują, to nie są to dwie informacje zupełnie ze sobą powiązane, bo w pewnym zakresie można oczywiście przyspieszyć np. czas realizacji, zwiększając liczbę osób zaangażowanych w projekt. Oczywiście nie podlega to takim prostym przeliczeniom jak taki stary żart na temat zarządzania projektami, że 9 kobiet w miesiąc dziecka nie urodzi. Także są tu oczywiście pewne ograniczenia, ale jednak czas i budżet są ze sobą powiązane. Jeżeli przyjrzymy się bliżej wielu projektom, które trafiają na tapet do wyceny, do analizy, to okazuje się, że zakres, z którym klient przychodzi wcale nie jest z betonu. Koniec końców zakres, czyli po prostu lista pewnych wymagań, funkcji do zrobienia, mają po prostu służyć pewnemu celowi biznesowemu. Mają rozwiązać pewien problem, z którym początkowo klient się znalazł. Z drugiej strony klient może dysponować bardzo konkretnym budżetem, który został np. wcześniej założony w budżecie całościowym organizacji lub też wie, że np. może przeznaczyć jakąś kwotę, żeby nie musieć przechodzić przez jakieś skomplikowane procedury organizacji. Klient może wreszcie być ograniczony czasowo z uwagi na jakieś zewnętrzne wydarzenia np. udział w targach, uruchomienie jakiejś kampanii marketingowej czy po prostu wewnętrzne deadline narzucone przez zarząd.  W takiej sytuacji kluczowe jest otwarcie klienta na elastyczną dyskusję o zakresie, co, nie da się ukryć, nie zawsze jest łatwe. Natomiast z drugiej strony wypracowanie już na tym etapie partnerskich zasad współpracy pozwala na nawiązanie lepszej, trwalszej współpracy w przyszłości.

Trzecie zachowanie, trzecia porada wiąże się z czymś może mniej konkretnym, ale też nie da się ukryć, bardzo ważnym. Chodzi o nastawienie. Trudno prowadzić biznes bądź kierować jakąś organizacją czy nawet jej działem, podejmować ambitne wyzwania, realizować jakieś zaawansowane projekty i jednocześnie nie mieć w sobie za grosz optymizmu. Wiara w powodzenie nawet takich trudnych projektów to podstawa, bo to jest, można powiedzieć, warunek konieczny, od tego się zaczyna. Trudno znaleźć w sobie energię do podjęcia realizacji projektu, jeżeli nie spojrzymy na niego z pewną wiarą. Z drugiej strony, gdy już przystępujemy do działania, to warto odnaleźć w sobie taką dawkę realizmu czy też powiedziałbym, zdrowego pesymizmu, bo to często przesądza o sukcesie przedsięwzięcia. Warto tu przypomnieć sobie o serialu „Curb Your Enthusiasm” i jego bohaterze Larrym Davidzie, który pokazuje jak niemal każda pozytywna sytuacja, których w tym serialu jest wiele, potrafi obrócić się na niekorzyść i wtedy trzeba powściągnąć ten tytułowy entuzjazm. Jeżeli zaczynamy jakiś projekt, zwłaszcza technologiczny, warto ten pesymizm, można powiedzieć, włączyć od samego początku. Po co w ogóle się spotykamy i coś chcemy zrobić? Nie można oczywiście popaść w jakieś skrajności, dlatego dobrze jest zadbać, aby w takim zespole, zwłaszcza na początku, pojawił się jakiś sprawdzony firmowy sceptyk, pesymista, ale jednocześnie nie maruder, ewentualnie warto wyznaczyć osobę, która będzie takim, można powiedzieć, adwokatem diabła, będzie starała się iść pod prąd z argumentacją. Potrzebny jest ktoś kto celnie wytknie potencjalne problemy i w razie czego pozwoli na zamknięcie projektu na przestrzeni tych kilkunastu, może kilkudziesięciu godzin poświęconych na spotkania i wstępne analizy, ale jednocześnie pozwoli zachować, oszczędzić setki czy tysiące godzin, które zostałyby utopione w faktyczną realizację projektu. To samo może odnieść do kontekstu już stricte technologicznego, bo przy skomplikowanych problemach, przy projektach związanych ze sztuczną inteligencją czy nauczaniem maszynowym, przy tematach, które mogą wymagać solidnej analizy pod kątem wydajności na danym sprzęcie, czy też przy projektach np. związanych z urządzeniami mobilnymi, warto zadbać o wykonanie elementarnego, najprostszego choćby studium wykonalności. W początkowych etapach projektu wszyscy są z reguły znacznie bardziej skłonni do ustępstw, bo to jest taki etap, w którym można negocjować, można ustalać, kiedy jeszcze nie ma obietnic, one dopiero będą padać. Natomiast dużo gorzej jest najpierw coś obiecać, a potem rakiem wycofywać się ze złożonych obietnic i wtedy często klienci potrafią być oczywiście źli. Cały ten punkt można sprowadzić do jednej prostej reguły. Zamiast pytać, po co drążyć temat, warto powiedzieć: drążmy temat i już. My wewnętrznie w firmie nawet wprowadziliśmy nieco bardziej bezpośrednią wersję tego powiedzenia, ale tak właśnie brzmi ona w wydaniu nieco bardziej publicznym.

Trzy poprzednie punkty można sprowadzić do wytycznych, takich powiedziałbym, komunikacyjnych, mocno zorientowanych na dobór i współpracę różnych członków zespołu. Ale nie byłbym sobą gdybym nie wtrącił tutaj argumentu nieco bardziej zorientowanego na liczby i dane. Koniec końców rzadko kiedy nowe projekty, czy to w IT, czy nie w IT, są tak w 100% nowe i innowacyjne. I nie mówię tego w złym kontekście, nie chodzi o jakieś powtarzanie się. Chodzi po prostu o to, że realizując nowe przedsięwzięcia, nawet jeżeli one mają jakiś istotny w sobie taki pierwiastek innowacji, to przynajmniej częściowo powinny opierać się na tym co już znamy. Jeżeli tworzymy jakiś np. rewolucyjny mechanizm e-commerce, to wciąż będą jacyś użytkownicy, którzy będą się rejestrować, będzie jakaś kwestia obsługi płatności. I to są funkcje, to są mechanizmy, które nie są same w sobie super oryginalne. Dlatego warto śledzić historię, analizować podobne projekty, zwłaszcza te, w których zostały wdrożone podobne funkcje, zostały zrealizowane podobne zadania. I warto chociażby jako taki punkt wyjścia potraktować właśnie estymaty, ale i faktycznie spędzony czas na takich zadaniach. Można też skonfrontować estymaty z faktycznym czasem realizacji i sprawdzić, że: zobaczmy, tutaj system użytkowników udało się zrobić w czasie o połowę krótszym, to jest dobra wiadomość, a z kolei inna funkcja, te płatności rzeczone mogły zająć więcej czasu, bo były to płatności subskrypcyjne i się okazało, że trochę bardziej skomplikowany proces z tego wyszedł. Być może w wyniku takiej analizy da się przenieść nie tylko estymaty, wartości liczbowe, ale i wręcz całe gotowe komponenty oprogramowania, co jakby w konsekwencji może sprawić, że te estymaty zmienią się mocno na plus. Natomiast koniec końców korzystanie z już sprawdzonych rozwiązań z reguły działa jednak pozytywnie, w kierunku sukcesu projektu i satysfakcji klienta.

Ostatni punkt to powrót do kwestii ludzkich, niezwykle wręcz ludzkich bym powiedział, bo dotyczy nastawienia, ale w trochę innym kontekście niż to miało miejsce w punkcie trzecim. Często gdy stajemy przed kwestią zaplanowania i realizacji jakiegoś projektu, może zaistnieć pokusa jak najszybszego rozpoczęcia prac i jak to się mówi, dowiezienia pierwszych rezultatów. Zwłaszcza jest to popularne podejście w przypadku metodyk zwinnych, agilowych, o których mówiłem w poprzednich wydaniach tego podcastu. To jest ok, ale niesie niestety za sobą pewne ryzyko. Warto więc potraktować proces estymacji w pewnym sensie jako checklistę zadań do zweryfikowania i odhaczenia przed startem projektu. Nie będę w tym miejscu omawiał wszystkich możliwych rodzajów zadań, bo mocno one zależą od rodzaju projektu, ale myślę, że niezależnie od tego czy mówimy o projektach IT, czy nie, warto rozważyć takie tematy jak chociażby kwestia finansowania, czy projekt ma zabezpieczone środki. Oczywiście mamy tu na myśli w budżecie firmy. Choć może w jakichś skrajnych przypadkach, ale też i w przypadku start-upów można skonfrontować czy koszt jakiegoś rozwiązania, czy w ogóle realizacji projektu nie okaże się większy niż np.  po prostu budżet firmy. Chyba że ktoś oczekuje na inwestycje. Świat start-upowy rządzi się swoimi prawami. Jest kwestia takich kosztów stałych, w przypadku IT infrastruktury do utrzymania, kosztów wsparcia, bo musimy pamiętać, że poza samym kosztem realizacji projektu, czy to IT, czy nie, z reguły jego utrzymanie przy życiu też kosztuje, co często w ujęciu miesięcznym może nie jest jakimś dużym kosztem, ale już w ujęciu np. rocznym czy wieloletnim zaczyna być niemałym kosztem. I wreszcie ukochane przez wszystkich kwestie prawne. Czy projekt jest zgodny w ogóle z przepisami prawa, regulacjami, które obowiązują w firmie, regulaminami, czy będą zapewnione wszystkie licencje, to bardziej w kontekście IT. I jakby to wszystko musi być sprawdzone, bo może się okazać, że nawet po realizacji projektu, po osiągnięciu jakichś efektów, z różnych kwestii prawnych, względów prawnych, nie będziemy w stanie wdrożyć takiego projektu.

Zwróćcie uwagę, że tak naprawdę w tych kilku punktach nie dotknąłem w zasadzie jakichś tematów stricte technologicznych, takich zadań do omówienia, tutaj można by mówić przede wszystkim o kwestiach kompatybilności, wykonywalności projektów, tak jak wspominałem wcześniej, natomiast jest ich bardzo sporo, nie da się ukryć, że samo przygotowanie takiej checklisty jest już takim zadaniem wstępnych, które trzeba wykonać. Natomiast zdecydowanie może to pomóc w skutecznym i rozpoczęciu, i przeprowadzaniu szczęśliwego finału projektu.

Na tym kończymy dzisiejszy odcinek. W zasadzie można powiedzieć, że z takiego zagadnienia stricte estymacji zrobiła się nieco gawęda ogólnie o takich kluczowych założeniach, ważnych zasadach, które warto wdrażać przy realizacji projektów, ale koniec końców w obu procesach chodzi o to samo, że jeżeli podejmujemy się jakichś wyzwań, projektów, to chcemy je skutecznie przeprowadzić.

Jeżeli macie jakieś własne pomysły i przemyślenia jak zawsze gorąco zachęcam do dzielenia się nimi. Chętnie bym też porozmawiał z kimś właśnie na temat estymat, bo to ile osób tyle poglądów. Natomiast myślę, że warto o tym rozmawiać, bo dzielenie się taką wiedzą może przysłużyć się i formom, które wykonują takie projekty, ale i potem im klientom, czyli w zasadzie wszystkim potencjalnie graczom, którzy są obecni na rynku.

Na dziś to już koniec. Dziękuję bardzo za uwagę, za wysłuchanie. Kłaniam się nisko i do usłyszenia.