User Story c.d.

Wokół metod zwin­nych nara­sta wie­le mitów, szcze­gól­nie tych o sku­tecz­no­ści w dużych pro­jek­tach. Dzisiaj kolej­ne kil­ka słów o popu­lar­nym narzę­dziu jakim jest tak zwa­ne user sto­ry” czy­li histo­ryj­ka użyt­kow­ni­ka, o ich ewo­lu­cji i o tym, że mogą być przy­dat­ne i kiedy.

Co praw­da, jako źró­dło infor­ma­cji wolę doku­men­ty, ale bywa, że tym źró­dłem infor­ma­cji są jed­nak użyt­kow­ni­cy, bo doty­czy to pro­jek­to­wa­nia np. nowych por­ta­li biz­ne­so­wych. Tu nie­ste­ty nie ma ani ustaw z wzo­ra­mi doku­men­tów ani dotych­cza­so­we­go papie­ro­we­go obie­gu doku­men­tów”. Bardzo podob­nie wyglą­da­ją start-up’y w obsza­rze ope­ra­cyj­nym. Podobnie wyglą­da ana­li­za i pro­jek­to­wa­nie sys­te­mów wspie­ra­ją­cych obsłu­gę klien­tów (CRM i podob­ne). Dlaczego? Bo tej sfe­ry nie regu­lu­ją ani prze­pi­sy ani żad­ne nor­my. Nie licząc ele­men­tów pra­wa cywil­ne­go, są cał­ko­wi­cie uznaniowe.

User Story

Historyjki użyt­kow­ni­ka, mają swój rodo­wód w EX (pro­gra­mo­wa­nie eks­tre­mal­ne) i są z regu­ły defi­nio­wa­ne tak:

In softwa­re deve­lop­ment and pro­duct mana­ge­ment, a user sto­ry is a descrip­tion con­si­sting of one or more sen­ten­ces in the eve­ry­day or busi­ness lan­gu­age of the end user or user of a sys­tem that cap­tu­res what a user does or needs to do as part of his or her job func­tion (źr. ang. wiki).

Scott Ambler pisze:

User sto­ries are one of the pri­ma­ry deve­lop­ment arti­facts for Scrum and Extreme Programming (XP) pro­ject teams. A user sto­ry is a very high-level defi­ni­tion of a requ­ire­ment, con­ta­ining just eno­ugh infor­ma­tion so that the deve­lo­pers can pro­du­ce a reaso­na­ble esti­ma­te of the effort to imple­ment it?1?

Generalnie jest to opis w potocz­nym języ­ku, ten – z uwa­gi na nie­jed­no­znacz­ność – jako wyma­ga­nie, stwa­rza pro­ble­my. Podejmowane są pró­by for­ma­li­zo­wa­nia tych histo­ry­jek. Pisze o tym autor blo­ga QAgile (poda­jąc przy­kła­dy, pole­cam cały artykuł):

W podej­ściu agi­le takim jak Scrum wyma­ga­nia defi­niu­je­my na ogól w posta­ci User Story. Prosta for­ma, któ­ra ma adre­so­wać ocze­ki­wa­nia i potrze­by użyt­kow­ni­ków czę­sto zespo­łom przy­spa­rza dużo pro­ble­mów w imple­men­ta­cji.?2?

Swego cza­su ja tak­że pisa­łem o efek­tach sto­so­wa­nia tej meto­dy z zbyt­nią ufno­ścią w jej skuteczność:

Niedawno po raz kolej­ny widzia­łem nega­tyw­ne skut­ki tego podej­ścia, tym razem był to wdra­ża­ny i zakoń­czo­ny poraż­ką (pro­jekt prze­rwa­no) obieg doku­men­tów, nie tyl­ko kosz­to­wych, więc posta­no­wi­łem do tam­te­go arty­ku­łu dodać coś jesz­cze: wyma­ga­nia zbie­ra­no tu z w posta­ci user story”.[…]

