REQ MAGAZYN - Numer 4 by Monika Perendyk

Nr 4/2016

Dl aczego warto analizować przyczyny sukcesów i porażek projektów ?

BRM, czyli Budowniczy Relacyjnych Mostów między IT i Biznesem.

Dl aczego (nie) modelować procesów biznesowych w UML

inżynieria wymagań

inżynieria oprogramowania

user experience

JAK WIEDZĘ O M Ó Z G U W Y KO R Z Y S TA Ć W PROJEKTOWANIU UX?

Analiza wpływu zmian wymagań

zarządzanie projektami

dział prawny

procesy biznesowe

Inżynieria Wymagań IREB

Szanowni Państwo

– potrójny pakiet korzyści weryfikacja

Przyznawanie się do porażki jest ostatnią rzeczą, o której myśli niemalże każdy kierownik projektu. A to właśnie porażki uczą nas najwięcej. Analiza przyczyn błędów jest najlepszą nauką, o ile wyciągniemy z niej wnioski.

wymagan

wsparcie

W tym numerze piszemy o tym, dlaczego warto analizować przyczyny porażek. Polecamy również spotkania, podczas których można wysłuchać tych, którzy postanowili się „publicznie” przyznać do błędów.

Projekcie

Procesy biznesowe to nieodłączna część inżynierii wymagań, dlatego przedstawiamy Wam kolejny dział, jakim są: „Procesy biznesowe”. W nowym dziale możecie przeczytać dlaczego nie modelować procesów biznesowych w języku UML.

innowacyjnosc

W jaki sposób analizować wpływ zmian w wymaganiach to jeden z wielu artykułów, które prezentują teorię w praktyce.

Synergia

Jednocześnie niezmiernie miło nam poinformować, iż nasze czasopismo objęło swoim patronatem książkę Magdaleny Chomuszko: „System ERP. Dobre praktyki wdrożeń”, która jest do wygrania w konkursie.

zakres projektu

Serdecznie również zapraszamy już 13-14 czerwca na kolejną już edycję Konferencji Inżynierii Wymagań i Analizy Biznesowej, która odbędzie się w Warszawie.

rekomendacje

Zapraszam do lektury!

W PAKIECIE TANIEJ ulepszanie Szkolenie + członkostwo w stowarzyszeniu + egzamin procesów W SPECJALNEJ CENIE REQ

Monika Perendyk Prezes Stowarzyszenia Inżynierii Wymagań Redaktor Naczelna REDAKCJA Opracowanie i redakcja: Redaktor naczelna: Monika Perendyk Zespół redakcyjny: Włodzimierz Dąbrowski Artur Kiełbowicz Rafał Stańczak Marek Zawadzki Korekta: Ewa Brzeska Projekt graficzny i skład: Dagmara Zawada-Żark

Prawa autorskie Wszystkie opublikowane artykuły są objęte prawem autorskim autora lub przedsiębiorstwa. Wykorzystywanie w innych publikacjach, kopiowanie lub modyfikowanie zawartości artykułu bez pisemnego upoważnienia autora jest zabronione.

magazyn

Reklama kontakt@reqmagazyn.pl Współpraca Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: kontakt@reqmagazyn.pl Zdjęcia:

Więcej szczegółów: http://cts.com.pl/info/inzynieria-wymagan-ireb

Facebook http://www.facebook.com/ reqmagazyn

siw.org.pl 3

Spis

Treści Działy stałe

Słowo wstępu

Procesy biznesowe Tomasz Gzik Dlaczego (nie) modelować procesów biznesowych w UML

Inżynieria oprogramowania Jarosław Łojewski BRM, czyli Budowniczy Relacyjnych Mostów między Biznesem i IT

Inżynieria wymagań Hanna Wesołowska, Karolina Zmitrowicz Analiza wpływu zmian wymagań

28 4

Hanna Wesołowska Czy znasz techniki, języki i narzędzia do modelowania najpopularniejsze wśród analityków?

Zarządzanie projektami Ewa Brzeska Na styku biznesu i IT: MVP a wytwarzanie oprogramowania Case Study

34 42

Bożena Rumak Dlaczego warto analizować przyczyny sukcesów i porażek projektów?

Wydarzenia

FuckUp Nights, czyli uczymy się na cudzych błędach!

User Experience

Małgorzata Żądkowska Jak wiedzę o mózgu wykorzystać w projektowaniu UX?

Dział prawny

Karolina Alama Jeden konflikt- wiele ścieżek ku jego rozwiązaniu, czyli rozwiązanie sporów dotyczących nowych technologii-- część II 5

Tomasz Gzik

wych licencji i szkoleń z nimi związanych, bądź analizujemy potrzebujemy elementów, które

Procesy

Biznesowe

nieświadomie i intuicyjnie - nie mając odpo- w dostępnych notacjach nie zostały zdefiniowiedniej wiedzy, decydują się na modelowa- wane. nie procesów biznesowych w UML. Możliwe jest wówczas utworzenie nowych, W przedsięwzięciach informatycznych wyko- odpowiednich dla naszych wymagań elerzystywanie języka UML to standard. W związ- mentów UML. ku z faktem, iż standardem staje się również modelowanie procesów biznesowych – m.in. Co więcej, możemy to zrobić praktycznie w kontekście analizy wymagań, za pomocą w każdym narzędziu wspierającym UML po-

Dlaczego (nie) modelować procesów biznesowych w UML

nified Modeling Language (UML) nie jest językiem modelowania procesów biznesowych. Tezy tej dowodzi fakt, iż w samej specyfikacji UML brak jest jednoznacznych wskazań w tym zakresie.

mowe, ale również biznesowe.

rzeń. (Przypis: UML posiada „wbudowane”

Takie podejście sprzyja utrzymywaniu jedne- mechanizmy, które umożliwiają rozszerzanie go spójnego repozytorium artefaktów projek- jego elementów w kontekście nadawania im

procesów biznesowych. Specyfikacja nie definiuje semantyki elementów UML celowo pozostawiając dowolność w interpretacji i stosowaniu w kontekście procesów biznesowych.

Jednak odnosząc się do praktyki wielu pro- Dlaczego zatem „w towarzystwie” notacji jektów, zespołów i organizacji, w których ję- przeznaczonych do modelowania procesów biznesowych zyk ten jest bardzo - np. BPMN (Busiczęsto wykorzyJęzyk UML znajduje ness Process Model stywany do tego zastosowanie w mo- & Notation), EPC celu, można wniodelowaniu proce- (Event-Driven Proskować zupełnie sów biznesowych cess Chain), UML inaczej – UML jest w wielu projektach ma się bardzo dostandardem przeznaczonym do mo- i organizacjach, ale też w wielu brze i znajduje zadelowania procenie znajduje. Wynika to z faktu, iż stosowanie w wielu organizacjach sów biznesowych, pomimo argumentów „za”, sto- i kontekstach bizco więcej, jednym sowanie UML do modelowania nesowych? z najbardziej popularnych. W związku procesów rodzi ryzyka i ograniOdpowiedź brzmi: z powyższym, war- czenia. UML jest (zasłużeto rozważyć, czy nie) bardzo popunależy modelować procesy w UML oraz jakie są „+” i „-” takiego larny i bardzo elastyczny. Wspiera go wiele podejścia. narzędzi do modelowania, o różnym przeznaczeniu, co również wpływa na jego popularSpecyfikacja UML jednoznacznie wskazuje, iż ność i szerokie zastosowanie. język ten stanowi „narzędzie” analizy i projekOrganizacje, które posiadają w swoim porttowania systemów i może być wykorzystywafelu narzędzia wspierające UML, często świany do modelowania biznesu, w szczególności domie - np. w celu ograniczania kosztów no6

UML modelowane są nie tylko aspekty syste- przez wykorzystanie mechanizmów rozsze-

towych.

innych niż standardowych znaczeń; składają się na nie: profile, stereotypy i metki; profile

Poza popularnością, UML posiada bardzo stanowią podzbiór elementów UML, którym istotną w kontekście praktycznego zastoso- zostało nadane nowe znaczenie (stereotypy) wania cechę – jest elastyczny.

i nowe właściwości - metki).

Rysunek 1. Rozszerzenie znaczenia elementu UML „przypadek użycia” z wykorzystaniem stereotypu

W zależności od potrzeby, każdemu jego ele- Bardzo ważną perspektywą w modelowaniu mentowi może zostać nadane nowe znacze- procesów biznesowych jest hierarchia procenie, tworząc tym samym nowy element możli- sów. Perspektywa ta bez problemu – w przeciwy do wykorzystania podczas modelowania.

wieństwie do BPMN, może zostać uchwycona

Wyobraźmy sobie, że opracowujemy model w UML, np. z wykorzystaniem diagramu przyprocesów biznesowych organizacji o wyjąt- padków użycia lub diagramu aktywności (Rykowej specyfice, co powoduje, że do jak naj- sunek 2 i Rysunek 3). lepszego odwzorowania rzeczywistości, którą 7

Hierarchia procesów biznesowych jest uzupełnieniem perspektywy przebiegu procesów biznesowych, analogicznie jak w UML perspektywa statyczna, na którą składają się diagramy struktury (ang. Structure Diagram), uzupełnia perspektywę dynamiczną, na którą składają się diagramy zachowania (ang. Behaviour Diagram).

Rysunek 3. Diagram hierarchii procesów biznesowych utworzony z wykorzystanie diagramu aktywności UML Źródło: https://bpmstandard.pl/wiedza/artykuly/60-modelowanie-procesow-biznesowych-w-uml (odczyt 14.03.2016)

Dzięki temu do modelowania procesów możemy wykorzystać dowolne elementy według naszego uznania. Takie podejście jest tak samo atrakcyjne – ponieważ elastyczne, jak i ryzykowne. Jeżeli założymy, że zespół będzie modelował procesy biznesowe w UML bez konkretnych wytycznych, to każdy z członków zespołu będzie modelował zgodnie ze swoim doświadczeniem, wyczuciem i intuicją (co W praktyce, trudno wyobrazić sobie model jest naturalne), ale bardzo prawdopodobne procesu biznesowego, którego perspektywa jest, że w inny sposób. hierarchii zamodelowana jest w UML, a perspektywa przebiegu np. w BPMN. W efekcie, członkowie naszego zespołu wzajemnie i pozostali interesariusze (klient, projekJęzyk UML znajduje zastosowanie w mode- tanci, programiści, testerzy, partnerzy…) nie lowaniu procesów biznesowych w wielu pro- będą potrafili jednoznacznie zinterpretować jektach i organizacjach, ale też w wielu nie stworzonych modeli. znajduje. Wynika to z faktu, iż pomimo argumentów „za”, stosowanie UML do modelowa- Powodem jest niejednoznaczność elemennia procesów rodzi ryzyka i ograniczenia. tów UML w kontekście procesów biznesowych, dla przykładu dla jednych proces Specyfikacja języka UML nie definiuje seman- biznesowy w UML można zamodelować z wytyki jego elementów w kontekście procesów korzystaniem elementu „obiekt”, dla innych biznesowych. „klasa”, „czynność” lub „przypadek użycia”.

Rysunek 2. Diagram hierarchii procesów biznesowych utworzony z wykorzystanie diagramu przypadków użycia UML, Źródło: https://bpmstandard.pl/wiedza/artykuly/60-modelowanie-procesow-biznesowych-w-uml (odczyt 14.03.2016)

W rzeczywistości wyżej opisana sytuacja może i dalej jego implementowanie w narzędziach rodzić bardzo poważne konsekwencje, np. modelowania i wykonywania procesów. brak czasu i budżetu w projekcie na ujednoliTakie podejście ma swoje źródło w inżynierii cenie i poprawę modeli. oprogramowania, w której standardem jest Kolejną konsekwencją braku „semantyki pro- generowanie kodu aplikacji na podstawie cesowej”, jest fakt, iż narzędzia wspierające diagramów UML, np. z diagramu klas (ang. modelowanie w UML nie posiadają funkcjo- forward engineering). nalności generowania definicji procesów opartych o XML (Extensible Markup Langu- Stosując UML w modelowaniu procesów poage), które są podstawą wykonywania pro- zbawiamy się takiej możliwości lub bardzo cesów w środowisku workflow lub BPMS (Busi- mocno ją ograniczamy. W praktyce, trudno jest sobie aktualnie wyobrazić projekt autoness Process Management System). matyzacji procesów biznesowych w oparciu Zupełnie inaczej sytuacja przedstawia się o BPMS, w którym definicje procesów będą w kontekście BPMN, wiele narzędzi zapew- tworzone „ręcznie”, a nie na podstawie monia możliwość generowania definicji proce- deli. sów w XPDL (XML Process Definition Language) bezpośrednio z modeli opracowanych Odpowiedź na pytanie „czy modelować procesy biznesowe w UML?” w formie NIE lub w BPMN. TAK, nie może być obiektywna. Decyzja lub Semantyka BPMN jest jednoznaczna w inter- konieczność stosowania UML w modelowaniu pretacji, stąd możliwe jest opracowanie stan- procesów może być spowodowana wieloma dardu definicji procesów takiego jak np. XPDL różnym czynnikami i okolicznościami, często

również takimi, na które decydent nie ma cesów, ze zwróceniem uwagi na pozytywne wpływu. i negatywne doświadczenia; W tym kontekście, przede wszystkim bardzo ważne jest stwierdzenie, iż w UML można skutecznie i efektywnie modelować procesy biznesowe.

• jednoznacznie określić diagramy UML i zamknięty zbiór elementów, które będą wykorzystane do modelowania, wraz z opracowaniem dla nich „semantyki procesowej” – zdecydowanie rekomenduje się realizację Dowód stanowi praktyka wielu organizacji tego założenia poprzez utworzenie profii projektów, opisane w literaturze autorskie lu UML; profile UML dedykowane do modelowania procesów biznesowych oraz prawdopodob- • udokumentować utworzony profil UML; nie najbardziej popularna na świecie metodyka tworzenia oprogramowania Rational Uni- • zapewnić sytuację, w której interesariusze fied Process, która w każdej swojej dyscyplinie będą znali i rozumieli opracowany profil UML - również dyscyplinie modelowania bizneso- oraz posiadali jego dokumentację; wego, zakłada wykorzystanie języka UML. • zaimplementować profil UML w wybranym Z uwagi na fakty i argumenty przedstawione do modelowania narzędziu. powyżej, zanim rozpoczniemy modelowanie Uwzględnienie powyższych rekomendacji procesów w UML warto: wiąże się z pewnym nakładem pracy i cza• określić cel modelowania procesów i sposób su, który można traktować jako „inwestycję” wykorzystania modeli - inną specyfikę mają mającą na celu obniżenie prawdopodobieńmodele dedykowane do podejmowania de- stwa materializacji ryzyka związanego z wykocyzji biznesowych, modele związane z proce- rzystywaniem UML do modelowania procesami produkcji i modele tworzone w kontek- sów biznesowych. ście budowy systemów informatycznych; • zidentyfikować i ocenić otoczenie przedsięwzięcia, w ramach którego będę modelowane procesy, jego kluczowe uwarunkowania i ograniczenia; • zidentyfikować interesariuszy produktów modelowania, określić ich perspektywy patrzenia na procesy biznesowe oraz poziom wiedzy w zakresie analizy i modelowania proTomasz Gzik - Menadżer i doradca IT, pracownik akademicki Zorientowany na skuteczne i efektywne budowanie, optymalizowanie, wdrażanie procesów biznesowych, strategii IT, rozwiązań informatycznych oraz zespołów. Doświadczenie zdobywał pracując m.in. w IBM Polska, Biurze Informacji Kredytowej, ABG (aktualnie Asseco), Ubezpieczeniowym Funduszu Gwarancyjnym, jako programista, analityk, kierownik projektów, dyrektor IT, dyrektor ds. rozwoju i zarządzania portfelem projektów. Absolwent i pracownik Wydziału Cybernetyki Wojskowej Akademii Technicznej w Warszawie. Współpracuje z Wyższą Szkołą Technologii Informatycznych w Warszawie. Pomysłodawca i założyciel portalu BPMstandard.pl, który dedykowany jest zagadnieniom związanym z zarządzaniem procesami biznesowymi i systemami IT. Prywatnie mąż, ojciec, kibic i amator sportu.

Jarosław Łojewski

Inżynieria Oprogramowania

BRM, czyli Budowniczy Relacyjnych Mostów między IT i Biznesem.

Wprowadzenie

pozyskać informacje dotyczące wpływu nowych pomysłów biznesowych na usługi lub systemy IT.

usiness Relationshp Manager (BRM, pol. Menedżer ds. Relacji z Klientem Jak doszło do powstania roli Wewnętrznym) to łącznik między dziaBRM-a? łem IT organizacji a jednostkami biznesowymi, które wspiera (w skrócie: Biznesem). Jego praca nie ogranicza się tylko do prze- Jak to najczęściej bywa – z potrzeby, w tym kazywania wiadomości między tymi grupami. przypadku zrodzonej na styku IT i Biznesu. W dużych Głównym celem Rola BRM-a to z jednej organizacjach, pracy BRM jest upewnienie się, strony ktoś w rodzaju liczących tysiące osób, z mocno że IT wykorzystuje wewnętrznego konsultanta rozbudowanymi swój potencjał, IT, aby jak najlepiej po stronie biznesu z zakresu technologii działami wspierać zada- czy usług IT. To pojedynczy punkt kontaktu okazało się, że potrzebna jest nia biznesowe. To Biznesu z IT w sprawach nietypowych czy rola łącząca również odnajdycoraz bardziej wanie po stronie niezdefiniowanych w usługach IT. specjalizujące IT zasobów, osób czy zespołów oraz wskazywanie rozwiązań, się IT z poszukującymi nowych rozwiązań które będą właściwe do efektywnej realizacji zespołami biznesowymi. Jak to ładnie opisał Doug Blacker, wieloletni BRM w dużej firmie konkretnych zadań na rzecz Biznesu. z branży finansowej: BRM powinien być pierwszym punktem kontaktu biznesu z IT. Wówczas odpada „W momencie, gdy IT staje się coraz bardziej po stronie biznesu problem, z kim porozmawiać o jakiejś sprawie, wyspecjalizowane, do kogo zwrócić się z prośbą o konsultacje pojawia się coraz więcej wątpliwości, z kim, dotyczące technologii czy w jaki sposób w jakiej sprawie powinien się kontaktować 12

