Sklep

Oferta edukacyjna

Już dziś zainwestuj w kompetencje jutra.
Wyniki: 45
Brak danych o cenie
Załącznik nr 3- Regulamin grupy
Zapisy wkrótce

Załącznik nr 3 – Regulamin Grupy 

  1. INFORMACJE OGÓLNE
  1. Niniejszy Regulamin określa zasady weryfikowania i moderowania Treści, zgłaszania Nielegalnych Treści, Treści niezgodnych z Regulaminem Grupy, wydawanie decyzji oraz prawo odwołania się od decyzji. 
  2. Na potrzeby niniejszego Regulaminu Grupy, Właściciela Serwisu określa się Administratorem Grupy. 
  1. ZASADY WERYFIKOWANIA MODEROWANIA TREŚCI 
  1. Administrator Grupy może weryfikować Treści pozostawione przez Użytkownika na Grupie. Weryfikacja Treści polega na dokonaniu przeglądu i analizy pod względem Nielegalnych Treści lub Treści niezgodnych z Regulaminem Grupy. Przedmiotowa analiza wykonywana jest przez Administratora Grupy lub upoważnionego pracownika albo współpracownika.
  2. Weryfikacja, o której mowa w ustępie 2.1. powyżej prowadzona jest z inicjatywy Administratora Grupy, odbywa się w dobrej wierze i z należytą starannością w celu wykrycia, identyfikacji lub usunięcia Nielegalnych Treści, Treści niezgodnych z Regulaminem Grupy lub uniemożliwienia dostępu do tych Treści. 
  3. Administratora Grupy podejmuje bezzwłocznie odpowiednie działania w celu usunięcia lub uniemożliwienia dostępu do Nielegalnych Treści, gdy uzyska taką wiedzę, wiadomość lub zgłoszenie.  
  4. W razie stwierdzenia, że umieszczone przez Użytkownika Treści są niezgodne z Regulaminem Grupy lub kwalifikowane są jako Nielegalne Treści, Administrator Grupy podejmuje następujące ograniczenia:
  • Treść uznana za Nielegalną Treść lub Treść niezgodną z Regulaminem Grupy może zostać usunięta w całości z Serwisu lub zmodyfikowana w ten sposób, że zostanie ona zanonimizowana;
  • W stosunku do Użytkownika rozpowszechniającego Nielegalne Treści lub Treści niezgodne z Regulaminem Grupy, Usługi elektroniczne mogą zostać zawieszone lub zakończone w całości lub w części. 
  • Administrator Grupy niezwłocznie powiadamia Użytkownika, który zamieścił Treść podlegającą usunięciu lub animizacji w formie decyzji. Decyzja Administratora Grupy zawiera uzasadnienie oraz informację o możliwości złożenia odwołania od decyzji. 
  1. ZGŁASZANIE NIELEGALNYCH TREŚCI I TREŚCI NIEZGODNYCH Z REGULAMINEM GRUPY 
  1. Każdy Użytkownik ma prawo i obowiązek zgłaszania do Administratora Grupy Treści, które w jego ocenie naruszają Regulamin Grupy lub stanowią Nielegalne Treści. 
  2. Zgłoszenie Nielegalnych Treści lub Treści niezgodnych z Regulaminem Grupy można dokonać na adres: szkolenia@analizawymagan.pl
  3. W Zgłoszeniu należy podać:
  • imię i nazwisko lub nazwę (firmę) oraz adres e-mail Użytkownika dokonującego zgłoszenia, z wyjątkiem zgłoszenia dotyczącego informacji uznawanych za związane z przestępstwami, o których mowa w art. 3–7 Dyrektywy 2011/93/UE, tj.:
    • przestępstwem związanym z niegodziwym traktowaniem w celach seksualnych;
    • przestępstwem związanym z wykorzystywaniem seksualnym;
    • przestępstwem związanym z pornografią dzieciecą;
    • przestępstwem nagabywania dzieci do celów seksualnych;
    • przestępstwem podżegania, pomocnictwa i usiłowania przestępstw, o których mowa powyżej. 
  • wystarczająco uzasadnione wyjaśnienie powodów, dla których zgłaszający Użytkownik uważa, że zgłaszane Treści stanowią Nielegalne Treści lub Treści niezgodne z Regulaminem Grupy;
  • jasne wskazanie dokładnej elektronicznej lokalizacji zgłaszanych Treści takich jak podanie dokładnego adresu (-ów) URL oraz w stosownych przypadkach, dodatkowe informacje umożliwiające identyfikację Nielegalnych Treści lub Treści Niezgodnych z Regulaminem Grupy;
  • oświadczenie potwierdzające powzięte w dobrej wierze przekonanie Użytkownika dokonującego zgłoszenia, że informacje i zarzuty w nim zawarte są prawidłowe i kompletne.
  1. Jeżeli zgłoszenie zawiera elektroniczne dane kontaktowe Użytkownika, który dokonał zgłoszenia, Administrator Grupy bez zbednej zwłoki przesyła temu Użytkownikowi potwierdzenie otrzymania zgłoszenia. 
  2. Jeżeli zgłoszenie nie zawiera wszystkich informacji, o których mowa w ustępie 3.3. lub zawiera błędne informacje, Administrator Grupy może zwrocić się do zgłaszającego Użytkownika o ich uzupełnienie lub poprawienie wskazując 14-dniowy termin do ich uzupełnienia lub poprawienie pod rygorem pozostawienia ich bez rozpoznania. 
  3. Wszelkie zgłoszenia rozpoznawane są niezwłocznie, nie później niż w terminie 14 dni od dnia ich otrzymania. 
  4. Wszystkie zgłoszenia oraz podejmowane na ich podstawie decyzje rozpatrywane są w sposób terminowy, niearbitralny i obiektywny oraz z zachowaniem należytej staranności.
  5. Administrator Grupy nie korzysta z algorytmicznego systemu do podejmowania decyzji. 
  6. W przypadku, gdy Administrator Grupy poweźmie jakiekolwiek informacje dające podstawę do podejrzenia, że popełniono, popełnia się lub może dojść do popełnienia przestępstwa zagrażającego życiu lub bezpieczeństwu osoby lub osób, natychmiast informuje o swoim podejrzeniu organy ścigania lub organy sądowe i przekazuje wszystkie dostępne informacje na ten temat.
  1. DECYZJE ADMINISTRATORA GRUPY I PRAWO ODWOŁANIA SIĘ
  1. W razie stwierdzenia przez Administratora Grupy, że umieszczone przez Użytkownika Treści są niezgodne z Regulaminem Grupy lub kwalifikowane są jako Nielegalne Treści, Administrator Grupy podejmuje decyzje o czym informuje Użytkownika rozpowszechniającego Nielegalne Treści lub Treści niezgodne z Regulaminem Grupy – o ile Administrator Grupy zna odpowiednie elektroniczne dane kontaktowe tego Użytkownika. 
  2. Administrator Grupy informuje Użytkownika, którego dotyczy decyzja najpóźniej w dniu nałożenia ograniczenia, bez względu na powód i sposób jego nałożenia.
  3. Obowiązek, o którym mowa w ustępie 4.1-4.2. nie ma zastosowania w sytuacji, gdy Nielegalne Treści lub Treści niezgodne z Regulaminem Grupy są wprowadzającymi w błąd treściami handlowymi o dużej objętości. 
  4. Decyzja, o której mowa w ustępie 4.1. powyżej, zawiera jasne i konkretne uzasadnienie w odniesieniu do podjętych przez Administratora Grupy działań. 
  5. Uzasadnienie decyzji, o której mowa w ustępie 4.1. powyżej, zawiera co najmniej następujące informacje:
  • wskazanie, czy decyzja obejmuje usunięcie Treści, uniemożliwienie dostępu do nich, depozycjonowanie lub ograniczenie widoczności Treści lub zawieszenie lub zakończenie płatności pieniężnych odnoszących się do takich Treści albo nakłada inne środki, w odniesieniu do Treści, oraz, w stosownych przypadkach, zakres terytorialny decyzji i okres jej obowiązywania;
  • fakty i okoliczności, na podstawie których podjęto decyzję, w tym w stosownych przypadkach informację, czy decyzję podjęto na podstawie zgłoszenia dokonanego zgodnie z zawiadomieniem innego Użytkownika czy na podstawie dobrowolnych czynności sprawdzających prowadzonych z własnej inicjatywy oraz, gdy jest absolutnie niezbędne, tożsamość zgłaszającego Użytkownika;
  • informacje na temat wykorzystania zautomatyzowanych środków podczas podejmowania decyzji, w tym informację, czy decyzję podjęto w odniesieniu do Treści wykrytych lub zidentyfikowanych z wykorzystaniem zautomatyzowanych środków;
  • jeżeli decyzja dotyczy potencjalnie Nielegalnych Treści, wskazanie podstawy prawnej, na której opiera się decyzja, oraz wyjaśnienia dotyczące powodów, dla których na tej podstawie uznaje się dane informacje za Nielegalne Treści;
  • jeżeli decyzja opiera się na zarzucanej niezgodności informacji z Regulaminem Grupy, wskazanie postanowienia Regulaminu Grupy, na której opiera się decyzja, oraz wyjaśnienia dotyczące powodów, dla których uznaje się dane Treści są niezgodne z tym postanowieniem;
  • jasne i przyjazne dla Użytkownika informacje na temat przysługujących mu możliwości odwołania się od decyzji, w szczególności w stosownych przypadkach za pośrednictwem wewnętrznych mechanizmów rozpatrywania skarg, pozasądowego rozstrzygania sporów i sądowych środków odwoławczych.
  1. Decyzja Administratora Grupy nie zawiera informacji, o których mowa w ustępie 4.5. powyżej w przypadku, gdy Administrator Grupy otrzymał nakaz podjęcia działań przeciwko Nielegalnym Treściom wydany przez odpowiednie krajowe organy sądowe lub administracyjne.  
  2. Użytkownik, wobec Treści którego podjęte ograniczenia ma prawo złożyć odwołanie. 
  3. Odwołanie można złożyć na adres: szkolenia@analizawymagan.pl
  4.  Odwołanie powinno zawierać co najmniej:
  • imię i nazwisko lub nazwę odwołującego się Użytkownika;
  • dane kontaktowe;
  • szczegółowe uzasadnienie, dlaczego w ocenie odwołującego się Użytkownika decyzja Administratora Grupy jest błędna i powinna zostać zmieniona. 
  1. Wszelkie odwołania rozwiązywane są niezwłocznie, nie później niż w terminie 14 dni od dnia złożenia odwołania. Składający odwołanie otrzymuje odpowiedź w formie wiadomości poczty elektronicznej wysłanej na adres e-mail, z którego zostało wysłane odwołanie.
  2. Regulamin Serwisu stosuje się odpowiednio do Regulaminu Grupy. 
