F.A.Q.

29 Lipca 2018 r. w Sopocie mia­ło miej­sce pierw­sze popo­łu­dnio­we spo­tka­nie Analiza Biznesowa 3 mia­sto” zor­ga­ni­zo­wa­ne wspól­nie z por­ta­lem Analiza​.IT a celem było Stary ana­li­tyk odpo­wia­da na pyta­nia młodych” 🙂

W ramach pod­su­mo­wa­nia spo­tka­nia zebra­li­śmy pyta­nia zdo­by­wa­ją­cych doświad­cze­nie ana­li­ty­ków, wspól­nie uzna­ne za repre­zen­ta­tyw­ne dla całe­go spotkania.

Oto one i moje odpo­wie­dzi. Starałem się nicze­go nie ukry­wać, trak­tuj­cie to jak szcze­re kole­żeń­skie rady, obcią­żo­ne moim 20-let­nim doświad­cze­niem i subiektywizmem.

Znajdziecie tu i trosz­kę inży­nie­rii i tech­no­lo­gii, i trosz­kę filo­zo­fii i trosz­kę ety­ki zawodu…

Zapraszam

Jarek Żeliński

Nowy analityk w korporacji, jak ma się zachować gdy wchodzi w nieuporządkowany projekt i niezbyt uporządkowane, chaotycznie tworzone papiery”?

To chy­ba naj­trud­niej­sze pyta­nie i naj­prost­sza odpo­wiedź: ma być uczci­wy wzglę­dem sie­bie. Jeżeli wszedł w miej­sce poprzed­ni­ka by go po pro­stu zastą­pić (ana­li­tyk przy­jął zło­żo­ną mu ofer­tę pra­cy), to pozo­sta­je mu tego poprzed­ni­ka zastą­pić w sfe­rze tego jak ten pra­co­wał i jakie doku­men­ty two­rzył. Jeżeli ktoś został zatrud­nio­ny bo pra­co­daw­ca uznał, że poprzed­nik robił coś gorzej a nowy pra­cow­nik ma wie­dzę by popra­wić dotych­cza­so­wą jakość pra­cy, i być może wdro­żyć nowe i lep­sze prak­ty­ki, to zna­czy że ma speł­nić tę obietnicę ;).

Tu waż­na uwa­ga: nie da się refor­mo­wać fir­my bez wie­dzy i zgo­dy jej zarzą­du a pro­jek­tu bez wie­dzy i zgo­dy Kierownika Projektu. Można owszem świe­cić przy­kła­dem”, ale nale­ży przy tym pamię­tać, że to nie to samo co robie­nie ina­czej i lepiej niż inni”, bo tak moż­na roz­sa­dzić fir­mę (pro­jekt) od środka.

Tak więc podej­mu­jąc się nowej pra­cy nale­ży przy­jąć na sie­bie wszel­kie wyni­ka­ją­ce z tego obo­wiąz­ki, napra­wia­nie świa­ta nale­ży robić zawsze za wie­dzą i zgo­dą zwierzch­ni­ków :). Jednak pod­sta­wo­wym, moral­nym i etycz­nym zada­niem każ­de­go z nas, jest infor­mo­wa­nie prze­ło­żo­nych o dostrze­żo­nych ryzykach.

Czego i jak się uczyć, żeby zacząć pracować w analizie

Analiza biz­ne­so­wa (ana­li­za sys­te­mo­wa orga­ni­za­cji) i szu­ka­nie roz­wią­zań pro­ble­mów, to pra­ca bar­dzo podob­na do pra­cy nauko­wej. Przyjęcie ana­li­zy sys­te­mo­wej jako fun­da­men­tu metod pra­cy, pozwa­la nie tyl­ko upo­rząd­ko­wać pra­ce ana­li­tycz­ne, ale tak­że upo­rząd­ko­wać cały pro­ces szu­ka­nia roz­wią­za­nia. Każdemu, kto ma ocho­tę się roz­wi­jać, pole­cam osią­gnię­cia myśli­cie­li z obsza­ru filo­zo­fii nauki (patrz arty­kuł Wiedza a nauka i praw­da). […] Tu tak­że inny arty­kuł zaczy­na­ją­cy się od słów:

