Modelowanie struktury organizacyjnej

Swego cza­su w arty­ku­le Business Rule Concepts ? czy­li jak ?wyłu­skać isto­tę rze­czy? opi­sa­łem rolę reguł biz­ne­so­wych w mode­lo­wa­niu orga­ni­za­cji. Dzisiaj pora na rolę struk­tu­ry orga­ni­za­cyj­nej. Także w ostat­nim arty­ku­le poru­szy­łem pro­blem tę kwestię:

Model orga­ni­za­cji to: opis moty­wa­cji jej dzia­ła­nia, opis ludzi, jacy reali­zu­ją wewnętrz­ne zada­nia, opis reguł jakie regu­lu­ją ich zacho­wa­nia­mi. Całość (model) powin­na być na tyle upo­rząd­ko­wa­na, by model był w 100% jed­no­znacz­ny, czy­li klu­czo­we poję­cia w nim uży­te powin­ny być zebra­ne w jeden wewnętrz­ny, spój­ny biz­ne­so­wy słow­nik tej orga­ni­za­cji. To wszyst­ko dopie­ro pozwo­li stwo­rzyć model pro­ce­sów biz­ne­so­wych, czy­li wewnętrz­ne sce­na­riu­sze zacho­wa­nia (Modelowanie biz­ne­so­we).

Więc przy­szła pora na ludzi…

Opis ludzi, jacy realizują wewnętrzne zadania

Jednym z regu­lar­nie zanie­dby­wa­nych, a nie raz cał­ko­wi­cie zanie­cha­nych ele­men­tów ana­liz biz­ne­so­wych, jest struk­tu­ra orga­ni­za­cyj­na. Prowadzi to do wie­lu pro­ble­mów nie tyl­ko z np. sys­te­mem upraw­nień we wdra­ża­nym opro­gra­mo­wa­niu. Zaniechanie to pro­wa­dzi bar­dzo czę­sto do bra­ku moż­li­wo­ści opra­co­wa­nia popraw­nych mode­li pro­ce­sów. Dlaczego?

Przytoczę jesz­cze raz model obra­zu­ją­cy związ­ki pomię­dzy tym co opi­su­je organizację:

Tak więc w skró­cie: pro­ces ma wej­ście i wyj­ście, jego wyko­na­nie jest zależ­ne od pro­ce­dur i reguł biz­ne­so­wych (ogra­ni­cze­nia), za wyko­na­nie (czyn­no­ści) odpo­wia­da Odpowiedzialny, peł­nią­cy w orga­ni­za­cji okre­ślo­ną rolę. I teraz bar­dzo waż­ne: Odpowiedzialny ma swój zakres obo­wiąz­ków, ma wyma­ga­ne na jego sta­no­wi­sku umie­jęt­no­ści i jest umiej­sco­wio­ny gdzieś w struk­tu­rze orga­ni­za­cyj­nej” (komuś pod­le­ga i cza­sem kimś kieruje).

Pamiętając moje poprzed­nie arty­ku­ły na ten temat, nie da się, nie ma sen­su, mode­lo­wa­nie umie­jęt­no­ści i prze­pi­sów pra­wa czy też zarzą­dzeń wewnętrz­nych (nie algo­ryt­mi­zu­je się pra­cy ludzi). Jednak trze­ba to co muszą i potra­fią robić gdzieś ująć” i miej­scem tym jest struk­tu­ra organizacyjna.

Zasoby to nie tyl­ko sys­te­my IT czy maszy­ny (to cze­go uży­wa­ją ludzie do reali­za­cji swo­ich zadań), to tak­że ludzie i Ci są waż­niej­si, bo to oni odpo­wia­da­ją za efek­ty swo­jej pra­cy (u kogo z Państwa na dywa­nik” wzy­wa­ny jest kom­pu­ter a nie pracownik?).

Idąc dalej: zarzą­dze­nia i pra­wo to jest.… no co? To jest coś co musi znać pra­cow­nik (wyko­naw­ca), musi postę­po­wać zgod­nie z usta­lo­ny­mi zasa­da­mi, a one są wie­dzą jaką musi posia­dać ta oso­ba (nie przy­pad­kiem wpi­su­je­my w ogło­sze­niu rekru­ta­cyj­nym wyma­ga­na znajomość…”).

Skoro więc wynik pra­cy (pro­dukt pro­ce­su) zale­ży od wie­dzy i umie­jęt­no­ści jej wyko­naw­cy, to zna­czy, że model pro­ce­su biz­ne­so­we­go powi­nien nam powiedzieć:

  1. co jest na wej­ściu procesu,
  2. co jest jego produktem,
  3. kto jest wyko­naw­cą czynności/procesu,
  4. co musi umieć/wiedzieć wyko­naw­ca by osią­gnąć zamie­rzo­ny efekt (pro­dukt procesu).

Jakaś czyn­ność w pro­ce­sie, może np. wyma­gać zna­jo­mo­ści pew­nej usta­wy (wyma­ga­na wie­dza oso­by zna­jo­mość pra­wa podat­ko­we­go”), w fir­mie obo­wią­zu­je regu­ła biz­ne­so­wa: doku­ment musi być kon­sul­to­wa­ny z prze­ło­żo­nym”, a ze struk­tu­ry orga­ni­za­cyj­nej ów pra­cow­nik (i czy­ta­ją­cy model pro­ce­su) zawsze dowie się kim jest ten przełożony.

Jaki z tego poży­tek? Reguły i struk­tu­ra orga­ni­za­cyj­na to ele­men­ty, któ­re ule­ga­ją rela­tyw­nie czę­stym zmia­nom. Jeżeli zamo­de­lu­je­my” je w pro­ce­sie jako pro­ce­sy”, to model taki będzie po pierw­sze bar­dzo zło­żo­ny (czy­taj kosz­tow­ny, trud­ny do stu­dio­wa­nia czy­li naj­czę­ściej nie­wy­ko­rzy­sty­wa­ny). Bardzo zło­żo­ny model jest bar­dzo trud­ny i kosz­tow­ny w kon­ser­wa­cji”, dla­te­go jak tyl­ko taki powsta­nie, to pierw­sze zmia­ny np. w pra­wie uczy­nią go nie­ak­tu­al­nym czy­li nie przy­dat­nym. Skoro zaś jego aktu­ali­za­cja jest kosz­tow­na, to jest naj­czę­ściej zarzu­ca­na i cała pra­ca poszła na marne.

Dlatego na pyta­nie ile kosz­tu­je utrzy­ma­nie i aktu­ali­za­cja takich dia­gra­mów” zawsze odpo­wia­dam: im gor­szy model tym kosz­tow­niej­szy w utrzymaniu.

Jak można modelować strukturę organizacyjną

Z lite­ra­tu­rą na ten temat bar­dzo cięż­ko. Proszę zwró­cić uwa­gę na fakt, że nie­mal­że żad­na książ­ka czy pre­zen­ta­cja, w któ­rej uży­wa się poję­cia struk­tu­ra orga­ni­za­cyj­na”, nie przy­ta­cza żad­nej jej defi­ni­cji. Pod mode­la­mi pro­ce­sów znaj­dzie­my opis nota­cja BPMN”, pod mode­la­mi struk­tu­ry opro­gra­mo­wa­nia znaj­dzie­my np. nota­cja UML”, a co znaj­du­je­my pod dia­gra­ma­mi struk­tur orga­ni­za­cyj­nych? Najczęściej nic! Co mamy w pre­zen­ta­cjach i książ­kach o zarzą­dza­niu? Ano np. to:

Próba poszu­ka­nia defi­ni­cji tak zwa­ne­go orga­ni­gra­mu w sie­ci koń­czy się na WIKI:

An orga­ni­za­tio­nal chart (often cal­led orga­ni­za­tion chart, org chart, organigram(me), or organogram(me)) is a dia­gram that shows the struc­tu­re of an orga­ni­za­tion and the rela­tion­ships and rela­ti­ve ranks of its parts and positions/jobs. (Organizational chart – Wikipedia, the free encyc­lo­pe­dia).

W dużym uprosz­cze­niu: orga­ni­gram to dia­gram obra­zu­ją­cy struk­tu­rę orga­ni­za­cji, wewnętrz­ne sta­no­wi­ska i ich zależ­no­ści. Czyli nie za wie­le. Szukamy więc czym jest owa struk­tu­ra orga­ni­za­cji” (struc­tu­re of an orga­ni­za­tion). Zaglądamy do WIKI (bo zno­wu wyszła jako pierw­sza w wyszukiwarce ;)):

An orga­ni­za­tio­nal struc­tu­re con­si­sts of acti­vi­ties such as task allo­ca­tion, coor­di­na­tion and super­vi­sion, which are direc­ted towards the achie­ve­ment of orga­ni­za­tio­nal aims.[1] It can also be con­si­de­red as the vie­wing glass or per­spec­ti­ve thro­ugh which indi­vi­du­als see the­ir orga­ni­za­tion and its envi­ron­ment. (Organizational struc­tu­re – Wikipedia, the free encyc­lo­pe­dia).

