Nierealistyczne oczekiwania w projekcie i ich wpływ na inżynierie wymagań

Wszystkie realizowane na świecie projekty bazują na pewnych wstępnych wyobrażeniach finalnych produktów oraz założeniach jakie przyjmujemy na początku projektów. Finalny produkt często w oczach zamawiającego jest bliski ideału i często daleko wykracza za realne możliwości technologiczne lub oczekiwania rynku. Przyjęte warunki często wymykają się spod kontroli podczas realizowanych projektów i słyszymy od klienta „to jest to co chcieliśmy ale” lub co gorsza generują koszty nie adekwatne do wartości wytwarzanego rozwiązania.

W wielu projektach możemy spotkać się z osobami, które stawiają nierealistyczne wymagania, mimo że nie ma to uzasadnionej przesłanki biznesowej lub wybiegają z oczekiwaniami w przyszłość daleko w przyszłość. Oczywiście wszystko jest kwestią środków jakie mamy na realizacje projektów, jednak z praktyki wynika że budżetu w projekcie zawsze jest zbyt mało bo projekt często nie został odpowiednio oszacowany.

Z doświadczenia wiadomo że nie istnieją projekty gdzie przy tym samym zakresie możemy dowolnie zmniejszyć budżet lub wymagać dużo większej jakości, nie jest to realne. Podobnie jak w anegdocie o szewcu, usługa może zostać wykonana :

  • szybko i wysokiej jakości ale tanio to nie będzie
  • tanio i szybko ale jakości tam próżno się doszukiwać
  • tanio i wysokiej jakości, jednak w bardzo długim czasie

Z powyższych refleksji wyłania się problem realnych priorytetów w naszych projektach i przypisania ich do zebranych wymagań. Często w projektach wewnętrznych można spotkać się z określenie że wymagania mają zostać zrealizowane wszystkie, jednak często nikt nie jest w stanie powiedzieć, które są najważniejsze. Przykładem może być przygotowanie prototypu produktu na konferencje gdzie z góry wiem że nie jesteśmy w stanie wyrobić się z pełną funkcjonalnością na podany termin. Dyrektor naciska, zespół informuje nas że produkt będzie gotowy w kwietniu roku następnego, a konferencja ma odbyć w grudniu. Sytuacja patowa, bez podjęcia odpowiednich kroków i decyzji co chcemy pokazać i realnie wykonać, strata będzie zarówno po stronie biznesowej ale także technicznej dla samego zespołu rozwoju. który dostanie zadanie przygotowania pełnego produktu będące nie do wykonania. Bez podjęcia działań spotkamy się z typowym „marszem ku śmierci”, gdzie zespół będzie pracował nad produktem dnie i noce, jednak z góry wiadome jest że nie jest w stanie wywiązać się z realizacji zadania.

Podobnie możemy się spotkać z nierealnymi wymaganiami, które zapisywane są w oczekiwania. Niestety nie są one weryfikowane na wczesnym etapie projektu bo często nie ma takiej możliwości, a następnie generują wysokie koszty realizacji projektu lub tworzą niepotrzebne opóźnienia i utrudnienia. Najczęściej tyczy się to wymagań niefunkcjonalnych, których natura uniemożliwia ich łatwe opisanie w postaci słów, a stanowią najtrudniejszą w realizacji część projektów.

Praktyka pokazuje że w takich sytuacjach musimy podjąć dyskusje z klientem na temat priorytetów w projekcie oraz obiektywnie pokazać mu zalety oraz wady decyzji. Stała współpraca z biznesem ma znaczący wpływ na powodzenie projektu i nie należy jej tutaj nie doceniać. Szczególny nacisk na obecność interesariuszy możemy zaobserwować popularnych metodykach zwinnych jak Scrum, gdzie jest jedna dedykowana rola o pełnej dostępności w projekcie.