Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie

Ronald Ross, współ­au­tor stan­dar­du mode­lo­wa­nia reguł biz­ne­so­wych i biz­ne­so­we­go słow­ni­ka pojęć napi­sał nie­daw­no na swo­im pro­fi­lu LinkedIn:

People love sto­ries. Are user sto­ries help­ful in engi­ne­ering busi­ness solu­tions? Absolutely. Are you done with requ­ire­ments and solu­tion engi­ne­ering when you’ve wor­ked thro­ugh a set of user sto­ries? No. Not even clo­se!” [„Ludzie kocha­ją histo­rie. Czy histo­rie użyt­kow­ni­ków są pomoc­ne w two­rze­niu roz­wią­zań biz­ne­so­wych? Zdecydowanie tak. Czy skoń­czy­łeś z wyma­ga­nia­mi i inży­nie­rią roz­wią­za­nia, gdy już opra­co­wa­łeś zestaw histo­ry­jek użyt­kow­ni­ka? Nie. Nawet nie zbli­ży­łeś się do nich!”.]

(https://​www​.lin​ke​din​.com/​p​o​s​t​s​/​r​o​s​s​r​o​n​a​l​d​_​p​e​o​p​l​e​-​l​o​v​e​-​s​t​o​r​i​e​s​-​a​r​e​-​u​s​e​r​-​s​t​o​r​i​e​s​-​h​e​l​p​f​u​l​-​a​c​t​i​v​i​t​y​-​6​9​3​5​6​2​7​0​0​8​2​6​5​6​3​3​7​9​3​-​B​p​zb/)

Świat od dekad bory­ka się z jako­ścią i sku­tecz­no­ścią spe­cy­fi­ko­wa­nia wyma­gań na opro­gra­mo­wa­nie. OMG​.org opu­bli­ko­wa­ło stan­dard o nazwie MDA (ang. Model Driven Architecture ), któ­ry tak opi­su­je pro­ces two­rze­nia oprogramowania:

CIM -> PIM -> PSM

Są to odpo­wied­nio mode­le: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu dzia­ła­nia (PIM: Platform-Independent Model, jest to model dzie­dzi­ny sys­te­mu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego cza­su sze­rzej opi­sa­łem zależ­no­ści mię­dzy tymi mode­la­mi (czy­taj wię­cej o MDA).

CIM to model dzia­ła­nia orga­ni­za­cji: pro­ce­sy biz­ne­so­we i ich pro­duk­ty. Z uwa­gi na to, że obec­nie już nie rodzą się pro­jek­ty jed­no­ra­zo­wej infor­ma­ty­za­cji cało­ści orga­ni­za­cji, poja­wia się potrze­ba okre­śle­nia zakre­su pro­jek­tu, bo nie jest już nim cała orga­ni­za­cja. Model PIM to udo­ku­men­to­wa­ny mecha­nizm dzia­ła­nia sys­te­mu (opro­gra­mo­wa­nia), logi­ka jego dzia­ła­nia. Nie ma tu mowy o tym w jakiej tech­no­lo­gii powsta­nie, bo z zasa­dy mamy ich wie­le do wybo­ru, a wybór tech­no­lo­gii zale­ży od wie­lu poza-funk­cjo­nal­nych ogra­ni­czeń i wyma­gań. Technologia jest (powin­na być) kon­se­kwen­cją wybo­ru wyko­naw­cy i ten dopie­ro opra­cu­je model PSM, któ­ry w prak­ty­ce jest tak zwa­ną Koncepcją Wdrożenia, moż­na ją tak­że udo­ku­men­to­wać w nota­cji UML, ale na tym eta­pie powszech­na prak­ty­ką jest jedy­nie zapro­jek­to­wa­nie śro­do­wi­ska, zesta­wie­nie go i pra­ca od razu w kodzie.

Kluczowym pro­ble­mem jest przej­ście z CIM na PIM, czy­li jak udo­ku­men­to­wać zakres pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia i prze­kształ­cić go na wyma­ga­nia wobec tego oprogramowania?

CIM -> [zakres pro­jek­tu] -> PIM -> PSM

W meto­dach zwa­nych zwin­ny­mi, mode­le CIM i PIM są pomi­ja­ne. Typowym zaś narzę­dziem zbie­ra­nia wyma­gań” są tak zwa­ne histo­ryj­ki użyt­kow­ni­ka (user sto­ry). Problem w tym, że są one klu­czo­wym ryzy­kiem pro­jek­tów gdyż z regu­ły są nie­spój­ne i nie­kom­plet­ne jako wyma­ga­nia. Specyfikacja wyma­gań powin­na być: spój­na, kom­plet­na i nie­sprzecz­na. Opisanie zakre­su pro­jek­tu histo­ryj­ka­mi użyt­kow­ni­ka, nie mając mode­lu pro­ce­sów biz­ne­so­wych cało­ści (model CIM), jest pozba­wie­niem się narzę­dzia do wery­fi­ka­cji kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji. Wszystkie wady (nie­kom­plet­ność, nie­spój­ność, sprzecz­no­ści) odkry­wa­ne są i usu­wa­ne (uzu­peł­nia­ne) dopie­ro na eta­pie wdra­ża­nia. Jest to pro­ces odkry­wa­nia wyma­gań w toku wdrożenia”. 

Historyjki użyt­kow­ni­ka jako lista potrzeb biz­ne­so­wych? Owszem! Historyjki użyt­kow­ni­ka jako wyma­ga­nia dla deve­lo­pe­ra? NIE! To tyl­ko mate­riał dla pro­jek­tan­ta, ponie­waż bar­dzo czę­sto jed­na i ta sama funk­cja sys­te­mu reali­zu­je wie­le róż­nych histo­rii użyt­kow­ni­ka. Implementacja per user sto­ry” pro­wa­dzi do bar­dzo kosz­tow­nych i nie­efek­tyw­nych roz­wią­zań (Opisywałem to na blo­gu: wpis pro­jekt Biblioteka, dwie histo­ryj­ki użyt­kow­ni­ka: chciał­bym wypo­ży­czyć książ­kę oraz chciał­bym zwró­cić książ­kę są reali­zo­wa­ne jed­ną usłu­gą apli­ka­cji: Karta Wypożyczenia, któ­ra zawie­ra rów­nież pole Data zwro­tu. Nadal spo­ty­kam pro­gra­mi­stów prze­ko­nu­ją­cych, że powin­ny to być dwa osob­ne ekra­ny – dwa przy­pad­ki uży­cia, czy­taj dwa razy wię­cej pra­cy kode­ra i dwa razy więk­szy koszt).

Czy można sformalizować proces zbierania historyjek użytkownika?

User Story to jed­no z naj­bar­dziej pro­ble­ma­tycz­nych narzę­dzi w meto­dach zwin­nych. Najczęściej zale­ca­na struk­tu­ra tych histo­ry­jek”, wraz z przykładami:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Na przy­kład:

Jako Administrator chcę otrzy­my­wać wia­do­mość e‑mail, gdy zosta­nie prze­sła­ny for­mu­larz kon­tak­to­wy, abym mógł na nie­go odpowiedzieć”

albo

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”;

Tak spi­sy­wa­ne wyma­ga­nia sta­no­wią ogrom­ny pro­blem z powo­du nie­rów­nej gra­da­cji, spro­wa­dza­nie ich do pozio­mu tak zwa­nych ato­mo­wych user sto­ry (dru­gi z powyż­szych przy­kła­dów) pro­wa­dzi do bar­dzo dużych liczb tych histo­ry­jek. Próba ich wery­fi­ka­cji (wali­da­cja user sto­ry) sta­je się co naj­mniej trud­nym zada­niem. Jakakolwiek wyce­na opro­gra­mo­wa­nia na bazie takich histo­ry­jek to wró­że­nie z fusów (więc deve­lo­pe­rzy moc­no zawy­ża­ją wyce­ny z uwa­gi na ryzy­ko utra­ty ren­tow­no­ści). Autorzy inne­go opra­co­wa­nia zauważają:

Rzeczywiście, przy oko­ło 800 US [User Story], hie­rar­chia była raczej trud­na do okre­śle­nia, a obraz sys­te­mu pod­czas pla­no­wa­nia był bar­dzo duży. Skalowalność jest więc zde­cy­do­wa­nie pro­ble­mem w pro­jek­tach zwin­nych, w któ­rych US są sła­by­mi arte­fak­ta­mi inży­nie­rii wyma­gań. Zdecydował się on [autor] na wpro­wa­dze­nie wzor­ca US: Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zde­fi­nio­wać hie­rar­chię w posta­ci Celu, Zadania i Użytkownika, ale bez powią­za­nia semantycznego.

Znam pro­jekt, w któ­rym licz­ba przy­pad­ków uży­cia, w pew­nym śred­niej tyl­ko wiel­ko­ści pro­jek­cie, szyb­ko się­gnę­ła czte­ry­stu. Wycena na ich pod­sta­wie poka­za­ła, że pla­no­wa­ny koszt wie­lo­krot­nie prze­kra­cza pla­no­wa­ny budżet. Ten pro­jekt zarzu­co­no, jed­nak wie­le tak wyce­nio­nych pro­jek­tów jest reali­zo­wa­nych, co daje obraz ska­li strat jakie przy­no­szą (zawy­żo­ny koszt to stra­ta). Powyżsi auto­rzy piszą na zakończenie:

Przyszłe pra­ce obej­mu­ją iden­ty­fi­ka­cję luk repre­zen­ta­cyj­nych, któ­re napo­ty­ka­ją prak­ty­cy w mode­lo­wa­niu US, oraz prze­gląd spo­so­bów, w jakie nasze ramy i [meto­da] GORE w ogó­le mogły­by roz­wią­zać te pro­ble­my. Równolegle oce­nia­na będzie rów­nież zdol­ność prak­ty­ków do sto­so­wa­nia pro­po­no­wa­nych ram zamiast zwy­kłych sza­blo­nów. Obecnie trwa­ją pra­ce nad narzę­dziem CASE (Computer Aided Software Engineering), któ­re zosta­nie wyko­rzy­sta­ne do wspar­cia eksperymentów.

Nie zna­la­złem wyni­ków dal­szych prac, więc podzie­lę się wyni­ka­mi swoich.

Gradacja User Story

Podstawowym pro­ble­mem z user sto­ry jest, moim zda­niem, brak stan­dar­du pozwa­la­ją­ce­go na zde­fi­nio­wa­nie ato­mo­wej histo­ryj­ki użyt­kow­ni­ka” czy­li pozio­mu, poni­żej któ­re­go nie dzie­li­my ich na mniej­sze. Jako audy­tor wie­lu doku­men­ta­cji (czę­sto w roli bie­głe­go) zauwa­ży­łem, że histo­ryj­ki użyt­kow­ni­ka są dopro­wa­dza­ne do pozio­mu poje­dyn­czych kro­ków sce­na­riu­szy przy­pad­ków uży­cia. Często też histo­ryj­ki użyt­kow­ni­ka utoż­sa­mia­ne są z przy­pad­ka­mi uży­cia (UML) i tak mode­lo­wa­ne, co jest poważ­nym błę­dem. Np. powyższe: 

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”

Mogło by to być czę­ścią sce­na­riu­sza usłu­gi (przy­pa­dek uży­cia UML), któ­rej celem jest Pokazanie Określonego Miejsca:

  1. AKTOR ini­cju­je usłu­gę Cel podróży
  2. SYSTEM wyświe­tla for­mu­larz Adres
  3. AKTOR wpro­wa­dza dane i naci­ska OK
  4. SYSTEM wyświe­tla mapę z nanie­sio­ną lokalizacją
  5. AKTOR kli­ka okre­ślo­ny punkt na mapie 
  6. SYSTEM powięk­sza obraz poka­zu­jąc deta­le lokalizacji

Powyższa histo­ryj­ka to jedy­nie punkt 5. tego sce­na­riu­sza. Nie trud­no dojść do wnio­sku, że samo klik­nię­cie na mapie to pozba­wio­na kon­tek­stu i celu, wyrwa­na pro­sta czyn­ność, i jej samo­dziel­ne ist­nie­nie w spe­cy­fi­ka­cji jako osob­ny byt, pozba­wio­ne jest sen­su. Z per­spek­ty­wy opro­gra­mo­wa­nia powsta­ją­ce­go w okre­ślo­nym celu, uzna­nie tej histo­ryj­ki za samo­dziel­ne wyma­ga­nie nie ma uza­sad­nie­nia. Uznanie jed­nak, że apli­ka­cja słu­ży mię­dzy inny­mi do zapo­zna­wa­nia się okre­ślo­ny­mi miej­sca­mi w prze­strze­ni, a usłu­gą tej apli­ka­cji jest Pokazanie Określonego Miejsca jak naj­bar­dziej ma sens. Idąc za suge­stią by histo­ryj­ka użyt­kow­ni­ka mia­ła strukturę: 

Jako [Użytkownik], chcę [Zadanie], aby [Cel]”

zmu­sza do zasta­no­wie­nia się czy kli­ka­nie na mapie jest celem, czy może jed­nak tym celem jest Pokazanie Określonego Miejsca, a kli­ka­nie jest ele­men­tem sce­na­riu­sza (pro­ce­du­ry) reali­za­cji tego celu (pamię­ta­my, że przy­pad­ki uży­cia mają sce­na­riu­sze, a te zło­żo­ne są z sekwen­cji kolej­nych kroków!).

Formalizacja User Story

Pojęcia Użytkownik, Zadanie, Cel, jako spój­ny zestaw pojęć odpo­wia­da­ją defi­ni­cji ato­mo­we­go (ele­men­tar­ne­go) pro­ce­su w nota­cji BPMN (doda­tek C, Słownik , ): Aktywność jest sko­ja­rzo­na z jej wyko­naw­cą (pula, tor), two­rzy pro­dukt (data object). Biorąc pod uwa­gę fakt, że pro­dukt ma tu okre­ślo­ne­go adre­sa­ta i musi on sta­no­wić sobą war­tość dla tego adre­sa­ta, mamy punkt wyzna­cza­ją­cy gra­ni­cę dzie­le­nia na czę­ści” tych histo­ry­jek. Nie będzie to moż­li­wość wsta­wie­nia z listy nume­ru NIP nabyw­cy” a utwo­rze­nie fak­tu­ry” (bo war­tość ma dopie­ro popraw­nie wysta­wio­na fak­tu­ra, a nie klik­nię­cie np. w pole NIP by wybrać kontrahenta). 

Jak sfor­ma­li­zo­wać histo­ryj­kę użyt­kow­ni­ka? Podstawą for­ma­li­za­cji (i celem) jest opra­co­wa­nie meto­dy kon­tro­li popraw­no­ści (wali­da­cja). Popatrzmy jesz­cze raz na szablon:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Typ użyt­kow­ni­ka to rola, celem jest pro­dukt pra­cy, a powo­dem? Powodem jest zawsze to, że okre­ślo­na oso­ba ocze­ku­je na efekt tej pra­cy (bez tego pra­ca ta była­by po pro­stu zbęd­na). Można więc wyobra­zić sobie taki zapis:

Jako sprze­daw­ca, chcę wysta­wić fak­tu­rę, klientowi. 

Mamy tu:

  1. rola: sprze­daw­ca
  2. cel: fak­tu­ra
  3. powód: ocze­ku­je tego klient. 

W tym miej­scu widać peł­ną zgod­ność tej defi­ni­cji z kon­struk­cją: aktyw­ność, jej pro­dukt, jego odbior­ca. Innymi sło­wy ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych wyko­na­ny w nota­cji BPMN, to nic inne­go jak połą­czo­ne w logicz­ne cią­gi histo­ryj­ki użytkownika. 

Wyobraźmy sobie taką listę histo­ry­jek użyt­kow­ni­ka, wyko­na­ną wg. powyż­sze­go opisu:

Specyfikacja histo­ry­jek użytkownika

Niektóre narzę­dzia CASE, pozwa­la­ją­ce na ich pro­fi­lo­wa­nie, pozwa­la­ją przed­sta­wić to tak­że na mode­lu wyma­gań (co póź­niej umoż­li­wia śla­do­wa­nie, czy­li kon­tro­lę kom­plet­no­ści, spój­no­ści i niesprzeczności):

Diagram wyma­gań (nota­cja SysML)

Powyższe mogło­by być kon­se­kwen­cją takie­go mode­lu procesów:

Diagram pro­ce­su reali­za­cji zamó­wie­nia (nota­cja BPMN).

Jak widać, model pro­ce­su daje peł­ny kon­tekst dla aktyw­no­ści. Fakt, że pro­ces to logicz­ny prze­pływ pra­cy, powo­du­je, że two­rze­nie mode­li BPMN gwa­ran­tu­je spój­ność, kom­plet­ność i nie­sprzecz­ność listy aktyw­no­ści, ich pro­duk­tów i ról. 

Podsumowanie

Stosowanie typo­wych histo­ry­jek użyt­kow­ni­ka ma dwie klu­czo­we wady: 1. nie ma jed­nej meto­dy zarzą­dza­nia ich gra­da­cją i struk­tu­rą, wie­lu auto­rów przy­wo­łu­je wła­sne, nie­co się róż­nią­ce meto­dy stan­da­ry­za­cji, 2. ich dro­bia­zgo­wość oraz brak meto­dy kon­tro­li spój­no­ści, pro­wa­dzą do szyb­ko rosną­cej ich licz­by, w kon­se­kwen­cji cha­osu, szcze­gól­nie w śred­nich i więk­szych projektach.

Powyżej widać, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie zebra­nych przy­kła­do­wych doku­men­tów (pro­duk­ty pra­cy ludzi: doku­men­ty) i opra­co­wa­nie na ich pod­sta­wie dia­gra­mu przy­pad­ków uży­cia, daje znacz­nie lep­sze wyni­ki niż zbie­ra­ne na warsz­ta­tach histo­ryj­ki użyt­kow­ni­ka. Same wyma­ga­nia wyra­żo­ne jako histo­ryj­ki użyt­kow­ni­ka, nie dają żad­nej szan­sy (brak meto­dy) na kon­tro­lę ich spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści. Wymagania, jako kon­se­kwen­cja popraw­nie wyko­na­nych mode­li pro­ce­sów biz­ne­so­wych, z zasa­dy są spój­ne, kom­plet­ne i niesprzeczne.

W przy­to­czo­nym tu przy­kła­dzie widać, że dwie aktyw­no­ści (reje­stra­cja zamó­wie­nia i kon­tro­la jego sta­tu­su) reali­zo­wa­ne są jako dostęp do zapi­sa­ne­go w sys­te­mie Zamówienia. Daje to jasną prze­słan­kę do tego, że dwie histo­ryj­ki użyt­kow­ni­ka (dwie aktyw­no­ści na mode­lu pro­ce­sów) to dwa róż­ne kon­tek­sty uży­cia tej samej usłu­gi apli­ka­cji: Zamówienia (czy­li dostęp do ich two­rze­nia, aktu­ali­za­cji i pod­glą­du, to typo­wy przy­pa­dek uży­cia typu CRUD). Prawa dostę­pu do tego doku­men­tu mode­lu­je się zaś regu­ła­mi biz­ne­so­wy­mi (nie poka­za­no ich na dia­gra­mach), np. Klient ma wgląd tyl­ko w Zamówienia, któ­re sam złożył”. 

Można uznać, że małe pro­jek­ty, o małym ryzy­ku cha­osu wywo­ła­ne­go bra­kiem mode­li pro­ce­sów, moż­na reali­zo­wac na skró­ty” czy­li histo­ryj­ki użyt­kow­ni­ka i od razu model PSM (imple­men­ta­cja) z pomi­nię­ciem CIM i PIM, jed­nak jest to poważ­ne ryzy­ko już przy śred­nich pro­jek­tach. Dlatego pro­ces MDA:

{CIM -> [zakres pro­jek­tu] -> PIM} -> PSM

wyda­je się być znacz­nie efek­tyw­niej­szy co poka­zu­je prak­ty­ka (w nawia­sach klam­ro­wych {} zakres pra­cy analityka-projektanta).

Zakres pro­jek­tu to albo całe pro­ce­sy biz­ne­so­we albo świa­do­mie wybra­ne ich okre­ślo­ne aktyw­no­ści. Nie jest to tak­że żaden wodo­spad” (water­fall), bo ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych powsta­nie szyb­ciej i taniej niż lista setek histo­ry­jek z pomo­cą wie­lo­dnio­wych warsz­ta­tów anga­żu­ją­cych całe zespo­ły ludzi. Wygenerowane z mode­lu pro­ce­sów biz­ne­so­wych przy­pad­ki uży­cia, są z zasa­dy spój­ne i kom­plet­ne, więc ich ite­ra­cyj­ne (kolej­ne) spe­cy­fi­ko­wa­nie (każ­dy pro­jek­tu­je­my jako samo­dziel­ny mikro­ser­wis) pozwa­la bez ryzy­ka odda­wać je kolej­no do imple­men­ta­cji, i jed­no­cze­śnie doku­men­to­wać (uszcze­gó­ła­wiać) kolejne. 

To spraw­dzo­na w prak­ty­ce meto­da wspie­ra­na przez wie­le narzę­dzi CASE (wszyst­kie dia­gra­my i ich prze­kształ­ce­nia poka­za­ne w tym arty­ku­le powsta­ły z uży­ciem Visual-Paradigm). Diagram przy­pad­ków uży­cia UML jest tu auto­ma­tycz­nie gene­ro­wa­ny z mode­li BPMN, wg poniż­szych zasad:

BPMNtoUseCase (źr. http://​www​.visu​al​-para​digm​.com/​t​u​t​o​r​i​a​l​s​/​f​r​o​m​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​t​o​-​u​s​e​-​c​a​s​e​s​.​jsp)

Po tej ope­ra­cji wystar­czy spraw­dzić kon­tek­sty doku­men­tow i skon­so­li­do­wać w jeden ewen­tu­al­ne nad­mia­ro­we przy­pad­ki uży­cia. I na koniec:

Jeśli nie masz mode­li poję­cio­wych, bra­ku­je Ci waż­ne­go ele­men­tu ukła­dan­ki w pro­jek­to­wa­niu roz­wią­zań, któ­ry jest nie­zwy­kle pomoc­ny w dostrze­ga­niu i prze­ka­zy­wa­niu ogól­ne­go obra­zu tych historyjek.”

Ronald Ross (Business Rules)

Źródła

Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agi­le requ­ire­ments: the Quality User Story fra­me­work and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
Ross, R. G., & Fisher, L. (2020). Business Rules: Management and Execution.
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 07881-6_15
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

Pełna Specyfikacja

Poniżej przy­kła­do­wy doku­ment wyge­ne­ro­wa­ny bez­po­śred­nio z Visual Paradigm, zawie­ra tak­że śladowanie. 

1. Procesy Business Process Diagram

Procesy Business Process Diagram

2. User Story

Historyjki użyt­kow­ni­ka jako wyma­ga­nia biznesowe.

ID

Nazwa

Rola

Produkt

Adresat

Opis

REQ001

Sprzedaż

Sprzedawca

Faktura

Klient

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

REQ002

Wydanie towa­ru

Magazynier

Dokument WZ

Klient

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

REQ003

Rejestracja Zamówień

Pracownik BOK

Zamówienie zaku­pu

Sprzedawca

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

REQ004

Śledzenie Zamówień

Klient

Zamówienie zaku­pu

Klient

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

3. Diagram Przypadków Użycia

Diagram Przypadków Użycia

4. Specyfikacja

 

Nazwa

ID

 

Główni akto­rzy 

Pula zadań

!!

Sprzedaż

UC02

Sprzedawca

Magazyny

UC03

Magazynier

Zamówienia

UC01

Klient, Pracownik BOK

4.1. Sprzedaż

ID: UC02

Usługa pozwa­la wysta­wiać faktury.

4.1.1. Główni aktorzy 

Sprzedawca

4.1.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Sprzedaż będzie doku­men­to­wa­na fak­tu­ra­mi w reje­strze sprzedaży

4.1.3. Wymagania 

4.1.3.1. Sprzedaż

ID: REQ001

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

4.1.4. Relacje

Relacja

Z

Do

unnamed

Sprzedawca

Sprzedaż

4.1.5. Diagramy Podległe 

4.1.5.1. Faktura

Faktura

4.1.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Sprzedaż

4.2. Magazyny

ID: UC03

Usługa doku­men­tu­je wyda­wa­nie towa­ru na pod­sta­wie opła­co­nych faktur.

4.2.1. Główni aktorzy 

Magazynier

4.2.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Operacje maga­zy­no­we doku­men­to­wa­ne są stan­dar­do­wy­mi doku­men­ta­mi księgowymi

4.2.3. Wymagania 

4.2.3.1. Wydanie towaru

ID: REQ002

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

4.2.4. Relacje

Relacja

Z

Do

unnamed

Magazynier

Magazyny

4.2.5. Diagramy Podległe 

4.2.5.1. Dokument WZ

Dokument WZ

4.2.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Wydanie z magazynu

4.3. Zamówienia

ID: UC01

Rejestr zamó­wień pozwa­la reje­stro­wać zamó­wie­nia, śle­dzić ich status.

4.3.1. Główni aktorzy 

Klient,  Pracownik BOK

4.3.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Zamówienia od klien­tów są reje­stro­wa­ne jako Zamówienia zaku­pu w Rejestrze zamówień

4.3.3. Wymagania 

4.3.3.1. Rejestracja Zamówień

ID: REQ003

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

4.3.3.2. Śledzenie Zamówień

ID: REQ004

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

4.3.4. Relacje

Relacja

Z

Do

unnamed

Pracownik BOK

Zamówienia

unnamed

Klient

Zamówienia

4.3.5. Diagramy Podległe 

4.3.5.1. Zamówienia Zakupu

Zamówienia Zakupu

4.3.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Rejestracja zamó­wie­nia

Kto winien porażki projektu? Zamawiający!

Od cza­su do cza­su jestem pro­szo­ny o audy­ty doku­men­ta­cji pro­jek­tów. Ma to miej­sce, albo gdy jestem anga­żo­wa­ny do pro­jek­tu będą­ce­go kolej­nym podej­ściem do wdro­że­nia, albo w spo­rach przed­są­do­wych mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Tu razem kil­ka spo­strze­żeń z tych analiz.

Na mar­gi­ne­sie. W spo­rach przed­są­do­wych i sądo­wych wynik eks­per­ty­zy abso­lut­nie nie może być zamó­wio­ny”, cze­go nie­ste­ty czę­sto ocze­ku­ją, nie raz wręcz żąda­ją pod groź­bą odmo­wy zapła­ty za tę usłu­gę, zama­wia­ją­cy takie eks­per­ty­zy. Bywa to tym bar­dziej żenu­ją­ce, że rosz­cze­nia takie wysu­wa­ją praw­ni­cy zle­ca­ją­cych, czy­li oso­by zna­ją­ce pra­wo i – teo­re­tycz­nie – sto­su­ją­cy zasa­dy ety­ki w swo­jej pracy.

Wiele lat uwa­ża­łem, że win­ni są dostaw­cy, któ­rzy powin­ni wyka­zać się moż­li­wie naj­wyż­szym pro­fe­sjo­na­li­zmem, a tego nie robią. Jakiś czas temu zmie­ni­łem jed­nak zda­nie (nie o pro­fe­sjo­na­li­zmie dostawców). 

Poza reali­zo­wa­ny­mi pro­jek­ta­mi, pro­wa­dzę tak­że szko­le­nia oraz zaję­cia ze stu­den­ta­mi stu­diów nie­sta­cjo­nar­nych i pody­plo­mo­wych: to nie raz doświad­cze­ni prak­ty­cy. Na wykła­dach i ćwi­cze­niach sta­ram się poka­zać jak to robić dobrze”, jed­nym z ele­men­tów tego jak to robić dobrze” jest jak nie robić tego źle” i dys­ku­sje na ten temat. 

Dlaczego zmie­ni­łem zda­nie? I wła­sne doświad­cze­nie i dys­ku­sje ze stu­den­ta­mi prze­ko­na­ły mnie, że gene­ral­nie celem dostaw­cy jest mak­sy­ma­li­za­cja zysków. Co mi sta­le mówią uczą­cy się u mnie prak­ty­cy? Klient nasz pan, mamy robić wszyst­ko co chce klient bo on za to pła­ci, a to, czy to co klient chce ma sens, nie ma zna­cze­nia bo to pro­blem klien­ta (chy­ba każ­dy pro­gra­mi­sta sły­szy to od swo­je­go prze­ło­żo­ne­go raz dziennie). 

Jak klient nie wie cze­go chce, to na jego koszt pró­bu­je­my.

W 2018 arty­kuł o poraż­ce wdro­że­nia w LID koń­czy­łem słowami: 

Dziwi mnie, że wszyst­kie te, doświad­czo­ne poraż­ką, fir­my mają dostęp do tej samej wie­dzy co np. ja, a mimo to zarzą­dy tych firm wie­rzą bez­gra­nicz­nie dostaw­com opro­gra­mo­wa­nia i wie­rzą, że opi­sy­wa­ne od lat przy­czy­ny pora­żek u nich nie wystą­pią? (źr.: Porażka za 2 mld zł. Lidl wyco­fu­je się z wdro­że­nia SAP – Jarosław Żeliński IT-Consulting)

więc win­ny jest zamawiający… 

Ten arty­kuł to krót­ka ana­li­za warun­ków praw­nych i prak­tycz­nych reali­za­cji pro­jek­tów wdrożeniowych. 

Umowa efektu a staranne działanie

Poniższy tekst, to treść, któ­rą w róż­nych for­mach umiesz­czam jako wstęp do ekspertyz. 

W pra­wie cywil­nym wyróż­nio­no dwie pod­sta­wo­we for­my świad­cze­nia zamó­wio­nej usługi:

  1. Umowa o dzieło
  2. Umowa zle­ce­nia

Scharakteryzowane zosta­ły w nastę­pu­ją­cy sposób:

Umowa o dzieło

Art. 627. Przez umo­wę o dzie­ło przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się do wyko­na­nia ozna­czo­ne­go dzie­ła, a zama­wia­ją­cy do zapła­ty wynagrodzenia.

Zlecenie

Art. 734. § 1. Przez umo­wę zle­ce­nia przyj­mu­ją­cy zle­ce­nie zobo­wią­zu­je się do doko­na­nia okre­ślo­nej czyn­no­ści praw­nej dla dają­ce­go zlecenie.

§ 2. W bra­ku odmien­nej umo­wy zle­ce­nie obej­mu­je umo­co­wa­nie do wyko­na­nia czyn­no­ści w imie­niu dają­ce­go zle­ce­nie. Przepis ten nie uchy­bia prze­pi­som o for­mie pełnomocnictwa.

.

W powszech­nej i utrwa­lo­nej opi­nii praw­ni­ków i w orzecz­nic­twie przyj­mu­je się, że:

Umowa zle­ce­nia jest umo­wą sta­ran­ne­go dzia­ła­nia. Zleceniobiorca zobo­wią­zu­je się do sta­ran­ne­go dzia­ła­nia i za to wła­śnie odpo­wia­da, a nie, jak w przy­pad­ku umo­wy o dzie­ło, za rezul­tat pra­cy. W umo­wie nale­ży więc dokład­nie opi­sać czyn­no­ści, jakie ma wyko­ny­wać zle­ce­nio­bior­ca, by póź­niej moż­na było oce­nić, czy zle­ce­nie zosta­ło wyko­na­ne oraz czy zosta­ło wyko­na­ne w spo­sób sta­ran­ny.” . A tak­że, że „…moż­na stwier­dzić, iż w zobo­wią­za­niach sta­ran­ne­go dzia­ła­nia dłuż­nik zobo­wią­zu­je się jedy­nie do doło­że­nia nale­ży­tej sta­ran­no­ści w zmie­rza­niu do usta­lo­ne­go celu, z tym że jego osią­gnię­cie pozo­sta­je poza tre­ścią sto­sun­ku zobo­wią­za­nio­we­go. Natomiast w przy­pad­ku zobo­wią­za­nia rezul­ta­tu na dłuż­ni­ku cią­ży powin­ność osią­gnię­cia ozna­czo­ne­go z góry, spre­cy­zo­wa­ne­go rezul­ta­tu, przy czym ten rezul­tat to okre­ślo­ny fakt, w nastą­pie­niu któ­re­go wie­rzy­ciel jest zain­te­re­so­wa­ny, praw­ny i eko­no­micz­ny sku­tek ozna­czo­ny w tre­ści zobo­wią­za­nia, nie zaś sama czyn­ność, któ­rą dłuż­nik powi­nien pod­jąć.” .

Podsumowując moż­na stwier­dzić, że

  1. Umowa o dzie­ło to umo­wa, w któ­rej dają­cy zamó­wie­nie z góry opi­su­je to co chce otrzy­mać (dzie­ło), a przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się to dostar­czyć (wyko­nać dzieło).
  2. Zlecenie to umo­wa, w któ­rej przyj­mu­ją­cy zle­ce­nie dzia­ła w imie­niu dają­ce­go zle­ce­nie, w kon­se­kwen­cji za efekt zle­co­nej pra­cy odpo­wia­da dają­cy zlecenie.

Znakomita więk­szość umów na dostar­cze­nie opro­gra­mo­wa­nia to, umo­wy sta­ran­ne­go dzia­ła­nia, a tak zwa­ne umo­wy agi­le” mają taki cha­rak­ter z zasa­dy. Tu za uzy­ska­ny efekt zawsze odpo­wia­da Zamawiający.

A jeże­li dostaw­ca jest nie­rze­tel­ny? Jest takie ryzy­ko, jed­nak odpo­wie­dzial­no­ścią zama­wia­ją­ce­go jest tak­że nad­zór na pra­ca­mi wykonawcy!

Proces dostarczenia oprogramowania

Inżynieria opro­gra­mo­wa­nia, na tle innych obsza­rów inży­nie­rii, jest mło­dą dzie­dzi­ną, któ­ra nie wykształ­ci­ła dedy­ko­wa­ne­go pra­wo­daw­stwa, tak jak np. inży­nie­ria budow­la­na, któ­ra ma swo­je” pra­wo budow­la­ne. Z tego też powo­du, jedy­nym źró­dłem opi­sów postę­po­wa­nia są tak zwa­ne dobre prak­ty­ki, stan­dar­dy oraz ana­lo­gie, sto­so­wa­ne tak­że – w obsza­rze inży­nie­rii – do pra­wa budowlanego.

Na diagramie 'Iteracyjno-przyrostowy proces tworzenia oprogramowania' zobrazowano standardowy proces dostarczania rozwiązania jakim jest oprogramowanie (Dennis et al., 2012). Obecnie, z uwagi na tempo zmian w gospodarce, zaleca się by jedna 'pętla iteracyjna rozwoju i utrzymania' nie przekraczała w czasie jednego roku budżetowego, jednak preferowanym okresem jest pół roku z uwagi na to, że sztywne uzależnianie wdrażania oprogramowania wspomagającego zarządzanie, od rygorów rocznych okresów budżetowych było by znaczącym utrudnienie w toku wdrażania zmian w firmach. Projekty małe to projekty będące pojedynczą iteracją. Dobrą praktyką postępowania dla projektów większych jest dzielenie ich na przyrostowe iteracje (w kolejnych cyklach pętli iteracji wdrażane są kolejne funkcjonalności lub moduły) (Larman, 2004). Z reguły robi to wtedy wykonawca przyjmujący zamówienie(Maciaszek, 2001). Co do zasady, za specyfikowanie wymagań i jakość tej specyfikacji, w każdym rodzaju inżynierii, odpowiada zamawiający (Hay, 2003). Zamawiający jest jedynym tu podmiotem, znającym swój cel biznesowy, jako podmiot zamawia u dostawcy produkt a nie efekt biznesowy jaki ma zamiar osiągnąć (Ackoff i in., 2007). W tym miejscu, należy zwrócić uwagę na bardzo ważny fakt, że w przypadku umowy efektu, kolejne iteracje to uszczegółowienie i implementacja funkcjonalności opisanych w umowie, a nie kolejne nowe funkcjonalności.
Iteracyjno-przy­ro­sto­wy pro­ces two­rze­nia oprogramowania

Na dia­gra­mie «Iteracyjno-przy­ro­sto­wy pro­ces two­rze­nia opro­gra­mo­wa­nia» zobra­zo­wa­no stan­dar­do­wy pro­ces dostar­cza­nia roz­wią­za­nia jakim jest opro­gra­mo­wa­nie . Obecnie, z uwa­gi na tem­po zmian w gospo­dar­ce, zale­ca się by jed­na «pętla ite­ra­cyj­na roz­wo­ju i utrzy­ma­nia» nie prze­kra­cza­ła w cza­sie jed­ne­go roku budże­to­we­go, jed­nak pre­fe­ro­wa­nym okre­sem jest pół roku z uwa­gi na to, że sztyw­ne uza­leż­nia­nie wdra­ża­nia opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, od rygo­rów rocz­nych okre­sów budże­to­wych było by zna­czą­cym utrud­nie­nie w toku wdra­ża­nia zmian w fir­mach. Projekty małe to pro­jek­ty będą­ce poje­dyn­czą ite­ra­cją. Dobrą prak­ty­ką postę­po­wa­nia dla pro­jek­tów więk­szych jest dzie­le­nie ich na przy­ro­sto­we ite­ra­cje (w kolej­nych cyklach pętli ite­ra­cji wdra­ża­ne są kolej­ne funk­cjo­nal­no­ści lub modu­ły) . Z regu­ły robi to wte­dy wyko­naw­ca przyj­mu­ją­cy zamó­wie­nie . Co do zasa­dy, za spe­cy­fi­ko­wa­nie wyma­gań i jakość tej spe­cy­fi­ka­cji, w każ­dym rodza­ju inży­nie­rii, odpo­wia­da zama­wia­ją­cy . Zamawiający jest jedy­nym tu pod­mio­tem, zna­ją­cym swój cel biz­ne­so­wy, jako pod­miot zama­wia u dostaw­cy pro­dukt a nie efekt biz­ne­so­wy jaki ma zamiar osią­gnąć, za efekt efekt biz­ne­so­wy z zasa­dy odpo­wia­da biz­nes” 

W tym miej­scu, nale­ży zwró­cić uwa­gę na bar­dzo waż­ny fakt: w przy­pad­ku umo­wy efek­tu, kolej­ne ite­ra­cje to uszcze­gó­ło­wie­nie i imple­men­ta­cja funk­cjo­nal­no­ści opi­sa­nych w umo­wie, a nie kolej­ne nowe funk­cjo­nal­no­ści. Nowe funk­cjo­nal­no­ści powsta­ją w toku roz­wo­ju JUŻ WDROŻONEGO I POPRAWNIE DZIAŁAJĄCEGO oprogramowania. 

Podsumowanie

Projekty wdro­że­nio­we (dostar­cza­nie opro­gra­mo­wa­nia) mogą być reali­zo­wa­ne przez bie­żą­ce zle­ca­nie kon­kret­nych prac usłu­go­daw­cy, lub poprzez opi­sa­nie ocze­ki­wa­ne­go efek­tu jako wyma­ga­ne­go roz­wią­za­nia i zawar­cie Umowy o dzie­ło z przyj­mu­ją­cym zamó­wie­nie, co zobra­zo­wa­no na dia­gra­mie Podsumowanie sta­nu wie­dzy. W obu przy­pad­kach Zamawiający pono­si skut­ki swo­jej decy­zji bo:

  1. jako zle­ce­nio­daw­ca (umo­wy T&M) sam usta­la co i jak ma zostać wykonane,
  2. jako zama­wia­ją­cy okre­ślo­ny efekt (umo­wy o dzie­ło), sam usta­la ocze­ki­wa­ny efekt (pro­dukt) w dniu zawar­cia umo­wy (jako opis przed­mio­tu zamówienia).

Odpowiedzialność przyj­mu­ją­ce­go zamó­wie­nia pole­ga albo na sta­ran­nym dzia­ła­niu, albo na zgod­no­ści tego co dostar­czy z tym co zamó­wio­no, w rozu­mie­niu ocze­ki­wa­ne­go efek­tu. Jeżeli przed­mio­tem zamó­wie­nia jest opro­gra­mo­wa­nie, czy­li narzę­dzie pra­cy zama­wia­ją­ce­go, tyl­ko zama­wia­ją­cy pono­si odpo­wie­dzial­ność za skut­ki wdro­że­nia tego co zamó­wił . Dostawca odpo­wia­da wyłącz­nie za przed­miot umo­wy .

Tak więc zama­wia­ją­cy zawsze dosta­nie to co chce, ale nie koniecz­nie to co jest mu fak­tycz­nie potrzeb­ne. Innymi sło­wy, na ryn­ku rzą­dzo­nym przez docho­dy i zyski, dostaw­ca opro­gra­mo­wa­nia zawsze będzie pra­co­wał pod dyk­tan­do zama­wia­ją­ce­go (lub za jego zgo­dą) i będzie to robił do wyczer­pa­na budże­tu zamawiającego. 

Bardzo cie­ka­we są blo­gi dostaw­ców opro­gra­mo­wa­nia. Wielu ich auto­rów fak­tycz­nie sta­ra się, ale cóż… jeden z cie­kaw­szych wpi­sów na ten temat jest zaty­tu­ło­wa­ny The art (and scien­ce) of col­lec­ting requ­ire­ments: top 3 mista­kes ven­dors make”. Autor z per­spek­ty­wy dostaw­cy, zwra­ca uwa­gę na trzy klu­czo­we przy­czy­ny pora­żek: uzna­nie, że to użyt­kow­nik odpo­wia­da za wyma­ga­nia, mie­sza­nie wyma­gań z pomy­sła­mi na ich reali­za­cję, nie­do­ce­nia­nia macie­rzy śla­do­wa­nia. To, popeł­nia­nie tych błę­dów, nie­ste­ty jest naj­czę­ściej spo­ty­ka­ną cechą ana­liz pro­wa­dza­nych wła­śnie przez dostaw­ców opro­gra­mo­wa­nia, a za wszyst­ko i tak pła­ci nabyw­ca. W bar­dziej nauko­wy spo­sób (szcze­gól­nie kry­ty­ku­jąc wyma­ga­nia pisa­ne języ­kiem natu­ral­nym przez zama­wia­ją­ce­go) opi­sa­li to bar­dzo dokład­nie Šenkýř i Kroha .

Konkluzja jest taka, że za nie­uda­ne wdro­że­nia odpo­wia­da zawsze zamawiający. 

Główną winą zama­wia­ją­ce­go jest to, że zama­wia usłu­gi, któ­rych isto­ty nie rozu­mie więc pozo­sta­wia wyko­naw­cę prak­tycz­nie bez nad­zo­ru, odda­jąc mu nie­mal­że nie­ogra­ni­czo­ne upraw­nie­nia co do zakre­su pro­jek­tu. Pierwszym zaś samo­bój­czym kro­kiem jest zle­ce­nie ana­li­zy wyma­gań i pro­jek­to­wa­nie wybra­ne­mu wcze­śniej dostaw­cy opro­gra­mo­wa­nia. Biorąc pod uwa­gę ryn­ko­wy kon­flikt inte­re­su dostaw­cy i odbior­cy (zama­wia­ją­cy mak­sy­ma­li­zu­je żąda­nia a dostaw­ca mak­sy­ma­li­zu­je zysk), jest to pro­sta dro­ga do poraż­ki, jaką jest tak­że znacz­ne przepłacenie. 

Pytani pra­cow­ni­cy dostaw­ców zawsze odpo­wia­da­ją, że prze­cież celem jest dowie­zie­nie pro­jek­tu”, nie­ste­ty nie jest jed­nak żad­ną sztu­ką w koń­cu dostar­czyć opro­gra­mo­wa­nie”. Sztuką jest to zro­bić zgod­nie z obiet­ni­cą daną pierw­sze­go dnia pro­jek­tu, a z wła­sne­go wie­lo­let­nie­go doświad­cze­nia wiem, że to moż­li­we. Sztuką jest tak­że to, by dal­szy roz­wój i utrzy­ma­nie nie były naj­droż­szym pro­jek­tem świata.

Szanowni pań­stwo: pod­pi­su­jąc z dostaw­cą opro­gra­mo­wa­nia umo­wę czas i mate­riał”, i zle­ca­jąc temu dostaw­cy tak­że ana­li­zę wyma­gań, kopie­cie sobie grób. 

Za co odpo­wia­da dostaw­ca? Za sta­ran­ne dzia­ła­nie, jed­nak sto­so­wa­nie nie­ade­kwat­nych metod nie jest dzia­ła­niem nie­sta­ran­nym, i dla­te­go w sądach z regu­ły prze­gry­wa­ją zama­wia­ją­cy a nie dostaw­cy opro­gra­mo­wa­nia. Wykazanie sta­ran­ne­go dzia­ła­nia przez dostaw­cę opro­gra­mo­wa­nia jest bar­dzo pro­ste: comie­sięcz­ne opła­co­ne fak­tu­ry za pra­cę” dostaw­cy opro­gra­mo­wa­nia są tak napraw­dę uzna­niem jego sta­ran­ne­go dzia­ła­nia przez zama­wia­ją­ce­go. Pozostaje tu jedy­nie kwe­stia ety­ki dostaw­cy, ale to temat na osob­ne opracowanie. 

Tak więc podej­mu­jąc decy­zję o wdro­że­niu pomy­śl­cie Państwo o ryzyku:

ryzyko, popper, decyzje
Karl Popper Ryzyko i decyzje

Kontynuacja wąt­ku: Myślenie życze­nio­we.…

Źródła

Wiegers, K. E., & Beatty, J. (2013). Software requ­ire­ments (Third edi­tion). Microsoft Press, s divi­sion of Microsoft Corporation.
Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Agaronian, A., Freyer, C. W. S., Bierbooms, C. G., Hoeijmakers, T. P. H., Jansen, T., Kafoe, T., Makantasis, I., Mankevic, K., Sinx, R. D., & Smits, I. M. (2019). Software Requirements Document. 133.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems ana­ly­sis and design (5th ed). John Wiley.

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
na gotowca”">

Analiza wymagań metodą na gotowca”

Od cza­su do cza­su spo­ty­kam się z ana­li­za­mi wyma­gań, powsta­ły­mi w dość spek­ta­ku­lar­ny spo­sób. Jest to meto­da zbie­ra­nia wyma­gań na pro­ce­sy refe­ren­cyj­ne” i nadal nie­ste­ty ma wzię­cie. Głównym powo­dem jest to, że nie wyma­ga żad­nych umie­jęt­no­ści, może to zro­bić każ­dy. W ostat­nim roku spo­tka­łem się z wyni­ka­mi tego podej­ścia trzy razy. Wszystkie trzy spa­lo­ne nie­ste­ty… Dlaczego?

Jednym z chy­ba naj­bar­dziej zna­nych zesta­wów pro­ce­sów refe­ren­cyj­nych jest APQC. Tak piszą jego pro­mo­to­rzy o nim:

APQC’s Process Classification Framework?(PCF) is the most used pro­cess fra­me­work in the world. It cre­ates a com­mon lan­gu­age for orga­ni­za­tions to com­mu­ni­ca­te and defi­ne work pro­ces­ses com­pre­hen­si­ve­ly and witho­ut redun­dan­cies. Organizations are using it to sup­port bench­mar­king, mana­ge con­tent, and per­form other impor­tant per­for­man­ce mana­ge­ment acti­vi­ties. (Źródło: About APQC)

Co cie­ka­we nie ma tu mowy o wyma­ga­niach. Jednak tego typu spe­cy­fi­ka­cje są uży­wa­ne w cie­ka­wy spo­sób: nazwy tych pro­ce­sów są kolej­no czy­ta­ne a pra­cow­ni­cy fir­my, któ­ra jest bene­fi­cjen­tem tej ana­li­zy”, sie­dzą na sali i w toku warsz­ta­tów wyma­gań” mówią, któ­ry pro­ces wg. nich powi­nien być wyma­ga­ny w sys­te­mie ERP (co by to nie mia­ło zna­czyć), mimo że i tak nie rozu­mie­ją co wybie­ra­ją, bo nie wie­dzą jak dany pro­ces jest reali­zo­wa­ny (spe­cy­fi­ka­cja APQC ope­ru­je ich listą nie mode­la­mi). W efek­cie otrzy­mu­je­my nie raz kil­ka tysię­cy (!) tak zwa­nych wyma­gań”, z któ­ry­mi nie bar­dzo wia­do­mo co zro­bić. Owszem doku­ment, dzie­ło takie­go ana­li­ty­ka”, wyglą­da impo­nu­ją­co. Rzecz w tym, że nie ma tu mowy i jakim­kol­wiek spraw­dze­niu kom­plet­no­ści, nie­sprzecz­no­ści i spój­no­ści (brak mode­li tych pro­ce­sów nie pozwa­la na takie weryfikacje).

Podobna meto­da, sen­sow­niej­sza ale tyl­ko tro­chę, pole­ga na tym, że listą bazo­wą jest nie APQC a lista pro­ce­sów biz­ne­so­wych (a raczej dostęp­nych czyn­no­ści i nazw doku­men­tów) dostar­czo­na z kon­kret­nym opro­gra­mo­wa­niem ERP. Tu przy­naj­mniej wie­my, że to opro­gra­mo­wa­nie ma te cechy, ale nadal jest to tyl­ko ich lista. Niektóre fir­my, pro­du­cen­ci opro­gra­mo­wa­nia ERP, dostar­cza­ją spe­cjal­ne narzę­dzie, któ­re panu­je nad spój­no­ścią takie­go wybo­ru. Ma np. wbu­do­wa­ne infor­ma­cje o wza­jem­nych powią­za­niach pomię­dzy pro­ce­sa­mi i ich pro­duk­ta­mi (np. powią­za­nie zamó­wień z fak­tu­ra­mi) co pozwa­la unik­nąć sytu­acji rezy­gna­cji z doku­men­tów źró­dło­wych i żąda­niu tych, któ­re na ich pod­sta­wie powsta­ją. Jednak uży­cie tego narzę­dzia wyma­ga posia­da­nia wie­dzy o pro­ce­sach biz­ne­so­wych w danej fir­mie, bo to zesta­wie­nie pro­ce­sów w sys­te­mie ERP nie słu­ży do gło­so­wa­nia chcę/nie chcę”, to zesta­wie­nie słu­ży do wyko­na­nia tak zwa­nej ana­li­zy gap/fit (nie ma/jest), czy­li do wykry­cia pro­ce­sów, któ­rych nie ma na tej liście, a w toku ana­li­zy biz­ne­so­wej klien­ta stwier­dzo­no, że są reali­zo­wa­ne. Oczywiście, dla takie­go porów­na­nia, bar­dzo istot­na jest wie­dza o tym jak dany pro­ces prze­bie­ga w bada­nej fir­mie i w ofe­ro­wa­nym (pla­no­wa­nym do wdro­że­nia) opro­gra­mo­wa­niu ERP. Nie zmie­nia to fak­tu, że dostaw­cy opro­gra­mo­wa­nia ERP, nie wie­dzieć cze­mu, bar­dzo czę­sto nie sto­su­ją się do tych zale­ceń, zale­ceń pro­du­cen­tów tego co ofe­ru­ją i wdra­ża­ją. Warto pamię­tać, że

pod­pi­sa­nie umo­wy z dostaw­cą ERP przed wyko­na­niem tej ana­li­zy czę­sto rodzi poważ­ny pro­blem: odkry­cie” (ana­li­za gap/fit), że to kon­kret­ne opro­gra­mo­wa­nie nam po pro­tu nie pasu­je (wykry­ta w toku gap/fit luka jest duża), i skut­ku­je dość pokaź­ną listą tak zwa­nych kasto­mi­za­cji”. Deklaracja dostaw­cy ERP: nasze opro­gra­mo­wa­nie Wam pasu­je” skła­da­ne przed wyko­na­niem takiej ana­li­zy, to niczym nie popar­te wró­że­nie z fusów. 

Warto też pamię­tać, że

sama nazwa pro­ce­su to za mało, bo np. wysta­wie­nie fak­tu­ry sprze­da­ży na praw­dę może prze­bie­gać na wie­le spo­so­bów i uzna­nie, na pod­sta­wie samej tyl­ko nazwy pro­ce­su, że to wyma­ga­nie speł­nia­my” jest raczej poważ­nym nad­uży­ciem. Przebieg pro­ce­sów biz­ne­so­wych i orga­ni­za­cja pra­cy w każ­dej fir­mie, są efek­tem wie­lu bar­dzo zło­żo­nych zależ­no­ści, kom­pe­ten­cji i umie­jęt­no­ści ludzi oraz narzę­dzi pra­cy jakich używają.

Trzy lata temu pisałem:

Na pew­nym wyso­kim pozio­mie abs­trak­cji moż­na mówić o pro­ce­sach refe­ren­cyj­nych, a raczej dobrych prak­ty­kach np. pro­ces two­rze­nia nowe­go pro­duk­tu powi­nien mieć nastę­pu­ją­ce kro­ki: opis pomy­słu, ana­li­za SWOT pro­duk­tu na ryn­ku, osza­co­wa­nie ceny sprze­da­ży, kosz­tu wytwa­rza­nia i pla­no­wa­ne­go pozio­mu sprze­da­ży, pro­gno­za prze­pły­wów gotów­ko­wych. Ale to ?ogól­ny opis? a nie ?pro­to­ty­py pro­ce­sów i mapy pro­ce­sów?. pro­ces i jego mapa to naj­niż­szy, imple­men­ta­cyj­ny poziom opisu.Tak więc są na pew­no pew­ne pryn­cy­pia, moż­na je zna­leźć np. w książ­ce M.E.Portera ?Strategie kon­ku­ren­cji? (autor kon­cep­cji ryn­ko­we­go łań­cu­cha war­to­ści) czy P.Druckera ?Praktyka zarzą­dza­nia?. Jednak jak nam ktoś ofe­ru­je sys­tem ERP z ?wbu­do­wa­ny­mi pro­ce­sa­mi refe­ren­cyj­ny­mi? to nale­ży rozu­mieć: ?szy­ku­je się total­na rewo­lu­cja?, czy ją prze­ży­je­my? (Źródło: Procesy refe­ren­cyj­ne czy­li kto żyw niech ucie­ka | Jarosław Żeliński IT-Consulting)

Wszystkie te trzy spo­tka­ne przy­pad­ki tak wyko­na­nej ana­li­zy, nie­ste­ty skoń­czy­ły klę­ską: w jed­nym na szczę­ście od razu odrzu­co­no wyni­ki ana­li­zy więc stra­ta była rela­tyw­nie mała. Więc jeże­li ktoś Państwu ofe­ru­je pro­sty spo­sób na wyko­na­nie ana­li­zy wyma­gań” na, bądź co bądź, bar­dzo zło­żo­ny sys­tem infor­ma­tycz­ny, to zasta­nów­cie się nad ryzy­kiem jakie podejmujecie…

Warsztaty analityczne – czyli malowanie trawy

W koń­czą­cym się roku trzy razy mia­łem do czy­nie­nia z nie mały­mi (czy­taj kosz­tow­ny­mi) doku­men­ta­mi zawie­ra­ją­cy­mi mode­le pro­ce­sów biz­ne­so­wych” i spe­cy­fi­ka­cję wyma­gań”. Wszystkie trzy mia­ły pew­ne wspól­ne cechy:

  1. były pro­ble­my z przy­dat­no­ścią tych doku­men­tów, co było powo­dem popro­sze­nia mnie o oce­nę i reko­men­da­cje w kwe­stii ich naprawy,
  2. wszyst­kie były pro­duk­tem zbio­ro­wych warsz­ta­tów pro­ce­so­wych” i warsz­ta­tów wyma­gań” z pra­cow­ni­ka­mi mode­lo­wa­nej firmy,
  3. żaden nie nada­wał się do uży­cia jako mate­riał do stwo­rze­nia opro­gra­mo­wa­nia, mimo, że wszyst­kie one były pro­duk­tem pierw­sze­go eta­pu pro­jek­tu o nazwie ana­li­za przed-wdrożeniowa”,
  4. wszyst­kie cier­pia­ły na pro­blem nad­mia­ru szcze­gó­łów, nie­jed­no­znacz­no­ści i bra­ku spójności.

Jedenaście lat temu (tak jede­na­ście!) napisałem:

Często fir­my ofe­ru­ją usłu­gę i pro­dukt Model (mapę) Procesów Biznesowych. Co dają? Dają nie­udol­nie zro­bio­ny opis pro­ce­dur, nie­słusz­nie nazwa­nych pro­ce­sa­mi. Setki sche­ma­tów obra­zu­ją­cych kto, co i jak robi. A po co to robi? Tego tam z regu­ły nie opi­sa­no! Dziesiątki i set­ki stron dia­gra­mów, któ­re lądu­ją na pół­ce i nie są uży­wa­ne pod­czas wdro­że­nia. Powstaje opra­co­wa­nie, któ­re jest nie­zro­zu­mia­łe przez zarząd fir­my zle­ca­ją­cej tę pra­cę. Zarząd nie przy­zna się, że nie rozu­mie bo podob­no to zna­na fir­ma dorad­cza lub wdro­że­nio­wa opra­co­wa­ła. A moim zda­niem, jeże­li Zarząd nie potra­fi zro­zu­mieć udo­ku­men­to­wa­ne­go obra­zu wła­snej fir­my to doku­ment jest do kitu a nie Zarząd. (Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

Dlaczego tak jest? Dlaczego tak bar­dzo popu­lar­ne są tego typu warsz­ta­ty a nie rze­tel­ne, dają­ce wyso­kiej jako­ści pro­duk­ty, analizy?

Obserwacja gry vs. reguły gry

To co się dzie­je na sto­le bilar­do­wym (meta­fo­ra z książ­ki M.Fowlera) moż­na opi­sać z pomo­cą praw fizy­ki i reguł gry w bilar­da. To co obser­wu­je­my na sza­chow­ni­cy (meta­fo­ra z blo­ga Paula Harmona) to wynik reguł gry, doświad­cze­nia i kla­sycz­nych zagry­wek. W obu przy­pad­kach docho­dzą też do gło­su wie­dza i umie­jęt­no­ści gra­czy. Piłka noż­na to regu­ły gry, pra­wa fizy­ki (tor pił­ki po kop­nię­ciu pił­ki) i umie­jęt­no­ści zawod­ni­ków. Można tu podać wie­le innych przy­kła­dów efek­tów łącz­ne­go ist­nie­nia okre­ślo­nych reguł oraz umie­jęt­no­ści ludzi.

Każda orga­ni­za­cja (fir­ma, urząd, inne) to ludzie z ich wie­dzą i umie­jęt­no­ścia­mi oraz regu­ły gry” czy­li obo­wią­zu­ją­ce Prawo i wewnętrz­ne regu­la­cje. I teraz poja­wia się pyta­nie: czym jest model orga­ni­za­cji? Przede wszyst­kim model to uprosz­cze­nie rze­czy­wi­sto­ści, jed­nak sto­pień tego uprosz­cze­nia nie jest przy­pad­ko­wy. To co uprasz­cza­my (pomi­ja­ne szcze­gó­ły) zale­ży od kon­tek­stu w jakim ten model będzie uży­ty, bo two­rze­nie mode­lu na jeden cel: uży­cie go w kon­kret­nym celu. Tu nie­ste­ty” wkra­cza nauka, mam na myśli podej­ście (meto­da nauko­wa w ana­li­zie).

Spójrzmy na to od koń­ca. Aby powsta­ło jakie­kol­wiek narzę­dzie wspo­ma­ga­ją­ce pra­cę np. ludzi wyko­nu­ją­cych swo­je obo­wiąz­ki w orga­ni­za­cji, narzę­dziem taki jest tak­że opro­gra­mo­wa­nie (czy­li apli­ka­cje), musi powstać opis tego narzę­dzia. Aplikacje to takie narzę­dzia, two­rzy­my je głów­nie z dwóch powo­dów: two­rzy­my elek­tro­nicz­ne wer­sje kar­to­tek (reje­strów) oraz two­rzy­my elek­tro­nicz­ne wer­sje okre­ślo­nych umie­jęt­no­ści (np. wyli­cza­nie pier­wiast­ków w kal­ku­la­to­rze). Tak więc aby zamó­wić u deve­lo­pe­ra Kartotekę musi ją opi­sać i to jest rela­tyw­nie pro­ste: two­rzy­my wzór Kartoteki, np. kar­to­te­ki pra­cow­ni­ka, książ­ki w biblio­te­ce itp. Nieco trud­niej jest opi­sać (udo­ku­men­to­wać) umie­jęt­ność, zresz­tą naj­pierw trze­ba ja jakoś zde­fi­nio­wać. Umiejętności, tu wyma­ga­ne, mogą być róż­ne: od umie­jęt­no­ści wery­fi­ka­cji danych wpro­wa­dza­nych do kar­to­tek aż do umie­jęt­no­ści wytwa­rza­nia nowych infor­ma­cji na bazie tych dostęp­nych w kar­to­te­kach. Np. utwo­rze­nie fak­tu­ry sprze­da­ży wyma­ga sko­rzy­sta­nia z kar­to­te­ki klien­tów, z kar­to­te­ki ofe­ro­wa­nych towa­rów i usług, kar­to­te­ki towa­rów dostęp­nych w maga­zy­nie, trze­ba tak­że posia­dać umie­jęt­ność popraw­ne­go wyli­cze­nia war­to­ści podat­ków na for­mu­la­rzu fak­tu­ry, mogą do tego dojść upu­sty zależ­ne od wie­lu czyn­ni­ków: war­to­ści zaku­pu, aktu­al­nych pro­mo­cji, sta­tus kupu­ją­ce­go i wie­le innych. Inny przy­kład: zare­je­stro­wa­nie nowe­go doku­men­tu w archi­wum wyma­ga sko­rzy­sta­nia z kar­to­te­ki doku­men­tów oraz umie­jęt­no­ści nada­nia doku­men­to­wi spe­cjal­ne­go zna­ku, sygnatury.

workshopI 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­je 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 elektronicznym!).

Dokumenty, któ­re dosta­ję do recen­zji, to czę­sto wła­śnie zapi­sy, wręcz ste­no­gra­my z takich spo­tkań, i nie ma zna­cze­nia czy to zapi­sy pro­zą” czy zapi­sy w posta­ci obraz­ko­wej z uży­ciem nota­cji BPMN czy UML (gdzie nota­cja jest wyko­rzy­sty­wa­na raczej jako biblio­te­ka sym­bo­li a nie narzę­dzie z jego syn­tak­ty­ką i seman­ty­ką). To doku­men­ty, któ­re sta­no­wią rodzaj ste­no­gra­mu z roz­mów, są jak fil­my nakrę­co­ne pod­czas roz­gry­wa­nia par­tii sza­chów lub bilar­da: miłe w oglą­da­niu, dłu­gie, kosz­tow­ne i kom­plet­nie nie­przy­dat­ne do napi­sa­nia kom­pu­te­ro­wej gry.

Do opi­sa­nia każ­dej z tych gier, a tak­że do opi­sa­nia tego jak funk­cjo­nu­je orga­ni­za­cja, wystar­czy doku­ment opi­su­ją­cy zasa­dy gry (regu­ły biz­ne­so­we) oraz mini­mal­ną wie­dzę i umie­jęt­no­ści gra­czy oraz to jakie i w jakiej kolej­no­ści rze­czy maja powstać czy­li model pro­ce­sów biz­ne­so­wych. Model pro­ce­sów jed­nak to nie jest film” opi­su­ją­cy czy­jąś pra­cę a logicz­ny łań­cuch aktyw­no­ści two­rzą­cych, każ­da, przy­dat­ny biz­ne­so­wi produkt.

Jaki opis powsta­nie po prze­pro­wa­dze­niu kil­ku dni warsz­ta­tów z gra­cza­mi, któ­rzy gra­ją od lat, zasa­dy gry zna­ją na pamięć, bywa ze podej­mu­ją pró­by łama­nia zasad dla osią­gnię­cia doraź­nych efek­tów? To będą dłu­gie, nie raz nie­spój­ne wywo­dy. Każdą z wymie­nio­nych gier opi­su­ją jed­nak jed­no­znacz­nie dwa bar­dzo krót­kie doku­men­ty: regu­ły gry oraz mini­mal­ne umie­jęt­no­ści i wie­dza każ­de­go z gra­czy. Z takim doku­men­tem każ­dy pro­jek­tant opro­gra­mo­wa­nia sobie pora­dzi bez problemu.

Niestety wie­le pro­duk­tów eta­pu pro­jek­tu o nazwie ana­li­za przed-wdro­że­nio­wa to tak zwa­ne malo­wa­nie tra­wy: kawał kosz­tow­nej i niko­mu nie przy­dat­nej pra­cy. Jakiś temu pisa­łem z innej okazji:

Niestety, pod­czas tak zwa­nych typo­wych ana­liz, opar­tych na wywia­dach i spo­tka­niach warsz­ta­to­wych, im wię­cej inte­rak­cji tym więk­sze pole do mani­pu­la­cji i per­swa­zji (świa­do­mej lub nie, ale jed­nak). Po dru­gie, nie ma żad­nej gwa­ran­cji, że nicze­go nie pomi­nię­to (w takich roz­mo­wach w zasa­dzie oma­wia­ne są rze­czy cie­ka­we i rzad­kie a pra­wie nigdy oczywiste). […]

Drugim pro­ble­mem i poważ­nym błę­dem jest uzna­nie, że ?sko­ro te ana­li­zy to spo­tka­nia i zapi­sy­wa­nie ich wyni­ków, to może to robić nie­mal­że każ­dy byle był komu­ni­ka­tyw­ny?. Bzdura. Po pierw­sze takie dzia­ła­nie to nie są ana­li­zy a ste­no­gra­my ze spo­tkań, po dru­gie są one zapi­sem subiek­tyw­ne­go oglą­du sytu­acji, jaki mają odpy­ty­wa­ni pra­cow­ni­cy danej fir­my (do tego z ich tyl­ko per­spek­ty­wy). (Nowoczesne tech­no­lo­gie w służ­bie zdro­wia, czy­li tele­me­dy­cy­na w pro­jek­tach IT).

Dlatego rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych partii.

klientsobiezyczyBardzo czę­sto sły­szę od deve­lo­pe­rów, ze więk­szość doku­men­tów jakie dosta­ją jest nie­przy­dat­na. Nie raz zasta­na­wiam się, dla­cze­go mimo to więk­szość usłu­go­daw­ców two­rzy tak nie­przy­dat­ne doku­men­ty? Najprawdopodobniej dla­te­go, że słu­cha­nie i ste­no­gra­fo­wa­nie jest łatwe… Z dru­giej stro­ny, nie raz nie­ste­ty sami zama­wia­ją­cy chcą takich wła­śnie doku­men­tów, Ci jed­nak są uspra­wie­dli­wie­ni, bo to nie oni są ana­li­ty­ka­mi. Ci ostat­ni sami decy­du­ją jaki­mi ana­li­ty­ka­mi są…

Drugim powo­dem jest dość powszech­ny brak umie­jęt­no­ści abs­trak­cyj­ne­go myśle­nia. Problem ten widać czę­sto na eta­pie mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: zamu­la­nie zbęd­ny­mi szcze­gó­ła­mi. Bardzo wie­lu ana­li­ty­ków ma skłon­no­ści do wgłę­bia­nia się w nie­istot­ne szcze­gó­ły, to wła­śnie objaw bra­ku umie­jęt­no­ści two­rze­nia abs­trak­cji. Do tego stop­nia, że powstał pomysł na sfor­ma­li­zo­wa­nie zaj­mo­wa­nie się tymi szcze­gó­ła­mi (Case Management). Ciekawa dys­ku­sja na ten temat poja­wi­ła się na LinkedIn. Ja ze swej stro­ny pole­cam arty­kuł (Case Managemet) oraz wypo­wie­dzi Paula Harmona w dyskusji:

At the pro­cess level, we want the abi­li­ty to descri­be and orga­ni­ze a gene­ric set of acti­vi­ties. We might be con­cer­ned, for exam­ple, with how we orga­ni­ze Hotel Guest Services. To be cle­ar what we mean by orga­ni­zing Hotel Guest Services, we might talk abo­ut a spe­ci­fic instan­ce in which a hotel orga­ni­zed guest servi­ces. One of the things we might deci­de, for exam­ple, was that the hotel wan­ted eve­ry­one to use the guest’s name. Thus, we might think of all of the acti­vi­ties in which employ­ees might inte­ract, and pon­der how we would pro­vi­de each set of employ­ees with each guest’s name. It obvio­usly would­n’t be a mat­ter of sim­ply noti­fy­ing one gro­up – like tho­se who take restau­rant rese­rva­tions of who is in what room – sin­ce, as Roger sug­ge­sts, a hotel guest could pro­ce­ed in any order, going to the pool, or to a con­fe­ren­ce ses­sion, or pro­ce­eding to make a restau­rant rese­rva­tion. In this case we are pro­ba­bly tal­king abo­ut put­ting infor­ma­tion into a data­ba­se from which vario­us employ­ees could easi­ly retrie­ve it. Processes are dyna­mic and com­plex, in part, becau­se the gene­ric pro­cess descrip­tion isn’t as pre­scrip­ti­ve as it would be in a pro­duc­tion line, whe­re the sta­tions are set and the beha­viors expec­ted at each sta­tion are well defi­ned. They are cases” becau­se each instan­ce of the pro­cess uses a dif­fe­rent set of acti­vi­ties in a dif­fe­rent order – as in the Rescue Hostage exam­ple. When we plan for a Rescue Hostage case or pro­ject if you pre­fer, we deve­lop a series of sce­na­rios, and prac­ti­ce a lar­ge set of acti­vi­ties. When the time comes to exe­cu­te the pro­cess, we begin by plan­ning for the spe­ci­fic instan­ce case. The idea that we start the pro­cess with a gene­ric: Plan for the Specific Rescue Effort, acti­vi­ty may be gene­ric, but any deta­iled exam­ple of it will be an instan­ce, sin­ce in the very natu­re of the plan­ning we are tailo­ring to the spe­ci­fic instan­ce. (Case Management Approaches | LinkedIn).

User story czyli nic nie poprawić a może nawet bardziej skomplikować

Prawie trzy lata temu pisa­łem o wadach metod zbie­ra­nia i doku­men­to­wa­nia wyma­gań w posta­ci wywia­dów i pisa­nia tak zwa­nych user sto­ry”. Byli i zapew­ne nadal są obroń­cy tej metody:

User sto­ry to świet­ne narzę­dzie do komu­ni­ka­cji pomię­dzy użyt­kow­ni­kiem a ana­li­ty­kiem (archi­tek­tem) (uwa­gi do tre­ści arty­ku­łu: User sto­ry – kło­po­ty).

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”.

User sto­ry to per­spek­ty­wa użyt­kow­ni­ka i to ska­żo­na jego ogra­ni­czo­ną wie­dzą lub jej bra­kiem oraz ogra­ni­czo­nym doświad­cze­niem lub jego bra­kiem. Duże, zdo­by­te w jed­nym miej­scu, doświad­cze­nie pra­cow­ni­ka, bez głęb­szej i szer­szej ana­li­zy, też nie popra­wia sytu­acji, czę­ściej ją jesz­cze pogar­sza (bo nikt nie podej­mu­je dys­ku­sji z tym dużym doświad­cze­niem”). Popatrzmy na poniż­szy rysunek:

analiza uklad geocentryczny

Jak zapew­ne już Państwo wie­dzą, jest to model” geo­cen­trycz­ny ukła­du sło­necz­ne­go (na rysun­ku jedy­nie orbi­ta jed­nej pla­ne­ty z tak zwa­ny­mi epi­cy­kla­mi), stwo­rzo­ny na bazie obser­wa­cji z Ziemi. Złożoność tego co widzi­my jako miesz­kań­cy tej pla­ne­ty to efekt tego, że obser­wa­tor stoi na zie­mi czy­li krą­żą­ce­go wokół Słońca obiek­tu. Innymi sło­wy, obser­wa­tor jest we wnę­trzu tego co opi­su­je (ana­li­zu­je) i widzi jedy­nie frag­ment tego co sta­ra się opi­sać i zrozumieć.

Poniżej praw­dzi­wy obraz ukła­du słonecznego:

Jak widać, praw­da jest znacz­nie prost­sza, jed­nak by ją odkryć nale­ży zupeł­nie ina­czej podejść do ana­li­zy i opi­su ota­cza­ją­cej nas rze­czy­wi­sto­ści. Należy zre­zy­gno­wać z uży­cia zapi­su subiek­tyw­nych obser­wa­cji jako final­ne­go opi­su zja­wi­ska, zapis taki może być testem teo­rii ale nie nią samą. Kopernikański model to efekt głę­bo­kiej i for­mal­nej (pra­wa fizy­ki) ana­li­zy i badań. Model geo­cen­trycz­ny, zna­ny w śre­dnio­wie­czu, to nic inne­go jak user story”.

Podaję ten przy­kład, mam nadzie­ję, że obra­zo­wy, gdyż moja prak­ty­ka poka­zu­je, że pró­by two­rze­nia opro­gra­mo­wa­nia bazu­ją­ce na rela­cjach (życze­niach, wywia­dach, burze mózgów, itp.) prze­cięt­ne­go obec­ne­go lub przy­szłe­go użyt­kow­ni­ka, to bazu­ją­ce na dobrych chę­ciach i nie­ste­ty na zupeł­nym bra­ku zro­zu­mie­nia kon­tek­stu, pro­jek­ty o zło­żo­no­ści sztucz­nie zwięk­szo­nej nie raz naście razy, niż fak­tycz­na. Użytkownik z drob­nych, sta­ty­stycz­nych odstępstw (tyl­ko takie zwra­ca­ją jego uwa­gę) robi zasa­dy, nie potra­fi wychwy­cić nad­rzęd­nych uogól­nień i praw­dzi­wych reguł.

User-Stories

Oprogramowanie powsta­ją­ce z uży­ciem zwin­nych metod, tych bazu­ją­cych na bie­żą­cej obser­wa­cji i czę­stych popraw­kach, trak­to­wa­niu odosob­nio­nych przy­pad­ków jako wyma­ga­nych sce­na­riu­szy, pro­wa­dzi do bar­dzo zło­żo­nych two­rów, któ­rych zło­żo­ność nie raz prze­ra­sta pro­jekt. Brak logi­ki takie­go opi­su powo­du­je, że powsta­łe sys­te­my wyma­ga­ją ręcz­nej pra­cy przy każ­dej zmia­nie zasad panu­ją­cych w firmie.

Tu nie­ste­ty muszę napi­sać jed­ną waż­ną rzecz: winę za to pono­szą czę­sto spon­so­rzy pro­jek­tów gdyż po pierw­sze dopusz­cza­ją do tego, po dru­gie, nie raz jako człon­ko­wie zarzą­dów i dyrek­to­rzy, nie dopusz­cza­ją do sie­bie myśli o upo­rząd­ko­wa­niu orga­ni­za­cji jako pierw­szym kro­ku projektu.

Typowym, czę­sto spo­ty­ka­nym przy­kła­dem, są popu­lar­ne ostat­nio wdro­że­nia elek­tro­nicz­ne­go obie­gu doku­men­tów, w tym fak­tur kosz­to­wych. W więk­szo­ści chy­ba firm, z powo­dów histo­rycz­nych, nie­mal­że każ­dy kie­row­nik i dyrek­tor ma nie­co inny próg kwo­to­wy samo­dziel­nej akcep­ta­cji ponie­sio­ne­go koszu. Zapisanie w posta­ci wyma­gań a potem imple­men­ta­cja, takie­go sta­nu rze­czy, bywa kosz­ma­rem. Koszmar ten jest bar­dzo kosz­tow­ny z uwa­gi na swo­ją zło­żo­ność i brak ogól­nych zasad. Powoduje to, że zamiast uzy­ska­nia auto­ma­ty­za­cji i znacz­ne­go wzro­stu efek­tyw­no­ści uzy­sku­je się bar­dzo zło­żo­ny i pra­co­chłon­ny (kosz­tow­ny) sys­tem zamra­ża­ją­cy zasta­ny stan rze­czy. Jedyną korzy­ścią cza­sa­mi bywa to, że z rapor­tów wie­my: to na praw­dę dłu­go trwa. A to tyl­ko jeden aspekt opi­su orga­ni­za­cji i wyma­gań na oprogramowanie.

Nie twier­dzę, że każ­dy pro­jekt zwią­za­ny z ana­li­zą wyma­gań, nale­ży pro­wa­dzić kosz­tow­ny­mi, for­mal­ny­mi meto­da­mi, jed­nak zanim z tych metod zre­zy­gnu­je­my oceń­my jakie ryzy­ko podej­mu­je­my, bo czę­sto jest ono bar­dzo duże. Dlatego przed decy­zją o tym czy i jakie opro­gra­mo­wa­nie wdro­żyć, war­to zba­dać fir­mę i upew­nić się czy nie wyma­ga upo­rząd­ko­wa­nia, kom­pu­te­ry­zo­wa­nie bała­ga­nu jest zawsze bar­dzo kosz­tow­ne i ryzykowne.

Warto tu zwró­cić uwa­gę na cie­ka­wy trend. Otóż opi­sa­ne wady user sto­ry (rozu­mia­ne­go jako mniej lub bar­dziej swo­bod­ny opis użyt­kow­ni­ka) dostrze­ga­ją nawet zwo­len­ni­cy zwin­nych metod i zaczy­na­ją je powo­li for­ma­li­zo­wać, np. tak:

Jako [oso­ba odgry­wa­ją­ca daną rolę] chcę [wyko­nać jakąś czyn­ność] aby [osią­gnąć jakiś cel].

W ten sam spo­sób moż­na pisać sce­na­riu­sze przy­pad­ków uży­cia, przy któ­rych nale­ży uwzględ­nić, że sce­na­riusz może obej­mo­wać kil­ka user sto­ry. (Pisanie user sto­ry i sce­na­riu­szy przy­pad­ków uży­cia | Michał Wolski).

Wzorzec ten, co cie­ka­we, jest bli­ski defi­ni­cji pro­ce­su biz­ne­so­we­go: czyn­ność lub łań­cuch czyn­no­ści w celu osią­gnię­cia usta­lo­ne­go rezul­ta­tu. Jest to jed­nak sta­now­czo za mało wie­dzy. Powyższe podej­ście komen­tu­je inny autor:

Przykładowe poje­dyn­cze user sto­ry może brzmieć:

?Jako użyt­kow­nik pre­mium kupu­jąc towa­ry powy­żej 1000zł ccę dostać rabat 10% do koń­ca mie­sią­ca tak aby zachę­cić mnie do kolej­nych zakupów.?

Taki zapis user sto­ry ma wie­le zalet. Pozwala określić:

1.kto będzie uży­wał danej funkcjonalności,

2.czego ten użyt­kow­nik będzie wyma­gał od systemu,

3.kontekst dla wymagania.

Powyższy zapis ma też jed­ną wadę. Jest dość dłu­gi, a lista wyma­gań przed­sta­wio­nych w tej for­mie jest nie­przej­rzy­sta. (Jak ugryźć user sto­ry | agi​le​.pl).

Właśnie pro­blem w tym, że jest nie­przej­rzy­sta oraz nie wie­my jaka logi­ka wią­że war­tość towa­ru z wiel­ko­ścią raba­tu, któ­ry może być jeden, może być ele­men­tem tabe­li raba­to­wej, może być wyli­cza­ny wg. okre­ślo­ne­go wzo­ru, może… Takie zapi­sy, zakła­da­jąc, że dłuż­sze user sto­ry to lep­szy opis, zbli­ża­ją nas do pró­by zapi­sa­nia wyma­gań na grę w sza­chy poprzez nakrę­ce­nie kame­rą kil­ku par­tii. Mając dzie­siąt­ki takich user sto­ry nie mamy żad­ne­go narzę­dzia pozwa­la­ją­ce­go spraw­dzić ich spój­ność, nie­sprzecz­ność i kom­plet­ność. Idąc zaś kro­kiem for­ma­li­za­cji user sto­ry i porząd­ko­wa­nia przy­pad­ków uży­cia, powyż­szy wzo­rzec ja jako użyt­kow­nik zro­bię to a to by osią­gnąć to a to” szyb­ko nas dopro­wa­dzi do defi­ni­cji pro­ce­su biz­ne­so­we­go, któ­ry jest niczym innym jak wła­śnie pra­cą mają­cą okre­ślo­ny cel. Po co więc odkry­wać Amerykę i wal­czyć z nie­jed­no­znacz­no­ścią sko­ro pro­blem ten daw­no roz­wią­za­no: zamiast pisać user sto­ry wystar­czy w toku ana­li­zy opra­co­wać mode­le pro­ce­sów biz­ne­so­wych i w ramach zakre­su pro­jek­tu trans­po­no­wać je na przy­pad­ki uży­cia.

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 rejestrów.