Tak więc opi­so­we user sto­ry może być wyma­ga­niem biz­ne­so­wym, testem ale raczej nie spe­cy­fi­ka­cją tego co ma powstać. Bez ana­li­zy pozwa­la­ją­cej wyspe­cy­fi­ko­wać wyma­ga­nia dzie­dzi­no­we (logi­kę wewnętrz­ną) nie mamy szans na spraw­ne stwo­rze­nie opro­gra­mo­wa­nia wykra­cza­ją­ce­go poza pro­sty zestaw kar­to­tek i reje­strów.?3?

User sto­ry to opis z per­spek­ty­wy użyt­kow­ni­ka. Najlepszą chy­ba meta­fo­rą będzie tu zna­na aneg­do­ta z opi­sy­wa­niem słonia:

User-Stories

Każdy z tych okrzy­ków to odręb­ne user story.

Wszelkie meto­dy zakła­da­ją­ce, że użyt­kow­nik wie cze­go chce i jest naj­lep­szym źró­dłem wyma­gań” bazu­ją na zaufa­niu dla tych opisów.

I tu wpa­da­my w efekt ?krę­ce­nia fil­mu?. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­jej pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elek­tro­nicz­nym!).?4?

Historyjki użyt­kow­ni­ka mają sens, jed­nak nie jako kom­plet­ny opis wyma­gań na apli­ka­cję” (wczo­raj usły­sza­łem, że w pew­nej dużej insty­tu­cji zebra­no już ok. tysią­ca (!) takich histo­ry­jek i pro­ces ten nadal trwa). Mają jed­nak sens jako sam­ple” do ana­li­zy. Przekazywanie takich histo­ry­jek bez­po­śred­nio deve­lo­pe­ro­wi jest ogrom­nym ryzy­kiem. Dlaczego? Historyjka, nawet w sfor­ma­li­zo­wa­nej for­mie, nie­sie tyl­ko subiek­tyw­ne spoj­rze­nie z zewnątrz”, a pro­gra­mi­sta zaczy­na domy­ślać się i gdy­bać, nie­jed­no­krot­nie prze­kra­cza­jąc dozwo­lo­ne granice:

…?jako sprze­daw­ca, dosta­ję od klien­tów zamó­wie­nia, na pod­sta­wie któ­rych muszę wysta­wiać fak­tu­ry VAT?, do tego ana­li­tyk doda, np. po ana­li­zie otrzy­ma­nej par­tii doku­men­tów, struk­tu­rę zamó­wie­nia i fak­tu­ry VAT oraz ?algo­rytm? wyli­cze­nia podat­ków. Jeżeli pro­gra­mi­sta zaczy­na ?lepiej wie­dzieć? od zama­wia­ją­ce­go, for­su­jąc np. prost­szą imple­men­ta­cję, to zna­czy, że prze­kro­czył swo­je kom­pe­ten­cje, sam sobie ? jako deve­lo­pe­ro­wi ? robi krzyw­dę psu­jąc to opro­gra­mo­wa­nie bo klient i tak prę­dzej czy póź­niej na tych uprosz­cze­niach ?pole­gnie?.?3? 

Bywa bar­dzo czę­sto, że pro­gra­mi­sta bez żad­ne­go opo­ru przyj­mu­je histo­ryj­kę: ja jako sprze­daw­ca, chcę umie­ścić na fak­tu­rze towar, któ­re­go nie ma jesz­cze w maga­zy­nie, w celu zali­cze­nia sprze­da­ży w danym dniu” … (Komentarz zbędny…)

Czy to zna­czy, że nale­ży odejść cał­ko­wi­cie od tego narzę­dzia? Moim zda­niem nie. Wystarczy uznać , że user sto­ry” to WYŁĄCZNIE opis z per­spek­ty­wy użyt­kow­ni­ka, swo­iste jed­no spoj­rze­nie z setek możliwych”.

Swego cza­su opi­sa­łem tak­so­no­mię pojęć sto­so­wa­nych w ana­li­zie wymagań:

Taksonomia wymagań na system (źr. opracowanie własne Jarosław Żeliński)
Taksonomia wyma­gań na sys­tem (źr. opra­co­wa­nie wła­sne Jarosław Żeliński)

