o modelowaniu procesów i systemów 

W ostatnią sobotę na moim blogu wystartowały konsultacje online

Konsultacje online to usługa usługa doradztwa udzielana przez Internet za pomocą platformy o nazwie System Konsultacji Online (SKO). Platforma ta znajduje się pod adresem:

http://www.wolski.waw.pl/konsultacje-online/

Konsultacje online są dedykowane tym wszystkim, którzy mają wątpliwości lub problemy związane z inżynierią oprogramowania a nie mogą (z różnych przyczyn) skorzystać z konsultacji tradycyjnych. Usługa ta świetnie się sprawdza w sytuacjach gdy rozwiązanie danego problemu musi nastąpić w miarę szybko. W najszybszym wariancie odpowiedź zostanie udzielona w przeciągu 24 godzin od odnotowania wpłaty.

Koszt jednej konsultacji online to wydatek rzędu kilkudziesięciu złotych. Każde zapytanie jest wyceniane indywidualnie a cena jest uzależniona nie tylko od złożoności pytania ale także od czasu realizacji usługi.

Myślę, że konsultacje online znajdą  przede wszystkim zastosowanie w sytuacjach gdy podczas pracy nad projektem wątpliwości pojawiają się sporadycznie i angażowanie zewnętrznych konsultantów do odpowiedzi na jedno lub kilka pytań jest nieopłacalne.

Konsultacje online to także anonimowość zadającego pytanie, gdyż zarówno w czasie korzystania z usługi dane osobowe mogą być nieprawdziwe a system płatności za te usługi po za adresem e-mail nie przekazuje żadnych danych osobowych płatnika.

Z nowym rokiem uzupełniłem kilka wpisów, które były niedokończone a które miały się ukazać w grudniu. Pierwsze dwa tygodnie były dość pracowite dla mnie.  Jedno z zadań z jakiego myślę, że wywiązałem należycie się to autorskie szkolenie zakresu gromadzenia i zarządzania wymaganiami w Enterprise Architect.  Dlaczego myślę, że wywiązałem się należycie. W testach z wiedzy przed i po szkoleniu widać progres u każdego z uczestników szkolenia. Ponadto w ankietach oceniających szkolenie otrzymałem dobre i bardzo dobre noty. Innym ciekawym przedsięwzięciem w jakim mogłem uczestniczyć to współpraca z polskim instytutem badawczym. Pomagałem im, i mam nadzieję, że w nowym roku także będę to robił,  w zakresie budowy architektury złożonego systemu (sprzęt + oprogramowanie) oraz zarządzaniem wymaganiami na ten system. Zadanie to jest tym bardziej ciekawe, że jest to jeden z ostatnich polskich instytutów z polską myślą inżynierską. To rzadkość  na polskim rynku, a dla mnie satysfakcja z pracy z rewelacyjnymi polskimi inżynierami, specjalistami w swojej dziedzinie, praktykami w każdym calu. W tym instytucie tworzą się na prawdę innowacyjne polskie produkty.

Przymiotnik polski powtórzyłem celowo kilka razy.

Ostatni czwartek i piątek spędziłem wspomagając bardzo ciekawą firmę. Otóż jest to Polska firma pisząca systemy wspierające szerokorozumianą e-administrację. Nasuwa sie pytanie a gdzie są te systemy? Otóż w USA. Tak tak Polskie, niewielkie, firmy mogą pisać oprogramowanie wspierające obywateli innych Państw. A my, obywatele 4,5,6 RP jesteśmy gorsi? Myślę, że nie ale za to bardziej specyficzni bo u nas znów ogłoszony zostanie przetarg, do którego będą mogły przystąpić (czyt. będą spełniać warunki formalne) 3-4 firmy, potem lista odwołań, i? kolejny przetarg? ach szkoda pisać. Nawiasem mówiąc to kolejna średniej wielkości firma w Polsce, z którą miałem okazję współpracować, która robi rzeczy wielkie. Szkoda, że są one niedoceniane na rynku lokalnym bo mało jest firm, które mają doświadczenie zdobyty w kilkunastu zagranicznych projektach.

Na koniec pragnę tylko pochwalić się, że jako konsultant otrzymałem dobre i bardzo dobre noty. Dziękuję.

