5 częstych błędów planowania w tworzeniu oprogramowania

Trudno przewidzieć przyszłość, nawet jeśli istnieją do tego specjalne metody. Rzeczywistość jest taka, że nawet planowanie prostego projektu w tworzeniu oprogramowania jest wyzwaniem. Jest wiele rzeczy, które należy wziąć pod uwagę, i równie wiele rzeczy, które mogą pójść nie tak. Udowodniono, że gdy oprogramowanie jest dostarczane wyłącznie na podstawie prognoz, często kończy się to niepowodzeniem. Niestety nadal jest to utrwaloną praktyką.

Najczęstsze błędy popełniane w tworzeniu oprogramowania:

1. Złożoność tworzenia oprogramowania jest często niedoceniana

Tworzenie oprogramowania jest często porównywane do budowy domu. Wydaje się to dobrym porównaniem, bo na pierwszy rzut oka programiści coś „budują". Niestety tworzenie oprogramowania zasadniczo różni się od tradycyjnego budownictwa. Gdy stosuje się takie metody planowania, mogą więc pojawić się problemy.

Nassim Nicholas Taleb w swojej książce „The Black Swan" opisuje dwa różne światy: „Mediocristan" i „Extremistan". Oba światy reprezentują dwa różne rodzaje niepewności.

Aby zademonstrować tę różnicę, Taleb proponuje następujący eksperyment:
Wybiera się 1000 różnych osób z populacji. Osoby te kładą się jedna za drugą głową przy stopach, tworząc długą linię.

Załóżmy, że przeciętny wzrost osoby wynosi 1,68 m. Linia miałaby wtedy długość około 1680 metrów. Linia dwa razy dłuższa (3360 m) musiałaby składać się z około 2000 osób (o takim samym przeciętnym wzroście 1,68 m).

Co by się stało, gdyby kolejne 1000 osób dołączyło do istniejącej już linii? Tym razem jednak wzięto by pod uwagę najwyższego człowieka na świecie (Sułtan Kösen, 2,51 m). W takim przypadku potrzebowalibyśmy tylko 1999 osób. Nawet po uwzględnieniu takiego scenariusza worst-case w planowaniu nie ma więc dużej różnicy w stosunku do naszego pierwotnego obliczenia.

Spróbujmy teraz tego samego eksperymentu – ale z innym obliczeniem:

Tym razem wybieramy 1000 różnych osób z populacji i rejestrujemy majątek poszczególnych rodzin. Przeciętny majątek rodziny w USA wynosi na przykład 110 000 dolarów. Dla tej grupy byłoby to łącznie 110 000 000 dolarów. Następnie szacujemy wymaganą wielkość sejfu do przechowywania łącznego majątku 2000 osób. Można to stosunkowo łatwo obliczyć, znajdując wymaganą wielkość dla majątku 1000 osób i podwajając ją.

Teraz weźmy znowu 1000 osób, ale włączmy Billa Gatesa. Co mogłoby się teraz wydarzyć? Pierwotne szacowanie dotyczyło sejfu, w którym można przechowywać 220 000 000 dolarów. Teraz jednak potrzebny jest sejf na 77 500 000 000,00 dolarów. Jaką różnicę robi tu scenariusz worst-case?

Co mają te eksperymenty wspólnego z tworzeniem oprogramowania?
Jeśli masz już doświadczenie w tworzeniu oprogramowania, z pewnością napotkałeś jakiś problem, którego nie mogłeś rozwiązać. Może to błąd, który jest bardzo trudny do naprawienia. Albo problem techniczny, którego nie możesz rozwiązać dostępnymi narzędziami. Pierwotne szacowanie było nie tylko trochę niedokładne, ale wykazuje odchylenie wynoszące 10%, 20% lub 500%. To jest świat tworzenia oprogramowania. To jest „Extremistan" (drugi eksperyment), gdzie jeden incydent lub element może mieć duży wpływ na wynik.

Większość projektów budowlanych pochodzi ze świata „Mediocristan" (pierwszy eksperyment), gdzie odchylenia są w całości wyrównywane. Powtórzmy eksperyment z losowo wybranymi wieżowcami i ułóżmy je jak domino obok siebie. Teraz wchodzi do gry najwyższy budynek na świecie – Burj Khalifa. Czy wynik jest taki sam jak w przykładzie z wzrostem osób czy w przykładzie z majątkiem?

