Jak zawalić projekt informatyczny. Analiza wymagań.

Marek Rafałowicz · 25/05/2006 · Link

Jest nieskończenie wiele błędów, które można popełnić w trakcie projektu. Jednak część z nich jest popełniana dosyć często a ich skutki są wyjątkowo przykre. Warto więc o nich opowiedzieć ku przestrodze. Podobnie jak trudno jest podać zestaw rad, który pozwoli opanować na przykład jazdę na rowerze lub sztukę podrywania, tak samo prawie niemożliwe jest wytłumaczenie jak zarządzać w projektach informatycznych. W tych dziedzinach bowiem ważna jest nie książkowa wiedza a umiejętności, wypracowywane przez wielokrotne próby i odpowiednią liczbę porażek. Co więcej, działania, które są wymagane w takich sytuacjach są niepowtarzalne, dramatycznie zależą od sytuacji i ludzi których dotyczą: innymi słowy nie ma gotowej recepty pasującej do różnych sytuacji. Można podać sprawdzone przykłady, dobre praktyki, pomysły, ale ostateczny scenariusz jest zawsze budowany dynamicznie.

Jest jednak pewien zestaw działań, które można dość jednoznacznie określić i przewidzieć ich skutek - są to antyporady. Jeżeli się do nich zastosuje, to dramatycznie zwiększamy ryzyko klapy. Dla podrywania może to być zbyt szybkie przejście do sedna lub pytanie o Ex. Niektóre antyporady mają to do siebie, że opisują powszechnie występujące błędy a ich identyfikacja może pomóc w ich unikaniu.

W tej serii artykułów postaram się przedstawić zestaw antyporad dla tworzenia oprogramowania i pokazać jakie są skutki ich stosowania. Zaczynam tam, gdzie zaczyna się każdy projekt: od określenia po co tworzony jest program i co będzie potrafił zrobić, czyli od analizy wymagań.

Warto zacząć od tego, że analiza wymagań jest dobrym obszarem do zawalenia projektu, bo sukces zależy od solidnych fundamentów i ich brak źle rokuje. Według raportu Extreme Chaos opracowanego przez Standish Group, wśród dziesięciu najważniejszych czynników wpływających na sukces projektu aż cztery są blisko związane z analizą wymagań:

• 2. Zaangażowanie użytkowniów
• 4. Jasno określone cele biznesowe
• 5. Zminimalizowany zakres projektu
• 7. Stabilne bazowe wymagania

Możemy więc zacząć od tej listy i mamy pierwszą wskazówkę do zawalenia projektu:

Unikaj zaangażowania użytkowników

Informatycy mają tendencję do unikania kontaktów z użytkownikami, z różnych względów. Zwykle mają przekonanie, że wiedzą lepiej od nich, jakie są ich potrzeby. W końcu też są użytkownikami komputerów i zwykle mają wyobrażenie o dziedzinie, którą ma wspierać system, a ponadto mają doświadczenie, widzieli takie systemy, znają ludzi i biznes etc. To może być prawda. Tkwi tu jednak niebezpieczeństwo: jeżeli przyjęte założenia i wyobrażenia na temat potrzeb użytkowników są jednak fałszywe lub choćby nieprecyzyjne, to kiedy się o tym dowiemy? Otóż nie stanie się to ani podczas projektowania, programowania, ani podczas testowania a dopiero na samym końcu projektu. Koniec końców efekt pracy trafi pod osąd użykowników, nie uciekniemy od tego. Jeżeli ważymy się odwlec ten moment na sam koniec, to oznacza, że stać nas na hazardową rozrywkę o wysokiej stawce.

Jasne, wobec tego angażujemy użytkowników od początku i korzystamy z ich wiedzy podczas trwania projektu. Pojawia się tylko pytanie, kogo konkretnie mamy angażować? W ten sposób dochodzimy do drugiej antywskazówki:

Błędnie zidentyfikuj użytkowników produktu

Zaczynamy od odpowiedzi na fundamentalne pytanie: kto będzie używał naszego oprogramowania? Jeżeli nie umiemy określić jasno tej grupy, to mamy spory kłopot. Kłopot ten wygląda różnie w zależności od kontekstu biznesowego.

