Jak spartaczyć analizę wymagań

Zaczynam pracę nad serią artykułów o przyczynach porażek projektów informatycznych. W pierwszym z nich chciałbym opisać typowe będy występujące w fazie analizy wymagań. Wstępna lista zidentyfikowana przeze mnie wygląda tak:

• Błędnie zidentyfikuj udziałowców projektu
• Unikaj jasnego określenia celów projektu
• Ignoruj cele biznesowe i skup się na funkcjonalności
• Zrezygnuj z zapisania wizji
• Pozwól decydować użytkownikom
• Pozwól decydować deweloperom
• Pozwól na grupowe podejmowanie decyzji
• Zgódź się na wszystkie wymagania
• Uznaj wszystkie wymagania za niezbędne
• Zignoruj koszty i ograniczenia technologiczne (np. wydajnościowe)
• Ogranicz czas na analizę
• Pozwól na zmianę wymagań w trakcie (lepiej - na zmianę celów)
• Zrezygnuj z use-case'ów i prototypów
• W rozmowach z użytkownikami używaj informatycznego żargonu
• Pozwól dominować papierom i formalizmom
• Ugrzęźnij w detalach

Spotkałeś się z innymi problemami dotyczącymi zbierania wymagań? Uczestniczyłeś w projektach, gdzie takie błędy skutkowały problemami w dalszej fazie projektu lub wręcz jego porażką? Będę wdzięczny za wszelkie sugestie - można je przesłać na przykład za pomocą tego anonimowego formularza.

Zobacz inne wpisy

• Zasada Scarlett O'Hara
• Joel Test na polskim podwórku
• Co wpływa na sukces projektu?

Dodaj komentarz

Twoje imię:

Wymagane

Twój adres email:

Nie będzie wyświetlany; ochrona prywatności)

Strona internetowa:

Opcjonalnie

Wpisz odczytany tekst:

Aby utrudnić automatyczne wpisywanie spamu, proszę Cię o przepisanie słowa wyświetlanego na obrazku.