Jak można teraz zapobiec myleniu „Extremistanu" z „Mediocristanem"? Ważne jest szczegółowe zrozumienie rodzaju zadania, które planujemy. Jeśli nakład pracy jednego elementu może potencjalnie znacznie odbiegać od innych elementów, wskazane jest stosowanie odpowiednich metod planowania. Dlatego empiryczne metody planowania stosowane w Scrumie są bardziej odpowiednie dla projektów z „Extremistanu".

2. Nie planujemy nieprzewidywalnego

Złożone zadania wymagają innego rodzaju zarządzania ryzykiem. W zwykłym planowaniu projektów stosuje się bufory na nieprzewidywalne zdarzenia. Panuje często przekonanie, że nieprzewidywalne jest wyrównywane przez nadrabianie straconego czasu zyskanym. Niestety w przypadku złożonej pracy to nie działa.

Przy tym projekcie jesteśmy pewni, że dostarczymy go w zaplanowanym terminie. Ale wyobraźmy sobie, że prawdziwe fakty są następujące:

• Jesteś indykiem
• Śledzony postęp to Twoja waga
• Nikt nie powiedział Ci o Święcie Dziękczynienia. Co dzieje się z indykami w Święto Dziękczynienia?
  Jak się teraz czujesz?

Nassim Nicholas Taleb używa tej metafory w swojej książce „The Black Swan", by zilustrować wpływ nieprzewidywalnych zdarzeń. Indyk nigdy nie słyszał o Święcie Dziękczynienia i nie ma żadnego buforu. Nieprzewidywalne zdarzenia nie są uwzględniane w tradycyjnym planowaniu. W tworzeniu oprogramowania jednak często do nich dochodzi.

Jak można uniknąć tego błędu? Ramy Scruma przewidują regularne dostarczanie poszczególnych części oprogramowania. Ryzyko jest zmniejszane przez wczesne i częste dostarczanie – a nie przez zaplanowane bufory. Gdy dochodzi do nieprzewidywalnych zdarzeń, istnieje możliwość odwołania się do tego, co zostało dotychczas zbudowane.

3. Często składamy interesariuszom obietnice, których nie możemy dotrzymać

Skoro wiemy, że tworzenie oprogramowania jest złożone i ryzykowne, dlaczego po prostu nie powiemy o tym interesariuszom? Dlaczego składamy obietnice, których nie możemy dotrzymać? Odpowiedź jest taka, że liderzy potrzebują pewności. Ustalają budżet, muszą być pewni, że wszystkie działania są zaplanowane, chcą terminu i oczywiście chcą wszystkich żądanych funkcji.

Ale czy wymagane są zobowiązania wyryte w kamieniu?
Większość fachowców z branży rozumie ryzyko. Rozumie też, że często musi podjąć ryzyko, by osiągnąć zwrot i zyski. Bardzo często wysokość ryzyka jest bezpośrednio powiązana z potencjalnym zwrotem. Większość firm wolałaby gwarantowany zwrot. Wiedzą jednak, że zysk z takich inwestycji jest tak niski, że często w ogóle nie warto inwestować. Jeśli wszyscy o tym wiedzą, dlaczego nie każdy tak postępuje?

Jeśli interesariusze rozumieją stosunek ryzyka do nagrody (zysku), dlaczego w tworzeniu oprogramowania nie stosuje się tej samej zasady? Przy każdym nowym wydaniu pojawia się element nagrody. W każdym dobrym projekcie istnieje obliczenie rentowności (Return on Investment, ROI). Jeśli w projekcie można oczekiwać znacznej rentowności, interesariusze muszą liczyć się z pewnym ryzykiem. Rozmawiaj więc ze swoimi interesariuszami. Uświadom im, że być może nie otrzymają wszystkiego, czego oczekiwali w momencie planowania. To jest ryzyko w tworzeniu oprogramowania. Nie oznacza to, że nie można ograniczyć ryzyka. Uczciwa dyskusja powinna jednak na pewno zostać przeprowadzona.

Jeśli interesariusze chcą od Ciebie wiążących zobowiązań, rób tylko takie, które możesz dotrzymać. Zobowiąż się do współpracy. Zobowiąż się do przestrzegania uzgodnionych procesów. Zobowiąż się do pracy zorientowanej na jakość. Zobowiąż się do ciągłego przeglądania i adaptacji. Zobowiąż się do zapewnienia transparentności.

