Sztuczki w Balsamiq

Uwielbiam makiety w rozumieniu prototypów aplikacji. Dlaczego? Bo to świetny sposób na pokazanie użytkownikowi jak aplikacja będzie wyglądać zanim jej kodowanie się zacznie (pozwala to też przedyskutować zbyt abstrakcyjne dla 'biznesu' rzeczy na "żywym" przykładzie).

Balsamiq jest programem, dzięki któremu możemy stworzyć pliki pdf w które da się klikać. Nawet najbardziej oporny użytkownik nie pomyśli, że to jest już 'prawie' gotowa aplikacja (więc nie ma niebezpieczeństwa, że poprosi o jej wdrożenie... jutro!). Makiety robione w narzędziach typu 'Just in mind' są łudząco podobne do aplikacji, co może być mylące i... użytkownik może pomyśleć, że aplikacje jest prawie gotowa ;)

Mam nadzieję, że udało mi się was zachęcić do prototypowania. Poniżej kilka wskazówek jak zabrać się za robienie makiety w Balsamiq:

• zaplanuj jak wygląda "flow" w aplikacji
• wybierz opcje które chcesz pokazać (lepiej wybrać parę różnych niż takich które wyglądają bardzo podobnie do siebie)
• zastanów się na sekwencją, którą użytkownik powinien podążać klikając w prototyp
• przygotuj sobie szkielet dla wszystkich ekranów (obrazy które pokazują stan aplikacji)
• przygotuj ekrany które odpowiadają zaplanowanej sekwencji (jedna akcja - jeden obraz)
• stwórz linki między ekranami
• zapisz jako Pdf
• gotowe :)

Zajrzyj do innych notek o prototypowaniu!

Makiety w VS

Balsamiq

Just in mind

Bajka o kopciuszku

Znacie historię Kopciuszka?

Właśnie ta bajka stanowiła inspirację dla mojego dzisiejszego warsztatu świątecznego :) Mam nadzieję, że wam się spodoba! 

Aplikacja od początku do końca - czyli skąd programiści wiedzą co pisać? from Kasia Mrowca

Kanban-ish

Wiecie co jest najlepszą częścią meetup'ów i innych spędów dla pasjonatów IT? Nieformalne dyskusje po! 

Ok, ale może zacznę od początku i małego wprowadzenia. W zeszłym tygodniu byłam na spotkaniu ALE Kraków - warsztat prowadziła +Oana Juncu, a mówiła o Innovation@Games. Warsztat był podzielony na część teoretyczną i praktyczną (i jak podejrzewacie, ta praktyczna najbardziej mi się podobała ;)). W czasie tej krótkiej sesji grupom warsztatowym udało się stworzyć projekty w formie papierowych mockup'ów bardzo ciekawych aplikacji. Nie mogę się już doczekać, aż zastosuję tą metodę w pracy :)

Oczywiście po zakończeniu szkolenia, była dyskusja. Dla mnie szczególnie inspirująca ponieważ Oana pracowała w Eurosporcie, więc mogłyśmy wymienić opinie na temat wyzwań jakie stawia IT 'klient' jakim jest telewizja. Bardzo inspirujące! Ale nie o tym dziś. Dyskusja była też o innych ciekawych trendach związanych z IT. Bardzo podobała mi się dyskusja o Kanbanie, który stanowił przykład 'przestrzegania zasad metodyki'. Dużo ludzi używa Kanbanu, ale pytanie brzmi: czy używają tego poprawnie? Jak użyć Kanbanu efektywnie? Oczywiście zdania były podzielone, ale konkluzją było:

• metodyka (Kanban i każda inna) jest dla ludzi, a nie na odwrót,
• ludzie mogą (i powinni!) dostosowywać ją do swoich potrzeb,
• przestrzeganie reguł od A do Z nie koniecznie przyniesie oczekiwane rezultaty, 
• nie ma nic złego w używaniu czegoś Kanbano-podobnego dopóki to działa - to dotyczy także innych metodyk!  

Przykład tablicy Kanbanowej. Źródło: http://www.iddblog.org/?p=1150

A tak przy okazji - pamiętacie o moim jutrzejszym warsztacie? Do zobaczenia! 

Świąteczne warsztaty

Już w następną niedzielę prowadzę kolejny warsztat dla Analityków, Product Ownerów i nie tylko! (Spokojnie, jak masz z tą działką nie wiele wspólnego a temat Cię interesuje - zapraszam, na pewno będzie coś interesującego i dla Ciebie). 
Tym razem przedstawię tajniki zbierania wymagań... w formie świątecznej baśni :) Będzie świetna zabawa! 

Temat: Aplikacja od początku do końca - czyli skąd programiści wiedzą co pisać?
Koszty: Za darmo, ale wymagana rejestracja: http://swietaggc.evenea.pl/ 
Kiedy: 15.12.2013, 17:00
Gdzie: Pauza In Garden, Rajska 12, 31-124 Kraków