czy konsultować. <<Gdzie kucharek sześć tam nie ma co jeść>>. A kuchnia, która ma jednego szefa, koordynującego pracę wielu kucharzy dostarcza lepsze jedzenie niż w sytuacji, gdy z każdym z kucharzy klienci rozmawiają osobno. Podobnie jest w IT. Biznes ma możliwość lepszej współpracy w IT, kiedy może kontaktować się z jedną osobą – z Business Relationship Managerem, koordynującym działania dla określonego obszaru biznesu.” I podobnie jak szef kuchni, który nie przygotowuje sam wszystkich potraw (bo wówczas tworzyłyby się zatory w realizacji zamówień), BRM nie realizuje samodzielnie większości zadań. Jego rolą jest przede wszystkim znaleźć po stronie IT osoby, które podejmą temat i doprowadzą go do końca.

Aby to zrobić musi np. wyjaśnić z osobą proszącą o wsparcie, jakie są jej oczekiwania, co chce osiągnąć, czego potrzebuje. Wówczas znajduje specjalistów, którzy odpowiadają za dany obszar czy rodzaj działań i kontaktuje ich ze zgłaszającym.

Jak oceniać jakość pracy BRM-a? Przede wszystkim oceniając poziom satysfakcji z jego pracy – tak ze strony biznesowej jak i po stronie IT. Można na przykład przeprowadzać badania zadowolenia z pracy BRM-a korzystając z ankiet . Inną metodą mogą być uzgodnione metryki. Jednak przy ich definiowaniu i stosowaniu należy zwrócić uwagę, że praca BRM to przede wszystkim relacje, a nie liczby.

Dlatego ciężko zdefiniować KPI (ang. Key Performance Indicators – kluczowe wskaźniki efektywności ) bazujące na przykład na ilości obsłużonych spraw czy czasie ich realizacji. Czasami zidentyfikowanie obszaru, do którego ma trafić jakaś typowa sprawa biznesowe może być bardzo proste. Z kolei przy nietypowych sprawach, które są częstym obszarem wspieranym przez BRM, może być wymagany spory nakład pracy związanej np. z wyjaśnieniem rzeczywistych potrzeb i znalezieniem pomysłu na ich zaspokojenie. Ciekawym wskaźnikiem jakości pracy BRM może być np. porównanie kosztów rozwiązań, które pomaga znaleźć do korzyści, które z nich płyną. Janusz Stankiewicz, dawny CIO w GE Money Bank, który jako jeden z pierwszych w Polsce zadecydował i powołaniu takiej roli, pół-żartem określił swoje podejście do oceny

pracy BRM-a mniej więcej takimi słowami: „Ma odrzucać jak najwięcej pomysłów biznesowych i zdejmować mi z głowy jak najwięcej spraw związanych z dyskusjami z biznesem.”. Pierwsza część nie oznaczała bynajmniej ustawienia jakiegoś „wskaźnika odrzuceń”, ale zobowiązywała BRM-a do weryfikowania pomysłów biznesowych pod kątem korzyści, które może przynieść ich realizacja w stosunku do kosztów rozwiązań, które mogą czy też muszą być zastosowane. A druga część zdania to nic innego jak przeniesienie części zadań CIO właśnie na BRM-a. W szczególności w obszarze ustalania i egzekwowania zasad współpracy czy (w dużym uproszczeniu) rozwiązywania konfliktów między IT i Biznesem. Rola BRM-a może być przydatna nie tylko w dużych, rozwiniętych organizacjach, ale też w średnich. Jeśli CIO nie ma wystarczająco czasu na zajmowanie się wszystkimi sprawami na styku IT i Biznesu, jeśli widać, że nie dzieje się dobrze w takim obszarze, jeśli Biznes nie rozumie jak działa IT i dlaczego podejmuje takie a nie inne decyzje, jeśli IT ma podobną percepcję Biznesu – to według mnie najlepsza wskazówka, aby powołać taką rolę w organizacji. Może ją pełnić jedna osoba w całej firmie, jako jedno z dodatkowych zadań, a może też (kiedy

jest to potrzebne) powstać zespół BRMów, z których każdy jest odpowiedzialny za współpracę ze ściśle zdefiniowanym obszarem Biznesu.

Jaką wartość rola BRM daje działowi IT? Ponieważ BRM to łącząca potrzeby IT i biznesu, to w swoim zakresie prac ma też zadania wspierające działania IT. Jest to na przykład informowanie IT o strategii czy pomysłach biznesowych z dużym wyprzedzeniem tak, aby można było na nie zareagować odpowiednio dopasowując strategię IT czy też dbając o zarezerwowanie potrzebnych zasobów. BRM bierze udział w pracach nad tworzeniem strategii i taktyki działania IT, aby była ona dostosowana do bieżących i przyszłych potrzeb biznesowych. Proponuje usprawnianie pracy działów IT, które są najbardziej wystawione na kontakt z klientem (w tym np. Service Desk-u czy analityków IT), aby te kontakty były jak najbardziej efektywne i partnerskie. Pomaga w rozwiązywaniu nieporozumień czy konfliktów między IT a biznesem. Czasami podejmuje ad hoc decyzje „za biznes” czy „za IT” - w sytuacjach, kiedy takowe były potrzebne natychmiast, bazując na swojej wiedzy dotyczącej technologii i procesów biznesowych. Lista zadań BRM-a będzie specyficzna dla danej organizacji - jej poziomu rozwoju, obecności bądź braku innych ról (jak np. SLM), wielkości firmy czy też zmieniających się potrzeb. Dlatego ważne jest „wbudowanie” w tę rolę ciągłego strojenia - dostosowywania zakresu i sposobu pracy.

Z kim można porównać BRM-a? Rola BRM-a to z jednej strony ktoś w rodzaju wewnętrznego konsultanta po stronie biznesu z zakresu technologii czy usług IT. To pojedynczy punkt kontaktu Biznesu z IT w sprawach nietypowych czy niezdefiniowanych w usługach IT. To też pewna odmiana Key Account Managera (w sprzedaży – osoba odpowiedzialna za opiekę nad kluczowymi klientami biznesowymi firmy), który reprezentuje IT wobec klienta wewnętrznego – czyli wspomnianego Biznesu. Opiekuje się wyznaczonym obszarem organizacji (w mniejszych - może całą), kontaktuje się z szefostwem czy osobami decyzyjnymi w tym obszarze, pomaga w budowaniu zasad współpracy i oferty IT, która będzie atrakcyjna dla Biznesu. Opisywana rola ma w sobie również zakres prac analityka IT czy Service Level Managera. W dojrzałych organizacjach, w których praktycznie wdrożono ITIL czy metodykę projektową, rola BRM-a powinna być precyzyjnie zdefiniowana tak, aby nie dublował działań SLM-a czy analityków, ale w inteligentny sposób je uzupełniał. W mojej praktyce miałem umowę z SLM skonstruowaną tak, aby było wiadomo: • kto i za jaki zakres z biznesem odpowiada,

współpracy

• kiedy i jak przekierowuje niewłaściwie skierowane do naszych ról zapytania od naszych klientów (nie odbijając do biznesu, ale robiąc to bezpośrednio), • co powinniśmy dostarczać sobie wzajemnie, • kiedy i jakimi informacjami mieliśmy się 15

dzielić. Podobnie w obszarze analizy IT – jako BRMowie odpowiadaliśmy za dostarczenie przez biznes dobrze opisanej potrzeby biznesowej (Business Case), dobrze określonych, typowo biznesowych wymagań (w tym np. map procesów – stanu obecnego i planowanego lub innych materiałów, potrzebnych do analizy u uruchomienia projektu). W zakresie projektowym działaliśmy przede wszystkim w obszarze opisanym przez np. PRINCE2 jako proces „Przygotowanie projektu”, przekazując projekt na późniejszych etapach w ręce (najczęściej proponowanego przez nas) Project Managera z działu IT. Rola BRM-a przypomina momentami nieco rolę dyplomaty. Wzywany jest często w sytuacjach, w których wymagana jest jednocześnie delikatność i zdecydowanie oraz równoczesne dbanie o interesy IT i Biznesu. Dlatego ważne jest, aby na tej pozycji pracowały osoby, do których zaufanie mają wszystkie jednostki w organizacji. Jak się zapewne domyślacie czasami trudno znaleźć odpowiedniego kandydata. Wynika to często z faktu naturalnego napięcia między „dostawcą” (IT) a „klientem” (biznesem) – bo wciąż właśnie z takiej perspektywy postrzega się te obszary w bardzo wielu firmach. Rolą BRM-a jest budowanie mostów między

tymi obszarami. Celem jego działania jest zbudowanie platformy porozumienia – prowadzi mediacje, tworzy i rozwija zasady współpracy, dopasowuje sposób komunikacji obu stron tak, aby jak najlepiej się porozumiewały. Stara się, aby wszyscy byli „po jednej stronie”. Biznesowi tłumaczy zasady działania organizacji IT, stosowane technologie i możliwości ich wykorzystania – językiem biznesowym. Pracownikom IT opowiada o działaniu biznesu, jego planach i potrzebach, które technologia ma zaspokoić – językiem IT.

Czym się powinien charakteryzować dobry kandydat na BRM-a? Powinien reprezentować kombinację praktycznej wiedzy technicznej, umiejętności jej zastosowania i jednocześnie musi wiedzieć, jak działa biznes, z którym współpracuje – jak i do czego używa systemów IT, jakie ma potrzeby i zastrzeżenia, jak wspiera swoich klientów. Konkretna wiedza i umiejętności BRM-a powinny wynikać ze specyfiki organizacji, które wspiera. W mniejszej firmie powinien znać całość działalności biznesowej i jej specyfikę oraz mieć wiedzę na temat istniejących rozwiązań IT (systemów, usług).

W dużych organizacjach może funkcjonować kilkuosobowy zespół BRM, którego każdy członek będzie wspierał tylko wybrane obszary działalności biznesowej i będzie miał większą wiedzę na temat systemów dotyczących tej części.

jest bardzo wyczerpująca i mocno angażująca - nie da się wykonywać tylko w określonych godzinach i w szablonowych ramach. Dużo pracy, sporo nerwów i dużo, dużo satysfakcji z rezultatów, które można osiągnąć budując mosty między IT a biznesem.

Kogo najlepiej dedykować do roli BRM-a? Z mojej praktyki wynika, że pasują do niej najlepiej Project Managerowie lub analitycy IT, którzy pracowali przy projektach dla obszaru biznesowego, z którym mają współpracować. Jeśli są to osoby, do których biznes ma zaufanie, z którymi lubi pracować i do tego podobnie są postrzegane po stronie IT, to są one najlepszymi kandydatami do takiej roli.

Jeśli intryguje Ciebie, droga Czytelniczko czy drogi Czytelniku rola BRM-a i chcesz dowiedzieć się czegoś więcej na jej temat, zapraszam do kontaktów via LinkedIn. W miarę możliwości postaram się odpowiedzieć na Twoje pytania.

Pracowałem w roli BRM-a i potem szefa zespołu BRM-ów około 10 lat. Było to czas niezwykłej przygody, intensywnej nauki tego, jak działa biznes i IT, jak powinny wyglądać relacje między tymi obszarami, jaki wpływ na nią mają miękkie aspekty, sposób komunikacji czy podejście do sytuacji kryzysowych. To był czas dużego rozwoju osobistego, poznawania meandrów pracy menedżera IT oraz menedżerów biznesowych. Praca BRM Jarosław Łojewski - Specjalizuję się w coachingu biznesowym, rozwoju osobistego oraz kreatywności. Pracuję bazując na doświadczeniu wyniesionym z pracy w roli managera w międzynarodowej korporacji, certyfikowanych szkoleniach oraz kilkuletniej praktyce coachingowej. Stosuję indywidualne, holistyczne podejście, zgodne z metodyką CoachWisetm. Umożliwia ono managerom szybsze osiągnięcie celów, skuteczne mierzenia się z wyzwaniami biznesowymi oraz rozwinięcie niezbędnych kompetencji. Jako coacha, doradcę, mentora i trenera kadry zarządzającej, wyróżnia mnie wieloletnia praktyka managerska. Od 1991 roku zajmuję się budowaniem zespołów i zarządzaniem nimi tak, aby skutecznie realizowały wyznaczone cele. Realizowałem cele definiowane przez moich przełożonych lub klientów, jak również definiowałem cele i egzekwował ich wykonanie. Wieloletnia praca w spółkach należących do koncernu General Electric pozwoliła mi na zdobycie szerokiego spojrzenie na pracę i rolę managerów. Teoretyczna i praktyczna wiedza dotycząca metod usprawniania pracy zespołów i optymalizacji procesów (SixSigma, Lean Management) oraz bieżący kontakt z managerami na różnych szczeblu, do zarządów przedsiębiorstw i rad nadzorczych włącznie, dały mi unikalną wiedzę na temat wyzwań i oczekiwań stawianych przed managerami. Dały mi także wiedzę o ich wątpliwościach, problemach i potrzebach rozwojowych. W efekcie dysponuję unikalną wiedzą pozwalającą na efektywne wspieranie potrzeb rozwoju kadry managerskiej każdego szczebla.

Inżynieria Wymagań Hanna Wesołowska

Analiza wpływu zmian wymagań

zakres prac do realizacji.

Tak można by zrobić w świecie idealnym – w prawdziwym istnieje presja rynku i klientów oraz – nierzadko bardzo silna i pomysłowa – konkurencja. Odmowa wprowadzenia istotnych z punktu klienta zmian, oznaczałaby dla dostawcy rozwiązania nieprzyjemne skutki Warunki zewnętrzne i wewnętrzne wymuszają uboczne. na organizacjach pewien stopień elastyczności, niezbędny do zapewnienia ciągłości Jak więc wprowadzać zmiany, aby nie zadziałania i konkurencyjności oferty. Zmiana skakiwały nas ich nieprzewidziane konsejest więc nieunikniokwencje? Jak ocena. Skupmy się na zięki śledzeniu nić całościowy koszt typowych projekpowiązań można wprowadzenia motach informatyczkontrolować zmianę, dyfikacji? nych, gdzie zwykle jej zakres i ryzyko, uwzględniając większość modyfikaSposób wszystkie elementy, na które cji dotyczy zakresu na zmiany dana modyfikacja może – wymagań i powią- analiza mieć wpływ. zanych z nimi artewpływu faktów. W zależności od etapu projektu, zmiany mogą Analitycy sięgają w takich przypadkach być proste do analizy i wprowadzenia, lub też po analizę wpływu. Cytując słownik ISTQB obarczone ogromnym ryzykiem destabilizacji [6], analiza wpływu to oszacowanie zmiany systemu. w dokumentacji projektowej, testowej oraz ie od dziś wiadomo, że w IT jedyną pewną rzeczą jest zmiana. Zmieniają się wymagania, technologie, nawet cele strategiczne organizacji. Bez zmian nie ma biznesu.

Oczywiście najłatwiej byłoby wstrzymać wprowadzanie zmian i przyjąć stabilny, stały 18

Podczas wykonywania analizy zmiany, należy uwzględnić [1]:

Analiza wpływu zmian jest procesem:

• Korzyści – w jaki sposób zmiana podniesie wartość rozwiązania w kontekście celu biznesowego

(1) Identyfikacji potencjalnych skutków zmiany lub szacowania, co musi być zmodyfikowane, aby dokonać zmiany. (2) Oceny wielu zagrożeń związanych ze zmianami, łącznie z oszacowaniem wysiłku, wpływu na zasoby i harmonogram.

Karolina Zmitrowicz

Wprowadzenie

Nieco szerszą i pełniejszą definicję podaje REQB [2]:

zmian w modułach systemu, koniecznych do implementacji żądanej zmiany wg określonych wymagań.

Jednym zdaniem – analiza wpływu ma na celu określenie skutków wprowadzanych modyfikacji na interesariuszy, projektu i systemu oraz wszelkie inne artefakty związane z docelowym produktem. Po co wykonywać analizę wpływu? Można przecież szacować „na oko”. Można, jednak wtedy łatwo o przeoczenie, co prowadzi do nieprzyjemnego zaskoczenia rozmiarem zmian w fazie wytwarzania i niespodziewanymi błędami w innych modułach podczas testowania. Chcielibyśmy uzyskać wiarygodne i mierzalne informacje czy zmiana nie spowoduje niepożądanego działania innych części rozwiązania oraz ocenę opłacalności wprowadzenia zmiany. Niektóre z nich mogą wiązać się ze zbyt rozległymi i kosztownymi modyfikacjami, a wartość wynikająca z wprowadzenia zmiany nie uzasadnia poniesionych nakładów. Niezwykle przydatnym narzędziem do analizy zmian jest śledzenie powiązań między wymaganiami i innymi artefaktami (jak elementy diagramów, przypadki testowe, projekty interfejsów czy implementacji, kod, dokumenty, itp.). Dzięki śledzeniu powiązań można kontrolować zmianę, jej zakres i ryzyko, uwzględniając wszystkie elementy, na które dana modyfikacja może mieć wpływ.

wpływu

• Koszty – całkowity koszt wprowadzenia zmiany, łącznie z kosztem prac związanych z modyfikacją powiązanych elementów • Wpływ – skutek wprowadzenia zmiany na działalność klientów i funkcjonowanie procesów biznesowych • Plan – wpływ zmiany na istniejące zobowiązania związane z terminem dostarczenia rozwiązania lub składników docelowego produktu • Pilność – inaczej priorytet wprowadzenia zmiany. Pilność wynika zwykle z istotności zmiany dla interesariuszy, w szczególności z konieczności spełnienia wymagań prawnych, środowiskowych czy bezpieczeństwa. Warunkiem początkowym wykonania analizy wpływu i w ogóle możliwości kontrolowania zakresu przedsięwzięcia jest posiadanie aktualnej listy wszystkich wymagań – na wszystkich poziomach. Dla przypomnienia, zgodnie z klasyfikacją BABOK wyróżniamy następujące typy wymagań [1]: • Wymagania biznesowe • Wymagania użytkowników • Wymagania rozwiązania: o Wymagania funkcjonalne o Wymagania jakościowe • Wymagania przejścia na nowe rozwiązanie Przykłady poszczególnych przedstawia Tabela 1.