Analiza sys­te­mo­wa, ogól­na teo­ria sys­te­mów, świat to cha­os czy zło­żo­ność? Biznes i jego oto­cze­nie to zło­żo­ność, któ­ra dla wie­lu jest cha­osem. (Źródło: Wszystkie dro­gi pro­wa­dzą do Rzymu | | Jarosław Żeliński IT-Consulting).

Uogólniając, war­to się oswo­ić z filo­zo­fią ana­li­tycz­ną i logi­ką, bo na niej mię­dzy inny­mi opar­te są fun­da­men­ty nota­cji takich jak UML, BPMN i nie tyl­ko. Warto nauczyć się zapi­sy­wać zdo­by­tą wie­dzę o ana­li­zo­wa­nej orga­ni­za­cji z pomo­cą sche­ma­tów blo­ko­wych i for­mal­nych nota­cji, zgod­nie z maksymą:

jeże­li cze­goś nie potra­fisz popraw­nie nary­so­wać to zna­czy, że jesz­cze tego nie rozumiesz…

Ważna rzecz: gdy tyl­ko to moż­li­we, czy­tać cudze doku­men­ty i ana­li­zo­wać ich wady, w szcze­gól­no­ści wszyst­ko to, co oka­za­ło się nie­ja­sne i nie­jed­no­znacz­ne, to co było przy­czy­ną poraż­ki pro­jek­tu, bo to te wady doku­men­tów, któ­re nale­ży usu­wać w swo­jej wła­snej pracy.

I pod­sta­wa: nie być kon­for­mi­stą (ponad 3/4 pro­jek­tów IT to wto­py a nie suk­ce­sy.… wiec więk­szość nie ma racji). Na tej Stronie (mój blog) znaj­dzie­cie recen­zje wybra­nych ksią­żek, któ­re polecam.

Czy są gotowe zestawy dokumentów, w oparciu o które można napisać specyfikację

Osobiście nie spo­tka­łem takich i nie pole­cam ich szu­ka­nia… Każda ana­li­zo­wa­na fir­ma jest inna, więc każ­da ana­li­za będzie mia­ła inną wyni­ko­wą treść. Można mówić o ramie, czy­li klu­czo­wych eta­pach ana­li­zy i tym samym o klu­czo­wych roz­dzia­łach specyfikacji:

  1. wpro­wa­dze­nie czy­li cel biz­ne­so­wy pod­mio­tu ana­li­zo­wa­ne­go, tak­że to (opis) jak spraw­dzi­my, że fir­ma ten cel (po zakoń­cze­niu pro­jek­tu) zre­ali­zo­wa­ła (tu przy­da­je się nota­cja BMM),
  2. model dzia­ła­nia pod­mio­tu ana­li­zo­wa­ne­go poka­zu­je w jaki spo­sób orga­ni­za­cja dzia­ła, nale­ży przede wszyst­kim zba­dać i poka­zać jak powsta­ją doku­men­ty i ich treść, co powo­du­je (jakie fak­ty), że te doku­men­ty w ogó­le powsta­ją (tu mode­le pro­ce­sów biz­ne­so­wych, sza­blo­ny doku­men­tów, słow­ni­ki i regu­ły biz­ne­so­we, głów­nie nota­cje BPMN, SBVR, tu ewen­tu­al­nie UML jako narzę­dzie doku­men­to­wa­nia aktu­al­ne­go sta­nu IT w organizacji),
  3. pro­jekt roz­wią­za­nia pro­ble­mu, czy­li opis sta­nu doce­lo­we­go: jakie roz­wią­za­nie (zmia­ny orga­ni­za­cyj­ne, nowe sys­te­my IT, inne) nale­ży wdro­żyć by zre­ali­zo­wać cel biz­ne­so­wy; to etap napi­sa­nia wyma­gań na nowe roz­wią­za­nie, jeże­li zapa­da decy­zja że będzie to nowe lub aktu­ali­zo­wa­ne opro­gra­mo­wa­nie, pisze­my wymagania: 
    1. jeże­li ryzy­ko pro­jek­tu jest nie­zbyt duże, opi­sać je tra­dy­cyj­nie czy­li cecha­mi ocze­ki­wa­ny­mi, np. zgod­nie z nor­mą IEEE Std 830‑1998,
    2. jeże­li oka­że się, że opis meto­dą cech zewnętrz­nych jest zbyt ryzy­kow­ny (czy­li w zasa­dzie każ­dy nie­try­wial­ny sys­tem), idzie­my w MDA/MDE (model PIM w UML, INCOSE/SysML) opi­sy­wa­ne na tym blo­gu nie raz bo w tym się specjalizuję.