View Larger Map

Do zobaczenia! 

Warsztaty - relacja

I już po warsztatach dla inicjatywy "Jestem Informatyczką", której patronuje PTI.

Organizacja całego wydarzenia - pierwsza klasa :) A to wszystko dzięki +Alicji, która rozkręca inicjatywę "Jestem Informatyczką". Już niebawem na pewno będą kolejne ciekawe wykłady :) 
Wielkie podziękowania dla pani fotograf, która zadbała o to aby wydarzenie było dobrze udokumentowane :) Część zdjęć możecie zobaczyć poniżej. +Agnieszka - dziękuję!

Slajdy można zobaczyć >>tu<<

A teraz pora na zdjęcia!

O to widownia :) fot. Agnieszka Celińska

O to ja  :) fot. Agnieszka Celińska

A tu wspomaganie (prawie) tradycyjną tablicą suchościeralną ;) fot. Agnieszka Celińska

Aktywna publiczność - taką lubię najbardziej! fot. Agnieszka Celińska

Warsztaty dla analityków

Hej!

Prowadzę warsztat ciekawy warsztat niedługo ;) Zainteresowanych zapraszam i zachęcam do zapisania się >>tu<<

Szczegóły:
Temat: Z IT NA NASZE, CZYLI NA CZYM POLEGA PRACA ANALITYKA IT?
Kiedy: 28.11.2013, 18:15
Gdzie: UP Kraków

Agenda:
1. Czym jest analityk IT i jaka jest jego rola?
2. Niezbędnik technologiczny - czyli na czym znać się analityk powinien
3. Szczypta psychologii
4. Techniki ułatwiające życie: od mindstormingu po UML 
5. Oprogramowanie wspomagające "kartkę i papier" - czyli tajniki wizualizacji
6. Polecana literatura

Do zobaczenia! 

Prototypy w Visual Studio?

Śmiała myśl, czyż nie? Dla programisty pewno oczywistym jest stworzenie prototypu w Visual Studio albo innym IDE. Dla mnie VS było ostatnim narzędziem, które wybrałabym do robienia makiet… Jednak kolega zasugerował aby spróbować tego narzędzia.

I tak zaczęła się przygoda. Aplikacja była mobilna, więc czyste VS wydawało się nie wystarczające (kobieta jestem, więc wygląd ma znaczenie). Tak, Microsoft Blend był tym czego potrzebowałam… albo takie pozory przynajmniej sprawiał ;) Jak się domyślacie, okazało się że idealną parą do Blenda jest… PhotoShop. Niestety moja licencja na PS wygasła dawno temu. Finalnie powróciłam do VS.

Po tym przydługim wstępie, pora na najciekawszą część – moje odkrycia ;)

Wady prototypowania w VS:

-          trzeba trochę znać programowanie

-          standardowe gui jest brzydkie… więc jak nie masz umiejętności aby podgładzić interfejs, to makieta jest brzydka

-          wygląda jak prawdziwa aplikacja (użytkownik może nie pojąć, że to tylko atrapa)

-          kuszące jest dążenie do zrobienia idealnego narzędzia od razu… powoduje to spędzenie masy czasu nad dopieszczeniem makiety, która z założenia ma się zmień… (user na pewno powie że chciał przecież co innego, czyż nie?)

Zalety:

-          Zdecydowanie szybciej można zrobić prototyp w VS niż w narzędziach “klikalnych” (jeśli znasz się ciut na programowani I nie popłyniesz z perfekcją za bardzo ;))

-          Limitem jest tylko Twoja wyobraźnia (można zrobić absolutnie wszystko jeśli umie się… programować ;))

Tak… lepiej zostanę przy moim ulubionym balsamiq :)

Confitura video

Już jest! Już jest! Już jest... wideo z confitury :)
Miłego oglądania!

Conferences

Warsjawa i JDD - pracowity weekend i początek tygodnia. Na obu konferencjach prowadzę warsztaty. Już nie mogę się doczekać.

Zastanawia mnie tylko - gdzie są dziewczyny? Zobaczyłam na listę prelegentów i...:

• na JDD jestem jedyna,
• na warsjawie jestem jedyna "techniczna" (druga prelegentka prowadzi warsztaty z umiejętności miękkich)

* choć słowo techniczna chyba mało do mnie pasuje ;) Statystyczna już tak!

Zmiana: jedyna pewna rzecz w IT

Zmiana jest naturalną rzeczą jeśli chodzi o organizacje. Rynek zmienia się często i szybko. Chyba już nie istnieją sektory czy branże, które są "stabilne" (czasami się zastanawiam czy takie kiedykolwiek istniały, może to tylko miejska legenda?). IT ma za zadanie wspierać biznes, więc powinno być elastyczne. Systemy powinny pozwalać na szybkie zmiany. Oczywiście łatwo powiedzieć, ale czy równie łatwo zrobić? 