Niewiele lepiej, zno­wu mało kon­kre­tów ale już coś jest: con­si­sts of acti­vi­ties such as task allo­ca­tion” (opi­su­je gdzie są wyko­ny­wa­ne jakie zada­nia). Drugie zda­nie jest nie mniej waż­ne: jest to per­spek­ty­wa z jakiej postrze­ga­ją orga­ni­za­cję jej pracownicy.

Pochylmy się nad pro­ble­mem. Typowy tak zwa­ny przy­zwo­ity orga­ni­gram” wyglą­da naj­czę­ściej tak:

Jest jakaś hie­rar­chia (naj­czę­ściej i dzia­łów i ludzi). Wadą wie­lu takich dia­gra­mów jest to, że pra­wie nigdy nie mają jakich­kol­wiek zasad. Co mamy w więk­szo­ści firm?

Np. dia­gram ze stro­ny Promis ), publicz­nie dostęp­ny więc popatrzmy:

Zarząd nijak się ma do resz­ty, Sklepem w zasa­dzie chy­ba nikt nie kie­ru­je, są jakieś nazwi­ska a przy nich raz Leader, raz Kierownik, raz Manadżer, spe­cja­li­sta itp. Wygląda to tak, jak by każ­dy pra­cow­nik, odizo­lo­wa­ny od pozo­sta­łych napi­sał coś o sobie po swo­je­mu i wrzu­cił do wor­ka, zaś jesz­cze inna oso­ba poukła­da­ła to tak­że po swo­je­mu na bazie wie­dzy z jakie­go poko­ju pocho­dzi dana karteczka.

Inny dia­gram (tak­że ze stro­ny fir­my, któ­ra go pre­zen­tu­je). Tu dla odmia­ny wyczy­nem jest zro­zu­mie­nie pod­le­gło­ści zakła­dów pro­duk­cyj­nych. Wygląda to na tak zwa­ny zgni­ły kom­pro­mis” kie­row­ni­ków tych dzia­łów. Próba doj­ścia kto kim kie­ru­je sta­je się nie lada wyczynem:

(źr. http://​public​-rela​tions​.epra​ce​.edu​.pl/​5​1​3​,​S​t​r​u​k​t​u​r​a​_​o​r​g​a​n​i​z​a​c​y​j​n​a​.​h​tml)

Takie dia­gra­my moż­na przy­ta­czać bez końca.

Jak (można) modelować strukturę organizacji

Zanim poka­żę, przy­kła­do­we spo­so­by mode­lo­wa­nia struk­tu­ry orga­ni­za­cyj­nej zde­fi­niuj­my poję­cia jakie będą wyko­rzy­sta­ne bo one są tu podstawą.

Struktura orga­ni­za­cji to hie­rar­chicz­na struk­tu­ra obra­zu­ją­ca obsza­ry poszcze­gól­nych komó­rek orga­ni­za­cyj­nych, pod­le­głość osób oraz ich przy­na­leż­ność do komó­rek orga­ni­za­cyj­nych. Cechą popraw­ne­go mode­lu struk­tu­ry orga­ni­za­cji jest jego drze­wia­sta[1] struk­tu­ra oraz ist­nie­nie ści­słej defi­ni­cji każ­de­go typu uży­te­go blocz­ka” (czy­li mamy jed­no­znacz­ny opis tego co każ­dy z nich ozna­cza). Przykładowe defi­ni­cje (opra­co­wa­nie własne):

  1. Podmiot – każ­da orga­ni­za­cja sku­pia­ją­ca ludzi i zaso­by nie­za­leż­nie od jej for­my prawnej.
  2. Rola/Stanowisko pra­cy to pod­sta­wo­wy, poje­dyn­czy i nie­po­dziel­ny ele­ment struk­tu­ry orga­ni­za­cyj­nej orga­ni­za­cji, posia­da zakres wyma­ga­nych obo­wiąz­ków, upraw­nień i wyma­ga­ne umie­jęt­no­ści, w celu reali­zo­wa­nia zadań wyzna­czo­nych mu przez orga­ni­za­cję. Jest dość powszech­ną prak­ty­ką łącze­nie sta­no­wisk pra­cy w komór­ki orga­ni­za­cyj­ne, któ­re są kie­ro­wa­ne przez jed­ną oso­bę zarzą­dza­ją­cą nią. Każde sta­no­wi­sko może wystą­pić tyl­ko raz i tyl­ko w jed­nej komór­ce orga­ni­za­cyj­nej ale może być zaj­mo­wa­ne przez wie­le osób za wyjąt­kiem oso­by kie­ru­ją­cej komórką).
  3. Osoba Do każ­de­go sta­no­wi­ska pra­cy przy­dzie­lo­ny jest jeden lub wie­lu pracowników.
  4. Podmiot gru­pu­je komór­ki orga­ni­za­cyj­ne, role i peł­nią­ce je oso­by. Komórka orga­ni­za­cyj­na gru­pu­je pod­le­głe komór­ki orga­ni­za­cyj­ne, role (sta­no­wi­ska), te są pia­sto­wa­ne przez kon­kret­ne osoby.

[[1] Drzewo ? ozna­cza w teo­rii gra­fów graf, któ­ry jest acy­klicz­ny i spój­ny. Mówiąc języ­kiem obra­zo­wym, z każ­de­go wierz­choł­ka drze­wa moż­na dotrzeć do każ­de­go inne­go wierz­choł­ka (spój­ność) i tyl­ko jed­nym spo­so­bem (acy­klicz­ność, czy­li brak moż­li­wo­ści cho­dze­nia w kół­ko”)].

Te defi­ni­cje mają (taki jest tak­że ich cel) waż­ną cechę: poję­cia (ich defi­ni­cje) wza­jem­nie sę wyklu­cza­ją ([[zasa­da wyłą­czo­ne­go środ­ka]]), gwa­ran­tu­je nam to w jed­no­znacz­ną inter­pre­ta­cję dia­gra­mu. Kolejną waż­ną rze­czą jest uzna­nie zasa­dy, że Każde sta­no­wi­sko może wystą­pić tyl­ko raz i tyl­ko w jed­nej komór­ce orga­ni­za­cyj­nej”. Może się to wyda­wać kon­tro­wer­syj­ne ale to kon­se­kwen­cja wyma­ga­nej (w dobrze zarzą­dza­nej orga­ni­za­cji) jed­no­znacz­nej odpo­wie­dzial­ność (przy­po­mi­nam, że nazwa iden­ty­fi­ku­je sta­no­wi­sko wiec Kierownik Produkcji i Kierownik Sprzedaży to dwóch róż­nych kie­row­ni­ków podob­nie jak Asystent Działu Sprzedaży i Asystent Działu Produkcji).

Po co to wszyst­ko? Po pierw­sze, jeże­li jakiś obra­zek ma być mode­lem to powi­nien symu­lo­wać (móc zastą­pić) w okre­ślo­nym kon­tek­ście to co mode­lu­je. Modelowana jest struk­tu­ra komó­rek orga­ni­za­cyj­nych jako ele­men­tów gru­pu­ją­cych, w pew­nym sen­sie są one [[prze­strze­nia­mi nazw]] np. DziałFinasowy/Dyrektor, tak więc wol­no nawet użyć poję­cia Dyrektor wie­lo­krot­nie w mode­lu bo i tak każ­dy Dyrektor” jest umiesz­czo­ny w innym dzia­le i zacho­wu­je­my uni­kal­ność nazw.

Model struktury organizacyjnej w notacji UML

Dosyć czę­sto spo­ty­kam się z mode­lo­wa­niem struk­tur orga­ni­za­cyj­nych czy nawet ról w pro­ce­sach, z pomo­cą dia­gra­mów przy­pad­ków uży­cia i hie­rar­chii akto­rów z uży­ciem dzie­dzi­cze­nia. Jest to moim zda­niem kom­plet­ne nie­po­ro­zu­mie­nie i fał­szy­we wyobra­że­nie o rolach pracowników.

Zawiłe dia­gra­my struk­tur orga­ni­za­cyj­nych w posta­ci akto­rów dzie­dzi­czą­cych po sobie (nie przy­to­czę tu żad­ne­go, każ­dy taki jest w zasa­dzie zły), na któ­rych prze­ło­żo­ny dzie­dzi­czy po pod­wład­nym (lub podob­ne kon­struk­cje), są nie­mal­że zawsze grun­tu fał­szy­we. Dodam, że trak­to­wa­nie dia­gra­mu przy­pad­ków uży­cia wła­śnie jako mode­lu upraw­nień w sys­te­mie jest nie mniej fałszywe.