U szczy­tu tej hie­rar­chii mamy wyma­ga­nia biz­ne­so­we. Są to w zasa­dzie owe histo­ryj­ki użyt­kow­ni­ka. To wyra­żo­ne języ­kiem zama­wia­ją­ce­go, ocze­ki­wa­nia w sto­sun­ku do opro­gra­mo­wa­nia. Rolą ana­li­ty­ka jest takie prze­ana­li­zo­wa­nie i prze­two­rze­nie tych opi­sów, by dopro­wa­dzić do powsta­nia sfor­ma­li­zo­wa­ne­go opi­su (np. w posta­ci mode­li UML: przy­pad­ki uży­cia, model dzie­dzi­ny, ogra­ni­cze­nia, inne) czy­li do posta­ci spe­cy­fi­ka­cji usług apli­ka­cji i logi­ki (mecha­ni­zmu) dzia­ła­nia tej aplikacji.

Kolekcjonowanie wyma­gań biz­ne­so­wych w posta­ci np. user sto­ry, ma sens jako zbie­ra­nie sam­pli”, przy­kła­do­wych sytu­acji. Na ich pod­sta­wie, w toku ana­li­zy, moż­na two­rzyć mode­le i testo­wać te histo­ryj­ki (sta­ją się sce­na­riu­sza­mi testo­wy­mi). Tu pole­cam mię­dzy inny­mi blog i książ­ki Scotta Amblera:

In this epi­so­de, Scott Ambler helps us to under­stand the power of using models and how to use models in an agi­le envi­ron­ment.?5?

Wspominałem nie raz o nim i o jego książ­kach na tym blogu:

Co praw­da książ­ka ma 12 lat i trze­ba brać na to lek­ka popraw­kę, jed­nak jest to war­to­ścio­wa, nafa­sze­ro­wa­na dia­gra­ma­mi UML, książ­ka trak­tu­ją­ca o tym, że zwin­ność nie ozna­cza bała­ga­nu i pospo­li­te­go rusze­nia. Scott Ambler to kolej­ny auto­ry­tet w inży­nie­rii opro­gra­mo­wa­nia. I mimo, że niko­go nie ma sen­su mał­po­wać, na pew­no war­to się uczyć? ?6?

Ostatnio popu­lar­ność zdo­by­wa podej­ście sfor­ma­li­zo­wa­ne do histo­ry­jek użyt­kow­ni­ka, bazu­ją­ce na kon­cep­cji Scott’a Amblera (mode­lo­wa­nie) i Rona Jeffries’a, zwo­len­ni­ka porząd­ko­wa­nia, nie tyl­ko tre­ści wywia­dów ;). Tu posłu­żę się ilu­stra­cja­mi z arty­ku­łu na stro­nie Visual Paradigm.

User sto­ry is one of the most impor­tant tool for agi­le deve­lop­ment. They are often used for iden­ti­fy­ing the featu­res of a sys­tem under deve­lo­ped. User sto­ries are well com­pa­ti­ble with the other agi­le softwa­re deve­lop­ment tech­ni­qu­es and methods, such as scrum and extre­me programming. […]

Concept of 3C’s

The 3C’s refer to the three cri­ti­cal aspects of good user sto­ries. The con­cept was sug­ge­sted by Ron Jeffries, the co-inven­tor of the user sto­ries prac­ti­ce. Nowadays, when we talk abo­ut user sto­ries, we usu­al­ly are refer­ring to the kind of user sto­ries that are com­po­sed of the­se three aspects:
Card – User sto­ries are writ­ten as cards. […]
Conversation – Requirements are found and re-fined thro­ugh a con­ti­nu­ous conver­sa­tions betwe­en custo­mers and deve­lop­ment team thro­ugho­ut the who­le softwa­re pro­ject. […]
Confirmation – or also known as Acceptance cri­te­ria of the user sto­ry. […]?7?