Nowoczesne metodologie pozwalające na zarządzanie projektami/produktami IT pozwala na szybką reakcję na zmiany (Scrum i generalnie cały agile, lean oraz inne), niemniej jednak sama metodyka to nie wszystko.


Elastyczne założenia

Brzmi dziwnie, nieprawdaż? Podczas zbierania wymagań, trzeba zrobić założenia. Skoro to założenia to powinny być przecież stabilne! Praktyka brutalnie uczy, że założenia wyglądające jak skały tatrzańskie albo i nawet same Tatry także mogą zostać ruszone w rozumieniu zmienione (znacie powiedzenie o przenoszeniu gór? pasuje tu!). Myślę, że nawet założenia związane z teorią grawitacji mogą zostać podważone na gruncie IT ;)

Ok, co można zrobić aby oswoić zmianę?

Architektura - małe moduły/funkcjonalności którą są niezależne (na tyle ile to możliwe)

Plan - długoterminowe plany są ok, ale tylko gdy nie są zbyt szczegółowe. Długoterminowa wizja jest ważna, ale szczegółowy plan powinien być wytyczony tylko dla krótkiego okresu. Trzymanie się kurczowo planu długoterminowego, podczas gdy rzeczywistość się zmieniła, nie jest dobrym pomysłem (chyba że naszym celem jest dostarczenie bezużytecznego narzędzia). 

Wymagania - bądź pewny że się zmienią w czasie. Napisz je tak aby umożliwiały nagłe zmiany (zwłaszcza w strategicznych obszarach).

Założenia - sprawdzaj od czasu do czasu czy się nie zmieniły. Niestety, do końca świata nie zostaną takie jak były na początku :(

Metodologia - nie jest to koniecznie Twoja brożka, ale jak możesz to wybierz taką która jest elastyczna, lekka i wspomagająca zmiany. 

Jest mnóstwo innych rzeczy pomagających adaptować się do zmiany: continuous delivery, continuous integration, całe mnóstwo metodyk testowania itp. Zatrzymam się jednak tu. Może kiedyś napiszę o tym z punktu widzenia analityka ;) Może być interesująco! 

Pamiętaj! Do not underestimate the power of change!

BABOK

Gratka dla analityków - książka BABOK (Business Analysis Body of Knowledge) jest dostępna na Google Books! Lektura obowiązkowa dla wszystkich chcących zgłębić tajniki analizy biznesowej. 

Zainteresowany? >>Kliknij<< Książki wygląda na kompletną (bez ograniczeń co do stron), ale nie można ściągnąć. 

źródło: okładka książki BABOK

New toy

R jest jedną z moich ulubionych statystycznych zabaweczek... upsss... narzędzia chciałam powiedzieć :) Mam nadzieję, że pamiętacie moją recenzję

Ostatnio znalazłam ciekawy pakiet do R - rattle się nazywa. Jest dedykowany do data miningu i na pierwszy rzut oka wydaje się... przeładowany. Zaletą R jest prostota - skromne menu, trochę toporny design i moc kryjąca się w komendach pozwalających liczyć statystyczne cuda. 

Szybkie spojrzenie na konsolę R przed załadowaniem rattle:

I zaraz po jego załadowaniu:

Ogromna różnica! Pierwsza myśl: jak tego użyć?! Wygląd był jednak zwodniczy i pakiet jest całkiem przyjazny, jak się wie co się chce policzyć ;)

R in data mining

Prowadzę dwa warsztaty z Data Miningu i R w przyszłym tygodniu (pierwszy na Warsjawa, drugi na JDD).
Podczas przygotowywania znalazłam to:

źródło: dilbert.com

Piękne!

P.s. Zastanawiam się czy może słowo "wykopałam" nie było by lepsze niż znalazłam w kontekście owych warsztatów ;)

Mity i problemy w Agile - mity o Scrum

Byłam dziś na szkoleniu. Ha – już pewnie wiesz o czym! Tak, to był agile (dokładniej scrum)!

Wydarzenie było mniej więcej darmowe. Umowa była w czymś rodzaju barteru – codespronters dostarczali szkolenie, a uczestnicy 8h pracy dla społeczności. Bardzo inspirujący pomysł!

Warsztat miał szeroki zakres i zdecydowanie był przeprowadzony w duchu agile. Zawartość dostosowywała się do potrzeb uczestników płynnie i szybko.

Ok, ale zobaczymy na szczegóły:

Temat: Mity i problemy w Agile - mity o Scrum

Cena: 8h pracy na rzecz społeczności

Zawartość: super

Ocena ogólna: warto pójść! 

Moja lista tematów na notki zdecydowanie się wydłużyła po tym szkoleniu! Szkoda, że doba ma tylko 24h. 

źródło obrazka: http://www.mypmhome.com/scrum-methodology/

