środa, 21 maja 2014

Dla kogo jest pozyskiwanie i negocjowanie wymagań?

Ogromna różnorodność grup docelowych INŻYNIERII WYMAGAŃ jest tym, co różni inżynierię wymagań od innych dziedzin inżynierii oprogramowania. Wymagania, to swego rodzaju spoiwo, łączące w projekcie IT w jednorodną całość działania osób, należących do różnych grup zawodowych [więcej].

[wpis na temat warsztatów 28-29 maja]

Poniżej opisujemy szczegółowo, jakie konkretne korzyści przyniesie osobom, należącym do różnych grup docelowych, wiedza na temat pozyskiwania i negocjowania wymagań.

Ponieważ inżynieria wymagań służy tak wielu różnym grupom zawodowym, podstawowa wiedza, potrzebna wszystkim, określona jest przez system certyfikacji IREB CPRE (Certified Professional in Requirements Engineering). Ten certyfikat uzyskało już ponad 15.000 osób na świecie.

Projekt IT to przedsięwzięcie, mające na celu osiągnięcie, zrealizowanie jakiejś potrzeby biznesowej, celu, marzenia, przy pomocy nowego, lub zmodyfikowanego, systemu informatycznego.

Podstawą całego projektu jest więc poprawne, dokładne, ale zarazem elastyczne zdefiniowanie jego celu i założeń: inżynieria wymagań = stworzenie dobrej specyfikacji wymagań. Ten proces, kluczowy dla powodzenia projektów IT, jest jednak często niedoceniany i przez to źle realizowany, skutkiem czego cierpią inne, lepiej znane i rozpoznawalne obszary, celebryci projektów IT: zarządzanie, projektowanie, programowanie (zwłaszcza metodyki agile), wdrożenie, sprzedaż, i testowanie.

DLA LUDZI AGILE

Zapraszamy zwolenników metod zwinnych (agile), bowiem - wbrew pozorom - podejście agile nie oznacza rezygnacji z wymagań oraz inżynierii wymagań, lecz wręcz przeciwnie - polega na niezwykle intensywnym, interaktywnym zdobywaniu (pozyskiwaniu) wymagań w bliskiej współpracy z klientem.

W szczególności, możliwość zastosowania z powodzeniem metod zwinnych nie tylko w małych, ale również w dużych projektach, zależy od dobrych praktyk inżynierii wymagań (czyli, mówiąc językiem Agile Scrum, od dobrego rejestru wymagań produktu - product backlog - i skutecznego zarządzania podziałem go na rejestry przebiegów - sprint backlog). 

Korzyści dla uczestników Scrum Team, Scrum Master'ów, Product Owner'ów:
Głównym zadaniem Product Owner'a jest tworzenie, zarządzanie i priorytetyzacja wymagań wchodzących w skład rejestru wymagań produktu (product backlog), oraz - wspólnie ze Scrum Master'em - jego podział na wymagania dla przebiegów (sprint backlog). To są w 100% zadania z zakresu inżynierii wymagań; dzięki uczestniczeniu w warsztatach Product Owner będzie je wykonywał lepiej i sprawniej.

Uczestnicząc w warsztatach, Scrum Masterzy oraz uczestnicy zespołów Scrum zdobędą lepszą wiedzę - do praktycznego zastosowania natychmiast - jak szacować pracochłonność realizacji wymagań, jakie są inne sposoby, oprócz user stories, specyfikacji wymagań, jak sobie radzić z wymaganiami niefunkcjonalnymi.
Wszyscy uczestnicy projektów prowadzonych metodą Agile Scrum dostaną cenne informacje, jak pogodzić tę metodykę z realiami zarządzania w dużych firmach i projektach (więcej na ten temat tutaj).

DLA ANALITYKÓW - INŻYNIERÓW WYMAGAŃ

Zapraszamy specjalistów inżynierii wymagań, czyli osoby często noszące tytuły analityków, analityków biznesowych, analityków systemowych, lub specjalistów modelowania biznesowego.