wymagań

Rys 1 Poziomy wymagań

Wymagania wchodzą ze sobą w różnego rodzaju relacje zależności. I tak na przykład wymagania niższego poziomu wywodzą się z wymagań wyższego poziomu, np. wymagania funkcjonalne wywodzą się z wymagań użytkowników, a te z kolei muszą być spójne z wymaganiami biznesowymi. Innym przykładem zależności są powiązania istniejące pomiędzy wymaganiami tego samego poziomu - pomiędzy różnymi przypadkami użycia. Dobrym przykładem celu śledzenia wymagań i wynikających z tego konsekwencji jest

interpretacja Karla Wiegersa, jednego z najbardziej cenionych specjalistów inżynierii wymagań. Diagram przedstawia przykład ewolucji artefaktów systemowych – wychodząc od wymagań biznesowych opisanych w dokumencie wizji i zakresu, poprzez wymagania użytkownika opisane jako przypadki użycia i wymagania jakościowe, aż do finalnego wyniku analizy wymagań: specyfikacji wymagań na oprogramowanie. Wizualizacja Karla Wiegersa jest poglądowa – przedstawia pewien sposób organizacji powiązań na wysokim poziomie, nie wyjaśniając jednak, w jaki sposób należy te powiązania realizować w rzeczywistych przypadkach.

Rys 3 Diagram wymagań, opracowanie własne między wymaganiami?

Inną formą śledzenia powiązań jest zastosowanie macierzy RTM (ang. Requirements Podstawową formą śledzenia powiązań jest Traceability Matrix) przedstawiającej powiąpodanie w specyfikacji w opisach wymagań zania pomiędzy artefaktami w postaci tabeidentyfikatorów wymagań powiązanych. larycznej.

Z tego powodu warto przedstawić wykorzystanie tej koncepcji na konkretnym przykładzie. Diagram wymagań (Rys 3) przedstawia przykład wizualizacji zależności pomiędzy konkretnymi wymaganiami – na niższym poziomie abstrakcji.

Rys 2 Ewolucja wymagań Karl Wiegers, www. processimpact.com [4]

Analiza wpływu polega na wskazaniu wszystkich elementów (m.in. wymagań, przypadków użycia), na które wprowadzana zmiana może mieć wpływ. Pojawia się pytanie, w jaki sposób można tę analizę wykonać i jak śledzić powiązania

macierz RTM oraz zidentyfikować powiązane elementy w narzędziu lub wygenerowanej dokumentacji systemu.

Ważnym elementem umożliwiającym odpowiednie zaplanowanie i utrzymanie śledzenia, jest opracowanie struktury modelu. Przykładową strukturę pakietów dla modelu analitycznego przedstawia poniższy rysunek.

Rys 6 Przykład relacji na diagramie wymagań. Źródło: [5]

Rys 4 Powiązania w macierzy śledzenia wymagań. Źródło: [5] Rys 8 Struktura pakietów w projekcie. Opracowanie własne Enterprise Architect umożliwia śledzenie poprzez różnego rodzaju relacje pomiędzy elementami modelu. Przykładowe relacje śledzenia mogą obejmować powiązania pomiędzy następującymi artefaktami: Rys 7 Przykład relacji śledzenia od wymagań klienta do systemowych przypadków użycia. Źródło: [5]

• Cele biznesowe i potrzeby biznesowe • Potrzeby biznesowe i wymagania biznesowe

Śledzenie w Enterprise Architect

Rys 5 Przykład realizacji macierzy wymagań w narzędziu IBM RequisitePro. Źródło: [5] Ostatnią wartą wspomnienia formą śledzenia jest zastosowanie możliwości narzędzi CASE. Wiele profesjonalnych programów wspierających modelowanie w UML, SysML czy innych popularnych notacjach, umożliwia tworzenie powiązań pomiędzy elementami modelu. Powiązania 22

te reprezentują różne formy zależności – od prostej asocjacji, po relacje realizacji, zależności i inne. Korzyścią wsparcia narzędziowego jest nie tylko wizualizacja powiązań ułatwiająca analizę zależności i zwiększająca przejrzystość modelu. Możemy automatycznie wygenerować

Analiza wpływu, jak i samo śledzenie powiązań oraz organizacja prac analitycznych i ich produktów może być wsparta przez różne narzędzia. W niniejszej publikacji przedstawimy podstawowe możliwości narzędzia Enterprise Architect – profesjonalnego narzędzia dla analityków i projektantów umożliwiającego między innymi modelowanie zagadnienia biznesowego i różnych aspektów rozwiązania.

• Wymagania biznesowe i elementy procesu biznesowego • Wymagania biznesowe i przypadki użycia • Przypadki użycia i klasy (dane) • Przypadki użycia i prototypy GUI • Przypadki użycia i przypadki testowe Przykład relacji poniższy rysunek.

śledzenia

przedstawia

Pracę z narzędziem rozpoczynamy nie od diagramów, czy listy wymagań, ale od stworzenia ram procesu analitycznego. 23

Wizualizacja powiązań to jedna kwestia – kolejną jest wsparcie analizy wpływu. W momencie zaistnienia konieczności wprowadzenia zmiany, pojawia się pytanie – jak powiązane są wszystkie elementy w modelu?

między wymaganiami czy klasami), ale i powiązania między różnymi warstwami modelu – czyli śledzenie.

• Traceability Window – okno śledzenia,

W rzeczywistych projektach wzorzec ten można niemal dowolnie rozszerzać, uwzględniając poziom celów i czynności w procesach biznesowych, struktury modelu danych, itd. Na szczególną uwagę zasługuje diagram śledzenia zależności. Do jego stworzenia można wykorzystać typ diagramu Extended -> Custom. Przedstawienie na nim elementów różnych typów i powiązanie ich relacją Trace umożliwia wykorzystanie np. narzędzia Relationship Matrix, pokazującego zależności między wybranymi rodzajami elementów, czy np. Traceability Window, które pokazuje wszystkie zależności każdego typu dla zaznaczonego elementu.

W poniższym przykładzie zrealizowano śledzenie na poziomach: W Enterprise Architect dostępne są następu- • Wymagań jące możliwości wykorzystania funkcji śledze- • Przypadków użycia nia: • Logicznym (klasy)

• Relationship Matrix – macierz relacji, • Relationships Window – okno relacji,

Rys 9 Przykład śledzenia pomiędzy przypadkami użycia a wymaganiami. Opracowanie własne Analiza powiązań na modelu to jedna z możliwości wizualizacji zależności i wykonywania późniejszej analizy wpływu. Innym sposobem przedstawienia powiązań między elementami jest macierz śledzenia.

• Wybierz źródło (pakiet) oraz typ artefaktów do śledzenia

W Enterprise ją następująco:

• Wybierz kierunek powiązania

Architect

tworzy

się

• Wybierz rodzaj powiązania np. realization lub dependency