Video

Film z WebMuses Unplugged już jest!Ciekawe kiedy będzie film z Confitury... Już się nie mogę doczekać!

Miłego oglądania!

You are fan of startups, aren’t you?

Jestem fanką meetupów. Wczoraj byłam na ' ALE Kraków: http://www.meetup.com/ALE-Krakow/events/140893652/ 

Temat: "Getting out the door: Managing new product development using Scrum, Lean Startup, and Reality!". Nie jestem zaangażowana w nic związanego ze startupami, ale inne 'składniki' tematu brzmiały interesująco. W praktyce było głównie o startupach. Nie zmienia to faktu, że bawiłam się dobrze, prezentacja była ładna aczkolwiek merytorycznego jej poziomu nie jestem wstanie ocenić. Po prostu - nie wiem wiele o startupach i ich problemach (prelegent parę problemów wskazał i próbował dodać receptę na ich rozwiązanie). 

Po meetupie uczestnicy są proszeni o ocenę eventu - i tu pojawia się inspiracja do dzisiejszej notki. Próbowałam ocenić spotkanie, ale:

1. Wysoka ocena byłaby nierzetelna (nie znam się na tym o czym mówiono)

2. Niska ocena byłaby niesprawiedliwa

Szczerość wygrała i napisałam co myślę. Jak się mogłam spodziewać posiadanie własnego zdania okazało się kontrowersyjne. Zawsze kiedy przyznam się iż nie podążam za startupowym tredem, następuje oburzenie (tak, to wydaje się być zbrodnią). Tak było i tu, na całe szczęście w łagodnym i kulturalnym wydaniu. 

Niestety nie jestem wstanie zrozumieć cóż jest złego w tym, że nie szaleję za startupami. Niestety (czego bardzo żałuję) nie jestem wstanie być ekspertem we wszystkim :( Wiem, że startupy istnieją i życzę im wszystkim dużo szczęścia. Nie jestem ani za nimi ani przeciwko nim. Tak się jakoś złożymy że istnieją obok mnie w tym samym wszechświecie. Kto wie? Może kiedyś nasze drogi się skrzyżują i pokocham je całym sercem ;) Niestety moja szklana kula zaliczyła blue screena i nie jestem wstanie przewidzieć przyszłości ;)

Na koniec smutna rzecz (nie dotycząca tylko startupów). Ludzie lubią 'zmuszać' innych do podążania za trendami i stawiania się po jednej ze stron barykady (kochasz lub nienawidzisz*). Zawsze mnie ciekawiły powody takiego zachowania... Śmieszna rzecz: mocno zaangażowane emocjonalnie osoby (będące bardzo za albo bardzo przeciw) czasami nie mają nic wspólnego ze startupami - nie mają żadnego ani nigdy w takowym nie pracowały. 

Może kiedyś ktoś mnie przekona... (jest różnica między przekona a zmusi ;)) i zmienię zdanie. Póki co, dziękuję postoję ;) 

* angażowanie skrajnych emocji w 'wybieranie stron' to jest kolejne znajwisko, którego nie rozumiem

WebMuses unplugged

Cześć!

WebMuses unplugged to było mega wydarzenie. Warsztaty w okolicach IT ale bez komputera i na świeżym powietrzu – czyli to co tygryski lubią najbardziej ;)

Idea trzeba przyznać świetna, sama impreza super zorganizowana – całość oceniam bardzo pozytywnie. Nawet pogodowe małe figle nie były wstanie bardzo jej zakłócić.

Przejdę może już do sedna, bo wychwalać pod niebiosa WebMuses mogłabym bez końca ;)

Na moim szkoleniu opowiadałam i pokazywałam „z czym je się” UMLa a dokładniej Use Casy oraz schemat blokowy (czyli coś co UMLem nie jest ;)).

Wyszła z tego super zabawa! Już nie mówiąc o tym, że część schematów narysowana przez uczestników, przechodziła moje najśmielsze oczekiwania ;)

Po wersji papierowej, warto zerknąć jak to wygląda w oprogramowaniu (bardzo się nie różni ;) może linie są odrobine prostsze ;)). Tu są przykładowe schematy w wersji super podstawowej w EA*: >>klik<<.

Materiały opisujące podstawy UML i schematu blokowego możecie znaleźć w >>notce<< 

*Co to jest EA? Enterprise Architect – narzędzie do rysowania, które uwielbiam. EA można pobrać >>stąd<<

Enjoy :)

WebMuses

Cześć!

Tu >>klik<< są matriały z dzisiejszego szkolenia :)

BI or not to BI

To jest tytuł konferencji, na której (uwaga, uwaga) nie byłam. Ale tak mi się spodobał, że postanowiłam go zaadoptować do swoich niecnych notkowych celów.

Dla niewtajemniczonych BI = Business Intelligence.