Pamiętajmy, że popularna nazwa "analiza biznesowa" stosowana jest głównie w przemyśle IT, podczas gdy określenie "inżynieria wymagań" jest bardziej rozpowszechnione i rozpoznawalne w świecie akademickim.

Korzyści dla analityków / inżynierów wymagań:

Inżynieria wymagań jest w istocie kluczowa dla powodzenia projektów IT, ale jest wciąż dramatycznie niedoceniana. Z reguły, realizuje się ją ad hoc, niefachowo, albo wrzuca do jednego worka z zarządzaniem projektami, albo wreszcie ogranicza do obszaru wymagań wysokopoziomowych, czego symptomem jest przewaga popularności nazwy "analiza biznesowa" nad nazwą "inżynieria wymagań".

Przy okazji: zapraszam do Stowarzyszenia Inżynierii Wymagań:

DLA WŁAŚCICIELI I DYREKTORÓW FIRM

Zapraszamy właścicieli firm, dyrektorów i specjalistów sprzedaży. Tak naprawdę, choć prawda ta bardzo powoli toruje sobie drogę do naszej świadomości, inżynieria wymagań ma także zaskakująco wiele punktów stycznych ze sprzedażą i z marketingiem: wszystkie trzy mają za zadanie wykrycie, analizę i zdefiniowanie potrzeb klientów. Uwaga: zaproszenie dotyczy właścicieli firm i dyrektorów naczelnych zarówno po stronie dostawców, jak i firm zamawiających oprogramowanie: banków, sklepów internetowych, fabryk robiących buty, samochody i telefony, biur podróży...



Próba określenia, w jaki sposób to właśnie system IT, a nie inne działania (może kampania reklamowa? może zastosowanie nowych technik sprzedaży? może wdrożenie franczyzy?) ma ulepszyć biznes, wymaga starannego doprecyzowania celów biznesowych przedsięwzięcia, czemu służy inżynieria wymagań.

Inżynieria wymagań, mimo swej technicznie brzmiącej nazwy, to prawa ręka biznesu.

Korzyści dla właścicieli i dyrektorów zarządzających:

Przemysł IT, oraz wszystkie branże, które wykorzystują IT, czyli dzisiaj cała gospodarka, od lat cierpi na trudności z porozumieniem się między IT a biznesem. Te trudności są najpoważniejszą przyczyną niepowodzeń, opóźnień oraz realizacji systemów IT, które nie przynoszą oczekiwanych, biznesowych korzyści.

Mimo fantastycznego rozwoju technologii informatycznych, umiejętność porozumienia się tkwi w tym samym punkcie, gdzie tkwiła 60 lat temu.

DLA ARCHITEKTÓW

Zapraszamy projektantów i specjalistów architektury oprogramowania, osoby uprawiające BDD (Behavior-driven development), a więc także i TDD (Test-driven development), bowiem, aby Wasze wysiłki nie poszły na marne, konieczne jest ich zsynchronizowanie w płynnie działającą całość.

W terminologii inżynierii wymagań interesariusze (udziałowcy) projektów, to osoby w różny sposób zainteresowane wynikami projektu. Ich interesy nie zawsze są zbieżne, niekiedy są wręcz przeciwstawne, co powoduje problemy.

Inżynieria wymagań zna metody (zwane negocjowaniem albo konsolidacją wymagań), zapewniające spójność sprzecznych często potrzeb biznesu, użytkowników końcowych oraz administratorów systemów; dzięki nim metody zwinne, w tym BDD oraz TDD, mają pełne szanse na sukces.

Korzyści dla architektów:

Dobra architektura jest warunkiem łatwości utrzymania. Od niej przede wszystkim zależy całkowity koszt produktu informatycznego. Aby zaprojektować dobrą architekturę, trzeba przede wszystkim znać cele biznesowe oraz funkcje tworzonego oprogramowania. Ta wiedza, niezbędna architektom, jest produktem inżynierii wymagań.

DLA PROGRAMISTÓW