Dokumentacja w procesach prowadzonych zwinnie – czy jest potrzebna, jak dokładna powinna być, kiedy powinna być tworzona, kiedy się przydaje?

O zwin­no­ści w IT zapi­sa­no tony papieru :).

Każdy kto poszedł do skle­pu i wró­cił z nie­go bez waż­nych spra­wun­ków, wie po co pisze­my listy zaku­pów: nie mamy aż tak dobrej pamię­ci. Generalnie brak doku­men­ta­cji ma takie same skut­ki jak jej nad­miar: bar­dzo szko­dzi w pro­jek­cie i pod­no­si kosz­ty. Dokumentacja to komu­ni­ka­cja mię­dzy uczest­ni­ka­mi pro­jek­tu i same­mu z sobą (prze­czy­taj­cie swo­je doku­men­ty z przed kil­ku mie­się­cy, a nawet tyl­ko z przed tygodni).

Co do zasa­dy, doku­men­to­wać nale­ży wszyst­kie decy­zje, w szcze­gól­no­ści archi­tek­to­nicz­ne. Decyzjami są w szcze­gól­no­ści zatwier­dzo­ne wyma­ga­nia (klient zde­cy­do­wał, że chce TO mieć). Podstawowym celem two­rze­nia doku­men­ta­cji jest potrze­ba wie­dzy o tym CO ZOSTAŁO ZAMÓWIONE oraz CO ZOSTAŁO ZROBIONE i DLACZEGO TAK.

Pod poję­ciem zwin­no­ści rozu­miem takie pro­wa­dze­nie pro­jek­tu i doku­men­ta­cji, by nie powsta­wa­ły tre­ści (doku­men­ty) zbęd­ne, czy­li przede wszyst­kim nie powin­ny powsta­wać opi­sy zawierające:

  1. szyb­ko dez­ak­tu­ali­zu­ją­ce się deta­le, pro­jekt trwa w cza­sie a czas to zmia­na oto­cze­nia ryn­ko­we­go czy­li tak­że wymagań,
  2. zapi­sy tre­ści spo­tkań, zupeł­nie wystar­czy pier­wot­ny doku­ment wyma­gań (patrz wyżej pro­dukt ana­li­zy) i bie­żą­ce aktu­ali­zo­wa­nie go na pod­sta­wie zgło­szo­nych żąda­nych zmian lub pytań o kolej­ne szczegóły.

Tu podam przy­kład: doku­men­ta­cja wyma­gań dla Senatu mia­ła w momen­cie roz­po­czę­cia prac deve­lo­pe­ra (wyma­ga­nia na dzień ogło­sze­nie prze­tar­gu) 35 stron (war­tość ofer­ty na wyko­na­nie tego co w niej opi­sa­no to ok. 250 tys.). Plan komu­ni­ka­cji wyglą­dał tak, że odpo­wie­dzią na każ­de pyta­nie deve­lo­pe­ra była odpo­wiedź (nad­zór autor­ski) w posta­ci zak­tu­ali­zo­wa­nej w odpo­wied­nim miej­scu doku­men­ta­cji z począt­ku pro­jek­tu. Developer musiał z góry dekla­ro­wać wszyst­kie swo­je bie­żą­ce tech­nicz­ne decy­zje (kon­cep­cja wdro­że­nia), któ­re były tak­że nano­szo­ne w doku­men­ta­cji. W efek­cie w dniu zakoń­cze­nia two­rze­nia opro­gra­mo­wa­nia ist­nia­ła kom­plet­na jego doku­men­ta­cja: mia­ła 84 stro­ny. Reszta to deta­le w kodzie i doku­ment Koncepcji Wdrożenia czy­li to co opra­co­wał i wyko­nał deve­lo­per (ja się na to tyl­ko powołuję).