Pisałam wam o szkoleniu na którym byłam niedawno? Pisałam!Otóż ono było właśnie z tematyki BI – bardzo mi się podobało. Odkryłam wręcz swoją głęboko skrywaną miłość do BI gdyż jest to… analiza danych. I to całkiem zaawansowana!

Zacznę od tego, że przed samym szkoleniem się trochę bałam, bo wg opisu to było dla programistów i administratorów (a ja przecież analitykiem jestem). O ile samego SQLa jeszcze używam i pisanie zapytań jest takim dużym problemem, to już część związana z administrowaniem wydawała się przerażająca. Całe szczęście jak wszystko co Microsoftowe – dało się wyklikać.

Samo szkolenie było w Comarchu (pisałam już o tym nawet w notce;)) a jego tytuł to:

Microsoft SQL Server - Analysis Services

Wykładowca (P. Grzegorz Stolecki)  był bardzo kompetentny i z talentem do transferowania wiedzy nawet do odpornych na wiedzę stworzeń mojego pokroju ;) 

Zdecydowanie polecam!

Ice Age

Dawno temu, za budowlami, drogami i rzeką - byłam na konferencji PAM Summit. Udało mi się wtedy wygrać szkolenie w Comarchu pt. "Harmonogramowanie".

Tytuł posta może wydawać się zaskakujący, po tym krótkim wstępie - aczkolwiek proszę Cię o cierpliwość czytelniku. 

Zacznijmy może od tego, że szkolenie które wygrałam zostało odwołane (nic dziwnego, wakacje są - ludzie wolą korzystać z pogody na łonie natury niż siedzieć w czterech ścianach). Na szczęście nie musiałam czekać do kolejnego terminu szkolenia (potencjalnie jakoś jesień/zima) tylko mogłam dołączyć do innego które się odbędzie i będzie mi pasować z tematyką. Muszę przyznać, że to było niezwykle miłe ze strony Comarchu :)

Zaskoczę was trochę, bo o merytorycznych wrażeniach ze szkolenia napiszę w przyszłości ;) Tu się skupię na Comarchu jako firmie szkoleniowej. Dlaczego? Bo byłam w szoku, że tam jest tak fajnie :)

1. Sala szkoleniowa - dobrze wyposażona, o dziwno był tam przyzwoity komputer więc nie trzeba było tachać własnego (a już byłam na paru technicznych szkoleniach gdzie trzeba było tachać własny sprzęt i wydawało mi się, że to jest norma... a tu miła niespodzianka).

2. Materiały szkoleniowe - książka. Nie tysiące karteczek wpiętych do ciężkiego i topornego segregatora. No i oczywiście materiały od szkoleniowca w formie elektrycznej (pliki z bazą na której ćwiczyliśmy, parę przydatnych skryptów które też były na bieżąco robione - także elegancko).

3.  Jedzenie - trzeba przyznać, stołówka Comarchu całkiem dobrze karmi. Tu też wszystko pięknie ;)

4. Katering - kawa, herbata, ciasteczka. Standardzik. 

I wszystko byłoby idealnie gdyby nie... klimatyzacja. Pierwszego dnia było mi tak zimno, że ciężko było mi palcami trafić w klawiaturę... Dodam jeszcze, że na zewnątrz było ok 16 stopni i w odczuciach moich to była wyższa temperatura niż ta panująca na sali... W kolejne dni się "wycwaniłam" i siedziałam opatulona w sweter i kurtkę. Niestety tak czy siak nic to nie dało, bo się rozchorowałam :/

Dobra, zapytacie dlaczego nie poprosiłam o skręcenie klimy? Prosiłam! Ale jest ona centralnie sterowana i się nie dało. Pozostało zamarzać. 

Także jak ktoś z was kiedyś się będzie wybierać na warsztat do Comarchu (co gorąco polecam) radzę ze sobą zabrać kożuch :)

WebMuses Unplugged

31 sierpnia - koniec wakacji... i dzień w którym odbędą się warsztaty WebMuses Unplugged :)

I powiem wam więcej - ja też tam będę! Udało mi się zdobyć bilety na te warsztaty które mnie interesują, dodatkowo...

... będę prowadzić także własny :)

Szybkie podsumowanie o czym będę prawić:

1. Temat: "kombinacje projektowe z wymaganiami w tle" 

2. Opis: Tajniki skutecznego zbierania wymagań oraz projektowania aplikacji przy użyciu... kartki i papieru :)

3. Czego się nauczysz? Podstawowych technik zbierania wymagań, prostej i szybkiej wizualizacji zachcianek naszych ukochanych użytkowników oraz rysowania podstawowych schematów dzięki którym dogadasz się z programistami.

Co prawda biletów już nie ma, aczkolwiek można jeszcze na nie próbować polować: http://webmuses-unplugged.evenea.pl/

A tu strona wydarzenia na Facebooku: https://www.facebook.com/events/557350894323676/

