Czy aby na pewno zarządzamy procesami biznesowymi?

…ana­li­za i spe­cy­fi­ko­wa­nie wyma­gań na sys­te­my prze­pły­wu doku­men­tów czy po pro­tu popra­wy pro­ce­sów biz­ne­so­wych to przy­go­to­wa­nie fir­my do zmian orga­ni­za­cyj­nych a nie spi­sy­wa­nie ocze­ki­wań pra­cow­ni­ków z nadzie­ją, że dział HR nie odczu­je tej zmia­ny. Nie zarzą­dza­my pro­ce­sa­mi, kształ­tu­je­my je.

Czytaj dalej Czy aby na pewno zarządzamy procesami biznesowymi?

Inżynieria wymagań

Wymagania inte­re­sa­riu­szy. Moja defi­ni­cja inte­re­sa­riu­sza (jed­na z wie­lu): oso­ba (pod­miot) zain­te­re­so­wa­na zaist­nie­niem pro­duk­tu, na któ­rą poja­wie­nie się pro­duk­tu ma wpływ. Nie raz jestem pyta­ny czy inte­re­sa­riusz ma pra­wo zgła­sza­nia wyma­gań. Jeżeli ma coś do powie­dze­nia pod­czas odbio­ru pro­duk­tu to zna­czy, że ma wyma­ga­nia. One mogą być jed­nak nie­jaw­ne czy­li taki inte­re­sa­riusz nie zgła­sza wyma­gań ale ma wpływ na odbiór pro­duk­tu, nale­ży go koniecz­nie ziden­ty­fi­ko­wać. Jeżeli zaś ktoś nie ma nic do gada­nia przy odbio­rze pro­duk­tu nie jest inte­re­sa­riu­szem (ang. sta­ke­hol­der, klu­czem jest tu «hol­der» czy­li dys­po­nent mają­cy coś do powie­dze­nia, mają­cy wpływ). Tak wiec inte­re­sa­riusz to ktoś kto, na swo­im pozio­mie ogól­no­ści, tak­że musi umieć okre­ślić, kie­dy uzna, że pro­dukt speł­nia jego wyma­ga­nia. Jak nie potra­fi, ktoś musi mu pomóc…analityk :)).

I tu rola ana­li­ty­ka. Interesariusz spi­su­je co mu przyj­dzie do gło­wy swo­im języ­kiem, ana­li­tyk upew­nia się, że zro­zu­miał, dopro­wa­dza je do posta­ci testo­wal­nej i kla­sy­fi­ku­je wyma­ga­nia” jako źró­dło: kon­kret­ny inte­re­sa­riusz” (bo każ­de wyma­ga­nie musi mieć wła­ści­cie­la). Proszę zwró­cić uwa­gę, że inte­re­sa­riu­szem jest tak­że użyt­kow­nik jeże­li tyl­ko ma coś go powie­dze­nia w projekcie :).

Czytaj dalej Inżynieria wymagań

Analiza wymagań – zrozumienie

Dzisiaj krótki artykuł o wymaganiach dziedzinowych. W jednym z poprzednich artykułów pisałem o wymaganiach, że problem tkwi w ich zrozumieniu i o tym, że przyszły użytkownik nie powinien pisać "jaki…

Czytaj dalej Analiza wymagań – zrozumienie

Inżynieria wymagań ? model tego co chcemy

Niedawno mój serdeczny kolega napisał: Samo zebranie wymagań to ważny etap. Schody zaczynają się jednak dalej. Trzeba zweryfikować pozyskane wymagania, uszczegółowić, nadać priorytety. Gdzie te schody? [...] Nie mamy w Polsce…

Czytaj dalej Inżynieria wymagań ? model tego co chcemy

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy. Faktycznie, czy­tel­ni­cy mają wie­le racji, jest on dość bli­ski imple­men­ta­cji”. Niejednokrotnie lep­szym pomy­słem” jest opis logi­ki sys­te­mu na nie­co wyż­szym pozio­mie abs­trak­cji pozo­sta­wia­jąc tym samym wię­cej swo­bo­dy deve­lo­pe­ro­wi. […] Nieco inne podej­ście, to któ­re sto­su­ję obec­nie, opi­su­ję poni­żej. Zachowując pod­sta­wo­we zna­cze­nia tych trzech klas, dosto­so­wa­łem je do wzor­ca MVVC. Jest to o tyle wygod­ne i waż­ne, że sto­so­wa­nie wzor­ca BCE wyłącz­nie do mode­lo­wa­nia logi­ki biz­ne­so­wej wyma­ga zacho­wa­nia her­me­ty­za­cji kom­po­nen­tu Model. W takim ukła­dzie boun­da­ry nie będzie ele­men­tem kom­po­nen­tu View a Modelu. Jego rola to stwo­rze­nie dedy­ko­wa­ne­go inter­fej­su do model np. pomię­dzy kom­po­nen­tem View lub Controlerem. Dzięki temu moż­li­we jest stwo­rze­nie odręb­ne­go inter­fej­su dla View na duży ekran i odręb­ne­go dla View na np. małych ekra­nach smart­fo­nów. Tak więc jest moim zda­niem dro­ga do mode­lo­wa­nia wyma­gań meto­dą tak to ma dzia­łać” a nie tyl­ko tak to ma wyglą­dać”, bo to dru­gie jest przy­czy­ną wie­lu problemów…

Czytaj dalej Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Jak udokumentować zakres projektu w sposób czytelny i jednoznaczny

Krótki wpis po pew­nej nie dłu­giej dys­ku­sji na pew­nym forum. Jeden z dys­ku­tan­tów przy­to­czył defi­ni­cję zakre­su pro­jek­tu publi­ko­wa­ną w WIKI:

Zakres pro­jek­tu jest to moż­li­wie jak naj­do­kład­niej­sze i cał­ko­wi­te okre­śle­nie ocze­ki­wa­ne­go wyni­ku projektu.

Zakres nigdy nie okre­śla kon­kret­nych zadań mają­cych na celu reali­za­cję pro­jek­tu. Odpowiada na pyta­nie, co powin­no być zro­bio­ne w pro­jek­cie. Wyznacza ramy do osza­co­wa­nia kosz­tu pro­jek­tu i cza­su reali­za­cji pro­jek­tu. Zakres, koszt i czas two­rzą para­me­try pro­jek­tu, tzw. ?magicz­ny trój­kąt?. (Zakres pro­jek­tu ? Wikipedia, wol­na encyklopedia).

Tak więc mamy pyta­nie: co powin­no być zro­bio­ne w pro­jek­cie”? Pytanie jakie ja posta­wi­łem: czy­im pro­jek­cie”? Zakres pro­jek­tu dla kogo? […] W moich oczach nie ma nic bar­dziej ryzy­kow­ne­go niż prze­ka­za­nie Opisu Księgowej od razu pro­gra­mi­stom do wyko­na­nia. Bo mamy tak na praw­dę trzy zakre­sy pro­jek­tu, każ­dy inny, każ­dy ma inne­go adre­sa­ta i każ­dy nale­ży udo­ku­men­to­wać ina­czej, ale zawsze jed­no­znacz­nie posta­wić zadanie.

Praca bez tego typu doku­men­tów, bez jasne­go wydzie­le­nia poszcze­gól­nych eta­pów ana­li­zy, tak czę­sto prak­ty­ko­wa­na przez wie­le firm IT, to atak na twier­dzę bez mapy tere­nu i strategii… 

Czytaj dalej Jak udokumentować zakres projektu w sposób czytelny i jednoznaczny