• Dependency Report – report zależności, • Implementation Report – raport implementacji. Wizualizację powiązań i zależności pomiędzy artefaktami projektowymi przedstawia poniższy diagram. Warto zwrócić uwagę na to, iż na diagramie przedstawiono nie tylko zależności pomiędzy samymi artefaktami (jak po-

• Wybierz opcję Refresh

• Menu > Tools > Relationship Matrix

Rys 10 Przykład macierzy śledzenia w narzędziu Enterprise Architect. Opracowanie własne 24

Rys 11 Przykładowy diagram zależności. Źródło: [3]

do wykonania podstawowej analizy wpływu wystarczy przejrzysta struktura wymagań, śledzenie powiązań i umiejętność analizy informacji. Wystarczy więc przemyślany proces, minimalne wsparcie narzędziowe/ proceduralne i wiedza. Korzyścią z poznania sposobów analizy wpływu jest nabycie możliwości kontrolowania zakresu projektu oraz prognozowania konsekwencji wprowadzanych modyfikacji. Tym samym dajemy sobie szansę na minimalizację ryzyka związanego ze zmiennością wymagań i warunków zewnętrznych. Otrzymujemy także narzędzie do wiarygodnej, opartej na faktach analizy konsekwencji, zakresu i kosztu wprowadzanych zmian umożliwiające sprawne podejmowanie decyzji.

[3] Sparx Systems: Traceability tools, [online]. Dostępne: http://www.sparxsystems. com/enterprise_architect_user_guide/10/ navigate_search_and_trace/traceability_ tools.html [4] Karl Wiegers: traceability, [on-line]. Dostępne: www.processimpact.com [5] Bartosz Chrabski, Karolina Zmitrowicz, “Inżynieria wymagań w praktyce”, PWN 2014 [6] Słownik ISTQB [7] Sparx Systems: Create Traceability diagrams, [on-line]. Dostępne: http://www. sparxsystems.com/enterprise_architect_ user_guide/10/navigate_search_and_trace/ create_traceability_diagrams.html

Bibliografia: [1] International Institute of Business Analyst IIBA, A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3.0, 2015. [2] REQB Foundation Level Syllabus, v2.1 Rys 12 Przykład diagramu śledzenia. Opracowanie własne

Podsumowanie Analiza wpływu nie musi być niemożliwa, trudna ani wyjątkowo czasochłonna. Istnieją ogólne i proste w zastosowaniu zasady wspierające szacowanie wpływu zmian na

projekt – wystarczy je poznać i nauczyć się je stosować. W wielu przypadkach nie jest nawet konieczne wsparcie komercyjnego narzędzia do zarządzania/modelowania wymagań –

Hanna Wesołowska- Analityk biznesowy z 6 letnim doświadczeniem. Brała udział w projektach polskich i zagranicznych, jako jedyny analityk, analityk wiodący oraz członek kilkudziesięcioosobowego zespołu analityków. Projekty dla sektora prywatnego (transport, telekomunikacja, bankowość i inne) i publicznego. Członek Zarządu Polskiego Oddziału IIBA ds. Edukacji i Rozwoju Zawodowego. Członek Stowarzyszenia Inżynierii Wymagań. Prowadziła zajęcia na Politechnice Gdańskiej z Inżynierii Oprogramowania i Zarządzania Projektem Informatycznym oraz na WSB. Absolwentka informatyki na Politechnice Gdańskiej (specjalność Inżynieria Systemów i Bazy Danych) oraz Psychologii w biznesie. Certyfikaty Agile Project Management Foundation, PSM I (Professional Scrum Master), ITIL Foundation, PRINCE2 Practitioner. Autorka artykułów dla REQ Magazyn, Analizy Biznesowej IIBA, Gazety Bankowej, Gazety Ubezpieczeniowej. Prelegentka na konferencjach IIBA, NetVision, 3camp, UX Camp, Geek Girls Carrots. Autorka bloga o analizie biznesowej – www.analizait.pl 26

Karolina Zmitrowicz - Pracuje w branży IT od 10 lat. Posiada międzynarodowe doświadczenie w zakresie analizy biznesowej i inżynierii wymagań, zarządzania jakością i zarządzania projektami. Pracowała dla wiodących organizacji finansowych w Republice Południowej Afryki, Holandii, Austrii, Słowacji, Włoszech i w Polsce. Podczas swojej kariery pełniła różne role, od testera, poprzez analityka i projektanta, po koordynatora projektów, co umożliwiło jej poznanie wielu aspektów realizacji projektów IT i nauczyło postrzegania podejmowanych tematów z różnych punktów widzenia. Praca w międzynarodowych, wielokulturowych zespołach projektowych wykształciła w niej nie tylko umiejętności efektywnego planowania i koordynacji złożonych działań, ale i doskonałe umiejętności interpersonalne. Obecnie pracuje jako niezależny konsultant IT w obszarze biznesu i technologii wspierając organizacje m.in. w planowaniu i realizacji procesów analitycznych oraz czynności zarządzania jakością na przestrzeni całego cyklu życia rozwiązania. Zdobyte doświadczenie wykorzystuje jako podstawę do rozwoju własnych metod doskonalenia procesów wytwarzania kładąc nacisk przede wszystkim na transparentność, efektywność i spójność procesów z celami biznesowymi przy jednoczesnej elastyczności i uniwersalności zastosowanych rozwiązań. Karolina jest autorką kilkunastu publikacji z obszaru zarządzania jakością, testowania, analizy biznesowej i zarządzania zespołem oraz książek m.in. Inżynieria wymagań w praktyce (PWN 2014). Jest wykładowcą akademickim na WSB w Gdańsku na studiach podyplomowych na kierunku Tester oprogramowania oraz kierownikiem studiów podyplomowych na kierunku Inżynieria wymagań w projektach informatycznych. 27

Hanna Wesołowska

Inżynieria Wymagań

Czy znasz techniki, języki i narzędzia do modelowania

możliwość udzielenia wielu odpowiedzi oraz wybrania opcji, że nie używa się wspomagającego oprogramowania. Statystyki pokazują właśnie te narzędzia, które podkreślają specjalistyczny charakter naszej profesji. Na czołówkę wysuwają się dwa narzędzia do modelowania typu CASE. Czym różnią się od zwykłych programów do rysowania obrazków wyjaśniam na stronie [2]. Wyniki zaprezentowano wykresie słupkowym.

najpopularniejsze wśród analityków?

Wstęp

końcu nie musimy tłumaczyć kim jesteśmy i czym się właściwie zajmujemy. Przynajmniej w coraz większej liczbie polskich firm. W ostatnich latach przybyło wiele osób wykonujących zawód Analityka Biznesowego. Managerowie na rozmowach kwalifikacyjnych zaskakują już znajomością tematu i słów-kluczy, takich jak UML, Enterprise Architect, opisy przypadków użycia. Zdobyli także doświadczenie we współpracy z takimi jak my i oczekują od nas określonych kompetencji. Jako reprezentanci rozwijającego się zawodu, nie zawsze mieliśmy komu spojrzeć przez ramię na stosowane techniki. Często zastanawiamy się, czy robimy coś dobrze i jak to robią inni? Teraz rośniemy w liczebną siłę i czerpiemy z wiedzy o sobie nawzajem.

Podium zamyka miejsce trzecie – Visual Paradigm, którego używał w 2015 roku na poniższym podstawie [1] co czwarty analityk. Na pierwszy rzut oka niewiele różni się od Enterprise Architecta. Cechą wybijającą się najbardziej jest wyższa cena. Poza nią, w celu znalezienia różnic, mamy do porównania długą listę opcji obu narzędzi. Istotnymi cechami do porównania są także stopień zachowywania standardów poszczególnych notacji i ergonomia. Na marginesie odnotowujemy jeszcze inne spotykane narzędzia.

Uzyskane odpowiedzi dały wgląd, między innymi w to, jacy jesteśmy jako analityczna populacja i co potrafimy. Wyłoniło się jedno z ciekawych zagadnień – jakie najczęściej stosujemy techniki, języki i narzędzia do modelowania. Przyjrzyj się wynikowi badania i sprawdź, gdzie Ty umieściłbyś swoje umiejętności na widocznych wykresach? Musisz jeszcze się dokształcić, aby sprostać rynkowym standardom, czy może już wiesz i potrafisz więcej niż inni?

Narzędzia do modelowania

Podstawowymi narzędziami pracy analityka są Word i Power Point. A przynajmniej tak sądzi wiele postronnych osób. Odsłońmy jednak prawdziwe oblicze. Te narzędzia zakorzeniły się w naszej świadomości tak głęboko, że pomijamy je jako oczywistości. Podobnie Pod koniec zeszłego roku na blogu Analiza nie wspominamy o czystej kartce papieru IT przeprowadziłam Badanie Zarobków uwalniającej kreatywność. i Kompetencji Analityków Biznesowych 2015. Długą ankietę wypełniło cierpliwie 207 Jakie zatem oprogramowanie najbardziej analityków. Po szczegóły zapraszam na stronę wpiera nas w codziennej pracy – przy [1]. przygotowywaniu analitycznej dokumentacji i modeli? W ankiecie zadano pytanie: „Jakich używasz narzędzi do modelowania?”. Była 28

o dreszcze. Jeśli wszyscy członkowie zespołu wytwarzającego oprogramowanie nie odnoszą się do jednego modelu, każdy wyobrazi sobie dany aspekt projektu po swojemu. W zakładzie o to, że w takiej analizie roi się od przeoczeń i niedociągnięć, stawiam kwartalną wypłatę.

Kilkukrotnie pojawiło się słynne Visio do tworzenia prostych schematów i niepowiązanych ze sobą obrazków. Bizagi pozwala modelować procesy biznesowe [3]. W narzędziu Adonis przygotujemy także modele procesów [4]. Axure służy niektórym analitykom do tworzenia zaawansowanych i eleganckich prototypów interfejsów użytkowników projektowanego oprogramowania [5].

Rysunek 1 Najczęściej używane przez analityków w 2015 r. narzędzia do modelowania [źr. www.analizait.pl/badanie-zarobkow]

Tytuł najpopularniejszego narzędzia do modelowania używanego przez analityków biznesowych w Polsce w 2015 roku wg [1] otrzymuje… Enterprise Architect. Zawładnął naszym rynkiem w 55%.

Pytanie umożliwiało podanie wielu odpowiedzi, więc mogło być to jedno z wielu stosowanych narzędzi. Podawano je Techniki jednak zdecydowanie najczęściej. Połowa z nas wykonuje analizę w narzędziu Enterprise Co odróżnia analityka od stenotypistki? Między Architect. innymi to, że wynikiem jego pracy nie jest Martwi drugie miejsce na podium: 30% dosłowny zapis rozmowy z klientami i przyszłymi analityków nie używa żadnego narzędzia użytkownikami. Posiadamy sposoby, by do tworzenia analitycznych modeli! Projekt przetwarzać masę nieuporządkowanych bez ustalenia wspólnego punktu widzenia informacji na zadania do wykonania dla problemu w zespole, bez weryfikacji zespołów. Jak to robimy? Stosujemy techniki kompletności i spójności wymagań analityczne. oraz

projektu

rozwiązania,

przyprawia 29

wymagań. Jakbyśmy w projekcie byli odpowiedzialni jedynie za stawianie pytań. Jako analitycy oferujemy znacznie więcej, ale to prawda, że w przeprowadzaniu wywiadów nie mamy sobie równych (przynajmniej w branży IT).

Rysunek 2 Najczęściej używane przez analityków w 2015 r. analityczne techniki [źr. www.analizait.pl/badanie-zarobkow]

W badaniu [1] zapytano analityków jak oceniają swoją znajomość poszczególnych technik analitycznych w skali 0-5, gdzie 0 oznaczało brak znajomości, a 5 pełną biegłość i dużą częstotliwość wykorzystywania.

Wielu analityków ocenia swoje umiejętności na tym polu na tyle wysoko, że technika pozyskiwania wymagań za pomocą wywiadów ląduje na miejscu trzecim. Nie tylko „co?”, ale też „jak?” decyduje bardzo często o tym, czy rozwiązanie spełnia potrzeby użytkownika. Techniki identyfikowania i specyfikowania wymagań jakościowych, inaczej niefunkcjonalnych czy pozafunkcjonalnych, mamy także zawsze pod ręką w naszej narzędziowej skrzynce.

Zdolności wydobywania wymagań przez Po obliczeniu średniej znajomości technik, analityków nie ograniczają się jedynie wyłonione zostały techniki najbardziej znane do zadawania pytań. Potrafimy także analitykom biznesowym w Polsce w 2015 roku. organizować współpracę wielu interesariuszy, aby wypracowali wspólne rozwiązania. Pierwsze miejsce podium zdobyły opisy przypadków użycia. Stanowią one serce Warsztaty wymagań zakładają angażowanie naszej pracy oraz komunikacji z programistami całej grupy osób, które razem pracują i testerami. Pozwalają przedstawić z kolorowymi karteczkami, szarym papierem wymagania w ustrukturyzowanej formie i mazakami, nad określaniem procesów i dostarczają szczegółów istotnych z punktu widzenia członków zespołu do przygotowania oprogramowania. Na drugim miejscu pojawiają się metody modelowania i analizy procesów biznesowych. Nic dziwnego, bez nich brakowałoby nam informacji o tym, jak działa biznes i skąd biorą się takie a nie inne wymagania. Znakomicie, że robimy krok w tył (ku źródłom), by móc wykonać pewniejszy i bardziej skuteczny krok w kierunku rozwiązania. „Pojedziesz i pozadajesz im jakieś pytania” – pojawiają się niekiedy takie polecenia przełożonych, kiedy trzeba wykonać analizę 30

biznesowych, wymagań, przydzielaniem od tego, co chcemy wyrazić, sięgamy po priorytetów, tworzeniem wizji rozwiązania. odpowiedni język modelowania. A my krążymy po sali w roli moderatora Trzech na czterech analityków [1] potrafi i organizatora. Trudno oczekiwać, żeby nasi posługiwać się językami UML i BPMN. klienci, np. pani księgowa po przeczytaniu opisu przypadków użycia miała zawsze takie samo wyobrażenie projektowanej aplikacji jak my – specjaliści od IT. Problem rozwiązuje zaprezentowanie rozwiązania w formie zbliżonej do tego, co zobaczy ona na końcu etapu wytwarzania – interfejsu użytkownika. Człowiekowi łatwiej jest zrozumieć wnioski z analizy w takiej formie, dlatego często ilustrujemy prototypami to, co opisaliśmy bardziej wyczerpująco w wymaganiach.

Rysunek 3 Najczęściej używane przez analityków w 2015 r. języki do modelowania [źr. www.analizait.pl/ badanie-zarobkow]

Co prawda jest to statystyka oparta Na liście siedmiu najbardziej znanych na deklaracjach w ankiecie, a wśród technik analitycznych wg [1] nie mogło odpowiadających mamy zarówno tych, zabraknąć techniki mającej wiele wspólnego którzy potrafią wykonać proste diagramy, jak z metodykami Agile. i tych, którzy język znają od podszewki. Oto na miejscu siódmym pojawiają się Historyjki Użytkownika (ang. User Stories). Jest to uproszczony sposób zapisu wymagań funkcjonalnych podkreślający dla kogo i w jakim celu (korzyść dla użytkownika i biznesu) dana funkcja ma zostać dostarczona.

Cieszy jednak, że mamy bardzo dużą świadomość i używamy UML i BPMN w projektach, jak przypuszczam, w większości w narzędziach CASE.

Na popularność tych dwóch języków modelowania wpływać może, naturalnie, ich Przykład: Jako Czytelnik chcę pobrać nowy zastosowanie. numer REQ Magazyn, aby przeczytać najnowsze artykuły. Trudno wyobrazić sobie częściej spotykane modelowanie działania systemów Ciekawe, że jest to jednak technika, którą w czymś innym niż UML czy wygodniejsze opanowaliśmy w mniejszym stopniu niż opisy przedstawianie procesów biznesowych bez przypadków użycia. użycia BPMN.

Języki modelowania

Słyszymy o wielu szkoleniach poruszających te zagadnienia i coraz liczniejszych Język modelowania wyraża nasze myśli certyfikowanych specjalistach. Specyfikacje w sposób jednoznaczny. Modele pozwalają OMG są coraz częściej przeglądane porozumiewać się analitykom między sobą przez analityków. i ze światem zewnętrznym, a przynajmniej Niestety element grozy pojawił się także na tym z najbliższym otoczeniem – architektami, podium. 16% analityków nie używa żadnego programistami, testerami. W zależności 31

języka modelowania. Jak to robią? Oczywiście można zastąpić diagram dowolnym nieformalnym rysunkiem przedstawiającym pożądane właściwości specjalnie na tę okazję dobranymi symbolami, czy kolorami. Przydałaby się porządna legenda. O precyzji i oddziaływaniu takich tworów na projekt można by napisać kolejny artykuł.

Możesz teraz ocenić, na ile Twoje umiejętności wpisują się w rynkowe trendy. Musisz nadrobić zaległości czy może już potrafisz wszystko, co zostało wymienione w artykule? Warto przyjrzeć się także tym niewysokim słupkom na wykresach. Poznanie nowych technik poszerzy Twoje horyzonty i ułatwi rozwiązywanie problemów, które dziś, z racji niewystarczających zasobów, stanowią Wciąż rzadko spotykane jest posługiwanie spore wyzwanie. się innymi notacjami, takimi jak SysML (Systems Modeling Language), BMM (Business Motivation Model), SBVR (Semantics of Business Vocabulary and Rules) czy ArchiMate. Mają Źródła: one węższe zastosowanie, choć aspekty, 1. Analiza IT: Raport zarobków, [on-line]. jakie można nimi wyrazić (cele biznesowe, Dostępne: www.analizait.pl/raport-zarobkow/ słowniki, reguły biznesowe, wymagania i architektura korporacyjna), pojawiają się 2. Analiza IT: Traceability, czyli potęga narzędzi w każdym projekcie. Wymienione języki nie CASE, [on-line]. Dostępne: http://analizait. spopularyzowały się w naszym kraju powyżej pl/2014/traceability-czyli-potega-narzedzi7% używających ich analityków. A szkoda, bo case/ można dzięki nim uporządkować dodatkowe 3. Bizagi, [on-line]. Dostępne: http://www. aspekty analizy. bizagi.com SysML przyda się w uporządkowaniu wymagań na różnych poziomach szczegółowości. BMM 4. Adonis, [on-line]. Dostępne: https://uk.bocpozwoli uchwycić wizję, misję, strategię, group.com/adonis/ taktykę, cele i zadania organizacji, dla której 5. Axure, [on-line]. Dostępne: http://www. wykonywany jest projekt i sprawdzić, czy axure.com wpisuje się on w wyznaczone kierunki rozwoju. SBVR opanuje chaos w definicjach i uprości skomplikowane przypadki ujawniając reguły biznesowe. Dzięki ArchiMate uchwycisz i utrzymasz w ryzach architekturę korporacyjną. Hanna Wesołowska- analityk biznesowy w polskich i zagranicznych projektach, pracująca jako jedyny analityk, analityk wiodący oraz członek kilkudzięcioosobowego zespołu analityków. Projekty dla sektora prywatnego (transport, telekomunikacja, bankowość i inne) oraz publicznego. Członek Zarządu Polskiego Oddziału IIBA (International Institute of Business Analysis) ds. Edukacji i Rozwoju Zawodowego. Członek Stowarzyszenia Inżynierii Wymagań. Prowadziła zajęcia na Politechnice Gdańskiej z Inżynierii Oprogramowania i Zarządzania Projektem Informatycznym oraz na Wyższej Szkole Bankowej. Absolwentka informatyki na Politechnice Gdańskiej (specjalność Inżynieria Systemów i Bazy Danych) oraz Psychologii w Biznesie. Autorka artykułów dla REQ Magazyn, Analizy Biznesowej IIBA, Computer World, Gazety Bankowej, Gazety Ubezpieczeniowej. Prelegentka na konferencjach IIBA, NetVision, Be IT, 3camp, UX Camp, Geek Girls Carrots. Autorka bloga o analizie biznesowej (www.analizait.pl) oraz Kursu Adeptów Analizy. 32

Wydarzenie, podczas którego spotykają się początkujący jak również osoby z dużym doświadczeniem w swojej dziedzinie. Dzięki temu Konferencja Inżynierii Wymagań i Analizy Biznesowej staje się miejscem wymiany doświadczeń, czerpania inspiracji od innych, ale również miejscem tworzenia innowacyjnych rozwiązań na problemy napotykane w projektach. W pierwszej edycji konferencji organizowanej przez SIW wzięło udział ponad 100 uczestników, tym razem Ciebie nie może zabraknąć! II edycja konferencji organizowanej przez Stowarzyszenie Inżynierii Wymagań odbędzie się pod hasłem:„Podejmij wyzwanie inżynierii wymagań”. W obecnej edycji chcemy pokazać, że wyjście ze strefy komfortu w każdym z obszarów, który ma wpływ na jakość produktu, daje rewelacyjne rezultaty. Tematyka tej edycji kierowana jest do wszystkich, którzy czują się współodpowiedzialni za cele działań, elastyczność oraz szybkość i skuteczność przedsięwzięć IT: •Specjaliści agile, właściciele produktu w SCRUM •Analitycy biznesowi i systemowi, inżynierowie wymagań •Programiści, tworzący kod na podstawie wymagań •Kierownicy projektów, zarządzający nimi tak, aby w terminie zrealizować potrzebne wymagania Klientów •Prawnicy, zamawiający i dostawcy, borykający się z wpisaniem wymagań do umów cywilno-prawnych •Specjaliści BPM – zarządzania procesami biznesowymi •Testerzy, którzy muszą domyślać się prawdziwych wymagań, mając do dyspozycji ich niepełny i często nieprawdziwy opis.

WWW.KONFERENCJA.SIW.ORG.PL 33

Ewa Brzeska

Zarządzanie Projektami

Na styku biznesu i IT: MVP a wytwarzanie oprogramowania - Case Study

Wstęp

poprzednim numerze REQ Magazyn ukazał się mój artykuł pt. „Na styku biznesu i IT – Minimum Viable Product”. Po publikacji tego artykułu dostałam wiele pytań w jaki sposób praktycznie wyznaczyć MVP w przypadku, kiedy produktem jest oprogramowanie. Z tego typu pytaniem spotykam się też często w praktyce, podczas realizacji projektów informatycznych w ramach których wytwarzane jest oprogramowanie. Dziś zatem chciałabym kontynuować rozpoczętą wcześniej tematykę i pokazać na przykładzie, jak wyznaczyć Minimum Viable Product oprogramowania. Ponieważ, jak napisałam w poprzednim artykule, model MVP nadaje się świetnie do realizacji oprogramowania mobilnego i webowego, za przykład posłuży mi aplikacja mobilna.

Potrzeby inwestora, czyli początek Wyobraźmy sobie, że jedna ze znanych polskich marek odzieżowych, która ma w naszym kraju sieć sklepów tradycyjnych, chce wejść ze swoją ofertą na platformę mobilną, aby zwiększyć sprzedaż produktów marki w kraju 34

i za granicą. Potrzebna jest w związku z tym aplikacja mobilna, która umożliwi jej użytkownikom dokonywanie zakupów online. Podczas burzy mózgów managerowie marki odpowiedzialni za stworzenie mobilnej platformy zakupowej stworzyli następującą listę potrzeb i życzeń w stosunku do aplikacji mobilnej: • aplikacja ma być ładna i nowoczesna, • ma umożliwić szukanie odzieży wg rozmiaru i koloru, • kolorystyka aplikacji ma być jasna, • ubrania mają być podzielone wg kategorii: odzież damska / męska / dziecięca, • użytkownik aplikacji ma mieć możliwość obejrzenia filmów z pokazów marki, • aplikacja ma powiadamiać użytkownika o nowej kolekcji, promocjach, itp., • użytkownik ma mieć możliwość obejrzenia zdjęć każdego produktu, • aplikacja ma prezentować szczegółowy opis każdego produktu, • treści w aplikacji mają być prezentowane w wielu językach, • użytkownik ma mieć możliwość dokonania zakupu bezpośrednio w aplikacji, • aplikacja ma pokazywać użytkownikowi prognozę pogodny na najbliższe dwa tygodnie, aby zachęcić go do zakupów odzieży np. przed zbliżającym się upałem czy nagłym chłodem.

Powyższa lista uzyskała akceptację na najwyższym szczeblu Zarządu marki. Jednocześnie Zarząd przyznał na realizację projektu konkretny, ustalony budżet i zdecydował, że wdrożenie platformy mobilnej powinno nastąpić w nieprzekraczalnym terminie trzech miesięcy. Lista życzeń, określony budżet i czas i … co dalej?

Od potrzeb inwestora do MVP w siedmiu krokach Krok 1: Cel biznesowy

Krok 2: Główny cel produktu Następnym krokiem powinno być określenie głównego celu produktu – powstającego oprogramowania. W omawianym przypadku w opisie znajduje się fraza: „aplikacja mobilna (..) umożliwi jej użytkownikom dokonywanie zakupów online”. To co z punktu widzenia użytkownika aplikacji będzie zakupem, z punktu widzenia właściciela marki i jednocześnie inwestora projektu będzie sprzedażą. Powstające oprogramowanie będzie zatem aplikacją sprzedażową, a sprzedaż produktów marki – głównym celem oprogramowania.

Od czego zacząć mając taką jak wyżej lub podobną listę życzeń w stosunku do opro- Krok 3: Główny proces obsługiwagramowania, które ma być zrealizowany przez oprogramowanie ne w ramach projektu informatycznego? Szczególnie, jeśli czas na wykonanie i wdro- Wiemy już jaki jest cel biznesowy i główny cel żenie rozwiązania jest krótki, budżet skoń- samego produktu, mamy również sporzączony i niedzoną przez zbyt duży, inwestora a Klient projektu listę Zakres funkcjonalny MVP, to zestaw oczekuje jego życzeń funkcji], które stanowią absolutne „must w stosunku wymiernych korzy- have” powstającego oprogramowania. do oprograści biznesomowania. wych. Aby proces Tytułem wywytwórczy oprogramowania zakończył się jaśnienia: celowo i konsekwentnie używam pełnym sukcesem, powstałe oprogramowa- w stosunku do wyżej wspomnianej listy okrenie powinno przede wszystkim być skupione śleń „potrzeby” lub „życzenia”, a nie wymana konkretnym celu biznesowym, dla realiza- gania. Zgodnie z teorią inżynierii wymagań cji którego oprogramowanie to jest środkiem w inżynierii systemów i oprogramowania - pisałam na ten temat szerzej w artykule pt. każde wymaganie charakteryzuje się zespo„Na styku biznesu i IT: od potrzeby biznesowej łem cech takich jak: spójność, kompletność, do gotowego produktu – rozważania w kon- zgodność, jednoznaczność, poprawność, tekście inżynierii oprogramowania”, który uka- weryfikowalność, itd. Potrzeby i życzenia są zał się w pierwszym numerze REQ Magazyn. znacznie bardziej ogólne i najczęściej stanoPierwszy krok w procesie wytwórczym to za- wią jedynie punkt wyjścia do określania rzetem jednoznaczna identyfikacja celu bizne- czywistych wymagań. sowego przedsięwzięcia. Dla omawianego Sposób określania i opracowywania wymaprzykładu cel biznesowy to „zwiększyć sprze- gań na podstawie potrzeb użytkowników nie daż produktów marki w kraju i za granicą”. jest przedmiotem niniejszego artykułu. 35

Założyłam, że rozpatrzymy model uproszczony, opierający się na ogólnych potrzebach inwestora, który jest w pełni wystarczający dla prezentacji mechanizmów i ogólnego sposobu postępowania. Kolejny krok to zdefiniowanie głównego procesu, który będzie obsługiwany przez oprogramowanie. Jak już ustaliliśmy głównym celem aplikacji jest sprzedaż produktów marki, a jej użytkownicy mają dokonywać zakupów bezpośrednio w aplikacji. Głównym procesem obsługiwanym przez aplikację jest zatem proces zakupu. Typowy proces zakupu składa się z następujących etapów: • Etap I - uświadomienie potrzeby. • Etap II - poszukiwanie opcji. • Etap III - podejmowanie decyzji. • Etap IV zakup. Etapy procesu zakupu przedstawiono schematycznie na Rys. 1

przez ten produkt. W rozpatrywanym przykładzie poszczególnym etapom procesu przyporządkowano następujące główne funkcje aplikacji: • Etap I - uświadomienie potrzeby -> ?. • Etap II - poszukiwanie opcji -> Wyszukiwarka produktów. • Etap III - podejmowanie decyzji -> Prezentacja szczegółowych informacji o produkcie. • Etap IV – zakup -> Obsługa zakupu. Funkcje te zaprezentowano schematycznie na Rys. 2

Rysunek 2 Funkcje realizujące główne etapy procesu zakupu

Jak widać, do Etapu I (uświadomienie potrzeby) nie jest przypisana w tym momencie żadna funkcja produktu. Wrócimy do tego w dalszej części artykułu.

W naszym uproszczonym modelu podczas dekomponowania poszczególnych funkcji głównych posłużymy się listą życzeń i potrzeb inwestora względem aplikacji. Poniżej poszczególne potrzeby zdefiniowane przez inwestora, przyporządkowane do odpowiednich funkcji głównych – pierwszy krok w realizacji przyporządkowania.