Zapraszamy programistów, zwłaszcza stosujących języki obiektowe. Często - zbyt często - zdarza się przecież, że Wasze najlepsze wysiłki idą częściowo na marne, bowiem okazuje się, że klient chciał coś zupełnie innego, niż wywnioskowaliście z niepełnej i niejednoznacznej specyfikacji. Równie często zdarza się, że musicie wykłócać się z testerami, czy dane działanie programu jest poprawne, czy nie, co marnuje czas i nerwy. Wreszcie, jakże często w miesiąc po wdrożeniu wychodzi na jaw, że niedostateczna jest na przykład wydajność oprogramowania, o której nikt w ogóle nie wspominał wcześniej, albo pojawia się nagła konieczność przeniesienia systemu na nową platformę, i z głowy macie plany urlopowe. Czy to wyłącznie Wasza wina? Nie, to skutek niedostatecznej inżynierii wymagań.


Korzyści dla programistów:

Jak wioślarz musi znać nie tylko budowę swojej łodzi, ale także cechy akwenu, po którym pływa, tak programista musi znać nie tylko składnię swojego języka programowania, ale również warunki panujące w projektach IT.

To, co najbardziej przeszkadza programistom w tworzeniu dobrego, budzącego zadowolenie użytkowników kodu, to niejasne i zmieniające się wymagania.

Programiści - uczestnicy warsztatów - dowiedzą się, że inżynieria wymagań to nie tylko biznesowe ogólniki, lecz także - a nawet przede wszystkim - narzędzia, umożliwiające tworzenie dobrego kodu, z którego użytkownicy będą zadowoleni, oraz unikanie wiecznych poprawek i przeróbek.

DLA TESTERÓW

Szczególnie gorąco zapraszamy testerów, analityków testowych i kierowników testów! Kto, jeśli nie Wy, cierpi szczególnie dotkliwie, kiedy wymagania są niejasne, niepełne, nieaktualne, błędne i zmienne! Kto, jak nie Wy, w rzeczywistości wykonuje 90% pracy inżynierii wymagań, domyślając się, jak system ma działać (w szczególności, modne jest nazywać tę czynność testowaniem eksploracyjnym), doprecyzowując założenia, a wreszcie zawzięcie ścigając zwinną, wciąż umykającą chimerę ostatecznej, aktualnej wersji?

W praktyce, niemal każdy w Waszych problemów i prawie każde ze stojących przed Wami wyzwań wynika z braków inżynierii wymagań. Parafrazując słowa wiersza "Ach, kiedyż wykujem, strudzeni oracze, lemiesze z pałaszy skrwawionych" - kiedy wreszcie testerzy będą mogli testować, a nie zajmować się gaszeniem pożarów wybuchających w przeddzień wdrożenia wszędzie tam, gdzie ostrożności nie zachowali inni?

Autentyczny cytat z ogłoszenia o pracę (czerwiec 2013): "[Expected to] work with internal and external stakeholders to clarify requirements".
Korzyści dla testerów:

Testowanie, podobnie jak inżynieria wymagań będące przez dziesięciolecia Kopciuszkiem informatyki, wybiło się w ciągu ostatnich 10 lat na dziedzinę docenianą i znaczącą. Tyle, że stało się to kosztem wzięcia siebie obowiązków, które z testowaniem mają mało wspólnego: przede wszystkim poszukiwania, opisywania, a wręcz domyślania się wymagań!

Dla testerów, korzyści z udziału w są ogromne: będą mogli poznać zasady, jak zadbać o to, aby wymagania dawały się przetestować, jak je wykorzystywać do projektowania testów, i jak sobie radzić, kiedy wymagania są niedostateczne, czy wręcz brakuje ich zupełnie.

DLA PRAWNIKÓW I SPECJALISTÓW PRAWA ZAMÓWIEŃ PUBLICZNYCH

Zakończenie - oby szczęśliwe - projektu, to testy akceptacyjne, zadowoleni użytkownicy, podpisany protokół odbioru, wystawiona faktura, a po zapłacie - obustronna nadzieja na dalszą, skuteczną i wzajemnie korzystną współpracę. Jeśli tak się nie dzieje - co czasem zdarza się, prawda? - to u źródeł tego problemu tkwią, oczywiście, niedostatki inżynierii wymagań.