Porozmawiaj z interesariuszami o ryzyku i nagrodzie oraz wyjaśnij im, że budowanie nowego oprogramowania podlega tej samej zasadzie. Omów, jakie środki ograniczające ryzyko można zastosować. I zobowiązuj się tylko do tego, co naprawdę możesz zrealizować.

4. Często dajemy interesariuszom złudzenie, że niektóre prace są bezpłatne

Gdy obiecujemy naszym interesariuszom określone funkcje w danym terminie i za określony budżet, myślą oni, że za te funkcje zapłacili i je kupili. Jako deweloper zobowiązałeś się do dostarczenia funkcji. Ryzyko polega teraz na tym, że interesariusze myślą, że nie będą musieli ponosić dodatkowych kosztów. W końcu już zapłacili i wierzą, że wszystkie dodatkowe funkcje są wliczone w cenę. Jedyne, o czym myślą, to koszty ewentualnych zmian. W swojej książce „Predictably Irrational" Dan Ariely opisuje zmianę zachowania ludzkiego, gdy coś jest bezpłatne:

„Wszędzie są zalety i wady, ale gdy coś jest bezpłatne, zapominamy o wadach."
Gdy Twoi interesariusze rozumieją, że żadna funkcja nie jest gwarantowana, dopóki nie zostanie ukończona, będą częściej angażować się, podejmować decyzje i iść na kompromisy. Będą nalegać, by najpierw ukończono ważne funkcje, a potem te mniej ważne. Rzadziej będą skłonni do dużego nakładu pracy na funkcje, które nie są tak ważne.

Dlatego należy regularnie przypominać interesariuszom, że nie ma gwarancji, że funkcja zostanie dostarczona zgodnie z planem, dopóki nie zostanie faktycznie wydana.

W celu ustalania priorytetów należy przez cały czas trwania projektu stale współpracować z interesariuszami. Sprint Reviews w Scrumie regularnie dają interesariuszom możliwość sprawdzenia postępów procesu, omówienia nadchodzących prac i ustalania priorytetów.

5. Nie działamy profesjonalnie

Wyobraź sobie, że masz operację oczu. Okulista wie, że przy tej operacji istnieje 10% ryzyko powikłań, które zamiast poprawy mogą spowodować ślepotę. Lekarz decyduje się nie przekazywać Ci tej informacji. Uważa, że w przeciwnym razie może stracić Twoje zlecenie. Wyobraź sobie teraz, że przeprowadzasz operację i tracisz wzrok. Następnie dowiadujesz się, że okulista znał to ryzyko, ale Cię o nim nie poinformował. Musiałby liczyć się z poważnymi konsekwencjami. Z pewnością nie tego można by oczekiwać od profesjonalisty.

Czy lepiej byłoby, gdyby okulista ostrzegł przed ryzykiem, ale potem powiedział: „Nie martw się, jestem bardzo dobrym okulistą i gwarantuję Ci, że nic się nie stanie". Czy to byłoby bardziej profesjonalne?

Ten scenariusz powtarza się ciągle w projektach tworzenia oprogramowania. Kłamiemy naszym interesariuszom. Powód, dla którego kłamiemy, może być zły (skłonienie interesariuszy do podpisania umowy) lub dobry (odebranie interesariuszom strachu) albo po prostu okłamujemy samych siebie. Wynik pozostaje taki sam: jest to wyjątkowo nieprofesjonalne!

Aby uniknąć tego błędu, trzeba być szczerym, nawet gdy jest to trudne. Daje się w ten sposób interesariuszom możliwość rozpoznania ryzyk i odpowiedniego planowania. Profesjonalista używa i promuje empiryczne podstawy Scruma, pomagając w ten sposób interesariuszom lepiej radzić sobie z ryzykami.

Podsumowanie: Błędy planowania w tworzeniu oprogramowania

Trudno przewidzieć przyszłość. Gdy planujemy złożone tworzenie oprogramowania, popełniamy wiele błędów, które często prowadzą do niskiego wskaźnika sukcesu. Dzięki Scrumowi takich błędów można uniknąć.

Tekst pochodzi z bloga Steve'a Portera i został przetłumaczony przez nas na język polski.

Czym zajmuje się Product Owner?

=> Dowiedz się więcej o zadaniach i obowiązkach Product Ownerów.

Spotkanie Sprint Planning

=> Przebieg i ważne wskazówki dla Product Ownerów dotyczące Sprint Planningu