Panuje powszechna opinia, że modele wyrażone w języku UML są niezrozumiałe i nie wiadomo jak go stosować. Problem czytelności diagramów jest tym bardziej istotny, gdy dokumentacji (jakże pieczołowicie) wykonanej w UML nie umie przeczytać Klient. Tak to problem, z którym czasem się spotykam. Wtedy zanim Klient zobaczy wartość modelowania  pozwalam nazywać poszczególne elementy notacji tak jak je nazwał klient przy zachowaniu odpowiedniego znaczenia tego elementu. I tak przykładowo aktor na początku nazywany jest ludzikiem z czasem jest nazywany systemem lub użytkownikiem by potem gdy klient wdraża już UML?a na stałe nazwać go poprawnie aktorem. Oczywiście pilnuję by znaczenie aktora na diagramach przypadków użycia nie zostało zniekształcone.  Ta metoda sprawdziła mi sie w u większości klientów, którzy nie używali UML. Niestety nie u wszystkich

Na koniec została sprawa jak stosować UML i kiedy? Nie ma jednoznacznej odpowiedzi na ten temat, gdyż użycie języka UML zależy od specyfiki realizowanego projektu, etapu na którym się ten projekt znajduje, czy znajomości języka UML przez różne osoby zaangażowane w dany projekt. Z tego też powodu potrzebne jest pewne doświadczenie. Ale jak zdobyć to doświadczenie, gdy książki mówią o notacji UML a nie o tym jak go stosować a przykłady z Internetu też są banalne? Na początek proponuję konsultacje u doświadczonej osoby, która ma za sobą kilka projektów z wykorzystaniem UML. Byłoby rewelacyjnie gdyby taka osoba nadzorowała nasze prace – była takim Aniołem Stróżem UML. Myślę, że takie spotkania dadzą więcej niż nawet kilkudniowe szkolenie.

W dniach 02-03 czerwca w Warszawie przeprowadziłem szkolenie z modelowania systemów informatycznych w UML 2.1. W otwartym szkoleniu brało udział 15 osób o zróżnicowanym stopniu przygotowania i doświadczenia. Osoby te reprezentowały różne firmy i tym  samym różne branże. Ponadto każda z osób miała inne oczekiwania wobec szkolenia co powodowało bardzo ciekawe dyskusje, w których uczestnicy mogli wymienić się swoimi doświadczeniami. W trakcie szkolenia, po przekazaniu podstawowych wiadomości teoretycznych odbyły się warsztaty, które wykonane były przy pomocy Enterprise Architect. Łącznie zrealizowaliśmy 10 godzin warsztatów w czasie dwudniowego szkolenia.  Szkolenie uważam za udane i myślę, że moją opinię potwierdzają anonimowe ankiety wykonane po szkoleniu. I tak  sposób prezentacji jako dobry i bardzo dobry oceniło 53% szkolenia. Być może przyczyną było zbyt wielkie tempo jakie nałożyłem na uczestników, ale ostatnie zadania polegające na wykonaniu modelu (lub jego fragmentu) systemu informatycznego, zarówno w zakresie modelu przypadków użycia i modelu analitycznego, wszystkie osoby wykonywały w sposób poprawny. Przygotowane przeze mnie materiały zostały uznane za dobrze i bardzo dobrze przygotowane przez 86% uczestników. Natomiast moje przygotowanie, jako trenera zostało ocenione jako dobre i bardzo dobre przez 80% uczestników szkolenia. Zdaniem organizatorów (Software-Konferencje) następna edycja szkolenia we wrześniu.  Zapraszam.

Jednym z ciekawszych wyzwań dla mnie jako trenera są sesje jednoosobowe. Specyfika takich spotkań polega na tym, że pomoc i kierowanie rozwojem umiejętności w modelowaniu procesów biznesowych lub systemów informatycznych jest bardzo precyzyjnie ukierunkowana na uczestnika sesji. Odmienność od szkolenia polega na tym, że coaching zapewnia znacznie bardziej indywidualne podejście, dopasowane do aktualnych potrzeb, wyzwań i ogólnej sytuacji. Dzięki temu w ciągu kilku godzin można rozwiązać znacznie więcej problemów z jakim boryka się Klient. Jest jeszcze jedna zaleta. Przeprowadzenie sesji z jedną osobą to przez cały dzień 100% zaangażowania po stronie Klienta przez co zyskuje on dużo więcej.  Elastyczność sesji coaching’owych też nie jest bez znaczenia.

W swojej pracy staram się poza pełnym zaangażowanie stosować zasady praktykowane przez International Coaching Community, która Międzynarodową Społecznością Coachów, posiadającą określone standardy etyczne i zawodowe, oraz opisane kompetencje Coacha.  Efekt? W ostatnich dwóch miesiącach odbyły się trzy sesje jednoosobowe z trzema różnymi osobami. Podsumowując uzyskane trzy ankiety otrzymałem w skali od 1-5 następujące oceny:

Ocenione jednodniowe sesje szkoleniowe dotyczyły modelowania biznesowego i inżynierii oprogramowania w ujęciu ogólnych problemów z jakimi borykał się Klient.