Brak danych o cenie
o mnie
Zapisy wkrótce

To nie jest strona o mnie. To jest strona o Twoich wyzwaniach w projektach IT.

Masz dość chaosu i niepewności w projektach IT?

Pracujesz w IT, ale czujesz, że wymagania są niejasne, a decyzje zapadają zbyt późno? Spotkania zamiast pomagać, tylko frustrują i ciągną się bez końca? Agile zamiast ułatwiać, wydaje się bardziej przeszkodą niż wsparciem? A może brakuje jasnych standardów i dokumentacji, która naprawdę usprawnia pracę?

Jeśli to brzmi znajomo – pomogę Ci to zmienić.

Dlaczego warto rozwijać się ze mną?

Jestem Mandalorianką w świecie IT – ostatnią deską ratunku w projektach, które utknęły w chaosie.

Wchodzę tam, gdzie inni już nie dają rady, wspieram zespoły w odzyskaniu kontroli i wyznaczam jasną drogę do rozwiązania. This is the way. Nie obiecuję cudów – obiecuję proces, który działa.

Jestem Twoim Sherpą, który pomaga Ci wejść na szczyt, ale to Ty decydujesz o trasie. Towarzyszę Ci w drodze, wspieram i motywuję, ale to Twoje decyzje kształtują proces zmian.

Mam 18 lat doświadczenia w analizie wymagań, a facylitacja stała się naturalnym krokiem w moim rozwoju, jako odpowiedź na rzeczywiste potrzeby zespołów, z którymi pracuję. Zanim zaproponuję konkretne narzędzia i metody, zawsze najpierw przyglądam się temu, jak organizacja działa, jak zespoły współpracują, by dobrać rozwiązania, które realnie usprawnią ich codzienną pracę. Właśnie na tym polega moja filozofia: ewolucja zamiast rewolucji – rozwijanie tego, co już funkcjonuje, zamiast wprowadzania zmian na siłę.

Pracowałam zarówno w jednej z największych korporacji w Polsce zajmujących się wytwarzaniem oprogramowania, gdzie usprawniałam procesy analityczne, jak i w mniejszych firmach, które dynamicznie się rozwijają. Bez względu na wielkość organizacji – czy to duża firma z ugruntowaną pozycją, czy mniejsza, dynamiczna organizacja – każda z nich ma swoje unikalne wyzwania. Wsłuchuję się w ich potrzeby, dostosowuję rozwiązania i wspieram je swoimi umiejętnościami na każdym etapie rozwoju, które potrzebują skutecznych rozwiązań dostosowanych do ich realiów.

Nie zmieniam organizacji zza biurka.

Pracuję z zespołami na każdym etapie projektu, pomagam im wypracować skuteczne rozwiązania i sprawiam, że te zmiany zostają na długo.

Łączę strategię z praktyką.

Pracuję z zespołami na każdym etapie projektu, pomagam im wypracować skuteczne rozwiązania i sprawiam, że te zmiany zostają na długo.

Zadaję właściwe pytania.

Moje podejście to nie suche teorie i gotowe szablony, ale dostosowane do Twojej rzeczywistości metody, które działają od pierwszego dnia.

Mocno stawiam na wsłuchanie się w ludzi i wspieranie ich w rozwoju, aby mogli skuteczniej działać w swoich organizacjach.

Każde szkolenie – zarówno zamknięte dla firm, jak i otwarte – jest dostosowane do konkretnej grupy uczestników, aby było jak najbardziej wartościowe.

Skupiam się na praktycznych przypadkach, z którymi na co dzień zderzam się w projektach. Pomagam ludziom odkryć ich własne talenty i umiejętności, których nawet nie byli świadomi.
Nie wprowadzam rewolucji, ale pomagam zespołom i organizacjom odkryć ich własny potencjał.

Moi klienci często mówią, że moje szkolenia i konsultacje „otwierają oczy” na rzeczy, o których wcześniej nie mieli pojęcia.

Co mówią moi Klienci?

Monika już po 8 minutach konsultacji wiedziała, gdzie leży przyczyna mojego problemu i od razu wskazała konkretne rozwiązania. (…) Jej styl wypowiedzi jest bardzo konkretny i rzeczowy, od razu rozumiałam wszystko i wiedziałam co z tym zrobić (…)
Scrum Masterka, branża e-commerce

Szkolenie Moniki było pełne praktycznych ćwiczeń, które od razu mogłam wdrożyć w pracy.

Product Owner, fintech

Monika nie tylko uczy analizy wymagań – inspiruje do działania i pomaga ludziom uwierzyć w ich własne umiejętności.Pomogła nam przejść od chaotycznych spotkań do struktury, która działa.
Lider zespołu IT, sektor ubezpieczeń

Jakie problemy rozwiązuję?

🟧Brak jasnych wymagań i ciągłe zmiany– pomagam uporządkować proces zbierania i dokumentowania wymagań, eliminując nieporozumienia.

🟧Analiza wymagań w podejściu Agile– pokazuję, jak połączyć analizę wymagań z elastycznym podejściem Agile, zamiast traktować je jako sprzeczne światy.

🟧Chaos na spotkaniach i brak decyzji– uczę facylitacji, która która pomaga uniknąć bezproduktywnych spotkań, nabyć umiejętności pracy z trudnościami w pozyskaniu informacji oraz skutecznie wypracowywać rozwiązania.

🟧Dokumentacja, która nie wspiera zespołu– pomagam wdrożyć praktyczne podejście do dokumentacji, które faktycznie usprawnia procesy.

Moje podejście i czym się wyróżniam?

🟦Ewolucja zamiast rewolucji – ulepszamy istniejące narzędzia i procesy, zamiast tworzyć zbędne komplikacje.
🟦 JA – JA-Zespół – JA-Organizacja – zmiana zaczyna się od pojedynczej osoby, ale jej wpływ rośnie wraz z zespołem i całą organizacją.
🟦 Nie uczę schematów – uczę myślenia – oprócz checklist, dostajesz konkretne podejście, które możesz wdrożyć od razu.

Dla kogo jestem?

🤝Dla Ciebie – jeśli chcesz łatwiej zbierać wymagania, skuteczniej komunikować się z biznesem i unikać nieporozumień w projektach IT.
🤝 Dla Product Ownerów i Project Managerów – którzy potrzebują jasnych metod pracy z wymaganiami i backlogiem.
🤝 Dla liderów zespołów IT i managerów – którzy chcą skutecznie usprawniać procesy bez chaosu i zbędnych iteracji.
🤝 Dla HR-owców i decydentów – którzy szukają szkoleń i wsparcia dla swoich zespołów w zakresie analizy wymagań i facylitacji.
🤝 Dla osób, które wchodzą w świat analizy wymagań – które chcą zdobyć solidne podstawy i od razu działać efektywnie.

Co teraz?

Nie pozwól, by Twój projekt ugrzązł w chaosie. Umów się na konsultację już teraz i sprawdź, jak skuteczna analiza wymagań może uporządkować Twoją pracę i zwiększyć efektywność zespołu.

Nie musisz już zgadywać, jak poprawić procesy w swojej organizacji.

Porozmawiajmy o Twoich wyzwaniach.

Brak danych o cenie
Podziękowanie
Zapisy wkrótce

Dziękuję za Twoje zgłoszenie.

Twoja wiadomość właśnie do mnie dotarła.

Przeanalizuję szczegóły i wrócę do Ciebie z odpowiedzią w ciągu 24 godzin (w dni robocze).

Co dalej?

– Jeśli potrzebuję dodatkowych informacji- dam Ci znać