Do zobaczenia!

VirtualStudy.pl

Jestem wielką fanką e-Learningu, dlatego z przyjemnością wypróbowałam platformę do nauki zdalnej z rodzimego, polskiego podwórka - VirtualStudy.pl. Dostępne materiały są związane głównie z IT (superancko) - brzmi obiecująco! Jeśli chodzi o merytoryczny poziom materiałów szkoleniowych, jest on całkiem wysoki (ok, nie oglądnęłam wszystkich - ale te na które trafiłam, były warte tego aby im poświęcić czas). 

Niestety moje pozytywne podejście legło w gruzach przez... funkcjonalność platformy. Może gdybym brała udział w zajęciach na żywo (bo takie też są dostępne) moje doświadczenia byłby lepsze...

Co mi się nie podoba?

1. Główna wyszukiwarka na stronie głównej nie wyszukuje w materiałach do nauki :( Odnośniki są do aktualności (choć nie wiem na 100% do czego to coś kieruje) a żeby było zabawniej w nich są kolejne odnośniki tym razem kierujące na... sami zobaczcie: 

Nawet chciałam wysłać wszystkie tego typu linki do autorów, ale po 15 minutach zmuszenia wyszukiwarki do działania, znudziło mi się już kolekcjonowanie błędnych odnośników. Naprawdę, wyglądało to tak jakby jedyną treścią strony był "error 404" :/

1. Materiały są dostępne pod zakładką "publikacje". Jak dla mnie brzmi to jak materiały szkoleniowe i przyznam się szczerze, że akurat tam zajrzałam na końcu...
2. Zakładka z publikacjami ma drugą wyszukiwarkę (ok, to jest niby filtr ale dla nie-IT użytkownika to jest po prostu zwykła wyszukiwarka w której może wpisać cokolwiek, taka sama jak ta 10cm wyżej...). Oczywiście jak ustawiłeś filtry i chcesz je wyczyścić, to nie może być standardowo. O nie! Ikona do czyszczenia przedstawia "haczyk" zamiast standardowej gumki do mazania. Proste jak drut. Kolczasty.
3. Nie ma opinii użytkowników pod materiałami (albo w ich najbliższej okolicy). Można je znaleźć na forum - więc za dużo klikania jak dla mnie (za leniwa jestem ;)). 

Zdecydowanie virtualstudy w mojej ocenie wygrało konkurs na najbardziej nieprzyjazną platformę do nauki. Zaskakujące jest to, że wrócę tam z uwagi na zawartość. Dobra treść jest jednak kluczem do sukcesu!  

Paper Cup

Ok, to zacznijmy od małej zagadki - jak myślicie co to jest "Paper Cup"? Oczywista odpowiedź się nie kwalifikuje! 
Ok, to let's begin from small riddle - what do you think the Paper Cup is? The obvious answer don't count. 

I tak, rysunek jest zwodniczy ;) Bo nadal Paper Cup nie jest papierowym kubkiem ;)

Nie będę trzymać was w niepewności - to jest klub "czytaczy" w Londynie (ciekawe czy ktoś zgadł ;))

Ogólne wrażenia z meetup'a:

- zwariowana nazwa

- interesujący temat i dyskusja

- przyjazna atomosfera

- fajna lokalizacja

Zdecydowanie warto było pójść ;)

Tak, tak - uważny czytelnik zauważył że meetup był w Londynie, czyli dość niecodziennej lokalizacji jak dla mnie ;) Cóż natura geek'a zwyciężyła i zrobiłam sobie przerwę w zwiedzaniu. Dzięki +Andrzej Grzesik, za zaproszenie!

Kartka i długopis

“Any sufficiently advanced technology is indistinguishable from magic”

"Każda wystarczająco zaawansowana technlogia jest nierozróżnialna od magii" 

Arthur C. Clarke

...ale nie może zastąpić długopisu oraz papieru (albo markera i tablicy) podczas dyskusji nad wymaganiami do projektu (oraz zapewne w przypadku tysięcy innych przypadków :))

Source: http://themediahaus.wordpress.com/2013/06/06/the-value-of-putting-pen-to-paper-in-a-digital-world/

Dlaczego?

• Łatwość użycia (każdy potrafi obsłużyć kartkę i długopis)
• Nielimitowana dostępność (nie trzeba mieć licencji)
• Szybkość (zmiany mogą być natychmiastowo)

Ok, a co w przypadku zespołów pracujących na odległość? 

Tak, używanie papieru może stanowić tu wyzwanie ale za to tablica świetnie się sprawdza (jeśli dołożymy do niej kamerę ;)). Tylko pamiętajcie aby zrobić pod koniec spotkania zdjęcie tablicy to i od razu dokumentacja będzie ;)

Nowy blog

Nie dużo postów było w tym tygodniu. A wszystko przez to, że... mam nowy blog, o szwedzkim :)
http://svenska-swedish.blogspot.com/