W projektach, w których opracowuje się gotowe oprogramowanie do masowej sprzedaży, brak wiedzy o grupie docelowej grozi tym, że opracowany produkt nie będzie interesujący dla nikogo. Dla niektórych zabraknie ważnych funkcji, inni stwierdzą, że jest sporo niepotrzebnych, które komplikują i podrażają produkt. W efekcie ryzykujemy rynkową klapę.

Inna nieco sytuacja jest w przypadku oprogramowania produkowanego na zamówienie,bo klient jest określony od samego początku i nie ma niebezpieczeństwa, że produkt nie zostanie sprzedany. Nadal zależy nam oczywiście na satysfakcji użytkowników, bo od tego zależą perspektywy współpracy w dłuższym czasie. Ale tu dochodzimy do sedna: Klient a użytkownik to zwykle zupełnie inne osoby. Dlaczego? Kto formułuje wymagania dla wykonawcy? Otóż będzie to kierownik projektu (od strony klienta), kierownik z działu w którym ma być używane oprogramowanie lub jeszcze ktoś inny, kto spełnia dwa warunki: ma dostateczną siłę przebicia i dostatecznie dużo czasu. Ale zwykle nie użytkownik. Do użytkownika trzeba dotrzeć i przekonać do aktywnej współpracy. Innymi słowy - słuchać należy niekoniecznie tego, kto najgłośniej mówi, a nawet nie tego, kto uzurpuje prawo do podejmownia decyzji, bo to nie on może być tym kto ma najważeniejsze rzeczy do powiedzenia.

Zwróćcie uwagę jeszcze na inny aspekt powyższej uwagi: kto inny opowiada o potrzebach (użytkownik), kto inny decyduje o zakresie projektu (analityk, kierownik projektu). Mieszanie tych ról może prowadzić do kłopotów, a konkretny przepis na nie brzmi:

Oddaj decyzję w ręce użytkowników

Taka rzecz się zdarza w przypadku oprogramowania wykonywanego na zamówienie. Jeżeli osoba, która powinna być odpowiedzialna ze strony klienta za analizę wymagań nie ma odwagi podejmować decyzji o funkcjonalności, pierwsze co zrobi, to odda je w ręcę użytkowników (którzy "są najważniejsci"). Jest to prawie pewne metoda na uzyskanie zbioru niezbornych życzeń, bez jasno określonych priorytetów i nijak pasujących do wizji całości. Nie taki jest cel angażowania użytkowników - oni mają zostać wysłuchani i zrozumieni. Poźniej ich potrzeby mają być przełożone na odpowiednie funkcjonalności, ale to jest rola całkiem kogo innego.

Pozwól decydować deweloperom

Dlaczego to jest groźne? Otóż dlatego, że programiści są to inni ludzie niż przeciętny użytkownik. Mają inne umiejętności, inne zamiłowania i inne kryteria oceny tego, co pożyteczne (np. słynny vi). Ta różnica ma szczególne znaczenie właśnie w fazie analizy wymagań. W tym przypadku ważne są takie cechy jak empatia, umiejętność słuchania, dobre zdolności komunikacyjne - cechy, których deweloperom często brakuje. I jeszcze jedno, programiści od początku projektu szufladkują usłyszane rzeczy w zależności od tego, czy się je da wykonać, jak będzie to trudne, jak wpłynie na elegancję wewnętrznej struktury projektu itp. Innymi słowy przyjmują niekoniecznie najważniejsze w tej fazie kryteria.

Kończymy temat z kim rozmawiać i zmierzamy do grupy antyporad wynikających z kolejnego z punktów z raportu Standish Group:

Unikaj jasnego określenia celów projektu (skup się na funkcjonalności)