Po dokonaniu powyższego przyporządkowania pozostało nam jeszcze szereg potrzeb, nie powiązanych z określonymi poprzednio głównymi funkcjami aplikacji. Czy to oznacza, że są one „niepotrzebne”? I że nie warto ich rozważać przy określaniu zakresu aplikacji odpowiadającemu MVP? Otóż takiej decyzji na pewno nie można podejmować pochopnie. Przyjrzyjmy się zatem jeszcze raz potrzebom, które dotychczas nie zostały przyporządkowane żadnym funkcjom głównym, popatrzmy także jeszcze raz na główny proces obsługiwany przez aplikację.

Wyszukiwarka produktu: • ubrania mają być podzielone wg kategorii: odzież damska / męska / dziecięca, • ma umożliwić szukanie odzieży wg rozmiaru i koloru. W poprzednich rozważaniach nie przyporządkowaliśmy żadnej funkcji głównej do Prezentacja szczegółowych informacji o pro- pierwszego etapu procesu zakupu obsługidukcie wanego przez aplikację, a mianowicie do • użytkownik ma mieć możliwość obejrzenia „Uświadamiania potrzeby”. zdjęć każdego produktu, Jeśli spojrzymy na ten etap szerzej, to uświa• aplikacja ma prezentować szczegółowy domienie potrzeby zakupu może być wywoopis każdego produktu. łane na skutek wykreowania takiej potrzeby, które są skutkiem odpowiednich działań marObsługa zakupu ketingowych. • użytkownik ma mieć możliwość dokonania zakupu bezpośrednio w aplikacji (dekompo- Nie zapominajmy, że głównym celem biznenuję dodatkowo dla potrzeb opracowania): sowym, który ma być zrealizowany z pomocą o koszyk, aplikacji ma być zwiększenie sprzedaży proo zarządzanie zamówieniami, duktów marki w kraju i za granicą. o obsługa płatności.

Krok 5: Określenie szczegółowej funkcjonalności w ramach poszczególnych funkcji głównych (dekompozycja funkcji głównych) Rysunek 1 Etapy procesu zakupu

Kolejny krok to rozkład zdefiniowanych uprzednio funkcji głównych oprogramowania (dekompozycja funkcji) w celu określenia Krok 4: Główne funkcje oprograszczegółowej funkcjonalności produktu. Podmowania odpowiadające za re- stawą do określania pełnej funkcjonalności alizację procesu głównego produktu jest zazwyczaj specyfikacja wymagań, która definiuje wszystkie wymagania: Główne funkcje oprogramowania powinny zarówno funkcjonalne, jak i niefunkcjonalne odpowiadać za realizację poszczególnych względem produktu. etapów głównego procesu obsługiwanego 36

A więc kwestie związane z odpowiednim marketingiem produktów stają się w aplikacji niezmiernie istotne. Co najmniej kilka potrzeb inwestora można zatem powiązać z pierwszym etapem obsługiwanego procesu zakupu: Uświadamianie (kreowanie) potrzeby -> Marketing produktów: • aplikacja ma powiadamiać użytkownika o nowej kolekcji, promocjach, itp., • użytkownik aplikacji ma mieć możliwość obejrzenia filmów z pokazów marki, • treści w aplikacji mają być prezentowane w wielu językach, Krok 7: Określenie MVP • aplikacja ma pokazywać użytkownikowi prognozę pogodny na najbliższe dwa tygodnie, aby zachęcić go do zakupów odzieży Po poprzednich etapach przygotowawczych, np. przed zbliżającym się upałem czy na- przyszedł wreszcie moment na określenie zakresu funkcjonalnego oprogramowania, który głym chłodem. będzie odpowiadał MVP. Pozostałe wymagania (potrzeby) są poza- Dla każdej z wcześniej określonych głównych funkcji oprogramowania odkreślamy linią te funkcjonalne: funkcje podrzędne, które muszą istnieć w po• aplikacja ma być ładna i nowoczesna, wstającym oprogramowaniu. • kolorystyka aplikacji ma być jasna. Mamy już określoną szczegółowo (oczywiście jedynie w przyjętym przez nas bardzo uproszczonym modelu) funkcjonalność aplikacji, pora na kolejny krok.

Krok 6: Nadanie priorytetu poszczególnym funkcjom szczegółowym Nadawanie priorytetów poszczególnym funkcjom programu jest niezmiernie istotne. Wymaga znajomości dziedziny, potrzeb inwestora i przyszłych użytkowników, a przede wszystkim powinno być przeprowadzone z pełnym uwzględnieniem celu biznesowe- My posłużymy się jeszcze raz naszą tabego przedsięwzięcia. lą priorytetów. Ciemniejszym pomarańczowym tłem oznaW poszczególnych wierszach powyższej tabeli czono te funkcje, które powinny być bezzaprezentowano kolejne funcje aplikacji uło- względnie zrealizowane w aplikacji, aby pełżone zgodnie z nadanymi im priorytetami: od niła ona swoją rolę, czyli aby można było za najwyższego priorytetu do najniższego. 38

jej pomocą doko- miania o promocjach oraz prezentacja oferty nywać zakupów. w wielu językach mogłyby być zrealizowane również w ramach MVP. Użytkownik aplikacji powinien mieć Z drugiej strony funkcje te są konieczne z punkmożliwość doko- tu widzenia zapewnienia obsługi podstawonania wyboru pro- wego procesu w aplikacji (procesu zakupu). duktu z pełnej ich A zatem decyzja o tym, czy włączyć te funkgamy, podjęcia cje w pakiet funkcjonalny odpowiadający decyzji o zakupie zakresowi MVP powinna być mocno przemypo obejrzeniu pro- ślana. duktu i zapoznaniu Linię, która oddziela funkcjonalność zakwalisię z jego opisem, fikowaną do realizacji w ramach zakresu odwskazania, który produkt kupuje (koszyk) oraz powiadającego MVP od pozostałych funkcji dokonania zapłaty. Taka podstawowa funk- oprogramowania nazywamy Linią MVP. cjonalność powinna być bezwzględnie zreali- Jeszcze raz dla przypomnienia – jest siedem zowana w ramach zakresu oprogramowania kroków wyznaczania MVP w przypadku oproodpowiadającego MVP. gramowania: 1. Identyfikacja celu biznesowego przedsięJaśniejszym pomarańczowym kolorem ozna- wzięcia, którego realizacji służyć będzie poczono te funkcje aplikacji, które być może wstające oprogramowanie, również powinny znaleźć się w MVP, lecz 2. Określenie głównego celu samego produkdecyzja o tym nie jest już tak oczywista, jak tu – wytwarzanego oprogramowania, w przypadku funkcji wskazanych wcześniej. 3. Określenie głównego procesu, który będzie obsługiwany przez oprogramowanie, 4. Identyfikacja głównych funkcji oprogramowania, 5. Dekompozycja funkcji głównych - określenie szczegółowej funkcjonalności w ramach każdej z funkcji głównych, 6. Nadanie priorytetów poszczególnym funkcjom szczegółowym, 7. Określenie zakresu oprogramowania odpowiadającego MVP.

MVP oprogramowania - o czym jeszcze powinniśmy pamiętać?

Pamiętamy o tym, że celem biznesowym realizacji całego przedsięwzięcia, w ramach którego ma zostać wytworzona aplikacja, jest W poprzednich krokach zajmowaliśmy się wzrost sprzedaży produktów marki w kraju i za funkcjami oprogramowania czyli wymagagranicą. niami funkcjonalnymi, które miały swój początek w potrzebach inwestora odnośnie funkcji Jeśli tak, kwestia marketingu produktów staje realizowanych przez oprogramowanie. się bardzo istotna, a więc funkcja powiada39

A co z tymi potrzebami i życzeniami, które nie przekładają się wprost na wymagania funkcjonalne? Dla przypomnienia w omawianym przykładzie: • aplikacja ma być ładna i nowoczesna, • kolorystyka aplikacji ma być jasna. Czy na poziomie określania zakresu odpowiadającego MVP powinniśmy w ogóle zajmować się takimi „drobiazgami”? W końcu proces zakupu będzie możliwy do zrealizowania zarówno w jasnej oraz w ciemnej aplikacji. Zarówno w „ładnej i nowoczesnej”, jak i w „brzydkiej i mało nowoczesnej”.

nomia obsługi, itp. nie mają żadnego znaczenia? Otóż i tak i nie. Odpowiedź na to pytanie nie jest jednoznaczna, gdyż zależy m.in. od: • charakteru wytwarzanego oprogramowania (oprogramowanie systemowe, oprogramowanie użytkowe), • typu oprogramowania użytkowego (np. oprogramowanie biznesowe, rozrywkowe, edukacyjne, itp. vs. oprogramowanie sterujące, wizualizujące procesy, pomiarowe, itp.), • grupy docelowej (np. wąska grupa specjalistów w dziedzinie, dla której powstaje oprogramowanie vs. bardzo szeroka grupa bliżej nie scharakteryzowanych użytkowników końcowych), • celu biznesowego przedsięwzięcia, w ramach którego powstaje oprogramowanie, itd.

Abstrahując od tego, że na podstawie tak „miękko” i nieprecyzyjnie określonych potrzeb powinien powstać najpierw zbiór konkretnych wymagań niefunkcjonalnych, definiują- Przykładowo w oprogramowaniu systemocych w sposób jednoznaczny, czego inwestor wym czy sterującym może wygląd nie będzie oczekuje w zakresie wyglądu aplikacji. najważniejszy, lecz prędkość działania oprogramowania może być kluczowa. Wracając do pytania, czy w zakres oprogramowania określony jako MVP powinny wcho- Z kolei w oprogramowaniu biznesowym ergodzić rzeczywiście jedynie najbardziej podsta- nomia obsługi i generalnie UI/UX będą barwowe funkcje, umożliwiające podstawową dzo istotne. obsługę głównego procesu, a pozostałe ce- Natomiast dla oprogramowania edukacyjchy jak np.: wygląd, szybkość działania, ergo- nego czy rozrywkowego atrakcyjny wygląd może być równie ważny, jak zapewnienie realizacji kluczowych funkcji oprogramowania. Decyzja które z wymagań niefunkcjonalnych należy przewidzieć i zrealizować na poziomie MVP, powinna być wypracowywana każdorazowo indywidualnie w danym procesie wytwórczym. W rozpatrywanym przez nas przykładzie kwestia interfejsu użytkownika oraz wygody posługiwania się aplikacją jest niezmiernie 40

istotna. Jeśli interfejs zostanie zaprojektowany niezgodnie z zasadami UI/UX, będzie archaiczny, nieładny i niewygodny, użytkownicy nie będą chcieli używać aplikacji, a tym samym nie będą za jej pomocą kupować produktów marki. Nie zostanie zatem zrealizowany postawiony na wstępie cel biznesowy.

Podsumowanie Szczupłe i przyrostowe wytwarzanie oprogramowania to strategia, która z jednej strony pozwala zminimalizować koszty realizacji rozwiązania, z drugiej strony umożliwia szybkie otrzymanie informacji zwrotnej, czy wytwarzany produkt spełnia oczekiwania inwestora oraz przyszłych użytkowników. Strategia ta sprawdza się szczególnie dobrze w szybko zmieniającym się środowisku biznesowym i technologicznym. Kluczowym elementem w/w strategii jest trafne określenie zakresu funkcjonalnego MVP tworzonego oprogramowania. MVP powinno zawierać funkcje kluczowe dla realizacji celu biznesowego przedsięwzięcia, któremu oprogramowanie ma służyć oraz jednocześnie takie, które są reprezentatywne dla planowanego produktu docelowego. W niniejszym artykule przedstawiłam siedem podstawowych kroków, których wykonanie pozwala na określenie właściwego zakresu funkcjonalnego Minimum Viable Product.

Podczas realizacji tych kroków należy pamiętać przede wszystkim o tym, co jest głównym celem tworzonego oprogramowania oraz mieć świadomość głównego procesu, który oprogramowanie ma realizować. Nadanie właściwego priorytetu funkcjom szczegółowym, obsługującym poszczególne etapy procesu głównego to klucz do ustalenia, które z funkcji o najwyższym priorytecie realizacyjnym stanowią absolutną konieczność MVP (ang. must have). Bibliografia: Książka: Ries Eric, „The Lean Startup”, Helion 2012, ISBN 978-83-246-5100-9, 9788324651009 Strony internetowe: http://www.syncdev.com/minimum-viable-product [dostęp: 21.01.2016] https://en.wikipedia.org/wiki/Minimum_viable_product [dostęp 21.01.2016] http://www.startuplessonslearned.com stęp 23.01.2016]