Nie jest też praw­dą, że doku­men­ta­cja jest (linio­wo?) tym więk­sza im więk­sza apli­ka­cja ma powstać. Im więk­sza apli­ka­cja tym dłu­żej w cza­sie trwa jej powsta­wa­nie, dla­te­go im więk­szy pro­jekt tym doku­men­ta­cja jest bar­dziej poli­ty­ką budo­wy sys­te­mu, jego archi­tek­tu­ra i kon­cep­cja, niż deta­licz­nym pro­jek­tem, co oczy­wi­ście wca­le nie zna­czy, że jej powsta­nie nie będzie kosz­tow­niej­sze: do prze­ana­li­zo­wa­nia jest duża orga­ni­za­cja i duży projekt.

Jakość tworzonej dokumentacji (temat omawiamy przy okazji wspomnienia o instrukcji wyłączenia kontroli składni w EA)

O jako­ści doku­men­ta­cji decy­du­je w 100% jej zro­zu­mia­łość (w tym tak­że więc jed­no­znacz­ność), spój­ność i kom­plet­ność (nie mylić z jako­ścią same­go opi­sa­ne­go w niej pro­jek­tu). To zaś ozna­cza, że wszel­kie odstęp­stwa od stan­dar­dów to pogor­sze­nie jako­ści. Ideałem jest taki doku­ment, któ­ry został w cało­ści prze­czy­ta­ny przez jego adre­sa­ta deve­lo­pe­ra (a więc nie­zbyt obszer­ny) i nie wyma­ga kon­tak­tu z jego auto­rem to by zro­zu­mieć jego treść i jed­no­znacz­nie ją zin­ter­pre­to­wać. W prze­tar­gach mier­ni­kiem jako­ści jest np. licz­ba pytań ofe­ren­tów do tre­ści wyma­gań a w każ­dym pro­jek­cie ilość wpro­wa­dza­nych zmian (ale nie roz­sze­rzeń). Tak więc odstęp­stwa od zasad sto­so­wa­nia uży­tych nota­cji, sto­so­wa­nie slan­gu w tre­ści, sto­so­wa­nie nie­stan­dar­do­wych i zamknię­tych licen­cja­mi metod i nota­cji, brak słow­ni­ka pojęć, to wszyst­ko powo­du­je, że doku­men­ta­cja sta­je się sama z sie­bie pro­ble­mem w projekcie.

Jedną z naj­gor­szych rze­czy jest nie­ste­ty łama­nie zasad uży­tej nota­cji, a nie raz po pro­stu nie­umie­jęt­ne (nie­za­mie­rzo­ne) jej sto­so­wa­nie. W jed­nej z ksią­żek na temat uży­cia UML, jej autor słusz­nie zauwa­ża we wstępie:

Wielu auto­rów doku­men­tów pro­jek­to­wych uży­wa UML (BPMN, itp.) nie jak sfor­ma­li­zo­wa­nych sys­te­mów nota­cyj­nych a jak biblio­te­ki sym­bo­li w Power Poincie, jest to tra­ge­dia tych autorów.

(o wali­da­cji w EA nie­daw­no pisa­łem wię­cej)

Narzędzia wspomagające pracę analityka – visual paradigm (VP) a enterprise architect (EA), co lepsze, jak dokonać wyboru