W dużym skró­cie: histo­ryj­ki dzie­li­my na jed­nost­ko­we ele­men­tar­ne (nie­po­dziel­ne) opi­sy w posta­ci kart”, zawie­ra­ją­cych opis tego cze­go zama­wia­ją­cy ocze­ku­je od apli­ka­cji, zapis uwag (kon­wer­sa­cja) doty­czą­cych kolej­nych dys­ku­sji z zama­wia­ją­cym na temat danej histo­ryj­ki to histo­ria usta­leń, opis ocze­ki­wa­ne­go uzy­ska­ne­go efek­tu czyn­no­ści opi­sa­nych w danej histo­ryj­ce potwier­dze­nie uzy­ska­nia ocze­ki­wa­ne­go efek­tu. Idąc zaś za wska­zów­ka­mi Amblera, imple­men­ta­cję poprze­dza­my pra­cą nad kon­cep­cją imple­men­ta­cji posłu­gu­jąc się mode­la­mi na dość wyso­kim pozio­mie abstrakcji.

Karta histo­ryj­ki to pro­sty zapis utrzy­ma­ny w kon­wen­cji ja jako «aktor», chcę «nazwa czyn­no­ści» w celu «ocze­ki­wa­ny efekt». Osobiście w pro­jek­tach dopusz­czam bar­dziej luź­ną” for­mę takiej histo­ryj­ki, jed­nak pil­nu­je co do zasa­dy, by doty­czy­ła wyłącz­nie jed­ne­go uzy­ska­ne­go efek­tu koń­co­we­go”. Każda kar­ta ma uni­kal­ne ozna­cze­nie, jest bowiem uży­wa­na jako jed­no zada­nie, w bac­klo­gu i sprin­tach (kan­ban). W doku­men­ta­cji (wspo­mnia­ne narzę­dzie VP) user sto­ry wyglą­da to tak:

01-user-story-example

Historyjki mają swój cykl życia i dobrą prak­ty­ką jest reje­stro­wa­nie wszel­kich kolej­nych uzgod­nień w toku pracy:

02-conversation

Tak zapi­su­je­my sło­wo­tok” zama­wia­ją­ce­go na temat jego wizji reali­za­cji danej usłu­gi apli­ka­cyj­nej. Analogicznie zapi­su­je­my opis ocze­ki­wa­ne­go efek­tu końcowego:

03-confirmation

Do tego momen­tu mamy kla­sycz­ne” zwin­ne pro­wa­dze­nie pro­jek­tu z jego wada­mi opi­sa­ny­mi powyżej.

Wymagania powinny być spójne, kompletne i niesprzeczne”

Jak to osią­gnąć? Analityk zaczy­na zbie­rać te histo­ryj­ki i zaczy­na skła­dać z nich kom­plet­ny pro­ces biz­ne­so­wy. Stanowi on wery­fi­ka­tor, czy całość (zestaw takich histo­ry­jek) sta­no­wi jakąś spój­ną, kom­plet­ną i nie­sprzecz­ną logi­kę biz­ne­so­wą w ska­li całej fir­my. Zmorą pro­jek­tów są wyma­ga­nia odkry­wa­ne w toku wdro­że­nia, dla­te­go war­to poświę­cić czas na wery­fi­ka­cję pomy­słu na całość sys­te­mu i zwe­ry­fi­ko­wać spój­ność i kom­plet­ność tej cało­ści z pomo­cą utwo­rze­nia mode­lu każ­de­go całe­go procesu:

04-business-process-to-user-story-mapping

Warto mode­lo­wać pro­ces gdyż wte­dy widać, że nie zawsze praw­dą jest, że jed­na (każ­da) histo­ryj­ka jest odręb­nym przy­pad­kiem uży­cia. Przypadki uży­cia wypro­wa­dza się z ele­men­tar­nych aktyw­no­ści jeden do jed­ne­go, co z uza­sad­nie­niem opi­sy­wa­łem w arty­ku­le Transformacja…. Model pro­ce­su biz­ne­so­we­go daje kon­tekst, pozwa­la lepiej zro­zu­mieć sens” cało­ści. Czy powyż­szy model pro­ce­su (nota­cja BPMN) z nanie­sio­ny­mi histo­ryj­ka­mi, nie przy­po­mi­na Wam wyni­ków bada­nia sło­nia? Tu słoń został przez ana­li­ty­ka odkry­ty: to pro­ces biz­ne­so­wy (jego model w nota­cji BPMN). Przypadkami uży­cia będą ele­men­tar­ne aktyw­no­ści w pro­ce­sie. Więcej na temat zwin­ne­go pro­wa­dze­nia pro­jek­tu z uży­ciem user sto­ry moż­na zna­leźć w tuto­ria­lu Agile hand­bo­ok.