Studiowanie zakre­sów obo­wiąz­ków pra­cow­ni­ków firm jaw­nie poka­zu­je, że to nie praw­da. Wielu mene­dże­rów dzia­łów nie ma kom­pe­ten­cji swo­ich pod­wład­nych, nie raz szef dzia­łu praw­ne­go nie ma, i nie musi mieć, upraw­nień rad­cow­skich czy adwo­kac­kich, w wie­lu więk­szych sekre­ta­ria­tach, upo­waż­nie­nia do pew­nych pod­pi­sów są przy­dzie­la­ne indy­wi­du­al­nie i szef (sze­fo­wa) tego dzia­łu nie ma tych wszyst­kich upo­waż­nień. Szef kan­ce­la­rii taj­nej może mieć upraw­nie­nia do infor­ma­cji taj­nej nada­ne przez ABW, któ­rych to upraw­nień nie ma nie raz, jego prze­ło­żo­ny. Przykładów na fał­szy­wość dzie­dzi­cze­nia upraw­nień w struk­tu­rze orga­ni­za­cyj­nej moż­na podać tak ogrom­ną ilość, że dość czę­ste sto­so­wa­nie tej kon­struk­cji wyda­je mi się niezrozumiałe.

W efek­cie pro­jek­tu­jąc opro­gra­mo­wa­nie sto­su­jąc meto­dę dzie­dzi­cze­nia dla akto­rów sys­te­mu powie­la­my te nie­praw­dę w sys­te­mie co rodzi nie raz ogrom­ne kło­po­ty. Nie przy­pad­kiem w prak­ty­ce sto­su­je się meto­dy macie­rzo­we zarzą­dza­nia pra­wa­mi dostę­pu (nie­wy­dol­ne i nie­sku­tecz­ne) lub kon­tek­sto­we (dużo lepsze).

Jeżeli już uży­wać UML do mode­lo­wa­nia struk­tu­ry orga­ni­za­cyj­nej, to raczej pakie­tów i związ­ków uży­cia, repre­zen­tu­ją­cych rela­cję” usługobiorca-usługodawca.

Jest to jed­na z moż­li­wych kon­wen­cji, jed­nak mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML, jak widać, wyma­ga uży­cia pro­fi­lu dla akto­rów (ste­reo­ty­py). Osobiście uwa­żam, że mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML nie jest dobrym pomy­słem i odra­dzam to zawsze. Są do tego prost­sze” narzę­dzia, nie przy­pad­kiem te lep­sze narzę­dzia CASE mają do tego dedy­ko­wa­ny dia­gram. Niestety nie ma tu dedy­ko­wa­nej nota­cji, dla­te­go bar­dzo waż­ne jest by słow­nik pojęć w mode­lu zawie­rał takie poję­cia jak pra­cow­nik, komór­ka orga­ni­za­cyj­ne itp. Dobrym pomy­słem jest zde­fi­nio­wa­nie wła­snej kon­wen­cji (dia­gram, sym­bo­le, defi­ni­cje pojęć) np. jak ta na począt­ku artykułu.

Inżynieria wymagań ? model tego co chcemy

Niedawno mój ser­decz­ny kole­ga napisał:

Samo zebra­nie wyma­gań to waż­ny etap. Schody zaczy­na­ją się jed­nak dalej. Trzeba zwe­ry­fi­ko­wać pozy­ska­ne wyma­ga­nia, uszcze­gó­ło­wić, nadać prio­ry­te­ty. Gdzie te scho­dy? […] Nie mamy w Polsce stan­dar­du doku­men­to­wa­nia pro­jek­tów. Czegoś na co moż­na się powo­łać. (Inżynieria wyma­gań ? cer­ty­fi­kat | Michał Wolski).

jak to mówią świę­te sło­wa”. Jednak mamy stan­dard doku­men­to­wa­nia wyma­gań, któ­ry moż­na wyko­rzy­stać. Jaki? Moje począt­ko­we opo­ry do sto­so­wa­nia kolej­nej nota­cji” były jed­nak chy­ba prze­sa­dzo­ne. SysML to obiek­to­we (w sen­sie para­dyg­ma­tu) roz­sze­rze­nie UML. Pomijając kwe­stie samej nota­cji, jeden z jej dia­gra­mów, dia­gram wyma­gań, pozwa­la na upo­rząd­ko­wa­nie listy wyma­gań”. To jed­nak mała zale­ta. Dużą zale­tą jest spój­ność poję­cio­wa z meto­da­mi obiek­to­wy­mi, ale może dosyć trud­nych terminów”.

Wymagania to hie­rar­chicz­na lista ocze­ki­wań wobec potrzeb­ne­go roz­wią­za­nia”. Zobrazowanie listy wyma­gań na dia­gra­mie poma­ga poka­zać wza­jem­ne związ­ki pomię­dzy wyma­ga­nia­mi oraz związ­ki wyma­gań z następ­ny­mi ele­men­ta­mi pro­jek­tu taki­mi jak testy odbior­cze i ele­men­ty mode­lu opi­su­ją­ce reali­za­cje tych wymagań:

Powyższy dia­gram pozwa­la po pierw­sze zoba­czyć” wyma­ga­nia, po dru­gie poka­zu­je związ­ki tych wyma­gań z pro­duk­ta­mi kolej­nych kro­ków pro­jek­tu. Po co? Przede wszyst­kim spraw­dzi­my, że te związ­ki są, że są spój­ne i kom­plet­ne (nie bra­ku­je żad­ne­go). Zapewne wie­lu z Was woli postać tabeli:

i słusz­nie, do czy­ta­nia jak naj­bar­dziej ale ta tabe­la, gdy­by powsta­ła jako jedy­na, nie pozwo­li na wery­fi­ka­cję kom­plet­no­ści imple­men­ta­cji wyma­gań i testów.

Cechy wyma­gań to bar­dzo waż­ne ele­men­ty zarzą­dza­nia wyma­ga­nia­mi, zale­cam stosowanie:

  1. Priorytet:
    1. naj­wyż­szy (np. 3.) – nie­speł­nie­nie tego wyma­ga­nia czy­ni roz­wią­za­nie cał­ko­wi­cie nie­przy­dat­nym do celu w jakim powstaje
    2. śred­ni (np. 2.) – nie­speł­nie­nie tego wyma­ga­nia powo­du­je ogra­ni­cze­nie przy­dat­no­ści rozwiązania
    3. niski (np. 1.) – nie­speł­nie­nie tego wyma­ga­nia pogor­szy jakość korzy­sta­nia z rozwiązania
  2. Status:
    1. Zgłoszone
    2. Uznane
    3. Odrzucone (ale nie usunięte)
  3. Źródło:
    1. ana­li­za (doku­men­tów, pro­ce­sów, inne samo­dziel­ne efek­ty pra­cy analityka)
    2. oso­ba (kon­kret­ne źró­dło infor­ma­cji po stro­nie ana­li­zo­wa­nej orga­ni­za­cji)
  4. Rodzaj (te na róż­nych etapach): 
    1. biz­ne­so­we
    2. wobec roz­wią­za­nia
      1. funk­cjo­nal­ne
      2. jako­ścio­we
      3. dzie­dzi­no­we

(wię­cej o kla­sy­fi­ka­cji wyma­gań)

Mamy IEEE 830‑1998, któ­ry opi­su­je doku­men­to­wa­nie wyma­gań. Często się mówi, że wyma­ga­nia mają być FURPS i SMART ale jak to osią­gnąć? Pomaga w tym nie rysu­nek a model, czy­li nie tyl­ko zobra­zo­wa­nie ale tak­że interpretowanie.

Osobna kwe­stią jest to jak pozy­sku­je­my wyma­ga­nia. Mogą to być wywia­dy, sesje JAD itp. Ja oso­bi­ście jestem zwo­len­ni­kiem ana­liz doku­men­tów, a potem wyja­śniam je i ich role z wyko­naw­ca­mi pro­ce­sów, ale o tym już było (i nie raz pew­nie będzie ;)).

Na koniec waż­na rzecz: nie wol­no utra­cić pano­wa­nia nad szcze­gó­ła­mi, któ­rych nie powin­no być zbyt wiele…

Gdyby ktoś zapy­tał: a po co kolej­ny dia­gram, odpo­wiem: model to sys­tem obiek­tów, ich powią­zań i cech. Ani tabe­la ani tym bar­dziej ilu­stro­wa­ny obraz­ka­mi tekst nam tego nie da, a bez tych powią­zań nie spraw­dzi­my ani kom­plet­no­ści wyma­gań ani tego czy ich imple­men­ta­cja jest spójna.

Aha, ile tych dia­gra­mów ma być? Nie za wie­le, ale muszą być dobre? jak ksią­żecz­ka do gry w sza­chy a do niej opis cze­go ocze­ku­je­my od naszych sza­chi­stów? (Ile tego ma być ? ana­li­za i model pro­ce­sów biz­ne­so­wych).

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

[[Analiza wyma­gań]] to temat rze­ka, meto­dy są róż­ne ale nie będę pisał o zna­nych mi, tyl­ko o pew­nym podej­ściu sys­te­mo­wym” zorien­to­wa­nym na mode­le i wzor­ce pro­jek­to­we. Ale po kolei.

Ile mamy poziomów szczegółowości wymagań