– Podsumowanie Twojego zgłoszenia otrzymasz w ciągu 15 minut na swój adres e-mail podany przez Ciebie w formularzu zgłoszeniowym

-Jeśli masz pilne pytanie, możesz do mnie napisać korzystając z formularza na dole tej strony.

Sprawdź swoją skrzynkę e-mail

Czasami moje wiadomości mogą trafić do folderu „Oferty” lub „Spam” – jeśli nie widzisz podsumowania po 15 minutach i odpowiedzi po 24 godzinach, zerknij tam lub skontaktuj się ze mną bezpośrednio.

Dziękuję za zaufanie

Monika Perendyk

Znajdziesz mnie również tutaj:

Brak danych o cenie
webinar
Zapisy wkrótce

Jak usprawnić analizę w projekcie i zapanować nad chaosem w zespole?

17 marca 2025, godz. 18:00

Webinar już za nami.

Przed Tobą dalszy rozwój umiejętności. Sprawdź, która z dostępnych opcji szkoleń jest właśnie dla Ciebie.

Czy te sytuacje dotyczą również Ciebie?


Czy zespół…

pracuje nad wymaganiami, które okazują się niepotrzebne?

Czy klient…

jest niezdecydowany i trudno mu podjąć decyzję co jest dla niego naprawdę ważne?

Czy Ty…

tracisz czas na nieefektywne spotkania i warsztaty, z których nic nie wynika?

Czy wiesz, że

tyle minut potrzebujesz, aby przekonać się jak niewiele trzeba, aby wprowadzić skuteczne zmiany.

W ciągu 60 minut dowiesz się:
Jakich błędów unikać w analizie projektów IT
Jak prowadzić spotkania, aby były efektywne?
Jak przygotować się do dokumentacji wymagań, aby zespół sprawnie poruszał się po dokumentacji?

Webinar już za nami.

Przed Tobą dalszy rozwój umiejętności. Sprawdź, która z dostępnych opcji szkoleń jest właśnie dla Ciebie.

Agenda webinaru

Twoje pytania moje odpowiedzi

Jak mam dołączyć na webinar?

W mailu potwierdzającym rejestrację otrzymasz link do webinaru. Dzień przed webinarem również otrzymasz przypomnienie z linkiem.

Czy mogę zadać pytanie podczas webinaru?

Liczę na to. To najbardziej interesująca część webinaru, bo pracujemy z Twoją sytuacją i Twoimi wyzwaniami.

Czy webinar będzie nagrywany?

Webinar będzie nagrywany.

Czy będę mieć dostęp do nagrania po webinarze?

Liczę na Twój udział podczas webinaru. Nagranie z webinaru będzie dostępne dla osób, które wykorzystają kod udostępniany w ramach webinaru i szkorzystają ze specjalnej oferty na moje szkolenia.

Brak danych o cenie
Dziękuję.
Zapisy wkrótce

Widzimy się na webinarze

Co musisz teraz zrobić?

Krok 1- Wejdź na swoją skrzynkę mailową

Krok 2- Otwórz maila z adresu: szkolenia@analizawymagan.pl , tam znajdziesz niezbędne informacje dotyczące webinaru

Krok 3-Dodaj mój adres do adresów zaufanych, aby nie ominęło Cię przypomnienie o webinarze.

Zaproś znajomych. Może ktoś z Twojego zespołu też chciałby dowiedzieć się, jak usprawnić analizę w projektach IT. We dwójkę zawsze raźniej!

Dodaj wydarzenie do swojego kalendarza:

Znajdziesz mnie również tutaj:

Brak danych o cenie
Mity Programisty- 3 przekonania, które warto obalić
Zapisy wkrótce

Czy istnieją jedynie mity klienta i mity analityka? A co z programistami? Czy wśród nich również można spotkać się z mitami? Zapraszam do zestawienia 3 kluczowych mitów, z jakimi można się spotkać w pracy z programistami.

Mit 1- Skoro Woźniakowi i Jobs’owi udało się stworzyć i napisać system na pierwszego Apple’a w garażu to mi też się uda napisać dowolny program.

Owszem analogicznie jak to było w przypadku pierwszego DOS’a czy Windowsa ktoś musiał go napisać mając jedynie do dyspozycji swoją wiedzę. Fascynujące historie z początków Doliny Krzemowej potrafią inspirować, ale niestety mogą również prowadzić do błędnych założeń. Tak, Steve Wozniak napisał pierwsze oprogramowanie Apple na własnym sprzęcie, ale… były to zupełnie inne czasy.

W  dobie wielu technologii, gdzie aplikacje rozwijają się w zastraszającym tempie a wiedza jest rozproszona i powstają nowe metodyki pisania wewnątrz firm nie możemy ograniczać się jedynie do swojej wiedzy. Ba! Nawet nie powinniśmy tego robić. Istnieje bowiem duże ryzyko, że mamy za małą wiedzę, aby ogarnąć wszystko. Owszem Apple’a pisało dwóch programistów, ale musimy pamiętać, że nie wszystkie aplikacje tak powstają. Zatem potrzebne jest wsparcie nie tylko od strony Klienta, który poprzez przedstawienie swoich wymagań może nieświadomie nakierować nas na rozwiązanie technologiczne, ale również Analityka, który zaznaczy nam ograniczenia, które musimy wziąć pod uwagę w procesie tworzenia oprogramowania.

(więcej…)

Brak danych o cenie
Mity Klienta”Klient nie wie czego chce” – mit czy rzeczywistość?
Zapisy wkrótce

Czy naprawdę klient nie wie, czego chce, czy to tylko wymówka, gdy analiza wymagań kuleje?
A może problem nie tkwi w nim, ale w sposobie prowadzenia rozmów i precyzowania oczekiwań?

W świecie IT krąży wiele mitów na temat klientów. Niektóre z nich prowadzą do nieporozumień i frustracji, inne sprawiają, że projekty się przeciągają lub kończą spektakularnym fiaskiem. Czas obalić te przekonania i spojrzeć na temat z nowej perspektywy.

 

Mit 1 – Najważniejsza jest idea projektu a szczegóły dopracujemy później.

🟧 Problem: Brak szczegółowych wymagań na początku to przepis na niekończące się poprawki i chaos decyzyjny.

Dlatego to ryzykowne?

  • Klient będzie stopniowo przypominał sobie kolejne wymagania, wydłużając cały proces.
  • Dokumentacja nigdy nie zostanie zamknięta, a projekt ugrzęźnie w poprawkach.
  • Koszty rosną, bo każda nowa zmiana wymaga czasu i zasobów.

🟦Jak temu zaradzić?

  • Wprowadź klarowną strukturę zbierania wymagań.
    • Podziel proces na etapy: najpierw ogólne założenia, potem ich uszczegółowienie.
  • Daj klientowi narzędzia, które uporządkują jego myślenie.
    • Szablony, checklisty i gotowe pytania mogą ułatwić mu sprecyzowanie pomysłów.

Mit 2: Drobne zmiany nie mają wpływu na cały projekt

🟧 Problem: Klient może nie zdawać sobie sprawy, że „mała zmiana” może pociągnąć za sobą ogromne konsekwencje techniczne.

Kto z nas nie słyszał: To tylko jeden nowy przycisk, dodacie go, prawda?

🟦Jak temu zaradzić?

  • Komunikuj wpływ zmian. Nie mów „to skomplikowane”, tylko pokaż, co to oznacza dla budżetu i harmonogramu.
  • Ustal zasady zmian już na starcie. Dobrze działający proces zarządzania zmianą zapobiega chaotycznym decyzjom.

Mit 3: Nie znam się na IT- wy wiecie jak to zrobić

🟧 Problem: To zdanie może brzmieć jak brak zaangażowania, ale… w rzeczywistości to ogromna szansa.Klient NIE powinien projektować aplikacji, ale MUSI wiedzieć, jakie ma potrzeby biznesowe.

🟦Jak prowadzić z nim skuteczną komunikację?

  • Nie pytaj „co ma robić system?”, tylko „co chcesz osiągnąć?”
    • Jakie procesy ma usprawnić?
    • Jakie problemy sprawiają największą trudność?
  • Zamiast technicznych detali, używaj metafor biznesowych.

Mit 5: No, ma wyglądać tak jak…

🟧 Problem: Klienci często myślą, że interfejs to tylko estetyka, podczas gdy kluczowe jest doświadczenie użytkownika (UX).

Klient projektuje GUI zamiast skupiać się na swojej potrzebie biznesowej. Oczekuje, że system będzie działał dokładnie jak znane mu narzędzia, tylko, że lepiej. Co nie zawsze pasuje do konktekstu tego co za pomocą tej funkcjonalności chce biznesowo osiągnąć.

🟦Jak to rozwiązać?

  • Zadawaj precyzyjne pytania.
    • „Co użytkownik powinien zobaczyć po kliknięciu?”
    • „Jakie informacje są kluczowe na tym ekranie?”
  • Prezentuj prototypy.
    • Wizualizacja interfejsu pomaga szybciej dojść do porozumienia.

Podsumowanie – czy klient naprawdę nie wie, czego chce?