Na zakończenie…

(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)

We are cal­led ?ana­ly­sts? for a reason! We don?t mere­ly hear sto­ries and convert them into ?requ­ire­ments?. Our inte­gra­ted value lies in going abo­ve and bey­ond the sto­ry and expan­ding bey­ond engen­de­ring deli­ve­ra­bles. We coale­sce cri­ti­cal thin­king and intel­lec­tu­al curio­si­ty to trans­form sto­ries into abs­tracts and to pro­po­se the needs as well as what the pro­blem real­ly is.?1?

___

  1. 1.
  2. 2.
  3. 3.
    Żeliński J. User sto­ry czy­li nic nie popra­wić a może nawet bar­dziej skom­pli­ko­wać. IT-Consulting. https://it-consulting.pl//2013/09/11/user-story-czyli-nic-nie-poprawic-a-moze-bardziej-skomplikowac/. Accessed May 9, 2019.
  4. 4.
    Żeliński J. Warsztaty ana­li­tycz­ne ? czy­li malo­wa­nie tra­wy. IT-Consulting. https://it-consulting.pl//2014/12/21/warsztaty-analityczne-czyli-malowanie-trawy/. Accessed May 9, 2019.
  5. 5.
  6. 6.
    Żeliński J. Agile Modeling. Effective Practices for Modeling and Documentation. IT-Consulting. https://it-consulting.pl//2015/05/27/agile-modeling-effective-practices-for-modeling-and-documentation/. Accessed May 9, 2019.
  7. 7.

Inne artykuły na podobny temat

