wtorek, 30 października 2007

Skąd się biorą wymagania?

Pytanie nieskomplikowane, odpowiedź zwłaszcza w świetle tego, o czym pisałem wcześniej powinna być oczywista: od klienta. Niestety. Odpowiedzi oczywiste nie zawsze są prawdziwe.

Najpierw trzeba się dobrze zastanowić, kto to jest klient. Klient jest osobą, która zamawia i płaci za nasz produkt. Jeżeli działamy w ramach projektów wewnętrznych zamiast klienta jest tzw. właściciel produktu, czyli osoba, która odpowiada za stworzenie nowego produktu. Płacą zaś za niego tak naprawdę klienci docelowi, którym właściciel produkt sprzedaje. Umówmy się, że niezależnie od tych sytuacji wszystkie te osoby będę nazywał klientami.

Pytanie jest następujące: czy klient ma dobrą wiedzę o tym potrzebnych funkcjonalnościach produktu? Zdarza się, że tak. Ale w ogólnym przypadku klient nie zawsze jest tym, który produktu używa. Na przykład w dużych korporacjach software jest zwykle kupowany przez dział IT a potem wdrażany w całej firmie. Czy dział IT (klient) naprawdę wie jakie funkcjonalności powinien mieć program? Nie. O funkcjonalnościach najwięcej wie użytkownik końcowy, czyli ten, który oprogramowanie będzie używał w swojej codziennej pracy.

Co więcej często dość naturalne jest, że istnieje pewnego rodzaju różnica zdań pomiędzy spojrzeniem na wymagania od strony klienta a od strony użytkownika końcowego. Załóżmy, że tworzone jest nowe oprogramowania do zarządzania projektami w dużej firmie. Używać go będą oczywiście kierownicy projektów oraz wszyscy zaangażowani w projekty w firmie. Zamawia go (klientem jest) jednak albo centralny dział IT albo szef działu zarządzania projektami. Z ich punktu widzenia priorytet będą miały takie wymagania jak: bezpieczeństwo danych, łatwość instalacji, łatwość zdalnego zarządzania, przeglądanie sytuacji wielu projektów, raporty z pracy poszczególnych kierowników projektów, kontrolowanie zasobów firmy w kontekście wielu projektów itp. To są funkcjonalności, które oni potrzebują. Czy te wymagania stanowią jakąkolwiek wartość dodaną dla zarządzania projektami w firmie? Wątpliwą. Użytkownicy końcowi potrzebują: łatwości planowania projektów, pomocy w harmonogramowaniu, łatwości przydzielania zasobów, automatyzacji przydzielania zadań, łatwości śledzenia postępu prac (dla kierowników), prostej i szybkiej metody raportowania postępu prac (dla wykonawców), ostrzeżeń o nieprawidłowościach w projekcie. Jeszcze raz: czy system spełniający wymagania klienta ale nie implementujący wymagań użytkownika końcowego będzie miał rzeczywistą wartość dodaną dla organizacji?

Czy w związku z tym wszystkie napisane we wcześniejszych wpisach słowa o kreowaniu wartości dla klienta nie są prawdziwe? Czy nie powinno chodzić o wartość użytkownika? Nie, bo mówimy o dwóch różnych rzeczach. Nie można porównywać jabłek z gruszkami. Klient płaci za produkt, więc to on domaga się za płacone pieniądze dostarczenia wartości dodanej dla siebie. Tylko za tą wartość zapłaci. Wartość ta tworzona jest poprzez implementację funkcjonalności potrzebnej użytkownikom końcowym produktu (wartość dla użytkownika końcowego powinna przekładać się na wartość dla organizacji). Jednak to klient ma ostateczny głos za co chce płacić a za co nie. On też decyduje o tym, które elementy z jego punktu widzenia są najbardziej potrzebne a które mniej. Jeżeli klient zadecyduje, że jego wymagania mają większą wartość niż wymagania użytkowników i trzeba je zaimplementować to jest jego suwerenna decyzja. Etyka zawodowa nakazywałaby jednak poinformować go o potencjalnym konflikcie takim jak opisany wcześniej.

Tak więc jak w projektach zwinnych powinno wyglądać ustalanie co tak naprawdę produkujemy? Wymagania zbieramy od użytkowników końcowych. Priorytety ustalamy z klientem. Proste.

Brak komentarzy: