niedziela, 30 sierpnia 2015

Strategiczne partnerstwo Sparx Systems oraz IIBA

Organizacja IIBA, czyli International Institute of Business Analysis, a zatem organizacja wyznaczająca standard w dziedzinie analizy biznesowej ogłosiła niedawno, że podpisała memorandum stanowiące globalne strategiczne partnerstwo z trzema organizacjami. Jedną z nich jest Sparx Systems Pty Ltd., a zatem producent narzędzia Enterprise Architect.



Co może oznaczać ten sojusz dla użytkowników EA?

W komunikacie prasowym wskazano, że Sparx Systems oraz IIBA podzielają zainteresowanie i zaangażowanie w zwiększanie wartości świadczonych dla swoich interesariuszy. Poprzez wzajemne wspieranie wysiłków w określonych obszarach dzięki nowej współpracy skorzystają zarówno członkowie IIBA, jak również klienci Sparx Systems.

Wskazano następujące konkretne inicjatywy:

  • Potencjalna integracja BABOK® 3.0 z Enterprise Architect.
  • Oferta dostępu do różnych zewnętrznych zasobów, narzędzi oraz rozszerzeń w celu zwiększenia produktywności i wydajności.
  • Pozostałe korzyści dotyczą wzajemnego docierania do szerszych grup odbiorców, dzięki czemu IIBA będzie mogła zyskać na popularności w świecie użytkowników Sparx EA, jak również członkowie IIBA będą kojarzyć modelowanie z oprogramowaniem firmy Sparx Systems.
Osobiście uważam, że jeśli pojawią się namacalne efekty tego sojuszu, to przyczyni się do to większego ustandaryzowania w dziedzinie analizy biznesowej i systemowej. Co prawda, nie wyobrażam sobie, na czym może polegać integracja BABOK® w oprogramowaniu, które jest tak elastyczne w dziedzinie modelowania. Na pewno dużą wartość dodaną wniesie już ujednolicenie stosowanych terminów oraz stworzenie materiałów szkoleniowych, które pokazują jak prowadzić analizę zgodną z  BABOK® w Sparx EA.

IIBA zawiązała podobny sojusz jeszcze z firmami:

  • BCS The Chartered Institute for IT
  • IREB®
  • BRMI  

Link do komunikatu na stronie IIBA: www.iiba.org/mou.aspx


sobota, 29 sierpnia 2015

Bo ten projekt jest specyficzny...

Gdy rozmawiam z ludźmi zaangażowanymi w realizację projektów informatycznych i dochodzimy do kwestii stosowania standardów, czy to ogólnie przyjętych, czy też standardów ustanowionych w organizacji, często słyszę, że w odniesieniu do tego, konkretnego projektu niemożliwe jest zastosowanie żadnego standardu, bo ten projekt jest specyficzny...
Później przychodzi refleksja, że tak naprawdę można to powiedzieć o każdym projekcie. Czy to oznacza, że każdy projekt jest specyficzny?

Otóż według metodyk zarządzania projektami projekt to przedsięwzięcie:
  • jednorazowe,
  • niepowtarzalne,
  • złożone.
Cechy traktujące o tym, że projekt jest jednorazowy i niepowtarzalny - oznaczają de facto, że projekt w swojej naturze jest specyficzny. Z drugiej strony złożoność przedsięwzięcia skłania do posiłkowania się jakimś usystematyzowanym podejściem, aby lepiej radzić sobie z planowaniem, kontrolowaniem i sterowaniem.

Jak to zatem jest w praktyce? Przecież osoby zaangażowane w projekty z reguły znają doskonale metodyki zarządzania projektami: PMI, Prince2..., znają standardy wytwarzania oprogramowania, takie jak: SWEBOK, standardy analityczne, takie jak: BABOK. A jak przychodzi do ich stosowania w świecie rzeczywistym, to kierują się bardziej intuicją niż wypracowanym podejściem?

Zauważam często problemy w przełożeniu teorii na praktykę. Trudno powiedzieć z czego one wynikają.
Czy źródło problemu leży po stronie metodyk, ludzi czy samych przedsięwzięć? A może po części wynika z każdego z tych elementów?

Z punktu widzenia metodyk, czy też innych standardów, które warto stosować w projektach być może za słabo jest akcentowany temat dostosowania przy jednoczesnym narzucaniu szczegółowych rozwiązań...
Choć często metodyka, czy standard wyróżnia elementy obligatoryjne oraz elementy fakultatywne. Jednakże być może brakuje dostatecznego uzasadnienia dla stosowania elementów obligatoryjnych. W przypadku metodyki Prince2 powstało nawet pojęcie PINO, czyli Prince In Name Only.

A może metodyki są zbyt szczegółowe i powinny narzucać tylko ogólne pryncypia, natomiast każdy specyficzny projekt określałby rozszerzenia wykonawcze opisujące, jak takie pryncypia są realizowane?
Ale, czy w takim ujęciu metodyki byłyby w ogóle przydatne?

A może problem nie leży jednak w po stronie metodyk i standardów, tylko ludzi, którzy powinni się nimi kierować? W trakcie szkoleń ludzie zapoznają się z materiałami w stopniu umożliwiającym im zdanie egzaminu. Nawet, jeśli pytania egzaminacyjne są nakierowane na wykorzystanie zdobytej wiedzy w praktyce, to jednak taka wiedza może jest niewystarczająca...  Rzeczywistość bywa z reguły bardziej złożona od modelu, który ją opisuje. Modele opisują rzeczywistość projektową, z którymi ludzie mają do czynienia w trakcie szkoleń i egzaminów. Modele te nie są w stanie opisać w pełni rzeczywistości. W rozpatrywanych przypadkach może brakować czynników takich, jak relacje międzyludzkie, konflikty interesów, brak zrozumienia po stronie klienta, czy menedżera. A są to czynniki, które pośrednio wpływają na podejmowane decyzje. W przypadku, gdy człowiek odczuwa zagrożenie (np. ze strony szefa, kolegów, klientów) zaczyna się kierować intuicją, która ma pomóc mu zmniejszyć zagrożenie. Można to porównać do ucieczki zwierzęcia przed drapieżnikiem: takie zwierzę skupia się bardziej nad tym, żeby biec, niż nad tym - dokąd biegnie.

Podobnie bywa w "lesie projektowym". Członkowie zespołu projektowego starają się "dowieźć" projekt. Zaczynają bieg, za nimi zawsze biegnie ktoś inny. W takiej sytuacji nie ma pewności, czy biegacz będzie biegł po ścieżkach wyznaczonych standardami, czy może jednak będzie wybierać drogi, które w danym momencie wydają się lepsze. A w takim przypadku nie ma pewności, czy dobiegnie do mety, czy po drodze nie wpadnie w jakieś pułapki, których nie dostrzegł w porę.