To kla­sycz­ne pyta­nie o narzę­dzia. Pierwsza rzecz: narzę­dzie, któ­re znasz jest zawsze lep­sze od tego, któ­re­go nie znasz. Warto też wie­dzieć, że na ryn­ku pra­cy stan­dar­dem de fac­to jest nadal EA (wystar­czy spoj­rzeć na ogło­sze­nia o pra­cę). Od tego momen­tu będzie subiektywnie ;):

  • EA jest rela­tyw­nie tani, dość powszech­ny, ale też mało ergo­no­micz­ny i bar­dzo pra­co­chłon­ny, nadal domi­nu­je w kor­po­ra­cjach i dużych fir­mach IT bo tu liczy się dostęp­ność kom­pe­ten­cji na ryn­ku pra­cy zaś koszt pro­jek­tów spa­da na dru­gi plan bo klien­ci i tak zapła­cą za men­dej­sy”.
  • VP jest droż­szy od EA, zaczy­na jed­nak domi­no­wać w małych fir­mach o małej rota­cji pra­cow­ni­ków i u fre­elan­ce­rów, bo jest ergo­no­micz­ny, ma bar­dzo dobre wspar­cie dla sfor­ma­li­zo­wa­nych nota­cji a tak­że dla meto­dyk zwin­nych, ma wer­sje pol­ską (w tym pol­ską kon­tro­lę orto­gra­fii), pozwa­la two­rzyć w locie doku­men­ta­cję bez potrze­by korzy­sta­nia z pakie­tów biu­ro­wych i pro­gra­mo­wa­nia SQL; VP daje bar­dzo wyso­kiej jako­ści usłu­gi w chmu­rze jaki­mi są ser­wer wer­sjo­nu­ją­cy pro­jek­ty i narzę­dzia do zdal­nej komu­ni­ka­cji z klien­ta­mi (1 GB na pro­jek­ty w cenie licencji).

Ja uży­wam VP od 2005 r., na warsz­ta­tach zaś nadal regu­lar­nie mie­wam uczest­ni­ków z EA, zawsze mają jakieś z two­rze­niem dia­gra­mów w zgo­dzie z nota­cją i meto­da­mi takim jak śla­do­wa­nie i zawsze two­rze­nie dia­gra­mów trwa dłu­żej niż i mnie z uży­ciem VP.

Od pra­wie 10 lat nie uży­wam pakie­tów biu­ro­wych (edy­to­rów tek­stów i arku­szy kal­ku­la­cyj­nych) do two­rze­nia doku­men­ta­cji (wyżej wska­za­na doku­men­ta­cja dla Senatu powsta­ła w 100% z uży­ciem VP).

Sami więc musi­cie wybrać…

Czy logowanie” jest przypadkiem użycia ( ? )

Logowanie nie jest powo­dem zaku­pu opro­gra­mo­wa­nia, logo­wa­nie to jed­na z moż­li­wych imple­men­ta­cji wyma­ga­nia ?tyl­ko auto­ry­zo­wa­ny użyt­kow­nik może korzy­stać z apli­ka­cji?, co nie prze­szka­dza więk­szo­ści ama­to­rów uży­wa­nia tych dia­gra­mów (w tym auto­rów ksią­żek) potrak­to­wa­nia logo­wa­nia jako przy­pad­ku uży­cia apli­ka­cji. Dobrym testem sen­su umiesz­cza­nia takich rze­czy na dia­gra­mach przy­pad­ków uży­cia jest zada­wa­nie sobie pyta­nia: ?czy kupił byś tę apli­ka­cję tyl­ko dla tego jed­ne­go przy­pad­ku użycia??

Tyle cytat z moje­go arty­ku­łu Ile przy­pad­ków uży­cia? | | Jarosław Żeliński IT-Consulting (pole­cam lek­tu­rę całe­go). Wiele nie­po­ro­zu­mień two­rzy książ­ka Alistaira Cockburn’a Stosowanie przy­pad­ków uży­cia: jego książ­ka nie ma nic wspól­ne­go z UML. Jeżeli powyż­sze jed­nak pyta­nie o przy­pad­ki uży­cia doty­czy dia­gra­mów w UML, to przy­pa­dek uży­cia jest tam defi­nio­wa­ny jako usłu­ga dla akto­ra świad­czo­na przez sys­tem, dla któ­rej to usłu­gi został on kupiony/stworzony”. Mam świa­do­mość ile jest tego rodza­ju przy­kła­dów (logo­wa­nie jako przy­pa­dek uży­cia) w sie­ci, ale war­to tu nie być konformistą…