Ale nie martwcie się, tu będę nadal pisać :) Może nawet będą notki po szwedzku?

Chce != potrzebuje

Ciężki chleb powszedni związany z wymaganiami to… nie uleganie koncertowi życzeń. Użytkownicy dużo chcą, czasem biznes chce nawet za to zapłacić ale… No właśnie, czy jest tu ale? Może IT powinno się cieszyć, że ma robotę?

Kogo słuchać?

To może zacznijmy od tego, od kogo zbierać wymagania? Użytkownik końcowy, użytkownik kluczowy a może właściciel biznesowy? Nie ma idealnej odpowiedzi i na pewno trzeba wysłuchać wszystkich, którzy w temacie są zainteresowani (czyli pozostałych interesariuszy, których nie wymieniłam także ;)). Zwłaszcza w agile kładzie się nacisk na słuchanie użytkownika, ale… No właśnie jest ale. Nie mówię, tu że użytkownik końcowy powinien zostać pominięty, aczkolwiek należy pamiętać że w większości wypadków systemy informacyjne to zespół naczyń połączonych i trzeba widzieć szerzej niż tylko swój kawałek aplikacji. Użytkownik kluczowy powinien w tym względzie być bardziej „uświadomiony” i przesiać wymagania z koncertu życzeń pod względem merytorycznym. Choć istnieje jeszcze przypadek, gdy użytkownik ani końcowy ani kluczowy nie ma nic do powiedzenia i system jest zdominowany przez właściciela biznesowego (święte jego prawo, płaci to wymaga). Jeśli za tym kryje się wizja i przy okazji dana osoba doskonale zna potrzeby użytkowników, to może tragedia się nie wydarzy. Aczkolwiek jak to jest trochę balansowanie na krawędzi przepaści (nie polecam, nawet dla osób lubiących sporty ekstremalne).

Może poprzestańmy na tym, że wysłuchać trzeba wszystkie strony. 

Co wybrać?

Kategoryzacja i wybór tego co jest do zrobienia to inna kwestia. Ciężkim kawałkiem jest wybranie tych elementów które faktycznie przybliżają biznes do osiągnięcia celu biznesowego. Jeszcze ciężej przekonać biznes, że ich wymarzona funkcjonalność nie jest potrzebna… Zaraz, zaraz – wróćmy do początku. Czy nie powinniśmy być szczęśliwi że mamy co robić, a nie odsiewać pomysły?! Odpowiedź brzmi NIE. Jak jesteśmy działem IT wewnętrznym – to zależy nam przecież aby firma nie marnotrawiła pieniędzy. Jak jesteśmy zewnętrzną firmą IT – to zależy nam na tym, aby klient był zadowolony. A nie będzie zadowolony jak dostanie funkcjonalności z których nie korzysta a do tego obraz rozpaczy dopełni  odpowiednio wysoka faktura…

Po co?

Analityk omnibusem nie jest, więc warto aby zadawał magiczne pytanie: „po co” (dlaczego to wiemy, aplikacja ma pomagać albo zarabiać, albo ciąć koszty*, wyjątek stanowią aplikacje urzędów których celem istnienia jest irytowanie petentów </joke>). Jak wiemy po co, to możemy zamodelować odpowiednie rozwiązanie. Plus doradzić co generuje koszty, a nie przybliża nas do osiągnięcia celu biznesowego (tak, tak – po to aby to wyrzucić do kosza, albo chociaż przesunąć na koniec kolejki do zrobienia i liczyć po ciuchu że z czasem upór na wykonanie danej funkcjonalności mnie). 

Podsumowanie w dwóch słowach: „po co?”. 

* ułatwienie pracy wlicza się w to. Pracownik który sprawniej wykonuje zadania (szybciej, robi mniej błędów itp.) ma większą wydajność i większe moce przerobowe. Jeśli to jest pracownik który był „wąskim gardłem” to według teorii łańcucha krytycznego, odciążenie go spowoduje szybsze wykonanie pracy. Nie wgłębiając się w teorie bardziej: wszystko sprowadza się do pieniędzy :)

Małe porównanie

Ciąg dalszy nastąpił :)

Teraz mega skrótowo najważniejsze (moim skromnym zdaniem) elementy wspólne

1.       Business Analyst i Project Manager

a)      Czas + budżet + zakres => planuje Project Manager, ale wchodzi to w skład analizy. Dlaczego? Bo projektując rozwiązanie nie bacząc na ograniczenia jesteśmy zawsze skazani na porażkę.  Dodatkowo często z uwagi na ograniczenia właśnie zakres projektu musi być dobrze skonsultowany z klientem biznesowym, co za tym idzie – musi się to wiązać z opracowaniem odpowiednich wymagań.

Sławny trójkąt ograniczeń :)