Klient nie musi znać technologii – ale musi wiedzieć, jakie ma potrzeby biznesowe. Mity o niezdecydowanych klientach często wynikają z braku struktury w zbieraniu wymagań i złej komunikacji.

Zamiast narzekać, że „klient nie wie, czego chce”, pokaż mu, jak może to odkryć razem z Tobą.

A Ty jakie mity słyszysz najczęściej?

Brak danych o cenie
Kim jest analityk w IT? Poznaj 10 cech skutecznego analityka biznesowego
Zapisy wkrótce

Wiele firm szuka dziś analityków IT.
A ja, czytając ogłoszenia o pracę, coraz częściej zastanawiam się, czy osoby je tworzące wiedzą, kogo tak naprawdę potrzebują.

Bo dobry analityk to trochę jak agent 007.
Musisz mieć wyjątkowe umiejętności i być przygotowany na każdą misję.

Czego więc szukać w idealnym analityku?
Sprawdź listę 10 cech, które według mnie są kluczowe.

10 cech skutecznego analityka biznesowego

1️⃣ Łączenie faktów

Bez analitycznego myślenia nawet najlepsze warsztaty czy dokumenty nic nie dadzą.
Analityk musi rozumieć zależności i widzieć więcej niż to, co mówi odbiorca.

2️⃣ Abstrakcyjne i plastyczne myślenie

Klient chce aplikacji, która zrobi wszystko?
Potrzebujesz wyobraźni, żeby to uporządkować i sprawdzić, co naprawdę da się zrobić.

3️⃣ Dociekliwość

Pytania, pytania i jeszcze raz pytania.
Bez nich zostaniesz z niepełnymi wymaganiami i projektem pełnym błędów.

4️⃣ Opanowanie i konsekwencja

Spotkania bywają trudne.
Czasem ktoś próbuje przerzucić odpowiedzialność na Ciebie.
Dlatego potrzebujesz spokoju i umiejętności stawiania granic.

5️⃣ Przewidywanie skutków

Jedna zmiana? Lawina problemów.
Analityk musi rozumieć, jak nawet drobne poprawki wpływają na całość systemu.

6️⃣ Komunikatywność i umiejętność słuchania

Masz dwie uszy i jedno usta – używaj ich proporcjonalnie.
Bez tego trudno będzie zebrać wymagania i zrozumieć potrzeby.

7️⃣ Kreatywne podejście

Czasem klasyczne metody nie wystarczą.
Dlatego warto mieć własne sposoby na pracę z klientem.

8️⃣ Krytyczne myślenie

Nie chodzi o blokowanie pomysłów.
Chodzi o to, żeby sprawdzać, czy wszystkie propozycje się nie wykluczają.

9️⃣ Świadomość odpowiedzialności

Niedokładna analiza = problemy na produkcji.
Dobry analityk myśli o konsekwencjach swoich decyzji.

🔟 Ciągły rozwój

Nikt nie wie wszystkiego.
Dobry analityk rozwija się, uczy i korzysta z doświadczenia innych.

O studiach podyplomowych i rozwoju możesz przeczytać tu: https://analizawymagan.pl/studia-podyplomowe-dla-analitykow-biznesowych/

Podsumowanie

Analityk to nie osoba od „pisania dokumentów”.
To ktoś, kto łączy wiedzę techniczną, komunikację i krytyczne myślenie.

To właśnie dzięki takim umiejętnościom projekty mają szansę na sukces.

Sprawdź czy masz analityczne supermoce, odpowiedz na 10 pytań.

Za każdą odpowiedź: Tak przyznaj sobie 1 punkt.

Podlicz wyniki i zobacz, jak blisko Ci do roli analityka w projektach IT.

1. Czy lubisz rozkładać problemy na czynniki pierwsze?

Szukasz powiązań, analizujesz zależności, nie zatrzymujesz się na powierzchni.

🔹 2. Czy potrafisz wymyślać rozwiązania dla nietypowych sytuacji?

Twoja wyobraźnia pomaga Ci ogarniać nawet najbardziej abstrakcyjne pomysły.

🔹 3. Czy zadajesz dużo pytań, zanim podejmiesz decyzję?

Drążysz temat, aż naprawdę zrozumiesz potrzeby i kontekst.

🔹 4. Czy umiesz zachować spokój, nawet gdy rozmowa robi się trudna?

Wiesz, jak stawiać granice i nie dajesz się sprowokować.

🔹 5. Czy widzisz konsekwencje małych zmian w dużych systemach?

Masz świadomość, że każdy drobiazg może wywołać efekt domina.

🔹 6. Czy potrafisz słuchać innych bez przerywania?

Dajesz przestrzeń na wypowiedź, notujesz, analizujesz.

🔹 7. Czy masz swoje sposoby na wyciąganie informacji od rozmówców?

Korzystasz z różnych technik i potrafisz dostosować styl do sytuacji.

🔹 8. Czy umiesz krytycznie spojrzeć na pomysły – także własne?

Nie boisz się powiedzieć: „To się wyklucza” albo „To się nie spina”.

🔹 9. Czy bierzesz odpowiedzialność za efekty swojej pracy?

Wiesz, że Twoje analizy mają realny wpływ na projekt.

🔹 10. Czy lubisz się uczyć od innych i rozwijać swoje umiejętności?

Nie boisz się nowej wiedzy i chętnie korzystasz z doświadczenia zespołu.

Wyniki:

🔹 8-10 punktów – Masz analityczne supermoce! 🚀 Rozwijaj je, a żadna analiza Cię nie zaskoczy.
🔹 5-7 punktów – Jesteś na dobrej drodze. Praktyka i rozwój pomogą Ci wejść na wyższy poziom.
🔹 0-4 punkty – Może to jeszcze nie Twoja misja… ale wszystko przed Tobą, jeśli masz ochotę się uczyć.

Brak danych o cenie
Trendy analizy biznesowej w 2015 nowe wyzwanie czy znana rzeczywistość?
Zapisy wkrótce

Na początku 2014 roku nikt nie przewidywał, że metody zwinne w zarządzaniu produktem będą miały tak silny wpływ na naszą pracę – inżynierów wymagań, bądź jak kto woli – analityków.

Nikt z nas nie wiedział, co to dla nas będzie oznaczało w praktyce. Teraz na początku roku 2015 już wiemy, że dla wielu z tych, którzy pracowali do tej pory w tradycyjnym modelu, pojawienie się, a w niektórych przypadkach nawet umocnienie tego trendu wymagało całkowitego przemodelowania pracy, a przede wszystkim myślenia. Podejrzewam, że część z Was stojących przed takim wyzwaniem starała się znaleźć swoje miejsce w nowej rzeczywistości, co było niełatwe.

W organizacjach, w których wprowadzenie podejścia zwinnego było nagłe, bez przygotowania zespołu, mogliście spotkać się z sytuacją braku konieczności posiadania w zespole analityka. Mam nadzieję, że takiej sytuacji nie było, a jeśli była to są to skrajne przypadki.

Jaki zatem będzie 2015 rok dla nas – inżynierów wymagań, czy przyniesie nowe trendy w analizie biznesowej?

1. Agile wkracza do akcji…

W 2015 roku podejście agile będzie wkraczało w nowe obszary gospodarki oraz nastąpi znaczne jego  umocnienie w tych dziedzinach, które obecnie wykorzystują taki sposób pracy. Takie dziedziny jak finanse, czy medycyna to jedne z ostatnich bastionów podejścia waterfallowego, który pozwalał na spokojne oczekiwanie na zakończenie pracy analityka, powstawanie tomów opracowań tylko po to, aby w 40% przypadków okazało się, że Klient oczekuje zupełnie innego rozwiązania. Albo co gorsza, rynek wymusił na organizacji Klienta korekty modelu biznesowego, aby dotrzeć do większej ilości odbiorców, czy też być bardziej elastycznym i szybciej reagować na ich potrzeby.

Coraz częściej będziemy świadkami łączenia się podejścia zwinnego ze standardowym podejściem i tworzeniem hybryd: łączenia agile z waterfall – pod nazwą: Water-scrum-fall. Dla wielu organizacji będzie to łagodne wejście w zwinne metodyki przy zachowaniu dotychczasowych przyzwyczajeń.

Co to oznacza dla analityka? Po pierwsze będziemy coraz częściej pracować w środowiskach mieszanych, dla których będziemy wsparciem w zakresie nie tylko analizy jako reprezentacji wymagań Klienta, ale przede wszystkim będziemy zarządzać wymaganiami na całym procesie wytwórczym. Tempo rozwoju oraz zmian będzie wymuszało na dostawcach przygotowanie takiego modelu biznesowego, który będzie nadążał za zmianiającymi oraz nowymi oczekiwaniami Klientów bez konieczności wydłużania terminu dostarczenia produktu.

2. Między chmurami a ziemią….