Większość ludzi odruchowo "projektuje" sposób rozwiązania swoich problemów. W związku z tym zapytani, jakie są cele projektu opowiedzą o swoim wyobrażeniu rozwiązania a nie o źródłowym problemie. "Potrzebuję aplikacji, która ma mieć funkcję do przesyłania dzwięku i żeby miała książkę adresową ze zdjęciami..." zamiast "mamy pracowników w trzech biurach: musimy usprawnić i obniżyć koszty komunikacji między nimi". Brak jasno sformułowanych celów biznesowych powoduje, że brakuje odniesienia i kryteriów dla decyzji dotyczących poszczególnych funkcjonalności. Które są naprawdę potrzebne, z których można zrezygnować, czy można zastąpić je innymi, które rozwiązują problem? Ze względu na brak kryteriów odpowiedź zależeć będzie od gustu i siły przekonywania różnych udziałowców projektów.

Zrezygnuj z zapisania wizji

Nawet jeśli wspomniane kwestie zostały przemyślane na początku projektu, to jest spora szansa, że zostaną zapomniane w ferworze walki. Zwłaszcza, jeżeli projekt trwa dłużej niż kilka miesięcy, zmieniają się uczestniczący w nim ludzie, następują większe zmiany zakresu, wtedy łatwo stracić z oczu ustalone na początku cele. Brak pisemnego odniesienia - krótkiego, jasnego, spójnego dokumentu, zbierającego główne założenia projektu, jest dobrym przepisem na zdryfowanie projektu.

Zgódź się na wszystkie wymagania

Mając określone wspomniane cele mamy narzędzie umożlwiające podjęcie i obronę decyzji o odrzuceniu pewnych wymagań czy wynikających z nich funcjonalności. Co się stanie jeśli nie będziemy stawiać oporu pokusom rozbudowania systemu? Ludowe wyobrażenie jest takie, że więcej funkcji w produkcie nie zaszkodzi, bo najwyżej nie będzie się ich używało. Ale to nie jest prawda z dwóch powodów. Po pierwsze rosnący worek funkcji do zaimlementowania jest sam w sobie sporym zagrożeniem dla projektu (patrz punkt 5. raportu Standish Group). Im większy, tym dłużej trwa projekt, więcej kosztuje, później przynosi korzyści. Po drugie wpływa na spójność aplikacji i wygodę użytkowania. Multum gadżetów, dodatków, możliwości konfiguracji etc. może przesłonić istotę programu, ukryć jego najbardziej kluczową ideę i odstraszać przeciętnych użytkowników. Warto przypomnieć kilka programów, które odniosły ogromny sukces: Firefox, Skype, Gadu-Gadu, Del.icio.us, Google. W stosunku do swoich konkurentów wcale nie miały przewagi w liczbie dostępnych funkcji - raczej miały je bardzo starannie wyselekcjonowane i dopracowane.

Perfection is achieved not when there is nothing to add, but rather when there is nothing more to take away. (Eric Raymond, The Cathedral and The Bazaar)

Everything should be made as simple as possible, but not simpler. (Albert Eistein)

Uznaj wszystkie funkcje za równie istotne

Podobnie jak podjęcie decyzji o selekcji funkcjonalności, również określenie wzajemnych priorytetów poszczególnych funkcji wymaga pewnej odwagi, bo wskazanie mniej istotnych elementów systemu oznacza przeznaczenie ich na pierwsze ofiary w przypadku braku czasu i/lub sił w projekcie. Stąd częste naciski klienta do przyjęcia, że "wszystko jest istotne". W konsekwencji, jak tylko zaczną się kłopoty, to zostaną "ucięte" dość przypadkowe funkcje, potencjalnie kluczowe dla spełnienia celów biznesowych. Gdyby od początku zostały uporządkowane według ważności i były realizowane w takiej kolejności, wtedy cięcia automatycznie dotknęłyby tych najmniej ważnych.

Wiemy już z kim i o czym rozmawiać, zastanówmy się teraz, jakie niebezpieczeństwa tkwią w sposobie rozmowy:

W rozmowach z użytkownikami używaj informatycznego żargonu

