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.

wtorek, 23 października 2007

Wielkość zespołu zwinnego

Temat wielokrotnie poruszany, tym razem doczeka się mojego komentarza. Zwykło sie uważać, że zespół pracujący metodami zwinnymi nie powinien mieć więcej niż 10-12 osób (maksymalna górna granica). Mało kto jednak pisze dlaczego tyle a nie więcej. Co prowadzi, do usilnych prób implementowania metod zwinnych w większych zespołach.

Historię trzeba zacząć od zasad podstawowych. Jedną z wartości zarządzania zwinnego jest "people and interactions over processes and tools", czyli "ludzie i interakcje ponad procesy i narzędzia". Czy to oznacza, że narzędzia i procesy nie są ważne? Nie. Narzędzia i procesy są ważne (zarządzanie zwinne to też proces) ale ważniejsi od nich są ludzie i interakcje miedzy nimi. Każdy kto pracował nad jakimkolwiek bardziej złożonym problemem w grupie ludzi doskonale wie, że choćby nie wiadomo jak dokładne były procesy i narzędzia zawsze zdarzają się sytuacje, kiedy lepiej pójść do kogoś do pokoju i wyjaśnić coś w 2 minuty zamiast (zgodnie z procesem) robić eskalację przez zarząd. Oczywiście mówimy tu o projektach a nie o np. produkcji leków - w przypadku produkcji leków raczej trzeba dokumentować, bo się kończy jak w Jelfie.

Interakcje między ludźmi są najszybszą znaną formą przekazywania informacji. Jakiekolwiek narzędzie spowalnia przekaz informacji, gdyż wymusza zakodowanie informacji do postaci akceptowalnej przez narzędzie (np. zapisanie) a następnie odkodowania przez osobę, która to odbiera (odczytanie). Dlatego w projekty realizowane zwinne cechują się często dużo wyższą efektywnością niż realizowane metodami tradycyjnymi. Po prostu to co jest oczywistością, czyli bezpośrednie przekazywanie informacji zostało tam wbudowane w metodykę zamiast jak to proponuje wiele innych metod udawać, że da się lepiej komunikować przy użyciu narzędzi - głównie dokumentów tworzonych tonami w niektórych projektach.

Dobrze, więc skoro jest tak dobrze się komunikować bezpośrednio to skąd ograniczenie na wielkość zespołu? Jak to w życiu bywa wszystko w nadmiarze szkodzi. Utrzymywanie efektywnego zespołu polegającego na komunikacji interpersonalnej oznacza w skrócie, że członkowie zespołu muszą mieć możliwość swobodnego rozmawiania każdy z każdym i wymiany informacji. Problem w tym, że ilość kanałów komunikacyjnych w zespole rośnie wykładniczo w stosunku do liczby osób w tym zespole. I tak dla zespołu 5 osobowego mamy 10 kanałów komunikacyjnych, dla 8 osób kanałów jest 28, dla 10 osób 45, dla 12 osób 66 kanałów. I tu jest granica, której przekraczać nie należy. Przy 15 osobowym zespole jest już ponad 100 kanałów komunikacyjnych - ponad dwukrotny wzrost w stosunku do 10 osobowego zespołu. Czas poświęcony na dogadywanie się pomiędzy członkami zespołu zaczyna przewyższać wszelkie zyski z wykorzystania szybkich metod komunikacyjnych.

Do wszystkiego należy podchodzić w sposób zgodny z rosądkiem. Ostatnio słyszałem o przypadku firmy X, gdzie wdrożono zwinne zarządzanie projektami a zespoły "po optymalizacji" liczą 20 osób (190 kanałów komunikacyjnych w zespole). Wydaje mi się, że to będzie jeden z tych nielicznych przypadków, kiedy na koniec stwierdzone zostanie, że metody tradycyjne były lepsze. A może to nie stare metody były lepsze, tylko wprowadzenie nowych nieprofesjonalne?

niedziela, 14 października 2007

Niepewność wymagań

Niepewność wymagań została wywołana dwukrotnie w ciągu ostatnich dwóch tygodni, w tym raz publicznie w komentarzach na blogu Alexa. Dlatego dzisiaj o niepewności wymagań.