[do-

http://theleanstartup.com [dostęp 23.01.2016] Słowa kluczowe artykułu: Minimum Viable Product, MVP, Linia MVP, Lean development, wytwarzanie oprogramowania

Ewa Brzeska, Doświadczony Manager i Konsultant IT. Od 25 lat związana czynnie z branżą informatyczną. W tym czasie uczestniczyła w realizacji wielu projektów, pełniąc rolę analityka, projektanta, architekta i programisty oraz kierownika projektu. Wśród zrealizowanych przez nią projektów są rozwiązania wspomagające zarządzanie różnymi sferami biznesu i produkcji. Ma ponad 15 lat doświadczenia w tworzeniu systemów klasy MES (ang. Manufacturing Execution System) dla energetyki i przemysłu. Zarządza projektami i produktami informatycznymi oraz wytwarzaniem oprogramowania. Zajmuje się konsultingiem i doradztwem IT, wykorzystując przy tym bogate doświadczenie praktyczne oraz wiedzę teoretyczną, zdobytą m.in. w Szkole Głównej Handlowej w Warszawie. W 2009 roku wraz ze wspólnikiem założyła firmę Ebitech, która zajmuje się głównie tworzeniem oprogramowania biznesowego na platformy systemowe Apple: iOS i Mac OS X. Współzałożycielka oraz Członek Zarządu Stowarzyszenia Inżynierii Wymagań.

Bożena Rumak

Zarządzanie Projektami

Dlaczego warto analizować przyczyny sukcesów i porażek projektów ? Wyścig z czasem

ły się niebezpiecznie do wysokości potencjalnych przychodów, klient nie chciał podpisać d początku swojej pracy w roli protokołu odbioru systemu twierdząc, że nie analityka biznesowego i syste- został zaimplementowany oczekiwany przez mowego przyzwyczaiłam się do niego zakres wymagań, frustracja członków bardzo szybkiego tempa pracy. zespołu projektowego szybko rosła. Kierownik Zadanie „goniło” zadanie, ledwie zakończy- projektu zorganizował spotkanie, na którym podjęta zostałam notatkę z sesji ła próba znaleanalitycznej, od zienia przyczyn razu przygotoi (niestety !) winwywałam się do nych zaistniałej następnych sesji sytuacji. Wreszi spotkań. Zanim cie „zbiorowym zakończyłam praStephen King „Mroczna wieża” wysiłkiem cace analityczne łej ekipy” (czyli w jednym prodzięki naszej prajekcie, już rozpoczynałam analizę nowych obszarów. Sporne cy po godzinach) doprowadziliśmy projekt sprawy we współpracy z klientem rozwią- do końca po planowanym terminie i ze strazywałam na bieżąco. Tak mijały kolejne dni tą finansową – uzyskaliśmy upragniony podpracy i kolejne projekty. Poznawałam nowe pis odbiorcy na protokole. Kierownik projektu narzędzia i doskonaliłam umiejętności pozy- ostatecznie podsumował: udało się zapobiec skiwania i analizy wymagań. Wydawało się, całkowitej katastrofie.

Kto nie wyciąga wniosków z przeszłości, skazany jest na jej powtarzanie

że mam coraz większą wiedzę i doświadczenia, więc każdy następny projekt będzie kolej- Zaczęłam się zastanawiać, co było przyczyną niedotrzymania przez nas harmonogramu nym sukcesem. i zakładanych kosztów. Na pierwszy rzut oka Pewnego dnia 6-miesięczny projekt, w którym nie było widać przyczyn: mieliśmy wiedzę brałam udział znalazł się w punkcie zwrotnym: merytoryczną i techniczną , pracownicy byli termin zakończenia minął, nasze koszty zbliży- bardzo zaangażowani, klient jasno przedsta42

wiał nam swoje oczekiwania na spotkaniach analitycznych, zaplanowany czas realizacji wydawał się adekwatny do zakresu projektu, komunikacja z klientem była dobra. Uświadomiłam sobie wtedy, że po projektach zrealizowanych z sukcesem ani ja, ani nikt z zespołu projektowego nie zastanawiał się nad oceną prac w projekcie. Mieliśmy całkowite zaufanie do naszej wiedzy i kompetencji, nie identyfikowaliśmy potencjalnych ryzyk w projekcie, a po jego zakończeniu nie wyciągaliśmy wniosków na przyszłość. Zadałam sobie pytanie, co mogę z tym zrobić. Na początek postanowiłam przygotować listę zagadnień, która pozwoliła mi porównać ze sobą projekty zakończone sukcesem. Była ona następująca: • wiedza merytoryczna dostawcy z obszaru zamówienia ; • analiza i walidacja wymagań; • stabilność obowiązujących aktów prawnych związanych z zamówieniem; • poziom dojrzałości organizacji klienta oraz metody współpracy dostawca-odbiorca; • zastosowane narzędzia i technologie; • komunikacja w zespole projektowym; • kompetencje zespołu developerskiego; • tryb reakcji na zmiany zakresu ; • inne warunki realizacji unikalne dla projektu. Moja lista była formalnie dość prosta – każdej z pozycji przypisałam poziom w skali 1-3 (1-niski, 2- średni, 3-wysoki). Wynik porównania kilku projektów zakończonych sukcesem był dość zaskakujący: we wszystkich projektach, mimo różnych wartości dla kilku pozycji, dwa elementy osiągały zawsze wysoki poziom. Były to komunikacja w zespole projektowym oraz tryb reakcji na zmiany zakresu. Tak mnie to zaintrygowało, że niezwłocznie wypełniłam listę dla „projektu-porażki”. Wynik skierował moją uwagę na zagadnienie trybu reakcji na zmiany zakresu. Po głębszej analizie okazało się, że w tym projekcie doszło

do wielu zmian na różnych etapach realizacji projektu, a niekompletna ich ewidencja przyczyniła się do tego, że realizowane było one bezpłatnie i wydłużyły czas realizacji zadań. Z dumą pokazałam wynik mojej analizy kierownikowi kontraktu. Niestety dość wszechstronnie skrytykował moje podejście. Oto kilka przykładowych zdań: • w tym projekcie klient nie wiedział, czego chce; • w tym projekcie ludzie się nie sprawdzili; • po co robić analizę przyczyn sukcesów – udało się je osiągnąć i to jest najważniejsze; • nie trać czasu na niepotrzebne analizy i wyciąganie wniosków, następny projekt już czeka; • każdy nasz projekt jest inny, nie da się ich porównać. Mimo takiej reakcji postanowiłam, że nie zejdę z nowej drogi wyciągania wniosków z realizowanych projektów. Z czasem znacznie rozbudowałam tę analizę.

Zarządzanie ryzykiem Bez względu na stosowaną metodykę i swoją rolę w projekcie (analityk, kierownik projektu, menadżer obszaru operacyjnego) zawsze prowadzę proces zarządzania ryzykiem w obszarze, za który odpowiadam. Stopień szczegółowości mojego rejestru ryzyka dobieram do zakresu i skali projektu. Tam, gdzie jest to możliwe włączam mój rejestr do rejestru ryzyka całego projektu. W swojej pracy przyjęłam następującą definicję: ryzyko jest to sytuacja, która może spowodować straty finansowe, wydłużyć termin realizacji albo w inny sposób zagrozić sukcesowi projektu. Zwykle stosuję następujący szablon śledzenia elementów ryzyka w projekcie, który wspiera mnie w szacowaniu i kontrolowaniu ryzyka (rozbudowałam go na podstawie najlepszej książki n/t analizy wymagań, jak ukazała się 43

na polskim rynku wydawniczym1) • ID [numer] • Zgłaszający [osoba/rola, która zwróciła uwagę zespołu projektowego na dane ryzyko] • Data otwarcia [data zidentyfikowania ryzyka] • Data zamknięcia [data mitygacji ryzykalub jego materializacji] • Opis ryzyka [opis w postaci: warunek – konsekwencje] • Zakres ryzyka [zespoły projektowe, obszary biznesowe oraz funkcjonalne, na które wpływa ryzyko] • Prawdopodobieństwo [prawdopodobieństwo, że ryzyko zmaterializuje się; skala od 0,1 (mało prawdopodobne) do 1,0 (pewność)] • Wpływ [liczbowe oszacowanie potencjalnej straty, jeśli ryzyko się zmaterializuje; skala od 1 (brak problemu) do 10 (duży problem)] • Narażenie [=prawdopodobieństwo x wpływ] • Plan zarządzania ryzykiem [jedno lub kilka rozwiązań mających na celu kontrolowanie, uniknięcie, zminimalizowanie lub załagodze-

1 Karl Wiegers, Joy Beatty, Specyfikacja oprogramowania,, Gliwice, Helion SA, Wyd.III, 2014, 978-83-246-9166-1

nie skutków zagrożenia, wykaz czynności i terminów] • Plan awaryjny [działanie do podjęcia, jeśli plan zarządzania ryzykiem okaże się nieskuteczny] • Właściciel [osoba/rola w projekcie odpowiedzialna za zarządzanie ryzykiem] • Data zapadalności [dzień, w którym należy przeprowadzić działania łagodzące] • Realizacja działań kontrolnych [terminy realizacji, opis działań kontrolnych i ich skutków] • Status zamknięcia ryzyka [mitygacja, zmaterializowanie się] Dzięki takiemu opisowi ryzyk łatwo można stwierdzić, które z nich są największym zagrożeniem dla projektu – będą one miały najwyższą wartość czynnika „Narażenie”. Pamiętajmy także, że nie wystarczy opisać czynnika i planu jego zarządzania. Należy okresowo sprawdzać, czy działania łagodzące doprowadziły do jego mitygacji czyli obniżyły ryzyko do akceptowalnego poziomu lub minęło niebezpieczeństwo jego materializacji.

ygrywa tylko ten, kto ma jasno określony cel i nieodparte pragnienie,aby go osiągnąć. W wyniku podjętych działań ryzyko może zostać zamknięte albo zmieni się jego poziom prawdopodobieństwa i /lub wpływu. Oczywiście analitycy biznesowi i systemowi zwykle skupiają się na czynnikach ryzyka związanych z wymaganiami, których rozbudowaną listę znajdziemy w książce2: 1. Pozyskiwanie wymagań • Wizja produktu i zakres projektu • Czas poświęcony na opracowanie wymagań • Zaangażowanie klienta • Kompletność i poprawność specyfikacji wymagań • Wymagania dotyczące produktów innowacyjnych • Definiowania wymagań niefunkcjonalnych • Porozumienie z klientem co do wymagań • Wymagania niewyartykułowane • Istniejące produkty w roli źródła wymagań • Rozwiązania przedstawione jako potrzeby • Brak zaufania między zespołem odbiorcy i dostawcy

4. Walidacja wymagań • Wymagania bez walidacji • Biegłość w inspekcji 5. Zarządzanie wymaganiami • Zmiana wymagań • Proces zmiany wymagań • Niezaimplementowane wymagania • Rozszerzenie zakresu projektu Nie wszystkie projekty wymagają tak szczegółowej identyfikacji czynników ryzyk związanych z wymaganiami. Bardziej doświadczeni analitycy z pewnością szybko wybiorą te, które w każdym z ich projektów były lub są najważniejsze. Początkujących analityków zachęcam do rozważenia czynników ryzyka z obszaru pozyskiwania wymagań oraz koncentracji na priorytetyzacji i walidacji wymagań. Nie zapominajmy również o innych czynnikach ryzyka mających wpływ na jakość i terminowość pracy analitycznej np. model tworzenia oprogramowania (iteracyjny, model kaskadowy, zwinne wytwarzanie itp.) czy też komunikacja w zespole projektowym.

„Wyloguj się...”

Po zakończeniu projektu wyłączam się z bieżącej pracy operacyjnej i analizuję rejestr ryzyk. Jeśli projekt zakończył się sukcesem skupiam się na identyfikacji podstawowych czynników, które do niego doprowadziły. 2. Analiza wymagań Jeśli projekt zakończył się porażką, wykonuję • Priorytetyzacja wymagań szczegółową analizę jej przyczyn źródłowych. • Technicznie trudne funkcje • Nieznane technologie, metody, języki, na- Bardzo pomaga mi w tym wielokrotne zadawanie pytań dlaczego dany problem wystąrzędzia sprzęt pił oraz stosowanie analizy „top-down”. Dla każdego przypadku tworzę Diagram Ishi3. Specyfikacja wymagań kawy (przyczynowo-skutkowy) wg składo• Zrozumienie wymagań wych 5M: • Presja czasu • Manpower – ludzie (współpraca dostawca• Niejednoznaczna terminologia -odbiorca, komunikacja w zespole projekto• Projekt dołączony do specyfikacji wym, doświadczenie członków zespołu projektowego w stosowaniu metod i technologii); 2 Karl Wiegers, Joy Beatty, Specyfikacja oprogramowania,, Gliwice, Helion SA, Wyd.III, 2014, 978-83-246-9166-1 45

• Methods – metody (głównie z obszaru zarzą- Z mojego dotychczasowego doświadczenia dzania wymaganiami); wynika, że metodycznemu zarządzaniu ryzykiem w projektach poświęca się obecnie za • Machinery – maszyny (głównie stosowa- mało uwagi w stosunku do potrzeb i korzyści, ne technologie); które można osiągnąć. Skutkuje to powielaniem czynności, które nie przynoszą oczeki• Materials – materiały (głównie forma opisu wanych efektów w kolejnych projektach oraz potrzeb przygotowana przez klienta oraz ro- frustracją tych, którzy uczestniczą w projekdzaje dokumentacji analitycznej, projekto- tach zakończonych porażką. wej i testowej tworzonej w projekcie); Mam nadzieję, że zaproponowane przeze mnie działania ułatwią wyciąganie wniosków • Management – zarządzanie (głównie model z sukcesów i porażek oraz spowodują szybki tworzenia oprogramowania oraz metodyka rozwój zawodowych kompetencji. zarządzania projektem, w tym zarządzaniem rejestrem ryzyk). Napoleon Hill (1883–1970) - amerykański piTeraz czas na plan nowych działań uspraw- sarz i badacz wpływu osobistych przekonań niających proces pracy. Tworząc go nie na zawodowy sukces napisał „Wygrywa tylko zapominam o sprecyzowaniu celu i miary ten, kto ma jasno określony cel i nieodparte sukcesu oraz planu monitorowania jego reali- pragnienie, aby go osiągnąć” . zacji. W planie umieszczam elementy działań Życzę, abyście znaleźli czas i umieli wyciągać wskazując datę zakończenia oraz potrzebne wnioski zarówno z porażek, jak i sukcesów zasoby. Rozważam w nim również zależności projektów ! i zagrożenia. W praktyce po każdym projekcie mam zaplanowane 3-5 czynności dosko- Słowa kluczowe artykułu: zarządzanie ryzykiem projektu, analiza wymagań, analityk, nalących mój proces pracy. czas, wyloguj, Diagram Ishikawy, sukces proZawsze dużą satysfakcję daje mi realizacja jektu tego planu. W konsekwencji jego realizacji oszczędzam czas oraz mam świadomość, że unikam popełnienia dwa razy tego samego błędu. Dodatkowo dzięki tej pracy mogę dobrać metody i narzędzia pracy oraz współpracy w zespole najbardziej odpowiednie do warunków w następnym projekcie. Bożena Rumak, absolwentka AGH w Krakowie, Uniwersytetu Warszawskiego oraz IBD Business School. Pracowała na stanowiskach analityka biznesowego i systemowego w sektorze przedsiębiorstw (handlowo-usługowych, produkcyjnych) oraz banków. Pełniła rolę Głównego Analityka w kilkudziesięciu projektach. W zakresie analizy biznesowej specjalizuje się w obszarze finansów i rachunkowości. W trakcie wielu szkoleń zdobywała wiedzę zarówno z zakresu inżynierii oprogramowania, jak i rozwoju umiejętności miękkich przydatnych w pracy analitycznej oraz w obszarze zarządzania. Uzyskała certyfikat w zakresie zarządzania projektami „Certified Project Management Practitioner IPMA Level D” , zarządzania ryzykiem „Risk Management, The George Washington University, School of Business” oraz ukończyła studia podyplomowe z zarządzania projektami Unii Europejskiej. Obecnie jest certyfikowanym trenerem biznesu (IES), coachem oraz konsultantem procesów biznesowych. Obszarem jej szczególnego zainteresowania zawodowego jest rozwój technik analizy biznesowej i dostosowanie ich do tempa zmian potrzeb klientów oraz mentoring i coaching zawodowy. 46

PATRONAT MEDIALNY:

Jakich tematów, bądź działów brakuje Ci w naszym magazynie?

Napisz do nas, a my wśród prac rozlosujemy 2 książki : „System ERP. Dobre praktyki wdrożeń”. Propozycje należy nadsyłać na nasz adres: kontakt@reqmagazyn.pl z dopiskiem: „KONKURS” do 20 czerwca 2016 roku. 47

Dzisiaj pamiętamy głównie to, czego się wówczas nauczyliśmy, a dawne przykrości traktujemy zazwyczaj jako zabawne anegdoty. Prelegenci FUN to odważne osoby, obdarzone poczuciem humoru, dystansu do siebie, które lubią dzielić się swoim doświadczeniem z innymi.

Wydarzenia FuckUp Nights, czyli uczymy się na cudzych błędach!

Potem kolejne i kolejne….. aż pomysł zamienił się w cykl, który spodobał się widzom. Niektórzy spośród nich zgłosili chęć organizowania podobnych spotkań w innych miastach.

Po (wspólnym z Romanem) powrocie do Warszawy postanowili zorganizować tego typu wydarzenie w Polsce. Jego przygotowanie wymagało nieco czasu.

A później idea, jak wirus, przeniosła się do innych krajów. I w taki mniej więcej sposób (szczegóły nieco zniknęły w oparach piwa i mezkalu, z których to pierwsze do dzisiaj jest nieodłącznym składnikiem spotkań) powstaO sprawach, których nie przypilnowali, o złych ła idea FuckUp Nights (FUN). decyzjach, niepodjętych szansach, niezre- Są regularne spotkania, na których odważalizowanych zobowiązaniach. Rozmawiali ni ludzie opowiadają o swoich porażkach też o podobnych historiach usłyszanych od w biznesie, sporcie czy działalności społeczprzyjaciół czy znanych im z mediów. Pod- nej. Dzielą się doświadczeniem tego, co się czas rozmowy padały stwierdzenia w rodza- wydarzyło w wyniku błędnych decyzji, złych ju „Gdybym wcześniej znała jego historię, to założeń, nietrafionych pomysłów, zaniedbanie popełniłabym podobnego błędu.”, bądź nia czy lenistwa. Prelegenci pokazują, jak re„Gdybym wiedział, że może to tak zadziałać agowali na porażki, jak się z nich podnieśli, jak jak u niej, to zrobiłbym inaczej.” ich zainspirowały.

Pierwsze spotkanie odbyło się 14 stycznia 2015 roku w pubie Wilson na Żoliborzu. Zgromadziło ono ok. 70 osób zaintrygowanych nazwą i zainteresowanych samą ideą spotkania.

iedy pod koniec 2012 roku piątka przyjaciół spotkała się przy piwie i mezkalu w jednym z pubów w stolicy Meksyku, nikt nie spodziewał się, że niewinna rozmowa przerodzi się w ciągu kolejnych 3 lat w przedsięwzięcie obecne w kilkudziesięciu krajach świata. Ich rozmowa krążyła wokół wspomnień o tym, co udało się im popsuć w biznesach, które prowadzili.

Wspólnie zauważyli, że historie porażek to nauki, z których nie mogli wcześniej skorzystać, bo… nie znali tych historii. Słowo do słowa i powstał pomysł spotkania, na którym chcieli podzielić się swoimi porażkami, a przede wszystkim wynikłymi z nich doświadczeniami. W efekcie zorganizowali pierwsze spotkanie, które nazwali FuckUp Nights.

Mówią o tym, czego się nauczyli i co osiągnęli dzięki swoim błędom. Czasami dawały one „tylko” nowe doświadczenie i wiedzę, ale nierzadko stanowiły one powód rozpoczęcia zupełnie nowej drogi życiowej. FuckUp Nights (w skrócie FUN) trafiły do Polski pod koniec 2014 roku dzięki Eli Piotrowskiej i Romanowi Bautista.

Opowiedzieli na nim o swoich porażkach, odpowiadalii na pytania osób, które przyszły ich posłuchać, a potem był czas na dyskusje i rozmowy. Idea spotkania spodobała się uczestnikom, dlatego postanowili zorganizować kolejne, na którym tym razem zaproszeni goście opowiedzieli o swoich porażkach.

W trakcie pobytu w Meksyku Ela (która poznała tam Romana) miała okazję wziąć udział w spotkaniach. Spodobała jej się w panującą na nich atmosfera.

FUCKUP

„fuckup” (wym. „fakap”) • potoczne określenie osoby, która działa niedbale lub głupio, jest partaczem, popełnia błędy • często używane przez osoby anglojęzyczne na określenie „głupich błędów”

Dlaczego stają na scenie przed kilkudziesięcioma osobami i mówią o swoich błędach? Powody są różne. Niektórzy chcą się po prostu pokazać. Dla innych jest to okazja do przemyślenia sobie tego co przeżyli i wyciągnięcia wniosków. Niektórzy mówią, że opowiedzieli tą historię pierwszy raz i teraz lepiej się z nią czują. A inni – że to opowiedzenie to dla nich świetna zabawa. Historie są czasami śmieszne, czasami smutne. Po niektórych osobach widać, jak bardzo je przeżyli. Dla innych są równie zabawnym i przyjemnym wspomnieniem, podobnie jak „nauczyciel piła” w podstawówce. Wtedy stanowił powód do zgryzoty, dzisiaj stał się nostalgicznym wspomnieniem.

To przedsiębiorcy, działacze społeczni, sportowcy czy założyciele startupów. Starsi i młodsi. Tacy, którzy popełniali błędy na początku swojej działalności lub mając już pewne doświadczenie. Wszyscy prelegenci FUN mówią o tym, jakie doświadczenie wyciągnęli z tego, co przeżyli. Niektórzy przedstawiają swoje porady, a inni pozostawiają ich wyciągnięcie samodzielnie przez publiczność. A tej nie brakuje! Na widowni siedzi zazwyczaj od 50 do ponad 150 osób (rekord w Polsce to 190 osób!) - pełen przekrój wiekowy i społeczny. Są młodsi i starsi, przedsiębiorcy i etatowcy, uczniowie i pracownicy uczelni. Sprzedawcy ubezpieczeń, producenci rur plastikowych, wydawcy gazet i całkiem spora reprezentacja ludzi pracujących w marketingu. Są informatycy i humaniści. Łączy ich jedno – szukają wiedzy podanej w ciekawy, atrakcyjny sposób, która wynika z doświadczenia prelegentów, z czegoś, co naprawdę się wydarzyło. I taką wiedzę dostają na spotkaniach FuckUp Nights. Co wynoszą słuchacze z tych spotkań? Piotr był gościem na jednych z pierwszych spotkań FUN w Trójmieście. Był świeżo po zamknięciu biznesu, który nie udał się, bo było za dużo złych decyzji, za mało doświadczenia i… nieco innych błędów. Stwierdził, że nie nadaje się do prowadzenia biznesu. Trafił na spotkanie FUN zaintrygowany tematyką i namówiony przez znajomych. W efekcie… Pozwolę sobie zacytować fragmenty maila, który do mnie napisał: „(…)słuchanie o wtopach innych ludzi, zmotywowało mnie, aby powrócić do startupów. 49

Zrozumiałem, że porażka będzie po prostu kolejnym krokiem na mojej drodze do celu i że będzie ich więcej. Ode mnie zależy czy okażą się klęską, czy jedynie kolejnymi fuckupami, z których wyciągnę wnioski i się podniosę. Teraz znowu chwytam życie za rogi i próbuję swoich sił z nowym projektem. (…) [FuckUp Nights] naprawdę inspirują do tego, aby próbować dalej.”.

Od marca 2015 roku organizuję spotkania FUN w Trójmieście. Moja przygoda zaczęła się od tego, że zupełnie przypadkiem na koniec 2014 roku znalazłem informacje w jednym z warszawskich portali o pierwszym FuckUp Nights w Polsce. Sama nazwa zaintrygowała mnie na tyle, że z uwagą przeczytałem całą informację, potem pogooglałem i na koniec stwierdziłem, że TAK, chcę to robić!

W chwili obecnej spotkania FuckUp Nights organizowane są w około 140 miejscach w 50 krajach na całym świecie. Na spotkaniu 3-4 mówców dzieli się historiami o swoich błędach i porażkach. To również od 20 do ponad 100 słuchaczy, którzy jednocześnie uczą się i bawią przy tych opowieściach.

Tym bardziej, że idea spotkań jest zgodna moją praktyką coachingową, doradczą i trenerską, w której od zawsze działam tak, aby moi Klienci jak najwięcej wykorzystywali swoje doświadczenia– nie tylko z porażek, ale również z sukcesów.

To historie czasami śmieszne, czasami smutne – zawsze od serca mówcy do serc słuchaczy. To tysiące litrów wypitego piwa oraz rozmów. Dzięki temu, że możesz spotkać tutaj ludzi zajmujących się naprawdę różnymi rzeczami, to również świetny networking i możliwość nawiązania wielu nowych znajomości. O FuckUp Nights opowiadam ze swojego doświadczenia.

goś, kto mógłby prowadzić dalej FUN w Warszawie… Zgłosiłem się. Miałem już wtedy deklarację współpracy ze strony grupy przyjaciół ze stolicy. I tak się stało, że odpowiadam za organizację spotkań w obu miejscach. W Polsce, poza Warszawą i Trójmiastem spotkania FuckUp Nights organizowane są w Lublinie i w Poznaniu. Niedługo powinny pojawić się też w innych miastach.

Z niektórych wydarzeń dostępne są też materiały na YouTube. Do informacji o spotkaniach, których organizację koordynuję, dotrzecie za pośrednictwem strony fuckupnights. pl.

Pamiętajcie - porażka nie oznacza „końca wszystkiego”, a jedynie jest końcem pewnego etapu, po którym jest kolejny nowy początek. Nie wierzycie?

Znajdźcie informacje o najbliższym spotkaniu Głównym kanałem informacji o spotkaniach i przekonajcie się sami. Jeśli się mylę – konieczjest Facebook – wyszukaj po frazie „FuckUp nie napiszcie o tym do mnie . Nights”.

Dzięki pomocy fundacji Failure Institute z Meksyku (założonej przez wspomnianą na początku piątkę przyjaciół) oraz Eli Piotrowskiej, a także grupie zaangażowanych przyjaciół, uruchomiliśmy comiesięczne spotkania w Trójmieście. Do dzisiaj (koniec marca 2015) wraz ze wspaniałym Zespołem zorganizowaliśmy w Trójmieście 12 spotkań, na których gościliśmy 46 prelegentów i prawie 1200 widzów. Kiedy Elżbieta i Roman postanowili wrócić do Meksyku i zapytali się mnie czy nie znam ko-

Magdalena Żądkowska

UX user

experience

Jak wiedzę o mózgu wykorzystać w projektowaniu UX? Wstęp

mogą wpływać na zachowanie użytkownika na stronie internetowej oraz poznasz praktyczudzki mózg to zaledwie 2% całej masy ne wskazówki, które pozwolą Ci tę wiedzę wyciała. Mimo swoich niewielkich rozmia- korzystać w projektowaniu. rów zużywa aż 20% energii produkoSzablony działania wanej przez nasz organizm. Niemniej pomimo swojej energochłonności nie jest on Projektując produkt czy usługę nigdy nie uwzw stanie przetworzyć wszystkich informacji naględniamy wymagań wszystkich użytkowpływających do nas z otoczenia, dane ze śroników. Spełnienie wszystkich wymagań byłodowiska są nieustannie filtrowane przez nasz by niemożliwe, a rezultat takich prób byłby system poznawczy. Z ewolucyjnego punktu przeciwny do zamierzonego. Z tego powodu widzenia jest to konieczny proces, w innym skupiamy się na użytkownikach kluczowych, wypadku musielibyśmy nieustannie siedzieć starając się w procesie projektowym uwzględprzy stole, aby dostarczyć wystarczająco nić ich perspektywę, potrzeby, motywacje energii dla tak skomplikowanego narządu. lub obawy. Z pomocą w zrozumieniu perspekW naszym codziennym życiu, selekcjonowa- tywy użytkownika przychodzi termin z zakresu nie informacji przyczynia się do popełniania psychologii poznawczej- model mentalny. wielu błędów i działania na skróty w celu zaoszczędzenia energii. To, w jaki sposób postrzegamy otaczający nas świat jest zależne od naszego aparatu poznawczego. Zazwyczaj nie zdajemy sobie sprawy, jak bardzo nasza percepcja czy działanie są niezależne od naszej woli. Zwykle ta wiedza nie jest nam również potrzebna do prawidłowego funkcjonowania w świecie. Jednak powinna ona być wykorzystana przez projektantów doświadczeń (ang. User Experience). Po przeczytaniu tego artykułu dowiesz się, jak ograniczenia Rysunek 1. Modele mentalne użytkownika i projektanta i możliwości ludzkiego systemu poznawczego mogą się różnić

Modele mentalne pozwalają człowiekowi z modelem mentalnym użytkownika, realizuje zrozumieć świat i w nim się poruszać. Są to po- on kolejne kroki niemal automatycznie, bez znawcze interpretacje otoczenia tworzone na większego zastanowienia. Jednak, gdy okapodstawie doświadczenia i obserwacji. Pełnią zuje się, że dodanie produktu do koszyka wyone funkcję wzorca, pomagając w podjęciu maga wykonania dodatkowych czynności, decyzji 1. Nie są one idealnym odzwierciedle- których użytkownik się nie spodziewał, zostaje niem rzeczywistości, a raczej szkicem, dzięki on zmuszony do zrewidowania swojego moktóremu potrafimy delu, co z kolei wymaga eśli Twoja przewidzieć zachowzmożonego wysiłku postrona wymaga wanie innych osób. znawczego. od użytkownika Kluczem w projektoDobrą praktyką stosoz a s t a n o w i e n i a waniu doświadczeń się nad jakąś kwestią waną w trakcie badań jest odseparowanie bądź podjęcia decyzji, z użytkownikami jest prosię od swojego mo- nie rozpraszaj go śba o tzw. głośne myśledelu mentalnego wyskakującymi oknami czy nie. W ten sposób nie tylw celu zrozumienia migającymi banerami. ko dowiadujemy się, jak modelu użytkownii czy użytkownik realizuje ka. dane zadanie, ale także poznajemy jego moDlatego tak ważną rolę w procesie projek- del mentalny. Może się okazać, iż pomimo, towym odgrywa badanie potrzeb użytkow- że użytkownik bez problemu wykonał zadaników, m.in. poprzez tworzenie person, które nie (np. dodał produkt do koszyka czy odnareprezentują użytkowników o podobnym lub lazł ofertę kredytową), spodziewał się innych identycznym charakterze2 . nazw etykiet w menu nawigacyjnym lub innej Persona działa jak awatar modelu men- kolejności poszczególnych kroków procesu. talnego użytkownika, jednak nie służy ona perfekcyjnemu przedstawieniu użytkownika. Co za dużo to niezdrowo Celem tworzenia person jest uwolnienie się od własnych przekonań oraz uprzedzeń, i przyjęcie dzięki temu perspektywy użytkownika. Obciążenie poznawcze to kolejne pojęcie, Analizując kim są nasi użytkownicy, jakie są ich które powinno znaleźć się w słowniku oczekiwania, potrzeby i motywacje, jesteśmy projektanta doświadczeń. Większość w stanie stworzyć produkt, który będzie zgod- użytkowników komputerów doskonale wie, że ny z ich wyobrażeniami. Użytkownik wchodząc uruchomienie na raz zbyt wielu programów na stronę, na przykład sklepu internetowego, może spowolnić urządzenie. Jak tego ma pewne wyobrażenia, co do tego jak ta uniknąć? Wystarczy wyłączyć niepotrzebne strona wygląda i jak działa. Spodziewa się listy programy. Podobnie jak w przypadku produktów, które może kupić, zakłada, że jeśli komputera, moc obliczeniowa mózgu dany produkt znajduje się na tej liście, to jest człowieka również jest ograniczona. Gdy ilość on w sklepie dostępny, a kliknięcie przycisku informacji płynących z otoczenia przewyższa „dodaj do koszyka” spowoduje dodanie pro- naszą zdolność do ich przetworzenia, duktu do koszyka i rozpoczęcie procesu zaku- nasza wydajność spada. Przetworzenie powego. Dopóki działanie strony jest spójne informacji może zabierać nam więcej czasu,

1 Staggers, Nancy; Norcio, A.F. (1993). Mental models: concepts for human-computer interaction research. International Journal of Man-Machine Studies 38 (4): 587–605. 2 Masłowska Aleksandra , Od potrzeby do procesu - jak zsyntezować wiedzę o użytkownikach ?, „REQ Magazyn” 2015, 3, 16-21.

możemy nieświadomie pomijać pewne szczegóły, a nawet całkowicie zrezygnować z wykonania zadania. Obciążenie poznawcze to termin, który został stworzony 53

przez psychologów do opisywania wysiłku umysłowego wymaganego do przyswojenia nowych informacji. Choć przeglądanie stron internetowych nie wymaga tak wzmożonego wysiłku jak edukacja, użytkownicy muszą nauczyć się korzystania z witryny np. jej układu czy korzystania z nawigacji. Nawet, gdy strona jest im znana, użytkownicy nadal muszą wykorzystywać swoją wiedzę, aby osiągnąć zamierzony cel. Co więcej, obciążenie poznawcze dotyczy nie tylko wiedzy związanej z interfejsem użytkownika, ale także ograniczeń i wymagań bezpośrednio wynikających z celu użytkownika. Na przykład korzystając ze strony biura podróży, użytkownik musi wziąć pod uwagę także ograniczenia związane z ceną i terminami wyjazdu. Jeżeli szybkość komputera nie spełnia naszych oczekiwań, możemy po prostu kupić nowsze, wydajniejsze urządzenie. Jak dotąd naukowcom nie udało się znaleźć sposobu na zwiększenie mocy obliczeniowej naszego mózgu. Dlatego to rolą projektantów jest zrozumienie i dostosowanie serwisów internetowych do ograniczeń

ludzkiego systemu poznawczego. Jak już wiemy, użytkownicy w interakcji z produktem (także serwisem internetowym) polegają na swoim doświadczeniu, więc dopóki zadania, jakie muszą wykonać są zgodne z ich dotychczasowymi przeżyciami, będą szybko podejmować decyzje. Zatrzymają się dopiero wtedy, gdy w trakcie interakcji z produktem pojawi się czynność dla nich niezrozumiała, wymagająca zastanowienia się.

Co za dużo to niezdrowo Jak wykorzystać wiedzę o modelach mentalnych i obciążeniu poznawczym w projektowaniu? • Zachowaj umiar: duża liczba linków, grafiki niepowiązane z treścią strony, zbyt kwiecista typografia spowolnią działania użytkownika. • Projektuj w oparciu o modele mentalne swoich użytkowników: jeśli użytkownicy szukają informacji w niewłaściwym miejscu, prze-

nieś je właśnie tam. Zadanie sortowania kart 3 jest dobrym sposobem na dowiedzenie się, jakim modelem mentalnym posługują się użytkownicy, jeśli chodzi o architekturę informacji. Umożliwi Ci to zaprojektowanie odpowiedniej nawigacji.

Istotne w tym podziale jest to, że uwaga mimowolna zawsze dominuje nad dowolną. Uwaga dowolna wymaga od nas wysiłku i świadomego zaangażowania w zadanie, dlatego jest podatna na dystrakcję. Oznacza to, że nawet w przypadku skupienia się na danej czynności np. czytaniu oferty banku, nasza uwaga zostanie mimowolnie skierowana na nowy bodziec pojawiający się w otoczeniu np. wyskakujące okno z formularzem kontaktu. Oczywiście jesteśmy w stanie nauczyć się ignorować dany bodziec i zahamować odruch orientacyjny, ale wiąże się to dodatkowym wysiłkiem poznawczym.

• Ułatw zadanie: przeanalizuj na swojej stronie wszelkie elementy, które wymagają czytania tekstu, zapamiętywania informacji czy podjęcia decyzji. Następnie poszukaj alternatyw - czy możesz tekst przedstawić w postaci grafiki, ponownie wyświetlić informacje wprowadzone przez użytkownika wcześniej bądź ustawić sensowną opcję domyślną? Oczywiście, zwolnienie użytkownika ze wszystkich zadań, nie jest możliwe, ale ich zredukowanie zwalnia zasoby, które mogą być wykorzystane do realizacji tych naprawdę Ubocznym skutkiem filtrowania docierających do nas informacji jest zjawisko przez istotnych. psychologów nazwane „ślepotą przez nieuwagę”. W 1999 roku Simons i Chabris Paradoks uwagi poprosili badanych o obejrzenie krótkiego nagrania i liczenie podań piłki wykonanych Biorąc pod uwagę ograniczone możliwości przez osoby w białych koszulkach4 . Nagranie naszego mózgu do przetwarzania informacji, możesz samodzielnie obejrzeć w serwisie oczywiste jest, że musi istnieć mechanizm, YouTube pod adresem https://www.youtube. który z natłoku napływających danych filtruje com/watch?v=vJG698U2Mvo. te, które są dla organizmu najważniejsze. Mechanizmem tym jest uwaga. Możemy Spośród 192 osób, które wzięły udział wyróżnić jej dwie kategorie: w eksperymencie aż 46% nie zauważyło przechadzającego się między podającymi • uwagę mimowolną (ang. bottom-up goryla. Autorzy udowodnili, że „ślepota przez attention), która jest wyzwalana przez nieuwagę” zależy od trudności aktualnie otoczenie, jej przykładem może być odruch wykonywanego zadania. Im trudniejsze orientacyjny, którego funkcją jest skierowanie zadanie wykonywali uczestnicy, tym częściej uwagi na zmianę bodźca bądź pojawienie goryl umykał ich uwadze. Badania te się nowego, jest ona niezależna od naszej pokazują, że uwaga jest aktywnym systemem woli i zmusza do skupienia uwagi na bodźcu, decydującym, które z bodźców są dla nas bez względu na to, czy tego chcemy czy nie; ważne. Oznacza to, że obiekty znajdujące się poza naszą uwagą, mogą zostać pominięte. • uwagę dowolną (ang. top-down attention), Oczywiście w większości przypadków to my która wyzwalana jest przez organizm i wiąże decydujemy gdzie skierować uwagę. Jeśli jednak skoncentrujemy ją tylko na jednym 3 więcej na ten temat w prezentacji : http://www.slideshare. net/symetria/sortowanie-kart-symetria-natalia-bednarz

się z jego celową, świadomą aktywnością.

4 Simons Daniel, Chabris Christopher, Gorillas in our midst: Sustained inattentional blindness for dynamic events, “Perception”, 1999, 28, 1059-1074.

zadaniu, możemy nie zauważyć nawet goryla. Wszystkie elementy, które nie są spójne z tym celem, są przez nich nieświadomie pomijane. Przeglądają stronę pod kątem informacji, Badacze zajmujący się „ślepotą przez które są dla nich istotne w realizacji tego nieuwagę” uważają, że tylko dzięki uważności celu. Utrudnianie im znalezienia tych danych, zmysłowe cechy mogą być kodowane poprzez umieszczanie na stronie mnóstwa i zachowywane w pamięci. Oznacza to, że treści niepowiązanych z tym, czego szukają, wszystkie informacje są potencjalnie dostępne spowoduje ucieczkę ze strony. i możliwe do zapamiętania dla odbiorcy, jednak muszą być najpierw zauważone. jednak ż y t k o w n i c y Skąd Dlaczego tak się mamy wiedzieć, dzieje? Skupienie zawsze korzystają czego użytkownicy na wymagającym szukają? Tutaj z serwisu w jakimś celu zadaniu zużywa całe znowu wracamy do zasoby poznawcze badania potrzeb. - niewiele pozostaje Tworzenie person na analizowanie bodźców, które nie są czy scenariuszy użycia produktu pozwala nam bezpośrednio związane z wykonywanym zdefiniować, w jakim celu nasi użytkownicy zadaniem. Mózg, by zredukować obciążenie odwiedzają bądź będą odwiedzać stronę, poznawcze, „nauczył” się filtrować informacje, a także co może ich do tego zniechęcić. które wydają się być nieistotne z perspektywy Znając potrzeby naszych użytkowników, realizacji konkretnego zadania. możemy zacząć projektowanie.

Jak wnioski z tych badań wpływają na projektowanie serwisów internetowych? Użytkownicy zawsze wchodzą na stronę w jakimś celu: znalezienia informacji, kupienia produktu, zapoznania się z ofertą, rozrywki. Jak

Rekomendacje w projektowaniu wiedzę o funkcjonowaniu uwagi wykorzystać w projektowaniu? • Nie rozpraszaj: jeśli Twoja strona wymaga od użytkownika zastanowienia się nad jakąś kwestią bądź podjęcia decyzji, nie rozpraszaj go wyskakującymi oknami czy migającymi banerami. • Podkreślaj zmiany: jeśli chcesz, żeby użytkownik dostrzegł jakąś zmianę na Twojej stronie, nie może być ona subtelna np. jeśli etykieta przycisku „dodaj do koszyka” zmienia się na „produkt niedostępny” w sytuacji, gdy użytkownik wybierze rozmiar czy kolor produktu, którego nie ma w magazynie,

istnieje duże prawdopodobieństwo, że tej Bibliografia: różnicy nie dostrzeże. Oprócz zmiany etykiety, Książka: niech zmieni się kolor przycisku. • Nie utrudniaj: użytkownik wchodząc na Twoją stronę od razu powinien wiedzieć, co na niej może zrobić i jak ma to zrobić. Kieruj użytkownika krok po kroku do momentu, aż zrealizuje swój cel.

Podsumowanie Wraz z rozwojem technologii i metod obrazowania mózgu zwiększa się stan naszej wiedzy na temat funkcjonowania ludzkiego systemu poznawczego, jego ograniczeń i możliwości. Warto jednak pamiętać, że zanim zdecydujemy się na uwzględnienie w projekcie wniosków płynących z badań neuronalnych czy behawioralnych, musimy mieć solidną wiedzę popartą własnymi badaniami – badaniami z użytkownikami. Może się bowiem okazać, że nasz serwis, zaprojektowany zgodnie z wiedzą z zakresu psychologii poznawczej, nie zaspokaja podstawowych potrzeb użytkowników, a co się z tym bezpośrednio wiąże, nie spełnia naszych celów biznesowych. Poprzedzenie prac projektowych badaniami potrzeb jest jedynym sposobem na uniknięcie tego błędu. Dopiero wiedząc, kim są nasi użytkownicy i w jakich celach korzystają z serwisu, możemy skutecznie czerpać z dorobku nauki.

1. Krug Steve, Nie każ mi myśleć!, Gliwice, Helion, 2005, 8373616969. 2. Nęcka Edward, Orzechowski Jarosław, Szymura Błażej, Psychologia poznawcza, Warszawa, Wydawnictwo Naukowe PWN, 2013, 9788301174682

Strony internetowe: 1.https://www.nngroup.com/articles/ minimize-cognitive-load, [dostęp: 3.11.2016]. 2.http://www.helloerik.com/the-uxpsychologist, [dostęp: 3.11.2016]. Słowa kluczowe artykułu: projektowanie UX, modele mentalne, obciążenie poznawcze, uwaga, badania potrzeb

Magdalena Żądkowska – UX Specialist w Agencji UX Symetria. Na co dzień zajmuje się badaniami potrzeb i użyteczności, przeprowadza analizy eksperckie i benchmarkingowe, wykorzystując w swojej pracy wiedzę z zakresu psychologii poznawczej. Agencja UX Symetria specjalizuje się w projektowaniu złożonych interfejsów i przeprowadzaniu badań użyteczności. Od 1998 roku eksperci agencji doradzają i wykonują projekty dla dużych polskich i zagranicznych firm. Obecnymi klientami Symetrii są m. in. Alior Bank, BZ WBK, Credit Agricole, Deutsche Bank, Ergo Hestia, ING Bank Śląski, LIDL, LOT, Orange, Philip Morris International, PKO, PZU. Agencja UX Symetria jest jedynym w Polsce członkiem międzynarodowego stowarzyszenia UXalliance oraz wyłącznym przedstawicielem Certyfikatu UX PM – pierwszego na świecie Certyfikatu UX dla Project managerów. 57

Karolina Alama

Dział Prawny

Jeden konflikt- wiele ścieżek ku jego rozwiązaniu,

czyli rozwiązywanie sporów dotyczących nowych technologii - część II się z roku na rok w niebywałym tempie. A spory odsetek spraw znajduje swój finał w sądzie, Wstęp narażając strony na długotrwałe i kosztowne procesy. Co gorsza, ponieważ styk IT z IP jest owoczesne technologie otaczają w dużej mierze obszarem niezbadanym przez nas ze wszystkich stron. Nie da się prawników i orzecznictwo, spory takie obciąprzed nimi uciec (i tak naprawdę żone są dużym (i niepoliczalnym) ryzykiem. mało kto by tego chciał). Staliśmy Ta nieprzewidywalność nie dotyczy zresztą się konsumentami technologii, którzy gene- wyłącznie kwestii IP – każdy, kto miał do czyrują niekończący się popyt. Po drugiej, po- nienia z procesami dotyczącymi wdrożeń indażowej stronie stoi formatycznych wie, jak biznes zajmujący się eżeli strony trudna jest to materia generowaniem nonie uzgodniły i jak nieprzewidywalne wych rozwiązań, któmiędzy sobą zasad mogą być wyroki - i to re w ogromnej mierze zarówno ze względu postępowania, sąd związane są z szeroko na brak wyspecjalizomoże prowadzić je w sposób, pojętą własnością inwanych sądów, jak telektualną (IP). Wła- który uzna za właściwy. i obiektywnie trudną sność intelektualna materię sporu. stała się wszechobecW Polsce od zarania na – czasami może wydawać się, że podjęcie wymiar sprawiedliwości nieodmiennie kojarzy jakichkolwiek kroków związanych z biznesem się z salą sądową. Charakterystyczna atmosIT musi uwzględniać badanie ryzyk naruszenia fera, formalizm i przewlekłość postępowania, praw IP innych podmiotów. W dobie interdodatkowe koszty – takie skojarzenia budzi nacjonalizacji działalności i nieutrudnionego u większości osób hasło „sąd”. Cechy te - nieprowadzenia biznesu na właściwie nieograwątpliwie niezbyt pozytywne - sprawiają, że niczoną terytorialnie skalę, wiedza i umiejętprzedsiębiorcy traktują salę sądową jako zło ność skutecznej, międzynarodowej ochrony konieczne. Wymienione wady dodatkowo praw własności intelektualnej stały się wręcz nabierają na sile w przypadku sporów dotyniezbędne. W tym obszarze skala prawdziczących IP i IT, głównie ze względu na brak wych czy domniemanych naruszeń zwiększa

rozwiązań prawnych i orzeczeń, które umożliwiałyby rozsądne przewidywania co do wyniku sporu. Druga kwestia to upływ czasu, który stanowi o „być albo nie być” produktu, jako że efekt nowości często decyduje o sukcesie rynkowym. Wieloletni spór, blokujący wprowadzenie produktu na rynek nie wchodzi w rachubę.

Koszty sądowe również nie zachęcają do podejmowania tej drogi rozwiązywania sporów. Rekordzistą w tym przypadku są bez wątpienia Stany Zjednoczone, gdzie w przypadku sporów pomiędzy liderami rynkowymi właściwie nie ma granic. Nie sięgając daleko w gigantycznym sporze Apple v. Samsung sąd federalny przyznał Apple w sierpniu 2012 r. ponad US$ 930,000,000 za naruszenie patentów. Dla przykładu, garść danych statystycznych, W przypadku sporów dotyczących własności dotyczących postępowania w zakresie spo- intelektualnej oraz IT, oprócz szybkości w ich rów patentowych w różnych systemach praw- rozwiązywaniu bardzo istotna jest także elanych: styczność procedury ich rozwiązywania, która

Źródło: WIPO Arbitration and Mediation Center na podstawie danych dostarczonych przez The European Lawyer Ltd., Londyn 2006 („Patent Litigation, Jurisdictional Comparisons”)

Jak wynika z powyższego zestawienia, przeciętny czas trwania postępowania jest zdecydowanie zbyt długi. Po dwóch czy trzech latach postępowania blokującego komercjalizację rozwiązania, produkty tracą walor nowości i zwyczajnie przestają mieć wartość rynkową.

da stronom szansę na udział w procesie dochodzenia do konsensusu w sposób aktywny. W związku z „usztywnieniem” i niewydolnością procedury sądowej, przedsiębiorcy zaczynają więc poszukiwać innych mechanizmów, które sprostałyby ich wymaganiom biznesowym – sprawnych, mniej stresujących i mniej 59

inwazyjnych dla relacji handlowych z kontra- przez strony sporu osoby. Co ciekawe, polskie hentami, pozwalając tym samym na dalsze prawo nie posługuje się pojęciem „arbitraż”, prowadzenie współpracy w przyszłości. zastępując je określeniem „sąd polubowny” (które w mojej ocenie nie oddaje charakteOdpowiedzią na powyższe potrzeby mogą ru postępowania przed sądem arbitrażowym, być ADR (alternative dispute resolutions), czy- które niekoniecznie ma charakter ugodowy). li alternatywne metody rozwiązywania spo- Arbitrażem rządzą szczególne, odmienne od rów. Dają one szansę na rozwiązanie konfliktu postępowania przed zwykłym sądem zasady, prawnego bez konieczności uruchamiania na które strony mogą (ale nie muszą) mieć reczaso- i kosztochłonnej procedury sądowej, alny wpływ. z tym samym, wiążącym dla stron efektem, jaki wywołuje wydany przez sąd wyrok. Miejsce rozpraw zależy od specyfiki danego ADR-y to przede wszystkim arbitraż i mediacja. postępowania i wyboru samych stron – mogą Oprócz nich, szczególnie w USA, funkcjonują one same powołać sąd arbitrażowy (co nazydodatkowo takie formy jak mini-trial (skróco- wane jest sądem ad hoc) lub – co zdarza się na rozprawa), baseball arbitration, early neu- dużo częściej – skorzystać z jednego z sądów tral evaluation (ocena sprawy przez neutral- funkcjonujących na stałe przy izbach przemyną osobę trzecią) oraz tzw. formy hybrydowe, słowo-handlowych, organizacjach zrzeszajątakie jak med/arb i arb/med, będące kombi- cych przedsiębiorców etc. W Polsce jednymi nacjami tych dwóch metod. z najbardziej znanych sądów są Sąd Arbitrażowy przy Konfederacji Lewiatan i Sąd Arbitrażowy przy Krajowej Izbie Gospodarczej. JeI. Arbitraż śli chodzi o zagranicę – wymienić można ICC (sądownictwo polubowne) International Court of Arbitration czy the LonW uproszczeniu, jest to metoda rozwiązywania don Court of International Arbitration (LCIA). sporów poza sądem powszechnym, która polega na rozstrzyganiu spraw cywilnych (głów- Aby spór mógł być rozstrzygnięty przez sąd nie gospodarczych) przez powołane do tego

arbitrażowy, konieczne jest dokonanie tzw. zapisu na sąd polubowny. Zapisu tego trzeba obowiązkowo dokonać w formie pisemnej. Może on przybrać w dwie formy: może występować jako jedno z postanowień umowy głównej (wtedy nazywany jest klauzulą arbitrażową, która obejmuje przyszłe spory) lub jako oddzielna umowa, którą strony zawierają w momencie zaistnienia między nimi konfliktu. Efektem takich zapisów jest przyznanie kompetencji do rozwiązywania naszych sporów sądowi arbitrażowemu, z jednoczesnym wyłączeniem sądu powszechnego. Kolejną istotną kwestią jest brak apelacji – jeśli strony inaczej się nie umówią, postępowanie arbitrażowe jest jednoinstancyjne (czyli nie przysługuje odwołanie do wyższej instancji, co ma miejsce w postępowaniu przed sądem powszechnym). Ma to swoje duże plusy (postępowanie nie będzie się ciągnąć), ale i minusy (odwołanie od decyzji arbitrów nie będzie możliwe, nawet jak wyrok w naszym przekonaniu jest całkowicie błędny).

Sąd polubowny może powołać biegłego w sprawie, przeprowadzić dowód z przesłuchania świadków, a także z dokumentów, oględzin etc., jednak (w odróżnieniu od sądu powszechnego) nie może stosować środków przymusu. Jeśli chodzi o reżim prawny, sąd polubowny rozstrzyga dany spór według prawa właściwego dla tego konkretnego stosunku prawnego albo według ogólnych zasad prawa lub zasad słuszności (tzw. ex aequo et bono) – w przypadku, gdy strony wyraźnie go do tego upoważniły. Wyrok sądu arbitrażowego co do zasady da się uchylić, jednak nie należy traktować tego jako quasi-apelacji. W Polsce wyrok taki może zostać uchylony przez sąd powszechny tylko i wyłącznie w drodze skargi o uchylenie wyroku sądu polubownego i to w enumeratywnie wyliczonych przypadkach. Jest to m.in. brak zapisu na sąd polubowny lub jego nieważność, nieprawidłowy wybór arbitra, brak zdolności ugodowej sporu, a także sprzeczność z podstawowymi zasadami obowiązującego w Polsce porządku prawnego (czyli tzw. klauzula porządku prawnego). W praktyce jest to niezwykle trudne.

Dokonując takiego zapisu, możemy wskazać arbitrów (imiennie lub określając ich atrybuty – wiek, wykształcenie etc.), ich liczbę, procedurę ich powoływania i wyłączania (co ważne - nie muszą to być prawnicy, mogą być osoby z doświadczeniem w projektach IT), a także tryb postępowania przed sądem, jęPodsumowanie zyk w którym będzie ono prowadzone (strony mogą uzgodnić dowolny, przez nie preferoPodsumowując, teoretycznymi plusami arbiwany) itp. trażu są: równorzędność z wyrokami sądów powszechnych, szybkość rozstrzygnięcia spraZakres swobody i decyzyjności jest więc dość wy, względna elastyczność procedury (a duży. Jeżeli strony nie uzgodniły między sobą w każdym razie większy komfort i odformalizozasad postępowania, sąd może prowadzić wanie) poufność postępowania (co w wielu je w sposób, który uzna za właściwy. Zadeprzypadkach ma kluczowe znaczenie dla recyduje wtedy, czy przeprowadzić rozprawę nomy i prestiżu danej marki), możliwość wybow celu przedstawienia twierdzeń przez każdą ru arbitrów, którzy posiadać będą pożądane ze stron i dowodów na ich poparcie, czy też przez nas umiejętności i wiedzę, wykonalność przeprowadzi postępowanie i wyda wyrok na wyroków arbitrażowych w ok. 140 krajach podstawie dostarczonych przez strony dokuświata. mentów i pism, bez ich obecności. 61

Niestety, pierwsza z zalet bywa zawodna, gdyż szereg postępowań arbitrażowych potrafi trwać latami, zrównując się z postepowaniem przed sądami powszechnymi. Zazwyczaj jako plus wymienia się także niższy koszt rozstrzygnięcia sporu, jednak ta kwestia przez wielu jest poddawana pod wątpliwość, jako że w Polsce postępowanie przed sądami powszechnymi należy jednak do tych tańszych (w porównaniu np. do ekstremalnie drogich Stanów Zjednoczonych, gdzie postępowanie arbitrażowe bezwzględnie się opłaca).

ści w przepisach, nawet więcej - w wielu krajach po prostu ich nie ma.

Na polskim rynku arbitraż jest obecny, w przypadku domen internetowych stanowi wręcz jedyną metodę rozstrzygnięcia sporu. Nie zmienia to faktu, że wiele razy zapisy na sąd arbitrażowy są przeprowadzane bez świadomości kosztów i ryzyk związanych z tymi procedurami. Warto przed wyrażaniem zgody na podpisanie klauzuli arbitrażowej zastanowić się, czy w danym przepadku arbitraż ma uzasadnienie, a jeśli tak, to jaki, w którym sąNa koniec warto zaznaczyć, że prawdziwe dzie, w jakim składzie, z jaką procedurą. Nie zalety arbitrażu i jego przewaga nad postę- ma jednoznacznych odpowiedzi i nie zawsze powaniem przed sądami państwowymi ujaw- arbitraż jest dobrym rozwiązaniem. niają się w pełni w przypadku sporów dotyczących kontraktów międzynarodowych (a Niezależnie od zalet arbitrażu, pozostaje on liczba ich wzrasta dość znacząco w ostatnich sądem - ostatecznym sposobem rozwiązalatach). nia konfliktu. Wydaje się, że zbyt rzadko strony próbują podejmować czynności ugodoDecydując się na postępowanie arbitrażowe, we. W praktyce próbują negocjować ugodę jesteśmy w stanie uniknąć komplikacji spowo- samodzielnie, co jest trudne, chociażby ze dowanych różnicami w systemach prawnych względu na emocje związane ze sporem. kontrahentów, wybrać satysfakcjonujący nas Zadziwiająco rzadko używani są profesjouniwersalny regulamin sądu arbitrażowego, nalni mediatorzy, którzy dysponując wiedzą miejsce, czas i język postępowania dogodny biznesową i prawną mogą oszczędzić strodla stron sporu, co przy potencjalnej koniecz- nom wiele lat procesu i olbrzymich kosztów. ności prowadzenia postępowań w kilku krajach może okazać się zbawienne. Rozdźwięk O mediacji, jej postaciach, oraz niezwykle pomiędzy regulacjami prawnymi jest szcze- ciekawym procesie między IBM a Fujitsu w nagólnie dotkliwy właśnie w przypadku IP i IT, stępnych artykule. gdzie istnieją naprawdę znaczące rozbieżnoKarolina Alama - w Kancelarii Maruta i Wspólnicy od 2013 roku.Specjalizuje się w doradztwie z zakresu prawa nowych technologii, własności intelektualnej oraz sporów sądowych i arbitrażowych. Brała udział w projektach obejmujących tworzenie i negocjowanie kontraktów IT, w tym m.in. umów wdrożeniowych, serwisowych, licencyjnych oraz w audytach i stałym doradztwie prawnym. Uczestniczyła w sporach sądowych i arbitrażowych z zakresu prawa własności intelektualnej oraz prawa IT. Uczestniczka programu podyplomowego Computer and Communications Law Queen Mary University of London. Doktorantka prawa oraz absolwentka Wydziału Prawa i Administracji UW, Wydziału Zarządzania UW oraz Wydziału Ekonomii University of Skovde w Szwecji. Członkini Chartered Institute of Arbitrators w Londynie (tytuł MCIArb). Mediatorka sądowa wpisana na listę Sądu Okręgowego w Warszawie oraz w Krakowie. Uczestniczka szkoleń zawodowych z zakresu rozwiązywania sporów dotyczących własności intelektualnej i nowychtechnologii w World Intellectual Property Organization (WIPO) w Genewie. Autorka publikacji z zakresu rozwiązywania sporów w języku polskim i angielskim oraz uczestniczka międzynarodowych konferencji naukowych. 62

Dziel się swoją wiedzą i doświadczeniem! Dołącz do autorów!

Facebook

http://www.facebook.com/reqmagazyn

Linkedin https://www.linkedin.com/ groups/8527476

Reklama

kontakt@reqmagazyn.pl

Współpraca

Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: kontakt@reqmagazyn.pl 65