Przypomnę, że tak­że opcja w menu każ­de­go opro­gra­mo­wa­nia [Exit/Zakończ/Wyloguj] jest kli­ka­na, ma dia­log [czy jesteś pewien TAK/NIE] i mimo to nie jest przy­pad­kiem uży­cia tego oprogramowania.

Jaka jest różnica między analitykiem biznesowym a analitykiem systemowym

Na to pyta­nie nie ma odpo­wie­dzi, bo te poję­cia nie mają ści­słej defi­ni­cji. Zwyczajowo się przyj­mu­je w wie­lu fir­mach podział na:

  • ana­li­tyk biz­ne­so­wy zbie­ra i porząd­ku­je wyma­ga­nia (eli­ci­ta­tion),
  • ana­li­tyk sys­te­mo­wy coś pro­jek­tu­je w UML (sys­tem description).

Patrząc na wcze­śniej­sze moje odpowiedzi:

  • czę­sto ana­li­ty­kiem biz­ne­so­wym nazy­wa się oso­bę two­rzą­cą SRS (System Requirements Specification, spe­cy­fi­ka­cja wyma­gań), naj­czę­ściej zgod­nie z IEEE Std 830‑1998,
  • czę­sto ana­li­ty­kiem sys­te­mo­wych nazy­wa się archi­tek­ta opro­gra­mo­wa­nia (co nie do koń­ca jest zgod­ne z praw­dą i faktami),
  • ale w MDA powsta­ją mode­le: CIM, PIM PSM, ana­li­tyk biz­ne­so­wy (patrz tak­że IIBA) powi­nien być auto­rem mode­li CIM i PIM, deve­lo­per (wyko­naw­ca) wyko­na imple­men­ta­cję i być może wyko­na tak­że model PSM; rola tak zwa­ne­go ana­li­tyk sys­te­mo­we­go zani­ka, nie tyl­ko w lite­ra­tu­rze, jako sztucz­na rola pomię­dzy tymi dwie­ma (ana­li­tyk pro­jek­tant i deve­lo­per czy­li wykonawca).

Cel biznesowy w dokumentacji – co zrobić, gdy: brak jasno sprecyzowanego celu biznesowego; cele biznesowe wykluczają się nawzajem; cele biznesowe wykraczają poza obszar projektu

To będzie krót­ka odpo­wiedź: nie reali­zo­wać takie­go pro­jek­tu. Wiem, że pra­co­daw­cy ana­li­ty­ka może się taka odpo­wiedź nie spodo­bać, ale pod­trzy­mu­ję swo­je zda­nie. Jeżeli nie uda się zama­wia­ją­ce­go namó­wić na usu­nię­cie tej wady pro­jek­tu, uczci­wy ana­li­tyk się wyco­fa… W prze­ciw­nym wypad­ku ktoś w koń­cu powie gło­śno: dosta­li­śmy dokład­nie to co chcie­li­śmy i zupeł­nie nie to cze­go potrzebujemy.

Czy rejestrować funkcjonalności, których realizacja została wykluczona podczas specyfikowania

Najlepszą zna­ną mi meto­dą zarzą­dza­nia wyma­ga­nia­mi jest zarzą­dza­nie ich sta­tu­sa­mi (w tym sta­tus: poza zakre­sem pro­jek­tu), więc nie usu­wa­my ich ze spe­cy­fi­ka­cji. To poma­ga póź­niej przy­po­mnieć innym, że wyma­ga­nie było i dla­cze­go zosta­ło usu­nię­te z zakre­su. Czasem jest ono prze­su­wa­ne do kolej­nej now­szej wer­sji. Dobrą prak­ty­ką jest zapi­sa­nie dla każ­de­go wyma­ga­nia: wła­ści­cie­la czy­li oso­by zgła­sza­ją­ce­go wyma­ga­nie po stro­nie zama­wia­ją­ce­go, sza­co­wa­ne­go kosz­tu imple­men­ta­cji, bie­żą­ce­go statusu.