Komentarze

  1. Michał Stachura 12 października 2016 at 10:35

    Wszystkie pro­jek­ty jakie poło­ży­łem ter­mi­nem lub prze­kro­cze­niem budże­tu mia­ły jed­ną wspól­ną cechę.
    – Opis wyma­gań bazo­wał na zebra­niu user-sto­ry”

    Przypadków nie­koń­czą­cych się pro­jek­tów IT, któ­rych zwin­na reali­za­cja pole­ga na defi­nio­wa­niu user sto­ries znam co naj­mniej kil­ka, a jak wie­my poraż­ka­mi mało kto się chwali.
    Problemami z takim podej­ściem, oprócz wspo­mnia­nych powy­żej trud­no­ści, są:
    – czas
    – abstrakcja
    – komunikacja

    Czas.
    Jak wie­my pły­nie nie­prze­rwa­nie. Jedyną sta­łą jakiej może­my być pew­ni przy reali­za­cji pro­jek­tów jest to, że wszyst­ko jest zmien­ne. Im dłu­żej pro­jekt trwa tym wię­cej zmian zali­czy na eta­pie reali­za­cji. Odnoszenie się do US pod­czas reali­za­cji pro­jek­tu – zwłasz­cza jeśli tych histo­ry­jek mamy set­ki – to zada­nie dla ludzi, któ­rych nazy­wam KKP (Kamikadze Kierownik Projektu).
    W mailu sprzed 6 mie­się­cy pisa­łem o tym, że ma być moż­li­wość …” – jak widzę tego typu kore­spon­den­cję oko­ło­pro­jek­to­wą – a widu­ję – ogar­nia mnie litość dla tych wszyst­kich ludzi zaan­ga­żo­wa­nych w pro­jekt i ska­za­nych na poraż­kę. Kiedyś ogar­niał mnie śmiech, dziś ogar­nia mnie litość. Podstawą pra­wi­dło­wo zapro­jek­to­wa­ne­go sys­te­mu (skom­pli­ko­wa­ne­go bar­dziej niż pro­sta, sta­tycz­na i bez sys­te­mu CMS, stro­na www) jest odpo­wied­nio opi­sa­na doku­men­ta­cja, któ­ra nawet i niech zawie­ra ten zestaw US jakie zebra­li­śmy w trak­cie roz­mów, ale pod­sta­wą reali­za­cji prac pro­gra­mi­stycz­nych są diagramy.
    Proste pyta­nie: Czy moż­na zapro­jek­to­wać wyda­ją bazę danych bazu­jąc na opi­sach funk­cjo­nal­nych sys­te­mu defi­nio­wa­nych przez end userów?
    Tu jed­nak docho­dzi­my do kolej­ne­go pro­ble­mu jaką jest:

    Abstrakcja.
    Diagramy UML, BPMN czy jakie­kol­wiek inne, bez wzglę­du na to jak try­wial­ne będą się wyda­wać ana­li­ty­ko­wi, bez wzglę­du na to jak dobrze i jed­no­znacz­nie będą opi­sa­ne, dla jed­no­stek biz­ne­so­wych pozo­sta­ją abs­trak­cją. Dobry KP musi zda­wać sobie z tego spra­wę, że ta część doku­men­ta­cji nie jest czy­ta­na przez biz­nes, któ­ry opi­sał swo­je user sto­ries. Tak jak inży­nie­ro­wie mają swo­je ban­ner blind­ness” i nie dostrze­ga­ją reklam ser­wo­wa­nych w inter­ne­cie, tak biz­ne­sow­cy” mają swo­je dia­gram blind­ness”, trak­tu­jąc te śmiesz­ne rysu­necz­ki jako coś co ich nie dotyczy.
    KKP nie zawra­ca sobie tym gło­wy, arbi­trar­nie pod­cho­dząc do tema­tu i przy pro­ble­mach (jakie poja­wią się na 100%) zawsze będzie odno­sił się do dia­gra­mów, czy­li do cze­goś cze­go biz­nes, akcep­tu­jąc doku­men­ta­cję nie widział mimo że czytał.
    Czy to dobre podej­ście? Może posłu­żę się anedgdotą.
    – W pew­nej śred­niej wiel­ko­ści fir­mie na spo­tka­niu gdzie oma­wia­no prze­kro­cze­nia cza­so­we i kosz­to­we w pro­jek­cie, KKP ze swo­im zespo­łem upar­cie wma­wiał zastra­szo­nym ludziom z mar­ke­tin­gu, że sami akcep­to­wa­li takie a nie inne dzia­ła­nie aplikacji.
    – Milczący przez całe spo­tka­nie szef na koniec kolej­nej tyra­dy słow­nej, trium­fu­ją­ce­go KKP wypo­wie­dział tyl­ko jed­no zda­nie: No i chuj z tego.”
    – KKP prze­stał triumfować.

    KP – jeśli chce reali­zo­wać pro­jek­ty – musi o tym pamię­tać i musi pamię­tać o kolej­nej rze­czy jaką wymieniłem:

    Komunikacja.
    To klucz do spraw­ne­go pro­wa­dze­nia pro­jek­tu. Nie żad­ne Scrumy, Prince czy inne PMIe.
    Właściwa komu­ni­ka­cja w połą­cze­niu z dobrą doku­men­ta­cją… tłu­kę to u sie­bie blo­gu jak mogę to już tu nie będę się roz­pi­sy­wał ale może taka pora­da na koniec. Jeśli marzy Ci się karie­ra KP lub Analityka – pierw­szą książ­kę jaką sobie kup i prze­czy­taj to cokol­wiek z zagad­nień Komunikacji interpersonalnej” :).

    • Jaroslaw Zelinski 12 października 2016 at 10:42

      Jak to mówią, to co na praw­dę chcia­łeś wie­dzieć ale wsty­dzi­łeś się o to zapytać, …

      W kwe­stii koniec trium­fów Kierownika Projektu”.… Niestety tak to wyglą­da i wte­dy nie raz mam zapro­sze­nie do pro­jek­tu.… Niestety taki Kierownik pro­jek­tu to stan­dard więk­szo­ści dostaw­ców opro­gra­mo­wa­nia… szcze­gól­nie tych dużych…

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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