Częsty pro­blem, z jakim się spo­ty­kam, to zja­wi­sko ​„utra­ty pano­wa­nia nad zło­żo­no­ścią” (ana­li­zy, doku­men­ta­cji, itp.). Winnymi są zresz­tą sami zama­wia­ją­cy, nie­po­tra­fią­cy myśleć abs­trak­cyj­nie. Nie cho­dzi o to, że powin­ni umieć, cho­dzi o to, że nie uzna­ją tego, nie potra­fią. Paradoksalnie, pro­gra­mi­ści w więk­szo­ści tak­że nie potra­fią myśleć abstrakcyjnie.

Beneficjenci opro­gra­mo­wa­nia sta­ra­ją się opi­sać swo­je ocze­ki­wa­nia przez pry­zmat swo­jej szcze­gó­ło­wej wie­dzy o pra­cy jaką wyko­nu­ją, pomi­ja­jąc w swych opi­sach nie­ste­ty jej ​„oczy­wi­ste” dla nich ele­men­ty (z regu­ły naj­waż­niej­sze). Programiści zaś patrzą na swo­ją pra­cę dokład­nie tak samo: chcą usły­szeć ​„co mają zapro­gra­mo­wać”. Pierwsi godzi­na­mi opo­wia­da­ją o zna­nych im przy­pad­kach i meto­dach wytwo­rze­nia jed­ne­go doku­men­tu, dru­dzy już w pierw­szej minu­cie spo­tka­nia z klien­ta­mi pyta­ją o ​„typ pola” tej formatki.

W efek­cie zama­wia­ją­cy wyar­ty­ku­łu­je set­ki wyma­gań a deve­lo­per zada pyta­nia o kolej­ne bra­ku­ją­ce set­ki szcze­gó­łów tych setek wyma­gań. Zupełnie nie­po­trzeb­nie w pierw­szych fazach projektu.

Wśród wie­lu takich szcze­gó­łów są róż­ne­go rodza­ju ogra­ni­cze­nia nazy­wa­ne regu­ła­mi biz­ne­so­wy­mi. Poniżej przy­kła­do­we ​„śmie­cio­we” zapi­sy w wymaganiach:

1. Assigning valu­es to variables.

2. Asserting man­da­to­ry GUI fields.

3. Specifying which data can be vie­wed by which users.

4. Expressing which docu­ments are to be routed to which queues.

5. Orchestrating tasks assi­gn­ments in an exe­cu­tion environment.

(źr. A Quick 5‑Item List of What Are Not Business Rules! ? Ron Ross on Business Rules).

Po pierw­sze są to albo ele­men­ty zwią­za­ne z imple­men­ta­cja (czy­li ostat­ni etap pra­cy) albo ele­men­ty sce­na­riu­szy pra­cy z GUI. Ani jed­no ani dru­gie to nie regu­ły biz­ne­so­we, bo te – jak sama nazwa wska­zu­je – ogra­ni­cza­ją (regu­lu­ją) dzia­ła­nia biz­ne­so­we (ludzi) a nie opro­gra­mo­wa­nia. Oprogramowanie to tyl­ko narzę­dzie pra­cy, ma okre­ślo­ne cechy i funk­cjo­nal­no­ści i nie może koli­do­wać z biz­ne­sem (jego regu­ła­mi), to tyl­ko narzę­dzie w rękach ludzi.

Reguły biznesowe

Reguła biz­ne­so­wa nie powin­na zawie­rać w sobie kry­te­riów podej­mo­wa­nia decy­zji. Reguła biz­ne­so­wa nie jest ele­men­tem algo­ryt­mi­za­cji, wska­zu­je kie­dy i co, a nie jak, ma być wyko­na­ne. Należy zawsze pamię­tać, że model orga­ni­za­cji, sys­tem któ­re­go ele­men­ta­mi są tak­że ludzie, nie może od tych ludzi abs­tra­ho­wać. Dlatego dia­gra­my zawie­ra­ją­ce wręcz algo­ryt­micz­ną szcze­gó­ło­wość być może mają sens, tam gdzie szu­ka­my 100%-towej auto­ma­ty­za­cji, albo nie mają żad­ne­go sensu.

Na stro­nie Business Rules Group moż­na prze­czy­tać Manifest Reguł Biznesowych (tak­że w pol­skiej wer­sji ;)). Dlaczego aku­rat to pole­cam? Bo kon­sor­cjum to wpro­wa­dzi­ło do OMG stan­dard Semantics Of Business Vocabulary And Business Rules (SBVR), któ­ry jest zhar­mo­ni­zo­wa­ny z inny­mi nota­cja­mi, w szcze­gól­no­ści z BMM, BPMN i UML. Dzięki temu poję­cie regu­ły biz­ne­so­wej ma tę sama defi­ni­cję na wyso­kim pozio­mie abs­trak­cji ana­li­zy biz­ne­so­wej i na pozio­mie np. ​„busi­ness rules engi­ne” na pozio­mie implementacji.

Korzyści ze sto­so­wa­nia stan­dar­du SBVR to przede wszyst­kim pano­wa­nie nad szcze­gó­ła­mi od same­go począt­ku pro­jek­tu. Od same­go począt­ku ana­li­zy i pro­jek­to­wa­nia logi­ki sys­te­mu nale­ży sku­pić się na tym ​„co i po co” a nie ​„jak”. Zajmowanie się pyta­nia­mi ​„jak” (naj­gor­sze pyta­nie ana­li­zy: jak Państwo to robią) na samym począt­ku, pro­wa­dzi do zgro­ma­dze­nia ogrom­nej ilo­ści nad­mia­ro­wych szcze­gó­łów, któ­re zamu­la­ją pra­ce wszyst­kich człon­ków zespo­łu pro­jek­to­we­go. Szczegóły, te któ­rych zna­jo­mość fak­tycz­nie wno­si war­tość, nale­ży ana­li­zo­wać na koń­cu, wte­dy – mając szkie­let całe­go pro­jek­tu – wie­my któ­re mają jakie­kol­wiek zna­cze­nie. Po dru­gie więk­szość szcze­gó­łów obec­nie wyko­ny­wa­nej pra­cy i tak ule­gnie zmia­nie w związ­ku z wdra­ża­niem nowe­go narzędzia.

Tak więc: od ogó­łu do szcze­gó­łu, sys­te­ma­tycz­nie i z peł­nym zro­zu­mie­niem na każ­dym eta­pie, a nie ​„spi­sze­my wszyst­ko co wie­my a potem zobaczymy”.