Udane, czyli dobrze zidentyfikowane i udokumentowane wymagania udziałowców, stanowią podstawę dla sukcesu projektu informatycznego. Sukcesu rozumianego nie jako dostarczenie produktu, systemu, ale dostarczenie wartości udziałowcom. Jaka jest różnica pomiędzy tymi pojęciami? Zasadnicza – i mogąca zmienić całkowicie podejście do realizacji projektu i ustalania jego celów. Koncepcja wartości udziałowców została opracowana przez Toma Gilba – światowej klasy eksperta inżynierii oprogramowania. W jego pojęciu, celem projektu nie jest wytworzenie i przekazanie klientowi systemu, kodu czy dokumentacji, lecz dostarczenie wartości. Dokładniej – dostarczenie wartości udziałowcom.

Dlaczego wartości? Ponieważ udziałowcy nie potrzebują kodu czy de facto samego systemu, sam fakt posiadania oprogramowania nie jest przyczyną, dla której potrzebują danego oprogramowania. Udziałowcy chcą wartości, której ma dostarczyć system. Bank zamawiający system on-line służący do przeprowadzania transakcji nie potrzebuje samego systemu - potrzebuje wartości, czyli zwiększenia liczby transakcji poprzez udostępnienie swoim klientom rozwiązania bankowości elektronicznej. Potrzebuje zwiększenia liczby klientów, minimalizacji kosztów, zwiększenia udziału na rynku. Sam system, kod źródłowy nie jest wartością – funkcjonalność oraz inne cechy, jakie daje – jest.

Dlaczego udziałowcom? Ponieważ – wbrew dość powszechnym opiniom – osoby zainteresowane projektem nie ograniczają się do klienta, czy użytkownika.

Dla niektórych dostawców oprogramowania role projektowe ograniczają się do zespołu projektowego (po stronie dostawcy) i klienta oraz użytkowników (po stronie zamawiającego). Dodatkowo, często miesza się role klienta i użytkownika traktując je równoznacznie. Klient nie musi być użytkownikiem, użytkownik nie musi być (i bardzo często nie jest) klientem. Bank zamawiający system on-line służący do przeprowadzania transakcji jest klientem dostawcy IT; użytkownikami systemu są klienci tego banku.

Nie wystarczy więc stwierdzić, że udane wymagania to wymagania klienta. To również wymagania użytkownika, sponsora biznesowego projektu, przedstawicieli biznesu, architektów systemu – oni wszyscy mają wpływ na ostateczny projekt rozwiązania i ich wszystkich należy uwzględnić podczas identyfikacji i dokumentowania wymagań.

Twórca koncepcji wartości udziałowców, bazując na swoim wieloletnim doświadczeniu, opracował 10 zasad tworzenia udanych wymagań. Oto one:

1. Zrozum krytyczne cele najwyższego poziomu
2. Myśl o udziałowcach - nie tylko o użytkownikach i klientach!
3. Skup się na wymaganej jakości systemu, a nie tylko na jego funkcjonalności
4. Określ liczbowo wymagania jakościowe jako podstawę do inżynierii oprogramowania
5. Nie mieszaj celów ze środkami
6. Pozyskuj wyraźną informację o wartości
7. Upewnij się, że specyfikacja jest „bogata”: specyfikacje wymagań potrzebują znacznie więcej informacji, niż samo wymaganie!
8. Wykonuj kontrolę jakości specyfikacji (ang. specification quality control, SQC)
9. Weź pod uwagę całkowity cykl życia i zastosuj myślenie systemowe - nie tylko koncentrację na oprogramowaniu
10. Uznaj, że wymagania się zmieniają: używaj informacji zwrotnej i aktualizuj wymagania w razie potrzeby

Szczegółowy opis każdej zasady znajdziecie w nowym artykule Toma Gilba, który wkrótce ukaże się w magazynie c0re . Zapraszamy do lektury artykułu „Ulepszanie podejścia do wychwytywania wartości w specyfikacji wymagań” w październikowym numerze c0re.

Autor: Karolina Zmitrowicz