Bardzo często można spotkać w sieci i w literaturze różne podejścia do oceny skutków błędów analizy wymagań. Nie mniej wiele jest “sposobów na odkrywanie” wymagań.
Burza mózgów
Bardzo często spotykam się z rozwlekłymi opisami, wszelkiego rodzaju ankietami, wywiadami, burzami mózgów, żółtymi karteczkami itp. Poradników nie brakuje. Dyskusje na tego rodzaju tematy dotykają zawsze pracy grupowej i jej “siły”. Niestety psychologia dawno dowiodła, że np. dowolna liczba studentów niepotrafiąca zdać egzaminu nie zda go pracując nad testem razem, i liczba tych studentów nie ma znaczenia. Po protu trzeba mieć wiedzę i umiejętność. (przeczytaj więcej o pracy grupowej)
Można się często spotkać z tłumaczeniem tego, tak zwanym holistycznym podejściem mówiącym, że całość znaczy więcej niż suma składników. Zapewne tak jest ale to dotyczy raczej uzupełniających się umiejętności: zarówno sprawny fizycznie ślepiec jak i pozbawiony nóg widzący kaleka, w pojedynkę mają nikłe szanse na samodzielne przeżycie. Obaj razem mają znacznie większe szanse, stanowią coś znacznie więcej niż niż każdy z nich z osobna. Jednak jeśli żaden z nich nie potrafi gotować, to razem także nie potrafią, nie będą potrafili nawet jeśli takich jak oni (nie umiejących gotować) było by w tym zespole więcej. Burza mózgów tego zespołu nie da nic lepszego do zjedzenia ponad to co potrafi najlepszy z nich (a jeżeli przepis ustalą jako kompromis własnych pomysłów, to chyba nie chciał bym tego jeść). A co na to nauka? Poniżej popularny mit i efekty badań:
Tak więc porównanie burzy mózgów z [[holizm]]em odbieram raczej jako niezrozumieniu tego drugiego.
Ciekawe jest to, że metoda ta jest “powszechnie stosowana” i zalecana przez niejedną firmę doradczą (zaryzykuję, że przez większość). Stosowana jest także jako “sposób na problem” przez firmy (zespoły), które z jakiegoś powodu, nie mają dostępu do potrzebnego specjalisty (na temat tych powodów innym razem :))
Klasycznym przykładem opisanego podejścia są analizy i zbieranie wymagań właśnie metodą burzy mózgów, ankietowania przyszłych użytkowników, sesje JAD i podobne metody. Skoro przyszłe oprogramowanie ma powstać na bazie wymagań (co by to nie miało znaczyć) to dlaczego autorzy pomysłów na zbieranie wymagań metodą “pracy grupowej” nie posadzą tej grupy od razu do napisania tego oprogramowania? Zgodnie z ich podejściem grupa “potrafi więcej” wiec powinno im się kiedyś udać napisać działający program? Głupie? Nie! Próby są podejmowane, oto etap przejściowy:
Joint Application Development (JAD) oznacza współtworzenie aplikacji. Jest to metodyka polegająca na zaangażowaniu klienta lub użytkownika w proces tworzenia oprogramowania, poprzez wprowadzenie warsztatów współprojektowania, zwanych sesjami JAD. (źr. WIKI).
Prawdę mówiąc, obserwując efekty tego podejścia, skłaniam się nie raz ku tezie, że JAD to przerzucenie znacznej części odpowiedzialności za potencjalną porażkę na klienta: “w końcu aktywnie brał Pan w tym udział wiec to nie tylko nasza wina”. W moich oczach to raczej próba w rodzaju “skoro nie umiem tego robić to może razem z klientem coś wymyślimy (znowu burza mózgów).
Proszę sobie kiedyś w ramach ćwiczeń policzyć koszty sesji JAD (np. 15 osób na sali, konsultant prowadzący i jego pomocnik notujący, koszt opracowania danych z każdej sesji, razem raz w tygodniu przez rok trwania projektu). Drugie ćwiczenie: ankieta wypełniona przez każdego pracownika szczebla średniego i wyżej. Najpierw czas tych ludzi jaki zajmuje wypełnianie ankiet, potem koszt ich opracowania przez konsultantów w firmy doradczej.
Pewna międzynarodowa korporacja, chcąc oszczędzić na zatrudnianiu specjalistów z zewnątrz, zarządziła by każdy ich zespół na świecie, metodą burzy mózgów, zaproponował kilka sposobów rozwiązania pewnego problemu. Z całego świata napłynęło ponad 6 tys. “pomysłów”, ich przetwarzanie tych danych trwało prawie rok, by przekonać się, że w zasadzie problemu nie rozwiązano. Koszt całości tej pracy (czas pracy własnych pracowników odciągniętych od normalnych zajęć) wielokrotnie przewyższał wartość odrzuconych ofert ekspertów.
Ostatnio zrobiła się moda na konkursy fotograficzne, konkursy na logo, konkursy na reklamę itp. dla amatorów. Regulaminy większości z nich zawierają zapisy o przejęciu praw majątkowych do nadesłanych prac. Często słyszę, że zawodowy fotograf czy grafik “chce za dużo” więc ogłasza się konkurs z jakąś nagrodą, uczestnicy nadeślą za darmo wiele prac i coś się wybierze. Nie raz jednak koszt zorganizowania, zbierania i przeglądu prac, czas pracowników zaangażowanych w cały ten proces wielokrotnie przekracza “to co sobie zażyczył Pan fotograf (czy grafik).
Agile
Niestety wiele projektów programistycznych to odkrywanie wymagań “w trakcie” dostarczania produktu. Po dostarczeniu jakiegoś fragmentu (lub nie raz prototypu całości) beneficjent stwierdza: “to jest dokładnie to czego chcieliśmy ale zupełnie nie to co jest nam potrzebne“… Projekty z rodzaju Agile WIKI definiuje jako:
Programowanie zwinne ((ang.) Agile software development) ? grupa metodyk wytwarzania oprogramowania opartego na programowaniu iteracyjnym (model przyrostowy). Wymagania oraz rozwiązania ewoluują przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania (źr. WIKI)
Nie jestem wrogiem Agile jako zwinności, gdyż sam uważam, że należy się dostosowywać, ale zwinność postrzegam raczej jako dostosowanie metod pracy a nie brak planowania i projektowania (przypominam, że planowanie nie polega na ustaleniu planu cyklicznych spotkań a na ustaleniu co kiedy powstanie).
Niestety bardzo często projekty Agile przypominają powyższy rysunek z mostem (napis na rysunku brzmi: może jednak zbudujmy łódź zamiast tego?) bo w Agile “rozwiązania ewoluują”. W efekcie na początku projektu nie wiemy co i jakim kosztem powstanie… o ile w ogóle powstanie, bo może skończyć się finansowanie.
Na zakończenie
Burze mózgów mają sens, jak najbardziej, ale w przypadku zespołu specjalistów. Jeżeli zachodzi ryzyko, że jeden specjalista w danej dziedzinie, będzie pracował nad uzyskaniem rozwiązania zbyt długo na co nie ma czasu, zamiast jednego specjalisty “sadzamy” kilku (słynna scena w Apollo 13). Jest bardzo prawdopodobne, że któryś z nich wpadnie na właściwy pomysł szybkiej niż koledzy. Jest nawet metoda polegająca na uzupełnianiu takiego zespołu osobą z innej dziedziny w celu wprowadzeniu elementu “nieszablonowego myślenia” (nie ma głupich pomysłów, są tylko w danym przypadku nie przydatne). Ale efekt (pomysłu “laika”) i tak będzie wymagał wiedzy specjalistów by go wdrożyć.
Jak specyfikować wymagania? Cały ten blog traktuje o tym jak, w sposób usystematyzowany i “niestety” troszkę naukowy. Można to zrobić, opracować wymagania na oprogramowanie, dobrze oraz relatywnie tanio i skutecznie (analityk w zasadzie zawsze jest tańszy niż koszt burza mózgów: jej członkowie i opracowanie wyników). Na jednym z forów w toku dyskusji na podobny temat napisałem:
… czym innym jest komplikacja [pracochłonność] a czym innym trudność (umiejętność zrobienia czegoś), np. robienie dobrych zdjęć nie jest skomplikowane (np. jeden guzik w telefonie) ale jest trudne (trudno jest zrobić zdjęcie, które zachwyci fotoedytora gazety) zaś ich wywoływanie nie jest trudne ale jest skomplikowane… dlatego dla ludzi, którzy nie rozumieją swojej pracy (bo nie zawsze muszą i nie zawsze jest takie oczekiwanie) tworzy się procedury np. instrukcja obsługi fotolabu ekspresowego. Podobnie projektowanie: ono nie jest skomplikowane ale jest trudne, ani procedury ani liczba osób nie przybliżą nas do lepszego projektu…
Jeśli coś jest skomplikowane, złożone, możliwym rozwiązaniem jest dodanie zasobów i właściwych procedur. Jednak jeśli coś jest trudne, potrzebny jest po protu ktoś, kto potrafi.
Czemu o tym piszę? A bo właśnie mam przed sobą kolejny dokument o nazwie SIWZ, wykonany techniką burzy mózgów i ankietowania (w obszarze specyfikacja wymagań), jakimś kosztem (czas pracowników albo koszt konsultanta pracującego tą właśnie metodą) opracowano tę specyfikację wymagań a teraz zamawiający sam przyznaje (po rozstrzygnięciu przetargu), że analiza wymagań (teraz) jest potrzebna bo ów SIWZ jest “niespójny, ma braki i wymaga korekty i uzupełnień”. Z tego powodu także nie ma pewności, że w ogóle dobrze opisano Przedmiot Zamówienia!.
TRUE 🙂
A propos SIWZ: Potwierdzam z autopsji. Dlatego tak cenię metodyki Agile – po co się oszukiwać 😛
Metodyki Agile nie są panaceum, są dobre w ograniczonym czasie na projekt, który ma słabo sprecyzowane wymagania i przy akceptacji ich dość dużego ryzyka. Dotyczy to często projektów związanych z internetem (głównie dla tego typu projektów powstały te metodyki). Jednak w projektach biznesowych, wymagających planowania skutków, metody zwinne postrzegane jako “odkrywanie wymagań” uważam za bardzo złe podejście co potwierdzają znane mi projekty biznesowe realizowane przez firmy z grupy “agencje interaktywne” i zespoły programistów, które dostawały termin ale nie projekt (wiele przetargów niestety tak wygląda).
Nie wydaje mi się, że metodyki agile powstały szczególnie dla projektów związanych z internetem. Raczej powstały, gdy inne metodyki zawiodły, a współpraca między klientem a dostawcą jest na poziomie WIN-WIN. Mocna sformalizowane podejścia w takich sytuacjach tylko “denerwują” i przeważnie nieformalnie odchodzi się od nich. Głównym błędem przy wdrażaniu i używaniu metodyk zwinnych jest myślenie, że w nich się nie planuje, nie analizuje ryzyka i “idzie się w ciemno”:). To wszystko nie tylko nie jest wykluczone w projektach typu agile, a czasami jest wręcz niezbędne np. analiza ryzyka, wczesne studium wykonalności.
Dla mnie najbardziej istotne elementy projektów agile to:
1.Partnerska współpraca z klientem.
2.Usługa/produkt jest dostosowywana i tworzona na poziomie zrozumiałym dla klienta. Nie musimy go mocno edukować, aby zrozumiał np. produkty analizy, jeśli tego nie oczekuje, nie wymaga. Dzięki temu klient widzi bardzo wcześnie zrozumiałe dla niego efekty. Możemy iść “na skróty” jedynie w sytuacji, gdy widzimy, że nie będzie to ze szkodą dla klienta i/lub projektu, inaczej pozostaje mocniejsze sformalizowanie. Krótko mówiąc elastyczność zależnie od sytuacji.
3.Ciągła kontrola czasu i budżetu po kątem przydatności dla projektu. Np. po co robić dogłębną analizę, jeśli jest robiona “na siłę”. Klient wymyśla “na kolanie” wymagania, a gdy zobaczy kawałek systemu to i tak zmieni zdanie :).
Namacalna
4.Cały zespół jest bardzo “blisko” produktu/usługi końcowego.
5.Efektywność i co jest paradoksalne autentyczne dotrzymywanie terminów 😀 (nie do końca rozumiem ten mechanizm)
Minusy :
1.Mniej formalnych “dupochronów” 🙂 – zwiększone ryzyko “wyłgania się” klienta z podjętych zobowiązań.
2.Większe obciążenie dla PM – spowodowane dużą zmiena.
3.w projekcie muszą być indywidualności/liderzy – ciągła potrzeba wizji na każdym etapie.
Wydaje mi się, że nieporozumienia mają swoje źródło w “braku formalizmu”. Na prawdę warto definiować sobie pojęcia na początku wywodu. Jeżeli agile to: “Wymagania oraz rozwiązania ewoluują przy współpracy samozarządzalnych zespołów” to znaczy, że projekt startuje bez specyfikacji wymagań i tyle. Wskazane pięć punktów “tego” Agile nie zawiera “tego co ma powstać” a tylko to “jak być może coś powstanie”. Proponuję do każdego punktu dodać pytanie “Co to znaczy”. Czyli:
1. Co to znaczy “partnerska współpraca z klientem”
i.t.d.
Jeżeli np. ktoś dopuszcza w projekcie to, że “Klient wymyśla ?na kolanie? wymagania, a gdy zobaczy kawałek systemu to i tak zmieni zdanie” to znaczy, ze nie panuje nad projektem.
Bardzo podobają mi się owe minusy Agile. One są po protu tym co trzeba umieć w projekcie a czego nie raz brakuje, z powodu… każdy sam sobie odpowie dlaczego…
Moim zdaniem, na “Agile” nie da się napisać definicji 🙂 Pojęcia z zarządzania projektami są bardzo często wypaczane i nadużywane. Nawet terminy PRINCE2 i PMBook “widziałem” nadużywane :), a co mówić tak kuszący Agile.
Twoja definicja mi nie pasuje 🙂
Ad.1. To oznacza, że obie strony znają swoje ograniczenia i szanują się wzajemnie. Nie ma tekstów małym druczkiem. Najważniejszy jest sukces obu stron.
Ad.2 i 3. Wydaje mi się, że wystarczająco to opisałem
Ad.4.”Blisko” tzn., że nie patrzy tylko na swój kawałek, np. analityk widzi tylko analizę, ale już go nie obchodzi efekt pracy programistów.
Ad.5.Jak najwięcej efektu w jak najkrótszym czasie i budżecie – oczywiście z zachowaniem wymagań niefunkcjonalnych. Stosowanie zasady Pareto (80/20).
Cały czas jest problem: skoro coś nie ma definicji to znaczy, że nie wiemy czym naprawdę jest (definicja, która przytoczyłem nie jest moja, pochodzi z WIKI), jeżeli nie wiadomo czym jest “coś” to znaczy, że nie wiemy nawet czy to osiągnęliśmy… nie da się powiedzieć ile czegoś osiągnięto skoro nie określono ile tego jest… (wymagania).
Sporo jest prawdy w tym co piszesz. Burze mózgów i praca grupowa stały remedium na wszystkie problemy – i często są nadużywane.
Ja bym jednak ich nie deprecjonował. Wszystko zależy od osoby. Np. mnie się dużo lepiej pracuje w grupie. Gdy sam mogę rzucać pomysłami, a kompani odbiją te bezsensowne (bo wiedzą coś czego ja nie wiem). I w drugą stronę – gdy inni podsyłają pomysły a ja, dzięki wiedzy i doświadczeniu, szybko odrzucam bądź rozwijam. Świetnie mi się tak pracuje w pierwszym stadium projektu, rozwiązywanego problemu.
Co jednak oczywiście nie oznacza, że przechodząc do szczegółów wolę się w to już zagłębić i przeanalizować sam 🙂
Dorzucę, że burze mózgów w trakcie projektu są bardzo pomocne np. w sytuacji, gdy trafimy na problem od którego się odbijamy już drugi dzień :). Jednak z punktu widzenia psychologicznego, często trudno jest się podzielić z zespołem problemem – po prostu duma nam nie pozwala :).
Duma jest złym narzędziem pracy 🙂
Kontynuując – skończyły się możliwości odpowiadania w wątku :). Wydaje mi się, że trochę niejasno napisałem co do definicji Agile. Definicja jak najbardziej istnieje w Manifesto for Agile, ja miałem na myśli coś na kształt definicji metodyk formalnych np. PRINCE2. Agile w każdym zespole jest inne ponieważ dostosowuje się do zespołu a nie zespół do metodyki. Ludzie się w nim(niej?:)) najważniejsi, bo to oni niosą wartość, a nie procedury, zasady, formalizmy. Przytoczona definicja z wikipedii jest nienajlepsza, nie mówi o duchu Agile i na pewno nie definiuje Agile – po prostu nie jest definicją :P. To tak jakby powiedzieć, że PRINCE2 to spotkania komitetu sterującego – wyjęte z kontekstu.
Pozwoliłem sobie na kilka kąśliwych uwag na temat pana poglądów na idee Agile.
http://touk.pl/blog/2011/09/01/zwinna-analiza/
Pozdrawiam.
@Tomasz: Małe ćwiczenie myślowe: czytamy to “Po co w ogóle robić analizę, produkować dokumenty i diagramy? Ich efektem będzie zamieszanie. Lepiej wyznaczyć cele i napisać działający kod.” i wyobrażamy sobie teraz tę metodę pracy podczas remontu mieszkania i to, że na remont łazienki mamy określone pieniądze i skończony czas (no bo ileż można żyć bez łazienki…) mam uczucie, że większość “fachowców” remontujących mieszkania pracuje “zwinnie”…
Bardzo fajnie sie to czyta Jarku ;-). Dzieki!
To ja dziękuję 🙂