Szczególnie w naszym regionie geograficznym z różnych względów ludzie mają kłopot z przyznaniem się, że czegoś nie rozumieją. Dlatego jeżeli w rozmowie z klientem będziemy używali slangowych określeń i będziemy robili to z dostateczną dozą pewności siebie, to mamy spore szanse, że nasz rozmówca nas nie zrozumie, ale mimo to uda, że zrozumiał. Może się zdarzyć, że w miejscach wątpliwych dopowie sobie to, co sam sobie wyobraża - potencjalnie coś zupełnie innego, niż przypuszczamy. Efekt tego nieporozumienia zostanie odkryty dopiero po wykonaniu działającego oprogramowania, a próba udowodnienia, że to my mieliśmy rację w niczym nie przybliży nas do sukcesu.

Pozwól dominować papierom

Papier jest narzędziem, które można użyć, jak każde narzędzie, dla swojej korzyści lub na swoją szkodę. Najprostszy przepis na to drugie, to go nadużyć. Generowanie długich acz mało treściwych dokumentów nie jest trudne przy obecnie dostępnych narzędziach. Warto zdać sobie sprawę, że przy dzisiejszym tempie życia, każdy dokument dłuższy niż kilka stron z ogromnym prawdopodobieństwem nie zostanie w ogóle przeczytany.

Oczywiście w piśmie można dodatkowo popełnić wszystkie grzechy dotyczące ustnej komunikacji: można pisać niejasno i wieloznacznie, nadużywać żargonu, ukrywać istotne myśli wśród stosu detali etc. Śmiało można zakładać, że większość osób onieśmielona kilkusetstronicowym dokumentem pełnym trudnych pojęć i złożonych schematów, nabierze nabożnego szacunku dla naszego profesjonalizmu, nie zada żadnego pytania, nie przyzna się do nie zrozumienia i nie będzie przeszkadzała nam w pracy.

Pozwól na grupowe decyzje (zgniły kompromis)

Z pewnością byliście nieraz na spotkaniu, na którym wszyscy się przekrzykiwali, pouczali, wymyślali celne riposty, ale podjęcie najprostszej decyzji zajmowało mnóstwo czasu. Co więcej, ludzie w takiej grupie często sprawiają wrażenie, jakby nie mogli zrozumieć całkiem prostych rzeczy. Przyczyn tego jest wiele, ale dla nas ważny jest wniosek: próba podejmowania kluczowych decyzji na spotkaniach, zwłaszcza licznych, zapewni absolutnie beznadziejną jakość podejmowanych ustaleń.

Zrezygnuj z use-case'ów i prototypów

Wspomniałem powyżej o problemach w jednoznacznym zdefiniowaniu celów projektu i wizji rozwiązania, wynikających z różnicy w perspektywie użytkowników i projektantów systemu. Jest kilka praktyk i narzędzi, które właściwie zastosowane zwiększają szansę na obopólne zrozumienie. Zrezygnowanie z ich użycia jest niebezpieczną drogą na skróty.

Przypadki użycia (use case) są najpowszechniejszą techniką próbującą rozwiązać problem bariery między światem użytkowników i projetantów. Dzięki swojej formie prowokują do opisania przykładów, odnoszą się do konkretnych wyobrażeń i potrzeb, a przy tym są pisane językiem zrozumiałym dla obu stron.

Doświadczenie pokazuje, że mimo wszelkich pomysłów na usprawnienie komunikacji werbalnej, najłatwiej się porozumieć mając przed oczami prototyp rozwiązania. Obejrzenie konkretnego okna, elementarne przejście w aplikacji procesu związanego z określonym problemem, pozwala zwykle na zauważenie rzeczy niemożliwych do wymyślenia w wielogodzinnych dyskusjach. Prototyp nie musi być kosztowny, w ostateczności może być to zestaw kartek papieru z wizją kolejnych okienek. Nie buduje się mostów bez uprzedniego zrobienia makiety, a przecież mosty są o niebo bardziej powtarzalnymi konstrukcjami niż oprogramowanie!

Zrezygnuj z narzędzi do zarządzania wymaganiami