Poziom szcze­gó­ło­wo­ści wyma­gań jest tema­tem wie­lu dys­ku­sji, pisa­łem tu już nie raz na ten temat. Tym razem nie o tym, że zarzą­dza­nie tysią­ca­mi deta­li dużych pakie­tów opro­gra­mo­wa­nia jest nie­moż­li­we (i nie­ra­cjo­nal­ne). Tym razem o tym, że sto­so­wa­ne wzor­ców, tu ana­li­tycz­nych i pro­jek­to­wych, poma­ga. Najpierw kil­ka słów o pozio­mach szcze­gó­ło­wo­ści, któ­re stosuję:

  • Najwyższy poziom abs­trak­cji to nazwa­nie celu biz­ne­so­we­go np. chce­my spraw­nie wysta­wiać fak­tu­ry VAT. Jedno zda­nie, bez szcze­gó­łów. To naj­czę­ściej jest cel spon­so­ra pro­jek­tu, któ­rym jest nie­jed­no­krot­nie ktoś z zarządu.
  • Kolejny etap to dopre­cy­zo­wa­nie tego wyma­ga­nia, w tym momen­cie powo­łu­je­my się albo na prze­pi­sy, któ­re opi­su­ją to wyma­ga­nie wystar­cza­ją­co szcze­gó­ło­wo (np. Ustawa o podat­ku VAT i Ustawa o rachun­ko­wo­ści). Jeżeli nie mamy na co się powo­łać posze­rza­my ten opis sami. Tu mamy do czy­nie­nia z usłu­gą sys­te­mu z per­spek­ty­wy zama­wia­ją­ce­go a z [[przy­pad­kiem uży­cia]] z per­spek­ty­wy oprogramowania.
  • Jeżeli opro­gra­mo­wa­nie mia­ło by być wyko­na­ne na zamó­wie­nie, powsta­je dodat­ko­wo uszcze­gó­ła­wia­ją­cy opis każ­dej usłu­gi zawie­ra­ją­cy: dane wej­ścio­we i ocze­ki­wa­ne dane wyj­ścio­we, wzo­ry for­mu­la­rzy do wpro­wa­dza­nia danych i wzór pro­duk­tu (tu wzór fak­tu­ry) oraz sce­na­riusz uży­cia czy­li ocze­ki­wa­nia zama­wia­ją­ce­go co do spo­so­bu pra­cy z przy­szłym pro­gra­mem. Opis taki robi ana­li­tyk-pro­jek­tant a jako źró­dło infor­ma­cji wystę­pu­je eks­pert dzie­dzi­no­wy (czę­sto przy­szły użytkownik).

I tu zaczy­na się cie­kaw­szy ciąg dal­szy. [[Przypadki uży­cia]] to tak zwa­ny [[opis czar­nej skrzyn­ki]], nic nie mówi o logi­ce jaką chce­my odtwo­rzyć, wbu­do­wać do nowe­go opro­gra­mo­wa­nia. Pojawia się waż­ne pyta­nie: jaką wie­dzę” ma mieć to opro­gra­mo­wa­nie? Przypadki uży­cia koja­rzy się z tak zwa­ny­mi Aktorami sys­te­mu. Są to okre­ślo­ne role, któ­re będą wyko­ny­wa­ne przez użyt­kow­ni­ków (np. Specjalista ds. Handlowych może peł­nić rolę fak­tu­rzy­sty – akto­rem jest Fakturzysta). Dopiero po zde­fi­nio­wa­niu wie­dzy jaką ma (ma mieć) Aktor, mamy pod­sta­wy defi­nio­wać wie­dzę” jakiej ocze­ku­je­my do opro­gra­mo­wa­nia (to cze­go nie potra­fi Aktor).

Czarna skrzyn­ka (wyłącz­nie przy­pad­ki uży­cia) jako wyma­ga­nie jest bar­dzo ryzy­kow­nym narzę­dziem, bo nie defi­niu­je tego jaką wie­dzę” ma mieć (odtwa­rzać) to opro­gra­mo­wa­nie. Tu potrzeb­ne jest okre­śle­nie z cze­go będą powsta­wa­ły ocze­ki­wa­ne pro­duk­ty (co jest potrzeb­ne do wysta­wia­nia fak­tu­ry VAT, np. pro­duk­ty i usłu­gi zna fak­tu­rzy­sta czy ma je pod­po­wia­dać oprogramowanie).

Potrzebny jest więc opis logi­ki biz­ne­so­wej, któ­rą chce­my zaim­ple­men­to­wać. Ten opis to sed­no pro­ble­mu pra­cy analityka.

I przy­szła pora na ana­li­zę”. Powszechnie nad­uży­wa­ne sło­wo ana­li­za oznacza:

ana­li­za [gr. anály­sis ?roz­ło­że­nie?, ?roz­biór?], roz­ło­że­nie pew­ne­go obiek­tu na ele­men­ty skła­do­we (czę­ści, cechy, rela­cje); może być zabie­giem fizycz­nym lub czyn­no­ścią myślo­wą; (za Encyklopedia PWN).

Słowo klucz: ele­men­ty skła­do­we”. W meto­dach pra­cy, któ­re sto­su­ję, powyż­sze jest pod­sta­wo­wym narzę­dziem” pra­cy. Ale tu małe wyja­śnie­nie: nie­ste­ty więk­szość spo­ty­ka­nych doku­men­tów ana­li­tycz­nych, nie wie­le ma wspol­ne­go z ana­li­zą. Dlaczego? Skoro ana­li­za to roz­ło­że­nie na ele­men­ty skła­do­we”, to czym jest zapis życzeń i ocze­ki­wań wyar­ty­ku­ło­wa­ny usta­mi pra­cow­ni­ków jakiejś fir­my czy orga­ni­za­cji na spo­tka­niach, w posta­ci tek­stu, tabel lub nie­for­mal­nych obraz­ków ? Jest po pro­stu jakimś spi­sem ale na pew­no nie analizą.

Żeby doko­nać jakiej­kol­wiek ana­li­zy musi­my sobie naj­pierw zde­fi­nio­wać jakieś ele­men­ty skła­do­we”. Analiza zda­nia pole­ga na wyod­ręb­nie­niu słów, koja­rze­niu ich w związ­ki itp. ale począt­kiem jest ist­nie­ją­cy słow­nik i regu­ły gra­ma­tycz­ne. Analiza che­micz­na to roz­ło­że­nie sub­stan­cji na z góry zna­ne pier­wiast­ki (pomi­jam ich odkry­wa­nie). Czym jest ana­li­za biz­ne­so­wa czy ana­li­za wymagań?

Analiza pro­ce­sów biz­ne­so­wych wyma­ga zro­zu­mie­nia tego co dzie­je się w ana­li­zo­wa­nej fir­mie i roz­ło­że­nie tego na pre­de­fi­nio­wa­ne ele­men­ty skła­do­we. W zasa­dzie mamy jeden: pro­ces biz­ne­so­wy. Jego defi­ni­cja okre­śla ato­mo­wy ele­ment takiej ana­li­zy. Jeżeli patrzy­my więc dia­gram zawie­ra­ją­cy pro­sto­ką­ty i linie będą­ce gra­ficz­nym zapi­sem tego co powie­dzia­no”, nie jest to żaden wynik ana­li­zy ani model a jedy­nie obraz­ko­wy zapis opowieści.