Dobrze, profesjonalnie zbudowania specyfikacja wymagań powinna być koniecznym uzupełnieniem, załącznikiem do kontraktu, ale... prawie nigdy tak nie jest. Mówiąc skrótowo, prawnicy nie słyszeli nigdy o inżynierii wymagań, a informatycy słabo znają się na prawie cywilnym; stąd nieporozumienia i kontrakty, w których dostawcy jako kryterium sukcesu projektu usiłują wpisać "system będzie w zasadzie działać", a prawnicy ze strony odbiorcy bronią się słowami "wtedy w zasadzie zapłacimy". Więc zapraszamy do nas prawników, specjalizujących się w brany IT.

W szczególności, zwracamy się do wszystkich instytucji, których dotyczy prawo zamówień publicznych, oraz do firm, które realizują dla nich systemy IT. Określone przez to prawo warunki przetargów oznaczają, że SIWZ - Specyfikacja Istotnych Warunków Zamówienia - to w istocie typowa specyfikacja wymagań. Jej formę określają szczegółowe regulacje prawne, z których dla nas najważniejsza jest ta, że po rozstrzygnięciu przetargu SIWZ nie może już ulegać zmianie. Z punktu widzenia zarówno dostawców, jak i ogłaszających przetarg instytucji jest to wielkie wyzwanie, z którym tylko inżynieria wymagań pozwala sobie skutecznie radzić.

Korzyści dla prawników i specjalistów zamówień publicznych:

Prawnicy oraz informatycy posługują się najzupełniej różnymi językami, choć często mówią o tym samym. Przykładowo, kryteria odbioru produktu, które prawnik wpisuje do kontraktu, to w istocie wysokopoziomowa specyfikacja wymagań. Poprawne skonstruowanie łańcucha: warunki kontraktu - wymagania - testy akceptacyjne, pozwoli uniknąć wielu kłopotów i sporów.

Prawnicy i specjaliści zamówień publicznych poznają sposoby, jak mogą unikać wielu chronicznych w ich pracy problemów, nauczywszy się lepiej rozumieć informatyków oraz zasady inżynierii wymagań.

DLA KIEROWNIKÓW PROJEKTÓW

Kto zajmuje się inżynierią wymagań, kiedy jej pozornie "nie ma"? Piszemy "pozornie", bo gdyby jej nie było naprawdę, to żaden, dosłownie żaden projekt na świecie nie skończył by się nawet w przybliżeniu osiągnięciem celu... bo cel byłby nieznany. Oczywiście, robi to po trosze biznes, który zwykle nieźle zna swoje cele, choć niechętnie precyzuje je wobec działów IT; dalej programiści, testerzy, ale przede wszystkim kierownicy projektów, odpowiedzialni wszak za osiągnięcie celu w terminie i za określone pieniądze. Cel określają wymagania (produktowe), termin i pieniądze - także wymagania (projektowe), więc jeśli projekt nie ma wymagań, to znaczy, że tworzą się one i są przechowywane w głowach kierowników projektów. Zresztą, tego właśnie uczą Was, drodzy PM-owie (kierownicy), popularne szkolenia PRINCE2 czy PMI.


Można wręcz powiedzieć, że standard PRINCE2 to standard inżynierii wymagań ("Projekt to organizacja powołana na pewien czas w celu wytworzenia - w przyjętym czasie oraz przy wykorzystaniu uprzednio określonych zasobów - niepowtarzalnych, a wcześniej określonych wyników czy rezultatu"). Z tym, że PRINCE2 koncentruje się na sposobach realizacji wymagań, a nie na samych wymaganiach.

Korzyści dla kierowników projektów:

Tam, gdzie brak analityka / inżyniera wymagań, kierownik projektu automatycznie staje się de facto inżynierem wymagań, odpowiedzialnym za sformułowanie celów przedsięwzięcia.

Brak komentarzy:

Prześlij komentarz