Czy zawsze warto analizować organizacje i otoczenie biznesowe projektu

Zawsze :). Bez tego nie wie­my nic o sen­se i celu pro­jek­tu 🙂 … Tu uwa­ga: dobry ana­li­tyk to nie najem­nik, któ­ry jak mu zapła­cą zro­bi każ­da głu­po­tę… patrz wyżej pyta­nie o reali­za­cję pro­jek­tu mają­ce­go źle sfor­mu­ło­wa­ne cele.

Jak rejestrować uprawnienia użytkowników – macierz uprawnień?

Obecnie macierz to chy­ba (poza rzad­ki­mi wyjąt­ka­mi) naj­gor­sza meto­da. Zarówno z powo­du zmien­no­ści upraw­nień w trak­cie życia orga­ni­za­cji jak i nie raz ogrom­nych roz­mia­rów takiej macie­rzy. Uprawnienia doku­men­tu­je­my i zarzą­dza­my nimi w apli­ka­cjach z uży­ciem reguł biz­ne­so­wych. To pozwa­la by apli­ka­cja sama dyna­micz­nie tym upraw­nie­nia­mi zarzą­dza­ła, np. pra­wa dostę­pu do tre­ści doku­men­tu ma tyl­ko oso­ba pro­wa­dzą­ca spra­wę zwią­za­ną z tym doku­men­tem oraz jej bez­po­śred­ni prze­ło­żo­ny”. Zmiany kadro­we, prze­ka­za­nie spra­wy innej oso­bie, nie prze­ło­żą się na jaką­kol­wiek pra­co­chłon­ność zwią­za­ną z pra­wa­mi dostę­pu do doku­men­tu, admi­ni­stra­tor sys­te­mu jest wyłą­czo­ny z inge­ro­wa­nia te w pra­wa co dodat­ko­wo pod­no­si bez­pie­czeń­stwo cało­ści systemu.

Jedną, z chy­ba naj­gor­szych, metod doku­men­to­wa­nia upraw­nień jest dia­gram przy­pad­ków uży­cia, któ­ry dzię­ki temu natych­miast sta­je się nie raz mon­stru­al­nie roz­bu­do­wa­ny (czy­li nieczytelny).

I Ty zadaj pytanie…

Zachęcam do zada­wa­nia kolej­nych pytań i dys­ku­sji pod tym arty­ku­łem, szcze­gól­nie tych któ­rzy nie zna­leź­li tu odpo­wie­dzi na nur­tu­ją­ce ich pyta­nia, a chcą poznać moje zda­nie ;), i pamię­taj: zanim zadasz pyta­nie, upew­nij się, że chcesz poznać odpowiedź ;).

Ten post ma 2 komentarzy

  1. Plebs

    Jakich pytań może spo­dzie­wać się ana­li­tyk na roz­mo­wie rekru­ta­cyj­nej i jak może prze­bie­gać taka rozmowa?

    1. Jarosław Żeliński

      Zła infor­ma­cja: naj­czę­ściej pyta­nia te ukła­da­ją przy­szli sze­fo­wie i współ­pra­cow­ni­cy (szef deve­lo­pe­rów, szef ana­li­ty­ków, star­szy deve­lo­per i ana­li­tyk, itp.) więc poza ogól­ny­mi pyta­nia­mi o nota­cje czy cer­ty­fi­ka­ty, poja­wia­ją się pyta­nia jak byś to zrobiła(a)” a tu nie­ste­ty jedy­ną popraw­ną odpo­wie­dzią jest to jak by to zro­bił oso­bi­ście pyta­ją­cy. Dlatego dobrą stra­te­gią jest docie­ra­nie do byłych pra­cow­ni­ków fir­my rekru­tu­ją­cej… albo odpo­wia­da­nie na pozio­mie stan­dar­dów nota­cji o któ­re pyta­ją ale to nie­ste­ty nie daje 100% gwarancji ;).…

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.