Dalej: pro­jek­to­wa­nie opro­gra­mo­wa­nia. Na czym pole­ga ana­li­za obiek­to­wa i pro­jek­to­wa­nie? Po pierw­sze zno­wu potrzeb­ne są ele­men­ty skła­do­we” (przy­po­mi­nam, że ma być ich skoń­czo­na licz­ba, mają zde­fi­nio­wa­ne zna­cze­nia, któ­re się na sie­bie nie nakła­da­ją (nic nie może paso­wać do dwóch defi­ni­cji jed­no­cze­śnie) i pozwa­la­ją, z usta­lo­na dokład­no­ścią, na zbu­do­wa­nie ana­li­zo­wa­nej całości.

Przykład

Opiszę jak moż­na pro­wa­dzić ana­li­zę i budo­wać część wyma­gań o nazwie model dzie­dzi­ny (model logi­ki biznesowej).

Zgodnie z powyż­szym nale­ży zacząć od zde­fi­nio­wa­na sobie skoń­czo­nej licz­by kloc­ków (ich typów). Np. LEGO, moż­na z nich zbu­do­wać wszyst­ko” akcep­tu­jąc pew­ną gra­ni­ce w odtwa­rza­niu uszcze­gó­łów. Typów pod­sta­wo­wych kloc­ków jest kil­ka a jed­nak moż­na z nich zbu­do­wać dom, samo­lot czy kaczkę:

Analiza pole­ga na tym, by real­ny dom lub kacz­kę roz­ło­żyć na skoń­czo­na licz­bę (z regu­ły nie wiel­ką) pro­stych ele­men­tów skła­do­wych, któ­rych słow­ni­kiem” jest posia­da­ny zestaw LEGO. Wynikiem ana­li­zy jest doku­ment” w posta­ci instruk­cji jak zło­żyć domek z LEGO”. Innymi sło­wy, mamy skoń­czo­ną licz­bę ele­men­tów budul­co­wych” ana­li­za pole­ga na zro­zu­mie­niu pro­ble­mu, roz­ło­że­niu go na takie wła­śnie elementy.

Osobiście jestem zwo­len­ni­kiem sto­so­wa­nia [[wzor­ca pro­jek­to­we­go MVC]] oraz sty­lu ana­li­zy i pro­jek­to­wa­nia zwa­ne­go DDD (ang. [[Domain Driven Design]], pro­jek­to­wa­nie ste­ro­wa­ne dzie­dzi­ną sys­te­mu, arty­kuł o DDD). DDD to wzor­ce zarów­no ana­li­tycz­ne jak i pro­jek­to­we. Te wzor­ce to wła­śnie takie ato­mo­we kloc­ki”.

Na eta­pie ana­li­zy, roz­kła­da­my” ana­li­zo­wa­ną fir­mę (jej część) na ele­men­tar­ne skład­ni­ki. W DDD są to poje­dyn­cze encje i ich agre­ga­ty, typy (value-object), usłu­gi, fabry­ki, repo­zy­to­ria. Analiza pole­ga na opi­sa­niu (roz­ło­że­niu jej ) całej logi­ki opro­gra­mo­wa­nia z pomo­cą tych kil­ku stan­dar­do­wych kloc­ków”. Model taki dla deve­lo­pe­ra sta­je się pro­jek­tem, a te kloc­ki wzor­ca­mi projektowymi.

Poniżej zaba­wo­wy” przy­kład takiej analizy.

Aktorem jest użyt­kow­nik. Potrzebny mu jest sys­tem” któ­ry da mu przed­miot wyko­na­ny z kloc­ków LEGO (domek). System cał­ko­wi­cie izo­lu­je Aktora od swo­je­go wnę­trza z pomo­cą Recepcji (View w mode­lu MVC). Wewnątrz mamy zestaw kloc­ków (encje, agre­ga­ty), deli­kwen­ta wie­dzą­ce­go jak wyko­nać domek (usłu­ga) oraz fabry­kę kloc­ków (na bazie wzor­ców two­rzy­my ich tyle ile potrze­bu­je­my, ile zażą­da usługodawca).

Aby zacho­wać wytwo­rzo­ne kloc­ki a tak­że wyni­ki prac czy pół­pro­duk­ty, musi­my mieć pudeł­ko na kloc­ki: repo­zy­to­rium. Nad cało­ścią czu­wa Kontroler, eki­pa ludzi zaj­mu­ją­ca się wszyst­ki­mi poza spe­cja­li­stycz­ny­mi” (poza-dzie­dzi­no­wy­mi) zada­nia­mi. Z racji tego, że takie poję­cia jak wydaj­ność, zaso­by, bez­pie­czeń­stwo itp. są uni­wer­sal­ne, taka eki­pa back offi­ce (skrzyn­ka na zabaw­ki, recep­cja, kon­tro­ler) może zostać wyna­ję­ta nie­mal­że dla każ­dej fir­my bez wzglę­du na bran­że (to się nazy­wa fra­me­work). Specyficzna jest tyl­ko dzie­dzi­na, tu typ klocków.

Tak więc ana­li­za wyma­gań na opro­gra­mo­wa­nie to lista wyma­ga­nych usług. Wymagania na dedy­ko­wa­ne opro­gra­mo­wa­nie zaś to nie jest spi­sa­nie i sor­to­wa­nie ocze­ki­wań. Analiza to roz­ło­że­nie pro­ble­mu (fir­ma klien­ta) na kloc­ki zgod­ne z uzna­ną (uży­wa­ną) meto­dy­ką i wzor­ca­mi. DDD (opis wzor­ców pro­jek­to­wych DDD) to wła­śnie jeden z takich zesta­wów klocków.

Wynikiem ana­li­zy jest model (a nie tyl­ko obra­zek) opi­su­ją­cy jak dzia­ła ana­li­zo­wa­na fir­ma, zbu­do­wa­ny z kloc­ków, tu opi­sa­nych w DDD.

Dla deve­lo­pe­ra taki model jest pro­jek­tem logicz­nym ([[Platform Independent Model w nomen­kla­tu­rze OMG/MDA]]). W efek­cie ana­li­tyk nie tyl­ko zro­zu­miał i udo­ku­men­to­wał pro­blem, ana­li­tyk zapro­jek­to­wał logi­kę biz­ne­so­wą opro­gra­mo­wa­nia, moż­li­wą do bez­po­śred­niej imple­men­ta­cji przez deve­lo­pe­ra (przy zało­że­niu, że sto­su­je meto­dy obiek­to­we i zna uży­te wzor­ce). Taki efekt dają meto­dy obiek­to­we i prag­ma­ty­ki np. DDD. Za to wła­śnie bar­dzo lubię obiek­to­wy para­dyg­mat i DDD: obiek­to­wość” zrów­nu­je wynik ana­li­zy z pro­jek­tem, DDD daje nam zestaw kloc­ków: słow­nik pojęć, zro­zu­mia­ły dla biz­ne­su” i dla deve­lo­pe­ra. DDD to zestaw wzor­ców pozwa­la­ją­cy na dogłęb­ne zro­zu­mie­nie ana­li­zo­wa­ne­go pro­ble­mu i będą­ce zara­zem pro­jek­tem jego implementacji.

Kim więc jest dobry analityk?

Jest to ktoś, kto potra­fi ana­li­zo­wa­ną orga­ni­za­cję roz­ło­żyć na ele­men­ty skła­do­we”. Tymi ele­men­ta­mi są wzor­ce pro­jek­to­we, ele­men­ty sto­so­wa­nej nota­cji. Wynik ana­li­zy to nie rysu­nek”, to model w posta­ci sche­ma­tu blo­ko­we­go (dia­gra­mu), na któ­rym każ­dy ele­ment ma ści­śle okre­ślo­ne znacz­nie, kon­struk­cję i zasa­dy wza­jem­ne­go łącze­nia i oddziaływania.

Analiza Biznesowa to roz­ło­że­nie ana­li­zo­wa­ne­go przed­mio­tu” na skoń­czo­ny zestaw ele­men­tów, któ­ry z okre­ślo­ną dokład­no­ścią zacho­wu­je się tak, jak ana­li­zo­wa­na orga­ni­za­cja. Jeżeli te ele­men­ty skła­do­we mają tak­że swo­je odwzo­ro­wa­nie w kodzie pro­gra­mu, to wynik ana­li­zy sta­je się pro­jek­tem tego oprogramowania.

Więc pozio­my szcze­gó­ło­wo­ści wyma­gań to:

  • cele biz­ne­so­we (pro­duk­ty pro­ce­sów biznesowych)
  • opis usług żąda­nych od opro­gra­mo­wa­nia (tu tak­że for­mat­ki papierowe/ekranowe, przy­pad­ki uży­cia oprogramowania)
  • opis (pro­jekt) wewnętrz­nej logi­ki biz­ne­so­wej (wewnętrz­ne ele­men­ty skła­do­we i sce­na­riu­sze ich współdziałania)

P.S.

Artykuł ma cha­rak­ter badaw­czy”, wszel­kie uwa­gi mile widziane.

Wymagania na coś dużego – w czym problem?

Zapytania o pro­dukt mają­cy wdzięcz­ną nazwę Analiza potrzeb i opra­co­wa­nie wyma­gań na sys­tem ERP” (w miej­sce ERP moż­na wsta­wić dowol­ny innych skrót w rodza­ju CRM, BI, SCM, work­flow itp..) naj­czę­ściej rodzą ocze­ki­wa­nia w posta­ci lista wyma­gań funk­cjo­nal­nych i poza-funkcjonalnych”.

Lista taka jest zna­na z inży­nie­rii opro­gra­mo­wa­nia i jest powszech­nie sto­so­wa­na do pro­jek­to­wa­nia i wytwa­rza­nia tego opro­gra­mo­wa­nia. Ale jest pewien pro­blem gdy celem jest zakup goto­we­go opro­gra­mo­wa­nia, bo w koń­cu goto­we­go nie pro­jek­tu­je­my, bo podob­no ma być tań­sze niż pisa­nie od początku.

Niedawno napi­sa­łem:

Duży sys­tem ERP to set­ki i tysią­ce jego przy­pad­ków uży­cia, nie ma sen­su ich spe­cy­fi­ko­wa­nie podob­nie jak nie ma sen­su pyta­nie o nie przy­szłych użyt­kow­ni­ków tego sys­te­mu, bo nie są w sta­nie ich wyli­czyć. Ma jed­nak sens zro­zu­mie­nie tego jak fir­ma dzia­ła. Po raz kolej­ny posłu­żę się meta­fo­rą Martina Fowlera: grę w sno­oke­ra moż­na opi­sać rela­cjo­nu­jąc (zapi­su­jąc) set­ki kolej­nych par­tii, ale i tak nigdy nie wyspe­cy­fi­ku­je­my nawet ułam­ka moż­li­wych zagrań. Zdecydowanie lep­szą meto­dą jest przyj­rze­nie się kil­ku par­tiom i wychwy­ce­nie cech bili, ich ilo­ści, wymia­rów sto­łu oraz reguł gry, bo to będzie zgod­ne nie tyl­ko z histo­rią ode­gra­nych par­tii sno­oke­ra ale z każ­dą przy­szłą partią.

Dlatego zamiast pro­wa­dze­nia żmud­nych wywia­dów i two­rze­nie nie­sku­tecz­nej listy setek szcze­gó­ło­wych opi­sów moż­li­we­go uży­cia opro­gra­mo­wa­nia, lepiej jest zro­zu­mieć orga­ni­za­cję, stwo­rzyć jej model (dzie­dzi­ny) i wyspe­cy­fi­ko­wać jakie usłu­gi ma to opro­gra­mo­wa­nie świad­czyć dla użyt­kow­ni­ków teraz (bo tak nale­ży rozu­mieć poję­cie przy­pad­ku uży­cia sys­te­mu). Poprawny model dzie­dzi­ny pozwo­li tak­że na obsłu­gę przy­szłych wyma­gań mimo, że nie zna­my ich teraz. Podobnie jak stół bilar­do­wy: nie zna przy­szłych ude­rzeń ale wie­my, że na pew­no zosta­ną ?obsłu­żo­ne?. (Czym jest to co mode­lu­jesz w opro­gra­mo­wa­niu? Model dzie­dzi­ny sys­te­mu jako wyma­ga­nie.).

Wydawało by się, że wszyst­ko jasne. Ale? Popatrzmy na poniż­szy diagram:

Czas trwa­nia ana­li­zy i spe­cy­fi­ko­wa­nia (pra­co­chłon­ność, więc tak­że koszt) rośnie linio­wo w takt kolej­nych dni pra­cy nad ana­li­zą. W mia­rę powsta­wa­nia kolej­nych udo­ku­men­to­wa­nych szcze­gó­łów, ryzy­ko, że wybie­rze­my zły (nie­pa­su­ją­cy nam) pro­dukt male­je. Jednak ryzy­ko jest, jak widać, funk­cją nie­li­nio­wą (jest to praw­do­po­do­bień­stwo złe­go wybo­ru, któ­re nigdy nie doj­dzie do zera) zaś wzrost kosz­tów jest linio­wy. W efek­cie od pew­ne­go momen­tu, dość bli­skie­go począt­ko­wi tej pra­cy, kosz­ty takiej ana­li­zy rosną szyb­ciej niż korzy­ści z jej szcze­gó­ło­wo­ści. Tak więc w typo­wym pro­jek­cie w zasa­dzie ska­za­ni jeste­śmy na kom­pro­mis i uzna­nie pew­ne­go (nie tak małe­go) ryzy­ka, że jed­nak wybór będzie zły (mimo, że pro­dukt speł­ni skoń­czo­ną listę wymagań).

Przekroczenie pew­nej umow­nej gra­ni­cy roz­sąd­ku” – ana­li­zy i spi­sy­wa­nia szcze­gó­łów – popy­cha taki pro­jekt w kie­run­ku pro­jek­to­wa­nia nowe­go sys­te­mu, a mia­ło być tanio, bo chce­my kupić sys­tem goto­wy. Krótkie wyli­cze­nie: typo­wy sys­tem ERPII to ok. 6 tys. cech. Samo ich spi­sa­nie ze zro­zu­mie­niem to:

  • opis jed­ne­go wyma­ga­nia to 500 zna­ków (śred­ni wynik z kil­ku zna­nych mi dokumentów)
  • jed­na stro­na maszy­no­pi­su to 1800 znaków
  • 6 tys cech to 6000 x 500 zna­ków / 1800 stro­na = 1667 stron tekstu
  • z roz­mów z wyko­naw­ca­mi ana­li­ty­ka­mi wiem, że efek­tyw­nie piszą ok. 7 mery­to­rycz­nych stron dzien­nie (to dość opty­mi­stycz­ne założenie)
  • w efek­cie 1667 stron / 7 dzien­nie = 238 dni robo­czych, staw­ka bar­dzo tanie­go kon­sul­tan­ta to np. 1000zł/dzień, otrzy­mu­je­my: 238 tys. zło­tych i ponad rocz­ny projekt.
  • Jeżeli uzna­my, że jed­nak spe­cy­fi­ko­wa­nie jest poprze­dza­ne ana­li­zą, dla uprosz­cze­nia (zno­wu bar­dzo opty­mi­stycz­nie) przyj­mę, trwa­ją­ca tyle co spi­sy­wa­nie jej wyni­ków, mamy dwa lata pra­cy i pół milio­na złotych.
  • Skrócenie tego poprzez zatrud­nie­nie nie jed­ne­go a np. czte­rech ana­li­ty­ków pod­nie­sie kosz­ty o ok. 30% (znam takich, któ­rzy by tu doda­li 50% i pew­nie mają nie raz rację) na koor­dy­na­cję, kon­tro­lę zgod­no­ści, popraw­ki wyni­ka­ją­ce z uspój­nia­nia pra­cy róż­nych autorów”.

Urealnienie tych wyli­czeń (choć­by staw­ki ana­li­ty­ków) wywin­du­je ten budżet na kwo­tę znacz­nie ponad milion zło­tych! Na to sobie mało kto sobie pozwo­li. W więk­szo­ści przy­pad­ków nie jest robio­na tak dłu­go trwa­ją­ca ana­li­za i za nie takie pie­nią­dze. Zaryzykuje tezę, że – obser­wu­jąc sta­ty­sty­ki pro­jek­tów IT – nie ma to, takie podej­ście, żad­ne­go sen­su. Tak więc tak opra­co­wa­ne spe­cy­fi­ka­cje, są jed­nak uprasz­cza­ne z uwa­gi na kosz­ty, są z zasa­dy niekompletne!

Teraz przy­szła pora na moje­go ser­decz­ne­go przy­ja­cie­la, któ­ry zjadł zęby na kor­po­ra­cyj­nym ryn­ku IT (wyba­czy­cie mi Państwo, że dane jego zacho­wam dla sie­bie). Oto co mi nie­daw­no powie­dział pod­czas podob­nej dyskusji:

Nawet przy kup­nie kon­kret­nej kieł­ba­sy kry­te­riów wybo­ru skle­pu może być wie­le i zakła­da­my, że ktoś ma czas/pieniądze aby je wszyt­kie zasto­so­wać, by pod­jąć decy­zję. Przy kup­nie samo­cho­du czy komór­ki ilość funk­cji, któ­re trze­ba porów­nać jest tak duża, że porów­ny­wa­nie to już spo­ra pra­ca. Nie zawsze ma się zaso­by, aby ją wyko­nać. Nabywca z dobrym dzia­łem zaku­pów ma sche­ma­ty oce­ny wie­lo­kry­te­rial­nej skom­pli­ko­wa­nych towa­rów i usług, Ale kto poświę­ci 2 godzi­ny na decy­zję, jaki kupić sobie dłu­go­pis? Pewnie nikt, ale na pod­ję­cie decy­zji kup­na komór­ki 2 godzi­ny to sta­now­czo za mało, choć błęd­na decy­zja jest kosz­tow­na lub wią­że nas na 2 lata z mode­lem, któ­ry nie speł­nia oczekiwań.

Producenci róż­nych rze­czy zda­ją sobie spra­wę, że kosz­ty pod­ję­cia wła­ści­wej decy­zji przy skom­pli­ko­wa­nych pro­duk­tach są spo­re i ludzie będą podej­mo­wać decy­zje błęd­ne, to pozwa­la dzia­łać na ryn­ku fir­mom, któ­re w prze­ciw­nym wypad­ku by upadły.

I jak teraz wyglą­da­ją w Państwa oczach zaku­py i wdro­że­nia dużych goto­wych sys­te­mów? Czy to zna­czy, że kup­no goto­we­go sys­te­mu nigdy nie ma sen­su? Ależ ma ale…

Gotowe opro­gra­mo­wa­nie jest adre­so­wa­ne z zasa­dy do wie­lu róż­nych odbio­rów, ska­za­ne jest więc na znacz­ny nad­miar funk­cjo­nal­no­ści na zapas” (popa­trz­my z jakiej czę­ści cech tele­fo­nów czy pakie­tów biu­ro­wych korzy­sta­my). Skoro więc potrze­bu­je­my cze­goś co ma 100 potrzeb­nych nam cech a wybie­ra­my coś goto­we­go na ryn­ku co ma ich 1000, ale zawie­ra te potrzeb­nych nam 100, to sama nasu­wa się teza, że powy­żej pew­ne­go pro­gu uni­wer­sal­ne roz­wią­za­nie kosz­tu­je wię­cej (uwzględ­nia­jąc kosz­ty decy­zji) niż korzy­ści z cech wyma­ga­nych i zapew­ne nie raz war­to wyko­nać coś pod nasze potrze­by”. I tu poja­wia się haczyk: nale­ży te potrze­by bar­dzo dobrze – z mini­mal­nym ryzy­kiem – opi­sać. Bo wszy­scy wie­my jak się koń­czą pro­jek­ty pro­gra­mi­stycz­ne, w któ­rych klient nie wie cze­go chce”.

Jak to robić lepiej? Po pierw­sze nie kupo­wać dużych i dro­gich zin­te­gro­wa­nych sys­te­mów” bo to duże ryzy­ko, kupo­wać mniej­sze, łatwiej­sze do opi­sa­nia, pro­jek­to­wać i two­rzyć te, któ­re są zbyt dużym ryzy­kiem w przy­pad­ku złe­go wybo­ru. Jeżeli już z powo­du ryzy­ka mamy poświę­cić duży budżet na kosz­tow­ne spe­cy­fi­ko­wa­nie opro­gra­mo­wa­nia to sygnał, że nale­ży je za te pie­nią­dze po pro­stu zapro­jek­to­wać i wykonać.

Niestety nie ma pro­stej odpo­wie­dzi na pyta­nie jak to robić dobrze”. Chyba, że będzie to pro­po­zy­cja nastę­pu­ją­ce­go procesu:

  1. ana­li­za biznesowa,
  2. zde­fi­nio­wa­nie celu,
  3. zapro­jek­to­wa­nie archi­tek­tu­ry sys­te­mu (to jako sys­tem nale­ży rozu­mieć orga­ni­za­cję wraz z wspie­ra­ją­ca ją infor­ma­ty­ką), tu zmie­rza­my w kie­run­ku tak zwa­nej [[archi­tek­tu­ry korporacyjnej]],
  4. ziden­ty­fi­ko­wa­nie ocze­ki­wa­nych od opro­gra­mo­wa­nia usług (wyma­ga­nia), podzie­lić je na odręb­ne ale spój­ne obsza­ry dzie­dzi­no­we,
  5. dla każ­de­go obsza­ru dzie­dzi­no­we­go opra­co­wać wyma­ga­nia na oprogramowanie,
  6. wybrać roz­wią­za­nia.

Zwracam uwa­gę na drob­ny szcze­gół: wybo­ru pro­duk­tu i jego dostaw­cy doko­nu­je­my na koń­cu, nigdy na począt­ku! A kto i dla­cze­go nas prze­ko­nu­je, że nale­ży naj­pierw kupić a potem analizować?

(arty­kuł uka­zał się tak­że w ERP​-Viev​.pl)

FURPS i SMART na widłach

Bardzo czę­sto poja­wia­ją się w ofer­tach i na szko­le­niach doty­czą­cych wyma­gań dwa akro­ni­my: [[FURPS]] i [[SMART]]. Cóż to jest? To zale­ce­nia doty­czą­ce oce­ny spe­cy­fi­ka­cji wyma­gań na opro­gra­mo­wa­nie. Jednak czym innym jest oce­nić czy zale­ce­nia te speł­nia doku­ment wyma­gań (jego treść) a czym innym jest to jak je spełnić.

Cóż to jest FURPS? Angielski akro­nim roz­szy­fro­wu­je­my następująco:

  • Functionality- funk­cjo­nal­ność w rozu­mie­niu zesta­wu funk­cji uwzględ­nia­ją­ca rów­nież bez­pie­czeń­stwo (ang. security)
  • Usability – uży­tecz­ność jako zestaw wizu­al­nych aspek­tów oprogramowania
  • Reliability – nie­za­wod­ność, będą­ca mie­rzo­na np. czę­sto­ścią wystę­po­wa­nia błędów
  • Performance – wydaj­ność apli­ka­cji okre­śla­na rów­nież jako czas odpo­wie­dzi lub uży­cie zasobów
  • Supportability – podat­ność na ser­wi­so­wa­nie („ser­wi­so­wal­ność”), dają­ca się łatwo testo­wać, napra­wiać i rozwijać.

SMART to akro­nim od słów: Sprecyzowane, Mierzalne, Akceptowane, Realistyczne, Terminowe.

Jak widać maję one pew­ną wspól­ną cechę: to są ocze­ki­wa­nia w sto­sun­ku do spe­cy­fi­ka­cji wyma­gań. Dlaczego piszę o tym? Po pierw­sze w FURPS są prze­mie­sza­ne wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne: funk­cjo­nal­ność vs. wydaj­ność, nie­za­wod­ność i podat­ność na ser­wi­so­wa­nie. Do tego są one dość subiek­tyw­ne bo np. jak spraw­dzić czy wyma­ga­nia są użyteczne?

W kwe­stii SMART jest jesz­cze gorzej: wszyst­kie pięć pojęć to subiek­tyw­ne życze­nia bez moż­li­wo­ści wery­fi­ka­cji ich spełnienia.

Widły Hume’a

Edynburg_2013-04-19_10-52_JZelinskiW filo­zo­fii func­kjo­nu­je poję­cie „[[widły Hume’a]]”, w dużym uprosz­cze­niu Hume ([[David Hume]]) twier­dzi, że wie­le tre­ści, ksiąg i wypo­wie­dzi to tre­ści ułom­ne, nie­zro­zu­mia­łe, bez­za­sad­ne lub banal­ne. Czym są owe Widły Hume’a? Każdą wypo­wiedź nale­ży spraw­dzić dwo­ma pytaniami:

  • Co to znaczy?
  • Skąd to wiesz?

Tak wiec jak ktoś powie, że jego wyma­ga­nia są SMART to zadaj np. pyta­nie: Co to zna­czy Sprecyzowane? Skąd wie­my, że one są spre­cy­zo­wa­ne? I tak po każ­dym z tych magicz­nych słów.

Zresztą każ­dy waż­ny doku­ment, tu doku­ment wyma­gań, war­to tak prze­te­sto­wać, szcze­gól­nie jeśli opi­su­je coś war­te­go poten­cjal­nie dzie­siąt­ki tysię­cy zło­tych. Jak na te, widły, zare­agu­ją doku­men­ty opra­co­wa­ne meto­da­mi for­mal­ny­mi? W pro­sty sposób:

Co to zna­czy, że wyma­ga­nia są zwe­ry­fi­ko­wa­ne? To zna­czy, że z powo­dze­niem prze­pro­wa­dzo­no test pole­ga­ją­cy na wyko­na­niu wszyst­kich czyn­no­ści mode­lu pro­ce­su biz­ne­so­we­go. Skąd to wie­my? Bo na wej­ściu mode­lu pro­ce­su poda­no” praw­dzi­we doku­men­ty, uda­ło się na mode­lu wska­zać wszyst­kie czyn­no­ści wyma­ga­ne do obsłu­że­nia tego doku­men­tu i nie było innych zbęd­nych, otrzy­ma­li­śmy taki sam rezul­tat (wyni­ko­wy doku­ment i jego stan) jak w natu­rze oraz na liście przy­pad­ków uży­cia są wszyst­kie te i tyl­ko te, któ­re były potrzeb­ne by ten pro­ces bez błę­du prze­szedł do koń­ca. Jak to się robi? Przeczytaj o tym tu.

Jeżeli doku­ment wyma­gań nie speł­nia tych kry­te­riów, nie mie­ści się w tych widłach, to jak sam Hume twier­dzi, jest on bez­war­to­ścio­wy, nie nie­sie żad­nej wie­dzy gdyż poszcze­gól­ne wyma­ga­nia są: albo nie­zro­zu­mia­łe, albo zro­zu­mia­łe lecz nie uza­sad­nio­ne, albo zro­zu­mia­łe i zasad­ne lecz banal­ne (np. mają być Sprecyzowane). Tak więc wie­my co to zna­czy FURPS i SMART (powyż­sze skró­ty). Odbierając doku­men­ty ana­liz zada­waj­cie pyta­nie: a skąd wie­my, że te wyma­ga­nia (któ­re ktoś spi­sał) są FURPS i SMART i co to oznacza?

Polecam: Grzegorz Trela, meta­fo­ry filozoficzne

jak to niektórzy robią w Ameryce”">

IIBA czyli jak to niektórzy robią w Ameryce”

O szkoleniu

Ameryka przy­je­cha­ła do nas, [[Darryl Booker]], któ­ry 20 lat (poza pra­cą na uczel­ni) pra­cu­je jako kon­sul­tant, ana­li­tyk biz­ne­so­wy był tre­ne­rem na szko­le­niu, któ­re mam wła­śnie za sobą.

Z jed­nej stro­ny trzy dni pozna­wa­łem coś do cze­go sam docho­dzi­łem, co w zasa­dzie znam i potra­fię, jed­nak z dru­giej stro­ny szko­le­nia pro­wa­dzo­ne przez ludzi z dużym doświad­cze­niem zawsze mają dwa aspek­ty: po pierw­sze począt­ku­ją­cy dowie­dzą się jak nale­ży pra­co­wać i co powin­no pod­czas tej pra­cy powsta­wać po dru­gie dla mnie (dla każ­de­go z dużym doświad­cze­niem) bar­dzo cen­ne są kon­tak­ty z inny­mi ludź­mi z bran­ży, bo porów­na­nie wie­dzy, wymia­na doświad­czeń oraz dys­ku­sje pozwa­la­ją porów­nać swo­je doko­na­nia z cudzy­mi. W wie­lu pro­jek­tach i na kon­fe­ren­cjach sły­szę, że wymy­ślam jakieś nie­stwo­rzo­ne rze­czy bo nikt tak nie robi (mode­lo­wa­nie, testo­wa­nie wyma­gań, pro­of-of-con­cept, itp.). Otóż nie praw­da, po pro­tu bar­dzo wie­lu ludzi (w bar­dzo wie­lu pro­jek­tach) nie zarzą­dza ryzy­kiem przyj­mu­jąc gene­ral­nie opty­mi­stycz­ne wer­sje wydarzeń.

Czego się nauczy­łem na tym szko­le­niu? Że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być loterią.

Jak to się robi? Od kil­ku lat pro­mu­ję ideę nauko­wej ana­li­zy sys­te­mo­wej: opis celu, opis pro­ble­mu, sta­wia­nie hipo­tez, mode­le i sce­na­riu­sze, reko­men­da­cje i pro­jekt. Nie musi to być i nie jest żaden tak zwa­ny wodo­spad” pro­jek­to­wy ([[wat­ter fall model IT]]), zwin­ność tu pole­ga na reago­wa­niu na każ­dym eta­pie pro­jek­tu na pro­ble­my i wpro­wa­dza­nie zmian, pro­dukt pro­jek­tu jest zawsze mode­lo­wa­ny i testo­wa­ny na każ­dym eta­pie. W efek­cie spe­cy­fi­ka­cja tego co ma powstać jest kom­plet­na, nie wyma­ga pro­to­ty­po­wa­nia” na żywym cie­le (powsta­je kod dla klien­ta, któ­ry zgła­sza uwa­gi do tego co zoba­czy) a zama­wia­ją­cy wie co dosta­nie w dniu zamó­wie­nia i wie ile to będzie kosztowało.

Mity dostawców oprogramowania

Dostawcy goto­we­go opro­gra­mo­wa­nia szer­mu­ją tezą, że oszczę­dzą Wam kosz­tów ana­li­zy bo mają wie­dzę i doświad­cze­nie zawar­te” w swo­im pro­duk­cie. Ryzyko, że wyma­ga­nia biz­ne­so­we zosta­ną źle zde­fi­nio­wa­ne i ryzy­ko, że dostar­czo­ny pro­dukt nie speł­nia tych wyma­gań jest igno­ro­wa­ne (klient zamó­wił to klient dosta­nie, czy to będzie mu potem potrzeb­ne to nie nasz problem).

Developerzy ofe­ru­ją­cy wyko­na­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia bez ana­li­zy wyma­gań a np. tyl­ko z pomo­cą tak zwa­nych sesji JAD (ang. [[Joint appli­ca­tion design]]) i kolej­nych pro­to­ty­pów, w ogó­le nie bio­rą pod uwa­gę ryzy­ka nie­kom­plet­no­ści tak okre­ślo­nych wyma­gań ani bra­ku ich spój­no­ści (zna­ny pro­blem odkry­wa­nia wyma­gań w trak­cie wdro­że­nia). Klient powie co chce i będzie OK a opro­gra­mo­wa­nie i tak ma być bo każ­dy ma.

A ryzy­ko, że ana­li­za potrzeb i pro­jekt tego co ma powstać, wyko­na­na przez przy­szłe­go wyko­naw­cę, będzie tak na praw­dę tyl­ko spe­cy­fi­ka­cję tyl­ko tego co dostaw­ca potra­fi wykonać?

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?

Wczoraj na sali i w kulu­arach padły mię­dzy inny­mi takie odpowiedzi:

  1. dostaw­cy opro­gra­mo­wa­nia bar­dzo czę­sto nie potra­fią takiej ana­li­zy wyko­nać bo nie mają wyma­ga­nych kom­pe­ten­cji, ale potra­fią pro­gra­mo­wać i tyl­ko na to się godzą.

  2. dostaw­cy opro­gra­mo­wa­nia dosko­na­le wie­dzą, że ist­nie­je ryzy­ko że ich pro­dukt nie speł­nia wyma­gań więc bar­dzo czę­sto nie dopusz­cza­ją do takich ana­liz for­su­jąc od razu wdro­że­nie (wręcz tępią w pro­jek­tach zewnętrz­nych analityków!).

  3. klien­ci mają sta­le do czy­nie­nia z dostaw­ca­mi a bar­dzo rzad­ko z nie­za­leż­ny­mi ana­li­ty­ka­mi i bar­dzo czę­sto przyj­mu­ją wia­rę w to co mówią dostawcy.

  4. nie ist­nie­ją nie­za­leż­ni analitycy.

Na ostat­nie odpo­wiem tak: jest ich (nas) mało… ale to łatwo spraw­dzić: popro­sić o refe­ren­cje i zapy­tać co reko­men­do­wa­li. Dobry ana­li­tyk nigdy nie reko­men­du­je imple­men­ta­cji a tyl­ko two­rzy spe­cy­fi­ka­cję biz­ne­so­wą. Po trze­cie, war­to anga­żo­wać ludzi zna­nych w bran­ży z tego, że nie są na pro­wi­zjach u producentów.

Agile…

Wielu z deve­lo­pe­rów idzie dalej: nie trze­ba ana­li­zy, trze­ba od razu zacząć two­rzyć roz­wią­za­nie, [[Agile Manifesto]] – hasło prze­wod­nie tej meto­dy jasno mówi, że cho­dzi o to by pro­gra­mo­wać a nie o to by coś doku­men­to­wać, szko­da cza­su na głu­po­ty (zawsze tak okre­ślo­ne meto­dy zwin­ne koja­rzy­ły mi się z home­opa­tią: dostaw­cy obie­cu­ją coś nie wie­dząc co na praw­dę boli i nie bio­rą żad­nej odpo­wie­dzial­no­ści za skut­ki, co cie­ka­we żad­ne dane nie potwier­dza­ją sku­tecz­no­ści tych metod).

Inna cie­ka­wost­ką metod Agile jest to, że pro­jekt koń­czy się nie wte­dy gdy powsta­nie to co zamó­wił (a raczej wyobra­żał sobie klient bo nic nie zamó­wił, w koń­cu nie powsta­ła żad­na spe­cy­fi­ka­cja) tyl­ko to co powsta­nie dopó­ki nie skoń­czy się budżet. Co powsta­nie? Zobaczymy jak skończymy.

IIBA czyli czym jest ta Analiza Biznesowa

Od pew­ne­go cza­su IIBA pro­mu­je idee Analizy Biznesowej, któ­ra jest poważ­nym zagro­że­niem dla opi­sa­nych wyżej dostaw­ców. Dlaczego? Bo pro­mu­je two­rze­nie doku­men­tów pozwa­la­ją­cych naj­pierw dokład­nie wyspe­cy­fi­ko­wać to co jest potrzeb­ne (czy­taj pomo­że w biz­ne­sie!), potem dopie­ro zosta­je to zamó­wio­ne i dostar­czo­ne lub wykonane.

Nie da się tak? A wła­śnie, że się da. Czy to kosz­tow­ne? Zapytam tak? Co lep­sze nie­przy­dat­ny pro­dukt za 100tys. zł czy przy­dat­ny za 120tys.? Co lep­sze, pro­jekt pla­no­wa­ny na pól roku za 100tys. i wyko­na­ny w ter­mi­nie czy obie­ca­ny za 50tys. w kwar­tał a dostar­czo­ny za 250 tys, po dwóch latach?

To się nazy­wa RYZYKO a ana­li­za i pro­jek­to­wa­nie to zarzą­dza­nie tym ryzykiem!

Co oferuję jako analityk a IIBA zaleca

Porządny pro­jekt analityczny:

[sin­gle­pic id=119 w=533 h=533 float=center]

Kończący się spe­cy­fi­ka­cją wyma­gań (IIBA nazy­wa to Dokument Wymagań Biznesowych):

[sin­gle­pic id=122 w=533 h=533 float=center]

A teraz to co mogę pole­cić: szko­le­nie Analiza Biznesowa w MT&DC. Dostawców nauczy pra­cy a klien­tów wia­ry, że moż­na lepiej. Dlaczego tak pole­cam to szko­le­nie? Bo jego koszt to nic w porów­na­niu do strat jakie gene­ru­je źle zapla­no­wa­ny pro­jekt a któ­rych moż­na unik­nąć lub znacz­nie zmi­ni­ma­li­zo­wać. Nawet jeśli ktoś po szko­le­niu nie będzie potra­fił sam od razu takiej ana­li­zy wyko­nać (bo raczej po trzech dnia nie) to na pew­no będzie w sta­nie oce­nić to co pro­po­nu­ją dostaw­cy a potem zarzą­dzać takim pro­jek­tem. Potem z cza­sem sam (lub na kolej­nych szko­le­niach) nauczy się dobrej ana­li­zy biznesowej.

Na koniec naj­waż­niej­sze, para­fra­zu­jąc stwier­dze­nie Daryll’a: ana­li­ty­kom, któ­rych jedy­nym narzę­dziem pra­cy jest pakiet MS Office, w szcze­gól­no­ści Excel i PowerPoint, z góry dzię­ku­je­my (on uży­wa pro­fe­sjo­nal­nych narzę­dzi CASE i pakie­tów do zarzą­dza­nia projektami).

Inny bar­dzo cie­ka­wy arty­kuł o wyma­ga­niach: Jak zawa­lić pro­jekt infor­ma­tycz­ny. Analiza wymagań.