W co większych firmach lub przy okazji dużych przedsięwzięć zwanych projektami, analitycy to nie jedna lub dwie osoby a grupa ludzi, która opracowuje wymagania, procesy biznesowe, specyfikuje wymagania. Ta grupa ludzi współpracuje z projektantami, programistami oraz ogólnie rozumianym biznesem. W takich organizacjach obserwuję dwa różne sposoby działania. Jeden, w którym nie ma opracowanych zasad modelowania i drugi, gdzie takie zasady modelowania zaczynają lub od dłuższego czasu funkcjonują.
Tam, gdzie zasad nie ma jakość analizy jest bardzo różna. Co analityk to inna technika, co zespół to inne produkty. Powstały chaos nie pomaga w komunikacji z interesariuszami. Trudno też jest wskazać konkrety w dokumentacji przygotowywanej przez kolegę lub koleżankę.
W innych organizacjach powstają zasady, które sprawiają, że analityk wie dokładnie co ma zrobić lub pozornie wie co ma robić. Czasem te działania są nieadekwatne do potrzeb czy analizowanego problemu (czyt. nadmiarowe lub z byt małe) a czasem prowadzą do konfliktów. Spotkałem się już parę razy z sytuacją, w której to różne zespoły (np.: analitycy i programiści) wzajemnie się zwalczali poprzez wytykanie nieścisłości w dokumentacji, jej braki lub niezgodność z przyjętymi regułami/metodykami. Sytuacja ta niewątpliwie nie sprzyja rozwojowi produktu, ale również utrudnia pracę.
Tam, gdzie zaczynają się tworzyć zespoły czy to analityków, projektantów czy też architektów, opracowanie zasad pracy jest bardzo ważne. Mądra standaryzacja pracy to standaryzacja, która uwzględnia nie tylko notacje, używane narzędzia, ale również uwzględnia coś co nazywam Zasadą TAO.
Zasada ta nawiązuje do taoizmu, który zakłada (w bardzo dużym uproszczeniu) akceptację samego siebie, dążenie do spokoju ducha oraz harmonii z otaczającym nas wszechświatem. W inżynierii oprogramowania pod zasadą TAO rozumiem, iż zespół kieruje się: Tolerancją, Autonomią i Odpowiedzialnością.
Tolerancja oznacza, iż każdy z nas postrzega świat inaczej a tym samym budowane modele, tworzona dokumentacja systemu przeważnie będzie inna niż gdybyśmy sami ją zbudowali. Każdy z nas inaczej postrzega świat stąd i modele mogą być inne. Tolerancja nie oznacza, że akceptujemy wszystko. Jeśli czegoś nie rozumiesz zapytaj twórcę artefaktu co miał na myśli a nie oceniaj z góry na jakim to „szajsie” musisz pracować. Czasem wystarczy, gdy odbiorcy dokumentacji powiedzą czego im brakuje lub co należy poprawić. Często udoskonalenia nie wymagają artefakty a kompetencje zarówno twórców, jak i odbiorców dokumentacji.
Autonomia to prawo do tego by każdy z członków zespołu dobierał takich narzędzi (czyt.: diagramów, modeli) oraz takiej perspektywy abstrakcji, które jego zdaniem w danym momencie są adekwatne do projektowanego systemu. To analityk lub projektant ma prawo zadecydować o tym, co i jak będzie zamodelowane. Oczywiście można a nawet trzeba wymagań ustalonego minimum artefaktów, ale trzeba być także otwartym na to, że nasze ustalenia nie obejmują danej sytuacji. Warto jest ustalić jakie artefakty będą dokumentować daną klasę aplikacji, gdyż analiza rozwijanej przez zespół aplikacji będzie wyglądać inaczej gdy jest to przykładowo CRM a inaczej gdy jest to (przykładowo) silnik reguł biznesowych. Dokumentowanie systemu z pudełka, który jest parametryzowany to jeszcze inna historia.
Odpowiedzialność wzmacnia/ogranicza autonomię, bo nie pozwala iść na skróty. Odpowiedzialny członek zespołu projektowego stara się przedstawić model sytemu z tylu perspektyw ile jest potrzeba by był on zrozumiały dla wszystkich interesariuszy. Bierze on też pełną odpowiedzialność za swoje decyzje projektowe i dąży razem z całym zespołem do wspólnego celu.
TAO jest proste w zastosowaniu i nie wymaga rewolucji w organizacji. Czasem wystarczy tylko wziąć głębszy oddech i postarać się zrozumieć współpracownika. Tam, gdzie modele są sercem specyfikacji warto jest zrobić cykliczne warsztaty, na których członkowie zespołu prezentują swoje modele (oraz inne artefakty) i jest przestrzeń na ich omówienie z punktu widzenia zastosowanych technik. Wspomniane warsztaty to także miejsce, gdzie można poprawić standardy pracy, wymienić się wiedzą i ustalić wspólnie, w zespole, czy dotychczas stosowane artefakty w danej sytuacji, w danym typie aplikacji mają sens. TAO to ciągłe doskonalenie kompetencji i warsztatu zespołu.
Fajny tekst, dobre reguły, w sumie konieczne przy pracy w zespole. Ale dla niektórych chyba za trudne do wprowadzenia – niezgodne z ich temperamentem (?), najpierw mówią potem myślą.
Dorzuciłbym do tekstu duuużą garść przecinków :), bo brakuje i trzeba czasami szukać sensu.
Istotnie czasem może być trudno. Zmiany zawsze wymagają czasu i choć odrobiny zaangażowania, ze wszystkich stron. Dzięki za uwagę dot. przecinków :-). W wolnej chwili przejrzę tekst ponownie.
Minęły trzy lata. Brak przecinków przeszkadza w odbiorze bardzo ciekawego tekstu.