Mimo rosnącego wpływu rozwiązań będących w chmurze, analityk będzie coraz więcej miał do czynienia z integracjami między systemami. Liczba nowych rozwiązań oferowanych Klientom z roku na rok rośnie w lawinowym tempie. Klient zamiast jednego spójnego rozwiązania, dla każdego obszaru swojego biznesu otrzymuje osobny program, aplikację, dedykowane rozwiązanie. Problem z ich obsługą pojawia się na etapie spójności danych pomiędzy systemami. Klienci coraz częściej zwracają uwagę na transparentność rozwiązań, które umożliwią płynne przekazywanie danych pomiędzy wszystkimi rozwiązaniami, jakie posiada w Firmie. Wymusza to konieczność połączenia systemów między sobą w celu wymiany informacji. Z jednej strony Analitycy będą musieli identyfikować potrzeby Klienta, ale coraz częściej będą musieli zwracać uwagę na aspekty bezpieczeństwa danych. Jest to nowy obszar szczególnie w analizie biznesowej, która po raz pierwszy wkracza w obszar analizy systemowej, tym samym wymuszając na analitykach rozbudowanie swoich kompetencji.

3. Pomniejszanie roli analityka a wpływ na projekt

Tak jak w poprzednich latach nadal będzie utrzymywała się tendencja pomniejszania roli analityka w projektach. Wprowadzenie zwinnego podejścią, bądź podejścia water-scrum-fall, będzie sprawiał wrażenie rozmycia kompetencji analityka na cały zespół.

W wielu organizacjach nadal tkwi poczucie, że lepiej mieć dozorcę – kierownika projektu, który pilnuje czasu, budżetu oraz ram projektu  niż zarządcę – analityka biznesowego, którego celem jest dostarczenie produktu jako wartości biznesowej.

Wartość biznesowa definiowana jest jako porównanie analizy jakościowej i ilościowej z wizją rozwiązania dla biznesu. Realizowana jest na podstawie jednego z 3 motywów: słuchania oczekiwań Klienta w trakcie trwania projektu, adoptowania pierwotnego rozwiązania do nowych potrzeb Klienta, rozwijanie funkcjonalności wspólnie z Klientem (wzrost jego zaangażowania w projekt) w oparciu o wzrost wartości biznesowej jego Firmy.

Dlaczego kierownik projektu jest ważniejszy niż analityk? Z punktu widzenia dostawcy ważniejsze jest zamknięcie projektu i jego rozliczenie niż sprawdzenie czy projekt oddany do Klienta spełni jego oczekiwania, które się zmieniły w jego trakcie. To przynosi zysk. A co ze zmianami? Zostaną rozpisane na kolejny projekt. Wina leży po obu stronach – Klient chce otrzymać szybko produkt, w trakcie zmian swoich wymagań w zakresie produktu nie chce wydłużenia czasu ani zmiany budżetu, jednocześnie chce zachować wysoką jakość zamówionego rozwiązania. Dostawca zatem chcąc dostarczyć produkt Klientowi z nowymi wymaganiami stara się skupić na funkcjonalnościach najistotniejszych, a jakość całego rozwiązania ze względu na ograniczony czas jego dostarczenia rozmywa się.

W części organizacji będą jednak zachodzić duże zmiany w zakresie zaangażowania analityka w roli: kierownika projektu, aby zapobiec sytuacjom opisanym wyżej. Jeszcze nie nazwane, lecz można jasno powiedzieć: nastąpi powoli dojrzewanie organizacji do wprowadzania inżynierii wymagań.

Brak danych o cenie
Jak zmierzyć niemierzalne, czyli jak to jest z tą analizą
Zapisy wkrótce

Oszczędzaj! Zaciskaj pasa! Idzie kryzys! A potem… „Już jest kryzys, musimy oszczędzać”. Brzmi znajomo? W ostatnich latach te hasła powtarzają się jak mantrę. W efekcie firmy ograniczają zatrudnienie, zmniejszają budżety, a najczęściej – tną koszty projektów. Bo przecież rozwijać się trzeba, ale jak najtaniej.

I tu pojawia się klasyczny zgrzyt:
🟧 Klient chce usprawnienia, które przyniesie oszczędności.
🟧 Jednocześnie nie chce inwestować w projekt, bo budżet ledwo zipie.

Więc szuka cięć. I najczęściej zaczyna od tego, co wydaje się najmniej namacalne – od analizy.

(więcej…)

Brak danych o cenie
10 obowiązków Klienta IT, których wymaga Dostawca
Zapisy wkrótce

W poprzednim wpisie pisałam o prawach Klienta, o których Dostawca nie zawsze wspomina podczas projektu.

Dzisiaj prezentuję drugą stronę medalu – obowiązki Klienta,  których nie zawsze jest świadomy, a Dostawca najczęściej ich wymaga w trakcie trwania projektu. Znajomość obowiązków oraz ich przestrzeganie nie tylko usprawnia pracę w projekcie obu stronom, ale przede wszystkim jest odpowiedzią na odwieczne pytania po zakończeniu projektu: „Co poszło nie tak”. Zastanawiasz się jak uniknąć takich sytuacji? Zapraszam do dalszego czytania.

Karta obowiązków Klienta to zbiór 10 elementów, które są czynnikiem sukcesu w projekcie. (więcej…)

Brak danych o cenie
10 praw Klienta IT, których nie dowiesz się od Dostawcy
Zapisy wkrótce

Oprogramowanie spełniające oczekiwania i potrzeby Klienta jest wynikiem dobrze przeprowadzonej analizy oraz realizacją dokumentu opisującego wymagania biznesowe Klienta. Baza dla dokumentu, jaką są wymagania, które powinny być poprawnie zidentyfikowane oraz zinterpretowane, są wynikiem partnerskiej współpracy pracy między Analitykiem a Klientem. Na podstawie rozpoznania potrzeby Klienta, Analityk może zdefiniować wymagania, które będą zbiorem informacji CO należy zrobić, aby potrzeba Klienta została zrealizowana.

“Partnerstwo, dobrowolny związek dwu lub więcej osób, którego celem jest prowadzenie przedsięwzięcia oraz dzielenie jego zysków lub strat” The Encyclopedia Britannica, wyd. z 1990r.

W przypadku niepowodzenia wdrożenia projektu najczęściej winnym według Klienta staje się Analityk, ponieważ:

  • najwyraźniej źle zrozumiał to co chciałem mu przekazać,
  • nie zapytał o jakąś kwestię- a przecież miał taką możliwość,
  • rozmawiał nie z tą osobą co powinien na spotkaniu.

Ta lista jest oczywiście o wiele dłuższa, ale już te kilka punktów pokazuje, że o partnerstwie w takim przypadku nie było mowy. Przecież do Dostawca jest odpowiedzialny za wszystko. Czyżby? Należy pamiętać, że obie strony (Dostawca i Klient) muszą być zaangażowani i być świadomi tego, czego potrzebują aby odnieść sukces.

Na początku projektu być może jest to oczywiste, lecz w trakcie jego trwania, tym bardziej kiedy narasta presja, o wspólnym celu łatwo zapomnieć. Klient i Dostawca nie zachowują się jak partnerzy, lecz jak strony w procesie wytwarzania oprogramowania próbujące nawzajem sobie udowodnić kto miał/ma rację. Brzmi znajomo?

W tym miejscu wyłania się kolejna kompetencja Analityka, który powinien być mediatorem, aby stwarzać atmosferę do dalszej współpracy szczególnie w sytuacjach kryzysowych.

Karta praw Klienta to 10 praw, z których mogą, a nawet powinni korzystać Klienci. Prawa te dotyczą współpracy między analitykami,programistami,wdrożeniowcami podczas wykonywania czynności związanych z wytwarzaniem oprogramowania, a dokładniej z fazą analizy i opracowania wymagań.

(więcej…)

Brak danych o cenie
Najczęstsze problemy w umowach wdrożeniowych
Zapisy wkrótce

Zapraszam na pierwszy wywiad z Panem Łukaszem Węgrzynem z Kancelarii Prawnej Maruta i Wspólnicy w Warszawie.

ŁUKASZ WĘGRZYN

Specjalista z zakresu prawa ​nowych technologii oraz własności intelektualnej. Wcześniej pracował między innymi jako prawnik wewnętrzny dla Agora S.A.. MTv Networks oraz członek zespołu TMT (Technology – Media – Telecomunications) międzynarodowej kancelarii prawnej „Bird & Bird”. Aktualnie pracuje w Kancelarii Prawnej Maruta i Wspólnicy w Warszawie.​ Wykładowca ​na Wydziale Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego. Absolwent Wydziału Prawa i Administracji Uniwersytetu Jagiellońskiego oraz podyplomowych studiów na kierunku „Prawo Nowoczesnych Technologii” prowadzonych przy Polskiej Akademii Nauk.

Serdecznie zapraszam na wykład o najczęstszych problemach z umowami wdrożeniowymi oraz o roli analizy w umowie. (więcej…)

Brak danych o cenie
Trendy analizy biznesowej 2016
Zapisy wkrótce

Trendy analizy biznesowej w 2016 roku to głównie weryfikacja tego, co zostało zainicjowane w roku 2015.

Niepoprawnie zdefiniowany  cel biznesowy jest nadal aktualny, ponieważ trudno zweryfikować czy został zrealizowany. Podobna sytuacja jest w przypadku przewidywań trendów.

