Częsty problem, z jakim się spotykam, to zjawisko “utraty panowania nad złożonością” (analizy, dokumentacji, itp.). Winnymi są zresztą sami zamawiający, niepotrafiący myśleć abstrakcyjnie. Nie chodzi o to, że powinni umieć, chodzi o to, że nie uznają tego, nie potrafią. Paradoksalnie, programiści w większości także nie potrafią myśleć abstrakcyjnie.
Beneficjenci oprogramowania starają się opisać swoje oczekiwania przez pryzmat swojej szczegółowej wiedzy o pracy jaką wykonują, pomijając w swych opisach niestety jej “oczywiste” dla nich elementy (z reguły najważniejsze). Programiści zaś patrzą na swoją pracę dokładnie tak samo: chcą usłyszeć “co mają zaprogramować”. Pierwsi godzinami opowiadają o znanych im przypadkach i metodach wytworzenia jednego dokumentu, drudzy już w pierwszej minucie spotkania z klientami pytają o “typ pola” tej formatki.
W efekcie zamawiający wyartykułuje setki wymagań a developer zada pytania o kolejne brakujące setki szczegółów tych setek wymagań. Zupełnie niepotrzebnie w pierwszych fazach projektu.
Wśród wielu takich szczegółów są różnego rodzaju ograniczenia nazywane regułami biznesowymi. Poniżej przykładowe “śmieciowe” zapisy w wymaganiach:
1. Assigning values to variables.
2. Asserting mandatory GUI fields.
3. Specifying which data can be viewed by which users.
4. Expressing which documents are to be routed to which queues.
5. Orchestrating tasks assignments in an execution environment.
(źr. A Quick 5-Item List of What Are Not Business Rules! ? Ron Ross on Business Rules).
Po pierwsze są to albo elementy związane z implementacja (czyli ostatni etap pracy) albo elementy scenariuszy pracy z GUI. Ani jedno ani drugie to nie reguły biznesowe, bo te – jak sama nazwa wskazuje – ograniczają (regulują) działania biznesowe (ludzi) a nie oprogramowania. Oprogramowanie to tylko narzędzie pracy, ma określone cechy i funkcjonalności i nie może kolidować z biznesem (jego regułami), to tylko narzędzie w rękach ludzi.
Reguły biznesowe
Reguła biznesowa nie powinna zawierać w sobie kryteriów podejmowania decyzji. Reguła biznesowa nie jest elementem algorytmizacji, wskazuje kiedy i co, a nie jak, ma być wykonane. Należy zawsze pamiętać, że model organizacji, system którego elementami są także ludzie, nie może od tych ludzi abstrahować. Dlatego diagramy zawierające wręcz algorytmiczną szczegółowość być może mają sens, tam gdzie szukamy 100%-towej automatyzacji, albo nie mają żadnego sensu.
Na stronie Business Rules Group można przeczytać Manifest Reguł Biznesowych (także w polskiej wersji ;)). Dlaczego akurat to polecam? Bo konsorcjum to wprowadziło do OMG standard Semantics Of Business Vocabulary And Business Rules (SBVR), który jest zharmonizowany z innymi notacjami, w szczególności z BMM, BPMN i UML. Dzięki temu pojęcie reguły biznesowej ma tę sama definicję na wysokim poziomie abstrakcji analizy biznesowej i na poziomie np. “business rules engine” na poziomie implementacji.
Korzyści ze stosowania standardu SBVR to przede wszystkim panowanie nad szczegółami od samego początku projektu. Od samego początku analizy i projektowania logiki systemu należy skupić się na tym “co i po co” a nie “jak”. Zajmowanie się pytaniami “jak” (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości nadmiarowych szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy – mając szkielet całego projektu – wiemy które mają jakiekolwiek znaczenie. Po drugie większość szczegółów obecnie wykonywanej pracy i tak ulegnie zmianie w związku z wdrażaniem nowego narzędzia.
Tak więc: od ogółu do szczegółu, systematycznie i z pełnym zrozumieniem na każdym etapie, a nie “spiszemy wszystko co wiemy a potem zobaczymy”.