Przy większych projektach zapanowanie nad wymaganiami i ich losem w trakcie projektu staje się trudne. Możliwe jest skorzystanie ze wsparcia narzędziowego, pozwalającego na katalogowanie wymagań, kontrolę ich zmian oraz śledzenie powiązania między wymaganiami a realizowanymi funkcjami systemu. Zrezygnuj z tego. Postaraj się rozproszyć wymagania w wielu dokumentach, arkuszach, poczcie elektronicznej. Po paru miesiącach spróbuj stwierdzić, czy wszystkie zostały spełnione.

Pomiń oczywiste wymagania

Pewne wymogi są "oczywiste". Nawet jeśli nie zostaną zdokumentowane, to przecież wszyscy o nich wiedzą. Zwykle z tego powodu jest szczególnie trudno zauważyć ich brak w dokumentach projektowych. Zauważcie jednak, że dla różnych osób różne rzeczy są oczywiste. To co jest absolutnie jasne dla użytkownika i projektanta, nie musi być takie dla programisty (oni są inni). Nie wszystko może być też oczywiste, gdy od czasu gdy prowadzono intensywne rozmowy z klientem minął rok. Na koniec zostajemy z oprogramowaniem, które ma prawie wszystko, tylko nie spełnia właśnie oczywistych (czasem najważniejszych) oczekiwań.

Ogranicz się do wymagań funkcjonalnych

Pomiń wymagania technologiczne: wydajnościowe, sprzętowe, zapewnienie bezpieczeństwa itp. Spróbuj wyobrazić sobie, jak będzie wyglądała na końcu projektu zmiana systemu, by spełniał te wymagania.

Oszczędzaj na analizie wymagań

Analiza wymagań kosztuje. Doświadczeni w bojach twierdzą, że cała faza projektowania systemu zajmuje z grubsza jedną trzecią całego wysiłku w projekcie - sporą część tego czasu zajmuje analiza wymagań. A przecież w tym czasie nie powstaje ani jedna pożyteczna linijka kodu! Nie zgadzaj się na to - ogranicz czas na analizę, zacznij programować od samego początku. Trudno najwyżej się to wszystko przerobi...

Pozwól rządzić polityce

W projekcie różni ludzie mają różne cele. Nie wszystkie z nich układają się w zgodzie z interesem samego projektu. Wielu będzie chciało upiec swoje pieczenie nie licząc się ze skutkami. Jeżeli przymkniesz na to oko lub nie znajdziesz sił na odparcie wpływu tych osób, to cały merytoryczny wysiłek zostanie solidnie narażony.

Zrezygnuj z formalnego zatwierdzenia ustalonego zakresu

W momencie rozpoczynania fazy analizy wymagań jest zwykle już pewna ilość materiałów źródłowych - materiały przetargowe, umowa, badania rynku, studium wykonalności itp. W konsekwencji zbierane i ustalane wymagania z pewnością będą w pewnej mierze niespójne z innymi dokumentami. Jeżeli nie uzyskamy formalnego zatwierdzenia, że ustalony zbiór wymagań ma pierwszeństwo przed wszystkimi innymi materiałami, to później z pewnością spotkamy się z sytuacją, w której ktoś będzie się powoływał na te inne źródła. Wszelkie niejasności i niespójności będą mogły być wykorzystane do prób podważenia ustalonego zakresu projektu.

Na koniec

W projektach nie ma złotych reguł. Wcale nie jest powiedziane, że projekt, w którym pojawiają się opisane powyżej zjawiska, jest skazany na porażkę. Tym bardziej nie jest prawdą, że zabezpieczenie się przed powyższymi błędami zapewni sukces. Niemniej są to znaki ostrzegawcze, jak ktoś widzi ich zbyt wiele, to może znaczyć, że jedzie złą drogą i ma małe szanse na dotarcie do celu.

Więcej na temat analizy wymagań

• Requirements analysis - Wikipedia, the free encyclopedia
• Use case - Wikipedia, the free encyclopedia
• Functional requirements and use cases
• 13 common objections against user requirements analysis, Sim D'Hertefelt
• Why user experience disaster happen at the start of web projects, Sim D'Hertefelt
• Requirements - Tyner Blain

---