Zanim napiszę o trendach, jakie przewiduję na 2016 rok zweryfikujmy, na ile udało się przewidzieć to, co będzie działo się w 2015 roku (http://analizawymagan.pl/trendy-analizy-biznesowej-w-2015/).

Oto 8 trendów w analizie biznesowej z 2015 roku oraz ich weryfikacja w roku 2016:

TREND 1: Coraz częściej będziemy świadkami łączenia się podejścia zwinnego ze standardowym podejściem i tworzeniem hybryd: łączenia agile z waterfall – pod nazwą:Water-scrum-fall. Dla wielu organizacji będzie to łagodne wejście w zwinne metodyki przy zachowaniu dotychczasowych przyzwyczajeń.

Weryfikacja w 2016: Cały rok 2015 to triumf podejścia zwinnego w projektach – takiego purytańskiego, ale również pojawienia się hybryd różnego rodzaju. Organizacje nieprzygotowane do pracy w podejściu zwinnym wytworzyły własne frameworki, które stanowią zbiór różnych praktyk i podejść w wytwarzaniu oprogramowania, które pasują i sprawdzają się w ich organizacji. Nie jest to złe podejście – wręcz przeciwnie. Świadome tworzenie hybrydy może przynieść korzyść, jeśli wiemy czemu ma służyć – ma usprawniać pracę zespołom deweloperskim oraz umożliwiać szybki przepływ informacji od biznesu do IT i odwrotnie.

 

PRZEWIDYWANIA NA 2016: UMACNIANIE SIĘ TRENDU W 2016

 

TREND 2: Co to oznacza dla analityka? Po pierwsze będziemy coraz częściej pracować w środowiskach mieszanych, dla których będziemy wsparciem w zakresie nie tylko analizy jako reprezentacji wymagań Klienta, ale przede wszystkim będziemy zarządzać wymaganiami na całym procesie wytwórczym.

Weryfikacja w 2016: Zarządzanie wymaganiami to jedno z podstawowych zadań każdego inżyniera wymagań. Zgadza się. Jednak jak praktyka pokazywała w podejściu tradycyjnym zarządzanie wymaganiami kończyło się najczęściej na etapie zaakceptowania dokumentu SRS (System Requirements Specification). Z uwagi na pojawianie się metod iteracyjnych wytwarzania oprogramowania, zarządzanie wymaganiami obejmuje cały proces wytwarzania oprogramowania. Dzięki czemu analityk uczestniczy w projekcie również na etapie testów akceptacyjnych z Klientem.

 

PRZEWIDYWANIA NA 2016: UMACNIANIE SIĘ TRENDU W 2016

TREND 3: Mimo rosnącego wpływu rozwiązań będących w chmurze, analityk będzie coraz więcej miał do czynienia z integracjami między systemami. Liczba nowych rozwiązań oferowanych Klientom z roku na rok rośnie w lawinowym tempie. Klient zamiast jednego spójnego rozwiązania, dla każdego obszaru swojego biznesu otrzymuje osobny program, aplikację, dedykowane rozwiązanie. Problem z ich obsługą pojawia się na etapie spójności danych pomiędzy systemami. Klienci coraz częściej zwracają uwagę na transparentność rozwiązań, które umożliwią płynne przekazywanie danych pomiędzy wszystkimi rozwiązaniami, jakie posiada w Firmie. Wymusza to konieczność połączenia systemów między sobą w celu wymiany informacji.

Weryfikacja w 2016: Jak zaobserwowano rok 2015 to kontynuacja integracji systemów IT w sektorze energetycznym. Koncerny energetyczne zainwestowały nie tylko w samą integrację swoich systemów, ale przede wszystkim na rozwój m.in systemów billingowych.  Coraz więcej pojawiło się projektów związanych z  integracją z systemami CRM oraz wdrożeniem rozwiązań dla tzw. „smart meteringu”, czyli  inteligentnych systemów pomiarowych w energetyce.

 

PRZEWIDYWANIA NA 2016: Umacnianie się trendu w 2016roku, choć w energetyce nie przewiduje się szybkiego wzrostu wdrożeń rozwiązań wykorzystujących chmurę.

 

TREND 4: Z jednej strony Analitycy będą musieli identyfikować potrzeby Klienta, ale coraz częściej będą musieli zwracać uwagę na aspekty bezpieczeństwa danych. Jest to nowy obszar szczególnie w analizie biznesowej, która po raz pierwszy wkracza w obszar analizy systemowej, tym samym wymuszając na analitykach rozbudowanie swoich kompetencji.

Weryfikacja w 2016: Analiza biznesowa okazała się niewystarczająca. Skupienie się tylko na tym aspekcie znacznie wydłuża proces wytwórczy z uwagi na konieczność wykonania analizy systemowej, czyli przeniesienia wymagań biznesowych w obszar projektowania rozwiązań systemowych. Taką tendencję zauważył już BABOK ver3, który powoli wchodzi w inżynierię wymagań. Coraz większa liczba analityków biznesowych dokształca się właśnie w tym kierunku.

 

PRZEWIDYWANIA NA 2016: UMACNIANIE SIĘ TRENDU W 2016, oraz wzrost popytu na certyfikację w kierunku inżynierii wymagań.

 

PRZYPIS: Inżynieria wymagań jest dziedziną interdyscyplinarną, ponieważ łączy ze sobą wiele dziedzin, które mają kluczowe znaczenie dla powodzenia projektu IT. Do nich należą: analiza biznesowa, analiza systemowa, zarządzanie projektem, technologie programowania, sposoby testowania, regulacje prawne, oraz psychologia. Szczególnie ta ostatnia dziedzina od kilku lat nabiera dużego znaczenia w procesie zbierania wymagań, kiedy wielu analityków szuka technik rozmawiania z Klientami, czy radzenia z różnymi emocjami podczas spotkań biznesowych.Potrzeba szerzenia wiedzy i dobrych praktyk w zakresie inżynierii wymagań była jednym z powodów powstania Stowarzyszenia Inżynierii Wymagań (http://www.siw.org.pl)

TREND 5: Tak jak w poprzednich latach nadal będzie utrzymywała się tendencja pomniejszania roli analityka w projektach.

Weryfikacja w 2016: Pierwszy przewidywany trend, który się nie sprawdził w 100%.  Klienci dostrzegli, że udział analityka w projektach IT to dobrze zainwestowane pieniądze, a przede wszystkim gwarancja zrozumienia ich języka. Coraz chętniej korzystają z warsztatów analitycznych oraz innych form współpracy z analitykiem na etapie identyfikacji i zbierania wymagań, ale przede wszystkim podczas ich opracowywania.

 

PRZEWIDYWANIA NA 2016: Umocnienie trendu coraz większej współpracy między Klientem a Analitykiem w całym procesie wytwarzania oprogramowania. Przewidywany jest również wzrost zapotrzebowania na analityka z wiedzą dziedzinową w projektach IT, na co wskazują ostatnie badania . Wg. Forbes (http://kariera.forbes.pl/2016-rok-najlepsze-zawody-nadchodzacego-roku,artykuly,201511,1,1,3.html) drugim najbardziej pożądanym zawodem będzie Product Manager w sektorze bankowym.

TREND 6: Wprowadzenie zwinnego podejścia, bądź podejścia waterscrumfall, będzie sprawiał wrażenie rozmycia kompetencji analityka na cały zespół.

Weryfikacja w 2016: Zwinne podejście niejako wymusza tworzenie interdyscyplinarnych zespołów, czyli również takich, którzy posiadają umiejętności analityczne. Fakt braku roli analityka jako takiej w podejściu zwinnym faktycznie może sprawiać wrażenie rozmycia kompetencji.

 

PRZEWIDYWANIA NA 2016: Jak pokazuje praktyka, wiele organizacji, w których udało się wdrożyć podejście zwinne/hybrydę metod trudno jest zbudować zespół interdyscyplinarny, który będzie skupiał umiejętności testera, analityka, programisty. Dlatego też coraz częściej można zaobserwować wytworzenie mniejszych specjalistycznych grup osób z określoną specjalizacją, np. analityczną, którzy dostarczają produkty zespołowi deweloperskiemu. Dodatkowo zauważalny jest trend edukowania grup: tester, programista, analityk pod kątem umiejętności analitycznych. Stąd na rynku coraz częściej pojawiają się nowe stanowiska takie jak np. analityk- tester.

 

Brak danych o cenie
Procesy biznesowe w inżynierii wymagań
Zapisy wkrótce

O wykorzystaniu i „roli” procesów biznesowych w kontekście inżynierii wymagań rozmawiamy z Panią Moniką Perendyk, analitykiem, wykładowcą akademickim, współ­za­ło­ży­cielem i Pre­zesem Sto­wa­rzy­sze­nia Inży­nie­rii Wyma­gań (www.siw.org.pl), zało­ży­cielem i Redak­torem Naczelnym maga­zynu: REQ Maga­zyn (www.reqmagazyn.pl).

[…]

bpmstandard.pl:

Pani Moniko, w praktyce, jaką rolę w inżynierii wymagań pełnią procesy biznesowe?

Monika Perendyk:

Istnieje ścisła zależność między tymi dwoma dziedzinami. Tak jak wspominałam wcześniej, jednym z wyzwań, jakie czekają na analityka podczas zbierania i analizy wymagań jest omówienie i nierzadko udokumentowanie procesu biznesowego, który ma być obsłużony przez system.
W wielu swoich wystąpieniach podkreślam, że błędem jest koncentrowanie się dostawcy na szukaniu rozwiązania informatycznego bez identyfikacji procesu biznesowego, który chcemy obsłużyć. Pracę w projekcie informatycznym powinniśmy rozpoczynać od poszukiwania odpowiedzi na pytanie: Którą część omawianego procesu biznesowego ma wspierać tworzony system?
Aby odpowiedzieć na to pytanie w pierwszej kolejności musimy zanalizować sytuację i problem klienta, z którym obecnie się zmaga. Wykonujemy analizę „as is” poprzez zadawanie szeregu pytań interesariuszom, m.in:
• kto jest odpowiedzialny za realizację tego zadania?
• kiedy wykonywana jest dana czynność, jakie warunki początkowe musza być spełnione?
• co powinno być wykonane oraz jakie dane, produkty uzyskamy w wyniku działania?

Takie podejście umożliwia zidentyfikowanie reguł biznesowych, które stanowią podstawę do zdefiniowania wymagań.
Następnie wspólnie z klientem wykonujemy analizę stanu docelowego, czyli analiza „to be”. Na tym etapie szukamy odpowiedzi na pytania: co chcę osiągnąć dzięki rozwiązaniu, jakie chcę osiągnąć zyski dzięki rozwiązaniu, jak chcę aby docelowo mój proces wyglądał.
Nie wystarczy jedynie rozrysować proces biznesowy i zaimplementować go w systemie. Celem uruchomienia projektu informatycznego jest optymalizacja pracy interesariuszy. Odtworzenie 1:1 stanu obecnego w systemie informatycznym nie jest żadną optymalizacją, a jedynie zmianą narzędzia.
Przed przystąpieniem do pracy nad rozwiązaniem informatycznym w powinniśmy pokazać jak będzie wyglądał proces biznesowy po wdrożeniu rozwiązania. Wskazać, w którym miejscu będzie znajdował się system, jakie będą dane wejściowe, a jakie wyjściowe oraz którzy interesariusze będą korzystać z tego rozwiązania.
Czasem wdrożenie rozwiązania jest impulsem do zmodyfikowania procesu biznesowego, dostosowania do integracji z systemem, który jest zaimplementowany.
Jeszcze kilka lat temu procesy biznesowe nie były takie oczywiste w inżynierii wymagań, bowiem uważano, że ich analizą zajmują się tylko analitycy biznesowi. Obecnie elementy procesu biznesowego wykorzystywane są w technice spopularyzowanej przez J.Pattona w 2009 roku, czyli w „user story mapping”. Technika ta polega na tworzeniu zestawu historyjek z punktu widzenia biznesu. Przekształcamy aktywności użytkownika w przepływ działań, którego można w kolejnym kroku zamienić na zbiór mniejszych zadań powiązanych z konkretnym celem biznesowym. Przepływ tych działań tworzy proces biznesowy.
Jak widać obecnie inżynieria wymagań nie może istnieć bez wykorzystywania analizy procesów biznesowych.

[…]

Cały wywiad: https://bpmstandard.pl/wywiady/139-procesy-biznesowe-a-inzynieria-wymagan

Brak danych o cenie
Główne trendy analizy biznesowej na 2017 rok
Zapisy wkrótce

Jakie są trendy analizy biznesowej na 2017 rok? Rola analityka nadal będzie taka ważna jak w roku ubiegłym? Co ze zwinnością analityka?

Przewidywania głównych trendów analizy biznesowej na dany rok nigdy nie należy do najprostszych. Wymaga obserwacji tego co dzieje się na świecie, ale również w Polsce w tym zawodzie. W zeszłym roku pojawił się opis weryfikacji trendów z 2015 roku (http://analizawymagan.pl/trendy-w-analizie-biznesowej/). Jak będzie w tym roku dowiemy się dopiero na początku roku 2018, kiedy przewidywania zostaną poddane weryfikacji.

Oto 3 kluczowe trendy analizy biznesowej na rok 2017.

1. Analityk wkracza do zwinnego świata, czyli analityk w agile

W świecie Agile nie ma specjalnie dedykowanej roli analityka. Nic nie wskazuje również na to, aby w przyszłości miałaby się pojawić, choć jak to mówią niektórzy „nigdy nie mów nigdy”. Mimo to w przedsiębiorstwach od co najmniej 3 lat można zaobserwować chęć utworzenia nowej roli w scrum, jakim jest analityk. Jest to naturalna kolej rzeczy szczególnie w tych przedsiębiorstwach, których wdrożenie zwinnego podejścia skończyło się na wypowiedzeniu słów: „od dziś będziemy tworzyć produkty zwinnie”.  Dlaczego jest to naturalna kolej rzeczy? Ponieważ nikt nie wie co zrobić z testerem, kierownikiem projektu i analitykiem w nowej rzeczywistości. Z braku pomysłu analityk najczęściej ubierany jest w buty „Product Ownera” – przecież analityk i Product Owner kontaktują się z programistami i klientem. Prawda, lecz kompetencji Product Ownera jest dużo więcej. Najważniejszą z nich jest jednak możliwość samodzielnego podejmowania decyzji i wyznaczania kierunku rozwoju aplikacji. Czy jest to złe? Nie, jeśli analityk będzie miał możliwość podejmowania takich decyzji.

Zapowiada się, że rok 2017 będzie nadal „próbowaniem” metodyk zwinnych w projektach do tej pory wytwarzanych metodą tradycyjną. Będzie to rok  naznaczony poszukiwaniem modeli umożliwiających połączenie metodyk zwinnnych i tradycyjnych –Water-scrum-fall (o trendzie pisałam w roku 2015 – http://analizawymagan.pl/trendy-analizy-biznesowej-w-2015/. Zatem należy spodziewać się, że w obecnym roku coraz częściej pojawią się pytania: „Co z tym analitykiem w agile”.

Rok 2017 to również metody zwinne w zamówieniach publicznych zgodnie z opinią prawną (https://cppc.gov.pl/opinia-prawna-sprawie-mozliwosci-sposobu-wykorzystania-metodyki-agile-projektach-informatycznych-realizowanych-zastosowaniem-ustawy-prawo-zamowien-publicznych/). W tym obszarze wydaje się, że będzie najwięcej „kombinowania”, gdzie tego analityka „upchać”. Jestem przekonana, że zaobserwujemy powstawanie frameworków, które będą złożeniem podejścia zwinnego i tradycyjnego w obszarze zamówień publicznych. Dlatego analitycy mogą spodziewać się, że w ofertach pracy na 2017 rok coraz częściej na liście wymaganych umiejętności będzie się pojawiać znajomość metodyk zwinnych.

2.Tytuł stanowiska zobowiązuje

Wg raportu Pracuj.pl: „W III kwartale pracodawcy znacząco zwiększyli zapotrzebowanie na specjalistów IT – wzrost ofert skierowanych do nich w stosunku do analogicznego kwartału 2015 r. wyniósł 13,9%. Wzrosło także zapotrzebowanie na inżynierów – o 10,7% w ujęciu rok do roku. Wciąż także obserwuje się rosnące zapotrzebowania na pracowników produkcji, w III kwartale 2016 r. wzrost zapotrzebowania na tych specjalistów wyniósł 17,1% w porównaniu z analogicznym okresem roku poprzedniego.” (http://www.pracuj-dla-mediow.pl/pr/332045/pracuj-pl-raport-rynek-pracy-specjalistow-w-iii-kw-2016-roku).

Pracodawcy nadal poszukują specjalistów na stanowisko: „Analityk”, które na przestrzeni lat stało się pojęciem dość pojemnym. Niektórzy na stanowisku: „analityk” zajmują się tylko i wyłącznie tworzeniem dokumentu wizji projektu, który zawiera specyfikację pożądanych funkcji rozwiązania oraz analizę przedsiębiorstwa. Inni robią wszystko, począwszy od analizy przedsiębiorstwa, aż po przygotowanie dokumentu SRS (Specification Requirements Software) zawierający szczegółowy opis rozwiązania.

Rynek zauważył, że potrzeba tak naprawdę obu kompetencji: analityka biznesowego i analityka systemowego, czyli inżyniera wymagań.

 

Mimo takiej wiedzy pracodawców, nadal wielu decyduje się na nazwy stanowisk takich jak : analityk biznesowy, analityk biznesowo-systemowy, analityk systemowy, architekt biznesu, technical writer. Perełkami wśród ogłoszeń są stanowiska: „Inżynier wymagań”.

Obserwując taki podział kompetencji w zawodzie: „Analityk” możemy spodziewać się w 2017 roku usystematyzowania nazewnictwa w taki sposób, aby pracodawca i pracownik wiedział, jakie są oczekiwane umiejętności związane są z konkretnym stanowiskiem. Jest to oczywiście proces, który nie zakończy się w obecnym roku. Dążymy do sytuacji, kiedy chcąc zatrudnić: „analityka biznesowego” pracodawca będzie miał na myśli osobę, która wykona analizę przedsiębiorstwa, przygotuje ten dokument wizji, lecz nie będzie oczekiwał znajomości relacyjnej bazy danych, aby opisać jak ma być dokładnie zrealizowane dane rozwiązanie – od tego jest inżynier wymagań.

Zwiększone zainteresowanie szkoleniami z zakresu inżynierii wymagań tylko potwierdza ten trend. Niestety nadal nam daleko do standardów światowych, gdzie funkcjonowanie dwóch ról: inżyniera wymagań i analityka biznesowego jest normą.

Czy wiesz, że w Polsce od 2014 roku działa pierwsze stowarzyszenie dla analityków biznesowych i inżynierów wymagań- Stowarzyszenie Inżynierii Wymagań (www.siw.org.pl) ?

3.Analityk ma się dobrze

Trend pomniejszania roli analityka w projektach przewidywany w roku 2015 na podstawie obserwacji z lat ubiegłych po raz pierwszy nie sprawdził się. Rola analityka w projektach w 2016 roku znacznie wzrosła w porównaniu do lat ubiegłych. Trend obserwowany od kilku lat to specjalizacja analityków w określonych dziedzinach. Przez wiele lat uważano, że skoro jesteś analitykiem to odnajdziesz się w każdej dziedzinie. Jest to prawda, lecz

„Jesteś tak dobrym analitykiem jak dobrze znasz dziedzinę, w której pracujesz” (M.Perendyk).

Tworzenie specjalizacji to trend, który również w tym roku będzie się utrzymywał, a nawet będzie miał silniejsze znaczenie niż w latach ubiegłych ze względu na coraz większy wpływ nowych technologii oraz pojawianie się rozwiązań dedykowanych na telefony komórkowe.

Z  badań „U.S. Bureau of Labor Statistics, Employment Projections Program” wynika, że amerykańscy przedsiębiorcy do roku 2020 będą potrzebować 876 tys. analityków biznesowych. To nie jest trend jedynie światowy, lecz również obserwowany w Polsce co widać po liczbie ofert pracy na to stanowisko.

A jakie trendy Ty typujesz na ten rok?

 

Brak danych o cenie
Czy Twój cel biznesowy jest S.M.A.R.T?
Zapisy wkrótce

Minął 2016 rok, a Ty właśnie zdałeś sobie sprawę, że nie udało Ci się zrealizować wszystkich planów, jakie założyłeś na jego początku? Dziś Twoja lista ponownie się zapełnia celami na 2017 rok. Ten rok będzie przecież lepszy, cele bardziej realne. Z pewnością Ci się uda…..jeśli tylko podejdziesz do nich jak do celów biznesowych w projekcie IT. Spójrz na swoje cele jak na cele biznesowe w projekcie IT.

W pierwszej kolejności musimy odpowiedzieć na pytanie czym jest cel biznesowy w projekcie IT?

Cel biznesowy – finansowa albo niefinansowa korzyść biznesowa, jaką spodziewa się odnieść organizacja w wyniku zrealizowania projektu lub innej inicjatywy (K.Wiegers, J.Betty)

Na etapie zbierania wymagań interesariusz nie będzie mówił o swoich celach biznesowych, lecz o funkcjonalnościach jakie są jego zdaniem niezbędne. Zadaniem każdego analityka, inżyniera wymagań jest poszukiwanie celu, jaki kryje się pod opisem danej funkcji, czy funkcjonalności. W jaki sposób to zrobić? Sprawdzając czy cel biznesowy jest: S.M.A.R.T.

1. S – (ang.Simple) – PROSTY

Cel musi być sformułowany w sposób jednoznaczny, prosty oraz zrozumiały. Dobrze sformułowany cel nie pozostawia miejsca na interpretację, domyślanie się. Proste sformułowanie celu pozwala dostawcy opracować różne rozwiązania, dzięki którym cel może być on osiągnięty. Pamiętaj, że cel nie musi być wyrażony w jednym zdaniu.

2. M – (ang.Measurable) – MIERZALNY

Definiując cel biznesowy nie możemy pomijać elementu, jakim jest jego mierzenie. To miara odpowiada nam na pytania: „ Co to oznacza, że funkcja została dobrze wykonana?” „Kiedy wiemy, że funkcjonalność jest gotowa do oddania Klientowi?” Aby zdefiniować miarę założonego celu biznesowego wystarczy poprosić klienta o opowiedzenie, w jaki sposób będzie testował daną funkcję, czy funkcjonalność. Pamiętaj, że tester sprawdza jedynie, czy produkt jest zgodny z opisem przygotowanym przez analityka biznesowego, inżyniera wymagań. Klient natomiast wykonuje testy sprawdzając poprawność funkcji wykorzystując je w normalnej pracy operacyjnej. Stąd wynikają duże nieporozumienia przy odbiorze funkcjonalności przez Klienta. Jeśli przy definiowaniu funkcjonalności nie wiemy, jaki jest jej cel powstania, i dodatkowo nie dopytamy o sposób testowania funkcjonalności przez Klienta możemy mieć duże problemy przy odbiorze produktu przez Klienta. Zawsze znajdzie się argument przemawiający za tym, że wg. Klienta funkcjonalność nie jest gotowa, bo nieuwzględniona została jeszcze jedna opcja.

Jeśli cel biznesowy projektu zakłada poprawienie wydajności, bądź generowania (czegoś) nie zapominaj o mierze jakim jest czas, ilość.

Nie pisz: „Umożliwienie generowania faktur po dokonaniu zakupu’, wiem, że to ładnie brzmi i nie trzeba zbytnio się pochylać nad tym do czego będzie wykorzystywany system – przecież jest wpisane w umowie.

Zastanów się w jaki sposób będzie sprawdzał to tester i Klient? Czy wygenerowanie 1 faktury jest wystarczającym potwierdzeniem poprawności działania? Czy generowanie 1000 faktur w ciągu 10 minut jest wystarczające dla Klienta, aby móc powiedzieć, że funkcjonalność działa zgodnie z oczekiwaniami?

3. A – (ang. Achievable) – OSIĄGALNY

Realizm – to słowo, które powinno nam towarzyszyć przy definiowaniu celu biznesowego. Nie możemy zakładać celu biznesowego, który nie jest możliwy do osiągnięcia w założonym czasie i środkach, wiedzy oraz umiejętnościach. Co to oznacza w praktyce? Wspólnie z klientem należy się zastanowić czy przy użyciu wszystkich możliwości jesteśmy w stanie dostarczyć funkcjonalność realizującą dany cel.

Spójrzmy na przykład:

System umożliwiał generowanie 100 faktur w ciągu 5 minut. Celem projektu jest zwiększenie wydajności systemu, który generowałby 100 faktur, ale w ciągu 3,5 minuty.

W pierwszej kolejności sprawdzamy ograniczenia, czyli sprawdzamy, przy jakich warunkach system jest w stanie osiągnąć taki czas generowania faktur. To co z punktu widzenia klienta jest organiczeniem, dla dostawcy jest doprecyzowaniem warunków, przy których zapewnia on poprawność działania funkcjonalności.

4.  R – (ang.Relevant) – ISTOTNY

Cel biznesowy musi być „krokiem naprzód” dla organizacji, musi nieść korzyść biznesową. W jaki sposób to sprawdzić? Zapytaj klienta:

„ W jaki sposób obecnie radzi sobie z problemem?”

„Ile zaoszczędzi czasu/pieniędzy, jeśli funkcjonalność nie zostanie wdrożona?”

Jeśli klient nadal twierdzi, że cel jest polepszeniem jego pracy, po wycenie realizacji funkcjonalności, która ma pozwolić mu osiągnąć ten cel ponownie zapytaj: „Ile zaoszczędzi czasu/pieniędzy, jeśli funkcjonalność nie zostanie wdrożona?”.

Zestawienie kosztów z korzyścią, jaką niesie dana funkcjonalność jest ostatecznym sprawdzianem istotności danego celu. Jeśli koszty wdrożenia są większe niż korzyść, jaką można dzięki niemu odnieść, zazwyczaj cel nie był istotny.

5. T – (ang. Timely defined) – OKREŚLONY W CZASIE

Definiując cel biznesowy musimy zdefiniować jego horyzont czasowy, w jakim zamierza się go osiągnąć. Może to być konkretna data, bądź czas, np. 2 miesiące. W przypadku tego drugiego konieczne jest podanie od kiedy rozpoczynamy mierzenie czasu.

Przykłady poprawnie zdefiniowanych celów biznesowych:

„Klient osiągnie 75% udziału w rynku IT w ciągu 6 miesięcy od 1 stycznia 2017 roku”

„ Zostanie zwiększona wydajność obsługi transakcji o 15% w porównaniu ze stanem obecnym, tj. 100 transakcji na minutę”.

Spójrz teraz na listę swoich celów na 2017 i sprawdź czy są S.M.A.R.T

Potrzebujesz wsparcia w wyborze?

Porozmawiajmy. Doradzę Ci opcję, która najlepej wesprze Cię na obecnym etapie rozwoju zawodowego.

Porozmawiajmy
PRACOWNIKU

Chcesz, aby pracodawca sfinansował Ci szkolenie?

Pomogę Ci przekonać go do tej decyzji.

Daj mi znać
PRACODAWCO

Chcesz zorganizować szkolenie dla pracowników?

Przygotuję szkolenie wewnętrzne ze specjalnym programem.

Porozmawiajmy