W świecie IT (choć nie tylko) bardzo często dochodzi do sytuacji, kiedy w momencie w którym projekt powinien się rozpocząć zespół wykonawczy nie jest w stanie spisać wszystkich wymagań klienta. Według standardowych metod w takim wypadku należy powołać zespół analityków i być może projektantów, którzy siądą z użytkownikami końcowymi (lub klientem, choć to bardziej ryzykowne) i spiszą wymagania. Brzmi bardzo rozsądnie. Problem pojawia się w momencie kiedy klient nie wie czego by chciał. To wbrew pozorom zdarza się dosyć często. Tzn. klient wie do czego ma służyć system, wie jakie mają być główne jego funkcje, ale na przykład wymyślenie szczegółowych raportów, które powinien generować system jest poza możliwościami klienta. Głównie dlatego, że system nie istnieje jeszcze w rzeczywistości a człowiek często ma trudności w operowaniu bytami wirtualnymi. Co więcej jest pewna gama projektów, w których nie ma możliwości określić wszystkich wymagań na początku trwania projektu. Przykładami jest większość projektów internetowych. Na przykład www.flickr.com powstał jako narzędzie do dzielenia się zdjęciami. Kto w momencie powstawania tego serwisu zdefiniowałby takie funkcjonalności jak geotagging czy tworzenie fizycznych gadżetów ze zdjęciami?

Wracając jednak do niepewności wymagań: należy założyć, że istnieją projekty w których ta niepewność po prostu jest. Są też projekty, w których tej niepewności być nie powinno. Na przykład projekty realizowane w ramach zamówień publicznych - tam wszystkie wymagania powinny być określone w SIWZ. Błędem często popełnianym przez kierowników projektów jest próba użycia metodyk doskonale sprawdzających się w projektach ze stałymi wymaganiami do projektów w których występuje duża niepewność wymagań. Oczywiście gwoździe można wbijać trzonkiem noża zamiast młotkiem ale skutki mogą być opłakane.

Narzędziem do radzenia sobie z projektami o dużej niepewności wymagań są właśnie metody zwinne zarządzania projektami. Metody zwinne oferują kilka narzędzi/technik, które pomagają radzić sobie z takimi problemami. Najważniejsze:
  • Klient szybko dostaje wartość dodaną - krótkie powodują, że klient dostaje regularnie system wzbogacony o nowe funkcjonalności do testowania, co powoduje że jest w stanie na żywo sprawdzić czy jego wymagania zostały spełnione i wygenerować/uszczegółowić nowe
  • Planuje i rozlicza sie funkcjonalności - całe planowanie oparte jest o kolejne funkcjonalności a nie o zadania do wykonania. Z tego względu klient i zarząd dokładnie wie co (jaką wartość) otrzyma po każdej iteracji. Konieczność zdefiniowania tego powoduje, że musi doprecyzowywać wymagania na bieżąco - do realizacji nie wchodzą wymagania "niepewne".
  • Można planować na różnych poziomach - Ze względu na poziomy planowania tylko najbliższa iteracja lub iteracje muszą być zaplanowane dokładnie. Kolejne wersje mogą być zaplanowane mniej dokładnie, co wprost implementuje naturalną dla człowieka zdolność do dokładniejszego planowania tego co jest bliżej a mniej dokładnego tego co jest dalej. Dodatkowo w sposób naturalny obejmuje to wszelkie niepewności co do wymagań odnośnie szczegółów projektu.
  • Istnieje pewność realizacji spójnego projektu - poziom planowania produktu czy też wizji w projektach zwinnych zapewnia, że cały czas będziemy realizować jeden projekt z jedną wizją i spójnym produktem końcowym. Pozwala to błyskawicznie wykryć sytuację kiedy okaże się, że wymagania tak się zmieniły, że robimy co innego niż pierwotnie zakładane.
  • Zespół pracuje w środowisku stabilnym - na czas iteracji. A to już spojrzenie "z drugiej strony". Programiści i inni zaangażowani w projekt realizowany metodami zwinnymi są szczęśliwi, bo mają pewność że wymagania są zamrażane na czas jednej iteracji. Mają pewność, że nikt nie przerwie im pracy i nie zmieni gwałtownie tego co robią przez całą iterację. Ta pewność w morzu niepewności jest przez członków zespołów szczególnie ceniona.
Oczywiście na koniec słowo o kontraktach. Kiedyś już to było poruszane na tym blogu. W skrócie jeżeli klient nie wie co chce to w jaki sposób może oczekiwać, że my wiemy jak to wycenić? W przypadku projektów o dużej niepewności wymagań podawanie stałej ceny za zrealizowanie takiego kontraktu to chodzenie po bardzo cienkiej linie.