b)      Harmonogramowanie => teoretycznie też PM ale… zwłaszcza pracując w agilowych metodologiach BA musi mieć przynajmniej świadomość który modułu kiedy ma być gotowy. Inna kwestia że to właśnie BA wie jaką wartość biznesową mają poszczególne elementy dla klienta, a z tego także wynika kolejność wdrożenia.

c)       Analiza ryzyka/zarządzanie ryzykiem => trochę analogicznie jak w poprzednich podpunktach. Teoretycznie to PM uwzględnia ryzyka w karcie projektu. Z drugiej strony BA także powinien je uwzględnić spisując wymagania i zostawiający tym samym „wyjście” awaryjne gdyby dane ryzyko wystąpiło (np. mamy system finansowy, zagrożeniem jest zmiana przepisów prawnych która wpływa na sposób wyliczania podatków – ryzyko wystąpienia tego zdarzenia jest tak duże, że w wymaganiach powinno być to uwzględnione na tyle, aby przynajmniej nie usztywnić systemu w tym zakresie).

źródło: dilbert.com

2.       Business Analyst i UX Designer

a)      Obserwacja pracy użytkownika w celu dobrania rozwiązania => obie osoby to robią J W przypadku BA przygląda się on raczej całemu procesowi, aczkolwiek samej aplikacji także. Na etapie zbierania wymagań często zdarzają się takie dotyczące użyteczności. Jak w firmie nie ma dedykowanego projektanta to BA się nimi zajmuje.

źródło: http://muharikah.com

b)      Wymagania co do funkcjonalności =>  chyba nie wymaga komentarza ;) No może BA bardziej skupia się na merytorycznym aspekcie związanym z celem powstania systemu, niż na tym jak rozmieścić kontrolki co do pixela ;)

żródło: http://ideas2action.pl

c)       Prototyp – często jako narzędzie wspomagające komunikacje jest wykorzystywany prototyp. Głownie aby sprawdzić czy wszystkie wymagania są spełnione ;) aczkolwiek wymaga to także zaprojektowania interakcji – więc element wspólny z projektantem jest.

źródło: http://www.bindulski.pl

3.       Business Analyst i Product Owner

Jak dla mnie granica jest tu bardzo cienka. Na oko BA jest bardziej po stronie biznesu a PO bardziej po stronie IT. Aczkolwiek to zależy :) Jako że jestem tym i tym, to wolałabym się nie wypowiadać w kwestii różnic ;)

Tak na koniec: myślę że nie warto przykładać wagi do nazwy stanowiska. Jest to kwestia czysto definicyjna, więc równie dobrze można by je nazwać „zielony słonik” i byłoby to równie jasne jak niektóre obecne nazwy ;) Zdecydowanie lepiej skupić się na wymaganych kompetencjach i umiejętnościach. A to może także spróbuję niebawem dla was rozszyfrować ;) 

Definicja to podstawa!

Czym się zajmuje Analityk IT na naszym polskim podwórku?

Temat prezentacji na ostatnim GGC został zainspirowany przez +Agnieszkę Leśniewską . Agnieszka bowiem zapytała mnie czymże to ja zajmuje się w pracy jako Analityk Systemów Informacyjnych i czy jest to, to samo co Analityk Systemowy. Tak zaczęła się moja przygoda z próbą zdefiniowania cóż na Polskim podwórku oznacza analityk.

Jak możecie się domyślić – co firma to inna definicja. Aczkolwiek można wyodrębnić pewien zbiór zawodów które można wrzucić do „jednego” wora: Analityk, Analityk IT, Analityk Systemów Informacyjnych, Analityk Systemowy, Analityk Biznesowy czasem Specjalista IT i Konsultant IT (zależy od opisu stanowiska oczywiście ;)).

A jak przy  zawodach byłam, to zanurkowałam także w zawodach pokrewnych (często występujących solo): UX Designer, Project Manager, Product Owner. Dlaczego nazwy w języku obcym? Bo tłumaczeń jest równie dużo jak w przypadku business analyst a szkoda czasu i papieru (nawet tego elektronicznego) na roztrząsanie różnic ;)

Dlaczego podałam te zawody? Ano dlatego, ze zaobserwowałam wiele elementów wspólnych

W moim przypadku raczej to wygląda tak:

Głownie z uwagi na to że pełnię rolę Product Ownera w Scrumie i dlatego że nie mamy dedykowanych ról Project Managera i UX designera – a ktoś tą robotę musi robić. Także robię niczym mała mróweczka pracowicie wszystko (mrowca w gwarze to mrówka, więc pasuje do mnie jak ulał ;)), przynajmniej jeśli chodzi o „moje” projekty. Może to odrobinę tłumaczy dlaczego zainteresowałam się kiedyś  HCI;) Elementy wspólne pomiędzy rolami zawsze istnieć będą, ale w zależności od firmy będą na siebie bardziej lub mniej zachodzić.

Ciąg dalszy nastąpi...